Im Kapitel SPF - Sender Policy Framework sind wir bereits darauf eingegangen, dass mit unter Probleme bei Mailumleitungen und/oder WebFormularen auftauchen können. Mit SRS¹⁾ kann ein Mailserver die eMail-Adresse im Envelope umschreiben und anpassen.

Das nachfolgende Schaubild verdeutlicht, warum bei zu strenger Wahl des SPF-Records der Versand bei einer Weiterleitung (alias) fehlschlägt. Der empfangende Mailserver überprüft die Angaben HELO und MAIL FROM im Envelop der eMail. Hierzu frägt der Mailserver den SPF-Record des sendenden Systems ab und vergleicht die IP-Adresse/Namen des einliefernden Empfängers mit den legitimen Sendern des SMF-Records. Ist der einliefernde Mailserver berechtigt, kann mit der weiteren Annahme und Prüfung fortgefahren werden. Ist der einliefernde Mailserver aber nicht berechtigt, quittiert das System den Zustellversuch mit einem Fehler-(code) 550.

Da in dem fiktiven Beispiel der Mailserver mx01.nausch.org nicht berechtigt ist Nachrichten der Domain example.org zu verschicken, schlägt die Zustellung an das Zielsystemfehl und der Mailserver wird die zuvor angenommene eMail zurück an den Absender bouncen!

Damit die Nachricht nun beim eigentlichen Zielsystem ankommt, müssen wir dafür Sorge tragen, dass das relayende System, also unser Mailserver, beim MAIL FROM im Envelope unsere Domain als Absender setzt. Dann kann das eigentliche Zielsystem, unsere eMail annehmen, da wir für unseren Mailserver einen entsprechend gültigen SPF-Record vorweisen können. Für den Fall, dass die Nachricht aber vom Zielsystem nicht zugestellt werden kann, oder eben von diesem später gebounced werden könnte, müssen wir uns nun die Absender-Adresse des ursprünglichen Mailservers merken. Nur so haben wir die Möglichkeit, den ursprünglichen Absender über den Zustellfehlversuch zu informieren.

Und an dieser Stelle setzt nun Sender Rewriting Scheme (kurz SRS) an! Wird eine eMail weitergeleitet, so setzt der SRS-Deamon die Envelop-Adresse MAIL FROM nach folgendem Schema: SRS0+xxxx=yy=example.com=alice@yourdomain.org, den wird dann auch als Return-Path im Mailheader unserer eMail beim entsprechenden Zielsystem vorfinden.

Return-Path: <SRS0+bCEv=YT=web.de=honeypot_for_spam@nausch.org>

Sollte die eMail zu uns zurück-bouncen, so kann unser Mailserver mit den Angaben dann, den ursprünglichen Absender, in dem Beispiel also honeypot_for_spam@web.de rekonstruieren und den Bounce an den richtigen Absender zurück schicken. Damit nun der reverse-SRS nicht als open-relay-Adresse missbraucht werden kann, werden bei der Envelope-Adresse die beiden Feder xxx und yy eingesetzt, die zum einen eine kryptografische Signatur und einen Zeitstempel repräsentieren. Sollten bei einem Bounce diese Angaben nicht stimmen, wird die Annahme der Nachricht verweigert, also verworfen.

Für SRS setzen wir den Postfix SRS Deamon, kurz PostSRSd von Timo Röhling ein. PostSRSd nutzt dabei zwei TCP lookup tables. Details zu diesen TCP lookup Tabellen, finden sich in der zugehörigen manpage.

 # man 5 tcp_table

TCP_TABLE(5)                                                      TCP_TABLE(5)
 
NAME
       tcp_table - Postfix client/server table lookup protocol
 
SYNOPSIS
       postmap -q "string" tcp:host:port
 
       postmap -q - tcp:host:port <inputfile
 
DESCRIPTION
       The  Postfix  mail  system  uses optional tables for address rewriting or mail routing. These
       tables are usually in dbm or db format. Alternatively, table lookups can be directed to a TCP
       server.
 
       To  find  out  what types of lookup tables your Postfix system supports use the "postconf -m"
       command.
 
       To test lookup tables, use the "postmap -q" command as described in the SYNOPSIS above.
 
PROTOCOL DESCRIPTION
       The TCP map class implements a very simple protocol: the client  sends  a  request,  and  the
       server  sends  one reply. Requests and replies are sent as one line of ASCII text, terminated
       by the ASCII newline character. Request and reply parameters (see  below)  are  separated  by
       whitespace.
 
       Send and receive operations must complete in 100 seconds.
 
REQUEST FORMAT
       Each request specifies a command, a lookup key, and possibly a lookup result.
 
       get SPACE key NEWLINE
              Look up data under the specified key.
       put SPACE key SPACE value NEWLINE
              This request is currently not implemented.
 
REPLY FORMAT
       Each  reply  specifies a status code and text. Replies must be no longer than 4096 characters
       including the newline terminator.
 
       500 SPACE text NEWLINE
              In case of a lookup request, the requested data does not exist.  In case of an  update
              request, the request was rejected.  The text describes the nature of the problem.
 
       400 SPACE text NEWLINE
              This  indicates  an error condition. The text describes the nature of the problem. The
              client should retry the request later.
 
       200 SPACE text NEWLINE
              The request was successful. In the case of a lookup  request,  the  text  contains  an
              encoded version of the requested data.
 
ENCODING
       In  request  and  reply  parameters,  the  character %, each non-printing character, and each
       whitespace character must be replaced by %XX, where XX is the corresponding ASCII hexadecimal
       character value. The hexadecimal codes can be specified in any case (upper, lower, mixed).
 
       The Postfix client always encodes a request.  The server may omit the encoding as long as the
       reply is guaranteed to not contain the % or NEWLINE character.
 
SECURITY
       Do not use TCP lookup tables for security critical purposes.  The client-server connection is
       not protected and the server is not authenticated.
 
BUGS
       Only the lookup method is currently implemented.
 
       The client does not hang up when the connection is idle for a long time.
 
SEE ALSO
       postmap(1), Postfix lookup table manager
       regexp_table(5), format of regular expression tables
       pcre_table(5), format of PCRE tables
       cidr_table(5), format of CIDR tables
 
README FILES
       Use "postconf readme_directory" or "postconf html_directory" to locate this information.
       DATABASE_README, Postfix lookup table overview
 
LICENSE
       The Secure Mailer license must be distributed with this software.
 
AUTHOR(S)
       Wietse Venema
       IBM T.J. Watson Research
       P.O. Box 704
       Yorktown Heights, NY 10598, USA
 
                                                                  TCP_TABLE(5)

Ob der im Einsatz befindliche Postfix diese TCP-Lookup-Tabellen unterstützt, können wir wie folgt abfragen.

 # postconf -d | grep mail_version && postconf -m

mail_version = 2.11.3
milter_macro_v = $mail_name $mail_version
btree
cidr
environ
fail
hash
internal
ldap
memcache
mysql
nis
pcre
proxy
regexp
socketmap
static
tcp
texthash
unix

Wie wir sehen können, bringt unser Postfix die benötigte Unterstützung für TCP-Lookup-Tabellen mit, so dass wir uns gleich der Installation des SRS-Daemon widmen können.

Die einfachste und schnellste Variante bei der Installation ist die aus dem Repository nausch.org. Hier reicht ein einfacher Aufruf von yum und alles wird automatisch installiert.

 yum install postsrsd -y

Will man das Repository nausch.org nicht einbinden kann man natürlich auch das betreffende Paket lokal installieren.

 # yum localinstall http://repo7.nausch.org/7/x86_64/postsrsd-1.2-1.el7.centos.x86_64.rpm

Ein Update des Paketes geht entsprechend der Installation.

 # yum localupdate http://repo7.nausch.org/7/x86_64/postsrsd-1.2-1.el7.centos.x86_64.rpm

Will man wissen, was das Paket alles mitbrachte, kann man dies mit dem Aufruf von rpm-qil <Paketname erkunden.

 # rpm -qil postsrsd

Name        : postsrsd
Version     : 1.2
Release     : 1.el7.centos
Architecture: x86_64
Install Date: Wed 03 Dec 2014 01:20:43 PM CET
Group       : System Environment/Daemons
Size        : 46260
License     : GPL
Signature   : RSA/SHA1, Wed 03 Dec 2014 01:04:43 PM CET, Key ID 60ecfb9e8195aea0
Source RPM  : postsrsd-1.2-1.el7.centos.src.rpm
Build Date  : Wed 03 Dec 2014 01:04:33 PM CET
Build Host  : vml000200.dmz.nausch.org
Relocations : (not relocatable)
Packager    : Django <django@nausch.org>
URL         : https://github.com/roehling/postsrsd/archive/1.2.tar.gz
Summary     : PostSRSd provides the Sender Rewriting Scheme (SRS) via TCP-based lookup tables for Postfix.
Description :
PostSRSd provides the Sender Rewriting Scheme (SRS) via TCP-based
lookup tables for Postfix. SRS is needed if your mail server acts
as forwarder.
/etc/sysconfig/postsrsd
/usr/lib/systemd/system/postsrsd.service
/usr/sbin/postsrsd
/usr/share/doc/postsrsd-1.2
/usr/share/doc/postsrsd-1.2/README.md
/usr/share/doc/postsrsd-1.2/main.cf.ex
/var/lib/postsrsd

Neben diesen Dateien wurde bei der Installation des RPMs auch ein individueller Schlüssel für postsrsd generiert. Wir finden diesen im Verzeichnis /etc/.

 # ll /etc/postsrsd.secret

-rw-------. 1 root root 25 Dec  3 13:20 /etc/postsrsd.secret

Hinweise zur Installation und Konfiguration finden sich in der mitgelieferten Datei /usr/share/doc/postsrsd-1.2/README.md.

 # less /usr/share/doc/postsrsd-1.2/README.md

PostSRSd                                                                                                  
========                                                                                                  

About
-----

PostSRSd provides the Sender Rewriting Scheme (SRS) via TCP-based 
lookup tables for Postfix. SRS is needed if your mail server acts 
as forwarder.                                                     


Sender Rewriting Scheme Crash Course
------------------------------------
Imagine your server receives a mail from alice@example.com
that is to be forwarded. If example.com uses the Sender Policy Framework 
to indicate that all legit mails originate from their server, your       
forwarded mail might be bounced, because you have no permission to send  
on behalf of example.com. The solution is that you map the address to    
your own domain, e.g.                                                    
SRS0+xxxx=yy=example.com=alice@yourdomain.org (forward SRS). If the      
mail is bounced later and a notification arrives, you can extract the    
original address from the rewritten one (reverse SRS) and return the     
notification to the sender. You might notice that the reverse SRS can    
be abused to turn your server into an open relay. For this reason, xxxx  
and yy are a cryptographic signature and a time stamp. If the signature  
does not match, the address is forged and the mail can be discarded.     

Building
--------

PostSRSd requires a POSIX compatible system and CMake to build. 
Optionally, help2man is used to create a manual page.           

For convenience, a Makefile fragment is provided which calls CMake with
the recommended command line options. Just run `make`.

Alternatively, you can control many aspects of the build manually:

    mkdir build
    cd build
    cmake .. <options>
    make
    make install

The CMake script defines a number of options in addition to the
standard CMake flags. Use `-D<option>=<value>` to override the defaults.

*   `GENERATE_SRS_SECRET` (default: `ON`). Generate a random secret on install.
*   `USE_APPARMOR` (default: `OFF`): Install an AppArmor profile for the daemon.
*   `INIT_FLAVOR` (default: auto-detect). Select the appriopriate startup
    script type. Must be one of (`upstart`,`sysv-lsb`,`sysv-redhat`) or `none`.
*   `CHROOT_DIR` (default: `${CMAKE_INSTALL_PREFIX}/lib/postsrsd`). Chroot jail
    for the daemon.
*   `SYSCONF_DIR` (default: `/etc`). Location of system configuration files.
*   `CONFIG_DIR` (default: `${SYSCONF_DIR}/default`). Install destination for
    the postsrsd settings.
*   `DOC_DIR` (default: `${CMAKE_INSTALL_PREFIX}/share/doc/postsrsd`). Install
    destination for documentation files.

Installing
----------

Run `make install` as root to install the daemon and the configuration
files.

Configuration
-------------

The configuration is located in `/etc/default/postsrsd` by default. You must store
at least one secret key in `/etc/postsrsd.secret`. The installer tries to generate
one from `/dev/urandom`. Be careful that no one can guess your secret,
because anyone who knows it can use your mail server as open relay!
Each line of `/etc/postsrsd.secret` is used as secret. The first secret is
used for signing and verification, the others for verification only.

PostSRSd exposes its functionality via two TCP lookup tables. The
recommended Postfix configuration is to add the following fragment to
your main.cf:

    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

This will transparently rewrite incoming and outgoing envelope addresses.
Run `service postsrsd start` and `postfix reload` as root, or reboot.

Die Konfiguration des postsrsd-Daemons gestaltet sich vergleichsweise einfach und erfolgt lediglich mit Hilfe Der Datei /etc/sysconfig/postsrsd. Mit unserem Editor der Wahl, z.B. vim bearbeiten wir diese Konfigurationsdatei.

 # vim /etc/sysconfig/postsrsd

/etc/sysconfig/postsrsd

# Default settings for postsrsd
 
# Local domain name.
# Addresses are rewritten to originate from this domain. The default value
# is taken from `postconf -h mydomain` and probably okay.
#
# Django : 2014-12-03
# default. #SRS_DOMAIN=example.com
SRS_DOMAIN=nausch.org
 
# Exclude additional domains.
# You may list domains which shall not be subjected to address rewriting.
# If a domain name starts with a dot, it matches all subdomains, but not
# the domain itself. Separate multiple domains by space or comma.
#
# Django : 2014-12-03
# default: #SRS_EXCLUDE_DOMAINS=.example.com,example.org
SRS_EXCLUDE_DOMAINS=pgp.guru
 
# Secret key to sign rewritten addresses.
# When postsrsd is installed for the first time, a random secret is generated
# and stored in /etc/postsrsd.secret. For most installations, that's just fine.
#
SRS_SECRET=/etc/postsrsd.secret
 
# Local ports for TCP list.
# These ports are used to bind the TCP list for postfix. If you change
# these, you have to modify the postfix settings accordingly. The ports
# are bound to the loopback interface, and should never be exposed on
# the internet.
#
SRS_FORWARD_PORT=10001
SRS_REVERSE_PORT=10002
 
# Drop root privileges and run as another user after initialization.
# This is highly recommended as postsrsd handles untrusted input.
#
RUN_AS=nobody
 
# Jail daemon in chroot environment
CHROOT=/var/lib/postsrsd

In der Postfix-Konfigurationsdatei /etc/postfix/main.cf aktivieren wir nun noch die Erweiterungen für die TCP Lookup Tabellen in der Sektion LOOKUP-TABELLEN bzw. tragen diese nach.

 # vim /etc/postfix/main.cf

################################################################################
## LOOKUP-TABELLEN
#
...
 
...
# Django : 2014-10-16 - Lookup-Tabelle zum Umschreibungen von Absender-eMail-
#          -Adressen im SMTP-Envelop und/oder im Header der eMail.
# default: sender_canonical_maps =
sender_canonical_maps = btree:/etc/postfix/sender_canonical_maps
#                       SRS - Sender Rewriting Scheme mit postsrsd
                        tcp:127.0.0.1:10001
#          Definition welche Adressen umgeschrieben werden sollen
# default: sender_canonical_classes = envelope_sender, header_sender
sender_canonical_classes = envelope_sender
 
# Django : 2014-10-16 - Lookup-Tabelle zum Umschreibungen von Empfänger-eMail-
#          -Adressen im SMTP-Envelop und/oder im Header der eMail.
# default: recipient_canonical_maps =
recipient_canonical_maps = btree:/etc/postfix/recipient_canonical_maps
#                          SRS - Sender Rewriting Scheme mit postsrsd
                           tcp:127.0.0.1:10002
#          Definition welche Adressen umgeschrieben werden sollen
# default: recipient_canonical_classes = envelope_recipient, header_recipient
recipient_canonical_classes = envelope_recipient

Das Starten des Daemon erfolgt über folgenden Aufruf.

 # systemctl start postsrsd

Den erfolgreichen Start bzw. den Status des postsrsd-Daemon können wir bei Bedarf mit folgendem Aufruf abfragen.

 # systemctl status postsrsd

● postsrsd.service - PostSRSd Daemon
   Loaded: loaded (/usr/lib/systemd/system/postsrsd.service; enabled)
   Active: active (running)since Wed 2014-12-03 14:39:49 CET; 2s ago
 Main PID: 29588 (postsrsd)
   CGroup: /system.slice/postsrsd.service
           └─29588 /usr/sbin/postsrsd -f10001 -r10002 -dnausch.org -s/etc/postsrsd.secret -unobody -c/var/lib/postsrsd -Xpgp.guru

Dec 03 14:39:49 vml000087.dmz.nausch.org systemd[1]: Starting PostSRSd Daemon...
Dec 03 14:39:49 vml000087.dmz.nausch.org systemd[1]: Started PostSRSd Daemon.

In der Prozessliste finden wir mindestens einen neuen Prozess, der gestartet wurde.

 # ps aux | grep postsrsd

 nobody   29588  0.0  0.0   6420   740 ?        Ss   14:39   0:00 /usr/sbin/postsrsd -f10001 -r10002 -dnausch.org -s/etc/postsrsd.secret -unobody -c/var/lib/postsrsd -Xpgp.guru

Mittels netstat können wir überprüfen, ob die beiden Ports 10001 und 10002 geöffnet wurden.

 # netstat -tulpen | grep 1000

 tcp        0      0 127.0.0.1:10001         0.0.0.0:*               LISTEN      0          290001     29588/postsrsd
 tcp        0      0 127.0.0.1:10002         0.0.0.0:*               LISTEN      0          290003     29588/postsrsd

Läuft unser Daemon kann mit Hilfe von lsof sehen wir nicht nur den geöffneten Port, sondern auch die Verbindungen die dort anliegen.

 # lsof -i :10001

COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
postsrsd 6170  nobody    5u  IPv4 574244      0t0  TCP localhost:scp-config (LISTEN)
postsrsd 7151  nobody    5u  IPv4 574244      0t0  TCP localhost:scp-config (LISTEN)
cleanup  7299 postfix   22u  IPv4 583245      0t0  TCP localhost:43341->localhost:scp-config (ESTABLISHED)
postsrsd 7300  nobody    0u  IPv4 583246      0t0  TCP localhost:scp-config->localhost:43341 (ESTABLISHED)
postsrsd 7300  nobody    5u  IPv4 574244      0t0  TCP localhost:scp-config (LISTEN)
postsrsd 7301  nobody    5u  IPv4 574244      0t0  TCP localhost:scp-config (LISTEN)

 # lsof -i :10002

postsrsd 6170  nobody    6u  IPv4 574246      0t0  TCP localhost:documentum (LISTEN)
smtpd    7146 postfix   40u  IPv4 582010      0t0  TCP localhost:57592->localhost:documentum (ESTABLISHED)
postsrsd 7151  nobody    0u  IPv4 582011      0t0  TCP localhost:documentum->localhost:57592 (ESTABLISHED)
postsrsd 7151  nobody    6u  IPv4 574246      0t0  TCP localhost:documentum (LISTEN)
cleanup  7299 postfix   23u  IPv4 583248      0t0  TCP localhost:57652->localhost:documentum (ESTABLISHED)
postsrsd 7300  nobody    6u  IPv4 574246      0t0  TCP localhost:documentum (LISTEN)
postsrsd 7301  nobody    0u  IPv4 583249      0t0  TCP localhost:documentum->localhost:57652 (ESTABLISHED)
postsrsd 7301  nobody    6u  IPv4 574246      0t0  TCP localhost:documentum (LISTEN)

Damit der Daemon automatisch beim Hochfahren des Servers gestartet wird, nutzen wir folgenden Aufruf.

 # systemctl enable postsrsd.service

 ln -s '/usr/lib/systemd/system/postsrsd.service' '/etc/systemd/system/multi-user.target.wants/postsrsd.service'

Wollen wir überprüfen ob der Dienst automatisch startet, verwenden wir folgenden Aufruf.

 # systemctl is-enabled postsrsd.service

 enabled

Die Rückmeldung enabled zeigt an, dass der Dienst automatisch startet; ein disabled zeigt entsprechend an, dass der Dienst nicht automatisch startet.

Im Maillog unseres Mailservers werden die Umschreibungen entsprechend dokumentiert.

 # less /var/log/maillog

Dec 3 19:01:59 vml000080 postsrsd[5806]: srs_forward: <honeypot_for_spam@web.de> rewritten as <SRS0+BaCI=YT=web.de=honeypot_for_spam@nausch.org>

Im Header zugestellten eMail beim Empfänger wird dies auch im Return-Pathhinterlegt.

Return-Path: <SRS0+BaCI=YT=web.de=honeypot_for_spam@nausch.org>

Bounced das Zielsystem die Nachricht, weil dieses z.B. die Nachricht wegen einer vollen Mailbox nicht zustellen kann, kann das relayende System nun problemlos den eigentlichen Absender informieren, da der PostSRSd die Zieladresse wieder ermitteln und umschreiben (srs_reverse) kann.

Dec 3 23:23:23 vml000080 postsrsd[6883]: srs_reverse: <SRS0+bCev=YT=web.de=honeypot_for_spam@nausch.org> rewritten as <honeypot_for_spam@web.de>
...
...
Dec 8 12:42:23 vml000080 postfix/smtp[6884]: 8413383: to=<honeypot_for_spam@web.de>, orig_to=<SRS0+bCev=YT=web.de=honeypot_for_spam@nausch.org>, relay=mx-ha03.web.de[213.165.67.104]:25, delay=0.75, delays=0.06/0/0.41/0.29, dsn=2.0.0, status=sent (250 Requested mail action okay, completed: id=0LtrOf-1X9H7q3CS5-011BDN)

• ⇐ Zurück zum Kapitel "SPF - Sender Policy Framework unter CentOS 7.x"
• ⇒ Weiter zum Kapitel "DMARC - Domain-based Message Authentication, Reporting & Conformance unter CentOS 7.x"
• Zurück zum Kapitel >>Mailserverinstallation unter CentOS 7<<
• Zurück zu >>Projekte und Themenkapitel<<
• Zurück zur Startseite