On Mon, 4 Jan 2010, ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
Attempting to avoid such bugs on the client side is an exercise in futility,
due to the nature of TCP and IP underneath it. You cannot in general prevent
packet fragmenation, reassembly, rebuffering, and all sort of other
entertaining stuff from accurring, so your attempts to align your buffering to
accomodate a broken received that doesn't handle its buffers properly are
to fail - the only question is when, not if.
Ned's right, of course, though the SMTP specification is vague about
exactly what a "reliable ordered data stream" consists of.
For a real instance of "entertaining stuff", I once had fun diagnosing a
bug in a Fortigate firewall that attempted to do TCP resegmentation. I
wouldn't have noticed, except that it screwed up if the segment happened
to be (n*512)+1 bytes long, causing all but the first 512 bytes of the
segment to be lost, which in turn caused the occasional message to get
stuck on the queue.
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.