'From Email' setting shoud not add original name to the offline notification message

[Gummikavalier]

Description:

We've set 'From Email' setting to 'noreply@example.com' in under admin settings:

The recipient of offline notification message gets the email coming from (as in From: field) formed like this: Givenname Surname <noreply@example.com>

This is problematic because today many email clients learn and use the names from the envelope directly.

When there has been more emails received from this address to recipient than from the actual real contact Givenname Surname <givenname.surname@example.com> the clients start preferring noreply-address over the actual contact address when typing them in to To: or Cc: during the composition of new emails.

Also often clients are not set to show real address in their To and recipient fields at all, which causes even more confusion.

Steps to reproduce:

1. Set From Email address in under SMTP admin settings
2. Send a message to recipient in RC when the recipient is offline

Expected behavior:

The recipient gets an email coming just from noreply@example.com as in specified in the setting.

Actual behavior:

The recipient gets an email coming from the author called Givenname Surname <noreply@example.com>. Many email clients show this only as Givenname Surname, and also start preferring noreply-address over the real one.

Server Setup Information:

• Version of Rocket.Chat Server: 3.9.1
• Operating System: CentOS 7
• Deployment Method: tar
• Number of Running Instances: 20
• DB Replicaset Oplog: Yes
• NodeJS Version: 12.18.4
• MongoDB Version: 3.6

Additional context

Unfortunately not using 'From Email' option is not a good one either. Rocket.Chat systems may have users from multiple independent mail domains (via Oauth etc. user federation services).

Today forging any sender domains into emails with SPF/DKIM signing and other assorted anti-spam technologies deployed leads eventually to a situation that the spam score of this server or its relay raises higher and higher until no domain doing these checks accepts emails from them anymore. This is why we'd prefer that all offline-notification messages would be sent with plain address noreply@example.com, a domain which SPF DNS txt record we have control over.

[fsainovich]

Same problem here. Waiting for solution.

[Gummikavalier]

Since creating this issue we've been able to somewhat mitigate issues caused by coupling of real names with the no-reply-address by doing following.

1. First, setting on Admin -> Email -> Privacy -> Add Sender to Reply-To

This one ensures that the email messages that has been sent has always the real reply-to-address of the user, and many clients seem to prefer reply-to address instead of originating address as long as reply-to exists in the email headers. And by default it does not. Note that the original problem of mashed up user name and the no-reply-address still exist in the FROM header even after this. It just does not stick into the email clients as one to be preserved.

2. And then setting no-reply address into Admin -> Email -> SMTP -> From Email. Note: The no-reply address needs to be a real one to avoid getting penalized by spam filters.

The second one ensures that RC-instance or its relaying SMTP server does not use real user's email address directly in the email headers. This prevents the relay from getting bad score and angry looks from the recipient end spam filter mechanisms for faking 3rd party email domains while not owning DNS MX records for them. Most of the multiple Oauth enabled RC systems would suffer from this. No-reply address is not important if all your users have the very same email domain where RC / SMTP-relay is located.

[fsainovich]

Hi Gummikavalier.

Thank you for your reply. I will try this settings.