Re: Addressing Backward Compatibility [was Re: SPF PASS]

[email protected] wrote:

>----- Original Message -----
>From: "Carl Hutzler" <[email protected]>
>Sent: Thursday, May 26, 2005 11:39 AM
>Subject: Re: SPF PASS
>
>  
>
>>I wish there was a way to utilize the relatively large number of SPF
>>records in a technology like CSV.
>>
>>-Carl
>>    
>>
>
>The basic issue with all of this is not a specific methodology can work or
>not work, but rather the basic fact that none of it can be enforced.
>
>So even if all the kinks were solved in SPF, CSV, FUZZ, ABC or what have
>you,  SMTP developers, such as yourself, myself and others will still be
>stuck with still ACCEPTING the non-compliant senders and/or dealing with
>legacy issues.
>
>It doesn't make sense.   The only, and I mean only reason I implemented SPF
>was two reasons:
>
>1) AOL.COM announced support from a domain standpoint. AOL being one of the
>greatest sources of spam (spoofed or otherwise),  we need something from AOL
>to help all the other victim systems.  So once AOL.COM announce SPF support
>by publishing a SPF domain,  we immediately started to implement SPF, and
>guess what, the AOL announcement also made MICROSOFT jump and in my view,
>was the reason MARID eventually started
>
>2) SPF would be part of a suite of other methods, in particular ONE method
>that has no dependency with "new" information being available - this is the
>CBV, the call back verifier.
>
>The CBV is 100% based on the idea that "ok, we don't have much to go on, but
>at the VERY least,  from a SMTP BOUNCE compliancy standpoint,  the return
>path must be valid.  It may be spoofed, it may be a zombie, but it must be
>valid. It can not be junk."
>
>So we explored the CBV. I am not saying it is the "answer" but what it
>proved was one fundamental aspect of the problem we are trying to address:
>
>         That indeed, the majority, by atleast 60-80% of all transactions
>         are non-compliant from a SMTP standpoint.
>
>Period. No ands, ifs or butts. And it should not be a SURPRISE to anyone
>because it is the reason why we have the problem in the first place.
>
>So what's missing from the process?
>
>We need an anchor that exist today to address the backward compatibility
>issue.   We don't really have a consensus on what uniquely identifies a MAIL
>sender or machine that is part of a mail domain.
>
>So we can debate, argue left and right,  we are still left with the same old
>issue on how to address backward compatibility.
>
>Until someone can address this,  all the proposals are for the most part
>worthless.
>
>This is the secret the spammers don't want us to discover and realize,
>because until we do, they have no reason for them to change or adapt.
>
>SPF can work if everyone was forced to use SUBMITTER like idea to address
>the transitional domain/ip changes.
>
>CSV can work if everyone was forced to use reliable client domain name.
>
>etc, etc, but as long as it is not "REQUIRED"  or enforceable, it is all
>worthless.
>
>So Carl,  how can we enforce these proposals?  How do I enforce CSV support?
>
>No,  I am not encouraging "POLICY" discussions. I am talking about how can
>we automate the framework of a mixed hetergeneous network of systems?
>
>I have a few ideas.
>
>--
>Hector Santos, Santronics Software, Inc.
>http://www.santronics.com
>
>
>
>
>
>  
>
So if AOL began doing CSV, then everyone would follow? Hmmm, it might 
help, but not sure that's a given.

-- 
Carl Hutzler
Director, Host Mail Development
America Online
[email protected]
703.265.5521 work
703.915.6862 cell