Re: Qmail/Postfix/Sendmail for fastest outgoing mail
On Mon, Nov 25, 2002 at 11:37:58PM +1100, Jason Lim wrote:
> > nope, because postfix has no way of knowing that they were
> > originally the same email(*). postfix has been handed 10 individual
> > emails by qmail, so it will deliver 10 individual emails.
>
> Mmm... but, for example, if it scanned it's queue every 30 seconds,
> for example, it could then combine them together?
nope.
> I'd assume ISPs and such would have great use for this, especially on
> web hosting boxes, as overhead in sending numerous emails could be
> saved?
i don't imagine they would. it's easy enough to just send one email if
that's what you want to do - why complicate matters by hacking your MTA
to have super mind-reading powers?
> > postfix would be slightly faster than qmail but not that much faster
> > that it's worth using different software for - unless part of your
> > purpose is to get some real (as opposed to testing) experience with
> > postfix to decide whether it's worth switching.
>
> Actually, I can't see how Postfix would be at all faster, since it
> would still be sending individual emails on separate connections. In
> fact, wouldn't it be slower, since Qmail was optimized specifically
> for this?
nope, because postfix is faster than qmail. with some usage patterns
(i.e. no VERP) it is much faster. for others (e.g. VERP) is is only
slightly faster.
> > if you want to fix this problem, you have to do it at the source -
> > i.e. replace qmail with postfix on your main boxes. that would be
> > a lot of work, not something to be done lightly.
>
> And certainly not feasible on production systems... unfortunate. But
> actually, Qmail was the best choice at the time, since it an Vpopmail
> make such a good incoming email system.
actually, it is feasible, it's just a lot of work that can go seriously
wrong if you're not scrupulously careful in your planning and your
implementation. i.e. it's do-able, but hard. whether it's worth the
effort is for you to decide.
> > if you're not using ezmlm, you may be able to hack your list manager
> > to bypass local qmail and send outgoing messages via SMTP direct to
> > the postfix box. this may involve hacking the list manager to talk
> > SMTP rather thank fork /usr/sbin/sendmail, or it may involve
> > replacing /usr/sbin/sendmail with a wrapper script that talks SMTP.
> > either way, it's not too hard.
>
> Nope... not running ezmlm at all, just a lot of CGIs (through
> web/Apache) sending emails. Actually... I wonder... is there any
> drop-in replacement for /usr/sbin/sendmail that would just dump the
> emails to another server for actual sending? This should not affect
> receiving email in the least (hence minimize disruption) but would
> need to be able to dump the emails at a high rate. I'm not sure if
> there is such a thing though.
IIRC, there's a simple one that comes with postfix or is available on
one of the postfix contrib web sites.
if not, it would be trivial to hack up a simple one in perl using the
Net::SMTP or MIME::Lite modules. about 5 minutes work - accept the
message on stdin, connect to port 25 on the postfix box, and send the
message via smtp.
alternatively, just modify your CGI scripts to make an SMTP connection
to the postfix box rather than fork sendmail. it's easy to do and, IMO,
is what CGI scripts should do anyway. MIME::Lite is a good perl module
for sending mail via smtp - whether you use it's MIME features or not
(and it's also good for generating correctly formatted MIME messages)
IMO, using MIME::Lite is easier than forking sendmail....and far more
versatile.
i tend to modify most email sending CGI scripts to use MIME:Lite or
Net::SMTP because i really don't like CGI scripts that fork sendmail -
most of the authors are too lazy to call sendmail with the right
arguments to set the real From envelope address, so the mail is sent
with the apache user's address in the Return-Path header (e.g.
www-data@your.host) - which results in bounces being delivered to
www-data and the occasional idiot user replying to www-data...a mailbox
that almost never gets read.
this is not a problem when sending with SMTP because you have to specify
the envelope from address as part of the SMTP dialog.
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: