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
   /
 Border

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
6) 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
     http://trusted-forwarder.org/
2) Motivate Forwarders to use SRS
     http://www.openspf.org/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>
        AUTH=list@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.

Advantages and Disadvantages of Possible Solutions
1) Someone must maintain the list of Trusted Forwarders.
2) Forwarders have been reluctant to modify their software so as to implement an address re-writing scheme such as SRS.