Mailman stopping message distribution because of SMTP errors
Hi list,
I have recently migrated some lists from Mailman 2 to Mailman 3. Users have been added using the mailman client as pre-verified addresses so the migration happened "silently". Thus, there was a dozen "bad" addresses (domains that did not exist anymore).
Unfortunately, Mailman got some of the "bad" addresses in the first message batch for sending out, so, Postfix closed the connection because of "too many errors" and this stopped the process completely, i.e. Mailman did not continue sending messages to the rest of the list over 600 addresses.
There was no more information in the logs than the Postfix error messages in smtp.log.
Once the "bad" addresses were removed, the list started working as expected.
I consider this a bug. The bouncing addresses should have been marked as "non deliverable" and the subscriptions "paused" and the rest should have been delivered. Or, the list owner should have been notified that there was a problem with message distribution. None of these happened.
Thanks!
-- Victoriano Giralt CIO University of Malaga +34952131415 SPAIN
Note: signature.asc is the electronic signature of present message A: Yes.
Q: Are you sure ?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email ?
On 2/11/20 10:28 PM, Victoriano Giralt wrote:
I have recently migrated some lists from Mailman 2 to Mailman 3. Users have been added using the mailman client as pre-verified addresses so the migration happened "silently". Thus, there was a dozen "bad" addresses (domains that did not exist anymore).
It seems you rolled your own instead of using mailman import21. Is
there a reason for this?
Unfortunately, Mailman got some of the "bad" addresses in the first message batch for sending out, so, Postfix closed the connection because of "too many errors" and this stopped the process completely, i.e. Mailman did not continue sending messages to the rest of the list over 600 addresses.
Is the message shunted? Is there a traceback and a shunting message in mailman.log?
Normally, I would expect the message to be queued in Mailman's retry queue and retried by Mailman
There was no more information in the logs than the Postfix error messages in smtp.log.
What was in the smtp.log?
Nothing in mailman.log?
Nothing in var/queue/shunt?
Once the "bad" addresses were removed, the list started working as expected.
I consider this a bug. The bouncing addresses should have been marked as "non deliverable" and the subscriptions "paused" and the rest should have been delivered. Or, the list owner should have been notified that there was a problem with message distribution. None of these happened.
The HEAD of the https://gitlab.com/mailman/mailman master branch implements bounce processing. This will be in 3.3.1 which is not yet released.
The place for a bug report is <https://gitlab.com/mailman/mailman/issues>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
El mié, 12-02-2020 a las 13:28 -0800, Mark Sapiro escribió:
On 2/11/20 10:28 PM, Victoriano Giralt wrote:
I have recently migrated some lists from Mailman 2 to Mailman 3. Users have been added using the mailman client as pre-verified addresses so the migration happened "silently". Thus, there was a dozen "bad" addresses (domains that did not exist anymore).
It seems you rolled your own instead of using
mailman import21. Is there a reason for this?
Yes, no access to the previous server command line. So, to tell the truth it was not a "real" migration, my excuses.
Unfortunately, Mailman got some of the "bad" addresses in the first message batch for sending out, so, Postfix closed the connection because of "too many errors" and this stopped the process completely, i.e. Mailman did not continue sending messages to the rest of the list over 600 addresses.
Is the message shunted? Is there a traceback and a shunting message in mailman.log?
Normally, I would expect the message to be queued in Mailman's retry queue and retried by Mailman
Yes, it was being retried every 15 minutes with the same result: stopped distribution after the first attempt with the first address batch. Also reprocessing the "retry" files with mailman command interface.
There was no more information in the logs than the Postfix error messages in smtp.log.
My bad, the errors where in the system maillog where Postfix complains.
What was in the smtp.log?
This (redacted to protect the innocent):
Feb 05 16:29:44 2020 (86791) ('127.0.0.1', 51146) recip: listname @example.org Feb 05 16:30:16 2020 (86797) <messageid@example.com> smtp to listname @example.org for 634 recips, completed in 29.087315797805786 seconds Feb 05 16:30:16 2020 (86797) <messageid@example.com> post to listname @example.org from sender@example.com, 4354 bytes, 9 failures Feb 05 16:30:20 2020 (86791) ('127.0.0.1', 51642) Data: b'RCPT TO:<listname -bounces@example.org>' Feb 05 16:30:20 2020 (86791) ('127.0.0.1', 51642) recip: listname -bounces@example.org Feb 05 16:30:43 2020 (86791) ('127.0.0.1', 51870) Data: b'RCPT TO:<listname -bounces@example.org>' Feb 05 16:30:43 2020 (86791) ('127.0.0.1', 51870) recip: listname -bounces@example.org ... rinse and repeat every 15 minutes ...
Nothing in mailman.log?
Nothing at all about SMTP/LMTP
Nothing in var/queue/shunt?
Nothing there, a .psv file in var/spool/mailman/bad/ and two .pck files in retry/
Once the "bad" addresses were removed, the list started working as
expected.
I consider this a bug. The bouncing addresses should have been marked as "non deliverable" and the subscriptions "paused" and the rest should have been delivered. Or, the list owner should have been notified that there was a problem with message distribution. None of these happened.
The HEAD of the https://gitlab.com/mailman/mailman master branch implements bounce processing. This will be in 3.3.1 which is not yet released.
The place for a bug report is <https://gitlab.com/mailman/mailman/issues>
Well, if 3.3.1 has bounce processing, I'd rather wait and test when it is released instead of adding "noise" in the bug tracker, right?
My problem was solved with a workaround: find and remove the "bad" addresses. Let's leave this as reference in the archives in case someone hits the same problem.
-- Victoriano Giralt CIO University of Malaga +34952131415 SPAIN
Note: signature.asc is the electronic signature of present message A: Yes.
Q: Are you sure ?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email ?
participants (2)
-
Mark Sapiro -
Victoriano Giralt