RFC2047 encoded-words as content-transfer-encoding value

[jameshoulahan]

There exist messages in the wild (notably, some originating from mailbox.org's automated mailer e.g. due to payments) in which the content-transfer-encoding presents as an RFC2047 encoded-word. For instance, here is a (redacted) example:

To: user@mailbox.org
MIME-Version: 1.0
Content-Type: text/plain;
 charset="utf-8"
Content-Transfer-Encoding: =?utf-8?Q?8bit?=
From: =?utf-8?Q?mailbox.org?= <noreply@mailbox.org>

Lieber Kunde,

... stuff in german ...

go-message cannot handle such messages.

One "hacky" solution is to simply pass the encoded word through the header decoder, as in this patch:

diff --git a/entity.go b/entity.go
index 99e69c8..fe13d91 100644
--- a/entity.go
+++ b/entity.go
@@ -35,8 +35,9 @@ func New(header Header, body io.Reader) (*Entity, error) {
  // e.g. "quoted-printable". So we just ignore it for multipart.
  // See https://github.com/emersion/go-message/issues/48
  if !strings.HasPrefix(mediaType, "multipart/") {
-   enc := header.Get("Content-Transfer-Encoding")
-   if decoded, encErr := encodingReader(enc, body); encErr != nil {
+   if enc, decErr := decodeHeader(header.Get("Content-Transfer-Encoding")); decErr != nil {
+     err = UnknownEncodingError{decErr}
+   } else if decoded, encErr := encodingReader(enc, body); encErr != nil {
      err = UnknownEncodingError{encErr}
    } else {
      body = decoded

[brunnre8]

If I understood the RFC2047/2045 correctly that's invalid for the Content-Transfer-Encoding header... that has a limited set of possible values and must not be encoded

[jameshoulahan]

Yes, it's invalid, but unfortunately, messages in the wild still put encoded words there. I don't think adding a decoding step here is a problem.

I think in this case, making this change increases usability without reducing correctness, as I can't think of a way this would lead to incorrectly parsed messages.

[emersion]

Have you reached out to mailbox.org to let them know about the issue?

[jameshoulahan]

No. And I haven't been able to reproduce it with newer messages, only ones from last year. Chances are they fixed it already.

[jameshoulahan]

@emersion are you opposed to making such a change to your library?

[emersion]

In this particular case, users can trivially ignore the UnknownEncodingError, so I think I'd rather not add this quirk.