spf-discuss
[Top] [All Lists]

Re: The New SPF: introducing RFROM

2004-05-21 20:09:41
On Fri, May 21, 2004 at 02:03:47PM -0700, wayne wrote:
| 
| I am not at all convinced that it will be easier to get the FRED (aka
| RFROM) ESMTP extention adopted than it would be to get all email
| forwarders to do SRS (or similar.)
| 
| All forwarders will need to update their MTA software to support the
| RFROM extention.  That's fine, 'cause the alternative is for all of
| them to update their MTA software to support SRS.  We aren't giving
| mail forwarders a choice in either case.  They can't just say "I don't
| want to do Caller-ID/SPF so I don't want to upgrade my software."
| 
| However, with the FRED extention, we are requiring the receivers to
| also update their MTAs.  One claim I heard was that this was only
| needed if the receivers were doing Caller-ID/SPF, but that is not
| true.  SpamAssassin on your home machine will support SPF just fine,
| even if comcast/roadrunner don't change their MTAs.  This is going to
| require everyone with an MTA to upgrade.

On the face of it, that's true --- the Old SPF is trivially pluggable
because it only looks at existing SMTP thingies.  That is why you can
support SPF using a milter in Sendmail, using a policy daemon in
Postfix, using an ACL in Exim.  Because the New SPF talks about the
RFROM/FRED field which is an extension to SMTP itself, it seems to be
more work.  It's less clear how an SPF plugin would get ahold of the
RFROM.

But if you keep in mind that the 2822 selection algorithm remains
primary over the FRED field, SpamAssassin can still arrive at the
Purported Responsible Domain even if the MTA doesn't support RFROM.
Remember, the RFROM field is simply a sneak peek at the PRD anyway.
It is there to enable rejection before DATA.

Furthermore, I'm sure that as things evolve, MTA plugin architectures
will make it trivial for plugins to get access to arbitrary elements
of the SMTP transaction.  So plugins will be able to get all the MAIL
parameters, including RFROM.

So things are actually not that bad.  The RFROM extension remains
optional for receivers; it is only mandatory for forwarders AFTER the
flag day, and even then it is only mandatory for forwarders who do not
do SRS.

One could conclude that on a technical level the New SPF is actually
99% backward compatible with the Old SPF.  After the flag day, you get
just as much protection.  If a forwarder wants, it can continue to
just do SRS and ignore RFROM.  The only new requirement is that it
prepend a Resent-Sender header, which is really not that much work.
This tradeoff is worth it because it makes life easier for other
forwarders who don't want to do SRS: those guys can just prepend the
Resent-Sender and emit RFROM.

Does this make sense?