This web page contains additions to the book Electronic mail by Jacob Palme with new information added after the publication of the 1995 edition of this book.
Last update: 1 June 1998
This document is available on the WWW on page
http://dsv.su.se/jpalme/e-mail-book/additions.html
A list of corrections to the same book is available on the WWW on page
http://dsv.su.se/jpalme/e-mail-book/corrections.html
To reach an agreement, or at least to make a decision in order to go forward, it is important to get a feeling about the general view of the participants. This is not only a matter of the majority view, a strongly held minority view may succeed against a less strongly held majority view. Most messaging systems do not provide tools to get such a feeling of the general view, and this can seriously restrain progress. In most messaging systems, you only see the opinions of those who actively write messages, while in face-to-face meetings, also the opinions of other participants are felt by a good chairman through body language.
In face-to-face meetings, the limited time and desires of the participants to get results will often stop a discussion on an item when nothing more important is said and the discussion starts to repeat itself. In most messaging systems, there is no such tool to stop discussion, and this can cause discussions to be too longwinded. Experienced chairpersons in messaging groups have developed tools to at least partially alleviate these problems, by forcefully saying "no more discussion on this" and by trying to summarize the opinions.
Many messaging-based groups (mailing lists, newsgroups, bulletin boards, etc.) allow anyone to participate. Sometimes this causes serious clashes between different groups of people who want to discuss different things, and often the only resolution is to split the group or to exclude certain members from further participation. In face-to-face meetings, less drastic measures are often available.
Possible, future development of CSCW techniques will develop computerized tools which will help to solve these problems and be able to replace the face-to-face cues. But such tools are not commonly in use yet. Certainly, chairmen of messaging based groups need to learn new skills in order for the new medium to work well.
Some researchers [5] claim that electronic mail tends to favor something called "flaming", by which is meant stormy debates of uncontrolled outbursts of anger. Other researchers do not agree that flaming is more common in e-mail than in other human communications media or not. The word "flaming" is also sometimes meant to refer to sudden intensive bursts of lot of messages in e-mail distribution lists and conference systems, often on small specialised issues and with much repetition and long-worded contributions. The difficulty of reaching consensus in e-mail may be one reason why such flame bursts sometimes tend to be more long-lived than in other human discourse. Another reason is that there is usually no time limitations in e-mail as in face-to-face meetings. Sometimes etchical rules for e-mail try to discourage flaming by recommending that "if a message makes you angry, wait a day until your anger dies down before writing a reply".
A simplified variant of X.500 called LDAP [6] may become the Internet standard for directory system lookup.
In spite of much work for many years in developing directory systems for e-mail addresses, this has met with surprisingly little success. The reason for this is probably that a global directory system for e-mail addresses, based on a combination of directories from many companies and organizations, is difficult to set up, because of the problem of getting so many organizations to co-operate. An alternative method is to provide directory services by automatically scanning the net for e-mail addresses occuring in web pages and public messages, in a way similar to the way in which web search engines searches the web for documents. This may be a more useful way, several companies provide such directory services, for example WhoWhere?, Four11, Switchboard. Many of the providers of web search engines also provide such directories as a value-added service.
Electronic mail is usually sent and received by humans. But a communication entity (sender or recipient) may also be a computer program. A human can also receive or send a message as a private message or as a message to or from a certain role, such as to the manager of a certain organizational unit. There may be a need to have different electronic mailboxes for different roles for the same person. The mailbox for the role of supervisor may, for example, be handled by a deputy when the supervisor is away. Messages sent to some roles may be delivered to more than one person. The access rights for a person may also vary with the role. The same person may fulfill more than one role, and the action taken by that person can can be marked with the role which the person assumed when performing that particular action (such as writing a message or removing an unsuitable message from a discussion group).
Some roles are basic to some message systems, such as a moderator (who has special rights to control a particular group discussion) and a system administrator (who has superuser privileges to do almost anything, but usually restricted to one server). Other roles belong to the human activities, in which e-mail is used, such as boss, project group leader, archivist, etc.)
Electronic mail systems today usually do not give much support for roles, but this may change in the future, since much research into of computer support for office procedures is based on the concept of roles.
In 1997, the Internet Society (ISOC) decided to extend the list of non-country top-level domains. The new list is the following:
| ARTS | for entitites emphasizing cultural or entertainment activities |
| COM | for commercial companies |
| EDU | for schools and universities |
| FIRM | for businesses or firms |
| GOV | for other government agencies |
| INFO | for entitites providing information services |
| INT | for international and multinational organizations |
| MIL | for military organizations |
| NET | network providers and gateways |
| NOM | for those wishing individual or personal nomenclature |
| ORG | for organizations |
| REC | for entitites emphasizing recreaiton/entertainment activities |
| STORE | for businesses offering goods to purchase |
| WEB | for entitites emphasizing activities related to the WWW |
The work of maintaining and administrating a distribution list can be quite large. Much of this problem is caused by stale entries in the list. By a stale entry is meant an e-mail address in a mailing list, which no longer works, because the mailbox does not exist any more. Some mailing list systems have advanced facilities for handling this problem. Some such facilities are:
None of these methods work perfectly. One problem is that a mailbox may be temporarily unavailable because some mail server is down. This mailbox might then be removed from the list, even though its user wants to stay as a member.
The digits in the SMTP reply codes are used as follows:
| 1 | Positive preliminary (not used in SMTP) |
| 2 | Success |
| 3 | Ready but requires additional info |
| 4 | Transient failure |
| 5 | Permanent negative |
| 0 | Syntax (error) |
| 1 | Information requested in reply |
| 2 | Transport service problem |
| 5 | Application-specific problem |
| 250 | Originator accepted |
| 452 | Out of local storage |
| 500 | Command syntax error |
A number of proposals for extensions to SMTP are being developed. These extensions allow the sending of delivery-report requests, binary and 8-bit data, and an SMTP sender can check if a very large message can be received before sending it. These extensions are only to be used by extended SMTP servers, so there is also a protocol for two SMTP servers to query each other's capabilities at the start of an SMTP session. This protocol thus provides an extension mechanism to SMTP and is called ESMTP (Extended Simple Mail Transfer Protocol). It is specified inRFC 1869. The method of protocol extension used by ESMTP is that the server gives the client a list of which ESMTP extensions it supports, and the client must then only use those extensions which the server says that it supports. This method has many advantages compared to the method of indicating protocol level (like HTTP version 0.9 or 1.0 or 1.1) because a server can choose to provide certain extensions without having to support other less useful extensions.
In plain ESMTP, a session is started by the client sending the HELO command. A client which supports ESMTP send the EHLO command instead of the HELO command. The EHLO command only indicates that the client understands ESMTP, not that the client is capable of handling any particular ESMTP extension.
The table below lists the most important ESMTP extensions:
| Service extension | Keyword | Parameters | Verb | Defined in RFC |
| Send | SEND | none | SEND | 821, 1869 |
| Send or Mail | SOML | none | SOML | 821, 1869 |
| Send and Mail | SAML | none | SAML | 821, 1869 |
| Expand | EXPN | none | EXPN | 821, 1869 |
| Help | HELP | none | HELP | 821, 1869 |
| Turn | TURN | none | TURN | 821, 1869 |
| Pipelining | PIPELINING | none | none | 1854 |
| Message size declaration | SIZE | adds optional parameter size-value ::= 1*20DIGIT no of octets | none | 1870 |
| Support of additional SMTP response codes | ENHANCEDSTATUSCODES | none | none | 2034 |
| Checkpoint/ restart | CHECKPOINT | adds optional parameter TRANSID to MAIL FROM command | none | 1845 |
| Large and binary messages | BINARYMIME | BINARYMIME parameter to the BODY keyword for the MAIL FROM command | none | 1830 |
| Starting remote message queues | ETRN | Name of the client to start processingqueues for | ETRN | 1985 |
| Send one transaction only | ONEX | ? | ? | Sendmail specific |
| Go into verbose debugging mode | VERB | ? | ? | Sendmail specific |
| Large and binary MIME messages | CHUNKING | BDAT is used instead of DATA, and takes as parameter packet length and last packet indication | BDAT | 1830 |
| 8bit-MIME transport | 8BITMIME | adds optional parameter BODY to MAIL FROM, values 7BIT and 8BITMIME | none | 1652 |
| Delivery Status Notification Extension | DSN | adds optional parameters NOTIFY and ORCPT to RCPT command and RET and ENVID to the MAIL command | none | 1891 , 1892 , 1894 |
| Submission versus routing | XUSR | This is the initial submission of this message from the sender's client to the first MTA. | XUSR | Non-standard |
The Internet Mail Consortium keeps a similar list, but which also includes ESMTP keywords in IETF drafts.
Here are three different examples of ESMTP capability negotiations:
| (1) Only mandatory SMTP commands provided |
S: <wait for connection on TCP port 25> C: <open connection to server> S: 220 dbc.mtview.ca.us SMTP service ready C: EHLO ymir.claremont.edu S: 250 dbc.mtview.ca.us says hello |
| (2) | S: <wait for connection on TCP port 25> C: <open connection to server> S: 220 dbc.mtview.ca.us SMTP service ready C: EHLO ymir.claremont.edu S: 250-dbc.mtview.ca.us says hello |
| Basic optional services: EXPN, HELP; | S: 250-EXPN S: 250-HELP |
| Standard service extension: 8BITMIME; | S: 250-8BITMIME |
| Unregistered services: XONE and XVBR | S: 250-XONE S: 250 XVRB |
| (3) ESMTP not supported |
S: wait for connection on TCP port 25> C: <open connection to server> S: 220 dbc.mtview.ca.us SMTP service ready C: EHLO ymir.claremont.edu S: 500 Command not recognized: EHLO |
SMTP often requires many interactions back and forward between client and server. For example, when a message is to be sent to many recipients, the client is expected to send a RCPT TO for each recipient and wait for the response from the server before sending the next RCPT TO. This will make the protocol slow, since interactions across large network distances often cause a delay of one or more seconds.
In practice, many SMTP clients ignore this rule, and send everything without waiting for reply codes, and then gets all the reply codes asynchronously. This is not correct, but usually works. An ESMTP extension specified in RFC 1854 allows a server to indicate that it is capable ot such pipelining.
In the user interface, a MIME message can either be displayed as a sequence of text passages and images, or MIME can be used to send attachments to a primary textual message. The attachments are then not viewed unless the user explicitly asks for them. In practice, the latter usage has been most common. RFC 1806 specifies an e-mail header which can be used to indicate, separately for each body parts, whether this body part is to be shown inline or as an attachment. The format is Content-Disposition: followed by either the word inline or the word attachment. A file name parameter can also be included, indicating a recommended file name if the attachment is stored in a file.
MIME was planned in order to allow messages to contain pictures, formatted text, sound, etc. In practice, MIME has mostly been used to send such information as attachments. The success of the World Wide Web (WWW) means that the HTML (Hypertext Markup Language) has become a very successful format for documents with formatted text and inline graphics. There are two ways of sending HTML in e-mail:
The HTML format often uses more than one file to convey a message. For example, graphics, frames and applets are usually stored in separate files, which are combined by the web browser when displaying the document. Thus, there is a need to send HTML as a set of related body parts which together form the document. This is done using the Content-Type: Multipart/related. The main message will then reference the other parts either through their Content-IDs or through their URLs. If URLs are used, the other body parts are given a heading Content-Location which indicates the URL of this body part.
While X.400 had a standard for requesting and getting delivery notifications from the beginning, Internet mail did not get such a standard until 1996. In Internet mail, this functionality is called Delivery Status Notifications (DSNs), and it is specified in four RFCs:
| RFC 1891 | SMTP service extension, 31 pages |
| RFC 1892 | Multipart/report content-type, 4 pages |
| RFC 1893 | Enhanced status codes, 15 pages |
| RFC 1894 | Delivery Status Notification format, 31 pages |
|
SMTP command |
Optional parameter |
Description |
|---|---|---|
| RCPT TO | NOTIFY | Values: NEVER = do not send any DSNs. SUCCESS = send a DSN if the message was successfully delivered to the recipient mailbox FAILURE = send a DSN if the message could not be delivered to the recipient mailbox DELAY = indicate willingness to accept notifications if delivery is delayed but may succeed later on |
| RCPT TO | ORCPT | Original sender-specified recipient address (needed to allow recpient of notifications to correlate notifications with original recipients, since some gateways will rewrite the recipient e-mail addresses before delivery) |
| MAIL FROM | RET | Values: FULL = return full text of the message with the DSN HDRS = return only headers of the message with the DSN If neither FULL nor HDRS is indicated, this means that no return of either headers or body is requested. |
| MAIL FROM | ENVID | Transaction ID to be returned with notification, so that the sender can find which message sending caused the failture. (Message-ID cannot be used for this, since sometimes the same message is sent more than once with the same Message-ID). |
Part 1 (mandatory) is a human readable message explaining in natural language the cause of the error. This part is mainly intended for recipients whose e-mail clients do not recognize the special format of Part 2 of a DSN.
Part 2 (mandatory) contains a machine parsable account of the reported event, with a special MIME type called Message/Delivery-status.
Part 3 (optional) contains the original message either full or only its headers.
Here is an example of a complete delivery status notification:
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
Message-Id: <199407072116.RAA14128@CS.UTK.EDU>
Subject: Returned mail: Cannot send message for 5 days
To: <owner-info-mime@cs.utk.edu>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/CS.UTK.EDU"
--RAA14128.773615765/CS.UTK.EDU Part 1, in "human-readable" (?) format:
The original message was received at Sat, 2 Jul 1994 17:10:28 -0400
from root@localhost
----- The following addresses had delivery problems -----
<louisl@larry.slip.umd.edu> (unrecoverable error)
----- Transcript of session follows -----
<louisl@larry.slip.umd.edu>... Deferred: Connection timed out
with larry.slip.umd.edu.
Message could not be delivered for 5 days
Message will be deleted from queue
--RAA14128.773615765/CS.UTK.EDU Part 2, in machine-parsable format:
content-type: message/delivery-status
Reporting-MTA: dns; cs.utk.edu
Original-Recipient: rfc822;louisl@larry.slip.umd.edu
Final-Recipient: rfc822;louisl@larry.slip.umd.edu
Action: failed
Status: 4.0.0
Diagnostic-Code: smtp; 426 connection timed out
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
--RAA14128.773615765/CS.UTK.EDU
content-type: message/rfc822 Part 3, return of original message:
[original message goes here]
--RAA14128.773615765/CS.UTK.EDU--
| per-message-fields = | |
| [ original-envelope-id-field CRLF ] | Envelope identifier from request. |
| reporting-mta-field CRLF | MTA which attempted to perform the delivery or relay. |
| [ dsn-gateway-field CRLF ] | Name of gateway which transformed foreign delivery report. |
| [ received-from-mta-field CRLF ] | MTA from which the message was received. |
| [ arrival-date-field CRLF ] | Arrival date to reporting MTA. |
| *( extension-field CRLF ) |
| per-recipient-fields = | |
| [ original-recipient-field CRLF ] | Original recipient when sent. |
| final-recipient-field CRLF | Final recipient to whom delivery status is reported. |
| action-field CRLF | failed, delyaed, delivered, relayed (to non-DSA environment), expanded. |
| status-field CRLF | Status code (RFC 1893) (DIGIT "." 1*DIGIT "." 1*3DIGIT |
| [ remote-mta-field CRLF ] | Name of MTA which reported to reporting MTA. |
| [ diagnostic-code-field CRLF ] | Sometimes less preciste diagnostic code from remote MTA. |
| [ last-attempt-date-field CRLF ] | Time of last delivery attempt. |
| [ final-log-id-field CRLF ] | Log entry in final MTA logs. |
| [ will-retry-until-field CRLF ] | Time when delivery attempts will stop. |
| *( extension-field CRLF ) |
Important: Routing is not done strictly following the hiearchical structure of the DNS. The DNS is used to look up the recipient host, but the message itself is not relayed step by step between the domain elements in the domain name.
MOSS (MIME Object Security Services) (RFC 1847-1848) is a way of combining PEM with MIME.
Users of e-mail often want to forward messages to additional recipients. Forwarding is also often used automatically. A person who has several mailboxes, may want all incoming mail to any of them forwarded to one particular mailbox. Mailing list expansion is also a kind of forwarding, where an incoming message is forwarde to the members of the list.
Some commonly used formats for forwarding of e-mail using Internet e-mail standards are:
Method (a) and (b) will not destroy digital seals on the forwarded message. For method (a), this is true only for seals on the content, for method (b) also for seals on the heading of the forwarded message. This means that with method (b), the recipient of the forwarded messages can check that the message has not been modified by the person doing the forwarding.
The model behind the POP and IMAP protocols is that mail messages are stored in a server, to be downloaded to the e-mail client at request of the user, as is shown by this picture:
Commands in POP and IMAP are textual strings, just like commands in SMTP. Here is a list of the most important commands in POP:
| USER | Client identifies mailbox to be downloaded |
| PASS | Password |
| STAT | Get number of messages and size of mailbox |
| LIST N | Return size of message N |
| LAST | Get highest message number accessed |
| RETR N | Retrieve a full message |
| TOP N M | Retrieve only headers and the first N lines |
| DELE N | Delete message |
| QUIT | Release service |
| NOOP | See if POP server is functioning |
| RPOP | Insecure authentication |
A good description of POP can be found in [12] and the latest RFC specifying POP is RFC 1939.
Internet Message Access Protocol (IMAP) is a more sophisticated protocol than POP. In IMAP, a server can send messages to the client without a request from the client, and several transactions between server and client can go on in parallel. This can be used to reduce the wait time for the users. Each message in an IMAP mailbox has a set of properties, which can be retrieved one or more than one at a time. Examples of properties are a seen flag and a deleted flag on the message. In IMAP, to delete a message you first set the delete flag on the message, and then perform the expunge command. IMAP also has a capability for searching for messages in the mailbox stored in the server. The latest RFC specifying IMAP is RFC 1730
A more up-to-date version of this table can be found from URL
http://dsv.su.se/jpalme/ietf/ietf-mail-attributes.html
Many languages use national characters like Ü, Ä and Ö in German and Scandinavian languages, ¿ in Spanish and é and è in French. There is however a problem in using such characters in e-mail headings.
There are two kinds of heading fields, fields meant for human reading only and fields meant for computer interpretation.
Examples of heading fields meant for human reading only is the subject, the user friendly part of e-mail names (see figure 8.29), comment and keyword fields, the phrase which can occur in Internet In-Reply-To and References fields. For such fields, X.400 recommends T.61, which is an old-fashioned but powerful character set which can handle national characters in many languages. Internet mail originally only allowed seven-bit us-ascii characters in such fields, but MIME has a part [22] which specifies a way of encoding non-ascii characters in such fields. The only problem with this part is that many e-mail systems do not support it, and the national characters will then look extremely ugly when received by users of such e-mail systems (Example: The Finnish name "Männikö" is encoded in this way as "?iso-8859-1?Q?=22=M=E4nnik=F6=22?=").
Examples of fields which computers need to interpret are e-mail addresses and Message-ID-s. The problem with such fields is that users sometimes have to type them in. A user may for example read an e-mail address from a business card, and want to send a message to this address. Thus, users anywhere in the world need to be able to type such e-mail addresses, and people in countries which do not use such national characters may have problems ttyping them on their keyboards.
Because of this, the 1984 version of X.400 only allowed the very limited Printable String character set, in e-mail addresses. This character set was intentionally chosen to be printable by keyboards anywhere in the world. The Internet e-mail standards originally only allowed 7-bit us-ascii characters. In theory, Internet e-mail allowed any 7-bit us-ascii character, by the use of a method called quoting to represent special characters. In practice, this has never worked for e-mail addresses, since many mail systems cannot handle such quoted characters correctly, so in practice Internet e-mail is limited to a small set of common characters similar to the Printable String set used in X.400. Of special importance is that the space characters in practice does not work. A person whose name is Björn Müller theoretically should be able to use an e-mail address like "Björn Müller"@host.net, but in practice, alternate names like Bjoern.Mueller@host.net or bmuller@host.net are used.
X.400 in its 1988 version specified that a person could have two e-mail addresses, one with national characters for use within language areas using such characters, and one without national characters for international usage. This X.400 feature has never been a success and obviously has problems, for example if a national letter is forwarded internationally.
The figure below shows how new articles are forwarded from server to server in Usenet News. A server tells its adjacent servers which items it offers, the server requests those it has not already got via another route.
This figure shows how new articles are forwarded from server to server in Usenet News.
| article [<Message-ID> | <Number>] | Return text of designated article. If no parameter is given, the next article is returned. The current article pointer is put at the fetched article. | |
| body [<Message-ID>| <Number>] | As article, but only returns body | |
| group <newsgroup> | Go to the designated newsgroup | |
| head [<Message-ID> | <Number>] | As article, but only returns head | |
| help | Lists available commands | |
| ihave <messageID> | Informs the server of an available article. The server can then ask for the article or refuse it. | |
| last | Sets current article pointer to last message available, return the number and Message-ID. | |
| list [active | newsgroups | distributions | schema] | Returns a list of valid newsgroups in the format: group last first |
|
| newgroups <yymmdd hhmmss> ["GMT"] [<distributions>] | List newgroups created since a certain datetime. "distributions" can be e.g. alt to only get newsgroups in the alt category. | |
| newnews <newsgroups> <yymmdd hhmmss> ["GMT"] [<distributions>] | List Message-ID of articles posted to one or more newsgroups after a specific time. newsgroups can be. e.g. net.*.unix to match more than one newsgroups. distributions checks for articles which also has this other newsgroup as recipient. | |
| next | Current article pointer is advanced. Returns number and Message-ID of current article. | |
| post | Submit a new article from a client. | |
| slave | Tells the server that this is not a user client, it is a slave server. (May give priority treatment.) | |
| stat [<Message-ID> | <Number>] | As article, but only returns Message-ID. Used to set the current article pointer. | |
| Newsgroups: | Comma-separated list of newsgroups to which this article belongs. Example of newsgroup format: alt.sex.fetisches.feet. Should never occur in e-mail. Use "Posted-To:" instead! | |
| Subject: | Add four characters "Re. " for replies. Do not change subject in replies. | |
| Message-ID: | Mandatory in Network News, and must be globally unique. | |
| Path: | Path to reach the current system, e.g. abc.foo.net!xyz!localhost. E-mail path format also permitted. Compare to Received: and Return-Path in e-mail. | |
| Reply-To: | In news: Where replies to the author should be sent. In e-mail: Ambiguous. | |
| Followup-To: | Where replies to newsgroup(s) should be sent. | |
| Expires: | Suggested expiration date. | |
| References: | Message-ID-s of previous areticles in the same thread. Should always contain first and last article in thread. Compare to e-mail: Usually only immediately preceeding messages.. | |
| Control: | Not used in e-mail. Communication with servers. Body or subject contains command. Subject begins with "cmsg". | |
| cancel | Delete physically a previously sent article. | |
| ihave | Host telling another host of available new articles. | |
| sendme | Host asking for articles from another host. | |
| newgroup | Name of new group, plus optional word moderated. | |
| rmgroup | Remove a newsgroup. Requires approved. | |
| sendsys | Send the sys file, listing neighbours and newsgroups to be sent to each neighbour. | |
| version | Version of software wanted in reply. | |
| checkgroups | List of newsgroups and descriptions, used to check if list is correct. | |
| Distribution: | Not used in e-mail. Limits distribution to certain geographical/organizational area. Example: Distribution: se, no. | |
| Organization: | Of sender. | |
| Keywords: | For filtering. | |
| Summary: | Brief summary. | |
| Approved: | Required for message to moderated group. Added by the moderator, contains his e-mail address. Also required for certain control messages. | |
| Lines: | Count of lines of the message body. | |
| Xref: | Numbers of this message in other newsgroups. Only for local usage in one server. Example: Xref: swnet.risk:456 swnet.sunet:897 | |
(a) To indicate that this message has also been sent via Usenet news to the indicated newsgroups.
(b) To indicate that this is a personal reply, sent only via e-mail, to a message posted on the indicated newsgroups.
Because of this problem, it is better to use the Posted-To header in e-mail to indicate that a message has also been sent to certain newsgroups, and e-mail recipients should ignore any newsgroups heading in an e-mail message.
When this is written (September 1996), MIME is not used much in Usenet News. Instead of BASE64, UUENCODING is used in Usenet News to include binary attachments. Also, because of message size restrictions, large attachments are very often split into several messages in Usenet News. This also occurs in e-mail, but is more frequent in Usenet News, since some Usenet News servers try to save space by not accepting articles above a certain size limit. Both MIME and Usenet News have methods of indicating how a client can automatically combine parts into a complete message or attachments. MIME encoding is however used a little in Usenet News, and may become more common in the future.
Usenet news has a cancel command, which can delete messages already sent out. Only the author of the cancelled message and the local newsserver administrator is allowed to cancel a message. Since, however, it is very easy to fake your identity, this command poses an obvious security risk, and the command is known to have been used to cancel messages for political reasons. The command is also used (not quite appropriate) by cancelbots, robots (= automatic programs) which cancel obvious spams by identifying messages with the same content sent to many disparate newsgroups. Usenet news also often has a Supersedes header field, which refers from a new message to an old message. This header usually cancels the old message.
Obsoletes in X.400 has some similarities to Supersedes in Usenet News, and can also be used to get an effect similar to the cancel command, by obsoleting a message with an empty message. However, cancel in Usenet News really deletes messages, while obsoletes is information to the recipient UA, which need not cause deletion. Many UA-s store both the new and the old version, so that the recipient can choose to see the obsoleted version if he so wishes.
Mail software often have a need to store collections e-mail messages. Such collections are sometimes named mailboxes, sometimes named folders or directories. MTAs need to store messages to be sent or delivered, UAs need to store messages which the user has not seen, or which the user has seen and wants to save. It would obviously be useful to be able to read such a mailbox, produced with one mail software, using another mail software. Because of this, many (but not all) mail software products use a de-facto standard format for such mailboxes. This de-facto standard is usually designated "Berkely Mailbox format" or "MBOX format". The main principle of the format is that all messages in a mailbox are stored in one sequential file, with special separators between the messages. These separators are lines with the syntax:
[">"] "from" [" " | "_"] <addr-spec> <date>
for example
From ???@??? Fri May 09 20:21:24 1997 (produced by Eudora)
or
From major@linus.isoc.org Sat May 18 11:50:50 1996 (produced by Pine)
where <addr-spec> is an e-mail address formatted according either the format defined in RFC 822 [17] or the format defined in RFC 976 [47], and <date> is a date according to the format defined in RFC 822, but sometimes without the "," between the day of the week and the day of the month.
This format is not a particularly good format. It is
Some mail software solve the inefficiency problem by using this format, but combining it with a separate direct access table listing the byte numbers where each message starts in the file.
Note: A line beginning with "From " is not a valid e-mail header line and should not occur in e-mail when sent using Internet e-mail standards.
There is no published standard which defines the MBOX format, but one defintion can be found in RFC 976 [47] section 2.4.
By spams is meant obviously inappropriate message, usually of an advertisting kind, sent to multiple mailing lists or as personal mail. Spams became more used around 1995-1996, and many mailing list software contain methods to recognize spams (by recognizing the same message sent to many lists, and by recognizing certain elements in spams, like faked senders. A similar function is the cancelbots in Usenet News, see page 154.) Legal control to restrict spamming can be expected, since otherwise the recipients are forced to pay the cost of advertising they receive.
| RFC 1652 | SMTP Service Extension for 8bit-MIMEtransport |
| RFC 1664 | Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables |
| RFC 1685 | Writing X.400 O/R Names |
| RFC 1711 | Classifications in E-mail Routing |
| RFC 1730 | Internet Message Access Protocol - Version 4 |
| RFC 1734 | POP 3 Authentication command |
| RFC 1740 | MIME Encapsulation of Macintosh files - MacMIME |
| RFC 1766 | Tags for the Identification of Languages |
| RFC 1767 | MIME Encapsulation of EDI Objects |
| RFC 1806 | The Content-Disposition Header |
| RFC 1844 | Multimedia E-mail (MIME) User Agent Checklist |
| RFC 1845 | SMTP Service Extension for Checkpoint/Restart |
| RFC 1846 | SMTP 521 Reply Code |
| RFC 1847 | Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted |
| RFC 1848 | MIME Object Security Services |
| RFC 1854 | SMTP Service Extension for Command Pipelining |
| RFC 1855 | Netiquette Guidelines |
| RFC 1864 | The Content-MD5 Header Field |
| RFC 1865 | EDI Meets the Internet: Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet |
| RFC 1869 | SMTP Service Extensions |
| RFC 1870 | SMTP Service Extensions for Message Size Declaration |
| RFC 1873 | Message/External-Body Content-ID Access Type |
| RFC 1891 | SMTP Service Extension for Delivery Status Notifications |
| RFC 1892 | The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages |
| RFC 1893 | Enhanced Mail System Status Codes |
| RFC 1894 | An Extensible Message Format for Delivery Status Notifications |
| RFC 1896 | The text/enriched MIME Content-type |
| RFC 1911 | Voice Profile for Internet Mail |
| RFC 1939 | Post Office Protocol - Version 3 |
| RFC 1947 | Greek Character Encoding for Electronic Mail Messages |
| RFC 1957 | Some observations on Implementations of the Post Office Protocol (POP3) |
| RFC 1991 | PGP Message Exchange Formats |
| RFC 2015 | MIME Security with Pretty Good Privacy (PGP) |
| RFC 2017 | Definition of the URL MIME External-Body Access-Type |
| RFC 2034 | SMTP Service Extension for Returning Enhanced Error Codes |
| RFC 2045 | Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies |
| RFC 2046 | Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types |
| RFC 2047 | MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text |
| RFC 2048 | Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures |
| RFC 2049 | Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples |
| RFC 2060 | Internet Message Accesss Protocol - Version 4rev1 |
| RFC 2076 | Common Internet Message Headers |
| RFC 2110 | MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML) |
| RFC 2111 | Content-ID and Message-ID Uniform Resource Locators |
| RFC 2112 | The MIME Multipart/Related Content-type |
| RFC 2183 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field |
| RFC 2184 | MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations |
If you find anything more, that you think should be included in the book, notify
me so that I can keep this list of additions to the book up-to-date. The additions
list will be available at URL:
http://dsv.su.se/jpalme/e-mail-book/additions.html
Send proposals for additions to:
Jacob Palme <jpalme@dsv.su.se>
Fax: +46-8-783 08 29
Phone: +46-8-16 16 67
Snail-mail: DSV, Electrum 230, S-164 40 Kista, Sweden