Re: [exim] LAN relaying

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] LAN relaying
Marc Haber wrote:

> On Sat, 26 Aug 2006 00:09:37 +1200, Stephen Kestle
> <stephen@???> wrote:
>
>>But why does exim take so long to send it (a full 35 seconds for a one
>>line text message)
>
>
> If the receiving box is a default-configured exim as well, this might
> be http://www.exim.org/eximwiki/FAQ/General_Debugging/Q0020
>
> Greetings
> Marc
>


The link marc refers to covers the very common 30 seconds for the default ident
time-out, and many, if not most of us have ceased to use that, as it rarely
succeeds nowadays, and is very annoyingly 'in your face' at the user's MUA session.

JFWIW department if you are interested in the *remaining* five seconds:

- a 'cross box' local-to-local transmission from the CLI to another user can log
as zero seconds (timestamps), zero Queue time, zero Delivery time. Use of the
'time' utility typically shows user 0m0.001s and sys 0m0.002s, plus whatever it
takes to fetch a canned message from a piped file or type a few words manually.

- a 'favored correspondent', message from on-box to on-box users, but invoked
via a remote MUA 12,000 miles from the server, runs about 3 seconds 'wall clock'
time, including TCP/IP session setup/tear-down and TLS_on_connect authentication.

In our case, this involves multiple SQL calls, though 'favored correspondent'
means we drop strict sync, skip RBL callouts, and omit SA (but not ClamAV)
scanning, apply fewer acl tests for format, MIME, smtp protocol violations, etc.

Best case, on a fast server without our complex SQL-based-everything, may be as
little as one second (wall clock time) for remote MUA access, and consistently
sub-one-second for LAN-to-LAN 'favored' traffic.

Coupled with fast-cycling POP or synced IMAP, this makes smtp near-real-time in
human terms. Much appreciated by SME home/branch offices!

*Worst case* is another matter, depending on message size, link packet loss,
callout and scanning turnaround time, use of the 'delay' verb, etc.

We've seen over 100 *hours* when testing really rude cumulative delays against
zombies that just won't drop off the teat. Gave *that* up for more reasonable
limits!

So - by issuing a 'free pass' to favored correspondents, such as your LAN
community, you may be able to cut the remaining 5 seconds by 50% to 80%, aside
from message size.

IF that matters to your needs ...

In all cases, SA and such aside, the 'machine time' Exim itself needs is a very
small fraction of the wall-clock time.

Fortunately ...

;-)

JFWIW,

Bill