John Maier writes:
> 
> identd, Hummm, this seem the most plausible reason thus far.  Do you know   
> of an option to stop this?  Our MIS would rather die that to open a hole,   
> for packet, at a specific port.

They should keep in mind that enabling outgoing identd is a security
*plus*, not a minus. For starters, it is an aid inverifying the name of
the sender of a piece of email (only useful if the sender is on a Unix
system, and doesn't have root privileges) which helps to reduce the
amount of mail with spoofed sender addresses. Additionally, you only
need to enable it *outbound*, meaning that it is a machine on your own
network that is requesting the service - it can't come in unrequested.

Ah, but I see the machine in question is outside your firewall, and you
want to send mail to it from inside the firewall. I would still
recommend turning on identd - if any internal machines don't have it,
they will return ICMP Port unreachable to whoever asks, and if they do
have it, they will simply return the username of the process that is
attempting to send the mail; since this should be in the mail message
already anyway (unless someone is trying to send spoofed email), I don't
see this as a security risk.

It used to be fairly easy to compile out the identd support in sendmail,
but I haven't done that in several revisions, so I can't recall how it
was done (probably a -Dsomething-or-other in the CFLAGS) nor do I know
if it's still as easy. I wouldn't recommend this anyway.

Alternately, you could have your firewall return an ICMP Port
Unreachable packet in response to an outgoing identd request. This would
cause sendmail to believe the other end wasn't running identd, in which
case it should immediately give up.

> Also, this doesn't explain why if I do a `telnet beta 25` on beta, I   
> still get an immediate connection, beta has ident remarked out.  Does   
> sendmail ignore local connections?

No, I believe the difference you are seeing is due to how your firewall
is blocking the packet. When you telnet localhost 25, sendmail attempts
to connect to identd on localhost, and localhost sends back and ICMP
Port Unreachable packet. Seeing this, sendmail realizes it is no use
trying any longer, so it just goes on without the information. When you
go across the firewall, sendmail sends out the identd syn packet, which
your firewall blocks, then either sends an ICMP Host Unreachable packet
back, or no packet at all. Because this response doesn't make any sense,
sendmail continues retrying for some amount of time, then finally gives
up.

The proper response for your firewall would be to send an ICMP Port
Unreachable (meaning "Sorry, but that host doesn't handle the specified
protocol"). If that were done, I'd bet there would be no delay.

> As for DNS, no, no, no, it isn't the DNS, I've tried DNS forward and   
> reverse lookup with no problems.  FTP does a reverse DNS lookup and works   
> fine.

I don't believe I suggested that.