In ‘debian’ gepostet

Debian Wheezy, Postfix und SRS

Mittwoch, 7. August, 2013

Ich betreibe für vom.tc einen Postfix-Mailserver und habe dort vor ewigen Zeiten SPF-Prüfung aktiviert. Unter wheezy ist das eher langweilig:

apt-get install postfix-policyd-spf-perl


Danach die master.cf ergänzen um

spfcheck  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/sbin/postfix-policyd-spf-perl


und main.cf um

smtpd_recipient_restrictions =
        permit_mynetworks
        reject_unauth_destination
        check_policy_service unix:private/spfcheck

Wer sich mit SPF auseinandergesetzt hat, weiß, dass es zu Problemen bei der Weiterleitung von E-Mails kommen kann.
Beispiel: paul@example.com leitet seine E-Mails an paul@example.net weiter. Schickt nun peter@example.net eine E-Mail an paul@example.com wird der Mailserver von example.com die E-Mail empfangen und den Empfänger auf paul@example.net ändern. Nutzt example.net SPF wird er diese E-Mail ablehnen, da der Absender peter@example.net ist und example.com keine E-Mails im Namen von example.net verschicken darf. Works As Designed. Dough.

Lösung: Sender Rewriting Scheme (kurz SRS)

Die Idee bei SRS ist es die ursprüngliche Absenderadresse in eine Adresse zu kodieren, für die der Mailserver Mails laut SPF verschicken darf. Dabei wird ein Hash und ein Zeitstempel ergänzt, um SPF-gültigen SPAM zu vermeiden und gleichzeitig eventuelle Fehlermeldungen an den ursprünglichen Absender weiterleiten zu können.

Etwas googlen hat mich dann an diese Orte gebracht:

Für mich war recht schnell klar, dass ich möglichst viel mit den Boardmitteln machen möchte. Nachdem die libsrs2-0 mit squeeze scheinbar endet, habe ich mir das Paket srs genauer angeguckt und entlang des Quelltextes oben zwei eigene Wrapper „srs_encode.sh“ und „srs_decode.sh“ geschrieben. Deren Verwendung möchte ich hier einmal skizzieren; sämtliche Dateien habe ich im Gist 6163083 hinterlegt.

1. Schritt: Das srs-Tool ans laufen bekommen

apt-get install srs
– anschließend müssen wir uns ein Secret für das Tool ausdenken. Meine Vorredner haben PHP verwendet um gleich mehrere Secrets zu erstellen, da aber das Tool nur das erste Secret zum Kodieren und alle zum Dekodieren nutzt, ist es in meinen Augen eher eine Sicherheitslücke als ein Vorteil bei einem einzelnen Server mehrere Zeilen zu verwenden. Bei mehreren Servern könnte man die Reihenfolge der Secrets allerdings durchtauschen, um aus der Adresse ableiten zu können, wo sie erstellt wurde.
Jede Art einen zufälligen String zu erzeugen ist gut, eine Methode, die einen sicheren Zufallszahlengenerator verwendet, besser. Ich habe
makepasswd --count 1 --minchars 42 --maxchars 84 >/etc/postfix/srs.secrets
verwendet (makepasswd ist aus dem gleichnamigen Paket). Anschließend per
chmod u=r,go= /etc/postfix/srs.secrets
sicher gehen, dass niemand das Secret liest.

Ein erster Test:
srs --alias=some.tld --secretfile=/etc/postfix/srs.secrets mail@example.com
> SRS0=fFqU=RU=example.com=mail@some.tld
srs --reverse --secretfile=/etc/postfix/srs.secrets SRS0=fFqU=RU=example.com=mail@some.tld
> mail@example.com

Es ist durchaus gängig eine eigene Sub-Domain für SRS-Adressen zu verwenden; einfach als --alias= beim Kodieren angeben. Das Dekodieren liest nur den Text links des @ und klappt bei euch hoffentlich nicht für mein Beispiel hier 😉

2. Wrapper Skripte

Die Skripte waren etwas tricky, da srs z.B. beim Dekodieren von E-Mail-Adressen mit einer anderen Groß-/Kleinschreibung im Hash zusätzlich zur dekodierten E-Mail-Adresse eine Warnung ausgibt. Um die beiden Skripte zu verwenden, ladet euch einfach srs-decode.sh und srs-encode.sh runter und legt sie unter /opt/srs/ ab (den Pfad werde ich gleich verwenden).

srs-encode.sh müsst ihr noch so anpassen, dass eure lokalen Domains durch den regulären Ausdruck erkannt werden und nicht umgewandelt werden (erzeugt nur Verwirrung) und die richtige Domain hinter --alias= steht.

Die Wrapper verwenden außer srs noch das Paket liburi-perl, das aber vermutlich bei den meisten ohnehin schon installiert ist.

Auch hier lohnt ein kleiner Test. Auf jede Eingabe der Form „get some@mail“ solltet ihr eine Antwort bekommen. Fängt die Antwortzeile mit 200 an, so wird Postfix die Adresse ändern, bei 400 und 500 wird sie nicht geändert. Die E-Mailadressen werden „URL-Encoded“ übertragen – wundert euch also nicht über %40 statt @.

3. Als Postfix-Tauglichen Dienst betreiben

Ein weiteres Paket, dass ohnehin auf den meisten Servern vorhanden ist, ist openbsd-inetd. Durch anfügen dieser drei Zeilen an die /etc/inetd.conf und Aufrufen von
service openbsd-inetd restart
machen wir aus unseren beiden Wrapper-Skripten per TCP erreichbare Dienste. Auch das sollten wir besser testen:

postmap -q mail@example.com tcp:10001
> SRS0=fFqU=RU=example.com=mail@some.tld
postmap -q SRS0=fFqU=RU=example.com=mail@some.tld tcp:10002
> mail@example.com

Wenn hier alles funktioniert (besser mehr Adressen testen!) können wir im letzten Schritt die Postfix-Konfiguration anpassen:

4. Postfix konfigurieren

Es gibt ein paar Adressen, die wir auf keinen Fall ändern wollen. Diese tragen wir in die /etc/postfix/pfix-srs.norewrite ein. Eine Vorlage findet ihr unten, bzw. hier
Immer, wenn wir die Datei ändern, rufen wir anschließend
postmap /etc/postfix/pfix-srs.norewrite
auf, um die von Postfix gelesene /etc/postfix/pfix-srs.norewrite.db zu aktualisieren.

In Postfix‘ main.cf kommen dann diese Zeilen, die dafür Sorgen, dass nur in der Kommunikation nach außen die umgeschriebenen Adressen verwendet werden. Ein
service postfix reload
später schlägt die Stunde der Wahrheit.

Getestet werden sollte das Weiterleiten einer extern abgeschickten E-Mail genau so, wie das Senden an eine SRS-Adresse und der allgemeine Betrieb (E-Mail von/an lokal). Wie immer ist der Teufel ein Eichhörnchen.

Alle Dateien auf einen Blick

Oh, eine Datei fehlt natürlich: die /etc/postfix/srs.secrets, die in Schritt 1 erstellt wurde 😉

Danke fürs lesen!

Ich freue mich über Feedback und auch um schönere Wrapper-Skripte z.B. in Perl.


Canonical URL by SEO No Duplicate WordPress Plugin