ietf-clear
[Top] [All Lists]

[ietf-clear] Getting CSV ready for prime time

2004-12-01 13:26:23
Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
On Wed, 1 Dec 2004, John Leslie wrote:

CSV exists to document authentication and authorization so as to make
domain-based whitelists useful (and a few other side-effects). Marking
domains as "not-authorized" is a rather minor optimization, concerning
a field which will almost never be visible to the end-user.

I think you're missing a massive marketing opportunity by taking this
stance.

   Frankly, I'm not terribly interested in marketing opportunities. (I
voluntarily pass up perhaps 300 per day. ;^)

   I've tried to make myself clear that CSV doesn't need massive marketing
to folks that would publish CSV records: it needs targeted marketing to
folks that write MTA software.

   (BTW, I also believe we've already won some of the most important
mind-share by the FTC reaction in early November.)

If a site advertises CSV and checks it, it will immediately reduce
its spam load by about 10% because of the prevalence of HELO forgery.

   Umm... I really don't want to argue against that!...

   But we should be careful what we claim...

   CSV really _isn't_ about whether a HELO string is a forgery: it's
about whether the domain listed in the HELO string authorizes an
authenticated IP address to act as a SMTP client, and takes some
(loosely specified) responsibility for email it sends.

   As John Levine has pointed out, a "HELO xxx.yyy.aol.com" may be
perfectly correct (and thus clearly not a forgery), but still not
represent an MTA authorized by aol.com (or yyy.aol.com, etc.).

   I quite agree that EHLO forgery is a common problem today. JLC.net
takes measures against it. But CSV won't do much about it -- unless
and until a large percentage of domains advertise CSV records (which
may never happen). I have no plans to abandon our current EHLO checks
when CSV "succeeds".

Extending CSV to allow domains to impose a blanket ban on the use of
their subdomains in HELO would be an easy win.

   Only to the extent they do so. I don't want to start down the road
to making CSV success dependent upon SRV publishing.

On the other hand, Leslie-CSV isn't enough of a benefit over my existing
HELO heuristics to be worth making an effort to implement it before it
finds its way into SpamAssassin.

   Hmm...

   There's no way for anybody's "existing HELO heuristics" to document
the authentication and authorization in the CSV SRV record. I'm sure
you have better "HELO heuristics" than I do; but CSV is about matching
the EHLO string to information about authentication and authorization
which simply doesn't exist before CSV.

--
John Leslie <john(_at_)jlc(_dot_)net>