Another
suggestion which is remarkably effective in my experience is
to do an identd lookup, not for the usual reasons but rather because
quite a number of the zombie-army machines are running toy identds
to satisfy things like IRC servers, and they exhibit certain
protocol errors.
"Some of us" are running spoofed identds for other
internal reasons.
What do you mean by "certain protocol errors"?
I've noticed five major classes of errors.
Timeout when connecting to port 113
This usually indicates a packet filter (mis)configured by
someone confused enough to think that silently dropping SYNs to
port 113 is somehow preferable to returning RSTs for them.
This ought to correlate positively with spammishness on grounds
of general clue lack, but it's so depressingly common that I
suspect any such correlation would be weak enough to be
difficult to tell from the noise. I don't refuse on this one;
I list it here largely for completeness.
+OK
I occasionally see what superficially appears to be a POP
daemon running on port 113. I've never seen it on anything
that didn't look like a dialup or other dynamic IP box with no
business sending mail to the net at large.
Port number mismatch
This is the big one. This refers to the response containing
port numbers other than the ones in the query, as when I send
"1397,25" and get back "4900, 6667 : USERID : UNIX : yarjo"
(this is a real example, taken from a recent mailer log). This
surprised me; I put the code in on general "verify all input"
grounds and was astonished to see it not only trip, but trip
fairly commonly.
Bogus UNIX username
This is a "USERID:UNIX:" response where the supposed username
contains a character not present in UNIX usernames. The above
response is an example, since " yarjo" is not a valid UNIX
username. (Well, there probably is some variant out there that
accepts it; '\n', ':', and '\0' may be the only characters that
_cannot_ appear - but a username with a space, or a tilde, or
suchlike, causes enough things to break that I don't mind
considering it invalid.)
Doesn't exist
This is an "ERROR:NO-USER" response. This should never happen;
it indicates either a totally busted identd, a NATting gateway
whose admin is crazy enough to run an identd without making
sure it's a NAT-aware identd, or an 0wn3d machine with a
rootkit good enough to hide the outgoing connection from
whatever interface identd uses. The third one I _definitely_
want to refuse mail from, and the other two I'm willing to call
broken enough to refuse too. (Hm, actually, it could also be a
portscanner connection that was reset before the identd
response comes in; that too I have no interest in accepting
anything from.)
Most of the trips of the "bogus UNIX" test are identds that claim UNIX
usernames beginning with a space. This was perfectly valid under
RFC931 (which specified that whitespace was ignored even at the
beginning of a username), but with 1314 having obsoleted 931 over a
decade ago, I am quite willing to consider it broken today. If you use
that one you may want to ignore leading whitespace.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
