spf-discuss
[Top] [All Lists]

RE: Wayne's thoughts from the IETF Meeting

2004-05-21 18:52:33
From: Meng Weng Wong
Sent: Friday, May 21, 2004 7:10 PM


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".


<...>

...  Besides, I couldn't do much else, since I was strapped to
a chair in the dark with toothpicks holding my eyelids open.

I knew those MS guys were tough, but geez.


<...>

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

I guess I didn't put 2+2 together here, or it didn't add up to 3 like it
should.  I my addition has improved, this means that:

1) people who are not forwarding don't have to put in RFROM:, in fact, they
probably shouldn't.

2) This forces the SPF check to use MAIL FROM:, which at least validates the
return path at the first hop.

3) In this case the CID extraction of PRD would check for a match to MAIL
FROM:.

Now, if we could only preserve the result of the SPF/PRD confirmation of
MAIL FROM:, the final recipient could trust it, as well.  Of course, we
could always use SES with its stinking callback for that.


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.

The bad memories will eventually fade.

--

Seth Goodman


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