[gconnor]:
The version of CSV that I reviewed (though it was some time ago)
seemed pretty clearly aimed at establishing a connection between
the actions of an MTA and a name -- the name used in HELO.
However, there was no information about how to generalize behavior
of many hosts with different hostnames, all in the same domain.
Thus you can build up a good reputation for "mail1.example.net"
and a bad one for "mail2.example.net", and neither of those is
connected to the other. In that scenario, "example.net" has no
reputation, unless there are one or more MTAs that announce
themselves with "EHLO example.net".
in my experience it is no longer common for the outgoing SMTP server
to have the name of an e-mail domain in use. we had such a setup ten
years ago, but even then many thought it old fashioned to have a host
with the same name as the delegated domain. from RFC 2821:
- The domain name given in the EHLO command MUST BE either a
primary host name (a domain name that resolves to an A RR) or,
if the host has no name, an address literal as described in
section 4.1.1.1.
(address literals obviously can't be used with CSV.) I don't think
this aspect of SMTP is going to be changed, and there is little
incentive to do so.
Your message seems to suggest that you can take several hosts in
the same domain (as in "the domain of the HELO string" and not
just "the HELO string") so I'm wondering if this is now defined in
CSV or if there's some other document that tells how to do it. If
my machine is called mail1.example.net, it makes sense to
consolidate the reputation info under "example.net"... but if my
machine is called mydomain.com, do my actions affect the
reputation of "com."? what about mail1.bbc.co.uk
vs. client1.demon.co.uk?
this is where SPF tries to find the zone cut and uses dozens of DNS
queries, but that won't help, since a spammer can just as easily
delegate himself arbitrarily many subdomains.
If the reputation attaches to a single name and doesn't get
consolidated over multiple MTAs, what value is being added over
just a list of IPs with their own reputations?
it's a practical issue. doing a SRV lookup based on the IP would mean
a lookup in in-addr.arpa. for many sites, adding non-PTR records to
their reverse zones would be excedingly difficult. many corporate
users can't even get their IP provider to update their PTR records to
be consistent. since CSV uses the HELO name as the basis, only
administrative access to the domain with the HELO name is needed to
publish CSV.
Actually, CSV would be worse in that case because the spammer can
use the current date in seconds as his HELO name, even with the
same domain suffix, and have a clean reputation every time.
hmmm..
he would need to add SRV records for each and every HELO name, but a
suitably savvy spammer (if such exists) could make a magic wildcard
syntax in the DNS server for this purpose. actually, _I_ want such a
wildcard to publish _negative_ SRV records for our workstations. as
it is, we would need to add 35296 negative SRV records to our zone to
fully implement CSV...
(I am of course open to the idea that I've missed something... if
so please just point me in the right direction...)
likewise.
--
Kjetil T.