User:David MacQuigg/Reverse MX

See also: Email authentication for a general overview and terminology.

Reverse MX (RMX) is an email authentication method developed by Hadmut Danisch. It became a basis for the two most commonly used methods, Sender Policy Framework and Sender ID. Like SPF, RMX uses the source IP address in a TCP connection to verify the domain name in the envelope Return Address with every message. The most significant change introduced by SPF was the use of plain text DNS records widely supported by DNS servers all over the world. RMX depended on implementation and worldwide deployment of a new binary record type.

---

The domain in the Return Address is verified by doing a DNS query for an SPF record under the domain name. If the IP address is listed in that record, the result is Pass. Thus SPF security depends on the security of Internet IP addresses and of the Domain Name System.

SPF prevents the "replay" abuse possible with signature methods like DKIM, because the verified domain owner can be held responsible for high-volume replication of a message.

Limitations

RMX has the same limitations as SPF with regard to the Forwarding problem. In addition, it requires a special binary record, as noted above.

---

SPF seeks 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 related to the originator's domain name. An SPF check by the MDA will likely fail.

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

The first solution to this problem was 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 example below.) 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. When a Recipient sets up forwarding from his old Receiver/Forwarder to his new MDA, he should make sure that the Forwarder is whitelisted by the MDA. Forwarders should make sure that Recipients (non-expert users) understand this. MDAs should understand that forwarding is a common need, and make it easy for Recipients to whitelist their Forwarders.

Unfortunately, the confusion over forwarding 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.

How it works

This is a brief explanation of an authentication using an SPF record with just a few of the more common terms. See RFC-4408 for the other terms and full details of SPF.

Senders that wish to use SPF should publish a TXT record and an identical SPF record under their domain name in DNS. Typical DNS records might look like:

example.com.  1800  IN  TXT  "v=spf1 ip4:192.168.33.32/28 mx a:colo.example.net ?all"
example.com.  1800  IN  SPF  "v=spf1 ip4:192.168.33.32/28 mx a:colo.example.net ?all"

These records authorize a number of IP addresses to transmit email for example.com. These addresses include a block of 16 starting at 192.168.33.32, plus any addresses found via the MX records for that same domain (i.e. the incoming mail servers), plus any addresses found in A records for the domain colo.example.net. The ?all term at the end means to treat all other addresses as "neutral", meaning the same as if no SPF records were published.

1) The sender (typically the Mail Submission Agent for example.com) checks the envelope return address to make sure the domain part is "example.com", then relays the message to the Transmitter.

  MAIL FROM:<[email protected]>

2) The Receiver extracts the domain part of the return address, and does a DNS query for the SPF record under that domain.

3) The terms in the SPF record are tested one at a time, left to right, and the first definite result (pass or fail) is accepted. The prefixes (+, -, ?) mean (pass, fail, neutral), with + being the default.

4) The Receiver adds an authentication header to the message:

  Received-SPF: Pass (mx1.example.org: domain of
   [email protected] designates 192.168.33.35 as permitted sender)
      receiver=mx1.example.org; client-ip=192.168.33.35;
      envelope-from=<[email protected]>; helo=foo.example.com;

5) If the message is forwarded. the forwarder is expected to rewrite the envelope return address so that an SPF check won't fail when the message is forwarded to the next agent. This is done using a related protocol, the Sender Rewriting Scheme (SRS). In this scheme, the forwarder's domain name is substituted for the domain part of the original, and the local part is a concatenation of various strings joined with = characters. These strings include authentication codes and the original return address.

 original:   MAIL FROM:<[email protected]>
 rewritten:  MAIL FROM:<[email protected]>