Tuesday, 01 June, 2004
Weird email messages
Jeff Duntemann mentioned in his Web diary post for May 30 that we'd been puzzling over some strange email messages we've both been receiving. These messages have none of the standard header fields beyond the tracing information (i.e. the "Received:" lines): no subject, no to field, no from field, and no message body. I've been seeing these on and off for a few months now, but they seem to be getting more prevalent. For a while I thought it was malfunctioning SMTP or POP servers because I figured the specifications wouldn't allow such a message to be passed. I was wrong. SMTP servers are quite happy to pass on empty messages. As it turns out, SMTP servers don't need any of the message header information in order to accept and deliver a message. Everything they need to get a simple message across is supplied by the MAIL FROM and RCPT TO commands to the server. I was able to send myself one of these blank messages, although I won't say how it's done. Read RFC2821 and figure it out for yourself if you're so inclined.
One other thing to note is that the original messages could have contained some text in the message body, but the resulting message is badly formed (not conforming to RFC2822). Mail clients barf when trying to parse the message. I connected to my POP server with telnet to examine one of my test messages and found that the body text is placed in the wrong position; immediately after the headers without the intervening blank line that's required by the specification. I have to wonder if this is a feature of the spec or a bug in some server implementations.
The more interesting question is the source of these messages. Who would send badly formed email messages? I'd suspect a denial of service attack, except that a dozen or so messages per week hardly represents an "attack" in my book. My best guess is a malfunctioning home-grown mail program, most likely a spam utility, but without more information it's hard to say. I do find it odd, though, that a spam utility would relay through the spammer's SMTP server rather than connecting directly to the target SMTP server. I can show that this happens by examining the tracing information in the message.