failing test for from header parser containing an additional @

[kant01ne]

Hello,

Here is a failing test when the sender name contains an @:

  1) test parses utf-8 encoded from (Mail.Parsers.RFC2822Test)
     test/mail/parsers/rfc_2822_test.exs:421
     Assertion with == failed
     code:  assert message.headers["from"] == {"me@examp...", "<[email protected]>"}
     left:  "me@examp..."
     right: {"me@examp...", "<[email protected]>"}
     stacktrace:
       test/mail/parsers/rfc_2822_test.exs:427: (test)

[andrewtimberlake]

Hi @kant01ne

That would be an invalid From header. To be valid, the name should be in quotes.
This test, with a valid quoted recipient, passes correctly:

test "parses utf-8 encoded from" do
  message =
    parse_email("""
    From: "me@examp..." <[email protected]>
    """)

  assert message.headers["from"] == {"me@examp...", "[email protected]"}
end

[andrewtimberlake]

Note: the expected result would not have the angular brackets.

[kant01ne]

Interesting. The original was an UTF8 encoded from a google comment. Could it be the source of the issue ?

From: =?UTF-8?B?am9obi5kb2VAcmVkYWN0ZS4uLg==?= <[email protected]>

[andrewtimberlake]

That gets decoded as john.doe.redacte... <[email protected]> which is still correct

[kant01ne]

Arf, forgive me, the previous value comes from some tests I've done. I've updated the comment and I've updated the UTF8 encoded value in the tests to john.doe@redacte....

1) test parses utf-8 encoded from (Mail.Parsers.RFC2822Test)
     test/mail/parsers/rfc_2822_test.exs:421
     Assertion with == failed
     code:  assert message.headers["from"] == {"john.doe@redacte...", "<[email protected]>"}
     left:  "john.doe@redacte..."
     right: {"john.doe@redacte...", "<[email protected]>"}
     stacktrace:
       test/mail/parsers/rfc_2822_test.exs:427: (test)

[andrewtimberlake]

Hi @kant01ne, It turns out that we are decoding quoted words too early. RFC 2047 §6.2 specifically states that you cannot decode a header and then guarantee it parses to RFC822

NOTE: Decoding and display of encoded-words occurs after a
structured field body is parsed into tokens. It is therefore
possible to hide 'special' characters in encoded-words which, when
displayed, will be indistinguishable from 'special' characters in the
surrounding text. For this and other reasons, it is NOT generally
possible to translate a message header containing 'encoded-word's to
an unencoded form which can be parsed by an RFC 822 mail reader.

I’ll work on a fix. Thanks for reporting this.