Apple joins the webmail hall of shame
Selected headers of a just-received advance fee fraud:
Received: from smtpout.mac.com ([22.214.171.124]) by <redacted> ... Received: from mac.com (webmail11-en1 [10.13.10.117]) by ...; Sat, 8 Apr 2006 03:01:49 -0700 (PDT) From: JOHAN CAMPHER <firstname.lastname@example.org> To: JOHAN CAMPHER <email@example.com> Subject: I AWAIT YOUR RESPONSE X-Originating-IP: 126.96.36.199/instID=151
I don't have much to say that I didn't already say when Demon Internet joined the webmail hall of shame, so I'll just refer people to that entry.
(I'm not sure if Apple's .Mac stuff offers genuinely free webmail, but
their FAQ says that they have at
least a 60 day free trial. And when they call a machine
I take them at their word.)
A common socket programming mistake: not handling short IO
With normal file IO, when you do do '
read(fd, buf, len)' you'll almost
always get back
len bytes unless you hit EOF or a disk IO error. This
breeds a certain sloppyness when filling buffers; an awful lot of code
effectively ignores the return value of
read() except to check it for
This can and will bite you on the rear when writing socket code, because networks only give you so much data at once. Short reads are routine for socket IO; you can't assume that you can get all of what you want in a single read.
The mistake is especially pernicious because the mistaken code almost always works. Usually the lines or transactions you're reading from the network are small; usually you test on a fast local network. Speaking from personal experience, it's easy to forget this and then not notice.
(Today's case was some of my code that assumed it could read all of
POST body in one
Whether or not a normal (blocking)
write() has similar issues is
probably system dependent. Linux seems to only return from a socket
write() once all data has been pushed out, but I don't know what
other systems do in practice.