Email Addressing
A Proposal

Wednesday, October 21, 1998

Abstract

There is much talk about moving the control and definitions of services to the periphery of the network. Email is a good example of and end-to-end facility, except that the definition of an email address or end-point is still defined by the service provider rather than the user. To be more specific, if I want to provide a family member with an email address or define an additional address for a new role, I often must buy a mail box from an ISP. This is less flexible than the post office which delivers mail to an address and lets me read the envelope to deliver it to the appropriate household member. The same problems exist for businesses that do not own their own mail domains: They cannot individualize email without paying for each addressee. This should not be necessary.

This proposal provides a simple solution that is compatible with current mail systems. It defines a standard syntax for interpreting email addresses so as to allow portions of the address to be used for further delivery. It also suggests a shift away from the interactive protocol of send mail. Instead all the information is embedded in the data stream (or file). In practice, the interactive handling of addresses in SMTP is of limited utility since it only applies to one step in the mail delivery process. By defining a way to include envelope information in the mail file we can standardize current ad-hoc procedures while allowing for more flexible mail handling.

There is a long history behind this proposal. Email has typically been considered as a way to communicate between users on time sharing systems. As I attempted to provide email for users outside of the core set of machines I find myself running into the implicit assumption that the administrator knew about all the mailboxes. This implicit assumption is still with us even as computing itself as moved beyond these centrally administered systems.

Please send me comments and suggestions" .

Background

It is useful to compare and contrast email messages and paper messages. The message consists of three parts:

1. The Envelope. The envelope is the only part of the letter that the post office uses for delivery. In fact, it is illegal to look inside of the letter. The envelope is less visible in an Internet message since it is only used in transmitting the message from one system to another and then discarded. This is in sharp contrast to the post office, which delivers the letter with the envelope intact so that further delivery is possible. The loss of the envelope is a major limitation of email.
2. The Header. This is the descriptive information associated with a letter, also known as the "inside address" since the purpose is to allow final recipient to better understand the letter, even when delivered to a different person. Neither the post office nor the email delivery systems look at the header. The address in the header has no direct connection to how the letter is delivered.
3. The Body. This is the message itself.

RFC-822 and its descendents have defined standard fields in the header of the letter to allow programs to better process the messages. Since the header information is only to provide information to the mail reading program, a message can still be delivered without any header at all even if it confuses the user by not having "from" and "to" information.

A large infrastructure has grown up around standard text messages. This has made the delivery of messages very efficient and inexpensive. But the message format was not sufficient for handling the rich message formats that became common as personal computers allowed richer messaging. Instead of creating a competing infrastructure, Nathaniel Borenstein and Einer Stefferud solved that problem by extending the message format without sacrificing compatibility with the standard email delivery systems. The MIME extensions defined a syntax for transporting multipart messages with binary information within the restrictions of the standard text messaging. It wasn't until HTML become a de facto standard that there was wide agreement on a format for enriched text messages.

Message Delivery

Although we have extended the format of messages, we are still stuck with a bad model for message delivery.

Email systems grew up in a time-sharing environment in which each user had a mailbox. A message were sent from one user's mailbox to another's mailbox. With the introduction of the ARPANET the address syntax as extended to include the name of the recipient's computer system. This has since evolved into the Domain Naming System. e have standardized a simple address format User@Host.

This same addressing model was also present in the formal X.400 standard, which had a hierarchical delivery model. Messages, with envelopes, were relayed between administrative mail systems until final delivery to the user's mailbox. The intermediate systems were Message Transfer Agents or MTA's, and the final delivery was the User Agent.

This is in sharp contrast to the how the postal systems treat the address. They only interpret enough of the address to get the message to the recipient's mailbox or an intermediate delivery address as when sending "care of" someone else. A family or company shares a common mailbox and then is responsible for final delivery. You don't need to register family members with the post office in order to get mail. In fact, you can send mail to your dog or a made-up name. You can also accept mail in care of someone else

The whole notion that we must register every email address with an ISP is very strange and limiting. And the ISP is rewarded for inconveniencing us by be able to charge for each additional mailbox.

While it is natural to think of each address as being associated with a person, addressing can be used for other purposes. You might subscribe to a magazine using a fictitious middle name so that when you get junk mail to that name you know it was due to the subscription. You should be able to do the same thing with email by a new address (or subaddress) when you add yourself to a mailing list. This way you would know with certainty the source of the email. This can also be helpful in managing spam.. In general, naming and addressing is an important tool for technical and social purposes. Current email standards are simply oblivious to this issue just as they used to be oblivious to the value of typography and presentation.

A Proposal for Extending Email Addresses

An Architecture

The architecture of an address can be very simple. If we didn't have to deal with compatibility we could simply use the domain name as a model. I could simply direct comments about this essay to comments.bobf.Frankston.com. No @ sign since we are removing the us vs them boundary implicit in the current email delivery systems.

Mail would be delivered according to the right-most fields that identify a delivery point. Thus the mail could be delivered to Frankston.com which would then place the message in my BobF mailbox tagged with Comments. In order to allow me to do further processing or delivery, it is necessary to retain the envelope.

Compatible Addressing

Just as with the other extensions, it must remain within the constraints of the current infrastructure. This means that we retain the @ for identifying an initial delivery point. For systems that don't understand the new addressing, the name on the left side will continue to be a mailbox name.

For newer systems, the information on the to the left of the @ can be parsed. There are already a number of systems that do this by taking the portion of the left hand side before a delimiter such as "+" or "=" and using it as the mailbox name while retaining the right hand portion to allow further processing. Thus in the example above, I could use BobF+Comments@Frankston.com. This is viable, but if we have the freedom to rethink the syntax, it would be more consistent to use the "." as a delimiter as in Comments.BobF@Frankston.com. In this format, the "@" is treated the same as a ".". It allows any degree of further processing.

Of course, if my mail system can't handle the extended address format, I can't use the extensions for mail to me. But I can use this format to send messages from existing systems without requiring changes to support the extensions. because the address is simply a text string.

Retaining the Envelope

A fundamental problem with email delivery systems is that the envelope information is "out of band" � in that the envelope is not in the data stream. It is only used in the transport protocols such as SMTPand UUCP. To allow more flexible delivery, we must keep the envelope information in-band.

Ideally, we would do this with the envelope separate from the header. It is important to distinguish between the header and envelope fields, since their roles are very different. Only the envelope fields are used for mail delivery, and they may be rewritten to assist in delivery.

But in order to be compatible with existing mail systems, we compromise by placing envelope fields in the header area of the message. There are already examples of envelope information in header fields, including the "received" fields,in UUCP and "x-receiver" fields in some SMTP implementations.

As part of this specification, we need to formalize the use of the header portion of the data stream as a way to pass envelope information by requiring that all envelope fields be prefixed with "envelope-". Standard envelope fields include:

• Envelope-Sender. Equivalent to SMTP "mail from"
• Envelope-Recipient. Equivalent to "rcpt to"
• Envelope-Received. Used for tracking mail transports. In order to avoid order-dependencies, each of these should be numbered. In fact, we can use this as an opportunity to formalize the format of these subfields by using a "name=value" syntax. Standard names may be: Hop, FromHost, FromTime, ToHost, ToTime.

Since these are envelope fields, we are free to rewrite them as necessary. For example, if the recipient is a mailing list, the Envelope-Recipient field must be replaced with the recipients from the list.

By having a standard for including the envelope information in the data stream, we can pass the entire message including the envelope in a file or a mailbox. This means that mail can be queued through an existing mailbox and transported using a simple protocol such as POP. Thus, as noted above, end-user mail rules can be used to process the mail for further delivery or for organizing the mail.

Upgrading Mailing Lists and More

The extended address can be used to allow a family to share a mail address as in Joe.Smith@Families.xyz. It can also be used to manage one's own mail.

When joining to a mailing list, one can, and should, use a unique name for each list. Thus instead of being User@host.com on every mailing list, we would typically use listname.User@Host.com. Any mail to that address must have come via the list. Mailing list software should be upgraded to support such addresses. Even if the list maintainer limits entries to the "from" address, adding a subaddress allows for flexibility while still preventing abuse, such as adding others to the list.

One can even create a new address for each letter and thus track messages associated with a given conversation. The address field is just a text string and the only requirement is that it is able to pass through intermediate systems.

Some Benefits

1. All family members can get email addresses without artificial constraints. You can also register whimsical names.
2. Email addresses can be used creatively. For example, by tagging a name used to subscribe to a list, the source of the address can be identified even if it the address is hidden in a secondary mailing list or passed on to a third party.
3. Better management of email addresses, such as by adding a signing value, makes it easier to identify unsolicited mail. Each mention of one's address in a discussion can get a unique tag. This might be part of an effective way to control spam.
4. By including the envelope information in a mail file, messages can be passed through file drops or other means without the need for direct connections. This includes messages passed through a single mail file such as reading Unix mail via POP.

A Technical Summary

Compatibility

The extended delivery address is consistent with current addressing formats. It follows the standard name@domain syntax. Extended addresses are only available to recipients whose systems support them. These addresses are valid on all current systems for address lists and other purposes.

Address Interpretation

When a message is received, the right-hand side is parsed to determine a local delivery or relay point. The address is retained for further interpretation after delivery. As with a DNS name, the "." is the syntactic delimiter and interpretation is right to left.

Systems receiving mail may be liberal in their interpretation of addresses and accept messages using wild-card domain names and then apply transformation rules to the whole name. Thus, a message to a.b@c.d.e may be accepted by and rewritten as a.b.c@d.e for local delivery. This is a "may" rather than a "must" since c.d.e and d.e can represent entirely different MX records.

Embedding the Envelope

In order to allow more flexible relaying of messages, we must represent the envelope information in the data stream. Envelope fields are prefixed envelope-.

Since older systems will not understand these new fields and will only process older fields. This means that these older fields will take priority over the newer ones if both are present.

For compatibility, existing envelope extensions, such as received may be retained but their envelope- fields should also be present. This is redundant but allows for transition to the improved syntax. If both are present, the older forms need to take priority since mail transports that do not support the extensions will pass them through and only do transformations to the older forms.

Conclusion and Action

The extensions I've proposed are compatible with existing systems and remedy a glaring deficiency in current email delivery. This is not a return to the old days of !@#%. It is simply a correction for a shortcoming in existing email systems. By agreeing to simple syntax extensions we allow for enhancing cooperation among email systems, while maintaining full compatibility with the existing infrastructure.