Well, it seems that to most of the world, my box is up and running and looks fine. But my Exchange 2000 server at work still won't talk to it..getting messages in the exim log to the effect of "SMTP command timeout"...meaning Exchange isn't getting a timely response, and so isn't sending any commands, even though the TCP connection is OK.

When I telnet:25 from work, I can pretty typically produce the following scenario (my typing is in bold):

ehlo amor.org
mail from: fumanchu@amor.org
rcpt to: fumanchu@aminus.net
data
subject: another test
from: fumanchu@amor.org
te220 mp5.aminus.net ESMTP Exim 3.36 #1 Wed, 19 Mar 2003 09:16:37 -0800
s250-mp5.aminus.net Hello amor.org [63.200.221.34]
250-SIZE
250-PIPELINING
250 HELP
250 <fumanchu@amor.org> is syntactically correct
250 <fumanchu@aminus.net> verified
354 Enter message, ending with "." on a line by itself
t78
.
250 OK id=18vhB7-0001Bc-00
quit

So...exim is waiting...the only thing I can guess at is that it is doing some sort of DNS lookup on my sending IP, but failing, even though exchange2.amor.org [63.200.221.34] is the lowest-cost MX for amor.org. I *believed* I had turned that off, but I must have missed something. I'll post my exim.conf if anyone wants to see it.

Anyway, the only reason I bring it up here instead of some exim mail list is that I'm not convinced the problem is with exim. My first thoughts were ipchains/netfilter (but my kernel's not set up for that), and then tcpd (i.e. hosts.allow/deny, but I'm not using inetd to start exim). So my question is, is there another layer somewhere that could be filtering this traffic on my box that I don't know about?

There's a setting for your exim.conf file to fix this for all hosts:

rfc1413_query_timeout = 0s

"0s" turns identd probing off completely. I know because I had to make a mad dash just now to get Papa John's email server to actually speak to me. :)

Mmmmm. Italian sausage....