[ On Monday, April 8, 2002 at 19:49:45 (+0200), Florian Weimer wrote: ]
> Subject: Re: [Exim] Mailing lists with a twist
>
> I fear that I might generate the messages much faster than they are
> sent out by the MTA, and they are unnecessarily stored in the queue
> (when it would have been better to delay the message generation a
> bit).
Does that matter? If you submit them via SMTP then they have to hit the
disk. That's a requirement of the SMTP store-and-forward protocol
requirement. The whole reason for using an SMTP MTA to relay the
messages in the first place is so that it can queue and retry those that
are not "immediately" deliverable -- otherwise you could just do direct
SMTP delivery right from the MLM! The MTA you choose as the relay will
hopefully have the best possible queue management implementation. :-)
I would say you _want_ this to happen anyway -- get all the messages
into the mailer's queue ASAP and then let it spew them out at the speed
they can be sent over your available bandwidth and the speed the remote
servers can accept them, using the amount of concurrency your local
server and your available bandwidth can manage (but hopefully not using
an MTA that will open [too many] multiple connections to each individual
remote server).
The MLM should open a single SMTP connection to the local relay mailer
which will deliver these messages and send each message separated by an
RSET command. Depending on the MTA you may have to tune it so that it
doesn't fork too many concurrent delivery processes while it's accepting
these messages (or even not to fork any -- i.e. not to start delivery
until they're all in the queue). (Note that there's little, if any,
difference between doing this and doing "batched SMTP" other than maybe
the fact that with a real SMTP connection you don't have to store the
batch on disk in between -- you just generate it on the fly.)
I should probably reiterate that what you're doing is "bad" and
unneighbourly. You should try to find a way to send as many identical
messages in a single SMTP transaction as possible, hopefully sorted by
MX for the destination domains. You're not only wasting your bandwidth,
you're also wasting the bandwidth of all those servers which MX for more
than one of your recipients. In my direct experience with list managers
who demand such silly things it usually turns out that many, and
sometimes all, of their recipients are hosted by a single MX server!
Of course I do understand the real world doesn't always work so smoothly
though. I have one colleague still sending out multi-megabyte PDFs
across an expensive T1, and most all go to one mailer at the other end.
The person paying him for this idiocity feels that the benefit of these
"personalised" messages is worth the cost, but unfortunately this person
is a third-party service provider who sells list-management services --
she is not the person who ultimately pays for the service, and is not
the person paying for the bandwidth on the receiving end (which for at
least some of her lists is the same person paying for the list
outsourcing in the first place -- making this situation double lunacy!).
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
