search

emersion / go-message

✉️ A streaming Go library for the Internet Message Format and mail messages
MIT License
382 stars 111 forks source link

MIME-Version header key casing #165

Closed cocoliliace closed 1 year ago

cocoliliace commented 1 year ago

The casing for Mime-Version, Content-Id, and Message-Id in RFC 2045 appear to be MIME-Version, Content-ID, and Message-ID. The header keys are currently being processed by textproto.CanonicalMIMEHeaderKey, which produces the former casing. The upstream said that they will not change it, so I propose that we change go-message, or add the option to use the RFC 2045 convention.

A discussion from another project suggested adding a wrapper to textproto.CanonicalMIMEHeaderKey in go-message, and replacing calls to textproto.CanonicalMIMEHeaderKey with the wrapper, if I understood it correctly.

emersion commented 1 year ago

What is the motivation for this? Why is the case-mapping important to you?

Consumers must process header field names in a case-insensitive manner.

If this is purely cosmetic, I'd rather not make go-message more complicated.

cocoliliace commented 1 year ago

My email provider (migadu) automatically converts the Mime-Version in my outgoing emails to MIME-Version. This messes up all my GPG-signed emails, since the signature is made with Mime-Version in the content, but the received email has MIME-Version.

emersion commented 1 year ago

This sounds like a Migadu bug. Even if we change it to MIME-Version, this may break another provider may convert the casing to the other way around. I'd suggest getting in touch with Migadu support.

cocoliliace commented 1 year ago

I've reached out. Thank you for the help.

rockorager commented 1 year ago

This came up on IRC today too, and the user was able to send me a message encrypted with neomutt through migadu. After looking at the differences, I found that aerc has MIME-Version in the body part (which is included in the signed content) while neomutt has it at the top level. I checked the RFC2045 and it does state:

Note that the MIME-Version header field is required at the top level of a message. It is not required for each body part of a multipart entity.

So, this turns out to be an aerc bug. I'll send in a patch to the aerc mailing list for it.