spf-discuss
[Top] [All Lists]

Re: Wayne's thoughts from the IETF Meeting

2004-05-21 17:10:27
On Fri, May 21, 2004 at 01:47:01PM -0700, wayne wrote:
| 
| Meng asked a question along the lines of "would anyone object to
| getting rid of SRS if we could find a better way?"  I know of no one
| that likes SRS.  It is ugly.  Who would say no?  The problem is that I
| think the FRED STMP parameter (aka the RFROM), is no where near as
| workable and have strong doubts that it is a better way.
| 
| Meng also has publicly committed to MicroSoft and the IETF to drop
| RFC2821 MAIL FROM checking in favor of RFC2822 From: header checking.

I wouldn't quite say "drop".

On Tuesday, when I was sitting in a room with four Microsoft guys, all
these consequences did occur to me.  Everything that made you queasy
also made me queasy.  I spent a lot of time thinking about the
tradeoffs.  Besides, I couldn't do much else, since I was strapped to
a chair in the dark with toothpicks holding my eyelids open.

The queasiness was why I insisted that after the flag day, if an RFROM
is absent, the FROM will be used instead.  This gives back all the
strength of the original SPF concept.

In fact, it is even stronger than the original SPF concept.  Let me
put on my MBA / strategy hat for a moment and explain.

Under the Old SPF, where we require forwarders to do SRS,
I observe the following scenario:

  A fair number of large companies may be hesitant to use
  "-all" in their SPF record because they are worried about
  the forwarding problem.

  Until a majority of forwarders are doing the right thing,
  large companies will worry about false positives and use
  "?all".

  Until a majority of large companies are doing "-all",
  forwarders won't feel any heat and will not bother with SRS.

I do not want to entrench this situation.  It is a tough
chicken-and-egg problem to solve.  It basically has to be
solved by fiat, and you are guaranteed to get a lot of
resistance.

Under the New SPF, we also require forwarders to change, but
what we ask from them is significantly reduced.  I assert
without proof that SRS is a bigger burden than prepending a
Resent-Sender header and adding RFROM support.  If we ask
forwarders to do RFROM, we have a fighting chance to get
them to do it.

Now, under the New SPF, what we're telling people is: we're
temporarily taking away the "bounce based on 2821" semantic.
This allows publishers to go forward with "-all".  The RFROM
stuff is much more specific and is less prone to the
forwarding false positive problem.

Another key difference is that if we can get the industry
behind The New SPF, that lets us, with authority, define the
flag day by which forwarders MUST be prepending
Resent-Sender and doing the RFROM thing.

Once that flag day comes, we get to restore the original
"bounce based on 2821" rule.

And then the queasiness goes away.

So we end up in the same place both ways: we can reject
based on 2821 MAIL FROM alone.  But the way to get there
with RFROM is smoother than the way with SRS.

That is why I think the convergence is a worthwhile effort.

That, and the toothpicks.




<Prev in Thread] Current Thread [Next in Thread>