hsantos(_at_)santronics(_dot_)com wrote:
----- Original Message -----
From: "Carl Hutzler" <cdhutzler(_at_)aol(_dot_)com>
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
cdhutzler(_at_)aol(_dot_)com
703.265.5521 work
703.915.6862 cell