Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

☯ Specifying the sender and recipients separately is more efficient, as it gives the SMTP

receiver the information it needs “up front” before the message itself is transmitted. In

fact, the SMTP receiver can decide whether or not to accept the message based on

the source and destination e-mail addresses.

☯ Having this information specified separately gives greater control on how e-mail is

distributed. For example, an e-mail message may be addressed to two recipients, but

they may be on totally different systems; the SMTP sender might wish to deliver the

mail using two separate SMTP sessions to two different SMTP receivers.

☯ In a similar vein, there is the matter of delivering blind carbon copies. Someone who is

“BCC'ed” on a message must receive it without being mentioned in the message itself.

☯ Having this information separate makes implementing security on SMTP much easier.

For these reasons, SMTP draws a distinction between the message itself, which it calls the

content, and the sender and recipient identification, which it calls the envelope. This is of

course consistent with our running analogy between regular mail and e-mail. Just as the

postal service delivers a piece of mail using only the information written on the envelope,

SMTP delivers e-mail using the envelope information and not the content of the message.

It's not quite the case that the SMTP server doesn't look at the message itself, just that this

is not the information it uses to manage delivery.

Note: It is possible for the sender of a message to generate envelope information

based on the contents of the message, but this is somewhat “external” to SMTP

itself. It is described in the standard but caution is urged in exactly how this is

implemented.

SMTP Mail Transaction Details

Let’s take a more detailed look at the SMTP mail transaction process, using as aids the

process diagram in Figure 305 and the example transaction of Table 251 (which has

commands highlighted in bold and replies in italics). The first two steps in the mail trans-

action are responsible for providing the receiving SMTP server with the envelope

information just discussed. The transaction begins by the SMTP sender issuing a MAIL

command. This serves to inform the receiver that a new transaction is commencing, and

also to tell it the “from” information on the “envelope”. An example:

MAIL FROM:<joe@someplace.org>

The e-mail address of the originator is always enclosed in angle brackets (“<”and “>”). The

SMTP receiver acknowledges the command with a 250 (“OK”) reply message, sometimes

sending back the address as a confirmation. For example:

250 <joe@someplace.org>… Sender ok

Next, the SMTP sender uses RCPT commands to specify the intended recipients of the e-

mail that is being sent. Each RCPT line can contain only one recipient, so if multiple recip-

ients are indicated, two or more RCPT commands must be issued. Each one normally

specifies an e-mail address, but if relaying is being used, the command may contain routing

information as well. (As described in the SMTP communication topic, this is not as

commonly done as it was in the past.) For example:

RCPT TO:<jane@somewhereelse.com>

Figure 305: SMTP Mail Transaction Process

Once an SMTP session is established between a sender and receiver, each mail transaction consists of a set

of three command/reply sequences. The sender is first identified using the MAIL command and the recipients

are specified using one or more RCPT commands. The actual mail message is then transferred using the

DATA command, which involves a preliminary reply before the actual message is sent, and a completion reply

when it has been fully received.

SMTP ReceiverSMTP Sender

MAIL FROM

1. Begin Transaction:

Identify Sender

Using MAIL Command

2. Receive MAIL; Begin New

Transaction, Send 250 "OK"

4. Receive RCPT;

Send 250 "OK" Reply

3. Receive "OK" Reply;

Identify Recipient

Using RCPT Command

250

RCPT TO

5. Receive "OK" Reply;

Begin Data Transfer

Using DATA Command

250

Send "." By Itself To Indicate

End of E-Mail Message Body

250

8. Receive and Store E-Mail

Message Lines

9. Receive "OK" Reply; Mail

Transaction Complete

DATA

6. Receive DATA;

Send 354 Intermediate Reply

354

7. Receive Intermediate

Reply; Send E-Mail Message

Headers and Body

(message line)

...

Receive "."; Store E-Mail

Message, Send 250 "OK" Reply

...

Assuming the server accepts the e-mail, it will give a 250 “OK” reply again, such as this:

250 <jane@somewhereelse.com>… Recipient ok

The SMTP sender then issues the DATA command, which tells the SMTP receiver that the

message is coming:

DATA

The SMTP receiver responds with a 354 “intermediate” reply message, such as this:

354 Enter mail, end with “.” on a line by itself

The SMTP sender then sends the e-mail message, one line at a time, with a single “.” on a

line to terminate it. The server confirms the receipt of the message with another 250 “OK”

reply, and the transaction is done.

Key Concept: After an SMTP session is established, e-mail messages are sent

using the SMTP mail transaction process. The SMTP sender starts the transaction

by identifying the sender of the e-mail, and then specifying one or more recipients.

The e-mail message itself is then transmitted to the SMTP receiver. Each e-mail to be sent

is a separate transaction.

Table 251: Example SMTP Mail Transaction

MAIL FROM:<joe@someplace.org>

250 <joe@someplace.org>… Sender ok

RCPT TO:<jane@somewhereelse.com>

250 <jane@somewhereelse.com>… Recipient ok

DATA

354 Enter mail, end with "." on a line by itself

From: Joe Sender <joe@someplace.org>

To: Jane Receiver <jane@somewhereelse.com>

Date: Sun, 1 Jun 2003 14:17:31 —0800

Subject: Lunch tomorrow

Hey Jane,

It's my turn for lunch tomorrow. I was thinking we could

[rest of message]

Hope you are free. Send me a reply back when you get a chance.

Joe.

250 OK

Potential Mail Transaction Complications

While this indeed is quite simple, I should point out that I have only shown an e-mail from a

sender to one recipient, and the case where there are no problems or complications in the

transaction. Due to either command syntax or server issues, it is possible for various types

of errors to occur at different stages of the process, which may result in the transaction

failing. There are also security concerns that may come into play, that may lead to restric-

tions in what transactions a server may allow.

SMTP Special Features, Capabilities and Extensions

The primary job of the Simple Mail Transfer Protocol is of course to implement the TCP/IP

electronic mail delivery system. Whenever the user of an SMTP server gives it an e-mail

message addressed to a non-local mailbox, the server will attempt to transfer it to the

appropriate destination server, using the SMTP mail transaction process. Many billions of

such transfers are performed every day on the Internet, allowing e-mail to quickly reach its

destination anywhere around the world.

SMTP Special Features

In addition to the basic mail transfer mechanism, SMTP includes a number of other features

and capabilities. These allow SMTP to support special requirements and auxiliary needs of

the mail system, and are described in detail in RFC 2821. It would take many topics to

describe them all in detail, so I will just provide a quick summary of the more important ones

here so you know a bit about them:

☯ Mail Relaying: As discussed in the SMTP communication overview, the protocol was

once widely used in a “relaying mode” where e-mail was routed from one SMTP server

to another to reach its destination. Today, the normal method of e-mail transfer on the

Internet today is directly from the sender's SMTP server to the recipient's, using DNS

MX records to determine the recipient SMTP server address. SMTP still includes the

ability to relay mail from one server to another, provided certain conditions are met.

Note that in addition to the inefficiency of relaying, many servers won't relay mail

because this feature has been abused for spamming and hacking.

☯ Mail Forwarding: Under certain conditions, an SMTP server may agree to accept e-

mail for a non-local mailbox and forward it to the appropriate destination. This sounds

similar to relaying but is used in a different way. A common example is when a user

changes his or her e-mail address. If I have worked at XYZ Industries for years and

then retire, the company may no longer wish to let me receive e-mail at the company's

SMTP server. As a courtesy, however, they may forward e-mail sent to me there so I

still receive it at my new company.

☯ Mail Gatewaying: Certain SMTP servers may be configured as e-mail gateways.

These devices “translate” TCP/IP e-mail into a form suitable for another e-mail system,

and vice-versa. Gatewaying is a complex topic because e-mail systems can be so

different; one of the more important problems is the inconsistency of addressing

methods of different e-mail systems.

☯ Address Debugging: SMTP includes a VRFY (verify) command, which can be used

to check the validity of an e-mail address without actually sending mail to it.

☯ Mailing List Expansion: The SMTP command EXPN (expand) can be used to

determine the individual e-mail addresses associated with a mailing list. (Note

however that this has nothing directly to do with mailing list software like Majordomo.)

☯ “Turning”: The original SMTP protocol included a command that allows the SMTP

sender and SMTP receiver to change roles. This could be used to allow SMTP server

A to send e-mail to server B, and then have B send e-mail it has queued for A in the

same session. In practice, this capability was not widely used for a variety of reasons,

including security considerations. It is now officially “not recommended”, but may still

be implemented in some SMTP software.

Other Capabilities and Functions of SMTP Servers

The list above represents just a few of the features that are mentioned in the SMTP

standards. In addition to these, a given type of SMTP server software may be given other

features as well by its developers. The HELP command is one way to determine what some

of the commands that a given SMTP server supports.

SMTP servers also must perform a great deal of “background processing” that doesn't get a

great deal of attention. This includes managing connections, checking for errors in

commands and e-mail messages, and reacting accordingly. They must also be on the

lookout for problem conditions, such as “looping” that may result in an e-mail message

being passed back and forth between two SMTP servers, each thinking the other is the

intended recipient. In the event of an initial failure to deliver mail, SMTP servers are also

required to periodically retry communication with the destination device, and return a failure

message to the sender if it cannot deliver the message after a certain period of time. Again,

RFC 2821 contains more details.

SMTP Extensions

As discussed earlier in this section, during the 1990s many extensions to the basic

operation of SMTP were defined. These are enabled when two SMTP servers supporting

the extension set up a session using the EHLO command and appropriate extension

response codes. Table 252 summarizes some of the more interesting SMTP extensions

that have been defined, and gives the RFC number where each is described.

Table 252: SMTP Extensions (Page 1 of 2)

Extension

Keyword

Extension

Defining

Document

Description

8BITMIME 8-bit MIME support. RFC 1652

Theoretically defines support for the 8-bit

content transfer encoding type in MIME, but

there are complications associated with this. See

the discussion of content encoding in the MIME

section.

AUTH Authorization RFC 2554

Used to implement an authorization mechanism

for servers requiring enhanced security.

On The Web: The full current set of SMTP extensions can be found here: http://

www.iana.org/assignments/mail-parameters

Note: Certain commands in the basic SMTP protocol description that are

considered optional are also sometimes considered extensions, such as the EXPN

and HELP commands; I have not listed these here since they are not true SMTP

extensions.

SMTP Security Issues

If you've already read the sections describing other TCP/IP protocols such as DHCP, FTP

and so forth, you probably already know how I am going to start this section. The theme is a

common one in TCP/IP: a lack of security in how a protocol is implemented. And this all

goes back to a common root cause: most of these protocols were developed when the

“Internet” was just a small group of machines controlled by individuals who mostly knew

and trusted each other, or who were able to use physical security means. Developers never

imagined TCP/IP being used by millions of anonymous “average Joe” users around the

world, which necessitates far more attention to security than a small research internetwork

like the ARPAnet.

DSN

Delivery status

notification

RFC 1891

Allows an SMTP sender to request that the

SMTP receiver notify it a problem occurs in

delivering a message the sender gives to it.

ENHANCED-

STATUSCODES

Enhanced status

codes.

(They should have

abbreviated the

keyword. ☺)

RFC 2034,

RFC 1893

Extends the traditional 3-digit SMTP reply code

format with extra codes that provide more infor-

mation. See the end of the topic on SMTP

replies for more.

PIPELINING Command pipelining RFC 2920

Allows multiple commands to be transmitted in

batches from the SMTP sender to the receiver,

rather than sending one command at a time and

waiting for a response code.

SIZE

Message size

declaration

RFC 1870

Allows information about the size of a message

to be declared by an SMTP sender prior to trans-

mitting it, so the SMTP receiver can decide if it

wants the message or not.

Table 252: SMTP Extensions (Page 2 of 2)

Extension

Keyword

Extension

Defining

Document

Description

When it comes to SMTP, security matters are if anything worse than they are with the other

protocols I mentioned above. Not only does SMTP not have any real security mechanism,

the original relaying model of SMTP communication is entirely designed around the idea of

“cooperation” and “trust” between servers. Since most SMTP servers would be asked to

handle a certain number of intermediate transfers, each server was required to accept mail

from any originator to be delivered to any destination.

The basic assumption in this model is that SMTP servers would all be “well-behaved”, and

not abuse the system by flooding intermediate servers with lots of mail to be delivered, or

sending bogus messages to cause problems. This all changed as the Internet exploded in

popularity in the 1990s. Con artists, hackers, and disreputable salespeople all discovered

that e-mail could be used for “free” delivery of messages simply by submitting them to an

SMTP server for delivery. The result was overloaded servers, primarily due to the sending

of large quantities of unwanted e-mail, which Internet users commonly call spam.

Note: The term “spam”, in this context, does not have anything directly to do with

the Hormel processed meat product. Its use in reference to massive amounts of e-

mail comes from a Monty Python comedy sketch where that word is repeated over

and over again.

It is actually very easy to “impersonate” an SMTP server. You can use the Telnet Protocol to

connect directly to an SMTP server on port 25. SMTP commands are all sent as text, and

so are SMTP replies, so you can have a “conversation” with a server and even manually

perform a mail transaction. This is useful for debugging, but also makes abuse of a wide

open SMTP server trivially easy. Since spammers often don't want to be identified, they

employ spoofing techniques to make it more difficult to identify them, which makes matters

even more difficult.

Common SMTP Server Security Techniques

Despite this obvious problem, efforts to implement a general security mechanism in SMTP

have been resisted for two main reasons. First, there is no foolproof way to retrofit a new

security mechanism onto something as widely used as SMTP without creating incompatibil-

ities between newer and older systems. Second, many administrators were reluctant to

completely do away with the general notion of cooperation between sites that has helped

make the Internet so successful, simply due to a few “bad apples”.

Still, something had to be done. The compromise was for system administrators to “tighten

up” their SMTP servers through the imposition of both technical and policy changes.

Naturally, these vary from one organization to another. Some of the more common SMTP

security provisions include:

☯ Checking the IP address of a device attempting connection and refusing to even start

an SMTP session unless it is in a list of authorized client devices.

☯ Restriction of certain commands or features, such as e-mail relaying, to authorized

users or client servers. This is sometimes done by requiring authentication via the

SMTP extension AUTH before the command will be accepted.

☯ Limiting the use of commands such as EXPN to prevent unauthorized users from

determining the e-mail addresses of users on mailing lists.

☯ Checking the validity of envelope information before accepting a message for delivery.

Some servers will first verify that the originator's e-mail address is valid before

agreeing to accept the MAIL command. Many will check the recipient's address and

refuse the message if delivery is not to a local mailbox. Others use even more

advanced techniques.

☯ Limiting the size of e-mail messages that may be sent or the number that may be sent

in a given period of time.

☯ Logging all access to the server to keep records of server use and check for abuse.

Because of all the abuse in recent years, you will find that most SMTP servers implement

these or other features, even though most of those features are not formally defined by the

SMTP standards. They are instead enhancements built into individual SMTP server

software packages.

Some of these measures can actually get quite sophisticated. For example, the SMTP

server run by pair Networks, the great Web hosting company I have used for years, uses

“POP-before-SMTP authentication”. This means that before the server will accept outgoing

mail from the user via SMTP, the user must first log in to check incoming mail using the Post

Office Protocol. Since POP includes authentication, successful POP login tells the server

the user is authorized. This “flips a switch” in the server that allows the user to access the

SMTP service after that login for a limited period of time. If this seems convoluted, well, you

start to get an idea of the hassle that spammers and hackers have created for Internet

service providers today.

It's also worth noting that SMTP does not include any mechanism for encryption to ensure

the privacy of e-mail transmissions. Users requiring security in who sees their messages

must use a separate encryption scheme to encode the body of the message prior to

submission.

Key Concept: SMTP was designed in an era where internet security was not much

of an issue; as a result, the base protocol includes no security mechanism at all.

Since e-mail is so often abused today, most modern SMTP servers incorporate one

or more security features to avoid problems.

SMTP Commands

I mentioned in the overview and history of SMTP that early TCP/IP e-mail mechanisms

were developed by borrowing techniques and elements from existing application protocols,

especially Telne t and FTP. SMTP is an independent protocol, but its heritage can still be

seen clearly in a few areas. One of the more obvious of these is in the method by which

commands are issued by an SMTP sender and replies returned by an SMTP receiver.

Like FTP, all SMTP commands are sent as plain ASCII text over the TCP connection estab-

lished between the client and server in an SMTP connection. These commands must end

with the two-character “CRLF” sequence that normally terminates ASCII text as required for

the Telnet Network Virtual Terminal (NVT). In fact, you can check the function of an SMTP

server and even issue commands to it yourself, simply by using Telnet to connect to it on

port 25.

SMTP Command Syntax

All SMTP commands are specified using a four-letter command code. Some commands

also either allow or require parameters to be specified. The basic syntax of a command is:

<command-code> <parameters>

When parameters are used, they follow the command code and are separated from it by

one or more space characters. For example, the HELO and EHLO commands are specified

with the command code, a space character, and then the domain name of the SMTP

sender, as we saw in our look at SMTP connection establishment.

Current SMTP Commands

Table 253 lists the commands currently used in modern SMTP, in the order they are

described in RFC 2821, with a brief description of each.

Table 253: SMTP Commands (Page 1 of 2)

Command

Code

Command Parameters Description

HELO Hello

The domain name of the

sender.

The conventional instruction sent by an SMTP

sender to an SMTP receiver to initiate the SMTP

session.

EHLO

Extended

Hello

The domain name of the

sender.

Sent by an SMTP sender that supports SMTP

extensions to greet an SMTP receiver and ask it

to return a list of SMTP extensions the receiver

supports. The domain name of the sender is

supplied as a parameter.

Like FTP commands, SMTP commands are not case sensitive.

Certain SMTP extensions make changes to the basic SMTP command set. For example,

the AUTH extension specifies a new command (also called AUTH) that specifies an authen-

tication method the SMTP client wants to use. Other extensions define new parameters for

existing commands. For example, the SIZE extension defines a SIZE parameter that can be

added to a MAIL command to tell the SMTP receiver the size of the message to be

transferred.

MAIL

Initiate Mail

Transaction

Must include a “FROM:”

parameter specifying the

originator of the

message, and may

contain other parameters

as well.

Begins a mail transaction from the sender to the

receiver.

RCPT Recipient

Must include a “TO:”

parameter specifying the

recipient mailbox, and

may also incorporate

other optional

parameters.

Specifies one recipient of the e-mail message

being conveyed in the current transaction.

DATA

Mail Message

Data

None

Tells the SMTP receiver that the SMTP sender is

ready to transmit the e-mail message. The

receiver normally replies with an intermediate

“go ahead” message, and the sender then

transmits the message one line at a time,

indicating the end of the message by a single

period on a line by itself.

RSET Reset None

Aborts a mail transaction in progress. This may

be used if an error is received upon issuing a

MAIL or RCPT command, if the SMTP sender

cannot continue the transfer as a result.

VRFY Verify

E-mail address of mailbox

to be verified.

Asks the SMTP receiver to verify the validity of a

mailbox.

EXPN Expand

E-mail address of mailing

list.

Requests that the SMTP server confirm that the

address specifies a mailing list, and return a list

of the addresses on the list.

HELP Help Optional command name.

Requests help information: general help if no

parameter is supplied, otherwise information

specific to the command code supplied.

NOOP No Operation None

Does nothing except for verifying communication

with the SMTP receiver.

QUIT Quit None Terminates the SMTP session.

Table 253: SMTP Commands (Page 2 of 2)

Command

Code

Command Parameters Description