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

Parse of email with brackets on from header recover an empty field. #532

Closed
reinaldocoelho opened this issue Jan 16, 2020 · 9 comments
Closed
Labels
compatibility Compatibility with existing software

Comments

@reinaldocoelho
Copy link

reinaldocoelho commented Jan 16, 2020

Describe the bug
Using MimeMessage.Load(stream) on EML with FROM having format "[Matt] [email protected]", recover an blank From field to Message object.

Platform (please complete the following information):

  • OS: Windows
  • .NET Runtime: DotNet4.6.1, NetCore 2.1
  • .NET Framework: .Net Core, .NET 4.6.1
  • MimeKit Version: 2.4.1

To Reproduce
Steps to reproduce the behavior:

  1. Create an EML with code below.
  2. Simple parse the EML with Mimekit lib.
  3. Verify "From" field on "Message" object.
  4. Expected to see the email but has blank text.

Expected behavior
Expected to see the email on "From" field but has blank text.

Screenshots
MimeKit-CodeRunning-Pic
MimeKit-EML-Pic

Additional context

  1. EML used to test Bug:

`
To: [email protected]
Content-type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64
From: [Invalid Sender] [email protected]
Message-Id: [email protected]
Date: Thu, 9 Jan 2020 11:13:09 +0900 (JST)
Subject: =?UTF-8?B?VGVzdCBzdWJqZWN0IHRvIHZhbGlkYXRlIHByb2JsZW0=?=

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFsLy9FTiI+CjxodG1sPgo8aGVhZD4KICA8dGl0bGU+TkIxPC90aXRsZT4KPC9oZWFkPgo8Ym9keT4KCTxoMT4gVGl0bGUgdGVzdCA8L2gxPgoJPHA+VGhpcyBpcyBvbmx5IGEgc2ltcGxlIEhUTUwgYm9keSB0ZXN0LjwvcD4KPC9ib2R5Pgo8L2h0bWw+Cg==
`

@reinaldocoelho

This comment has been minimized.

@jstedfast
Copy link
Owner

If I am understanding rfc5322 correctly, the syntax is invalid:

   atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                       "!" / "#" /        ;  characters not including
                       "$" / "%" /        ;  specials.  Used for atoms.
                       "&" / "'" /
                       "*" / "+" /
                       "-" / "/" /
                       "=" / "?" /
                       "^" / "_" /
                       "`" / "{" /
                       "|" / "}" /
                       "~"

   atom            =   [CFWS] 1*atext [CFWS]

   specials        =   "(" / ")" /        ; Special characters that do
                       "<" / ">" /        ;  not appear in atext
                       "[" / "]" /
                       ":" / ";" /
                       "@" / "\" /
                       "," / "." /
                       DQUOTE

   mailbox         =   name-addr / addr-spec

   name-addr       =   [display-name] angle-addr

   display-name    =   phrase

   word            =   atom / quoted-string

   phrase          =   1*word / obs-phrase

   obs-phrase      =   word *(word / "." / CFWS)

We can see from the syntax definitions above that a phrase (the display-name component of a name-addr-style mailbox address) must either be an atom or a quoted-string and an atom clearly does not allow [ or ].

That said, I don't think there would be any negative consequences for allowing square bracket characters in the name in MimeKit's parser...

The only special meaning I can think of that make use of square brackets are domain-literal tokens which would not appear in any areas that could easily be confused with a "phrase atom".

jstedfast added a commit that referenced this issue Jan 16, 2020
@jstedfast
Copy link
Owner

Thanks for the bug report!

@jstedfast jstedfast added the compatibility Compatibility with existing software label Jan 16, 2020
@reinaldocoelho
Copy link
Author

But in this case, the "Name" in brackets may be invalid, but the address is normal.
If the "From" object has "Name" and "Address", the library should not display the "Name" field, but may display the "Address" field as a result.
Because if we look at the EML, the "From" exists and is understandable.
Is it the best behavior for the library during parse to remove all information because of an invalid character?
Wouldn't it be better to return information that is at least valid?

@jstedfast
Copy link
Owner

That's the goal. Most of the specials characters were handled when they were encountered in the display-name except square brackets which is what you hit. Now they are handled, too.

@reinaldocoelho
Copy link
Author

Cool, will you release a version to this?
The last version on Nuget is the same 2.4.1.

Thank you :-)

@jstedfast
Copy link
Owner

Yea, I'm hoping to have some free time this weekend (or maybe tonight) to make a release.

@thomas-westergard-scandinn-se
Copy link

thomas-westergard-scandinn-se commented Nov 1, 2020

works: var displayName = "Tom Doe [Corp One]";
works: var displayName = "Tom Doe Corp One";
works: var displayName = "Tom Doe Cörp Öne";
does NOT work: var displayName = "Tom Doe [Cörp Öne]";

var mimeMessage = new MimeMessage();

mimeMessage.From.Add(new MailboxAddress(displayName, emailAddress));

No exception when sending.

@jstedfast

@jstedfast
Copy link
Owner

@thomas-westergard-scandinn-se This bug is about parsing, not sending.

aTakuyaKaneko added a commit to access-company/MimeKit that referenced this issue Mar 5, 2021
----

commit ac26fa6
Author: Jeffrey Stedfast <[email protected]>
Date:   Thu Jan 16 16:44:53 2020 -0500

    Fixed mailbox address parser to be more lenient about []'s in the display-name

    Fixes issue jstedfast#532
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

3 participants