[Mailman-Users] mailman is very slow...

[Troy Campbell]

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:mark at msapiro.net] 
Sent: Monday, September 27, 2010 4:54 AM
To: Troy Campbell; mailman-users at python.org
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 <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan