This is because the POP and SMTP servers are trying to establish an identd/AUTH
connection back to the client. These reverse-connections are blocked, and it takes a while
before the servers timeout and continue.
The identd/AUTH service identifies the user of
the TCP connection (user name, process id, etc.). When the e-mail server accepts the
incoming TCP connection, before sending the greetings, it will first attempt to gather
information via the identd protocol. This consists of a TCP connection in the reverse
direction. In other words, when I connect to my e-mail server, my e-mail server attempts
to connect back to me on port 113, the identd port. My e-mail connection just sits there
until the e-mail server resolves the identd information.
The problem comes about because the firewall silently drops the SYN packet. The e-mail
server is expecting an immediate SYN-ACK (identd supported) or RST (identd not supported),
but when the firewall drops the packet it keeps trying until the connection times out.
Note that the e-mail server doesn't care if I don't support identd, and indeed most
people don't on their clients. It just wants an immediate response one way or the other.
The firewall blocks that. This is why some personal firewalls for Windows (like BlackICE
Defender from my company) contain default rules that allow identd/AUTH to pass through.
Windows doesn't reveal the information that UNIX does, and opening it up gives the
immediate response these servers are looking for.
To solve this problem:
- reconfigure the e-mail server to stop querying identd info
- reconfigure the firewall to RST all those connections
- reconfigure the firewall to allow this protocol, but this would be a BAD IDEA
because identd/AUTH reveals a HUGE amount of information about your UNIX machines.
Note that this means you should be seeing lots of dropped incoming
connection attempts at port
113 in your log files because of this.