I think we mostly agree, though there's a difference of emphasis.
On Mon, 11 Oct 2004, John Leslie wrote:
Tony Finch <dot(_at_)dotat(_dot_)at> wrote:
There are currently two common kinds of EHLO domain misuse which CSA
could fix:
(1) The malware sends EHLO domain ... RCPT TO:<user(_at_)domain>. This is
trivial to detect and stop at the moment using local configuration
heuristics, but this isn't a general approach -- it's dependent on
folklore and a lot of duplicated effort. CSA handles this well with
only a few negative records.
I really want to trust that you're right about this; but I must admit
I'm not sure what "EHLO domain" means here...
It's a snippet of SMTP, where domain is a variable denoting whatever the
attacker stated after EHLO.
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. e.g.
*.dotat.at. SRV ...
hand.dotat.at. A ...
No record will be returned for a SRV query with QNAME hand.dotat.at.
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.
(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. These include using
made-up hostnames or hostnames without CSA records.
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.
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.
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.
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 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.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: SOUTHEAST 5 OR 6. RAIN IN EAST
OVERNIGHT. GOOD, BECOMING MODERATE OR POOR IN THE EAST OVERNIGHT. MODERATE,
BUT ROUGH WEST OF ORKNEY, CAITHNESS AND RATTRAY HEAD.