Error: cannot parse header "To" when trying to read an email

[onguntoglu]

Issue

I get the following error message when I try to read an email:

$ himalaya read 4499
Error: cannot parse header "To"

Caused by:
    Invalid address found: must contain a '@' symbol

I looked into it, oddly I can read any email that,

• was not directly sent to me (for example it was sent to a mailing list, which directed the email to my mailbox, and the header To does not have my email address in it)
• any email that is sent to an alias, which directs the email to my mailbox (header To is the alias)

Possible cause

Header To of unreadable emails should contain my name and the email address, but my name is not correctly displayed or parsed. I used Mozilla Thunderbird to view the source.

=?iso-8859-1?Q?Lastname=2C_Firstname?= firstname.lastname@provider.de

German umlauts could be the problem here, since my first name is displayed correctly, which doesn't have umlauts, and the last name is with umlauts and is not displayed correctly.

@soywod I can send you the actual header privately if you need that.

I looked at the code, there might not be too much to do about it, apart from opening an issue at https://github.com/staktrace/mailparse

Thanks for the great project!

[soywod]

It is not the first issue related to headers parsing, especially addresses (see #401, #380, #369). Starting from Septembre I will be able to dedicate half of my time to the project (see #399), I plan to git rid of all those errors (either by submitting PRs to the mailparse crate or by creating my own parser, at least for headers). Thank you for your detailed issue! You can send me the email or the headers by email if you want.

[soywod]

I dig a bit into this issue and it looks slightly different from the others. Just to confirm: you get the error Invalid address found: must contain a '@' symbol when the To header points to an alias or sth that does not contain a real address? I checked a bit the RFC, and it looks like the @ is mandatory:

addr-spec = local-part "@" domain ; global address

So I'm not so sure how to deal with this. It's not the first time that the theory (RFCs) impose sth that providers do not apply in practice :disappointed: any suggestion?

About the german umlauts, it should be fixed since the last release v0.6.0. Let me know!

[onguntoglu]

Hi thank you for coming back to this! The error message changed, this is on 0.6.1:

Error: cannot parse To value: Türkcüoglu, Ongun <ongun.tuerkcueoglu@web-site.de>

Caused by:
    Invalid address found: must contain a '@' symbol

AFAIK, the < and > should be not invalidate the header, or should it? It looks like the umlauts are not the problem this time. The actual email-address also has a dash in it.

[soywod]

The name part of the address is supposed to be wrapped with double quotes (from the RFC), which makes this address invalid (hence the error). The real question is which strategy to use when sth does not match the RFC? It's not the first time someone reports an error because of emails not respecting the RFCs. Should I drop warnings instead and use a String fallback? What is your opinion?

[soywod]

Maybe Himalaya does not need to be so strict, it could just keep strings around. It would remove a lot of complexity and a lot of bugs related to parsing. I will play a bit with this idea to see how far it can go.

[onguntoglu]

I might be completely off the track, but that RFC seems to be obsoleted by [RFC #2822](https://datatracker.ietf.org/doc/html/rfc2822#section-4, which seems to be allowing (Page 23) <>.

But in any case flexibility could be nice, maybe toggle-able and opt-in? Some people might want/need to have that check.

[soywod]

This issue will be fixed by #433 (it should be merged in the nearest days), feel free to reopen the issue on the new bug tracker!