Chapter 28

passim

RFCs 821 and 822 have been superseded by 2821 and 2822. Despite their numbers, these RFCs actually date as RFCs from April 2001. In particular, RFC 2821 makes support of EHLO (the extended form of HELO) compulsory for MTAs. However, many MTAs, such as midge's, do not support it.

p. 441

The statistics at the start of this chapter are very dated. For an opposing point of view, see the UK $\leftrightarrow$US (fat pipe) statistics⁵³ at http://bill.ja.net. However, we also notice that different universities have very different patterns of usage⁵⁴. The average size of message has also changed drastically -- a brief look at my e-mail box shows an average size of 20K bytes.

p. 441

This figure looks somewhat dated today. It still applies to the user interacting directly with a user agent such as PINE⁵⁵, but tools such as Simeon or Microsoft Outlook employ a more sophisticated model (see the note labelled ``Chapter 28'' below). Nevertheless, it is important to understand this model first.

p. 442

Sendmail is indeed the MTA shipped with most Unix systems. However, it is notoriously buggy (the original ``Internet worm'' exploited a hole in sendmail) and has a weak security model, so many sites, especially universities, have replaced it with a more modern MTA, such as MMDF, qmail or exim. Notice, from Figure 28.1, that changing the MTA might change the way the UA interacts with the MTA (for example, sendmail places incoming mail for jhd in /usr/spool/mail/jhd, whereas most of the others place it in ~jhd/.mail), but not the way that MTAs interact with each other, since that is specified by the SMTP protocol.

Figure 28.2

Note that the sender waits for an acknowledgement of each command before sending the next. This is normal in SMTP, though earlier standards do not comment on this. RFC 2920 specifies an SMTP extension that allows a server to declare that it will accept multiple commands (often called ``pipelining''), and specifies what the client may then do. This can reduce the number of small packets exchanged, and reduce the latency in mail delivery, particularly when there are a large number of destination addresses. It also avoids the problem mentioned in Exercise 28.4.

p. 445

The ``minimal commands'' now have the extension EHLO as well as HELO, and RFC 2821 added EXPN to the required list. TURN, SEND, SAML and SOML are now deprecated: TURN has serious security problems.

p. 445

The headers are now defined in RFC 2822, with several changes. In particular time zone names (such as MST = ``Mountain Standard Time'' on the example on p. 443) are deprecated, and should be replaced by numeric values, e.g. $-0700$ in the case of MST..

p. 446

Figure 28.3 is in fact a revised version of Figure 28.1.

Figure 28.3

The University of Bath's configuration is rather like either half of this diagram. The main difference is that there are two relay MTAs: primary pat.bath.ac.uk and secondary mercury.bath.ac.uk, with the choice determined by MX records (see page 450). If one looks up internally, one also sees bucs.bath.ac.uk, which is an alias for all the Unix servers, but this is not advertised externally (an example of so-called ``split horizon DNS'').

p. 448

RFC 1123's requirement that a mail sender should not give up for at least four days imposes a requirement on MTAs that they should not be down for more than four days. Institutions that close over, say, the Christmas-New Year period will cause mail sent to them to be returned to the sender as undeliverable.

p. 449

The interaction between an MTA and the DNS is now specified in RFC 2821. In particular, CNAME records should only be looked for if there are no MX records, so step 2 is wrong.

p. 452

While recipient MTAs generally perform a reverse (PTR) lookup on the incoming IP address, and sometimes print a humorous message, it is rare for them to log the failure to match the result of the reverse lookup. The failure might be a consequence of a mis-configured DNS, but it might also indicate an attempt at mail forgery.

Section 28.4

Although MIME was originally designed for the SMTP community, it has been taken up, in great volume these days, by the Web community: see III/p. 168, as a way of conveying various types of data over HTTP. The fundamental problems are the same.

p. 452

RFC 1425 has been obsoleted by RFC 1651, itself obsoleted by RFC 1869, and now by RFC 2821.

p. 453

Similarly, RFC 1427 (the SIZE option) has been obsoleted by RFC 1653, itself obsoleted by RFC 1870, and now by RFC 2821. It should be noted that the SIZE option changes the format of the Mail From command, and hence should not be used unless the recipient signals that it is acceptable.

p. 454

RFC 1522 has been obsoleted by RFCs 2045-9, themselves updated by RFCs 2184, 2231, 2646 and 3023.

p. 454

ISO standard 8859-1, commonly known as ISO-Latin-1, is an encoding for the letters found in (western) European latin-based alphabets, such as the ``é'' in the examples.

p. 456

MIME is the mechanism by which attachments are transferred, and hence has become ubiquitous in the Internet. This emphasises Stevens' point, that the MTAs require no modification. RFC 1521 has been obsoleted by the family RFC 2045-9, themselves updated by RFCs 2184, 2231, 2646 and 3023.

p. 457

Another very common application these days is msword; there are also x-excel, pdf, rtf, mac-binhex40 etc.

p. 457

The access-types allowed are ftp, anon-ftp, tftp (rarely used), local-file and mail-server.

Chapter 28

We said under page 441 that the diagram looked somewhat dated today. With the growth of mobile computing and ``e-mail at home'', the view of that diagram, that a user only ever interacted with one user agent and a local message store, is fast becoming obsolete. The view that many users adopt today can be seen as

$$\hbox{\rm User}\underbrace\longleftrightarrow_{\hbox{\rm key... ...underbrace\longleftrightarrow_{\hbox{\rm SMTP}} \hbox{\rm MTA}$$

at least as far as receiving is concerned. There are two very different kinds of candidates for ***.

POP

=Post Office Protocol, see RFC 1939 (as updated by RFCs 1957, 2449). This is based on the rural American view of a post office: one goes down there, posts some mail previously written, picks up the new mail, and goes back home, to read the mail and write some more. Here, ``goes down'' means logging in to the Mailbox (POP) server, sending stored mail, and retrieving all new messages. This is intended for use when dial-up is not cheap, since human reading and writing can be done off-line, but can be very expensive if one receives large attachments, since they are downloaded as well.

IMAP

=Interactive Mail Access Protocol, see RFC 2060 (obsoleted by RFC 3501) and 2683. This, though the later of the two protocols⁵⁶, is closer to the traditional model of electronic mail as described by Stevens. Here we assume that the user's software interacts with the mailbox, not because they are on the same machine, but via a well-defined protocol -- IMAP.

IMAP views the ``mailbox'' as a sequence of (possibly hierarchically-nested) folders, each containing messages and one of which is the ``inbox'', and provides facilities to list the contents of a folder, to retrieve header information about a message (without retrieving the whole message: important if there's a 5Mb attachment!), to retrieve the whole message, to delete/copy messages and so on (24 commands in all). To send messages, the user agent becomes an MTA and communicates the message via SMTP (generally to a relay MTA, as in the top half of Figure 28.3).

IMAP user agents tend to assume that TCP/IP connections to the IMAP server (port 143) are always open, and that SMTP (port 25) connections to the relay MTA (which could, but need not, be the same machine) are always possible.

While IMAP is becoming more popular, the choice between IMAP and POP depends mostly on the user needs, driven themselves by the cost of communication. As regards authentication mechanisms, the two are converging (see RFC 2195).