Sender Rewriting Scheme (SRS) is a scheme for rewriting the envelope sender address of an email message, in view of remailing it. This function (re)allow you to forward email on a server with SPF enabled. SPF ensure that the server who sends an email is allowed to send it from this domain. If you forward a mail, SPF will fail as your server is not allowed to send email from the domain of the forwarded email. SRS solve this issue.
An example may be better. You have your mail server server.mydomain.com and a mailboxes professional@mydomain.com this mailbox is forwarded to personal@gmail.com. A mail from store@vendor.com via server.vendor.com is sent to professional@mydomain.com. Your server checks with SPF that server.vendor.com is allowed to send email for domain vendor.com, do the antispam check and then forward it to personal@gmail.com. The Gmail server verify that server.mydomain.com is allowed to send email from domain vendor.com. As it’s not true the SPF test will fail and this mail could be classified as SPAM. If the forwarded mails are SPAM your server can also be blacklisted. With SRS the envelope is rewritten from <store@vendor.com> to something like <SRS0+yf09=Cw=vendor.com=store@mydomain.com> so SPF test will pass. More information about SRS can be found here at http://www.openspf.org/SRS.
Before implementing SRS you should be aware that all forwared mail will be interpreted as coming from your server. If you do not have a good antispam configuration you may become a relay of spam an cloud be blacklisted !
Runing configuration
Debian wheezy 3.2.0-4-amd64
Postfix 2.9.6
Plesk 12.0
Installation
First point is to install dependencies if you don’t already have this package.
|
1 |
apt-get install cmake |
SRS is implemented for Postfix with PostSRSd. They are other option but this is the only one that works as a Postfix milter.
|
1 2 3 4 |
mkdir /root/srsworkfolder cd /root/srsworkfolder/ curl -L -o postsrsd.zip https://github.com/roehling/postsrsd/archive/master.zip unzip postsrsd.zip |
Next step is to build the postsrsd application
|
1 2 3 4 5 6 |
cd postsrsd-master mkdir build cd build cmake -DCMAKE_INSTALL_PREFIX=/usr ../ make make install |
Configuration of PostSRSd
The configuration of PostSRSd is stored in /etc/default/postsrsd. Only one parameter must be changed to disable SRS for local domains. If your server hosts mutliples domains you have to disable SRS for local incoming mails :
|
1 |
SRS_EXCLUDE_DOMAINS=server.mydomain.com,mydomain.com,otherdomain.net |
During the installation, a secret key is generated and stored in /etc/postsrsd.secret. Be careful to protect this secret because your server can be used as open relay if this key is known. When the configuration is done you just have to enable the daemon on OS start (thanks to Albrecht in comments) and start it the PostSRSd directly.
|
1 2 |
systemctl enable postsrsd service postsrsd start |
Configuration of Postfix
By default OpenSRSd will use the ports 10001 and 10002. You only need to add these lines to /etc/postfix/main.cf to enable the rewriting.
|
1 2 3 4 5 |
# PostSRSd settings. sender_canonical_maps = tcp:127.0.0.1:10001 sender_canonical_classes = envelope_sender recipient_canonical_maps = tcp:127.0.0.1:10002 recipient_canonical_classes= envelope_recipient,header_recipient |
And then reload postfix
|
1 |
service postfix reload |
Integration with Plesk
As every local domain should be added to the OpenSRSd configuration (and removed when the domain is removed). We can use the scripts pleskDomainCreatedEvent.sh and pleskDomainRemovedEvent.sh described in post DKIM configuration for Postfix & Plesk to call custom scripts only for SRS configuration.
Create custom script in directory /scripts/ named postSRSDomainAdd.sh with the content below. It will add the newly created domain to the SRS_EXCLUDE_DOMAINS variable and apply change by restarting SRS and reloading Postfix.
|
1 2 3 4 5 6 7 8 9 10 11 |
#!/bin/bash die () { echo >&2 "$@" exit 1 } [ "$#" -eq 1 ] || die "1 argument required, $# provided, domain required, ex: ./script example.com" sed -i "/SRS_EXCLUDE_DOMAINS/ s/$/,$1/" /etc/default/postsrsd service postsrsd restart service postfix reload |
Create the script postSRSDomainRemove.sh that will remove the domain from the exclude list :
|
1 2 3 4 5 6 7 8 9 10 11 12 |
#!/bin/bash die () { echo >&2 "$@" exit 1 } [ "$#" -eq 1 ] || die "1 argument required, $# provided, domain required, ex: ./script example.com" sed -i "s/SRS_EXCLUDE_DOMAINS=$1,/SRS_EXCLUDE_DOMAINS=/g" /etc/default/postsrsd sed -i "s/,\?$1//g" /etc/default/postsrsd service postsrsd restart service postfix reload |
You need to edit pleskDomainCreatedEvent.sh and pleskDomainRemovedEvent.sh to call these two new scripts.
Important note about Spam Filtering and White/Black Lists
PostSRSd rewrites all incoming mails even those are not forwarded this is a known issue from the editor of PostSRSd caused by the way it is integrated with Postfix. This has an impact with the black and white list on Spam fighter, for example spamassassin. If you whitelist the main domain of the server (also the domain used by default by PostSRSd) the spam filter will be completely bypassed. Here is an example of the problem : A mail from test@gmail.com arrives, the from address is rewrited like SRS0=H8YL=IL=gmail.com=test@mydomain.com. If mydomain.com is whitlisted by the spam filter, no spam verification will be done.
To allow the main domain to be whitelisted without impact on spam filtering, you may change the SRS domain in PostSRSd with a subdomain of the main domain in /etc/default/postsrsd :
|
1 |
SRS_DOMAIN=srs.mydomain.com |
If you have custom blacklist or whitelist elements like *@othercompany.com, the spam filter will not match this pattern as the from field has been rewritten. These patterns have to be changed to *othercompany.com*@srs.mydomain.com. Do not forget that mails from internal domains will not be rewritten. If the server hosts the domain myotherdomain.com and you would whitelist this domain, you may add the rule *@myotherdomain.com.
Tests
The easiest way to check if the SRS is working well is to check headers on a forwarded mail. In the headers the Return-Path should be rewritten like this :
|
1 2 3 4 5 6 7 8 9 |
Return-Path: <SRS0=H8YL=IL=vendor.com=store@srs.mydomain.com> Received: from mydomain.com (server.mydomain.com. [123.123.123.123]) by mx.google.com with ESMTPS id db2si499444wjb.193.2015.08.04.12.00.20 for <personal@gmail.com> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2015 12:00:20 -0700 (PDT) Received-SPF: pass (google.com: domain of SRS0=H8YL=IL=vendor.com=store@srs.mydomain.com designates 123.123.123.123 as permitted sender) client-ip=123.123.123.123; Authentication-Results: mx.google.com; spf=pass (google.com: domain of SRS0=H8YL=IL=vendor.com=store@srs.mydomain.com designates 123.123.123.123 as permitted sender) smtp.mail=SRS0=H8YL=IL=vendor.com=store@srs.mydomain.com |
The mail log of the server will also show your the whole process of a mail. To do a real time trace :
|
1 |
tail -f /var/log/maillog |
Just found your tutorial and tried to install it on Debian 8.
> service postsrsd start
failed. I had to run
> systemctl enable postsrsd
before and everything was ok. Maybe you can extend your tutorial.
Hello Albrecht,
Thanks for your comment, this is completely right, I’ve added it to the post.
Thanks,
Stéphane
Hello,
On some example I have seen this approach:
“recipient_canonical_classes= envelope_recipient”
What happens exactly if ‘header_recipient’ is not added? So far I found no explanation.
Hello Costin,
Thanks for your comment, for each incoming mail Postfix will have the envelope_recipient with the value provided in the MAIL TO command during TCP connection to the mail server and a header_recipient contained in the BODY part of the mail in the mail header To:.
So basically if you didn’t add the header_recipient in the recipient_canonical_classes, the from address will not be de-rewritten during SRS process when a response to a rewritten mail come back to the mail server.
It may have no impact on the delivery of the e-mails if the To header is not rewritten. In any case I do recommend to remove all possible rewrite done before if any other mail server manipulate the To header (for example if some mail server replace the To address with the Envelope recipient you would have a reason to remove this).
For my point of view there is 99% of chances that only recipient_canonical_classes= envelope_recipient would be sufficient.
I hope I answered your question and wish you a great day.
Stéphane