spf-discuss
[Top] [All Lists]

Re: About 15 minutes ago at the FTC summit, Meng said SRS sucks

2004-11-11 08:25:16
In 
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0411102312470(_dot_)12512-100000(_at_)sokol(_dot_)elan(_dot_)net>
 "william(at)elan.net" <william(_at_)elan(_dot_)net> writes:

On Thu, 11 Nov 2004, wayne wrote:

In 
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0411102045350(_dot_)32295-100000(_at_)sokol(_dot_)elan(_dot_)net>
 "william(at)elan.net" <william(_at_)elan(_dot_)net> writes:

If I can convince them (which is not likely, but they have 0 deployment 
right now, so maybe they are little more open to more extendable format 
and its not a big change), then I think SES people and SRS really should  
change to fit into BATV framework so that all can co-exist together 
(right now that is not possible). 

Why should SES and SRS change just because Dave Crocker, et al
reinvented the wheel?

Reduces collisions for systems designed to "rewrite" enevelope mail from
address. SRS does not work well with SES either.

I guess it depends on what you mean by "work well".  Forwarder may be
able to skip doing SRS if they can correctly detect SES MAIL FROM's,
but forwarders that always do SRS don't break SES, in the sense that
checks will fail.

Domains that use stuff like ABBS/SES/BATV can avoid the problems with
excessivly long MAIL FROMs by internal policies.  Forwarders, on the
other hand, have to deal with long VERP MAIL FROMs in addition to
ABBS/SES/BATV, so they always have to be prepared to fall back to
using an opaque token instead of placing all info into the rewritten
MAIL FROM.

SRS can be used for the same purposes as ABBS/SES/BATV, but not vice
versa. 


I hate to say it, but no, I do not think that Doug Otis is "very very
good at [the] technical level."  *IF* any meaning can be extracted out
of his long incoherent rants, I think you will find that a great deal
of it is bogus.

No, his arguments are just difficult to sort through especially when he 
gets too heated in his pro-CSV agenda talk.

Again, I disagree.  Many, if not most, of his arguments are just plain
bogus and sound more valid than they are because of all the technical
BS he adds.


For example, his DNS poisoning stuff that he ranted about at the FTC
summit shows that he is missing really important things.  [...]

I've pointed that out too him. But he's correct that SPF documents
should mention the possibility of dns amplification DoS.

I happen to agree with Doug on this point and libspf2 has, from day
one, tried to address this.  I don't remember when I realized the
problems with MX and PTR, but I think that was before MARID started
also.

My libspf2 doc, draft-schlitt-spf-00, addresses this point.  I've done
the calculations and the amplification factor, even in the worst case,
is small and I don't think very useful to DDoS attacks.  Other SPF
specs, however, do have serious problems with this.


Of the things that are SPF related, I now agree with Doag that you can not
"hang" reputation system on SPF - its not precise enough because of having
to include all smart-hosts that can possibly be used by domain owner. 

I'm still not convinced of this.  If a domain authorizes an
untrustworthy MTA to use their domain name, they get what they deserve
and they can fix it if they want to.  But, as you point out, that
really isn't the goal of SPF.


-wayne