Hello,

with the current implementation, interface PartHeader is implemented as either InlineHeader or AttachmentHeader that both embed message.Header. And although it's not documented by the package, the wiki example implies that PartHeader will always be one of the two.

The logic to decide whether its AttachmentHeader or PartHeader,

if disp == "inline" || (disp != "attachment" && strings.HasPrefix(t, "text/")) {
    mp.Header = &InlineHeader{p.Header}
} else {
    mp.Header = &AttachmentHeader{p.Header}
}

unfortunately, doesn't always work for emails in the wild. E.g., I have a message with the following part header:

Content-Type: text/plain; name="emailreceipt_20121015R2315576090.pdf"
Content-Disposition: inline; filename=emailreceipt_20121015R2315576090.pdf

%PDF-1.4..%...

It's clearly a PDF attachment, but is currently classified as InlineHeader, so we cannot use AttachmentHeader.Filename to extract the filename.

To solve this problem, the user code can of course cast PartHeader as Header (which will succeed with the current implementation), and then effectively re-implement AttachmentHeader.Filename logic by perusing Header.ContentDisposition and Header.ContentType methods.

The alternative would be, at a minimum, to extend PartHeader interface to directly expose ContentDisposition and ContentType, which will help the user code that works with malformed parts. (If this indeed a desired direction, I'm happy to create a pull request).

Another alternative would be to improve the Inline vs Attachment logic, but it will probably be brittle as you cannot enumerate badness in the wild.

Thoughts?