[Mailman-Users] Increasing the Speed of Email Delivery

Derrick Wooden derrickwooden at gmail.com
Wed Dec 23 20:12:41 CET 2009

I'm well aware that SMTP doesn't mean instant.

I'm just looking at a solution that can cut 1E6 emails being delivered in 12
hours down to say 4 hours.  With a fast server, correct MTA optimization and
proper Mailman setup could this be attainable?
The Barack Obama email campaign used Postfix for their MTA and PHP Mailer to
deliver their newsletters.  

I'm using a package install of Mailman along with Exim through cPanel.  I
now know that this setup is not optimal and needs lots of tweaking.  I'm
looking into VERP also based on helpful information in the FAQs.

Bernd Petrovitsch-2 wrote:
> On Don, 2009-12-17 at 17:04 -0800, Carl Zwanzig wrote:
>> Lots of it depends on the MTA (general opinion is that postfix seems to
>> be 
>> the fastest), connectivity, and list settings (personalized email will
>> take 
> Do I take the flame bait?;-)
> Whatever you understand in detail under a "fast MTA" (and even if it
> would be the case), it doesn't really matter IMHO because
> a) Email/SMTP never was anywhere near "realtime" (though many people
>    expect mails to be delivered in seconds),
> b) if your local Internet connection is too small, it doesn't help to
>    have the fastest MTA[0],
> c) the local MTA resolves various hostnames and that could be "slow" and
>    will involved timeouts (where every MTA out there just can wait)[0],
> d) if your hardware (RAM, disks) are too small or slow, the MTA really
>    can't do anything (and I expect all widespread MTAS to reasonably
>    minimize the I/O and memory anyways). That may be irrelevant on the
>    usual small mailserver with average nowadays hardware but if you have
>    e.g. a small ISP with >25K mailboxes and (on the average) 1E6 mails
>    per day ("after" using DNSBLs blocking lots of spam/viruses before
>    even sending "EHLO"), it
>    looks quite different,
> e) b) for the remote MTA - but you have absolutely no influence on the 
>    remote side[0],
> f) c) for the remote MTA - but you have absolutely no influence on the 
>    remote side[0],
> g) the remote MTA may do extensive spam/virus checking, grey-listing,
>    ... - taking time - causing "slow" mail delivery you have absolutely
>    no influence on the remote side[0].
> Of course the timeouts and waiting from above cost next to no
> resources/performance locally (so the MTA(s) usually deliver several
> emails in parallel without any problems as long as the box(es) do not
> trash) but it costs total time (which makes email delivery "slow").
> So I don't think that saving 10% (or even 50%) local "speed" will make a
> significant difference (perhaps if you have a *really* large setup - but
> even then deploying one more box is cheaper than investing a day to
> improve the local performance. OK, saving a box is better for the world
> as such ....).
> 	Bernd
> [0]: And changing the local MTA won't solve that.
> -- 
> mobil: +43 664 4416156          http://bernd.petrovitsch.priv.at/
>     Linux Software Entwicklung, Beratung und Dienstleistungen
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at python.org
> http://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives:
> http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe:
> http://mail.python.org/mailman/options/mailman-users/lists%40nabble.com

View this message in context: http://old.nabble.com/Increasing-the-Speed-of-Email-Delivery-tp26837149p26906066.html
Sent from the Mailman - Users mailing list archive at Nabble.com.

More information about the Mailman-Users mailing list