James Kemp wrote:
Over the last couple of weeks I've noticed that a number of legitimate e-mails have failed to be delivered. All of these have been shunted and an error like the one repeated below is written to the error log.
[...]
Apr 17 21:22:28 2010 (2558) Uncaught runner exception: [Errno 104] Connection reset by peer [...] File "/var/lib/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/var/lib/mailman/Mailman/Handlers/SpamAssassin.py", line 76, in process score, symbols = check_message(mlist, str(msg)) File "/var/lib/mailman/Mailman/Handlers/SpamAssassin.py", line 62, in check_message res = connection.check(spamd.SYMBOLS, message) File "/var/lib/mailman/Mailman/Handlers/spamd.py", line 122, in check response = fp.readline() File "/usr/lib/python2.6/socket.py", line 406, in readline data = self._sock.recv(self._rbufsize) error: [Errno 104] Connection reset by peer
It appears that you (or someone) has installed the Spamassassin.py/spamd.py custom handler from <https://bugs.launchpad.net/mailman/+bug/557991> and included it in the GLOBAL_PIPELINE or a lists' pipeline.
The "Connection reset by peer" error is occurring while spamd.py is waiting for a response from the spamd daemon.
I suspect this is occurring because of a time out. Prior to SA 3.3, there was no limit on how long spamd could take to process a message. If there were DNS issues with RBL lookups for example, there could be very long delays. SA 3.3 has introduced a 300 second time limit, after which it just returns what it found plus a hit on the TIME_LIMIT_EXCEEDED rule. See <http://svn.apache.org/repos/asf/spamassassin/branches/3.3/build/announcement...>.
If you have SA 3.3, you could configure a shorter time_limit and see if that helps.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan