Zum Inhalt springen
clausvb.de

Postfix-Grundkonfiguration für kleine Server

Die Einstellungen in der main.cf, die wirklich zählen: Restriktionsreihenfolge, TLS, Grössenlimits und ein Setup, das kein offenes Relay wird.

Zuletzt geprüft: Gedacht für: eigener Mailserver auf einem vServer

Das Wichtigste

  • Die Reihenfolge in smtpd_recipient_restrictions entscheidet über alles. reject_unauth_destination muss vor jedem permit stehen, das nicht an Authentifizierung gebunden ist.
  • Einlieferung durch eigene Nutzer gehört auf Port 587 mit Pflicht-Authentifizierung, nicht auf Port 25.
  • Ein offenes Relay wird binnen Stunden gefunden. Prüfe nach jeder Änderung von aussen, nicht vom Server selbst.
  • Ohne gültigen Reverse-DNS-Eintrag auf den Hostnamen weisen grosse Provider die Zustellung häufig ab – unabhängig von SPF und DKIM.

Postfix ist schnell installiert und in der Standardkonfiguration nicht sicher betreibbar. Die folgenden Einstellungen sind das Minimum, mit dem ein kleiner Server produktiv laufen kann.

Identität und Netze

myhostname = mail.example.com
mydomain   = example.com
myorigin   = $mydomain

# nur lokale Zustellung, keine fremden Domains
mydestination = $myhostname, localhost.$mydomain, localhost

# NICHT auf 0.0.0.0/0 setzen
mynetworks = 127.0.0.0/8 [::1]/128

mynetworks ist die häufigste Ursache für offene Relays. Alles, was hier steht, darf ohne Anmeldung an beliebige Empfänger versenden. Ein grosszügiger Eintrag wie 10.0.0.0/8 in einer Cloud-Umgebung mit geteiltem privatem Netz reicht aus, um fremden Kunden das Versenden über deinen Server zu erlauben.

myhostname muss zum PTR-Eintrag der Versand-IP passen. Ohne diese Übereinstimmung lehnen grosse Provider die Zustellung ab, auch bei perfektem SPF und DKIM.

Restriktionen: die Reihenfolge ist die Konfiguration

smtpd_helo_required = yes

smtpd_helo_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    reject_rbl_client zen.spamhaus.org,
    check_policy_service inet:127.0.0.1:10023,
    permit

Postfix arbeitet die Liste von oben nach unten ab und hört beim ersten eindeutigen Ergebnis auf. Daraus folgen zwei Regeln:

reject_unauth_destination muss vor jedem allgemeinen permit stehen. Es ist die Direktive, die verhindert, dass dein Server Mail an fremde Domains annimmt. Steht sie zu weit unten oder fehlt sie, ist der Server ein offenes Relay.

Teure Prüfungen gehören nach hinten. RBL-Abfragen und Greylisting kosten eine Netzwerkanfrage beziehungsweise einen Datenbankeintrag. Was ohnehin abgelehnt wird, sollte vorher rausfliegen.

TLS

# eingehend
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file  = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_mandatory_protocols = >=TLSv1.2

# ausgehend
smtp_tls_security_level = may
smtp_tls_protocols = >=TLSv1.2
smtp_tls_CApath = /etc/ssl/certs

may heisst opportunistisch: verschlüsseln, wenn die Gegenstelle es kann, sonst im Klartext zustellen. Für Port 25 ist das der richtige Wert – encrypt würde die Zustellung an Server ohne TLS komplett verhindern und Mail verlieren.

Für die Einlieferung durch eigene Nutzer gilt das Gegenteil. In der master.cf:

submission inet n - y - - smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Auf Port 587 ist TLS Pflicht und Authentifizierung Pflicht. Ohne Anmeldung wird die Verbindung abgewiesen, egal aus welchem Netz.

Limits

message_size_limit = 26214400   # 25 MB
mailbox_size_limit = 0          # 0 = unbegrenzt, Quota macht Dovecot
smtpd_error_sleep_time = 5s
smtpd_soft_error_limit = 5
smtpd_hard_error_limit = 10
anvil_rate_time_unit = 60s
smtpd_client_connection_rate_limit = 30

Die Fehler- und Ratenlimits bremsen Versuche, Adressen durchzuprobieren. message_size_limit gilt für die kodierte Nachricht – ein 25-MB-Anhang wird durch Base64 rund ein Drittel grösser, das Limit muss also über der gewünschten Anhangsgrösse liegen.

Nach jeder Änderung prüfen

postfix check
postconf -n            # nur die abweichenden Werte, gut zum Vergleichen
systemctl reload postfix

Der wichtigste Test kommt von aussen, nicht vom Server selbst:

# aus einem fremden Netz
swaks --to fremde-adresse@example.org \
      --from test@irgendwo.invalid \
      --server mail.example.com

Erwartet wird 554 5.7.1 Relay access denied. Kommt stattdessen eine Annahme, ist der Server offen und gehört sofort vom Netz genommen – solche Server werden innerhalb von Stunden gefunden und landen auf Blocklisten, aus denen die IP nur mühsam wieder herauskommt.

Ergänzend gehört auf jeden produktiven Mailserver eine Überwachung der eigenen IP gegen die gängigen Blocklisten. Wer erst durch Kundenbeschwerden erfährt, dass er gelistet ist, hat schon Tage verloren.

Häufige Fragen

Wie erkenne ich, ob mein Server ein offenes Relay ist?

Indem du von einem fremden Netz aus versuchst, eine Mail an eine externe Adresse einzuliefern, ohne dich anzumelden. Der Server muss das mit 554 Relay access denied ablehnen. Ein Test vom Server selbst sagt nichts aus, weil mynetworks die eigene Adresse in der Regel erlaubt.

Brauche ich einen Reverse-DNS-Eintrag?

Für zuverlässige Zustellung ja. Der PTR-Eintrag der Versand-IP muss auf denselben Namen zeigen, den der Server im HELO nennt, und dieser Name muss vorwärts wieder auf die IP auflösen. Den PTR setzt der Anbieter der IP, nicht dein DNS-Hoster.

Welche Ports muss ich öffnen?

Port 25 für die Annahme von fremden Mailservern, Port 587 für die Einlieferung durch eigene Nutzer mit Anmeldung. Port 465 mit implizitem TLS ist wieder offiziell und wird von vielen Clients bevorzugt. Port 25 nach aussen wird von vielen Anbietern auf neuen Servern gesperrt und muss freigeschaltet werden.

Lohnt sich ein eigener Mailserver überhaupt noch?

Für Wissen und Kontrolle ja, für geschäftskritische Post ist die Abwägung ehrlicher: Reputationsaufbau, Blocklisten-Überwachung und Erreichbarkeit sind laufender Aufwand. Wer das nicht dauerhaft leisten will, fährt mit einem spezialisierten Anbieter besser.

Weiterlesen