-
Notifications
You must be signed in to change notification settings - Fork 530
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
=?UTF-8?Q? in e-mail headers #2923
Comments
It seems it determines encoding here: https://github.com/laminas/laminas-mail/blob/2.25.1/src/Header/Subject.php#L105. As encoding set to UTF-8 it will encode the header. If we remove setEncoding, not sure if everything will work fine. We would need a lot of testing. Can't do it soon. Maybe only after v8.1 release. Any help appreciated.
Not sure if it's true. |
Related: laminas/laminas-mail#54 |
I tried w/o setEncoding and it failed to send when met UTF-8 characters in the From Name, requiring explicitly set UTF-8 for the 'from' header. This should be the same for any address-line header and maybe for some other headers too. The subject header is fine as the implementation detects UTF-8. This means that to fix it we would need to check encoding for each header manually, not relying on the laminas-mail. Not sure whether I would like having this logic. Currently I'm not determined that this issue should be considered as a problem. But I may change my mind. |
We noticed the behavior when quite a few e-mails had not been delivered. Below is one example that lead me to believe that the e-mail is not following proper standards. Additionally my Android with K9-Mail does not properly display the sender in notification, can't recreate it now for a screenshot though. host mx01.emig.gmx.net [212.227.17.5] said: Transaction failed Reject due to policy restrictions. For explanation visit |
So I found out:
Possible solutions:
Recommendation: |
So basically we have another problem which is more significant, that not all characters are properly mime encoded that may result in delivery problems with some providers. |
Describe the bug
When sending e-mails, Espo is adding =?UTF-8?Q? and other non-printable characters into 'From' and 'Subject' fields of the header.
To Reproduce
Expected behavior
The e-mail header fields from and subject should contain plain characters as long as no special non-utf8/ascii characters have been entered by the user.
Actual behavior
Screenshots
E-Mail addresses have been hidden. They are correct though and do not contain faulty characters.
'from name' has been set
no 'from name' has been set
EspoCRM version
8.0.4
Additional context
I have replied to another user in the forum who seems to have the same issue but I think my post there might not be very visible. https://forum.espocrm.com/forum/general/78024-cryptic-from-sender-in-e-mails
I think the words have somehow been double or unnecessarily encoded. This will trigger some spam guards as this technique is sometimes used by spammers. If I understand correctly (but please don't quote me on it ), the email currently does not follow strict RFC5322 standards https://datatracker.ietf.org/doc/html/rfc5322#section-3.4
An improvement might be to only perform the current encoding if non-standard-ASCII characters are encountered.
A few possibly useful links:
https://security.stackexchange.com/a/213477
https://stackoverflow.com/a/55210089
I think the issue might occur here (haven't debugged yet though) https://github.com/espocrm/espocrm/blob/master/application/Espo/Core/Mail/Sender.php#L569
The text was updated successfully, but these errors were encountered: