Email forwarding problem

From Citizendium
Revision as of 15:21, 23 October 2009 by David MacQuigg (Talk | contribs) (New page: {{subpages}} The '''email forwarding problem''' refers to the authentication failures that occur in some popular IP-based email authe...)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This article is developing and not approved.
Main Article
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
This editable Main Article is under development and subject to a disclaimer.

The email forwarding problem refers to the authentication failures that occur in some popular IP-based email authentication methods when a forwarder is involved. In this discussion, we will assume the reader understands the basics of Email authentication and the roles of different agents in the Email system, as illustrated in this diagram:

|--- Sender's Network ---|           |--------- Recipient's Network --------|
Author ==> MSA/Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
                    /         /        /
                   /       Border     /
                  /                  /
                  ------ DNS -------  

SPF, and its offshoot Sender ID, seek to authenticate the domain name of an originator, usually the MSA, with an IP address from the last agent in a chain of trust, usually the Transmitter. This works well because there is a close relationship between the MSA and the Transmitter. Often they are the same agent.

When a Forwarder is involved, however, the source IP address on the "last hop" to the MDA is no longer correlated to the originator's domain name. An SPF check by the MDA will likely fail.

The first solution to this problem was proposed by SPF, a campaign to get Forwarders to re-write the Return Address on forwarded messages, so that it would have the Forwarder's domain name. (See step 5 in the SPF "How it works" example.) This failed because Forwarders were not willing to install SRS software and take on responsibility for bounced messages. Also, it required changing a long-standing interpretation of the Return Address as being that of the original sender.

The current solution is to emphasize proper setup within the Recipient's network. SPF checks should be done only at the Border. Recipients should whitelist their Forwarders at their MDAs. Unfortunately, the confusion over this issue has persisted so long that it has led to the second big problem with SPF, the "chicken-and-egg" standoff.

Senders are unwilling to publish robust SPF records ending in "-all" due to the fear that their mail will be rejected by mis-configured forwarding setups. The common practice among nearly all domains publishing SPF records is to end them in ?all. This says to treat all other IP addresses not as Fail, but Neutral. This takes away the major motivation for Receivers to do SPF checks. Without large numbers of Receivers taking these records seriously, senders find that they can be sloppy with their SPF records, or not publish them at all, and it doesn't matter.