[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rules for Rejecting Mail (was Re: Undelivered Mail Returned to Sender)
Jim says...
Eric, while your logic is correct it misses one critical point: SPAMMER don't
do this. I'm not saying that no SPAMMERs do this but I am saying that many
SPAMMERs do not.
I can't figure out what you're saying here. Are you saying that these checks
aren't meant to stop spam? What, then? (By the way, we write "spam" in lower
case. A small point, I grant, but....)
The efficacy of any given SPAM rule varies with its environment. I don't know
if this rule is "great" for the IETF but I do know it's a common rule. It has
a stricter version where the forward and backward DNS lookups are compared but
that is usually more problematic. The IETF does not use the strict version.
I'm not sure what that first sentence is meant to say. In any case, I think the
whole rule is problematic (see below).
Of course there is the point of view that says that any false positive is too
many, but then you got caught by this by having a poorly configured email
client. Once you fixed that the rule was not a problem for you, so I'm not
inclined to count your rejection as a false positive.
You say "poorly configured"; I say it's just fine. There's nothing in any
standard that says that an entity that sends mail (but doesn't receive it) has to
be resolvable in any way. It's perfectly reasonable for a small domain to set up
an outbound mail server that fails some or all of the checks that Glen lists.
And neither DKIM nor SPF/Sender-ID require that the individual server resolve in
DNS.
Logic does not necessarily apply when it comes to SPAMMING. What matters is
"does it work."
That's too simplistic. First, "works" means that it blocks spam *and* does not
block legitimate traffic. Second, it matters that it works in the long term, not
just for today (see below).
Glen says...
When we did the cutover, we went over the rules the IETF wanted to use, and
implemented them. Amongst those rules WERE such elements as:
A. Check that the HELO hostname has an "A" or "MX" record, defer if not.
B. Check that the client IP address maps to a name; defer if not.
C. Check that that name maps back to an IP address; defer if not.
D. Check that the name->address mapping matches the client IP; defer
if not.
These were, in essence, rules given to us by the IETF at the time.
The HELO serves only to start the session and to identify the sending domain for
the log file. The domain that's given there is used for nothing -- nothing at
all. It's easy to think that it's reasonable to at least make sure that it's a
valid domain for sending mail from (the purpose of test A, above), but the
reality is that it can be bypassed by putting any domain at all there. I can
send email and use "HELO whitehouse.gov" and the receiving mail server will be
happy.
There've been proposals to validate the sending server's authority to use that
domain (CSV, for example, http://mipassoc.org/csv/ ), and to actually use the
domain for some purpose, such as checking it against a whitelist or blacklist.
But unless it's *both* validated and used, there's no value in doing the DNS
check.
The assumption for checks 2 and 3 is that the mail infrastructure at example.com
will have a set of mail servers with fixed IP addresses that will resolve in both
direction, but that if mail is sent illegitimately, by some user within
example.com, bypassing the normal mail servers (such as spam sent by a zombie)
it's possible that one or both of the DNS resolutions in 2 and 3 will fail.
That's the theory, anyway. The practice is that the transient IP addresses that
are usually assigned to users' computers often *do* resolve in DNS... and small
domains often don't have all their computers listed (they aren't expecting people
to want/need to resolve them), so they wind up as false positives and get their
mail blocked.
And step 4 just seems odd. If the DNS resolutions work in 2 and 3, a failure in
4 would most likely indicate a configuration error, rather than a "bad guy". It
seems strange to use a check like that to block mail. Can that really be
catching any spam?
All of these checks seem wrong to me as currently implemented. And in general, I
think it's a bad idea to use anti-spam techniques that address current spammer
tactics that are easily changed once the spammers are aware of what we're doing.
It's rather like rejecting mail that contains certain keywords: the spammers just
start misspelling the words. We long ago learned that that's a pointless
skirmish, and that we need to fight more strategic battles.
It's reasonable to put something in that's not effective in the long term but
that will work for now, if you're responding to a burst of spam that has to be
stopped. "There," you can say, "this will take care of this problem until we get
a better solution." It's not reasonable to patch together a bunch of "anti-spam"
rules that will just be wasted effort as soon as a spammer realizes that enough
people are doing it.
(And I also agree with ekr that 4xx errors that will never go away are
particularly egregious ways to reject mail. Which is all the more reason that
it's a bad idea to do DNS checks for which you can't know whether or not you have
a definitive answer.)
Barry
--
Barry Leiba, DKIM working group chair, and IAB member (leiba at watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam