Electronic mail book additions

Electronic mail book additions

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

Table of contents


Decision making problems (addition to page 16):

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".

Directory systems (extension of chapter 6.11 page 51-52)

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.

Roles (extension of chapter 6.14 page 56)

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.

The outermost domain (revision of chapter 7.2.2 on page 65)

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

Mailing list management (addition to page 75 section 7.4)

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:

  1. Send a message, once a year or so, to all members, asking them if they want to stay on the list. Those who want to stay must reply to this message, if a user does not reply, that user is removed from the list.
  2. Send a probe message to all or some members. The probe message has a different identification code for each recipient. Thus, when the non-delivery message comes back, the software can find this identity code and automatically delete this mailbox from the list.

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.

SMTP reply codes (addition to page 131 after Table 8.1):

The digits in the SMTP reply codes are used as follows:

First digit:

1 Positive preliminary (not used in SMTP)
2 Success
3 Ready but requires additional info
4 Transient failure
5 Permanent negative

Second digit:

0 Syntax (error)
1 Information requested in reply
2 Transport service problem
5 Application-specific problem

Examples of reply codes to the MAIL FROM command:

250 Originator accepted
452 Out of local storage
500 Command syntax error

SMTP extensions (addition to page 131 after Table 8.1):

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 command pipelining

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.

Content-disposition (addition to page 140):

In-line or attachments

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.

Sending HTML in e-mail

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:

  1. Use the message/external-body MIME body part, which means that the e-mail message only contains a URL (Uniform Resource Locator) of the actual message, and the recipient mailer will then use this URL to retreieve the message from the net just like viewing an ordinary web page [RFC 1873 + not-yet-ready IETF standard for URLs in external body parts].
  2. Send the HTML text within the message, using the Content-Type Text/HTML.

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.

Delivery status notifications

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
Requests for delivery status notifications is sent via SMTP, using optional parameters to the RCPT TO and MAIL FROM commands:

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).
While the requests for DSNs are sent via SMTP, the DSNs themselves are specially formatted MIME messages. A DSN is sent as a MIME message with the Content-Type Multipart/Report. A Multipart/Report consists of two mandatory and one optional part:

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--


Here are some of the fields which can occur in a Delivery Status Notification:
Fields which apply to the whole message:

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 )

Fields which apply to only one recipient at a time:

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 )

Use of the DNS for routing (addition to page 132 section 8.6.3)

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 security features (addition to page 141 section 8.6.7):

MOSS (MIME Object Security Services) (RFC 1847-1848) is a way of combining PEM with MIME.

Forwarding of e-mail (addition on page 141)

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:

  1. Add new Resent-headers to the original message. Example of a message header with Resent-headers:
    Resent-From: Jacob Palme <jpalme@dsv.su.se>
    Resent-To: Mary Collins <mary@boxmail.box.net>
    Resent-Date: 17 Oct 1997 14:53:05 +0200 (MET DST)
    Date: Thu, 16 Oct 1997 14:47:15 +0200 (MET DST)
    From: lars <lars@dsv.su.se>
    To: Jacob Palme <jpalme@dsv.su.se>
    Subject: Re: Here is a message which will get Resent headers
    In-Reply-To: <v03110748b06bbc9984fb@[130.237.158.12]>
    Message-ID: <Pine.OSF.3.95.971016144005.10042A-100000@tellus.dsv.su.se>
    MIME-Version: 1.0
    Content-Type: TEXT/PLAIN; charset=US-ASCII
  2. The forwarded message is made into a body part of type message/rfc822 in a new multipart message:

  3. The text of the forwarded message is simply copied into the text of the new message.

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.

 

POP and IMAP (addition to page 141 section 8.6.8):

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

Table of e-mail headers (addition to page 144 Section 8.6.10):

A more up-to-date version of this table can be found from URL
http://dsv.su.se/jpalme/ietf/ietf-mail-attributes.html

Use of national characters in e-mail headings and addresses (addition on page 150)

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.

Fields meant for human reading only

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?=").

Fields meant for computer interpretation

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.

Network News Transport Protocol (addition to page 151 after figure 8.31):

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.

The table below lists the most common NNTP commands:

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
There is a problem with the newsgroups header in a message sent via e-mail. Different systems use this header in two different ways:

(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.

Cancel command in Usenet News (replacement for the top paragraph on page 152)

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.

8.15 Berkeley Mailbox (MBOX) Format (page 159)

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.

Spamming (addition to page 181)

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.

Table of RFCs of special interest (addition to table on page 218)

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

References

[5]
Sproull, Lee and Kiesler, Sara, Connections: New Ways of Working in the Networked Organization. MIT Press, Boston 1991.
[12]
Rose, Marshall T: The Internet Message: Closing the Book with Electronic Mail. Englewood Cliffs, NJ: Prentice-Hall 1993.
[47]
Horton, M., UUCP mail interchange format standard. RFC 976, January 1986.


Anything more that should be included in the book?

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

Back to the home page for the book "Electronic Mail"