Water tight opt-in

From FixForwarding
Jump to navigationJump to search

Water tight opt-in is an opt-in that involves three parties —sender, receiver, and recipient. It uses disposable addresses (a.k.a. tagged addresses) and web forms.

Definitions:

  • The recipient is the person who is subscribing to a given list,
  • the receiver is her mailbox provider,
  • the sender is the list manager, which also manages, directly or indirectly, the web form through which the recipient's address is collected.

Difference w.r.t. usual Confirmed Opt-In (COI)

  • The recipient delegates to the receiver part of subscription management. This explicitly allows the receiver to learn the details of the recipient's subscriptions (thanks to Richard Clayton for this note.)
  • The recipient is authenticated by the receiver when she states her will to subscribe. Details of the subscription, such as how long it should last for and whether to use a newly created disposable address, have configurable default values which can be changed during the subscription process.
  • The sender has a chance to skip COI, since the recipient statement suffices. The sender can collect a digital copy of such statement, signed by the mailbox provider.
  • The receiver maintains a database of the recipient's subscriptions, whereby she can manage them.

How does it work

The recipient interacts with the receiver via another web form, or via a browser add-on. A cooperating sender prepares its web form so as to ease the subscription process; for example, the sender's web form can include a special javascript function that brings up the receiver's web form after the recipient fills in the domain name —that is, an email address without an at-sign (@). If the domain does not support water tight opt-in, the function will ask the recipient to enter the local part of her address as well.

For non-cooperating senders, the recipient has to invoke the receiver's web form by herself. This task can be eased by an add-on, as described below.

Never type an email address in a web form any more

Logging in on the receiver's web form should make use of form autofill features, unless the recipient uses someone else's browser. Classical mailing lists use a mail-based subscription mechanism (otherwise see below.)

By the same rationale that users have been advised not to publish an email address in a web page, users have to be advised neither to type their address into one. Indeed, there is not much difference, except that regular web pages need to wait for a spammer to harvest the addresses written therein, while many web forms are directly connected to the spammer's processor.

Note: We mean no disrespect by using the term spammer. Bulk email is here and won't go away, whereas unsolicited has such a subtle meaning that it can often be applied to whatever message, irrespectively of it being wanted or not, useful or not, necessary or not. There are unlawful, criminal spammers, but there are legitimate, honest ones. Marketer may be a more formal term for the latter ones.

Well known service

Through this service, a client can learn how to have a confirmation form presented to a user. The confirmation form would behave like a Paypal login-and-pay form. The user logs in and confirms subscription to a given mail stream.

The mail stream provided by the wannabe sender can be characterized by several items, such as:

  • expiration date,
  • domain where the mail stream originates from,
  • List-Id, possibly matching the domain, DKIM-signed.

The user can tweak the expiration date and specify further details, such as:

  • max number of messages that will be accepted,
  • IMAP folder where mail from that stream will be delivered,
  • concealed local part that will return a disposable address to the wannabe sender.

The user's mailbox provider would return a subscription request to the sender, unless the user cancels the operation. The request shall be digitally signed, and can thus be exhibited to an ESP or to a court. (DKIM is not much useful for signing requests that way, because its key may suddenly expire.)

One-sided implementations

A mailbox provider can develop (part of) the required functionality as an interface for creating disposable email addresses. A sort of protocol for doing so is used by TrashMail, who also distribute a FireFox add-on and a PHP script. It currently features the following fields:

  • Creation date of the entry,
  • disposable address returned to the sender,
  • destination address or folder,
  • description by the tool that created the entry,
  • number of messages remaining,
  • expiration date,
  • HTTP address of the page that contained the subscription form, and
  • whitelisting options.

For that to evolve into cooperative functionality, there needs to be a relationship between the submission form and the List-Id or similar identifier of the mail stream.

On the other hand, a marketer would probably not develop any kind of stuff without some minimal support from some relevant number of receivers. It seems more likely that mailbox providers have to be the first mover.

Caveats

Care must be taken to implement a foolproof system. At a first glance, it might make sense to use an email address that expires after a month for a one-off purpose from a web store. Except that sometimes the customer might like the purchase so much, they decide to buy more stuff, only to find out the order confirmation emails stop arriving. Or the store might have a good reason to contact the consumer - a data breach, a fault discovered in the product - and the emails fail to arrive. (Thanks to Martijn Grooten for this hint.)

Implementation

Patents

Channelized addresses were described by Robert J. Hall, who filed patent US 5930479 on October 21, 1996.

Discussion lists

Discussion lists that present a web interface should perhaps discourage subscribers from using an anonymous disposable address, because that address will be made known to all other subscribed users, who may reply privately and store it in their address books.

Discussion

This particular subject was discussed in the following lists (in reverse chronological order):

Retrieved from "http://fixforwarding.org/w/index.php?title=Water_tight_opt-in&oldid=1593"