Errors in address format processing without white space

Question

Errors in address format processing without white space

rudyeeee opened this issue 6 years ago · comments

What I did:

...
From: "=?UTF-8?B?7ZWc6rWt642w7J207YSw7KeE7Z2l7JuQ?="<kodb_pr@kdata.or.kr>
...

The following problem occurred during testing with the eml file containing the above sender.

When testing with the same data,
using the mail package's mail.ParseAddressList(m.GetHeader("From")) works correctly,
but when using Envelope.AddressList("From"), a mail: no angle-addr error occurs.

What I expected:
([]*Mail.Address) returned without error,

What I got:
returned error
mail: no angle-addr

Release or branch I am using:
both v0.5.0 and master

(Please attach a sample message if you feel it will help reproduce the issue)

Neil commented 6 years ago

👍

rudyeeee · Answer 1 · Tue Dec 18 2018 09:46:01 GMT+0800 (China Standard Time)

The address part(<kodb_pr@kdata.or.kr>) disappears after passing through decodeToUTF8Base64Header() in AddressList().

If the while space rune does not exist between the name part and the address part, the problem seems to occur.

// original
fmt.Println(decodeToUTF8Base64Header("\"=?UTF-8?B?7ZWc6rWt642w7J207YSw7KeE7Z2l7JuQ?=\"<kodb_pr@kdata.or.kr>"))

-> =?UTF-8?b?Iu2VnOq1reuNsOydtO2EsOynhO2dpeybkCI8a29kYl9wckBrZGF0YS5vci5r?= =?UTF-8?b?cj4=?=

// Including white space
fmt.Println(decodeToUTF8Base64Header("\"=?UTF-8?B?7ZWc6rWt642w7J207YSw7KeE7Z2l7JuQ?=\" <kodb_pr@kdata.or.kr>"))

-> =?UTF-8?b?Iu2VnOq1reuNsOydtO2EsOynhO2dpeybkCI=?= <kodb_pr@kdata.or.kr>

James Hillyerd · Answer 2 · Wed Dec 19 2018 12:08:54 GMT+0800 (China Standard Time)

Thanks, definitely sounds like a bug. Or at least too strict application of RFC

Neil · Answer 3 · Wed Dec 19 2018 21:00:46 GMT+0800 (China Standard Time)

I'll take a look today

…

On Tue, Dec 18, 2018, 11:08 PM James Hillyerd ***@***.*** wrote: Thanks, definitely sounds like a bug. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#112 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANlVUgTxVJb3Evtdvj6QYLfkJg5aN69Vks5u6bvXgaJpZM4ZXcIs> .

James Hillyerd · Answer 4 · Thu Dec 20 2018 00:07:12 GMT+0800 (China Standard Time)

If easy, we may also want to add a warning to the Errors list. Not essential.

Neil · Answer 5 · Tue Jan 22 2019 03:25:56 GMT+0800 (China Standard Time)

Just wanted to provide some feedback on this issue. Since this issue was raise for a quoted RFC2047 base64 encoded display name, I was able to provide a break fix. If the it was not a quoted RFC2047 base64 encoded display name, then we would need to refactor the decodeToUTF8Base64Header completely:

Currently we depend on the whiteSpaceRune separator for splitting the header into tokens.
The stdlib iterates through the string, rune-by-rune, with a switch case to determine the beginning and end of each token. When it expects a whitespace, strings.TrimLeft(s, " \t") gets run, then proceeds to ingest the next expected token.

Should we go the route of the stdlib, I will need to call on @dcormier for his experience with rune-based iteration tokenizers

Neil · Answer 6 · Sat Jan 26 2019 04:10:36 GMT+0800 (China Standard Time)

@derktam Could you please confirm if your issue is now resolved using the latest develop branch?

rudyeeee · Answer 7 · Thu Jan 31 2019 12:39:20 GMT+0800 (China Standard Time)

As a result of testing with develop branch,
It seems to have been resolved. Thank you :)