Main Page
Email addresses are personal data that are notoriously subject to abuse. Research is underway to develop anti-spam techniques. Currently, the focus is on authentication, but little is done regarding authorization.
The idea of forwarding-specific authorizations arose from a discussion on the spf-discuss list in January 2008. How it had evolved since then can still be seen using the Wayback Machine. The current, simpler solution emerged around 2023, described in an IETF draft. This site remained behind the times until recently and is now slowly transitioning to the new spec.
Rationale
Both personal messaging and direct marketing would benefit from an unpolluted communication environment. Pollution results from insanely conceiving sales like a prey-predator relationship with customers. Production and distribution of goods and services should rather be a symbiotic relationship. The minority working against that ought to be pushed off. A responsible marketing is the precondition for commercial strength in the wp:Information Age.
The problem
There is an outstanding feature of sending bulk messages that characterizes email: the destination addresses can be 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.
wp:Email Authentication is typically baffled by indirect mail flows. SPF breaks forwarding by design. DKIM should withstand forwarding. However, occasional alterations or deliberate, legitimate additions break signatures as well. This state of affairs hinders the possibility to use domain authentication as a means to control email abuse. If it were not for forwarding, it would be possible to build reliable reputation systems. That way, authors would have to be responsible for what they send.
One possible mitigation is to associate email addresses stored in a list exploder with tags stored on the corresponding receivers, so that receivers can categorize indirect mail flows and allow their users to control them. Since forwarding requires specific setup anyway, it wouldn't be hard to keep track of these settings and use them to authorize forwarding.
The solution
The concept of an exploder is the same for mailing lists and spam campaigns. In both cases, the original message is replayed from an IP address not included in the domain's SPF record. The DKIM signature may fail to verify due to alterations made by mailing lists to the message (e.g., footer and subject tags) in one case, or it may be missing or broken by a faulty DKIM replay mechanism in the other.
In both cases, the sending domain can be authenticated one way or another. But who are they? We gallantly allow anyone on Earth to contact us without prior arrangement —this has been the flagship feature of email— but we may ask why an unknown contact like, say, John.Doe@gmail.com would send us his message from a server other than Google's? There are several ways to organize message forwarding from source to destination, but only one is fully automated: sending the message from the author's mail submission agent (MSA) to the recipient's mail exchange (MX). In other words, messages forwarded without prior arrangement don't pass through any third parties. So, why isn't authorization part of these arrangements?
Triple Opt-In
wp:Opt in email is the mail that users receive because they subscribed.
Confirmed opt-in (COI) —a.k.a. 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, as an integral part of the subscription process. This practice dates back to 1993, when Eric Thomas’s LISTSERV software added an address-verification / subscription confirmation feature (released March 15, 1993). It came years before privacy laws required the interested party's consent when sharing personal data.
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 requires a specific protocol intentionally conceived to allow the two involved servers to exchange the relevant data. This protocol is designed so as to fix forwarding in general; that is, not only bulk mail and lists, but also dot-forward files and backup MXes.
Criticism
One reason this kind of authentication might be unpopular is that it requires a relationship of trust between users and their mailbox providers. This trust may seem obvious, considering, for example, that forgotten passwords are reset via email. A person's email address has become an identity token. Yet, some users find it hard to bear having to entrust their communications to a third party suspected of intercepting them, 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 association. Indeed, the 'domain-part' of an address used to characterize people. Nowadays, everyone has 'gmail' or something. There are two reasons for this state of affairs. One is that running a mail server is not so simple. The other one is that server connections can cost much more than residential ones. Having to install your server on a server farm, at the mercy of an external admin, doesn't seem to be much different from letting the external admin manage your mail directly, as far as privacy is concerned.
An additional difficulty is that triple opt-in requires cooperation between senders and mailbox providers.
DNS declaration of Cooperative Mailbox Provider
To start experimenting this protocol, a mailbox provider notifies it to all interested parties by publishing an "underscored" DNS resource record named _fixforwarding. For example:
example.com._fixforwarding TXT "v=fixforwarding; post=https://www.example.com/.well-known/fixforwarding"
The DNS record contains all the information that a forwarder needs to know to request an authorization through a standardized web form. For example, a mailing list manager (MLM) can determine whether example.com can authorize it to forward messages. When a user subscribes with an address ending in @example.com, the MLM verifies that example.com is compliant by looking up the above record, and fills out the standardized web form at the specified URL. It can do this while sending the subscription confirmation request (opt-in) to the user, or it can omit that step, as example.com will still ask the user to confirm their subscription and notify the forwarder/ requester of the result.
What is a standardized web form?
The web form fields have standard names and requirements, so an MLM can set up a script that automatically sends an authorization request every time a user from a compliant mailbox provider signs up. However, it's also possible to fill out the form manually, either for initial testing or for small providers that don't have automatic email forwarding setup.
To be continued
...
