From: Frederic M. <fre...@wo...> - 2007-09-07 14:49:21
|
David Nash a écrit : > We've been using fetchmail for a few years, but recently noticed that there was a delay of up to 20minutes in receiving messages sent to us from an external email address. We're using a POP3 multidrop mailbox, and fetchmail passes the retrieved mail to Trestlemail MDA which then drops messages into the correct user's inbox. It's all worked fine 'til now. > > I logged on to our domain's webmail service, and noticed that our multidrop inbox had a few thousand messages in it. I don't think this used to happen, but they've started to collect there. I cleaned them out, and we started to receive external mail instantaneously (obviously fetchmail was taking time to parse the thousands of messages). > I encounter that problem from time to time. In my case, it always occurs after a broken connection. What happens is that fetchmail starts retrieving the mails and marks them for deletion as soon as they are delivered to the MDA. Then, at some point, the connection break (usually a timeout) and the server assumes that it should not delete the mails that were marked so (it is the expected behaviour). When fetchmail starts the next poll, it sees all the old messages and do not download nor delete them again. Instead it leaves them on the server. > > When new mail hits the multi-drop mailbox, its status is 'unread'. When fetchmail downloads from the multidrop, the mail is removed from the multidrop mailbox, with the exception of some messages where the status changes to 'read' but it is not downloaded. These are the ones that are building up. Some of the recipients are genuine users on our system, but many are not. From what I've been able to monitor, all these messages are SPAM. I've looked at the headers, and they seem to be pretty much the same as genuine messages, but they have X-IMAIL-SPAM-xxx lines in their header, eg X-IMAIL-SPAM-VALFROM. > > After all that explanation, I just wondered if fetchmail is looking at these header lines and choosing not to download the messages? > No header filtering that I'm aware of. > > I'm probably going to look at the 'flush' parameter to automatically delete them, once I've monitored it for a wee while to make sure that every message affected is genuinely SPAM. I don't really want to change fetchmail versions if I can help it! > You cannot assumes they are all spams but you may assume they were all delivered some time in the past. When I notice that a lot of mails are left on the server, I just turn the 'flush' option on for one poll and then I disable it for normal usage. To reduce the likelihood of leaving a lot of mails on the server if the connection break late in the transaction, I set fetchlimit to 500 mails. With that option, fetchmail closes the POP3 connection after retrieving 500 mails and the server deletes at least those mails. Frederic |