On Sat, 9 Oct 2004, John Leslie wrote:
I'm not sure I agree it's reasonable, but it has come up several
times that people want to mark subdomains as "not authorized" --
meaning, I assume, that they want receiving SMTP servers to reject
all email from sending SMTP clients who use a "not authorized"
subdomain for the EHLO string.
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.
(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, 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.
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; 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. This is a
nice feature.
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.
Absence of a CSA record implies to the recipient that the domain concerned
doesn't know about CSA, so the recipient has to fall back to traditional
lax HELO checking. 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'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.
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 more
about improving the believeability of Received: traces and preventing
blatantly stupid criminality.
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.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
SHANNON: NORTHEAST 6 OR 7 DECREASING 4 OR 5 LATER. SHOWERS. GOOD.