standard behavior
Standard behavior illustrates email simple store and forward mechanisms, that have been devised long before privacy regulations. Here we describe the most usual patterns that a message may go through, highlighting the problem of managing personal data, a.k.a. personally identifiable data.
Except for the first case, direct delivering, store and forward involves multiple parties, and thereby involves privacy concerns.
Direct personal message
Normal delivery accounts for the majority of messages. The illustration introduces the concepts of MSA (Message Submission Agent, a.k.a. outgoing mail server) and MX (Mail eXchanger, a.k.a. incoming mail server). All servers are labeled according to the first role they play along the illustrated message path. For example, the MSA also acts as a transmitter, as it determines the relevant destination server, and sends the message there.
The very format <recipient@domain> of email addresses implies there is an agreement between a recipient and the domain. It is assumed that such agreements cover any privacy concern.
External forwarding
The original destination rcpt@domain is replaced with rcpt@other-domain by the forwarding server. The new address is someone's personal data, and its owner deserves full access to it.
We call this external to distinguish it from role accounts, e.g. sales@domain and similar forwarding of messages within the same server or mail domain. While for internal forwarding we may assume adequate agreements between users and their mail domains, external organizations require their own agreements. We are not much interested in formal pieces of paper, but rather in the effective ability of users to control how their addresses are used.
Vanity domains' email addresses solely exist for forwarding. In most such cases, they feature full blown web applications that allow users to control their addresses. However, simple .forward files do not. (In a classical setting, .forward files live in users' home directories, and hence are under their complete control. Most current mail servers, however, work with virtual users, an arrangement that allows better management and is safer for server's security. Access to .forward files is an oversight originating from the fact that the fundamental principle, that email addresses shall be under the complete control of their owners, although respected, was never made explicit in SMTP.) They are part of the recommended procedure for changing email address, which may well be considered a necessary part of the mail system.
Newsletters and announcements
Newsletters are the long established case where privacy rules get broken. Technically, they are the same as mailing lists. However, the semantics is very different. Most mailing list are very respectful of privacy: they require explicit user's subscription, which is double checked so that it is really difficult to subscribe someone else, and they regularly send unsubscribe instructions. Newsletters and single announcements are a means for advertising something, and only in a few cases they collect subscriptions regularly.
Authors submit the message to the list exploder for list@domain. That is, they don't manually type addresses, nor select them from public directories, for each message they send. Rather, they maintain a database from which destination addresses can be extracted by the exploder using convenient criteria. Users shall be able to access the data records that concern them. However, seeking users' confirmation by sending them an email message upon insertion is grotesque, since message-sending is not yet confirmed.
Senders' requirement is to build those databases. In several cases, sending organizations lack the prestige, fame, and reputation for enticing users to subscribe spontaneously, and thus collect addresses in various ways. We are not much interested in how addresses are collected. However, there is a precise moment when an address is made available to an exploder, with given extraction criteria, a.k.a. profiles. An agreement with the subject must be sought after that moment, and before any message that matches those criteria is actually sent. Thus, automating this kind of agreement is apparently the kind of solution we seek. (Users might configure their preferences, on their mail servers, specifying what they wish to do for a forwarding agreement proposal that makes their mailbox the target of a given message or series of messages. For example, they might specify, for any category of message, whether they wish to automatically deny or accept the agreement, and how they'd like to be notified of this fact. Categories of messages might be defined by means of Solicitation-keywords, as defined in RFC 3865.)
External backup MX
It used to be rather common to have external backup MXes. These were machines configured to accept mail for a different domain, without being able to state the validity of its addresses. They should only be used when the main (or primary) server experiences a network outage.
Nowadays, organizations that operate on a single network have given up using backup MXes. Until networks work reliably, they are not needed. Old-style backup MXes accept messages destined to non-existent@domain, and attempt to send them to the main server, with embarrassing behavior about delivery status notifications. Larger organizations distribute their users' data so that any server can determine whether a mailbox exists. If they are distributed evenly around the globe, their mail systems may work even in case solar flares tamper with telecommunications.
Backup MXes operated by 3rd parties pose a problem that has a common facet with that of newsletters. Assume a backup MX has been fed with a hashed list of addresses; that is, it can compute a one-way hash of any address so as to determine whether it is listed. Since addresses are hidden, such feed doesn't require special interaction with each subject, although proper notification is appropriate. When the backup MX learns of the existence of one of those addresses --after a positive lookup-- it moves it from the hashed list and makes it available on a cleartext one: on performing such operation, it is in the same condition of a newsletter exploder acquiring a new address, therefore it can solve the problem by the same means.
Conclusions
Getting into an agreement would not be a tough procedure if there is a standard way to automate it. The solution proposed provides for procedures to automatically negotiate agreements, and manage the required passwords for SMTP Authentication. As a result, MX servers will have lists of effective agreements, that they can put in the hands of the corresponding subjects.
