Terminology for discussion of forwarding problems                                     Draft 15-Feb-08

See MHSmodel for diagrams of typical Mail Handling Systems and terminology used to describe them.  The model we will assume for this discussion has the following diagram. All Agents on the Recipient's side of the Border are related, at least indirectly, via direct relationships with the Recipient. i.e. the Recipient initiated all forwarding arrangements.

          |------------ Recipient's Network ------------|
--> / --> Receiver ~~> Forwarder(s) ~~> MDA ==> Recipient

Statement of Forwarding Problems
Here is a paraphrase of Michael Deutschmann's original definitions:  See the thread "Statement of Forwarding Problem" in [spf-discuss] 1/24/08.

Problem S - To technologies like SPF, messages forwarded without re-writing the Return Address appear to be forgeries.

Problem K - Forwarders will accumulate "bad karma" when they innocently pass on spam to a downstream Agent without prior arrangement, or with arrangements that are mistakenly ignored.

Problem B - Mail may be lost when a Receiver accepts a message without authenticating the Return Address and a downstream Agent rejects it.

Related problems:

Problem P - Recipients have difficulty keeping track of and updating their forwarding arrangements.

Problem R - The reliability of the global email system is so bad that users cannot be confident of delivery unless there is prior arrangement between Agents at the Border of the sending and receiving networks.

Requirements for Solution to Forwarding Problems
1) No cost or risk to Agents on Sender's side
2) Small cost or risk to Agents on Recipient's side
3) No lost mail
4) Effective
5) Minimum vulnerability to new attacks
At every stage of adoption, benefits must exceed costs to each Agent
   that must take some action.
7) Forwarder authentication must be resolved before the DATA command.

List of possible Solutions
1) Use list of trusted forwarders
2) Motivate Forwarders to use SRS
3) Extension to SMTP Protocol
 a) Submitter: http://tools.ietf.org/html/rfc4405
 b) SWK: ftp://ftp.ocis.net/pub/users/ldeutsch/beta/swkspf-0.0.txt
4) BCP for Forwarders and Downstream Agents

Short Descriptions of Possible Solutions

1) Bypass SPF checks on Trusted Forwarders

2) Forwarder assumes the role of Transmitter by re-writing the Return Address.  Authentication can then be done using the Forwarder's SPF record.
   e.g. mail from <sender@example.com> is re-written to <sender=example.com@forwarder.com>. Bounces then come back to forwarder.com, and can be re-bounced to the original sender.  Authentication codes (not shown) are added to the re-written address to avoid forged bounce messages.
3a) This proposal seeks to solve problem S by having the Forwarder add to the Mail From command a parameter (SUBMITTER= ) providing a domain name that will pass an SID check, even when the original PRA address won't.

A typical mail session would start like:
      S: 220 almamater.edu.example ESMTP server ready
      C: EHLO example.com
      S: 250-almamater.edu.example
      S: 250-DSN
      S: 250-AUTH
      S: 250-SUBMITTER
      S: 250 SIZE
      C: MAIL FROM:<alice@example.com> SUBMITTER=alice@example.com
      S: 250 <alice@example.com> sender ok
      C: RCPT TO:<bob@almamater.edu.example>
      S: 250 <bob@almamater.edu.example> recipient ok

3b) This proposal seeks to solve problem S by having the Forwarder add to the Mail From command a parameter (AUTH= ) providing a domain name that will pass an SPF check, even when the original Return Address won't.

Typical Mail From commands would look like:
   C:MAIL FROM: <> AUTH=fred@example.org
   C:MAIL FROM: <list-owner-ralph=example.net@fourth.example>

The first example shows an empty Return Address, commonly used in bounce messages.  'fred@example.org' is the address to be whitelisted, and 'example.org' is authorized by an SPF record to use the Forwarder's IP address.

The second example shows a Return Address that has been mangled to redirect bounces.  The SWK parameter works regardless of what has been done to the Return Address.

4) A BCP (Best Current Practices) document could recommend the best way to handle Forwarding, assuming no change in current protocols.  Key elements of this BCP would be:
  a) Chain forwarding should be discouraged.  MDAs should not re-forward.
  b) Recipient should set up the forwarding at both ends.  No decisions to be made
     by the Forwarder or MDA.
  c) Process should be easy for Recipient, e.g. adding the Forwarder's domain to an
     individual whitelist.
  d) MDA and Recipient must not file any spam reports against a whitelisted
  e) Forwarder should immediately suspend forwarding to an account that has filed a
     spam report against the Forwarder.  This is clearly an error.
  f) Forwarder should promptly notify Recipient when anything goes wrong.

Advantages and Disadvantages of Possible Solutions
1) Someone must maintain the list of Trusted Forwarders, and decide who is allowed
   on the list.
2) Forwarders have been reluctant to modify their software so as to implement an
   address re-writing scheme such as SRS.
3) Changing an established protocol, even adding an extension will be very
   difficult.  Adoption may be near zero.
4) This seems to be the easiest of the alternatives.  The most difficult part will
   be getting services to allow individual whitelisting at the domain level.  Most
   already have this feature, but it may not be done correctly.  It must not be
   possible to forge the Forwarder's domain name.
                                                                                                                      Update 19-Dec-08

The fundamental problem with forwarding is that there is no effective relationship between the Forwarder and the MDA.  In our models, we show an indirect relationship, because both are related to the Recipient, but in reality, the parties may be unaware of this relationship.  The Recipient may have set it up by filling out a form, or creating a .forward file, but current practice is that niether party does anything special as a result.  The Forwarder follows the Recipient's instructions, but the MDA treats the forwarded mail the same as any other.  In effect, there are two Borders in the setup, and we can expect authentication methods based on the sender's original address to have difficulty.

One way to avoid this "two Border" problem is for the Forwarder and MDA to negotiate a "forwarding agreement".  Then, they will have a direct relationship, and the single Border model is restored.  Having a relationship allows the MDA to skip the normal authentication checks, and deliver the mail per the Recipient's instructions.

The problem is, how do we get Forwarders and MDAs to change their current practices?  There is very little motivation to install software or incur any expense.  See http://fixforwarding.org for fresh ideas on this topic and a proposal to automate the setup of forwarding agreements.