solution proposed
From FixForwarding, something can be done for the email
The solution proposed by this site aims at fixing email forwarding by introducing forwarding agreements as a counterpart of forwarding recipes.
Contents |
Summary
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.
Agreements are classified into different categories, e.g., static .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. However, it is also 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 can be quite complicate, especially for the first agreement between two organizations. It provides for a three-way handshake during which the servers exchange the relevant credentials and URLs required to re-negotiate the agreement. By contrast, normal use of an existing agreement is very cheap: the sender finds the id/password pair in a local database, and the remote MX authenticates it normally.
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.
![[Main Page]](/upload/fflogo.png)