If you interested in SRS than you probably already know what it is In this tutorial I don’t want to explain the SPF and SRS mechanisms. In general, i think, it is used by big companies to reduce spam but also produces some problems with forwarding mails. It is also a mystery for me why after nearly 10 years there are so few tutorials over internet about this topic. I came to a problem with my postfix configuration on OpenSuse (12.3 at the time of writting). I use aliases maps (through mysql) to forward mails sent to my domain to other (external) domains ex: sender@example.com -> me@mydomain.com -> my_priv_adr@bla.com. In this situation, if the bla.com server has SPF running than it recognises that the orginal mail domain was different than the relay domain and will block the email with SPF error. I don’t want to enable SPF on my company server because i find it unnecesarry, but if I want to be able to use forwarding feature I had to use SRS. This tutorial asumes thet you have working postfix server.
My tutorial is generally based on two other but the configuration has been made for OpenSuse
First we’ll need libsrs2 library. It can be downloaded from libsrs2 - Download the newest version now is libsrs2-1.0.18.tar.gz
Install the package as describrd in INSTALL file. The default install location is /usr/local/lib64, so run:
cp /usr/local/lib64/* /lib64/
While comiling an error about missing .h files may occur but they can be installed from standard repos like:
zypper install libev-devel
Another missing file srs2.h can be found in libsrs2 package:
updatedb && locate srs2.h
cp <path>/srs2.h /usr/include/
Finally, you should get a binary pfix-srsd. Copy that file do /usr/local/bin/
Create config and secrets files
vi /etc/default/pfix-srsd
put:
DOMAIN=your_domain
SECRETS=/etc/postfix/pfix-srs.secrets
OPTIONS=-I
vi /etc/postfix/pfix-srs.secrets
Here put some long random string and set permissions:
chown postfix:postfix /etc/postfix/pfix-srs.secrets
chmod 400 /etc/postfix/pfix-srs.secrets
Create /etc/postfix/pfix-no-srs.cf
You can put addresses that should not be SRS’ed. If you don’t know any, leave empty file and run:
postmap /etc/postfix/pfix-no-srs.cf
Create a daemon for pfix-srsd
vi /etc/init.d/pfix-srsd
#!/bin/sh
### BEGIN INIT INFO
# Provides: pfix-srsd
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 5
# Default-Stop: 0 1 6
# Short-Description: pfixtools SRS Daemon backend for Postfix
### END INIT INFO
PFIXSRSD_CONFIG="/etc/default/pfix-srsd"
NAME="pfix-srsd"
DAEMON="/usr/local/bin/pfix-srsd"
PID_FILE="/var/run/pfix-srsd.pid"
if -f $PFIXSRSD_CONFIG ]; then
. $PFIXSRSD_CONFIG
else
exit 0
fi
test -x $DAEMON || exit 0
case "$1" in
start)
echo -n "Starting Postfix SRS Daemon: $NAME"
exec $DAEMON -f $OPTIONS -p $PID_FILE $DOMAIN $SECRETS 2>&1 &
echo "."
;;
stop)
echo -n "Stopping Postfix SRS Daemon: $NAME"
if -f $PID_FILE ]; then
kill `cat $PID_FILE`
rm $PID_FILE
fi
echo "."
;;
restart)
$0 stop
$0 start
;;
force-reload)
$0 restart
;;
*)
echo "Usage: $0 start|stop|restart|force-reload"
exit 1
;;
esac
Setup postfix
vi /etc/postfix/main.cf
At the EOF add:
Automate and run
chkconfig pfix-srsd on
/etc/init.d/pfix-srsd start
postfix reload
You can see the service listening on ports 10001 and 10002
Test
Do a redirection in postfix in alias maps. Send emali from external domain to your redirected address and see if it will come to destination. Check the mails’s header at the destination. You will notice an srs records.
Although I’m sure that what is posted here is valuable,
Isn’t the standard fix just to create SPF records in your public DNS? Without getting into detail, SPF merely checks the published authorized SMTP servers for your Domain.
Implementing SPF or SRS for incoming mail would be a completely different issue altogether, but for the stated Use Case, mail is merely outbound, being forwarded to a remote recipient mail server.
Unless I’m misunderstanding something here?
Also consider my thoughts are are entirely theoretical and not supported by actually testing in the real world.
Took another look at this.
Curiously, I can’t find anyone even trying what I described, which is to simply publish additional SPF records… So maybe recipient mail servers may simply fail when encountering a forwarding header instead of doing a lookup to verify <both> SPF records for the sender and forwarder.
So, it looks like the posted solution is the “Re-mail” method which I assume would be useful if you need to send to a large number and perhaps changing recipient mail servers. The problem with re-mailing is that the original sender’s identity is changed so you will need to map replies as well as forwarding.
Otherwise, it looks like most recommendations simply ask the recipient mail servers to whitelist the forwarders… But I would then return to my original suggestion to test whether publishing appropriate SPF records might do the same. I just don’t know if what I suggested will work or not, if anyone has tested
I’m not sure if I understood correctly your thoughts but here is some explanaton:
So maybe recipient mail servers may simply fail when encountering a forwarding header instead of doing a lookup to verify <both> SPF records for the sender and forwarder.
Otherwise, it looks like most recommendations simply ask the recipient mail servers to whitelist the forwarders… But I would then return to my original suggestion to test whether publishing appropriate SPF records might do the same. I just don’t know if what I suggested will work or not, if anyone has tested
It’s not like that the final destination server simply fail. The MTA with SPF will check 2 things:
1.
In the DNS record of the original sender domain it will check if the re-mailing (relay) server is actually authorised to re-mail. You can ask the source domain (not recipient) to whitelist your ip so you will be able to forward email from particular domain, but it is practically imposible to ask big companies like ex. google to do it for you. If you want to ask recipient server than you would have to ask every where you want send a mail and that’s impossible.
The SPF server will check the mail header. There must be information about the origin of the mail and all hops must be listed (re-mailing servers). This information is wtitten in srs records directly in mail header. If the information is correct the mail will pass, else it’ll be droped.
So, it looks like the posted solution is the “Re-mail” method which I assume would be useful if you need to send to a large number and perhaps changing recipient mail servers. The problem with re-mailing is that the original sender’s identity is changed so you will need to map replies as well as forwarding.
In this case the original sender adress remain unchanged but It shouldn’t be a problem to remap sender address with sender_canonical. It all depend what you need.
SMTP Relay (no re-mailing)
It would be trivial to simply add an SPF record. Typically, the reason why you might run into a relay issue is if you are mailing using an email Domain Name based on your own publicly registered Domain Name. If the recipient mailserver <simply> does a lookup for authorized outbound mail servers for your Domain, then simply adding additional SPF records to your Domain records should be simple and feasable (after all, you own your own Domain name). This would not work if the recipient mail server does a deeper message header analysis than simply comparing to and requiring a valid SPF record.
I dunno, things may have changed and be specific to various mail services, but if the whitelisting approach is required, I haven’t had a problem getting mail server admins to implement in the past. They’re already managing massive whitelist and blacklists (usually associated with anti-spam) so adding another entry is usually trivial… Just try to provide all necessary info up front so your request doesn’t become a long back-and-forth.
SMTP Re-mailing
This method re-writes the message header, it’s the difference between “Sent by” and “Send As”(The latter assumes a new primary identity). Although probably common to all mail systems, I’ve commented on this plenty of times in the past configuring MS Exchange servers (which require “Send As” to work). This seems to be acceptable universally and this seems to be what your post describes which is good.
In this tutorial I don’t want to explain the SPF and SRS mechanisms. In general, i think, it is used by big companies to reduce spam but also produces some problems with forwarding mails. It is also a mystery for me why after nearly 10 years there are so few tutorials over internet about this topic. I came to a problem with my postfix configuration on OpenSuse (12.3 at the time of writting). I use aliases maps (through mysql) to forward mails sent to my domain to other (external) domains ex: sender@example.com -> me@mydomain.com -> my_priv_adr@bla.com. In this situation, if the bla.com server has SPF running than it recognises that the orginal mail domain was different than the relay domain and will block the email with SPF error. I don’t want to enable SPF on my company server because i find it unnecesarry, but if I want to be able to use forwarding feature I had to use SRS. This tutorial asumes thet you have working postfix server.