Open Chrisjow opened 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.
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.
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.
Thanks!