Interesting bug today: A client’s web form takes file uploads and forwards them as email attachments. Script works great for .doc files, but .docx files end up as mysterious attachments with filenames like ATT00010.txt, whose content starts with this:
application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="filename.docx" Content-Disposition: attachment; filename="filename.docx" Content-Transfer-Encoding: base64
This “header” is followed by a bunch of base64 gobbledygook. In short, my original attachment appeared to be getting itself wrapped in an attachment, prefixed with its headers minus the string “Content-Type: “.
Turns out the problem was line-wrapping. I was hardwrapping the entire message to ensure a maximum line length of 70 characters (as recommended by the docs), and this was causing the obscenely long (> 70 character) mime type used by .docx to wrap onto a separate line from the string “Content-Type:”. Subsequently, Outlook was seeing a blank content type, freaking out, and putting the rest of the message into an attachment.
Moral of the story: Don’t hardwrap your email headers. Or use a library which keeps you from worrying about absurd implementational details.