Monday, 5. December 2005

Yes, it's that time of year when people start sending out their annual email to everyone they know. This has
caused us problems in the past and seems set to do so again.
Some time earlier today, a sender in Germany sent a seasonal message to a list of 47 recipients *. One of those is using the infamous Microsoft POP3 fetch. Another is a user here who contacted the helpdesk a short while later to ask why he had received the same email 19 times (so far). For those of you unfamiliar with how this goes, here's what happened.
- The original message hits a POP mailbox being used (very unwisely) by one of the 47 recipients.
- The POP fetch being used is the usual broken Microsoft one.
- On receiving the message, the POP fetch breaks as it can't handle a large number of recipients in the message "To" field.
- Instead of delivering a single copy to the only local recipient, the POP fetch does so and queues a fresh copy for every recipient including the local one.
- This fresh copy preserves none of the original "Received" headers and looks like a locally originated message.
- It is now sent back out and every recipient of the message gets a fresh copy - including the POP mailbox being used for the broken POP fetch.
- POP fetch kicks in again and ... [goto 1]
So, the first sample this festive season but I expect there'll be more.
If one of your users starts to complain about multiple delivery of a message and that message includes a large number of recipients in the "To" field, you can kill the problem locally ** by listing the email address of the original sender in the server config field "Deny messages from the following internet addresses/domains:".
* Yes, it only takes 47 recipients to trigger the bug (a buffer overrun in case you hadn't guessed)
** This doesn't fix the problem, it just masks it from your victim user.
Category: Dumb and Dumber
Technorati: Dumb and Dumber