ietf-clear
[Top] [All Lists]

[ietf-clear] Getting CSV ready for prime time

2004-12-01 17:43:07
I agree with John Leslie:
This functionality is not important or very useful.
I think folks who think it will help a lot haven't thought it through. 
It would not significantly help stop spam, except that it would slightly 
help early adopters of checking, and soon after become a useless waste 
of effort*.   I would not be strongly opposed to an additional draft in 
CSV that specifies checks for such a bit be made optional up to a sunset 
date, and forbidden after that date.  Unlike publishers of -all SPF 
records, publishers of the record in question don't defend themselves 
from backscatter by publishing, and don't defend their reputations.

Using the port field for this new bit sounds fine.  I also support 
handcuffing Otis and Leslie together until they agree on whether the bit 
being 0 (the default) or 1 means subdomains must publish.  If we can't 
get them to agree, my second choice is to waste bits: a value of 1 
represent subdomains must publish and a value of 2 represent subdomains 
may publish. (
xxxxxx01 = subdomains must publish
xxxxxx10 = subdomains may publish
)

On 12/1/2004 9:27 AM, John Leslie sent forth electrons to convey:

John R Levine <johnl(_at_)iecc(_dot_)com> wrote:
 

One thing that became blindingly clear is that if we want people to take
CSV seriously, we need some hack to say that the rest of a domain doesn't
have any mail clients.  That lets domains mark big swaths of their name
space as bad, which would be a significant reason for people to start
looking for CSV records even when there aren't a whole lot of them to
find.
   


  While I am sympathetic to the desire to mark whole domains as never
operating sending SMTP clients, there is a fundamental misunderstanding
here: CSV is about documenting authentication and authorization, not
about preventing email abuse.

  We SHOULD be very careful to not give the impression that CSV will
prevent abusive forgery of domains in EHLO strings. 

TRUE, BUT: CSV *will* 
  prevent abusive forgery of domains *with good reputations* in EHLO. 

We _cannot_ deliver
on such a promise -- no matter what CSV specs may say, nobody will be
forced to abide by the spec.

 


*  IMHO, spammers will learn to avoid the relatively few EHLO strings
which domains bother to publish "not-authorized" SRV records for; and
in the "stable" state we hope to reach in a few years, less than 1% of
CSV checks will result in such a "not-authorized" result.

Once that happens, the checks will be a useless waste, hence the sunset 
date.

[CSV just] needs targeted marketing to
folks that write MTA software.

Yes! (assuming you call SpamAssassin MTA software)
That's the audience I have had in mind for
http://wiki.fastmail.fm/wiki/index.php/ClientSmtpValidation.