From FixForwarding, something can be done for the email
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
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.
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. 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
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.
External backup MX
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.
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.
- 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
- 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.