I’ve been able to filter attachments, using the multipart definition in RFC 1341. I’ve implemented it like this, in a quite rudimentary manner.

1. If the message flags indicate that the message has an attachment, I’ll look for the first “\r\nContent-Type: ” header. Immediately following it will be a “boundary=” line, after which comes the multipart boundary (this may or may not be in quotes). A sample message (generated by Tb itself) has this:

   Content-Type: multipart/mixed;
    boundary="------------070607000408050100040102"

2. I extract the boundary, and trim whitespace and remove quotes.
3. I look for the first occurrence of the boundary, ignore it, look for the second occurrence, and remove that and everything ahead of it. (The first part is the juicy part, of course.)
4. I add the end boundary marker with surrounding CRLFs, as specified in the RFC.

UPDATE May 8: nsIMimeHeaders and nsIMIMEHeaderParam do the job in a cleaner and more RFC-compliant manner. This seems to be working for the most common type, multipart/mixed, where the first part contains the actual email. However, there are several other multipart subtypes. Out of these, I think only multipart/digest might be a problem (is it even used/supported by Thunderbird today?) Another potential concern is non-English messages (Unicode/codepages). I don’t think they should be a problem, given that we are dealing with “normal” 7-bit characters in the boundary. I also noticed some bugs in the current implementation while testing out changes.

• Drafts, once edited, aren’t re-written.
• Messages removed from trash don’t have their correspnding files deleted.
• Messages aren’t written as soon as they are saved as drafts. They have to be opened before the file is written.