Message parser chocking on charset-encoded addresses

[xguerin]

Hello there!

The message parser is giving me the following error:

mailio::message_error: Parsing failure of address or group at `<`.

Thrown from message.cpp:716, because of the following sender address:

 =?windows-1252?Q?Action_fran=E7aise_?=<contact@actionfrancaise.net>

My initial intuition is that MIME header encodings are not supported, but I might very well be wrong. I'll do a bit more digging, but any guidance would be appreciated :)

Thanks,

[xguerin]

Ref: https://en.wikipedia.org/wiki/MIME#Encoded-Word

[karastojko]

Hello,
Thanks for trying mailio.

The issue is caused by missing space between the displayed name =?windows-1252?Q?Action_fran=E7aise_?= and the address itself <contact@actionfrancaise.net>. By RFC 5322 section 3.4 the space is required. If you add the missing space character in between, everything works fine.

However, I am aware that RFC requirement sometimes are too hard. There is so called strict mode which (when disabled) allows some of the mandatory requirements to be omitted. Unfortunately, the case with the address is not included. What I can do is take a look into the code and check if the fix can be made easily without breaking the existing functionality.

Also, the MIME formatter/parser recognizes only ASCII and UTF-8 formats of the address (i.e. the displayed name part). Other formats like Windows-1252 are not supported. Doing that would require dealing with various codecs, probably by using an external library.

Regards,

[xguerin]

Thanks for looking into this. If I am not mistaken, according to RFC2822 section 3.4 the white space (CFWS) between the display-name and the angle-addr is optional.

What I can do is take a look into the code and check if the fix can be made easily without breaking the existing functionality.

Thanks. Concurrently, I wanted to toy with lemon and ragel to see if I can replicate the grammar specified in the RFC faithfully. If I get something usable I'll submit a PR.

[karastojko]

Actually, the bug exists only when Q encoding is used for the displayed name. In the case Action francaise<contact@actionfrancaise.net> or "Action francaise"<contact@actionfrancaise.net> (no space between the displayed name and the left bracket) everything works fine. I will investigate this further and let you know.

[karastojko]

@xguerin Take a look of the latest commit, tagged with version_0-16-1 on the master branch. It allows parsing of the Q encoded name/address in the case when no space exists between the displayed name and the address. Internal tests (which are far from being perfect) look fine, no existing feature should be broken.

[xguerin]

Thanks ! That fixes it for that particular header.