On Mon, 2009-03-02 at 11:18 -0500, Victor Duchovni wrote: > On Mon, Mar 02, 2009 at 11:59:31PM +0800, Wouter van Marle wrote: > > >> Use a custom transport for these messages with a low concurrency limit, > > > > You mean like installing sendmail or so in parallel to postfix and then > > have sendmail send out the lower-priority mails? > > No I mean a Postfix "transport", as in transport(5) and master(5).
The problem of a transport map (I have just read the man page, which as usual is highly technical so I am not sure whether I fully understand the purpose and working of transport maps) is that there is a huge overlap between receivers of the low-priority mail list and regular e-mail receivers. Most of the regular e-mail receivers also receive this mail list. Many of my mail list receivers are on common domains like gmail.com and yahoo.com, thus this would slow down all other mails to those domains as well, even if they are not part of the mail list. Setting it per recipient is not a good idea because of maintenance issues (keeping mail list and transport map in sync), and because of the regular mails that may be sent to those recipients while a mail list run is in progress. The idea of using a "slow:" transport as suggested in the transport(5) man page (without elaborating unfortunately...) to limit the number of smtp deamons that sounds like the way to go to me. Then I can reserve 80 deamons for the mail list, or maybe 50, enough to saturate my uplink - still allowing regular mails to have an smtp available to be handled immediately. This appears to me a way to let the other mails "jump the queue" and be processed with priority. That there is little bandwidth available is not too much of an issue, then it might take a minute instead of seconds to send out, still a major improvement of the hours it may take in the current situation. > >> or use traffic shaping in the TCP stack to limit the bandwidth per > >> SMTP connection. > > > > And how would that get certain mails out with priority? It sounds to me > > like this would slow down the overall process. I have up to 100 smtp > > processes running at a time, but as long as new mails end up at the back of > > the queue still no progress there. They have to come first. > > It would not, but you won't saturate the entire link with any given email, > leaving enough room for other traffic. If you can limit the concurrency > of this particular message, then you'll have some bandwidth left over for > other messages. I don't like that idea very much: when I have only a few mails to send out, I want them to go with the maximum speed possible. I have 2 Mbit available, so with 100 smtp connections could limit it to say 20 kbit per smtp process. But that would leave the rest of my bandwidth idle when there are less than 100 active smtp connections, which is the case like 90% of the time. Wouter. >
