jackbearheart / email-addresses

An RFC 5322 email address parser
MIT License
249 stars 36 forks source link

Bracketing not supported #52

Open Chrisjow opened 4 years ago

Chrisjow commented 4 years ago

Hi,

I am using the 'email-addresses' package in order to parse incoming emails senders. However, sometimes I get something like "JOHN DOE[XXX - DOE John] john.doe@gmail.com". The functions parseOneAddress() and parseAddressList() both return null (image below).

Would be nice to accept this kind of format.

image

Thanks!

jackbearheart commented 4 years ago

Hi! To my understanding, the RFC rules don't allow this format as-is. (Getting technical, the fundamental reason is that the atext production in the spec doesn't include the [ or ] characters, so a non-quoted display name cannot include those. A quoted display name would, however.)

It would be valid if it were quoted, for example:

> addrs.parseAddressList('JOHN DOE <john.doe@gmail.com>') !== null;
true
> addrs.parseAddressList('JOHN DOE[XXX] <john.doe@gmail.com>') !== null;
false
> addrs.parseAddressList('"JOHN DOE[XXX]" <john.doe@gmail.com>') !== null;
true

So from the perspective of this library, which was created to parse email addresses according to this specification, this is expected.

Now, that doesn't solve your problem. In curiosity, I wonder, what is your use case, what outside system is sending you emails in this format, and under what circumstances or as part of what protocol? That will help us figure out if there's anything this library can help with in a sane way. If there is a relevant spec or this is a common format then we could provide an option to allow it.

Chrisjow commented 4 years ago

Hi, sorry for the delay.

I received an email with this format from a big corporate employee. So my use case is not really original. However, it's the only company that sends us this kind of format.

Hope it helps.