Hello,
I've been trying to diagnose the cause of receiving multiple duplicate
messages delivered to the MDA (dovecot/deliver) from getmail (5.14). I
am using SimpleIMAPSSLRetriever, and launching getmail with --idle
INBOX. I have a Filter_classifier running ClamAV (0.101.4).
In the log file I was seeing a whole bunch of errors:
getmailOperationError error (IMAP error (socket error: [Errno 32] Broken
pipe))
After spending some time debugging, what I think is happening is as follows:
The message is downloaded successfully (getmail:200), and is then passed
on to the filter (:228). The filter was set up according to
http://pyropus.ca/software/getmail/faq.html#faq-integrating-clamav,
using the first example without the daemon. Running getmail with --trace
indicates that clamscan then takes rather a long time to run, for some
reason. This is a relatively recent issue, but I have not diagnosed why
clamscan would have started to take longer.
In any case, it's not getmail's problem, but what happens next could be
considered to be. The message is delivered (:240), but then when it
comes time to delete (:283) the process has spent so much time blocked
waiting for clamscan to return that the IMAP connection must have timed
out as it then raises the getmailOperationError with the broken pipe.
The end result is, an email successfully downloaded and delivered, but
then not deleted, and consequently re-downloaded and re-delivered again
and again until clamscan can execute quickly enough that the connection
doesn't get dropped while it's doing so.
For myself, I think I have an acceptable resolution by switching to
clamd and clamdscan, but I thought it was worth reporting my findings in
any case.
Perhaps getmail could detect the connection has dropped and re-open it?
Or issue NOOP's while waiting for a filter process to complete? If
nothing else, perhaps a warning against using clamscan or other
long-running process with IMAP retriever might be worth adding to the
FAQ document.
Regards,
Alex Vallat
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.