solution proposed

The solution proposed by this site aims at fixing email forwarding by introducing forwarding agreements as a counterpart of forwarding recipes.

Requirements

Agreements are classified into different categories, e.g., static dot-forward files, newsletters, mailing lists. An agreement is required for each target user and for each subscription. For example, if sender A runs one mailing list and two newsletters, and two users at receiver B subscribe to all of them, then B will store six agreements for A, just like A has six recipes for B.

Agreements may be obtained in a fully automated fashion. That means that a compliant sender can find out whether the target MTA supports this solution and automatically convert a to it in case. However, it must also be possible to require human inspection as desired.

Agreements may be renegotiated by the end user at any time. Renegotiation and queries by users are always fully automatic and (where applicable) recursive. Agreement negotiation may include arrangements and settings for DNSBL lookups, SPF checks, feedback loops.

This model of forwarding can be triggered by means of a local tweak and a light SMTP extension. The tweak on the sender side consists of a local encoding of the envelope sender that lets the sending software know that a message is being forwarded, and provides a parameter for either negotiating an agreement or using an existing one. This has to be enabled by setting the -f command switch accordingly, for each recipe. The tweaked envelope sender only lives locally, i.e. on the relevant host or ADMD. The extension on the receiver side is an EHLO keyword to let the sending software know that the specific MX being contacted is also willing to use forwarding agreements.

The negotiation required to establish a forwarding agreement could be quite demanding, especially for the first agreement between two organizations.

Verification

Here are two methods to verify that a message is being forwarded legitimately by a compliant sender.

DKIM / SPF authentication plus unique addresses

• The server generates a unique opaque email address, e.g. user-12345@domain, that is given to that sender only, and
• the sender authenticates with DKIM and/or SPF, referring which agreement it is using either in the envelope (as a new SMTP parameter) or in the message (in a header field such as List-Id).

Using Base32 encoding for the variant part allows for enough addresses to connect each pair of individuals in the world, since the local-part can be up to 64 chars long.

The sender has to be trusted for referencing the correct agreement.

SMPT AUTH

By negotiating a forwarding agreement, a sender obtains an SMTP AUTH id/password pair that it can use to relay messages destined to a given user on the relevant server. The receiver maintains a list of agreements, matching one-to-one with the corresponding elements at the senders' alias expansion lists.

An MTA has to be able to not grant relaying rights to this kind of authenticated senders, while still using authentication (in Submission servers) as usual for local users.

SMTP AUTH allows senders to change hat for each message being sent during a given session. This has to be implemented by the receiving MTA, so that the same entity can act upon different agreements at the same server. Again, the sender has to be trusted for this.

Pluses

This solution attempts to impose some order in the real and extensive diversity of email transfer scenarios, as Dave Crocker describes it[1].

Anti-Spam effects

The major effect of this solution against spam consists in enabling boundary filters. Some of those filters, in turn, don't aim at countering spam directly. SPF, for example, provides for anti-forgery, with the idea that forcing spammers to use their real domain names would confront them with their responsibilities.

A second effect is to improve legal stances. The usual definition of spam, "unsolicited bulk email", does not distinguish spammers who use false identities and zombies, thereby breaking criminal laws, from those who don't respect opt-in rules or similar civil law issues. For the latter, forwarding agreements constitute a means to verify opt-ins, thereby providing a further incentive for legitimate bulk mailers to behave correctly.

Unified unsubscribe

The data gathered with each agreement can be easily made available to UIs aiming at enumerating users subscriptions, possibly recursively. Agreements can be presented in historical order and/or by category, allowing users to change preferences and unsubscribe.

Rather than hitting "report spam" buttons on a per-message basis, users could target the whole series of messages that arrived under a given agreement. Such semantic shift may help to disambiguate an attempt to report that a single message is spam, not the newsletter it belongs to.

Minuses

Managing agreements is an additional burden. Are we ready?

False security

Automatically stipulated agreements are not bullet proof. Questionable senders may sneak in and send messages that formally look like having passed through SMTP AUTH. Although it may actually be easier for a server to monitor messages grouping them by forwarder-id rather than (or in addition to) IP address, downstream software may erroneously assume that Received or Authentication-Results headers exhibiting smpt.auth data imply a well identified sender.

Easy attack path

Since receiving hosts promise to skip some boundary checks for forwarded messages, spammers may just use a zombie and an easily obtained TLS certificate to stipulate forwarding agreements. Then they can send spam more easily to those hosts. If it is too easy to obtain an agreement, this solution won't work. However, it is possible to invest more time and precautions during the negotiation handshake than it would for single messages: that's the challenge hereby proposed.

History

The ff idea arose in a discussion originated on the spf-discuss list in January 2008[2]. In the same period, a wishful attempt has also been made to describe it within a single message on the ASRG[3] and Courier-users[4] mailing lists, where it just originated more or less (respectively) responses on SPF/SRS topics only. The idea itself is not very complicated, but it has to be described gradually. Thus this site born.