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...
(2) More recent malware is saying EHLO canonical-name. This is correct
from the protocol point of view (unlike case 1), but in most cases
direct-to-mx smtp is either not permitted or not supported by the ISP,
Lets clarify this. Forbidding direct-to-MX usually means port 25
blocking, except to a limited set of ISP-maintained SMTP servers.
I think you're talking of instead listing the IP range as "dynamically
allocated" and encouraging receiving SMTP servers to blackhole it.
and most recipients don't want to allow it either. Hence dynamic address
blacklists; but these require co-operation between ISPs and blacklist
maintainers. CSA can optimise this out by effectively being a distributed
blacklist maintained by ISPs.
I don't think this follows.
In the first place, CSV is quite specifically designed to allow a host
in a dynamically-allocated range to issue "EHLO vanitydomain.com" and
let one of the dynamic-DNS services report its IP address for the address
lookup. Under that scenario, a host which otherwise would have been
blacklisted by the receiving SMTP server can be both authenticated and
authorized, and email can be delivered.
CSV generally is more effective for bypassing blacklists than simulating
them.
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.)
but it allows clueful customers to override this policy without
co-operation from the ISP by defining their own foward DNS in the
appropriate way.
Exactly!
This is a nice feature.
Thank you. :^)
There are other kinds of abuse (more speculative) which CSA can protect
against:
(3) Malware that sends EHLO domain ... MAIL FROM:<user(_at_)domain>. CSA can
handle this as effecively as it does type 1 abuse.
(4) Use of random hostnames from unrelated domains in HELO, either valid
hostnames from the DNS, or completely made up ones. CSA can protect
against this, but it requires a negative CSA record for every name in the
zone, plus a wildcard negative CSA record to mop up the fictional names.
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.
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.
so the recipient has to fall back to traditional lax HELO checking.
... meaning no checking at all... :^(
However, the receiving SMTP server will presumably apply all its
usual blacklists (with nothing eligible for CSV bypassing).
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.
I'm not very fond of the idea of relying on the accreditation/reputation
system to patch up the gaps in CSA, because implementations are likely
to treat CSA as a binary accept/deny decider, whereas DNA will be
treated more as a hint.
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.
John Leslie wrote:
Regardless, let us remember that we're talking about a case of
misuse (if not actual forgery) of a subdomain-name which will _not_
be visible to the recipient; and this wouldn't actually give the
sending SMTP server any better chance of delivery than any other
EHLO string which doesn't return a CSV SRV record.
I'm not that concerned about helping email to be delivered :-)
But that's the _point_ of CSV -- enabling good email to be delivered.
but more about improving the believeability of Received: traces and
preventing blatantly stupid criminality.
Improving the believability of Received: traces requires recording
the right information in them. Recording CSV success is very promising;
recording CSV rejection seems pointless. (Why not just reject the email?)
The problem with making it easier for a domain to advertise a default
deny policy is it implies that CSA needs a zone cut search algorithm
or something similar, which increases the number of DNS queries
required from about 1 to about 5. It depends whether you value
administrative effeciency above network efficiency, I guess.
I will admit (as an ISP) to being more concerned about network
efficiency. YMMV, no doubt...
But if others see a need (as opposed to "Gee, it would be nice")
for CSV to cause blacklisting subdomains lacking SRV records, by all
means explain the need. After all, "Internet Engineering" is what
we're supposed to be about!
--
John Leslie <john(_at_)jlc(_dot_)net>