(comments not directed at Valdis, just at the thread!)

--On March 20, 2006 11:54:29 AM -0500 Valdis Kletnieks 
<[log in to unmask]> wrote:

> 2) Although the RFCs frown on it, you're best off making *one* attempt to
> deliver the mail with drastically shortened timeouts. One particularly
> big win is to timeout the *initial* connection attempt after only 5
> seconds or so ("O Timeout.iconnect=5s" for Sendmail's .cf file) - if they
> can't get a TCP 3-packet handshake done in 5 seconds, they're probably
> down.  After the first attempt, *get them out of the way* and re-try them
> with more traditional timeouts later.

Yup, in large installations I've done exactly this.  Addresses at the end 
of initial delivery attempts got shunted off to retry machines.  They had 
actual disk based spools instead of ramdisk.  The majority of mail that 
went over to the retry machines sat around for their max timeout values 
before being bounced back.  This was all internal tweaks.

> 3) If most of the mailings are going to the same people as the last time,
> I *highly* recommend a local caching-only DNS server - if you have enough
> memory, running it on the same machine as the MTA is ideal.  The
> round-trip time to look up MX and A records can be a *major* throughput
> killer (eliminating *one* particularly badly timed MX lookup in Sendmail
> resulted in a 6X speedup on my Listserv box. 'FEATURE(nocanonify)' in the
> sendmail.mc file is the magic incantation).

Yup, along those same lines your outbound ListServ MTA shouldn't be trying 
to do anything WRT inbound mail at all.  This speeds things up a lot.

> 4) Make sure all the 'User Unknown' bounces get fed back for removal from
> the database.

Yes!!! Please!!!  I can't tell you how many people come to host at 
$employer, and get upset when we won't let them use their cobbled up PHP 
script and force them to use mailman, listserv, or sendstudio (even 
sendstudio isn't great but...it's better than nothing) and they suddenly 
'lose' half their list!  They get *irate* -- well see here, they're all 5xx 
bounces, those addresses don't exist!

> 5) Be prepared to have somebody watching the queues in case some site you
> send a lot of mail to goes belly up.  If 1% of your subscribers have
> yahoo.com addresses, you will almost certainly end up with lots of mail
> queued for the yahoo.com mailservers (1% of a million means 10K
> recipients headed there, which will irritate their mailservers and
> generate lots of '421' errors).

Yahoo, Gmail, AOL, etc all do per-mailserver blocking so you've got to 
watch out for all of them.  When they decide to block a higher-ish-volume 
server you get a LOT of pain.  Most of the time for us it's because their 
clueless $lusers's have asked their domain to be forwarded then report SPAM 
at the other end which just reports us.  They wanted EVERYTHING forwarded, 
so we do.

>
> 6) If you don't have a clue what an SMTP 421 error is, find somebody who
> does.  If you're sending a million pieces of mail a day, you *will* need
> somebody who's technically skilled to deal with sites that think you're
> spamming them, or sites that block you because they don't like technical
> incompetence.
>
> 7) Have working *and responsive* abuse@ and postmaster@ aliases.  Failure
> to do is one of the quickest ways into many places' blacklists.  See (6)
> above....

And having abuse registered in the 'right' places, contact points in WHOIS 
for your domain *AND* your IPs.  If I have to hunt you down I might just 
add you to the permanent block lists and not even bother.  AOL, Verizon, 
others, will do the same.