Main Page

From FixForwarding
Jump to: navigation, search

Email addresses are personal data notoriously being abused. There is an ongoing quest for anti-spam techniques. However, little effort is being done to verify compliant controllers, thereby leaving a wide "gray" area and putting email abuse down to a fuzzy concept.


Both personal messaging and direct marketing would benefit from an unpolluted communication environment. Pollution results from insanely conceiving sales like a prey-predator relationship. Production and distribution of goods and services is a cooperative effort, and the minority working against that ought to be pushed off. A responsible marketing is the premise for commercial strength in the wp:Information Age.

The problem

Sending messages to a list is one of the standard behaviors.
There is an outstanding feature of sending bulk email that characterizes it: the destination addresses are held on a list exploder. Rather than typing addresses, or retrieving them interactively from personal or public address books, the sender sends to a pseudo-mailbox that the list exploder uses to select addresses from a local database. Mailing lists, newsletters, and dot-forwards (the best surrogate of email address portability) all require that recipients' addresses be stored on a mail server's file system. In most countries, this should be controlled by law. In Europe, in particular, this is never done in compliance with the letter of Directive 95/46/EC. Mailing lists comply with the spirit of 95/46/EC, but then they were run in the same way even before 1995, when the Directive was issued.

Laws have the nasty habit of snubbing technology. Possibly, they do so in order to address many technologies at once, but the result is often the opposite, to miss all of them at the same time. Email is sometimes assimilated to telephone or fax calls, sometimes to traditional paper mail, at times even to newspaper publishing. Such ambiguous feeling sorts little practical effects, if any. In particular:

  • while data controllers are allowed to build databases of subjects, subjects are inequitably hindered from building databases of controllers,
  • mailing lists have no means to prove subscriptions,
  • newsletters don't allow recipients to directly control the forwarding mechanism,
  • illegal disclosure of email addresses cannot be detected,
  • responsibility for injecting spam remains ambiguous,
  • bounces from forwarders may reveal recipients' identities thereby dishonoring any anonymity concern that forwarding might have implied.

One of the downsides of wp:Data Protection Directive is the work required for collecting subjects' consent. For email use, paperwork-based procedures are rather unpractical and apparently clash with the rest of computer-based procedures. On the other hand, since spam is a major concern, email servers run a number of checks trying to ascertain the legitimacy of incoming mail; however, recipient's consent cannot be checked because the paperwork produced to comply with the law is not machine-readable.

Update: data subject's consent could by acquired by means of a trust service provider according to eIAS proposal and amendment thereof.

Triple Opt-In

wp:Opt in email is the mail that users receive because they subscribed.

Double opt-in is a technique to confirm subscriptions. The server tests a new user's email address right after getting it, requiring the user to confirm the reception of a unique token, as an integral part of the subscription process. That way the operator knows that email addresses are correct and belongs to the subscribers. List operators can set up double opt-in on their own, relying on the fact that human subscribers can follow simple instructions. However, malicious operators can easily build fake opt-in evidence.

Triple opt-in is a kind of confirmed opt-in that requires three parties —the user, the user's mail server, and the list server— to interact with one another in order to complete each subscription. Differently from double opt-in, triple opt-in would require a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data. This protocol can be designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.


A reason to avoid the term triple opt-in altogether is that it is being used with a different (marketing) meaning, see e.g. here.

An additional weakness is that a user's mail server can just be grateful for the information supplied, and decline to send a proper acknowledge to the wannabe sender. Since the sender is doing this in order to have such legal proof of its conduct, lazy mailbox provider behavior can hamper a naive implementation.

Let me name this Water tight opt-in, following David Hofstee.

A consent-exchange Internet protocol for email users

A software tool for putting users in control of their email address data, even if stored at remote servers, would be generally useful. It would supply users with automatically updated lists of subscriptions and redirections, and it would provide servers with yet another tool to dominate spam. This tool could gain interest if it also stipulates means to obtain proofs of consent with legal standing. It is necessary to involve the wp:Article 29 Working Party for this, because the current formulation of the Directive regards the transmission of data over a network as an unlawful form of processing.

The target is an Internet Standard that spells out how to keep proof that a data subject granted her/his consent for processing what data to which controller. The email address is the key part of the transmitted data, although some controllers also collect names, birth days, and similar details. It is safe to assume that data subjects trust their mail servers as far as this kind of data is concerned, and these servers are able to authenticate their users, therefore it is natural to identify mail servers as one of the actors in the consent exchange. The other actors are the controllers' computers and, in case of interactive exchanges, the data subjects through their PCs.

The expected advantages include

  • an automatically updated list of subscriptions and redirections,
  • actual possibility to erase or rectify the data in each entry,
  • easy verification of legitimate behavior,
  • catching some illegitimate disclosures of addresses,
  • better anti-spam filtering by whitelisting legitimate messages, and
  • enabling automation of abuse reporting.

DNS declaration of mailing list

Yet another idea is to use DNS RRs to declare that a given email address is a mailing list (suggested by John Levine here). It is exemplified as

 <hash of ietf-822> TXT "v=MR1;"

That says the ietf-822 at list is signed with If a domain contains only mailing lists, you can use a wildcard

 * TXT "v=MR1;"

A submission server can then derive that one of its users is a subscriber of a list declared that way.

Anti-spam effect

The majority of spam these days is utterly illegal just about everywhere, sent using stolen resources advertising fraudulent stuff. The triple opt-in protocol outlined here can only control legal spam. However, it is not straightforward to tell legal and illegal spam apart, currently. A consent-exchange protocol paired with a buddy list could almost do it, thereby allowing automated anti-spam action.