Forwarding and Enable Sender Rewriting Scheme

swbrains

Well-Known Member
Sep 13, 2006
154
19
168
I've read some of the threads here on this topic but I'm still confused.

My case is pretty typical (I would think) in that an outside party using some email account like example @ gmail.com sends an email to an email forwarder address like forwarder @ hostedaccount.com. In this example, hostedaccount.com is hosted on my server. The mail is then forwarded according to the forwarder rules to example @ yahoo.com. Yahoo gets the email and rejects it for DMARC violation because it thinks it was sent from my server which does not host the sender's gmail.com domain. I do understand and accept why that happens.

I have been reading the threads that suggest that I enable Enable Sender Rewriting Scheme (SRS) Support on my server where the forwarder exists. But if I do this, what would be the sender/from address on the message that the ultimate recipient @ yahoo.com receives (according to my example above)? Could that message then be replied to by the Yahoo recipient in order to reply to the original sender @ gmail.com?

I don't want to enable this for my entire server and then realize that I've caused confusion for my customers that use forwarders because the messages no longer appear to "come from" the person who sent them or they can't determine who sent it (or reply to them) because the sender address has been modified by the server during forwarding.

Thanks for any clarification you can provide. :)
 

cPanelLauren

Forums Analyst II
Staff member
Nov 14, 2017
6,762
535
263
Houston
cPanel Access Level
DataCenter Provider
Hi @swbrains

The behavior of SRS is as follows:

This option rewrites sender addresses so that the email appears to come from the forwarding mail server. This allows forwarded email to pass an SPF check on the receiving server.

Note:

  • This setting defaults to Off.
  • This setting uses the default configuration for SRS. If you wish to customize the SRS configuration, use the Advanced Editor interface.
Warning:

Sender Rewriting Scheme (SRS) will not function correctly if the external mail server's autoresponder replies to the Sender address instead of the From address.
Which I think resolves your issue.

What I think you might be getting this confused with is an experimental feature we have available:

EXPERIMENTAL: Rewrite From: header to match actual sender
This option rewrites the From header in emails to show the original identity of the actual sender for messages sent from your server. Email recipients can see the original From header as the X-From-Rewrite header as well as the rewritten From header. This option is useful to determine the actual mail sender.

Note:

This option does not affect mail that you receive from a remote host. The system only rewrites the From header for mail that it sends from the local machine because it is not possible to determine or validate the actual mail sender from remote machines.
 

swbrains

Well-Known Member
Sep 13, 2006
154
19
168
Thanks, but I think I'm still confused... :)

>>rewrites sender addresses so that the email appears to come from the forwarding mail server

How is the new (rewritten) sender address generated? I realize it must use the domain of the forwarding mail server to pass SPF checks, but what does it use as the "local" part of the sender's email address? If I sent an email originally from example @ gmail.com, what would the ultimate recipient see as the Sender/FROM address on the message they receive?

Also, how does rewriting the sender/FROM address affect the ability of the recipient to identify or reply to the original sender?

Thanks!
 

cPanelLauren

Forums Analyst II
Staff member
Nov 14, 2017
6,762
535
263
Houston
cPanel Access Level
DataCenter Provider
For example if I send an email from [email protected] to [email protected] which has a forwarder to [email protected], SRS rewrites the sender addresss to come from [email protected] rather than [email protected] as far as the source of the email is concerned. The problem with this is found in the headers of the email.

Code:
Return-Path: <[email protected]>
Authentication-Results: mta4359.mail.bf1.yahoo.com;
 dkim=permerror (bad sig) [email protected] header.s=20161025;
 spf=softfail [email protected];
 dmarc=fail(p=none sp=quarantine dis=none) header.from=gmail.com;
Received-SPF: softfail (transitioning domain of gmail.com does not designate <myServerIP> as permitted sender)
So to answer your question when you forward mail like this it comes from the forwarding server but it's shown as coming from the original address (in this case gmail) and this causes a failure SPF, DKIM and DMARC

Here's an example of what is shown in the headers when I have it enabled:

Code:
Return-Path: <[email protected]>
Authentication-Results: mta4490.mail.ne1.yahoo.com;
 dkim=pass (ok) [email protected] header.s=default;
 spf=pass [email protected];
 dmarc=fail(p=none sp=quarantine dis=none) header.from=gmail.com;
Received-SPF: pass (domain of domain.tld designates <myServerIP> as permitted sender)
X
My DMARC in this case fails but only because I don't have one for this domain


Replying will work the same way it always does, you'll reply to the originator of the message in both instances.
 

swbrains

Well-Known Member
Sep 13, 2006
154
19
168
Thanks. So how does the recipient's email app know to reply to the original sender address? Is this feature rewriting only the FROM header to be the forwarding domain (to pass SPF checks), but keeping the REPLY-TO header set to the original sender's address?
 

cPanelLauren

Forums Analyst II
Staff member
Nov 14, 2017
6,762
535
263
Houston
cPanel Access Level
DataCenter Provider
The Reply-To/Return-Path header doesn't get changed all that's changed is the From header and the Received header:

With SRS:
Code:
Received: from 127.0.0.1  (EHLO server.hostname.us) (104.145.226.61)
  by mta4490.mail.ne1.yahoo.com with SMTPS; Fri, 19 Jul 2019 14:08:23 +0000
Without SRS:
Code:
Received: by mail-wr1-f42.google.com with SMTP id y4so32405766wrm.2
       for <[email protected]>; Fri, 19 Jul 2019 07:03:06 -0700 (PDT)