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 precondition for commercial strength in the wp:Information Age.
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 betraying 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.
There is an EU regulation, wp:eIDAS, a standard developed for transactions in the EU single market. It can be considered a sort of S/MIME extension; that is, it features centralized key management -the main difference w.r.t. the PGP suite. That way, data subject's consent could by acquired by means of a trust service provider according to regulation. A statement like this would be consistent with law-regulated privacy protection.
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 would be 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.
The main reason why that kind of authentication won't come is that it implies a trust between users and their mailbox providers. Such trust may seem to be taken for granted, considering, for example, that forgotten passwords are reset through email. A person's email address has become an identity token. Yet, there are users who hardly cope with having to entrust their communications to a third party suspected of sniffing it, profiling and reselling private data, and worse. Things would be different if the mailbox provider were the server of a household, of a company, a club, or similar associations. In fact, the 'domain-part' of an address used to characterize people. Nowadays, everyone has 'gmail'. There are two reasons for this state of affairs. One is that running a mail server is not so straightforward. The other one is that server connections cost much more than residential ones. Having to put the server at the mercy of an external admin doesn't seem to be much different than letting the external admin manage the mail directly, as far as privacy is concerned.
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.
The new REGULATION 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016, article 68, states (my enhancing):
To further strengthen the control over his or her own data, where the processing of personal data is carried out by automated means, the data subject should also be allowed to receive personal data concerning him or her which he or she has provided to a controller in a structured, commonly used, machine-readable and interoperable format, and to transmit it to another controller. Data controllers should be encouraged to develop interoperable formats that enable data portability. That right should apply where the data subject provided the personal data on the basis of his or her consent or the processing is necessary for the performance of a contract. It should not apply where processing is based on a legal ground other than consent or contract. By its very nature, that right should not be exercised against controllers processing personal data in the exercise of their public duties. It should therefore not apply where the processing of the personal data is necessary for compliance with a legal obligation to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of an official authority vested in the controller. The data subject's right to transmit or receive personal data concerning him or her should not create an obligation for the controllers to adopt or maintain processing systems which are technically compatible. Where, in a certain set of personal data, more than one data subject is concerned, the right to receive the personal data should be without prejudice to the rights and freedoms of other data subjects in accordance with this Regulation. Furthermore, that right should not prejudice the right of the data subject to obtain the erasure of personal data and the limitations of that right as set out in this Regulation and should, in particular, not imply the erasure of personal data concerning the data subject which have been provided by him or her for the performance of a contract to the extent that and for as long as the personal data are necessary for the performance of that contract. Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.
Besides all the limitations intended to safeguard data controllers, it clearly calls for such a standard.
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>._mayresign.ietf.org TXT "v=MR1; d=ietf.org"
That says the ietf-822 at ietf.org list is signed with d=ietf.org. If a domain contains only mailing lists, you can use a wildcard
*._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"
A submission server can then derive that one of its users is a subscriber of a list declared that way.
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.