-
Notifications
You must be signed in to change notification settings - Fork 15
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
Display name with '|' character not parsed #19
Comments
Is that a valid RFC2822 email even? Can you point to a test case where this is parsable? I suppose the rules could be relaxed a bit, I think the Example | Example part technically needs to be in double quotes "Example | Example", although I may be wrong. |
Putting it in quotes does make it parseable, I'm trailing through RFC 5322 to check whether putting the display name in quotes is mandatory, it's not the most approachable of documents though. |
So as far as I can tell the "|" is valid according to RFC 5322, but according to wikipedia it's not: https://en.wikipedia.org/wiki/Email_address
I need to dig a bit more. |
@postme did you find anything in your searches? |
I would venture that the authorative source is RFC 5322. This states the following in paragraph 3.4: name-addr = [display-name] angle-addr So deriving from this chain of definitions the "|" character is explicitly allowed in display name. Next question is whether the display name needs to be quoted to be valid. 3.2.4 states "Strings of characters that include characters other than those allowed in atoms can be represented in a quoted string format" It follows from this that characters that are allowed in atoms dont need to be quoted. It could even be argued that special characters dont need to be quoted either as conveyed via the word "CAN" rather than "MUST". Based on this reasoning I would posit that |
$sendingDomain =
$sendingAddress = @
Stripping out the '|' character before parsing resolves the issue.
The text was updated successfully, but these errors were encountered: