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. We _cannot_ deliver
on such a promise -- no matter what CSV specs may say, nobody will be
forced to abide by the spec.
I sometimes feel like a voice crying in the wilderness; but I will
continue to cry out whenever I see attempts to load more baggage on the
CSV wagon: CSV is a "Compatible" "Low-Level" "Email" "Authentication"
tool to document "Responsibility". (Check out the charter if you don't
recognize the quoted words.
I do _not_ believe CSV should be turned into more than that; and I
especially don't believe this proto-WG should be the place to do it.
I realize that DNS wildcards are broken and all the alternatives stink,
but given that we're competing with the stupendous awfulness of SPF, it's
not hard to do better than that.
Agreed. (And I think we can get there without violence to C.L.E.A.R.)
So here's my modest proposal to mutate CSV to do not too awful wildcard
like function:
1) Before (or perhaps in parallel with) the SRV lookup, do an A lookup on
the HELO name.
An implementation detail. I'll get to it later.
2) In the weight field of the SRV record, define the 4 bit to mean that
all mail clients in subdomains of this one have explicit records.
I believe John Levine means the bit-value 4. I concur with that.
The important thing here is to define the meaning of this bit. I
don't believe we _can_ enforce a particular algorithm to test for this;
nor do I believe we should. (However, if time permits, I'll get to what
I believe we _could_ do without violence to C.L.E.A.R.)
So this means that the revised CSA procedure is:
<snip>
The algorithm John Levine proposes, though "better than SPF" is
still more than we _can_ (IMHO) expect receiving SMTP servers to do
for every email.
The point of the A lookup is to prevent DDOS by sending a HELO like
a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.example.com
to force a blizzard of lookups. The A check means that the number of
lookups will never be more than the depth of an actual host, and we all
know that in practice the domain tree is pretty flat.
The disadvantage of the A lookup, beyond the theological issue that RFC
2821 says not to verify the HELO name for reasons that I think have long
faded into irrelevance, is that it forces the HELO namespace to match the
real namespace. There's a few domains, notably hotmail.com, where all the
mail clients HELO as the domain rather than as the actual host name. The
current scheme lets this work by allowing the name in the SRV record be
different, e.g. mailclient.hotmail.com. Validating the HELO name would
force Hotmail clients to HELO as their actual names which wouldn't be very
hard and would be more in the spirit of 2821, but would be a change from
what they do now.
John Levine makes my case better than I could myself. There is no good
reason to require this particular query for A records.
Again, I don't feel all that strongly about the A lookup; the very long
name is an exotic attack, and a DNS cache that caches negative replies
properly shouldn't have too much trouble with it. But I do feel strongly
that we need some way to say "you can ignore the other million hosts in
this domain."
I'm really out of time, so I'll just hint at my proposal.
There's no reason why this particular bit should change very often:
thus it could more appropriately be queried by a proxy service, say,
once a week, and a database distributed which receiving SMTP servers
could query without creating DNS traffic on the 'net.
====
No more time right now: I'll be happy to take questions when I get
back...
--
John Leslie <john(_at_)jlc(_dot_)net>