Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
On Mon, 11 Oct 2004, John Leslie wrote:
Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
Another way of dealing with type 2 abuse is to block port 25 outgoing, but
this is rather heavy-handed. CSA allows ISPs to define a default-deny
policy by installing negative records for all their dynamic hosts;
True. (For this purpose, a wildcard SRV record -- however ugly --
can work.)
No, a wildcard SRV record will not work, because wildcard records do not
apply to names that have any non-wildcard records...
I stand corrected: wildcard wouldn't work for what you describe. My bad.
Regardless, wildcard _is_ ugly; wildcard leads to great confusion; and
wildcard DNS should be avoided.
I'm having some difficulty understanding why anyone would want to go
to that much trouble. We're talking forgery here, and CSV is not
generally designed to combat forgery.
There are two reasons:
(1) About 10% of email is being sent by malware that lies in the EHLO
command in a trivially detectable manner. Using CSA to stop this would be
immediately valuable.
To whatever extent CSA stopped this, spammers would change.
(2) There is a lot of money available to fund attacks against anti-spam
protection. If CSA becomes popular it will become a target, so it needs
to be secure against obvious future spoofing techniques.
I quite agree.
These include using made-up hostnames or hostnames without CSA records.
I don't understand why that's an attack worth securing against. Simply,
the single UDP DNS query is made, and returns NXDOMAIN. There is no danger
of misinterpreting this as CSV-authorized. At worst, we're no worse off
than before CSV.
I would hope that the reputation check recommended by CSV could report
that somejunk.dotat.at is covered by a directive from dotat.at to treat
subdomains without their own CSV record as "unauthorized". That's the
second UDP DNS query (or very likely a query to a database in memory);
and the "attack" fizzles right there.
The particular way that a reputation service finds that directive is
certainly open to discussion...
Absence of a CSA record implies to the recipient that the domain
concerned doesn't know about CSA,
This, IMHO, is the wrong assumption. The right assumption is that the
domain in question isn't making use of CSV's ability to bypass overly
broad blacklists -- possibly because the issue hasn't arisen yet, or
possibly because the management of the DNS zone doesn't trust it to.
According to the CSV intro, it's about vetting MTAs and getting an
accountable name to use so that blame (or praise) can be directed to the
right place. It does not suggest that whitelisting is more important than
blacklisting, and given that it's being proposed in the context of
anti-spam protocols it's reasonable to assume the opposite.
The CSV specs as released bear Dave Crocker's imprimateur; and Dave
disliked putting that kind of "suggestion" in RFCs. This WG can suggest
additions -- I would certainly support some...
That said, I agree that CSV is about vetting MTAs and getting an
accountable domain name; but I disagree that the prime intended use is
to find someone to blame. I believe there's already plentiful suggestion
that strong authorization allows bypassing blacklists which are based
on less-strong relationships.
Either way, the spec is what it is, and whatever strength it posesses
is based upon complete authentication and authorization, in common with
any available accreditation. Clearly, few domains will attempt all of
that for _every_ subdomain -- merely for the ones they care about enough
to go that extra distance.
If you want recipients to be able to check HELO domains strictly
when they refer to your organization you have to get really verbose
with CSA.
I suppose one could do that...
But again, I'm having difficulty understanding why one would bother.
So that made-up-name.cam.ac.uk or not-an-mta.cam.ac.uk don't turn up in
blacklists because they are routinely used by malware.
I must be missing something.
What harm is there if made-up-name.cam.ac.uk appears on a RHSBL?
You never intended it to send email in the first place. At worst, it
seems to me, it would save you the trouble of creating a SRV record
for it...
Receiving SMTP servers would be just-plain-wrong to treat CSA as
binary accept/deny. The spec (IMHO) is quite clear that you need the
authentication of IP address, the authorization bit in the SRV record,
and a favorable reputation report in order to bypass blacklisting; and
that there's a fairly large grey area where CSV says nothing about
accept _or_ deny.
OK it isn't binary, but it does allow you to reject with certainty a
lot of obviously criminal lying.
This is a side-effect. We shouldn't spend much time worrying about
what percentage of obviously criminal lying it catches.
But that's the _point_ of CSV -- enabling good email to be delivered.
That isn't clear from the spec, and I'd be surprised if people use it
that way.
I'll be very disappointed if they don't.
CSV is, as our charter asks, a low-level tool. It begs to be used as
the basis on which to build higher-level tools. We should not attempt
to make it into a one-size-fits-all tool.
I expect that people will use CSA to help with rejecting junk at SMTP
time, and they'll use the rest of CSV to contribute to spam scoring.
All of which is certainly appropriate.
But, IMHO, to whatever extent it's effective at rejecting junk at
SMTP time, the spammers will adjust. I don't want to be constantly
diddling with CSV to try to keep ahead of spammers: I want to let
other build higher-level tools which use CSV information to help them
try to keep ahead of spammers.
--
John Leslie <john(_at_)jlc(_dot_)net>