Sam Silberman <sam(_dot_)silberman(_at_)openwave(_dot_)com> wrote:
[John Levine 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.
I concur. It would be very useful (and popular) to blanket entire domains
with "not authorized to send".
Even if I don't concur with "useful", I do concur with "popular".
The administrative burden to set/maintain millions of negative SRV records
will inhibit (or prevent) significant deployment of CSV.
The _belief_ that this is necessary would be a worse inhibition. :^(
Seriously, we shouldn't let people think of CSV as an anti-spam
measure "like SPF only better". It isn't "like SPF"; and it isn't an
anti-spam measure.
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.
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.
Obviously, YMMV; and I don't want to participate in any flame-wars
about the exact numbers.
While I am not happy with traversing down or up the DNS tree, it's better
than the alternative: (failure to deploy CSV).
CSV is very much _unlike_ SPF, in that it's deployment does _not_
depend upon widespread publications of CSV records. It will yield obvious
benefits to both publishers and receivers with less than one domain per
thousand publishing. Publishers will be able to counteract IP-based
blacklists with domain-based whitelists; and can avoid futile arguments
with their bandwidth-providers trying to get IP space which has _never_
been blacklisted. Receivers will be able to pass email known to be both
authenticated and authorized directly to recipients and greatly reduce
their worries about false positives.
As to "failure to deploy CSV" -- that's probably much more a question
of getting a stable spec for email-software programmers to program into
their MTA packages. The most effective way to ensure that (IMHO) is to
freeze the spec and promise not to define any new bits for at least 12
months. Short of that, I think it'd be OK to define one or two new bits
but leave implementation of them as optional, which is what I proposed.
I may be an optimist to believe that 5% penetration of CSV-capable
MTA software to receiving SMTP servers would ensure its success; but
I'm quite certain that this is the measure we need to chase: not the
percentage of domains publishing CSV records.
--
John Leslie <john(_at_)jlc(_dot_)net>