I'm almost certain that your problem is RFC 413. What is happening is that
Exim is doing auth/identd lookups (as described in RFC 413) to be able to
print additional information in log files, useful for tracking remote users,
among other things.
The problem is that most firewalls these days (incorrectly) simply drop
packets to TCP port 113, for security reasons. This causes problems, as mail
and FTP servers will wait out a long timeout before giving up on the ident
lookup, or worse, disconnecting the client. The proper way for firewalls to
block these connections is by responding with a TCP RST, asif the host
against which the lookup being done had itself refused the connection.
Exim performs the lookup immediately when a client connects, and does not
send its banner until it either receives a reply, receives a negative reply
(connection refused also counts here) or runs over its timeout for this
lookup.
The default timeout is quite long, and could easily be causing this. It
would not happen to your LAN machines as these most probably are not
firewalled off from the server and it receives a positive or negative reply
almost right away. It might still happen with localhost if your machine has
very strict firewalling policies.
My possible solution to your problem is adding this to the primary part of
your Exim configuration:
rfc1413_hosts =
This line disables all RFC 413 (ident/auth) probes and should make your
server send its banner immediatley. If you feel you really need these
lookups, for security reasons, or what ever, you might just want to lowe the
timeout, like this:
rfc1413_hosts = *
rfc1413_query_timeout = 5s
This means lookups are done for any connecting host, but abandoned if no
reply is received after 5 seconds. Choose which ever timeout you feel is the
best.
I might be missing something here, it is very off that port 1025 is not
bogged down, that could also be because of odd firewalling issues,
especially if you are using and old style (non-stateful) packet filter.
Hope this helps.
Will
----- Original Message -----
From: "Scott Courtney" <courtney@???>
To: <exim-users@???>
Cc: <dboyes@???>
Sent: Tuesday, November 11, 2003 11:10 PM
Subject: [Exim] More on the performance problem with mail routing
> I've got some additional information on our performance problem:
>
> 1. We did the test of disconnecting the incoming network from Exim, so
that
> it was only processing outbound messages to the next server. This was
done
> by physically disconnecting the cable. (In this situation, it happens
that
> all inbound messages come into eth1, and all outbound leave via eth0.)
The
> connect time instantaneously sped up from c. 45 seconds to c. 2
seconds.
> When we reconnected the cable, the connect time went back to its longer
> delay.
>
> 2. I happened to recall that we have Exim listening on port 10025 in
addition
> to port 25, a configuration that happened to be copied from another
server
> that uses amavisd-new in that mode. This router doesn't use that second
> port, but I had never gotten around to removing it from the config
file.
> Oddly enough, even when port 25 is under heavy load, port 10025 will
give
> me an Exim banner within about 2 seconds. Port 10025 is not accessible
from
> the Internet due to firewall rules; it can only be accessed from the
local
> host. But port 25 has the slow connection even with telnet from
localhost.
>
> This really smells like some kind of a problem with Exim forking itself
too
> slowly, or with Linux kernel not being able to create sockets fast enough.
>
> Does this additional information trigger anyone's memory on a possible
cause
> you might have seen?
>
> By the way, we have now exhaustively tested that all reverse DNS for all
the
> IP addresses of all the servers are working. This includes localhost and
its
> reverse lookup. I think DNS can finally be ruled out as a problem.
>
> The version of Exim we are running is 4.20. Among other things, I'm
looking
> at the changelogs of Exim 4.21~4.24 and at the kernel changelogs between
> 2.4.20-18 (what we're running) and 2.4.20-20 (the latest RedHat has
available
> to download), to see if there might be anything relevant in these updates.
>
> Finally, we're going to set up a test with Exim being spawned by xinetd
> instead of by its own listening daemon, to see if that will help.
>
> Kind regards,
>
> Scott
>
> --
> -----------------------+--------------------------------------------------
----
> Scott Courtney | "I don't mind Microsoft making money. I mind them
> courtney@??? | having a bad operating system." -- Linus
Torvalds
> http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999)
> | PGP Public Key at
http://4th.com/keys/courtney.pubkey
>
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim
details at
http://www.exim.org/ ##
>
>
>
