On Thu, 30 Aug 2001 15:47:06 EDT, "Gnanasekaran, Vijayalakshm" <[log in to unmask]>  said:
> Here is the additional info. Customers claim that their email server is
> available all the time. I am not sure about the routing problems (and I

If Dave Crocker says his e-mail server was available the whole time,
I'd tend to believe it without specific evidence to the contrary.

(For those who tuned in late, Dave was the author of RFC822 way back
in 1982, was co-author of ESMTP in 1993, and has been doing e-mail
for so long that he makes *me* feel like a newbie. ;)

> >Received: from dispatch.realcities.com (dispatch.realcities.com
> >[209.97.16.43])
> >         by joy.songbird.com (8.9.3/8.9.3) with ESMTP id OAA23631
> >         for <[log in to unmask]>; Mon, 27 Aug 2001 14:13:30 -0700
> >Received: from dispatch (209.97.16.43) by dispatch.realcities.com (LSMTP
> >for Windows NT v1.1a) with SMTP id <[log in to unmask]>;
> >Mon, 27 Aug 2001 12:01:49 -0400

And Dave is right - just over 5 hours to deliver it.

I'm a sendmail person, not an LSMTP person, but I know that LSoft
routinely pumps insanely high volumes of mail through LSMTP at their
EASE servers, so it's probably an configuration issue someplace.

Some things to check:

1) Multithreading - how many chunks does it break the mail into, and
how many are tried at once?  If your 40K list is broken into 8 pieces of
5K, the 4,984th recipient in each of the 8 pieces will have a VERY long
wait.  On the other hand, if it's broken into 400 work items of 100
recipients each, and all 400 are tried in parallel, things will go fast
(assuming the system has enough CPU/memory to do 400 at a time).

2) Check that your DNS is up to speed - if you have 40K recipients, that's
40K queries that have to happen.  Make sure that you don't have lots
of recipients waiting for DNS lookups (or if you do, that they are
not clogging up your queue and making other deliveries wait).

3) A very useful but not-quite-according-to-standards trick is to
set the timeout for the *first* attempted connection very low (in
the 5-10 second range), with a more reasonable wait (RFC1123 says
5 minutes) on retries.  This lets you get a *first* delivery attempt
done quickly without waiting - ones that don't answer in 5 seconds get
retried later after you've tried everything once.

4) And of course, check the *obvious* - are you running at 100% CPU
and tasks blocked waiting for CPU, or paging heavily?  If either of
these are true, you need to deal with them.

                                Valdis Kletnieks
                                Operating Systems Analyst
                                Virginia Tech