[ On Monday, April 8, 2002 at 20:46:21 (+0200), Florian Weimer wrote: ]
> Subject: Re: [Exim] Mailing lists with a twist
>
> I'm not sure. Injecting the messages over SMTP has a considerable
> advantage: a stable interface, and no need to upgrade the injecting
> software each time the MTA is upgraded.
Yes, that is also a huge advantage! ;-)
(I don't remember, did you say how you currently inject messages for
relay and distribution?)
> Well, I'm currently bypassing the central mail relay, after some
> (artificial) tests showed that it might not survive the load. ;-)
>
> You are probably correct that storing all the messages in the queue
> first wouldn't be too bad in the end. After all, our messages are
> rather short (probably 8K or so in the average), and even tens of
> thousands of them wouldn't take significant amount of disk space.
Are you using a separate mail relay machine to process the outgoing
mailing list distribution now? Can you continue to do so, just
upgrading the MTA on that machine? Can this machine handle the load
assuming the messages are all first queued?
> When I do this, shall I implement pipelining in the MLM SMTP client?
> Or this this a wasted effort if the relay MTA is Exim?
If you are going to send a separate SMTP envelope sender address for
each recipient, i.e. each message (which is essentially VERP, IIUC) then
you cannot gain anything with ESMTP pipelining regardless, so initially
I'd suggest not even bothering. You might not even need to bother with
ESMTP (unless you highly desire to use 8BITMIME where possible).
> I few years ago, I had the same attitude, but I'm no longer sure if
> it's the right approach.
Well, in your case the average message being quite small is certainly a
mitigating factor! ;-)
> It allows us to unsubscribe bouncing and
> autoreplying addresses immediately, thus saving bandwidth.
Do the bounces you seen normally happen as new messages from the remote
MTA, or do you more frequently see SMTP-level refusals, or is there some
mix of both?
If the former make up the majority then certainly reducing the number of
bounces helps everyone, but if the latter then even your own bandwidth
savings will be negligible. Indeed if it's the latter case then you can
also be more certain of the format of the bounce messages (at least for
a given MTA) and thus more easily process them and thust not need to use
VERP(-like) techniques to determine which address caused the bounce.
> In
> addition, network bandwidth is cheap, compared to the time required to
> manually process bounce messages, or even to write complaints about
> bounces without *any* information.
_Your_ network bandwidth may be cheap....
But can your own costs and savings justify the costs to others? ;-)
(indeed a more scientific analysis within the domain of your specific
lists would be necessary to answer this question without so much
bias.... :-)
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
