[Mailman-Users] bulk subscribe 7K users

Mark Sapiro mark at msapiro.net
Mon Oct 2 15:50:28 EDT 2017


On 10/02/2017 12:22 PM, Dimitri Maziuk wrote:
> 
>> One big killer in delivery from Mailman to
>> Postfix is recipient address validation at smtpd time. I.e., you don't
>> want reject_unknown_recipient_domain in smtpd_recipient_restrictions.
> 
> :) Well I do actually, this being our mail gateway, but I get the point.
> The more reason to outsource this to out university's IT instead of
> running it locally.


This is easily worked around. Define another "smtpd" service in
master.cf on an alternate port with an override for
smtpd_recipient_restrictions and use that port for Mailman delivery, but
that may not be needed anyway. See below.


> /var/log/mailman/smtp is interesting, actually:
> 
>> Sep 25 15:53:57 2017 (7782) <mailman.0.1506372716.29657.XXX at XXX> smtp to XXX for 1 recips, completed in 0.081 seconds
> ...
>> Sep 25 15:59:06 2017 (7782) <mailman.2.1506373144.7778.XXX at XXX> smtp to XXX for 1 recips, completed in 0.061 seconds

OK. So the bulk of the mail was delivered to Postfix in a bit over 5
minutes. That seem quite reasonable. I clearly misunderstood what you
ment when you said mail was still going out after days.


>> Sep 25 16:48:39 2017 (7782) <mailman.2.1506376117.7779.XXX at XXX> smtp to XXX for 1 recips, completed in 0.065 seconds
>> Sep 25 19:03:16 2017 (7782) <mailman.3.1506384195.7778.XXX at XXX> smtp to XXX for 1 recips, completed in 0.079 seconds
>> Sep 25 19:33:19 2017 (7782) <mailman.4.1506385998.7778.XXX at XXX> smtp to XXX for 1 recips, completed in 0.069 seconds
>> Sep 26 01:14:46 2017 (7782) <mailman.0.1506406484.11544.XXX at XXX> smtp to XXX for 1 recips, completed in 0.062 seconds
>> Sep 26 12:12:45 2017 (7782) <mailman.3.1506445964.7779.XXX at XXX> smtp to XXX for 1 recips, completed in 0.060 seconds


Some of these may be retries of temp fails from Postfix (anything in
smtp-failure?) and some may be unrelated.


> There's 3200 of these lines total, so at .1s/address it should've ran in
> 320 seconds. Instead it ran for 6 minutes,


Actually 5 minutes and 9 seconds or 309 seconds by the logs above.


> then hours later a message or
> two for a while, and nothing after Sep 26 12:12:45.
> 
> /var/log/mailman/subscribe goes
> 
>> Sep 25 15:51:56 2017 (29657) XXX: new aaa at ADDR, admin mass sub
> 
> to
> 
>> Sep 25 15:53:56 2017 (29657) XXX: new jjj at ADDR, admin mass sub
> 
> and ends there. To my uneducated eye it looks like smtp transactions
> haven't even started until the subscription's gone about halfway through
> and presumably aborted.


The welcome message is queued in Mailman's virgin queue and processed
asynchronously by VirginRunner which moves it to Mailman's out queue
where it is processes (again asynchronously by OutgoingRunner).


> Anyway, this is getting academic. What I wanted to know was is it dead
> or is it still doing something behind the scenes, and I got the answer.


Yes, it is 'academic' but a deeper understanding of the processes
involved can't hurt. I'm compulsive (often too much so) about answering
every outstanding question, even if they are only my own questions.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20171002/e3487a69/attachment.sig>


More information about the Mailman-Users mailing list