"Cryptic" From (Sender) in e-mails

[mfr]

Hello everyone,

it has now happened several times that e-mail recipients have wondered about a "cryptic" sender and for fear that it is malware that did not open the e-mail.

I have observed them in connection with mass emails, but I am not sure whether this is generally the case.

It is clear to me that this has to do with the Encodig UTF-8, but I have no idea how to correct this representation. It seems that the two "::" in the sender name are messing up the encoding.

I haven't seen the encoding for the header entries "Precendence" and "List-Unsubscribe" either. Is this encoded too much or is it a bug in the EspoCRM mail backend?

Regards Martin

[mfr]

Any hints?

[victor]

Hi mfr,

Most likely you had multiple usernames for your mailboxes from your provider (username or email address). In crm you need to use the email address as the username and then everything will be formatted correctly.

[jeff11]

Hi victor

Thank you for your input.

I am encountering the same issue, even when using the same 'username' as the 'from address'.

Additionally I have some more info:

1. The issue only affects the the sender's name when you set a 'from name'.
2. The issue seems to affect the subject as well (regardless whether 'from name' is filled or not)
3. The behavior does not depend on special characters in the 'from name'. Using a simple one like 'asd' also causes it, please see screenshots.
4. [not exactly an important issue, but noticed during testing] If you enter a 'from name' in outbound settings, then save, then reload the page, then delete the contents of the 'from name' field, then click 'Send Test Email', the system still sends the 'from name' you had before


'from name' has been set


no 'from name' has been set

I think the words have somehow been double or unnecessarily encoded. If I understand correctly (but please don't quote me on it ) This will trigger some spam guards as this technique is sometimes used by spammers and the email technically does not follow strict RFC5322 https://datatracker.ietf.org/doc/htm...22#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/b...ender.php#L569