3 ms·

Two off the top of my head: * A classic would be IE's abuse of TCP RST: http://www.stroppykitten.com/cms/index.php?option=com_content&view=article&id=2:interne

Two off the top of my head: * A classic would be IE's abuse of TCP RST: http://www.stroppykitten.com/cms/index.php?option=com_content&view=article&id=2:internet-explorer-and-tcp-rst-a-reason-to-dislike&catid=1:tech&Itemid=2 http://www.stroppykitten.com/cms/index.php?option=com_conten... * A decent chunk of email server code (SMTP & IMAP implementations in particular) is there to handle erroneous client behaviours. The worst cases are those where the workaround leads to misbehaviours (or less optimal behaviours) for conforming clients. If I remember correctly, the popular Outlook series of clients is a notorious source of such warts. A number of SMTP sender libraries will skip over significant parts of the protocol state machine; configuring a mail server to handle that degenerate case can weaken its anti-spam provisions.

mattmanser 14y ago
Yes, there were major changes between the way IMAP worked in Outlook 2003 & Outlook 2007 too, I think they re-wrote their IMAP code as it behaved completely differently. Admittedly it was much better, but it broke our custom IMAP server which I ended up fixing. I can't remember exactly why now, but Outlook 2003's implementation was bizarre, as if they'd not read the RFC. That reminds me of the bizarre big because they used a short uint to store the message UID. Maybe it wasn't a short but it definitely wasn't 32-bit as per the spec, there was some magic number that if you went over 'boom'. As an end user it appeared that some messages just disappeared.
danielweber 14y ago
POP3 is no picnic, either. Outlook seems to want care about the last-used UIDL. And, to make things more confusing, the RFC is a little vague about the re-use of UIDLs.