I recently upgraded from Mailman 2.0.8 to 2.1.2. Since then I've run into a wierd problem where qrunner appears to be looping on a message in the "out" queue. The message itself is a subscription confirmation from a nonexistent local user; apparently someone tried to subscribe and forgot to add the domain to their email address.
The only fix I've found so far is to manually stop qrunner, remove the offending .db and .pck file, and restart qrunner.
Make sure you local MTA correctly identifies the local user as bogus.
Postfix by default does not correctly identify a user as being missing and instead sends a lesser error indicating that the user is just temporarily unavailable.
Modify your MTA to report the bogus user correctly, then Mailman will not loop on that error. A check is being added to the next version so this will not be a problem in the future (though it is not Mailman's error).
Jon Carnes
On Tue, 2003-05-27 at 17:22, Gerald Combs wrote:
I recently upgraded from Mailman 2.0.8 to 2.1.2. Since then I've run into a wierd problem where qrunner appears to be looping on a message in the "out" queue. The message itself is a subscription confirmation from a nonexistent local user; apparently someone tried to subscribe and forgot to add the domain to their email address.
The only fix I've found so far is to manually stop qrunner, remove the offending .db and .pck file, and restart qrunner.
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
This message was sent to: jonc@nc.rr.com Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/jonc%40nc.rr.com
On 28 May 2003, Jon Carnes wrote:
Make sure you local MTA correctly identifies the local user as bogus.
Postfix by default does not correctly identify a user as being missing and instead sends a lesser error indicating that the user is just temporarily unavailable.
Modify your MTA to report the bogus user correctly, then Mailman will not loop on that error. A check is being added to the next version so this will not be a problem in the future (though it is not Mailman's error).
The setting in question appears to be "unknown_local_recipient_reject_code".
Postfix's main.cf has the following section:
# The unknown_local_recipient_reject_code specifies the SMTP server # response code when a recipient domain matches $mydestination or # $inet_interfaces, while $local_recipient_maps is non-empty and the # recipient address or address local-part is not found. # # The default setting is 550 (reject mail) but it is safer to start # with 450 (try again later) until you are certain that your # local_recipient_maps settings are OK. # #unknown_local_recipient_reject_code = 550
I migrated to a new server last week, and had it set to 450. After changing it to 550 it works as expected. Thanks for the help.
participants (3)
-
Gerald Combs -
Gerald Combs -
Jon Carnes