Interestingly I have the unknown_local_recipient_reject_code = 550
in my postfix configuration file so I'll have to investigate why that's not working. There were several pid lockfiles on the list of which one looks like it still had a pid related to it so I kept it and removed the others. Thanks again for your valuable support, Troy -----Original Message----- From: Mark Sapiro [mailto:[email protected]] Sent: Monday, September 27, 2010 4:54 AM To: Troy Campbell; [email protected] Subject: RE: [Mailman-Users] mailman is very slow... Troy Campbell wrote: > >I've got a little more information. I noticed that there was a lot of >"deferred" postfix connections. When I dumped out the deferred queue >using "postqueue -p | more" and then looked an an individual using >"postcat -q 677F0FE66" for example, then I see someone is trying over >and over again to send an email to a non-existent list and then the list >server is replying back and getting a "connection refused" and putting >that on the "deferred" queue. Is there an easy way to send the incoming >request to the non-existent queue to /dev/null until I can get a hold of >the admin of the server sending me this? I'm tempted to create the list >that they are trying to reach and then add a member translated to >/dev/null in postfix but wondering if there might be even an easier way? This is entirely a Postfix issue. If mail is sent to a non-existent list, Postfix should refuse the mail at incoming SMTP time. You may need unknown_local_recipient_reject_code = 550 in Postfix main.cf. If any case, Mailman should not be involved no matter what, even if Postfix is responding with a 450. What is Postfix's method of delivery to Mailman? Why is mail for a non-existent list being responded to at all? >The "in" directory went empty soon after I created the "null" list (just >didn't add any members)..didn't even have to stop mailman. OK, but something is wrong as Mailman shouldn't be involved with mail to a non-existent list any more than any non-existent user. >I'm looking >at the "archive" directory now trying to figure out why those files are >there. It looks like it's one list over and over (different one than >what was generating the "deferred" above). Is there anything to look at >in particular in the message. Why are they ending up here? They are messages that have been posted to a list and are queued to be added to the list's archive. >Side note, >it's kind of odd I can't get into the list through the Web interface >using the site password but can see its contents using the command line. >I wonder if the list is corrupt somehow and should be recreated? The list may be locked. See the FAQ at <http://wiki.list.org/x/noA9>. What happens for an attempted web access? What's in Mailman's 'error', 'qrunner' and 'locks' logs? -- Mark Sapiro <[email protected]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
