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

InReplyTo ArgumentException for a specific value #912

Closed
Nevca opened this issue Apr 11, 2023 · 3 comments
Closed

InReplyTo ArgumentException for a specific value #912

Nevca opened this issue Apr 11, 2023 · 3 comments
Labels
compatibility Compatibility with existing software

Comments

@Nevca
Copy link

Nevca commented Apr 11, 2023

Describe the bug
MimeMessage.InReplyTo calls MailboxAddress.TryParse and throws ArgumentException if it fails to parse the given value.

I can reproduce this with the following string:
[d7e8bc604f797c18ba8120250cbd8c04-JFBVALKQOJXWILKCJQZFA7CDNRQXE2LUPF6EIYLUMFGG643TPRCXQ32TNV2HA===@microsoft.com]

However, MimeMessage.References does not use MailboxAddress.TryParse, thus the same string is accepted and inserted in the references collection.

I also tested with the following code, and it is also working:
mimeMessage.Headers.Add(HeaderId.InReplyTo, "[d7e8bc604f797c18ba8120250cbd8c04-JFBVALKQOJXWILKCJQZFA7CDNRQXE2LUPF6EIYLUMFGG643TPRCXQ32TNV2HA===@microsoft.com]")

I'm somewhat confused which is the correct behavior. Shouldn't all three either throw or do not, given the same input string?

Which code should I use if I accept the example string as valid? Or should I trim the invalid characters? Is there a Util class or something I could use for trimming?

@jstedfast jstedfast added the compatibility Compatibility with existing software label Apr 11, 2023
@jstedfast
Copy link
Owner

MimeKit was designed to be strict in what it will send (which requires strictness in what it would accept as values for message.InReplyTo = ..., etc) but relaxed in what it would accept (e.g. MimeMessage.Load).

Over time, I've had to dumb down the message-id parser(s) that are used for various property setters because of the need to be able to reply to messages with garbage message-ids (presumably like in your situation).

It looks like I need to do the same for the InReplyTo property setter.

jstedfast added a commit that referenced this issue Apr 15, 2023
These properties now use ParseUtils.TryParseMesgId() which is more lenient in
what it accepts which is needed if/when a reply is being constructed for a
message with a syntactically incorrect Message-ID.

Also fixed ParseUtils.TryParseMsgId() to handle Message-Id's like:

    <[[email protected]]>

Fixes issue #912
@Nevca
Copy link
Author

Nevca commented May 3, 2023

Thank you.

@jstedfast
Copy link
Owner

You're welcome 🙏

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

No branches or pull requests

2 participants