Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

message::parse_many_ids() fails to parse ID lists without spaces #47

Closed
tsilia opened this issue Dec 23, 2020 · 1 comment · Fixed by #53
Closed

message::parse_many_ids() fails to parse ID lists without spaces #47

tsilia opened this issue Dec 23, 2020 · 1 comment · Fixed by #53

Comments

@tsilia
Copy link
Contributor

tsilia commented Dec 23, 2020

Hello.
I have run into an issue: message::parse_many_ids() can't parse ID strings which don't contain a space separator, like this one:
<029601d56c86$60e6e5e0$22b4b1a0$@mail.ru><02d901d56c96$89591ab0$9c0b5010$@mail.ru><114a0364-0ff7-f9ca-942a-3f58e45be343@otherdomain.tld>

It's a great library which implements almost all features I need, but right now it's not possible for me to fetch some e-mails due to an exception thrown: Parsing failure of the message ID. Thunderbird fetches such messages successfully.

Please, is there anything you could do to support such space-lacking ID lists as this seems to be a common misbehaviour of mail servers?

I've read another issue (#7) and saw you mentioned 'strict' mode which can be turned off to lift some restrictions. I did so and it didn't resolve the issue. I guess, this doesn't apply to parsing ID lists. Could you please extend the non-strict mode to ID lists?
Thank you.

@karastojko
Copy link
Owner

karastojko commented Dec 28, 2020

RFC 5322 section claims that IDs may be separated by one or more whitespaces. Thus, there is no need for the strict mode in this case, it has to work always. Check the PR55.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants