Konfiguration unseres MTAs Postfix 2.11 unter CentOS7

Postfix-Logo Das schlimmste, was uns passieren kann, wäre der Betrieb eines offenen Mailrelais gefolgt von einem Mailserver der sich beharrlich weigert eMails anzunehmen, zu versenden und weiterzuleiten. Mit unserer Grundinstallation haben wir schon mal den wichtigsten Part Mailrelay mit den Definitionen in der main.cf erschlagen und sichergestellt, dass kein Fremder Nachrichten an Dritte verschickt, für die unser MX sich nicht zuständig und verantwortlich fühlt.

Auch wurde der Versand unserer eMail bereits entsprechend berücksichtigt.

Damit aber nun unser Mailserver nicht jeden Dreck - aka SPAM & Co - annimmt und auch versendet, definieren wir uns nun ein Regelwerk, mit Hilfe dessen wir festlegen, wann unser Server Mails annehmen oder ablehnen soll. Diese Festlegungen erfolgt mit Hilfe der Restrictions.

Der entscheidenste Moment, an dem wir nicht nur SPAM sondern auch all die anderen unerwünschten Nachrichten abzuwehren, ist der Einlieferungszeitpunkt! Was wir nicht annehmen brauchen wir auch später nicht weiterverarbeiten bzw. beachten. Analog dem Briefverkehr legen wir quasi fest, welche Sendungen überhaupt in unseren Briefkasten geworfen werden können und dürfen.

Wie bereits auch schon bei der Grundkonfiguration wurden die wichtigsten Details mit Hilfe der beiden Bücher Postfixbuch und Postfix: Einrichtung, Betrieb und Wartung erarbeitet, bzw. den dortigen Beispielen entnommen.

In der Vergangenheit, dokumentiert in den Konfigurationsbeispielen zu CentOS 5 und CentOS 6, wurden bei den Konfigurationsbeispielen als Basis die Distributionsspezifischen Vorlagen verwendet. Rückblickend ist aber festzustellen, dass einige der (ungeübteren) Administratoren mit unter Schwierigkeiten sich zurecht zu finden, waren doch verschiedene Konfigurationsoptionen etwas verstreut in der /etc/postfix/main.cf verteilt.

Wir werden daher bei den nun folgendem Beispiel zur Konfiguration unter CentOS 7 einen, auf den ersten ungewöhnlichen Schritt unternehmen und die main.cf beiseite legen und eine eigene anlegen; folgende vier Schritte sind hierzu notwendig:

  1. Wir stoppen den vorhandenen Postfix-SMTP-Server.
     # systemctl stop postfix
  2. Anschließend wechseln wir in das Konfigurationsverzeichnis /etc/postfix/.
     # cd /etc/postfix
  3. Nun löschen oder verschieben wir die nicht benötigten Dateien:
    1. löschen
       # rm access canonical generic header_checks relocated virtual transport -f
    2. verschieben
       # mkdir -p /etc/postfix/.orig/
       # mv access canonical generic header_checks relocated virtual transport main.cf /etc/postfix/.orig/ -f
  4. Anlegen einer leeren main.cf.
     # touch main.cf

Somit befinden sich nun nur noch zwei Dateien im Verzeichnis /etc/postfix.

/etc/postfix/
├── main.cf
└── master.cf
 # ls -Al  /etc/postfix/
 total 16
 -rw-r--r--. 1 root root    1 Oct 14 15:50 main.cf
 -rw-r--r--. 1 root root 6220 Sep 24 19:22 master.cf

Zur Strukturierung unserer eigenen main.cf nutzen wir jeweils folgende Überschriftszeile.

################################################################################
## < beschreibenden Text > 
#

Wir werden später die einzelnen Konfigurationsoptionen strukturieren, d.h. zusammenfassen und jeweils bei den betreffenden Sektionen eintragen.

Installations- und Konfigurations Informationen

Als erstes definieren wir alle Installations- und Konfigurationsinformationen, die verwendet werden, wenn eine neue Version von Postfix installiert wird, wie z.B. bei einem Update der Postfixversion. Die nachfolgenden Konfigurationsoptionen sind jeweils entsprechend mit Kommentaren versehen, so dass eine zusätzliche Beschreibung hier im Wiki nicht notwendig ist. Jeweils tiefergehende Inmformationen und Beschreibungen findet man am einfachsten in Wietse's Onlinedokumentation oder in den beiden Eingangs erwähnten Fachbüchern.

 # vim /etc/postfix/main.cf
################################################################################
## INSTALLATIONS-KONFIGURATIONS INFORMATIONEN 
#
# Folgende Default-Parameter werden benutzt, sobald eine neue Postfix-Version 
# installiert wird.
#
# Django : 2014-10-31 - Vollständiger Pfad zum Postfix sendmail Programm, dem
#          zu senmail kompatiblen sendmail Befehl.
# default: sendmail_path = /usr/sbin/sendmail
sendmail_path = /usr/sbin/sendmail.postfix
 
# Django : 2014-10-31 - Vollständiger Pfad zum Postfix newaliases Programm, dem
#          zu sendmail kompatiblen Programm zum Anlegen der Alias Datenbanken.
# default: newaliases_path = /usr/bin/newaliases
newaliases_path = /usr/bin/newaliases.postfix
 
# Django : 2014-10-31 - Vollständiger Pfad zum Postfix qmail-Programm, dem zu
#          sendmail kompatiblen Programm zum Anzeigen der Maile-Queues
# default: mailq_path = /usr/bin/mailq
mailq_path = /usr/bin/mailq.postfix
 
# Django : 2014-10-31 - Gruppe für die Befehle mail submission und queue
#          management. Die Gruppe muss eine numerische eigene ID haben
#          und darf nicht mit anderen Benutzeraccounts geteilt werden,
#          auch nicht mit dem Postfix User! 
# default: setgid_group = postdrop 
setgid_group = postdrop
 
# Django : 2014-10-31 - Pfad für die Postfix Postfix HTML Dokumentation.
# default: html_directory
html_directory = no
 
# Django : 2014-10-31 - Pfad für die Postfix online man-pages.
# default: manpage_directory = /usr/local/man
manpage_directory = /usr/share/man
 
# Django : 2014-10-31 - Pfadangabe für die Postfix Beispielkonfigurationsdateien.
#          Dieser Parameter ist obsolete seit Postfix 2.1.
# default: sample_directory = /etc/postfix
sample_directory = /usr/share/doc/postfix-2.11.3/samples
 
# Django : 2014-10-31 - Pfadangabe für die Postfix README Dateien.
# default: readme_directory = no
readme_directory = /usr/share/doc/postfix-2.11.3/README_FILES

Pfadangaben der lokalen Installation

Als nächstes legen wir in der Section PFADANGABEN DER LOKALEN INSTALLATION die Pfade unserer lokalen Installation fest.

 # vim /etc/postfix/main.cf
################################################################################
## PFADANGABEN DER LOKALEN INSTALLATION
#
# Django : 2014-10-31 - Definition des Speicherortes für die Queue-Dateien von
#          Postfix. Dies ist auch der root-Pfad, falls Postfix in einer
#          chroot-Umgebung laufen sollte. In der Datei examples/chroot-setup
#          findet man bei Bedarf nützliche Hinweise und Beispiele, die 
#          beschreiben, wie man Postfix in einer chroot-Umgebung aufsetzen und 
#          betreiben kann. 
# default: queue_directory = /var/spool/postfix
queue_directory = /var/spool/postfix
 
# Django : 2014-10-31 - Vollständiger Pfad zu allen postXXX-Programmen.
# default: command_directory = /usr/sbin
command_directory = /usr/sbin
 
# Django : 2014-10-31 Vollständiger Pfad zum Verzeichnis, in dem sich alle
#          postfix Daemon Programme (die z.B. auch in der master.cf
#          aufgeführt sind) befinden. Das Verzeichnis muss root gehören!
# default: daemon_directory = /usr/libexec/postfix
daemon_directory = /usr/libexec/postfix
 
# Django : 2014-10-31 - Datenverzeichnis, in dem Postfix alle variablen Daten
#          ablegt, wie z.B. Caches, Zufallszahlen ect. pp. Das Verzeichnis 
#          muss dem nachfolgendem "mail_owner" gehören!
# default: data_directory = /var/lib/postfix
data_directory = /var/lib/postfix

Rechte bei Queues und Prozessen

Im folgendem Schritt definieren wir die RECHTE BEI QUEUES UND PROZESSEN .

 # vim /etc/postfix/main.cf
################################################################################
## RECHTE BEI QUEUES UND PROZESSEN
#
# Django : 2014-10-31 - Definition des Nutzers, unter dem die meisten Postfix
#          Daemons laufen und mit dem die Queue-Dateien geschrieben werden.
#          Die User muss unique sein, d.h. er darf weder einer anderen Gruppe 
#          noch einem Anderen User angehören, sowie fremde Dateirechte und 
#          Prozesse auf dem System besitzen! Also unbedingt einen separaten 
#          Nutzer verwenden! 
# default: mail_owner = postfix
mail_owner = postfix
 
# Django : 2014-10-31 - Festlegung der Defaultrechte, die vom LDA (Local 
#          Delivery Agent) verwendet werden, wenn dieser Nachrichten in eine 
#          externe Datei schreibt, oder einem anderen Befehl übergibt.
#          Der Parameter wird auch verwendet, sollten keine userbezogenen
#          Vorgaben vorhanden sein. 
#          Auf keinen Fall einen privilegierten Nutzer oder gar den Benutzer
#          postfix verwenden!
# default: default_privs = nobody
default_privs = nobody

Debugging

Für ggf. später notwendige Fehlersuchen definieren wir nun die Rahmenbedingungen in der Section DEBUGGING.

 # vim /etc/postfix/main.cf
################################################################################
## DEBUGGING 
#
# Django : 2014-10-31 - Mit dem Parameter "debug_peer_level" wird festgelegt
#          um welchen Faktor der Logging-Level erhöht wird, wenn ein SMTP 
#          Client, ein Hostname oder eine IP-Adresse zu den Definitionen des
#          nachfolgenden "debug_peer_list"-Parameters passt.
# default: debug_peer_level = 2
debug_peer_level = 2
 
# Django : 2014-10-31 : Definition einer Liste aus Netzwerk-Adressen,
#          Namen, IP-Adressen oder entsprechender Postfix-Listen 
#          "type:name", für die der Loglevel gemäß dem obigen Loglevelwert
#          erhöht werden soll.
#          Bsp: debug_peer_list = 127.0.0.1
#               debug_peer_list = some.domain
#               cidr:/etc/postfix/debug_peer_list
# default: debug_peer_list =
 
# Django : 2014-10-13 - Debugger-Befehlszeile
#          Die Option "debugger_command" definiert den kompletten Debug-Aufruf,
#          das ausgeführt werden soll, sofern der Postfix Daemon mit der 
#          Option -D gestartet wurde.
#          Am Ende der Befehlskette sollte man ein "... & sleep 5" anfügen, 
#          damit damit der Debugger genügend Zeit hat loszulegen, bevor das 
#          Programm aufgerufen wird.
#
#          Da wir kein X-System auf unserem Mailserver installiert haben (wozu 
#          auch?), verwenden wir nachfolgendes Beispiel. Als Ergebnis erhalten 
#          wir damit eine Datei mit dem Namen des Prozesses und der zugehörigen 
#          ID, die im Konfigurationsverzeichnis abgespeichert wird.
#
debugger_command =
           PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont;
           echo where) | gdb $daemon_directory/$process_name $process_id 2>&1
           >$config_directory/$process_name.$process_id.log & sleep 5

Zuständigkeiten, vertrauenswürdige Netze und Netzwerk-Definitionen

In der Sektion ZUSTÄNDIGKEITEN, VERTRAUENSWÜRDIGE NETZE UND NETZWERKK-DEFINITIONEN erfolgt nun die Mailserver spezifische Konfiguration.

HINWEISE:

Werden einem Parameter mehrere Optionen zugewiesen, so hat es sich bewährt, diese nicht mit Kommatas getrennt hintereinander aufzuzählen, sondern untereinander „eingerückt“ zu schreiben. Dies erleichtert nicht nur die Lesbarkeit der Konfigurationsdatei, sondern gestattet es uns später durch Voranstellen eines # einzelne Optionen zu deaktivieren.

Bsp.:

  • mynetworks mit allen Netzen.
    mynetworks =
                    127.0.0.0/8
                    [::1]/128
                    10.0.0.0/24
                    10.0.10.0/26
  • mynetworks ohne das Netz 10.0.0.0/24
    mynetworks =
                    127.0.0.0/8
                    [::1]/128
    #                10.0.0.0/24
                    10.0.10.0/26

Wie schon zuvor wurden die einzelnen Optionen mit hilfreichen Kommentaren ergänzt.

 # vim /etc/postfix/main.cf
...
 
################################################################################
## ZUSTÄNDIGKEITEN, VERTRAUENSWÜRDIGE NETZE UND NETZWERKK-DEFINITIONEN
#
# Django : 2014-10-15 - Hostname auf "offiziellen" DNS-MX-Record Namen gesetzt
# default: myhostname = FQDN
myhostname = mx01.nausch.org
 
# Django : 2014-10-15 - Domainpart der lokal generierten Nachrichten gesetzt
# default: myorigin = $myhostname
myorigin = $mydomain
 
# Django : 2014-10-15 - Für welche Domains ist unser Mailserver zuständig,
#          also final destination? Zusätzlich zu den Defaultwerten soll der MTA 
#          auch noch Nachrichten für die beiden Sub-Domains lists.nausch.org 
#          (Mailman) und dmarc.nausch.org (DMARC-Reportmails) annehmen.
# default: mydestination = $myhostname, localhost.$mydomain, localhost
mydestination =
                $myhostname
                localhost.$mydomain
                localhost
                lists.nausch.org
                dmarc.nausch.org
 
# default: unbekannte Empfänger sollen abgewiesen und nicht mit einem
#          temporären Fehler 450 abgewiesen werden.
# default: unknown_local_recipient_reject_code = 550
#          unverified_recipient_reject_code = 450
#unverified_recipient_reject_code = 577
 
# Django : 2014-10-15 - Soll bei einem unbekanntem Ziel der genaue Tabellenname
#          bei der Ablehnung genannt werden?
# default: show_user_unknown_table_name = yes 
show_user_unknown_table_name = no
 
# Django : 2014-10-15 - auf allen Interfaces und Protokollen (IPv4 und IPv6) 
#          soll gelauscht werden 
# default: inet_interfaces = all
# default: inet_protocols = all
 
# Django : 2014-10-15 - Grundsätzlich soll erst einmal unser Mailserver nur dem
#          eigenen Host trauen, sonst niemanden! 
# default: mynetworks_style = subnet
mynetworks_style = host
 
mynetworks =
                127.0.0.0/8
                [::1]/128
                10.0.0.0/24
                10.0.10.0/26
 
# Django : 2015-10-15 - Backup-Mailserver explizit erlauben
# default: permit_mx_backup_networks =
permit_mx_backup_networks = 88.217.171.167/32

Routing

In der Sektion ROUTING - WEITERLEITEN VON NACHRICHTEN AN DAS EIGENTLICHE ZIEL legen wir fest, wo und wie die einzelnen Zielserver erreichbar sind, an die unser Postfix SMTP-Server seine Nachrichten weiterleiten soll.

Auch wenn es für einen kleinen Server erst einmal als Overkill erscheinen mag, den IMAP-Server via LMTP anzusprechen, ist es dennoch von unschätzbaren Wert, sollte später doch noch ein separater IMAP-Server erforderlich sein. Somit muss später „nur“ noch die IP-Adresse oder der Name des IMAP-Servers geändert werden und nicht zusätzlich an der Konfiguration noch grundlegende Anpassungen vorgenommen werden!

 # vim /etc/postfix/main.cf
################################################################################
## ROUTING - WEITERLEITEN VON NACHRICHTEN AN DAS EIGENTLICHE ZIEL
#
# Django : 2014-10-15 - Relayhost: Alle Nachrichten werden an den Relayhost
#          smtp-out.dmz.nausch.org gesendet.
# default: relayhost =
# relayhost = [smtp-out.dmz.nausch.org]
 
# Django : 2014-10-15 - Backup-Relayhost: Sollte der $relayhost nicht erreichbar
#          sein, soll sich unser MTA an den backup-relayhost 
#          smtp-backup.dmz.nausch.org senden
# default: smtp_fallback_relay = $fallback_relay 
# smtp_fallback_relay = [smtp-backup.dmz.nausch.org]
 
# Django : 2014-10-15 - Relay Domains: Postfix als eingehendes Mailrelay vor 
#          einem anderen Server
# default: relay_domains = $mydestination 
relay_domains = btree:/etc/postfix/relay_domains
 
# Django : 2014-10-15 - Nachrichten für eine bestimmte Richtung sollen
#          abweichend von den MX-Definitionen im DNS an dedizierte Ziele
#          geroutet/weitergeleitet werden.
# default: transport_maps =
transport_maps = btree:/etc/postfix/transport_maps
 
# Django : 2014-10-15 - Definition zur Erreichbarkeit unseres MDA-Servers 
#          Dovecot-IMAP
# default: virtual_transport = virtual
virtual_transport = lmtp:[imap.dmz.nausch.org]:24

Queueing

Je nach Kundenwunsch stellen wir für die Mail-Queues eine maximale Verweildauer der Nachrichten in der/den Queues ein. Diese Dinge setzen wir in der Section QUEUEING-VERHALTEN.

 # vim /etc/postfix/main.cf
################################################################################
## QUEUEING-VERHALTEN
#
# Django : 2014-10-18 - Queue-Lifetime auf 3 Tage heruntersetzen, defininiert
#          die maximale Zeit, die der MX versuchen darf, eine Nachricht zuzu-
#          stellen
# default: maximal_queue_lifetime = 5d
maximal_queue_lifetime = 3d
 
# Django : 2014-03-17- Bounce-Queue-Lifetime auf 3 Tage heruntersetzen, die
#          der MTA versuchen soll eine Bouncenachricht zuzustellen.
# default: bounce_queue_lifetime = 5d
bounce_queue_lifetime = 3d

Nachrichtengrößen und Zustellversuche/-Mengen

Wie auch schon in der Section Queueing, gibt es für einzelne Installationen sehr oft Anforderungen im Bezug auf Nachrichtengrößen und Zustellversuche. Hierfür steht nachfolgende Section NACHRICHTENGROESSE UND ZUSTELLVERSUCHE/-MENGEN zur Verfügung.

 # vim /etc/postfix/main.cf
################################################################################
## NACHRICHTENGROESSE UND ZUSTELLVERSUCHE/-MENGEN 
#
# Django : 2014-10-18 Maximale Nachrichtengröße festlegen. Maximale Nachrichten-
#          größe einer Nachricht incl. der Headerinformationen darf maximal 
#          50 MB ( 52428800 = 50*1024*1024 ) betragen, darüber verweigert 
#          Postfix die Annahme. 
# default: message_size_limit = 10240000
message_size_limit = 52428800
 
# Django : 2014-10-18 Maximale Mailboxgröße einer einzelnen Mailbox bzw. 
#          Maildir-Fiels. Der Wert darf nicht kleiner als die maximale 
#          Nachrichtengröße (message_size_limit) sein.
# default: mailbox_size_limit = 10240000
mailbox_size_limit = 52428800
 
# Django : 2010-10-28 - Rate Limiting (DOS-Attacken verhindern) maximale
#          Zustellung limitieren (Kapitel 24 des Buches Postfix)
#          (Kapitel 13.14 Rate-Limiting gegenüber Clients durchsetzen)
#          Basiszeiteinheit für die Kalkulation der rate-limits
# default: anvil_rate_time_unit = 60s
#
#          Maximale Anzahl gleichzeitiger Verbindungen pro einliefernenden Host
# default : smtpd_client_connection_count_limit = 50 
smtpd_client_connection_count_limit = 20
#
#          Maximale Anzahl von Verbindungsversuchen je definierter Zeiteinheit 
#          (anvil_rate_time_unit) pro einliefernden Host
# default: smtpd_client_connection_rate_limit = 0
smtpd_client_connection_rate_limit = 20
#
#          Maximale Anzahl von erlaubten Empfänger Adressen je definierter 
#          Zeiteinheit (anvil_rate_time_unit) pro einliefernden Host
# default: smtpd_client_recipient_rate_limit = 0
smtpd_client_recipient_rate_limit = 50
#
#          Maximale Anzahl von erlaubten Anzahl von eMails je definierter Zeit-
#          einheit (anvil_rate_time_unit) pro einliefernden Host
# deafault: smtpd_client_message_rate_limit = 0
smtpd_client_message_rate_limit = 50
#
#          Welche Cleints sollen vom Rate-Limeting ausgenommen werden? Per
#          Default sind dies alle Clients aus dem eigenen Netzwerk $mynetworks
# default: smtpd_client_event_limit_exceptions = 
#          ${smtpd_client_connection_limit_exceptions:$mynetworks}
#
#          Wie oft soll der anvil-Daemon Statistikdaten ins Maillog schreiben?
# default: anvil_status_update_time = 600s         
#
#          Ausgehende Verbindungen der Delivery-Clients limitieren. Für jeden
#          einzelnen Transport kann bei Bedarf eine eigene Rate definiert 
#          werden.
# default: default_destination_rate_delay = 0s
#          error_destination_rate_delay = $default_destination_rate_delay
#          lmtp_destination_rate_delay = $default_destination_rate_delay
#          local_destination_rate_delay = $default_destination_rate_delay
#          relay_destination_rate_delay = $default_destination_rate_delay
#          retry_destination_rate_delay = $default_destination_rate_delay
#          smtp_destination_rate_delay = $default_destination_rate_delay
#          virtual_destination_rate_delay = $default_destination_rate_delay
#          Ausgehende Nachrichten des Mailinglistenservers auf 2,5 Minuten
#          setzen
smtp_destination_rate_delay = 150s

WICHTIG:
Die Option gilt für alle Clients! Das bedeutet, dass ein smtp_destination_rate_delay = 150s die Zustellversuche an alle SMTP-Ziele gilt. Im Maillog des Servers wird nicht extra ein Hinweis eingetragen, dass das rate_limiting zugeschlagen hat!

Rückmeldungen beeinflussen und individualisieren

In der Section RÜCKMELDUNGEN BEEINFLUSSEN UND INDIVIDUALISIEREN können wir festlegen, welche Informationen unser Mailserver unterdrücken und weitergeben soll. Auch eine Individualisierung auf Mailserverbetreiberebene sind möglich.

So werden z.B. bei der Option smtpd_reject_footer zusätzlich zu dem Fehlercode noch weitere Informationen zur Rückmeldemöglichkeit über den Roleaccount postmaster@ gegeben. Die anderen Optionen sind in dem Konfigurationsabschnitt entsprechend erklärt.

 # vim /etc/postfix/main.cf
################################################################################
## RÜCKMELDUNGEN BEEINFLUSSEN UND INDIVIDUALISIEREN
#
# Django : 2014-10-18 - Greeting Banner bei der 220er Begrüßung des MTA
smtpd_banner = $myhostname ESMTP $mail_name
 
# Django : 2014-10-16 - Extra-Footer bls zweite Zeiler jeder Fehlermeldungen 
#          anfügen
smtpd_reject_footer = \c. Contact your postmaster/admin for technical assistance. He can achieve our postmaster via email: postmaster@nausch.org or via fax: +49 8121 883179. In any case, please provide the following information in your problem report: This error message, time ($localtime), client ($client_address) and server ($server_name).
 
# Django : 2014-10-16 - Anzeige des Tabellen-Namens, in der der Empfänger
#          nicht gefunden wurde. Das unterdrücken macht unter Umständen die
#          Fehlersuche etwas aufwändiger, aber Externen geht diese Detailinfo
#          im Grunde nichts an. 
# default: show_user_unknown_table_name = yes
show_user_unknown_table_name = no
 
# Django : 2014-10-24 - Adressverifikationsdetails unterdrücken
#          Weder den numerischen SMTP-reply-Code, noch den enhanced status code
#          zurückgeben. Lediglich "Recipient address lookup failed" zurückmelden.
# default: unverified_recipient_reject_reason =
unverified_recipient_reject_reason = Recipient address lookup failed
 
# Django : 2014-10-24 - Adressverifikationsdetails unterdrücken
#          Weder den numerischen SMTP-reply-Code, noch den enhanced status code
#          zurückgeben. Lediglich "Recipient address lookup failed" zurückmelden.
# default: unverified_sender_reject_reason =
unverified_sender_reject_reason = Sender address lookup failed
 
# Django : 2014-10-18 Definition der benutzerspezifischen und individualisierten 
#          Bounce-Nachrichten mit deutsch- und englischsprachigen Texten aktiviert
# default: bounce_template_file =
bounce_template_file = /etc/postfix/bounce.de-DE.cf
 
# Django : 2014-10-18 - Delivery Status Notification (DSN) selectiv sperren
#          oder freigeben
# default: smtpd_discard_ehlo_keyword_address_maps =
smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_access
 
# Django : 2014-10-18 - SMTP-Kommando VRFY sperren, mit dem eine einfache und
#          schnelle Addressverifizierung möglich ist.
# default: disable_vrfy_command = no
disable_vrfy_command = yes
 
# Django : 2015-10-08 - Fehlercode bei Verwendung der Option
#          reject_plaintext_session beim Einsatz von verpflichtender
#          TLS-Transportverschlüsselung.
#          https://tools.ietf.org/html/rfc3463#section-3.8
# default: plaintext_reject_code = 450
# plaintext_reject_code = 571

Da wir ja nicht nur englischsprachige Nutzer haben, die bei unserem MX Post abliefern dürfen, möchten wir unter Umständen auch individuelle Bouncemessages verwenden. In der Sektion RÜCKMELDUNGEN BEEINFLUSSEN UND INDIVIDUALISIEREN haben wir bereits den Parameter bounce_template_file gesetzt. was uns jetzt noch fehlt ist das zugehörige File. Dieses mustergültiges Nachrichtentemplate von den beiden Spezialisten Patrick Koetter und Ralf Hildebrandt aus dem Web herunter.

 # cd /etc/postfix
 # wget http://postfix.state-of-mind.de/bounce-templates/bounce.de-DE.cf

Bevor wir uns nun die einzelnen Lookup-Tabellen genauer ansehen, werfen wir noch einen Blick in die nachfolgende Übersicht um festzustellen, wann die einzelnen Tabellen in der Mailbearbeitung gezogen werden, also überhaupt einen Einfluß haben.

Postfix MTA

Am Anfang der Definition unserer Lookup-Tabellen setzen wir noch zwei (Adress-)Listenspezifische Werte. Statt der Defaultmäßigen Tabellen im hash-Format setzen wir auf die wesentlich performanteren btree-Tabellen.

Damit wir später unsere Datenbankfiles einfach durch den Aufruf

 # postmap <lookup-table>

anlegen können, setzen wir noch den Wert default_database_type auf btree. Anderen Falls müssten wir bei jedem Aufruf von postmap den Datenbanktabellentyp mit angeben!

 # postmap btree:<lookup-table>
# Django : 2014-10-15 - default Datenbank Typ für die Befehle newaliases, 
#          postalias und postmap auf das performantere btree umgestellt.
# default default_database_type = hash
default_database_type = btree

Zur Abtrennung von Usernamen und Adresserweiterung wollen das +-Zeichen verwenden. Diese Festlegung erfolgt über die Option recipient_delimiter. Mit Hilfe dieses Zeichens können die Mailboxinhaber Benutzerspezifische zusätzliche Adressen generieren, um z.B. später mit Hilfe von sieve-Regeln ankommende Nachrichten in gewünschte unterordner einsortieren zu lassen.

# Django : 2014-10-15 - Trennzeichen zwischen Usernamen und Adresserweiterung 
# default: recipient_delimiter =
recipient_delimiter = +

aliases

Mit Hilfe der aliases-Tabelle lassen sich lokale eMailadressen umschreiben und so die Nachrichten an andere Postfacher umleiten. Die Alias-Tabelle aliases und die zugehörige Datenbankdatei aliases.db befinden sich aus historischen Gründen nicht im Postfix-Konfigurationspfad /etc/postfix sondern im Verzeichnis /etc.

Im Gegensatz zu den anderen Tabellen, wird der erste Tabellenwert jeweils mit einem : abgeschlossen.

Bsp.:

# Django : 2014-10-15 - Weiterleitung an den User django
root:           django@nausch.org

Dieser Doppelpunkt bedingt dann auch, dass die zugehörige indizierte Map-Datei nicht mit dem Befehl postmap erstellt wird, sondern mit newaliases.

 # less /etc/aliases*
/etc/aliases
#
#  Aliases in this file will NOT be expanded in the header from
#  Mail, but WILL be visible over networks or from /bin/mail.
#
#	>>>>>>>>>>	The program "newaliases" must be run after
#	>> NOTE >>	this file is updated for any changes to
#	>>>>>>>>>>	show through to sendmail.
#
 
# Basic system aliases -- these MUST be present.
mailer-daemon:	postmaster
postmaster:	root
 
# General redirections for pseudo accounts.
bin:		root
daemon:		root
adm:		root
lp:		root
sync:		root
shutdown:	root
halt:		root
mail:		root
news:		root
uucp:		root
operator:	root
games:		root
gopher:		root
ftp:		root
nobody:		root
radiusd:	root
nut:		root
dbus:		root
vcsa:		root
canna:		root
wnn:		root
rpm:		root
nscd:		root
pcap:		root
apache:		root
webalizer:	root
dovecot:	root
fax:		root
quagga:		root
radvd:		root
pvm:		root
amanda:		root
privoxy:	root
ident:		root
named:		root
xfs:		root
gdm:		root
mailnull:	root
postgres:	root
sshd:		root
smmsp:		root
postfix:	root
netdump:	root
ldap:		root
squid:		root
ntp:		root
mysql:		root
desktop:	root
rpcuser:	root
rpc:		root
nfsnobody:	root
 
ingres:		root
system:		root
toor:		root
manager:	root
dumper:		root
abuse:		root
 
newsadm:	news
newsadmin:	news
usenet:		news
ftpadm:		ftp
ftpadmin:	ftp
ftp-adm:	ftp
ftp-admin:	ftp
www:		webmaster
webmaster:	root
noc:		root
security:	root
hostmaster:	root
info:		postmaster
marketing:	postmaster
sales:		postmaster
support:	postmaster
 
 
# trap decode to catch security attacks
decode:		root
 
# Person who should get root's mail
#root:		marc
# Django : 2014-10-15 - Weiterleitung an den User django
root:           django@nausch.org

Achtung: Die aliases-Tabelle wird nur vom Postfix-Modul local ausgewertet, wenn diese lokal zugestellt werden. Erfolgt die Zustellung mit Hilfe von LMTP oder SMTP oder anderen Transportmethoden, wird die aliases-Tabelle ignoriert!

access

manpage

In der Manpage zu access bzw. in der Datei /etc/postfix/access finden wir detaillierte Informationen zur access - Postfix SMTP server access table.

 # man 5 access
ACCESS(5)                            File Formats Manual                           ACCESS(5)

NAME
       access - Postfix SMTP server access table

SYNOPSIS
       postmap /etc/postfix/access

       postmap -q "string" /etc/postfix/access

       postmap -q - /etc/postfix/access <inputfile

DESCRIPTION
       This document describes access control on remote SMTP client information: host names,
       network addresses, and envelope sender or recipient addresses; it is  implemented  by
       the  Postfix  SMTP server.  See header_checks(5) or body_checks(5) for access control
       on the content of email messages.

       Normally, the access(5) table is specified as a text file that serves as input to the
       postmap(1)  command.   The  result,  an indexed file in dbm or db format, is used for
       fast searching by the mail system. Execute the command "postmap  /etc/postfix/access"
       to rebuild an indexed file after changing the corresponding text file.

       When the table is provided via other means such as NIS, LDAP or SQL, the same lookups
       are done as for ordinary indexed files.

       Alternatively, the table can be provided as a regular-expression map  where  patterns
       are  given as regular expressions, or lookups can be directed to TCP-based server. In
       those cases, the lookups are done in a slightly  different  way  as  described  below
       under "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES".

CASE FOLDING
       The  search  string is folded to lowercase before database lookup. As of Postfix 2.3,
       the search string is not case folded with database types such  as  regexp:  or  pcre:
       whose lookup fields can match both upper and lower case.

TABLE FORMAT
       The input format for the postmap(1) command is as follows:

       pattern action
              When  pattern matches a mail address, domain or host address, perform the cor‐
              responding action.

       blank lines and comments
              Empty lines and whitespace-only lines are ignored, as are  lines  whose  first
              non-whitespace character is a `#'.

       multi-line text
              A logical line starts with non-whitespace text. A line that starts with white‐
              space continues a logical line.

EMAIL ADDRESS PATTERNS
       With lookups from indexed files such as DB or DBM, or from networked tables  such  as
       NIS, LDAP or SQL, patterns are tried in the order as listed below:

       user@domain
              Matches the specified mail address.

       domain.tld
              Matches domain.tld as the domain part of an email address.

              The  pattern  domain.tld  also  matches  subdomains,  but only when the string
              smtpd_access_maps is listed in  the  Postfix  parent_domain_matches_subdomains
              configuration setting.

       .domain.tld
              Matches  subdomains  of domain.tld, but only when the string smtpd_access_maps
              is not listed in the  Postfix  parent_domain_matches_subdomains  configuration
              setting.

       user@  Matches all mail addresses with the specified user part.

       Note: lookup of the null sender address is not possible with some types of lookup ta‐
       ble. By default, Postfix uses <> as the lookup key for such addresses. The  value  is
       specified  with  the  smtpd_null_access_lookup_key  parameter  in the Postfix main.cf
       file.

EMAIL ADDRESS EXTENSION
       When a mail address  localpart  contains  the  optional  recipient  delimiter  (e.g.,
       user+foo@domain),  the  lookup  order  becomes: user+foo@domain, user@domain, domain,
       user+foo@, and user@.

HOST NAME/ADDRESS PATTERNS
       With lookups from indexed files such as DB or DBM, or from networked tables  such  as
       NIS, LDAP or SQL, the following lookup patterns are examined in the order as listed:

       domain.tld
              Matches domain.tld.

              The  pattern  domain.tld  also  matches  subdomains,  but only when the string
              smtpd_access_maps is listed in  the  Postfix  parent_domain_matches_subdomains
              configuration setting.

       .domain.tld
              Matches  subdomains  of domain.tld, but only when the string smtpd_access_maps
              is not listed in the  Postfix  parent_domain_matches_subdomains  configuration
              setting.

       net.work.addr.ess

       net.work.addr

       net.work
       net    Matches the specified IPv4 host address or subnetwork. An IPv4 host address is
              a sequence of four decimal octets separated by ".".

              Subnetworks are matched by repeatedly truncating the last  ".octet"  from  the
              remote IPv4 host address string until a match is found in the access table, or
              until further truncation is not possible.

              NOTE 1: The access map lookup key must be in canonical form:  do  not  specify
              unnecessary  null  characters,  and do not enclose network address information
              with "[]" characters.

              NOTE 2: use the cidr lookup table type to  specify  network/netmask  patterns.
              See cidr_table(5) for details.

       net:work:addr:ess

       net:work:addr

       net:work

       net    Matches the specified IPv6 host address or subnetwork. An IPv6 host address is
              a sequence of three to eight hexadecimal octet pairs separated by ":".

              Subnetworks are matched by repeatedly truncating the  last  ":octetpair"  from
              the  remote  IPv6 host address string until a match is found in the access ta‐
              ble, or until further truncation is not possible.

              NOTE 1: the truncation and comparison are done with the string  representation
              of the IPv6 host address. Thus, not all the ":" subnetworks will be tried.

              NOTE  2:  The  access map lookup key must be in canonical form: do not specify
              unnecessary null characters, and do not enclose  network  address  information
              with "[]" characters.

              NOTE  3:  use  the cidr lookup table type to specify network/netmask patterns.
              See cidr_table(5) for details.

              IPv6 support is available in Postfix 2.2 and later.

ACCEPT ACTIONS
       OK     Accept the address etc. that matches the pattern.

       all-numerical
              An all-numerical result is treated as OK. This format is generated by address-
              based relay authorization schemes such as pop-before-smtp.

       For other accept actions, see "OTHER ACTIONS" below.

REJECT ACTIONS
       Postfix  version  2.3 and later support enhanced status codes as defined in RFC 3463.
       When no code is specified at the beginning of  the  text  below,  Postfix  inserts  a
       default enhanced status code of "5.7.1" in the case of reject actions, and "4.7.1" in
       the case of defer actions. See "ENHANCED STATUS CODES" below.

       4NN text

       5NN text
              Reject the address etc. that matches the pattern, and respond with the numeri‐
              cal  three-digit  code  and text. 4NN means "try again later", while 5NN means
              "do not try again".

              The following responses have special meaning for the Postfix SMTP server:

              421 text (Postfix 2.3 and later)

              521 text (Postfix 2.6 and later)
                     After responding with the numerical three-digit code and text,  discon‐
                     nect  immediately  from  the  SMTP  client.   This frees up SMTP server
                     resources so that they can be made available to another SMTP client.

                     Note: The "521" response should be used only  with  botnets  and  other
                     malware  where  interoperability  is  of no concern.  The "send 521 and
                     disconnect" behavior is NOT defined in the SMTP standard.

       REJECT optional text...
              Reject   the   address   etc.   that   matches   the   pattern.   Reply   with
              "$access_map_reject_code  optional  text..."  when the optional text is speci‐
              fied, otherwise reply with a generic error response message.

       DEFER optional text...
              Reject   the   address   etc.   that   matches   the   pattern.   Reply   with
              "$access_map_defer_code optional text..." when the optional text is specified,
              otherwise reply with a generic error response message.

              This feature is available in Postfix 2.6 and later.

       DEFER_IF_REJECT optional text...
              Defer the request if some later restriction would result in a  REJECT  action.
              Reply  with  "$access_map_defer_code 4.7.1 optional text..." when the optional
              text is specified, otherwise reply with a generic error response message.

              Prior to Postfix 2.6, the SMTP reply code is 450.

              This feature is available in Postfix 2.1 and later.

       DEFER_IF_PERMIT optional text...
              Defer the request if some later restriction would result in a an  explicit  or
              implicit  PERMIT  action.   Reply with "$access_map_defer_code 4.7.1  optional
              text..." when the optional text is specified, otherwise reply with  a  generic
              error response message.

              Prior to Postfix 2.6, the SMTP reply code is 450.

              This feature is available in Postfix 2.1 and later.

       For other reject actions, see "OTHER ACTIONS" below.

OTHER ACTIONS
       restriction...
              Apply the named UCE restriction(s) (permit, reject, reject_unauth_destination,
              and so on).

       BCC user@domain
              Send one copy of the message to the specified recipient.

              If multiple BCC actions are specified within the same SMTP  MAIL  transaction,
              only the last action will be used.

              This feature is not part of the stable Postfix release.

       DISCARD optional text...
              Claim  successful delivery and silently discard the message.  Log the optional
              text if specified, otherwise log a generic message.

              Note: this action currently affects all recipients of the message.  To discard
              only one recipient without discarding the entire message, use the transport(5)
              table to direct mail to the discard(8) service.

              This feature is available in Postfix 2.0 and later.

       DUNNO  Pretend that the lookup key was not found. This prevents Postfix  from  trying
              substrings  of  the lookup key (such as a subdomain name, or a network address
              subnetwork).

              This feature is available in Postfix 2.0 and later.

       FILTER transport:destination
              After the message is queued, send the entire  message  through  the  specified
              external  content  filter.  The  transport name specifies the first field of a
              mail delivery agent definition in master.cf; the syntax of the next-hop desti‐
              nation  is  described  in the manual page of the corresponding delivery agent.
              More information about  external  content  filters  is  in  the  Postfix  FIL‐
              TER_README file.

              Note  1:  do not use $number regular expression substitutions for transport or
              destination unless you know that the information has a trusted origin.

              Note 2: this action overrides the main.cf content_filter setting, and  affects
              all  recipients of the message. In the case that multiple FILTER actions fire,
              only the last one is executed.

              Note 3: the purpose of the FILTER command is to override message routing.   To
              override  the  recipient's transport but not the next-hop destination, specify
              an empty filter destination (Postfix 2.7  and  later),  or  specify  a  trans‐
              port:destination  that  delivers through a different Postfix instance (Postfix
              2.6 and earlier). Other options are using the  recipient-dependent  transport‐
              _maps  or  the  sender-dependent  sender_dependent_default_transport_maps fea‐
              tures.

              This feature is available in Postfix 2.0 and later.

       HOLD optional text...
              Place the message on the hold queue, where it will sit  until  someone  either
              deletes  it  or releases it for delivery.  Log the optional text if specified,
              otherwise log a generic message.

              Mail that is placed on hold can be examined with the postcat(1)  command,  and
              can be destroyed or released with the postsuper(1) command.

              Note:  use "postsuper -r" to release mail that was kept on hold for a signifi‐
              cant fraction of $maximal_queue_lifetime or $bounce_queue_lifetime, or longer.
              Use  "postsuper  -H"  only for mail that will not expire within a few delivery
              attempts.

              Note: this action currently affects all recipients of the message.

              This feature is available in Postfix 2.0 and later.

       PREPEND headername: headervalue
              Prepend the specified message header to  the  message.   When  more  than  one
              PREPEND  action executes, the first prepended header appears before the second
              etc. prepended header.

              Note: this action must execute before the message content is received; it can‐
              not execute in the context of smtpd_end_of_data_restrictions.

              This feature is available in Postfix 2.1 and later.

       REDIRECT user@domain
              After the message is queued, send the message to the specified address instead
              of the intended recipient(s).

              Note: this action overrides the  FILTER  action,  and  currently  affects  all
              recipients of the message.

              This feature is available in Postfix 2.1 and later.

       WARN optional text...
              Log  a warning with the optional text, together with client information and if
              available, with helo, sender, recipient and protocol information.

              This feature is available in Postfix 2.1 and later.

ENHANCED STATUS CODES
       Postfix version 2.3 and later support enhanced status codes as defined in  RFC  3463.
       When  an enhanced status code is specified in an access table, it is subject to modi‐
       fication. The following transformations are needed when the same access table is used
       for client, helo, sender, or recipient access restrictions; they happen regardless of
       whether Postfix replies to a MAIL FROM, RCPT TO or other SMTP command.

       ·      When a sender address matches a REJECT action, the Postfix  SMTP  server  will
              transform  a  recipient  DSN status (e.g., 4.1.1-4.1.6) into the corresponding
              sender DSN status, and vice versa.

       ·      When non-address information matches a REJECT action (such as the HELO command
              argument  or the client hostname/address), the Postfix SMTP server will trans‐
              form a sender or recipient DSN status into a generic  non-address  DSN  status
              (e.g., 4.0.0).

REGULAR EXPRESSION TABLES
       This  section  describes  how the table lookups change when the table is given in the
       form of regular expressions. For a description of  regular  expression  lookup  table
       syntax, see regexp_table(5) or pcre_table(5).

       Each  pattern  is  a  regular  expression  that is applied to the entire string being
       looked up. Depending on the application, that string is an entire client hostname, an
       entire client IP address, or an entire mail address. Thus, no parent domain or parent
       network search is done, user@domain mail addresses are not broken up into their user@
       and domain constituent parts, nor is user+foo broken up into user and foo.

       Patterns are applied in the order as specified in the table, until a pattern is found
       that matches the search string.

       Actions are the same as with indexed file lookups, with the additional  feature  that
       parenthesized substrings from the pattern can be interpolated as $1, $2 and so on.

TCP-BASED TABLES
       This  section  describes  how the table lookups change when lookups are directed to a
       TCP-based server. For a description of the TCP  client/server  lookup  protocol,  see
       tcp_table(5).  This feature is not available up to and including Postfix version 2.4.

       Each  lookup  operation uses the entire query string once.  Depending on the applica‐
       tion, that string is an entire client hostname, an entire client IP  address,  or  an
       entire  mail  address.   Thus,  no  parent  domain  or parent network search is done,
       user@domain mail addresses are not broken up into their user@ and domain  constituent
       parts, nor is user+foo broken up into user and foo.

       Actions are the same as with indexed file lookups.

EXAMPLE
       The  following  example uses an indexed file, so that the order of table entries does
       not matter. The example permits access by the client at address 1.2.3.4  but  rejects
       all other clients in 1.2.3.0/24. Instead of hash lookup tables, some systems use dbm.
       Use the command "postconf -m" to find out what lookup tables Postfix supports on your
       system.

       /etc/postfix/main.cf:
           smtpd_client_restrictions =
               check_client_access hash:/etc/postfix/access

       /etc/postfix/access:
           1.2.3   REJECT
           1.2.3.4 OK

       Execute the command "postmap /etc/postfix/access" after editing the file.

BUGS
       The table format does not understand quoting conventions.

SEE ALSO
       postmap(1), Postfix lookup table manager
       smtpd(8), SMTP server
       postconf(5), configuration parameters
       transport(5), transport:nexthop syntax

README FILES
       Use  "postconf readme_directory" or "postconf html_directory" to locate this informa‐
       tion.
       SMTPD_ACCESS_README, built-in SMTP server access control
       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

                                                                                   ACCESS(5)

Wir editieren nun aber nicht diese Vorlage- und Musterdatei /etc/postfix/access, sondern legen uns für die einzelnen Anwendungsfälle eigene Dateien an, auch wenn diese eventuell erst einmal ohne Inhalt sind. Wir haben so später kein Problem mehr, wenn wir ad hoc auf eine Anforderung schnell reagieren müssen.

Access-Aktionen

Bei den einzelnen folgenden Access-Tabellen stehen uns folgende Access-Aktionen zur Verfügung:

Steuerwort Ergebnis
OK Die Anfrage wird zugelassen
BCCuser@domäne.tld Sendet die empfangene eMail an einen gesonderten Empfänger als Blindcopy bcc
DEFER_IF_REJECT Wenn ein nachfolgender Test einen fatalen REJECT liefern würde, wird an den Client ein temporärer Fehler (4xx) signalisiert.
DEFER_IF_PERMIT Signalisiert an den Client einen temporären Fehler (4xx), obwohl die eMail sonst angenommen worden wäre.
DISCARD Die eMail wird für alle Empfänger verworfen, sobald nur ein einzelner Empfänger diesen DISCARD auslöst! Dem einliefernden Client wird eine erfolgreiche Zustellung signalisiert.
DUNNO Die Anfrage wird nicht abgelehnt, liefert jedoch auch kein ausdrückliches OK zurück. Die Access-Prüfung wird beendet - weitere Prüfungen können jedoch nich erfolgen.
FILTERnexthop Routet die eMail an nexthop und überschreibt dabei die Einstellung content_Filter
HOLD Nimmt die eMail entgegen und stellt diese in die hold-Queue
PREPENDMailheader:Wert Fügt in den Mailheader der eMail den Mailheader:Wert ein.
REDIRECTuser@domäne.tld Leitet die eMail an die neue eMail-Adresse um und verwirft dabei alle anderen angegebenen Empfänger!
REJECT Die Anfrage wird mit einem fatalen Fehlercode 5xx abgelehnt
REJECTHinweistext Die Anfrage wird abgelehnt und der Text Hinweistext ausgegeben
4xxHinweistext Die Anfrage wird mit einem temporären Fehlercode 4xx und dem Text Hinweistext abgelehnt
5xxHinweistext Die Anfrage wird mit einem fatalen Fehlercode 5xx und dem Text Hinweistext abgelehnt
WARNHinweistext Im Maillog des Mailservers wird ein Logeintrag mit den Informationen:
- Absender
- Empfänger
- HELO
- etc.
zusammen mit dem Hinweistext eingefügt.
restriction Es kommt eine der permit- oder reject-Restrictions-Regeln zur Anwendung

Access-Dateien

check_client_access
  • access_client Access-Tabelle zum Black- und Whitelisten einzelner Hosts auf Basis ihrer IP-Adresse. Damit wir auch Netzbereiche in der Form 10.0.10.1/28, also mit IP-Adressen mit einer Netzmaske versehen, nutzen können, dürfen wir hier nicht btree als Datenbankformat verwenden! Wir greifen hier auf cidr-Maps zurück!
     # vim /etc/postfix/access_client
    /etc/postfix/access_client
    # Django : 2012-02-06
    # Kapitel 5.2.7 access-Tabelle: Wer darf, wer darf nicht?
    # Tabelle zum black- und whitelisten einzelner Hosts auf Basis ihrer 
    # IP-Adressen nach dem Ändern und/oder Erweitern der Tabelle, muß ein
    # laufender Postfix über die Änderungen mit einem reload informiert 
    # werden: 
    #             $ systemctl reload postfix.service
    #
    # Es muss hier keine Datenbank mit postmap erzeugt werden, da 
    # Postfix die ASCII-Konfigurationsdatei direkt auswertet!
    #
    #
    #10.20.30.40/26        REJECT
check_helo_access
  • access_helo Access-Tabelle zum Black- und Whitelisten einzelner Hosts auf Grund seines HELO-Namens.
    access_helo.db Datenbankfile zur access_helo-Datei.
     # vim /etc/postfix/access_helo
    /etc/postfix/access_helo
    # Django : 2012-02-06
    # Kapitel 5.2.7 access-Tabelle: Wer darf, wer darf nicht?
    # Tabelle zum black- und whitelisten einzelner Hosts auf Grund seines 
    # HELO-Namens. Nach dem Ändern und/oder Erweitern der Tabelle, muß noch 
    # mittels:
    #             $ postmap /etc/postfix/access_helo
    #
    # die zugehörige Datenbank erzeugt werden.
    #
check_recipient_access-rfc
  • access_recipient-rfc Access-Tabelle zum Black- und Whitelisten einzelner aufgaben- oder funktionsgebundener E-Mail-Adressen (Role-Accounts).
    access_recipient-rfc.db Datenbankfile zur access_recipient-rfc-Datei.
     # vim /etc/postfix/access_recipient-rfc
    /etc/postfix/access_recipient-rfc
    # Django : 2012-02-06
    # Postmaster, abuse und andere aufgaben- oder funktionsgebundene eMail-Adressen
    # (Role-Accounts) whitelisten. Nach dem Ändern und/oder Erweiterrn der Tabelle, 
    # muß noch mittels:
    #             $ postmap /etc/postfix/access_recipient-rfc
    #
    # die zugehörige Datenbank erzeugt werden.
    abuse@          OK
    postmaster@     OK
check_recipient_access
  • access_recipient Access-Tabelle zum Black- und Whitelisten einzelner Hosts auf Grund der Empfänger-eMailadresse.
    access_recipient.db Datenbankfile zur access_recipient-Datei.
     # vim /etc/postfix/access_recipient
    /etc/postfix/access_recipient
    # Django : 2012-02-06
    # Kapitel 5.2.7 access-Tabelle: Wer darf, wer darf nicht?
    # Tabelle zum black- und whitelisten einzelne Empfänger auf Basis ihrer 
    # eMail-Adresse. Nach dem Ändern und/oder Erweitern der Tabelle, muß noch 
    # mittels:
    #                $ postmap /etc/postfix/access_recipient
    #
    # die zugehörige Datenbank erzeugt werden.
    #
    dj4n90@piraten-it.guru  DEFER_IF_PERMIT
check_sender_access
  • access_sender Access-Tabelle zum Black- und Whitelisten einzelner Absender auf Grund der Absender-eMailadresse.
    access_sender.db Datenbankfile zur access_sender-Datei.
     # vim /etc/postfix/access_sender
    /etc/postfix/access_sender
    # Django : 2012-02-06
    # Kapitel 5.2.7 access-Tabelle: Wer darf, wer darf nicht?
    # Tabelle zum black- und whitelisten einzelner Absender auf Basis ihrer 
    # eMail-Adresse. Nach dem Ändern und/oder Erweitern der Tabelle, muß noch 
    # mittels:
    #                  $ postmap /etc/postfix/access_sender
    #
    # die zugehörige Datenbank erzeugt werden.
    #
    #tachtler.net          reject_plaintext_session

canonical

Lookup-Tabelle zum Umschreibungen von Absender und/oder Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail.

manpage

In der Manpage zu canonical bzw. in der Datei /etc/postfix/canonical finden wir detaillierte Informationen zur canonical - Postfix canonical table format.

 # man 5 canonical
CANONICAL(5)                         File Formats Manual                        CANONICAL(5)

NAME
       canonical - Postfix canonical table format

SYNOPSIS
       postmap /etc/postfix/canonical

       postmap -q "string" /etc/postfix/canonical

       postmap -q - /etc/postfix/canonical <inputfile

DESCRIPTION
       The  optional canonical(5) table specifies an address mapping for local and non-local
       addresses. The mapping is used by the cleanup(8) daemon, before mail is  stored  into
       the queue.  The address mapping is recursive.

       Normally,  the canonical(5) table is specified as a text file that serves as input to
       the postmap(1) command.  The result, an indexed file in dbm or db format, is used for
       fast  searching by the mail system. Execute the command "postmap /etc/postfix/canoni‐
       cal" to rebuild an indexed file after changing the corresponding text file.

       When the table is provided via other means such as NIS, LDAP or SQL, the same lookups
       are done as for ordinary indexed files.

       Alternatively,  the  table can be provided as a regular-expression map where patterns
       are given as regular expressions, or lookups can be directed to TCP-based server.  In
       those  cases,  the  lookups  are  done in a slightly different way as described below
       under "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES".

       By default the canonical(5) mapping  affects  both  message  header  addresses  (i.e.
       addresses  that  appear inside messages) and message envelope addresses (for example,
       the addresses that are used in SMTP protocol commands). This is controlled  with  the
       canonical_classes parameter.

       NOTE: Postfix versions 2.2 and later rewrite message headers from remote SMTP clients
       only if the client matches the  local_header_rewrite_clients  parameter,  or  if  the
       remote_header_rewrite_domain  configuration parameter specifies a non-empty value. To
       get  the  behavior  before  Postfix  2.2,  specify  "local_header_rewrite_clients   =
       static:all".

       Typically,  one  would  use  the  canonical(5) table to replace login names by First‐
       name.Lastname, or to clean up addresses produced by legacy mail systems.

       The canonical(5) mapping is not to be confused with virtual  alias  support  or  with
       local  aliasing. To change the destination but not the headers, use the virtual(5) or
       aliases(5) map instead.

CASE FOLDING
       The search string is folded to lowercase before database lookup. As of  Postfix  2.3,
       the  search  string  is  not case folded with database types such as regexp: or pcre:
       whose lookup fields can match both upper and lower case.

TABLE FORMAT
       The input format for the postmap(1) command is as follows:

       pattern address
              When pattern matches a mail address, replace it by the corresponding address.

       blank lines and comments
              Empty lines and whitespace-only lines are ignored, as are  lines  whose  first
              non-whitespace character is a `#'.

       multi-line text
              A logical line starts with non-whitespace text. A line that starts with white‐
              space continues a logical line.

TABLE SEARCH ORDER
       With lookups from indexed files such as DB or DBM, or from networked tables  such  as
       NIS, LDAP or SQL, patterns are tried in the order as listed below:

       user@domain address
              Replace user@domain by address. This form has the highest precedence.

              This  is useful to clean up addresses produced by legacy mail systems.  It can
              also be used to produce Firstname.Lastname style addresses, but see below  for
              a simpler solution.

       user address
              Replace  user@site  by  address  when site is equal to $myorigin, when site is
              listed in  $mydestination,  or  when  it  is  listed  in  $inet_interfaces  or
              $proxy_interfaces.

              This form is useful for replacing login names by Firstname.Lastname.

       @domain address
              Replace other addresses in domain by address.  This form has the lowest prece‐
              dence.

              Note: @domain  is  a  wild-card.  When  this  form  is  applied  to  recipient
              addresses,  the  Postfix SMTP server accepts mail for any recipient in domain,
              regardless of whether that recipient exists.  This may turn your  mail  system
              into a backscatter source: Postfix first accepts mail for non-existent recipi‐
              ents and then tries to return that mail as "undeliverable" to the often forged
              sender address.

RESULT ADDRESS REWRITING
       The lookup result is subject to address rewriting:

       ·      When the result has the form @otherdomain, the result becomes the same user in
              otherdomain.

       ·      When  "append_at_myorigin=yes",  append  "@$myorigin"  to  addresses   without
              "@domain".

       ·      When  "append_dot_mydomain=yes",  append  ".$mydomain"  to  addresses  without
              ".domain".

ADDRESS EXTENSION
       When a mail address  localpart  contains  the  optional  recipient  delimiter  (e.g.,
       user+foo@domain),  the  lookup order becomes: user+foo@domain, user@domain, user+foo,
       user, and @domain.

       The propagate_unmatched_extensions parameter controls whether  an  unmatched  address
       extension (+foo) is propagated to the result of table lookup.

REGULAR EXPRESSION TABLES
       This  section  describes  how the table lookups change when the table is given in the
       form of regular expressions. For a description of  regular  expression  lookup  table
       syntax, see regexp_table(5) or pcre_table(5).

       Each  pattern  is  a  regular  expression that is applied to the entire address being
       looked up. Thus, user@domain mail addresses are not broken up  into  their  user  and
       @domain constituent parts, nor is user+foo broken up into user and foo.

       Patterns are applied in the order as specified in the table, until a pattern is found
       that matches the search string.

       Results are the same as with indexed file lookups, with the additional  feature  that
       parenthesized substrings from the pattern can be interpolated as $1, $2 and so on.

TCP-BASED TABLES
       This  section  describes  how the table lookups change when lookups are directed to a
       TCP-based server. For a description of the TCP  client/server  lookup  protocol,  see
       tcp_table(5).  This feature is not available up to and including Postfix version 2.4.

       Each lookup operation uses the entire address once.  Thus, user@domain mail addresses
       are not broken up into their user and @domain constituent parts, nor is user+foo bro‐
       ken up into user and foo.

       Results are the same as with indexed file lookups.

BUGS
       The table format does not understand quoting conventions.

CONFIGURATION PARAMETERS
       The  following  main.cf  parameters are especially relevant.  The text below provides
       only a parameter summary. See postconf(5) for more details including examples.

       canonical_classes
              What addresses are subject to canonical address mapping.

       canonical_maps
              List of canonical mapping tables.

       recipient_canonical_maps
              Address mapping lookup table for envelope and header recipient addresses.

       sender_canonical_maps
              Address mapping lookup table for envelope and header sender addresses.

       propagate_unmatched_extensions
              A list of address rewriting or forwarding mechanisms that propagate an address
              extension  from  the  original address to the result.  Specify zero or more of
              canonical, virtual, alias, forward, include, or generic.

       Other parameters of interest:

       inet_interfaces
              The network interface addresses that this system receives mail on.   You  need
              to stop and start Postfix when this parameter changes.

       local_header_rewrite_clients
              Rewrite  message header addresses in mail from these clients and update incom‐
              plete addresses with the domain name in $myorigin or $mydomain;  either  don't
              rewrite  message headers from other clients at all, or rewrite message headers
              and  update  incomplete  addresses  with   the   domain   specified   in   the
              remote_header_rewrite_domain parameter.

       proxy_interfaces
              Other interfaces that this machine receives mail on by way of a proxy agent or
              network address translator.

       masquerade_classes
              List of address classes  subject  to  masquerading:  zero  or  more  of  enve‐
              lope_sender, envelope_recipient, header_sender, header_recipient.

       masquerade_domains
              List of domains that hide their subdomain structure.

       masquerade_exceptions
              List of user names that are not subject to address masquerading.

       mydestination
              List of domains that this mail system considers local.

       myorigin
              The domain that is appended to locally-posted mail.

       owner_request_special
              Give special treatment to owner-xxx and xxx-request addresses.

       remote_header_rewrite_domain
              Don't  rewrite  message headers from remote clients at all when this parameter
              is empty; otherwise, rewrite message headers and append the  specified  domain
              name to incomplete addresses.

SEE ALSO
       cleanup(8), canonicalize and enqueue mail
       postmap(1), Postfix lookup table manager
       postconf(5), configuration parameters
       virtual(5), virtual aliasing

README FILES
       Use  "postconf readme_directory" or "postconf html_directory" to locate this informa‐
       tion.
       DATABASE_README, Postfix lookup table overview
       ADDRESS_REWRITING_README, address rewriting guide

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

                                                                                CANONICAL(5)

Auch hier editieren wir nicht die Vorlage- und Musterdatei /etc/postfix/canonical, sondern legen uns für die einzelnen Anwendungsfälle eigene Dateien an, auch wenn diese eventuell erst einmal ohne Inhalt sind. Wir haben so später kein Problem mehr, wenn wir ad hoc auf eine Anforderung schnell reagieren müssen.

Canonical-Dateien

sender_canonical_maps
  • sender_canonical_maps Lookup-Tabelle zum Umschreibungen von Absender eMail-Adressen im SMTP-Envelop und im Header der eMail.
    sender_canonical_maps.db Datenbankfile zur sender_canonical_maps-Datei.
     # vim /etc/postfix/sender_canonical_maps
    /etc/postfix/sender_canonical_maps
    # Django : 2012-02-06
    # Kapitel 5.2.3 canonical-Tabelle: Ich versteck' mich
    # Lookup-Tabelle zum Umschreibungen von Absender eMail-Adressen im 
    # SMTP-Envelop und im Header der eMail.
    # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels  
    # $ postmap /etc/postfix/sender_canonical_maps
    # die zugehörige Datenbank erzeugt werden.
    #
    # catch all
    #@pml010080.intra.nausch.org            @nausch.org
    #
    # einzelnen Nutzer umschreiben
    #weather                                        news@wetterstation-pliening.info
    #
    # genau eine Adresse umschreiben
    #admin@pml100201.intra.nausch.org       webmaster@nausch.org
    weather@vml000020.dmz,nausch.org                news@wetterstation-pliening.info
recipient_canonical_maps
  • recipient_canonical_maps Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail.
    recipient_canonical_maps.db Datenbankfile zur recipient_canonical_maps-Datei.
     # vim /etc/postfix/recipient_canonical_maps
    /etc/postfix/recipient_canonical_maps
    # Django : 2012-02-06
    # Kapitel 5.2.3 canonical-Tabelle: Ich versteck' mich
    # Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen 
    # im SMTP-Envelop und im Header der eMail.
    # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels 
    # $ postmap /etc/postfix/recipient_canonical_maps
    # die zugehörige Datenbank erzeugt werden.
    #
    # catch all
    #@omni128.de             @nausch.org
    #
    # genau eine Adresse umschreiben
    #swat@nausch.org        abuse@nausch.org
    #
    # Django : 2012-12-29
    # FaxMaster für hylafax definiert
    FaxMaster@nausch.org            django@nausch.org
    root@vml000020.dmz.nausch.org   django@nausch.org
     
    sks@keyserver.nausch.org        sks@vml000030.dmz.nausch.org
     
    # Django : 2014-05-09
    # test für dmarc.nausch.org
    #huhu@dmarc.nausch.org          dmarc-reports@vml000030.dmz.nausch.org
    huhu@dmarc.nausch.org           huhu@dmarc.nausch.org
     
    # Django : 2014-06-07
    # rewrite
    root@vml000080.dmz.nausch.org   django@nausch.org

generic

Tabelle zum Umschreiben von eMailadressen. Im Gegensatz zu den beiden canonical-Maps, die die Adresse beim Empfang umschreibt, wird bei der generic-Tbelle die Adresse beim Versenden umgeschrieben.

manpage

In der Manpage zu generic bzw. in der Datei /etc/postfix/generic finden wir detaillierte Informationen zur generic - Postfix generic table format.

 # man 5 generic
GENERIC(5)                           File Formats Manual                          GENERIC(5)

NAME
       generic - Postfix generic table format

SYNOPSIS
       postmap /etc/postfix/generic

       postmap -q "string" /etc/postfix/generic

       postmap -q - /etc/postfix/generic <inputfile

DESCRIPTION
       The  optional generic(5) table specifies an address mapping that applies when mail is
       delivered. This is the opposite of canonical(5) mapping, which applies when  mail  is
       received.

       Typically,  one would use the generic(5) table on a system that does not have a valid
       Internet domain name and that uses something  like  localdomain.local  instead.   The
       generic(5) table is then used by the smtp(8) client to transform local mail addresses
       into valid Internet mail addresses when mail has to be sent across the Internet.  See
       the EXAMPLE section at the end of this document.

       The  generic(5)  mapping  affects  both message header addresses (i.e. addresses that
       appear inside messages) and message envelope addresses (for  example,  the  addresses
       that are used in SMTP protocol commands).

       Normally,  the  generic(5)  table is specified as a text file that serves as input to
       the postmap(1) command.  The result, an indexed file in dbm or db format, is used for
       fast searching by the mail system. Execute the command "postmap /etc/postfix/generic"
       to rebuild an indexed file after changing the corresponding text file.

       When the table is provided via other means such as NIS, LDAP or SQL, the same lookups
       are done as for ordinary indexed files.

       Alternatively,  the  table can be provided as a regular-expression map where patterns
       are given as regular expressions, or lookups can be directed to TCP-based server.  In
       those case, the lookups are done in a slightly different way as described below under
       "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES".

CASE FOLDING
       The search string is folded to lowercase before database lookup. As of  Postfix  2.3,
       the  search  string  is  not case folded with database types such as regexp: or pcre:
       whose lookup fields can match both upper and lower case.

TABLE FORMAT
       The input format for the postmap(1) command is as follows:

       pattern result
              When pattern matches a mail address, replace it by the corresponding result.

       blank lines and comments
              Empty lines and whitespace-only lines are ignored, as are  lines  whose  first
              non-whitespace character is a `#'.

       multi-line text
              A logical line starts with non-whitespace text. A line that starts with white‐
              space continues a logical line.

TABLE SEARCH ORDER
       With lookups from indexed files such as DB or DBM, or from networked tables  such  as
       NIS, LDAP or SQL, patterns are tried in the order as listed below:

       user@domain address
              Replace user@domain by address. This form has the highest precedence.

       user address
              Replace  user@site  by  address  when site is equal to $myorigin, when site is
              listed in  $mydestination,  or  when  it  is  listed  in  $inet_interfaces  or
              $proxy_interfaces.

       @domain address
              Replace other addresses in domain by address.  This form has the lowest prece‐
              dence.

RESULT ADDRESS REWRITING
       The lookup result is subject to address rewriting:

       ·      When the result has the form @otherdomain, the result becomes the same user in
              otherdomain.

       ·      When   "append_at_myorigin=yes",  append  "@$myorigin"  to  addresses  without
              "@domain".

       ·      When  "append_dot_mydomain=yes",  append  ".$mydomain"  to  addresses  without
              ".domain".

ADDRESS EXTENSION
       When  a  mail  address  localpart  contains  the  optional recipient delimiter (e.g.,
       user+foo@domain), the lookup order becomes: user+foo@domain,  user@domain,  user+foo,
       user, and @domain.

       The  propagate_unmatched_extensions  parameter  controls whether an unmatched address
       extension (+foo) is propagated to the result of table lookup.

REGULAR EXPRESSION TABLES
       This section describes how the table lookups change when the table is  given  in  the
       form  of  regular  expressions.  For a description of regular expression lookup table
       syntax, see regexp_table(5) or pcre_table(5).

       Each pattern is a regular expression that is applied  to  the  entire  address  being
       looked  up.  Thus,  user@domain  mail addresses are not broken up into their user and
       @domain constituent parts, nor is user+foo broken up into user and foo.

       Patterns are applied in the order as specified in the table, until a pattern is found
       that matches the search string.

       Results  are  the same as with indexed file lookups, with the additional feature that
       parenthesized substrings from the pattern can be interpolated as $1, $2 and so on.

TCP-BASED TABLES
       This section describes how the table lookups change when lookups are  directed  to  a
       TCP-based  server.  For  a  description of the TCP client/server lookup protocol, see
       tcp_table(5).  This feature is not available up to and including Postfix version 2.4.

       Each lookup operation uses the entire address once.  Thus, user@domain mail addresses
       are not broken up into their user and @domain constituent parts, nor is user+foo bro‐
       ken up into user and foo.

       Results are the same as with indexed file lookups.

EXAMPLE
       The following shows a generic mapping with an indexed file.  When mail is sent  to  a
       remote  host  via  SMTP, this replaces his@localdomain.local by his ISP mail address,
       replaces her@localdomain.local by her ISP mail  address,  and  replaces  other  local
       addresses  by  his  ISP  account,  with  an address extension of +local (this example
       assumes that the ISP supports "+" style address extensions).

       /etc/postfix/main.cf:
           smtp_generic_maps = hash:/etc/postfix/generic

       /etc/postfix/generic:
           his@localdomain.local   hisaccount@hisisp.example
           her@localdomain.local   heraccount@herisp.example
           @localdomain.local      hisaccount+local@hisisp.example

       Execute the command "postmap /etc/postfix/generic" whenever  the  table  is  changed.
       Instead  of  hash,  some systems use dbm database files. To find out what tables your
       system supports use the command "postconf -m".

BUGS
       The table format does not understand quoting conventions.

CONFIGURATION PARAMETERS
       The following main.cf parameters are especially relevant.  The  text  below  provides
       only a parameter summary. See postconf(5) for more details including examples.

       smtp_generic_maps
              Address  mapping  lookup  table  for  envelope and header sender and recipient
              addresses while delivering mail via SMTP.

       propagate_unmatched_extensions
              A list of address rewriting or forwarding mechanisms that propagate an address
              extension  from  the  original address to the result.  Specify zero or more of
              canonical, virtual, alias, forward, include, or generic.

       Other parameters of interest:

       inet_interfaces
              The network interface addresses that this system receives mail on.   You  need
              to stop and start Postfix when this parameter changes.

       proxy_interfaces
              Other interfaces that this machine receives mail on by way of a proxy agent or
              network address translator.

       mydestination
              List of domains that this mail system considers local.

       myorigin
              The domain that is appended to locally-posted mail.

       owner_request_special
              Give special treatment to owner-xxx and xxx-request addresses.

SEE ALSO
       postmap(1), Postfix lookup table manager
       postconf(5), configuration parameters
       smtp(8), Postfix SMTP client

README FILES
       Use "postconf readme_directory" or "postconf html_directory" to locate this  informa‐
       tion.
       ADDRESS_REWRITING_README, address rewriting guide
       DATABASE_README, Postfix lookup table overview
       STANDARD_CONFIGURATION_README, configuration examples

LICENSE
       The Secure Mailer license must be distributed with this software.

HISTORY
       A genericstable feature appears in the Sendmail MTA.

       This feature is available in Postfix 2.2 and later.

AUTHOR(S)
       Wietse Venema
       IBM T.J. Watson Research
       P.O. Box 704
       Yorktown Heights, NY 10598, USA

                                                                                  GENERIC(5)

Auch hier editieren wir nicht diese Vorlage- und Musterdatei /etc/postfix/genericaccess, sondern legen uns für die einzelnen Anwendungsfälle eigene Dateien an, auch wenn diese eventuell erst einmal ohne Inhalt sind. Wir haben so später kein Problem mehr, wenn wir ad hoc auf eine Anforderung schnell reagieren müssen.

generic-Dateien

lmtp_generic_maps
  • lmtp_generic_maps Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail. Das Umschreiben erfolgt beim Verlassen des Systems via LMTP.
    lmtp_generic_maps.db Datenbankfile zur lmtp_generic_maps-Datei.
     # vim /etc/postfix/lmtp_generic_maps
    /etc/postfix/lmtp_generic_maps
    # Kapitel 5.2.4 generic-Tabelle: Umschreiben bei ausgehenden eMails
    # Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im 
    # SMTP-Envelop und im Header der eMail.
    #
    # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels  
    # $ postmap /etc/postfix/lmtp_generic_maps die zugehörige Datenbank 
    # erzeugt werden.
    #
    # catch all
    #@omni128.de             @nausch.org
    #
    # genau eine Adresse umschreiben
    #swat@nausch.org        abuse@nausch.org
smtp_generic_maps
  • smtp_generic_maps Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im SMTP-Envelop und im Header der eMail. Das Umschreiben erfolgt beim Verlassen des Systems via SMTP.
    smtp_generic_maps.db Datenbankfile zur smtp_generic_maps-Datei.
     # vim /etc/postfix/smtp_generic_maps
    /etc/postfix/smtp_generic_maps
    # Kapitel 5.2.4 generic-Tabelle: Umschreiben bei ausgehenden eMails
    # Lookup-Tabelle zum Umschreibungen von Empfänger eMail-Adressen im 
    # SMTP-Envelop und im Header der eMail.
    #
    # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels  
    # $ postmap /etc/postfix/smtp_generic_maps die zugehörige Datenbank 
    # erzeugt werden.
    #
    # catch all
    #@omni128.de             @nausch.org
    #
    # genau eine Adresse umschreiben
    #swat@nausch.org        abuse@nausch.org

relocated

Lookup-Tabelle zum Aktivieren von „Bounce-Nachrichten“ an den Absender einer eMail über nicht existierende eMailadressen mit Angabe der neu zu nutzenden eMailadresse des Empfängers.

manpage

In der Manpage zu relocated bzw. in der Datei /etc/postfix/relocated finden wir detaillierte Informationen zur relocated - Postfix relocated table format.

 # man 5 relocated
RELOCATED(5)                         File Formats Manual                        RELOCATED(5)

NAME
       relocated - Postfix relocated table format

SYNOPSIS
       postmap /etc/postfix/relocated

DESCRIPTION
       The  optional  relocated(5)  table provides the information that is used in "user has
       moved to new_location" bounce messages.

       Normally, the relocated(5) table is specified as a text file that serves as input  to
       the postmap(1) command.  The result, an indexed file in dbm or db format, is used for
       fast searching by the mail system. Execute the  command  "postmap  /etc/postfix/relo‐
       cated" to rebuild an indexed file after changing the corresponding relocated table.

       When the table is provided via other means such as NIS, LDAP or SQL, the same lookups
       are done as for ordinary indexed files.

       Alternatively, the table can be provided as a regular-expression map  where  patterns
       are  given as regular expressions, or lookups can be directed to TCP-based server. In
       those case, the lookups are done in a slightly different way as described below under
       "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES".

       Table lookups are case insensitive.

CASE FOLDING
       The  search  string is folded to lowercase before database lookup. As of Postfix 2.3,
       the search string is not case folded with database types such  as  regexp:  or  pcre:
       whose lookup fields can match both upper and lower case.

TABLE FORMAT
       The input format for the postmap(1) command is as follows:

       ·      An entry has one of the following form:

                   pattern      new_location

              Where  new_location specifies contact information such as an email address, or
              perhaps a street address or telephone number.

       ·      Empty lines and whitespace-only lines are ignored, as are  lines  whose  first
              non-whitespace character is a `#'.

       ·      A logical line starts with non-whitespace text. A line that starts with white‐
              space continues a logical line.

TABLE SEARCH ORDER
       With lookups from indexed files such as DB or DBM, or from networked tables  such  as
       NIS, LDAP or SQL, patterns are tried in the order as listed below:

       user@domain
              Matches user@domain. This form has precedence over all other forms.

       user   Matches  user@site  when site is $myorigin, when site is listed in $mydestina‐
              tion, or when site is listed in $inet_interfaces or $proxy_interfaces.

       @domain
              Matches other addresses in domain. This form has the lowest precedence.

ADDRESS EXTENSION
       When a mail address  localpart  contains  the  optional  recipient  delimiter  (e.g.,
       user+foo@domain),  the  lookup order becomes: user+foo@domain, user@domain, user+foo,
       user, and @domain.

REGULAR EXPRESSION TABLES
       This section describes how the table lookups change when the table is  given  in  the
       form of regular expressions or when lookups are directed to a TCP-based server. For a
       description of  regular  expression  lookup  table  syntax,  see  regexp_table(5)  or
       pcre_table(5).  For a description of the TCP client/server table lookup protocol, see
       tcp_table(5).  This feature is not available up to and including Postfix version 2.4.

       Each pattern is a regular expression that is applied  to  the  entire  address  being
       looked  up.  Thus,  user@domain  mail addresses are not broken up into their user and
       @domain constituent parts, nor is user+foo broken up into user and foo.

       Patterns are applied in the order as specified in the table, until a pattern is found
       that matches the search string.

       Results  are  the same as with indexed file lookups, with the additional feature that
       parenthesized substrings from the pattern can be interpolated as $1, $2 and so on.

TCP-BASED TABLES
       This section describes how the table lookups change when lookups are  directed  to  a
       TCP-based  server.  For  a  description of the TCP client/server lookup protocol, see
       tcp_table(5).  This feature is not available up to and including Postfix version 2.4.

       Each lookup operation uses the entire address once.  Thus, user@domain mail addresses
       are not broken up into their user and @domain constituent parts, nor is user+foo bro‐
       ken up into user and foo.

       Results are the same as with indexed file lookups.

BUGS
       The table format does not understand quoting conventions.

CONFIGURATION PARAMETERS
       The following main.cf parameters are especially relevant.  The  text  below  provides
       only a parameter summary. See postconf(5) for more details including examples.

       relocated_maps
              List of lookup tables for relocated users or sites.

       Other parameters of interest:

       inet_interfaces
              The  network  interface addresses that this system receives mail on.  You need
              to stop and start Postfix when this parameter changes.

       mydestination
              List of domains that this mail system considers local.

       myorigin
              The domain that is appended to locally-posted mail.

       proxy_interfaces
              Other interfaces that this machine receives mail on by way of a proxy agent or
              network address translator.

SEE ALSO
       trivial-rewrite(8), address resolver
       postmap(1), Postfix lookup table manager
       postconf(5), configuration parameters

README FILES
       Use  "postconf readme_directory" or "postconf html_directory" to locate this informa‐
       tion.
       DATABASE_README, Postfix lookup table overview
       ADDRESS_REWRITING_README, address rewriting guide

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

                                                                                RELOCATED(5)

Wir editieren nun aber nicht diese Vorlage- und Musterdatei /etc/postfix/relocated, sondern legen uns eine eigene Dateien an, auch wenn diese eventuell erst einmal ohne Inhalt sind. Wir haben so später kein Problem mehr, wenn wir ad hoc auf eine Anforderung schnell reagieren müssen.

relocated-Datei

  • relocated_maps Lookup-Tabelle zum Aktivieren von „Bounce-Nachrichten“ an den Absender einer eMail über nicht existierende eMailadressen mit Angabe der neu zu nutzenden eMailadresse des Empfängers.
    relocated_maps.db Datenbankfile zur relocated_maps-Datei.
     # vim /etc/postfix/relocated_maps
    /etc/postfix/relocated_maps
    # Kapitel 5.2.6 relocated-Tabelle: Empfängrt verzogen
    # Lookup-Tabelle zum Aktivieren von "Bounce-Nachrichten" an den Absender 
    # einer eMail über nicht existierende eMailadressen mit Angabe der neu zu 
    # nutzenden eMailadresse des Empfängers.
    #
    # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels 
    # $ postmap /etc/postfix/relocated_maps
    # die zugehörige Datenbank erzeugt werden.
    #
    michael.nausch@omni128.de      django@nausch.org

transport

Lookup-Tabelle zum Aktivieren einer alternativen Mailrouting bei der Zustellung an einen weiteren Mailserver.

manpage

In der Manpage zu transport bzw. in der Datei /etc/postfix/transport finden wir detaillierte Informationen zur transport - Postfix transport table format.

 # man 5 transport
TRANSPORT(5)                         File Formats Manual                        TRANSPORT(5)

NAME
       transport - Postfix transport table format

SYNOPSIS
       postmap /etc/postfix/transport

       postmap -q "string" /etc/postfix/transport

       postmap -q - /etc/postfix/transport <inputfile

DESCRIPTION
       The  optional  transport(5) table specifies a mapping from email addresses to message
       delivery transports and next-hop destinations.  Message delivery transports  such  as
       local  or smtp are defined in the master.cf file, and next-hop destinations are typi‐
       cally hosts or domain names. The table is searched by the trivial-rewrite(8) daemon.

       This mapping overrides the default transport:nexthop selection  that  is  built  into
       Postfix:

       local_transport (default: local:$myhostname)
              This  is  the default for final delivery to domains listed with mydestination,
              and for [ipaddress] destinations that match $inet_interfaces or  $proxy_inter‐
              faces. The default nexthop destination is the MTA hostname.

       virtual_transport (default: virtual:)
              This  is  the  default for final delivery to domains listed with virtual_mail‐
              box_domains. The default nexthop destination is the recipient domain.

       relay_transport (default: relay:)
              This is the default for remote delivery to domains listed with  relay_domains.
              In  order  of  decreasing  precedence,  the  nexthop destination is taken from
              relay_transport,  sender_dependent_relayhost_maps,  relayhost,  or  from   the
              recipient domain.

       default_transport (default: smtp:)
              This  is  the  default for remote delivery to other destinations.  In order of
              decreasing precedence, the nexthop destination  is  taken  from  sender_depen‐
              dent_default_transport_maps,     default_transport,    sender_dependent_relay‐
              host_maps, relayhost, or from the recipient domain.

       Normally, the transport(5) table is specified as a text file that serves as input  to
       the postmap(1) command.  The result, an indexed file in dbm or db format, is used for
       fast searching by the mail system. Execute the command  "postmap  /etc/postfix/trans‐
       port" to rebuild an indexed file after changing the corresponding transport table.

       When the table is provided via other means such as NIS, LDAP or SQL, the same lookups
       are done as for ordinary indexed files.

       Alternatively, the table can be provided as a regular-expression map  where  patterns
       are  given as regular expressions, or lookups can be directed to TCP-based server. In
       those case, the lookups are done in a slightly different way as described below under
       "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES".

CASE FOLDING
       The  search  string is folded to lowercase before database lookup. As of Postfix 2.3,
       the search string is not case folded with database types such  as  regexp:  or  pcre:
       whose lookup fields can match both upper and lower case.

TABLE FORMAT
       The input format for the postmap(1) command is as follows:

       pattern result
              When  pattern  matches  the recipient address or domain, use the corresponding
              result.

       blank lines and comments
              Empty lines and whitespace-only lines are ignored, as are  lines  whose  first
              non-whitespace character is a `#'.

       multi-line text
              A logical line starts with non-whitespace text. A line that starts with white‐
              space continues a logical line.

       The pattern specifies an email address, a domain name, or a domain name hierarchy, as
       described in section "TABLE LOOKUP".

       The  result  is  of  the form transport:nexthop and specifies how or where to deliver
       mail. This is described in section "RESULT FORMAT".

TABLE SEARCH ORDER
       With lookups from indexed files such as DB or DBM, or from networked tables  such  as
       NIS, LDAP or SQL, patterns are tried in the order as listed below:

       user+extension@domain transport:nexthop
              Deliver mail for user+extension@domain through transport to nexthop.

       user@domain transport:nexthop
              Deliver mail for user@domain through transport to nexthop.

       domain transport:nexthop
              Deliver mail for domain through transport to nexthop.

       .domain transport:nexthop
              Deliver  mail  for  any subdomain of domain through transport to nexthop. This
              applies only when  the  string  transport_maps  is  not  listed  in  the  par‐
              ent_domain_matches_subdomains configuration setting.  Otherwise, a domain name
              matches itself and its subdomains.

       * transport:nexthop
              The special pattern * represents any address (i.e. it functions as  the  wild-
              card pattern, and is unique to Postfix transport tables).

       Note  1: the null recipient address is looked up as $empty_address_recipient@$myhost‐
       name (default: mailer-daemon@hostname).

       Note 2: user@domain or user+extension@domain lookup is available in Postfix  2.0  and
       later.

RESULT FORMAT
       The  lookup result is of the form transport:nexthop.  The transport field specifies a
       mail delivery transport such as smtp or local. The nexthop field specifies where  and
       how to deliver mail.

       The  transport  field specifies the name of a mail delivery transport (the first name
       of a mail delivery service entry in the Postfix master.cf file).

       The interpretation of the nexthop field is transport dependent. In the case of  SMTP,
       specify  a  service  on  a  non-default  port  as  host:service, and disable MX (mail
       exchanger) DNS lookups with [host] or [host]:port. The [] form is required  when  you
       specify an IP address instead of a hostname.

       A  null  transport  and  null  nexthop result means "do not change": use the delivery
       transport and nexthop information that would be used when the entire transport  table
       did not exist.

       A  non-null  transport field with a null nexthop field resets the nexthop information
       to the recipient domain.

       A null transport field with non-null nexthop field  does  not  modify  the  transport
       information.

EXAMPLES
       In  order  to  deliver internal mail directly, while using a mail relay for all other
       mail, specify a null entry for internal destinations  (do  not  change  the  delivery
       transport  or  the nexthop information) and specify a wildcard for all other destina‐
       tions.

            my.domain    :
            .my.domain   :
            *            smtp:outbound-relay.my.domain

       In order to send mail for example.com and its subdomains via the  uucp  transport  to
       the UUCP host named example:

            example.com      uucp:example
            .example.com     uucp:example

       When  no nexthop host name is specified, the destination domain name is used instead.
       For example, the following directs mail for user@example.com via the  slow  transport
       to  a  mail exchanger for example.com.  The slow transport could be configured to run
       at most one delivery process at a time:

            example.com      slow:

       When no transport is specified, Postfix uses the transport that matches  the  address
       domain  class  (see DESCRIPTION above).  The following sends all mail for example.com
       and its subdomains to host gateway.example.com:

            example.com      :[gateway.example.com]
            .example.com     :[gateway.example.com]

       In the above example, the [] suppress MX lookups.  This prevents mail  routing  loops
       when your machine is primary MX host for example.com.

       In  the case of delivery via SMTP, one may specify hostname:service instead of just a
       host:

            example.com      smtp:bar.example:2025

       This directs mail for user@example.com to host bar.example port 2025.  Instead  of  a
       numerical  port  a  symbolic  name  may be used. Specify [] around the hostname if MX
       lookups must be disabled.

       The error mailer can be used to bounce mail:

            .example.com     error:mail for *.example.com is not deliverable

       This causes all mail for user@anything.example.com to be bounced.

REGULAR EXPRESSION TABLES
       This section describes how the table lookups change when the table is  given  in  the
       form  of  regular  expressions.  For a description of regular expression lookup table
       syntax, see regexp_table(5) or pcre_table(5).

       Each pattern is a regular expression that is applied  to  the  entire  address  being
       looked  up.  Thus, some.domain.hierarchy is not looked up via its parent domains, nor
       is user+foo@domain looked up as user@domain.

       Patterns are applied in the order as specified in the table, until a pattern is found
       that matches the search string.

       The trivial-rewrite(8) server disallows regular expression substitution of $1 etc. in
       regular expression lookup tables, because that could open a  security  hole  (Postfix
       version 2.3 and later).

TCP-BASED TABLES
       This  section  describes  how the table lookups change when lookups are directed to a
       TCP-based server. For a description of the TCP  client/server  lookup  protocol,  see
       tcp_table(5).  This feature is not available up to and including Postfix version 2.4.

       Each   lookup   operation   uses   the   entire   recipient   address   once.   Thus,
       some.domain.hierarchy is not looked up via its parent domains, nor is user+foo@domain
       looked up as user@domain.

       Results are the same as with indexed file lookups.

CONFIGURATION PARAMETERS
       The  following  main.cf  parameters are especially relevant.  The text below provides
       only a parameter summary. See postconf(5) for more details including examples.

       empty_address_recipient
              The address that is looked up instead of the null sender address.

       parent_domain_matches_subdomains
              List of Postfix features that use domain.tld patterns to match  sub.domain.tld
              (as opposed to requiring .domain.tld patterns).

       transport_maps
              List of transport lookup tables.

SEE ALSO
       trivial-rewrite(8), rewrite and resolve addresses
       master(5), master.cf file format
       postconf(5), configuration parameters
       postmap(1), Postfix lookup table manager

README FILES
       Use  "postconf readme_directory" or "postconf html_directory" to locate this informa‐
       tion.
       ADDRESS_REWRITING_README, address rewriting guide
       DATABASE_README, Postfix lookup table overview
       FILTER_README, external content filter

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

                                                                                TRANSPORT(5)

transport-Datei

  • transport_maps Lookup-Tabelle zum Aktivieren einer alternativen Mailrouting bei der Zustellung an einen weiteren Mailserver.
    transport_maps.db Datenbankfile zur transport_maps-Datei.
     # vim /etc/postfix/transport_maps
    /etc/postfix/transport_maps
    # Kapitel 5.2.5 transport-Tabelle: Abweichende Zustellung
    # Lookup-Tabelle zum Aktivieren einer alternativen Mailrouting bei der
    # Zustellung an einen weiteren Mailserver. Nach dem Ändern und/oder
    # Erweitern der Tabelle, muß noch mittels:
    #               $ postmap /etc/postfix/transport_map
    #
    # die zugehörige Datenbank erzeugt werden.
    #
    # Alle eMails, die an Subdomains von nausch.org gerichtet sind
    # ("." am Anfang der Zeile!) werden an den/die Mailserver von
    # intra.nausch.org (MX-Records) weitergeleitet. (keine "["-Klammern!)
    #.nausch.org                            smtp:intra.nausch.org
     
    # Alle eMails, die an die Domain tachtler.net gerichtet sind, werden an 
    # den bzw. die Mailserver der Mail-Domäne t-offline.de (MX-Records) 
    # weitergeleitet. (keine "["-Klammern!) 
    # tachtler.net                          smtp:t-offline.de
     
    # Mails an backup.nausch.org werden an den Mailserver (A-Record) auf Port 25
    # mit Namen mail.intra.nausch.org geschickt.
    #backup.nausch.org                      smtp:[mail.intra.nausch.org]:25
     
    # Django : 2013-02-21
    # eMails an den Fax-Server an den Host vml000020 weiterleiten
    fax.nausch.org                          smtp:[10.0.0.20]:25
    # eMails an den Key-Server sollen an den Host vml000030 weitergeleitet
    # werden.
    keyserver.nausch.org                    smtp:[10.0.0.30]:25
     
    # Django : 2013-02-22
    # eMails an den Mailinglisten-Server an das Programm mailman weiterreichen
    #lists.nausch.org                       mailman:

virtual

Lookup-Tabelle zum Verwalten der virtuellen Domains und virtuellen eMail-Adressen.

manpage

In der Manpage zu virtual bzw. in der Datei /etc/postfix/virtual finden wir detaillierte Informationen zur virtual - Postfix virtual alias table format.

 # man 5 transport
VIRTUAL(5)                           File Formats Manual                          VIRTUAL(5)

NAME
       virtual - Postfix virtual alias table format

SYNOPSIS
       postmap /etc/postfix/virtual

       postmap -q "string" /etc/postfix/virtual

       postmap -q - /etc/postfix/virtual <inputfile

DESCRIPTION
       The  optional  virtual(5) alias table rewrites recipient addresses for all local, all
       virtual, and all remote mail destinations.  This is unlike the aliases(5) table which
       is  used  only  for  local(8) delivery.  Virtual aliasing is recursive, and is imple‐
       mented by the Postfix cleanup(8) daemon before mail is queued.

       The main applications of virtual aliasing are:

       ·      To redirect mail for one address to one or more addresses.

       ·      To implement  virtual  alias  domains  where  all  addresses  are  aliased  to
              addresses in other domains.

              Virtual  alias domains are not to be confused with the virtual mailbox domains
              that are implemented with the Postfix virtual(8)  mail  delivery  agent.  With
              virtual mailbox domains, each recipient address can have its own mailbox.

       Virtual aliasing is applied only to recipient envelope addresses, and does not affect
       message headers.  Use canonical(5) mapping to rewrite header and  envelope  addresses
       in general.

       Normally, the virtual(5) alias table is specified as a text file that serves as input
       to the postmap(1) command.  The result, an indexed file in dbm or db format, is  used
       for fast searching by the mail system. Execute the command "postmap /etc/postfix/vir‐
       tual" to rebuild an indexed file after changing the corresponding text file.

       When the table is provided via other means such as NIS, LDAP or SQL, the same lookups
       are done as for ordinary indexed files.

       Alternatively,  the  table can be provided as a regular-expression map where patterns
       are given as regular expressions, or lookups can be directed to TCP-based server.  In
       those case, the lookups are done in a slightly different way as described below under
       "REGULAR EXPRESSION TABLES" or "TCP-BASED TABLES".

CASE FOLDING
       The search string is folded to lowercase before database lookup. As of  Postfix  2.3,
       the  search  string  is  not case folded with database types such as regexp: or pcre:
       whose lookup fields can match both upper and lower case.

TABLE FORMAT
       The input format for the postmap(1) command is as follows:

       pattern address, address, ...
              When pattern matches a mail address, replace it by the corresponding address.

       blank lines and comments
              Empty lines and whitespace-only lines are ignored, as are  lines  whose  first
              non-whitespace character is a `#'.

       multi-line text
              A logical line starts with non-whitespace text. A line that starts with white‐
              space continues a logical line.

TABLE SEARCH ORDER
       With lookups from indexed files such as DB or DBM, or from networked tables  such  as
       NIS, LDAP or SQL, patterns are tried in the order as listed below:

       user@domain address, address, ...
              Redirect  mail  for  user@domain to address.  This form has the highest prece‐
              dence.

       user address, address, ...
              Redirect mail for user@site to address when site is equal to  $myorigin,  when
              site  is listed in $mydestination, or when it is listed in $inet_interfaces or
              $proxy_interfaces.

              This functionality overlaps with functionality of the local  aliases(5)  data‐
              base.  The  difference  is that virtual(5) mapping can be applied to non-local
              addresses.

       @domain address, address, ...
              Redirect mail for other users in domain to address.  This form has the  lowest
              precedence.

              Note:  @domain is a wild-card. With this form, the Postfix SMTP server accepts
              mail for any recipient in domain, regardless of whether that recipient exists.
              This  may  turn  your  mail  system  into  a backscatter source: Postfix first
              accepts mail for non-existent recipients and then tries to return that mail as
              "undeliverable" to the often forged sender address.

RESULT ADDRESS REWRITING
       The lookup result is subject to address rewriting:

       ·      When the result has the form @otherdomain, the result becomes the same user in
              otherdomain.  This works only for the first address in a multi-address  lookup
              result.

       ·      When   "append_at_myorigin=yes",  append  "@$myorigin"  to  addresses  without
              "@domain".

       ·      When  "append_dot_mydomain=yes",  append  ".$mydomain"  to  addresses  without
              ".domain".

ADDRESS EXTENSION
       When  a  mail  address  localpart  contains  the  optional recipient delimiter (e.g.,
       user+foo@domain), the lookup order becomes: user+foo@domain,  user@domain,  user+foo,
       user, and @domain.

       The  propagate_unmatched_extensions  parameter  controls whether an unmatched address
       extension (+foo) is propagated to the result of table lookup.

VIRTUAL ALIAS DOMAINS
       Besides virtual aliases, the virtual alias table can also be used to  implement  vir‐
       tual  alias domains. With a virtual alias domain, all recipient addresses are aliased
       to addresses in other domains.

       Virtual alias domains are not to be confused with the virtual  mailbox  domains  that
       are implemented with the Postfix virtual(8) mail delivery agent. With virtual mailbox
       domains, each recipient address can have its own mailbox.

       With a virtual alias domain, the virtual domain has its own user  name  space.  Local
       (i.e.  non-virtual)  usernames are not visible in a virtual alias domain. In particu‐
       lar, local aliases(5) and local mailing lists are not visible  as  localname@virtual-
       alias.domain.

       Support for a virtual alias domain looks like:

       /etc/postfix/main.cf:
           virtual_alias_maps = hash:/etc/postfix/virtual

       Note:  some systems use dbm databases instead of hash.  See the output from "postconf
       -m" for available database types.

       /etc/postfix/virtual:
           virtual-alias.domain     anything (right-hand content does not matter)
           postmaster@virtual-alias.domain  postmaster
           user1@virtual-alias.domain       address1
           user2@virtual-alias.domain       address2, address3

       The virtual-alias.domain anything entry is required for a virtual alias domain. With‐
       out  this  entry,  mail is rejected with "relay access denied", or bounces with "mail
       loops back to myself".

       Do  not  specify  virtual  alias  domain  names  in  the  main.cf  mydestination   or
       relay_domains configuration parameters.

       With a virtual alias domain, the Postfix SMTP server accepts mail for known-user@vir‐
       tual-alias.domain, and rejects mail for unknown-user@virtual-alias.domain as undeliv‐
       erable.

       Instead of specifying the virtual alias domain name via the virtual_alias_maps table,
       you may also specify it via the main.cf virtual_alias_domains  configuration  parame‐
       ter.  This latter parameter uses the same syntax as the main.cf mydestination config‐
       uration parameter.

REGULAR EXPRESSION TABLES
       This section describes how the table lookups change when the table is  given  in  the
       form  of  regular  expressions.  For a description of regular expression lookup table
       syntax, see regexp_table(5) or pcre_table(5).

       Each pattern is a regular expression that is applied  to  the  entire  address  being
       looked  up.  Thus,  user@domain  mail addresses are not broken up into their user and
       @domain constituent parts, nor is user+foo broken up into user and foo.

       Patterns are applied in the order as specified in the table, until a pattern is found
       that matches the search string.

       Results  are  the same as with indexed file lookups, with the additional feature that
       parenthesized substrings from the pattern can be interpolated as $1, $2 and so on.

TCP-BASED TABLES
       This section describes how the table lookups change when lookups are  directed  to  a
       TCP-based  server.  For  a  description of the TCP client/server lookup protocol, see
       tcp_table(5).  This feature is not available up to and including Postfix version 2.4.

       Each lookup operation uses the entire address once.  Thus, user@domain mail addresses
       are not broken up into their user and @domain constituent parts, nor is user+foo bro‐
       ken up into user and foo.

       Results are the same as with indexed file lookups.

BUGS
       The table format does not understand quoting conventions.

CONFIGURATION PARAMETERS
       The following main.cf parameters are especially relevant to this topic. See the Post‐
       fix  main.cf file for syntax details and for default values. Use the "postfix reload"
       command after a configuration change.

       virtual_alias_maps
              List of virtual aliasing tables.

       virtual_alias_domains
              List of virtual alias domains. This uses the same syntax as the  mydestination
              parameter.

       propagate_unmatched_extensions
              A list of address rewriting or forwarding mechanisms that propagate an address
              extension from the original address to the result.  Specify zero  or  more  of
              canonical, virtual, alias, forward, include, or generic.

       Other parameters of interest:

       inet_interfaces
              The  network  interface addresses that this system receives mail on.  You need
              to stop and start Postfix when this parameter changes.

       mydestination
              List of domains that this mail system considers local.

       myorigin
              The domain that is appended to any address that does not have a domain.

       owner_request_special
              Give special treatment to owner-xxx and xxx-request addresses.

       proxy_interfaces
              Other interfaces that this machine receives mail on by way of a proxy agent or
              network address translator.

SEE ALSO
       cleanup(8), canonicalize and enqueue mail
       postmap(1), Postfix lookup table manager
       postconf(5), configuration parameters
       canonical(5), canonical address mapping

README FILES
       Use  "postconf readme_directory" or "postconf html_directory" to locate this informa‐
       tion.
       ADDRESS_REWRITING_README, address rewriting guide
       DATABASE_README, Postfix lookup table overview
       VIRTUAL_README, domain hosting guide

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

                                                                                  VIRTUAL(5)

virtual-Dateien

virtual_alias_domains
  • virtual_alias_domains Lookup-Tabelle zum Verwalten der virtuellen Domains.
    virtual_alias_domains.db Datenbankfile zur virtual_alias_domains-Datei.
     # vim /etc/postfix/virtual_alias_domains
    /etc/postfix/virtual_alias_domains
    # Kapitel 5.2.2 virtual: Weiterleitung und virtuelle Mailadressen
    # Lookup-Tabelle zum Verwalten der virtuellen Domains. 
    # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels  
    #
    #        $ postmap /etc/postfix/virtual_alias_domains
    #
    # die zugehörige Datenbank erzeugt werden.
    #
    #nausch.org                      meine_Hauptdomäne
    #wetter.nausch.org               blaablubb
    #omni128.de                      meine_erste_Domain
    #wetterstation-pliening.info     erste_Info_Domain
    #ebersberger-liedersammlung.de   Piraten
    #lists.nausch.org                Mailman
  • virtual_alias_maps Lookup-Tabelle zum Verwalten der virtuellen eMail-Adressen.
    virtual_alias_maps.db Datenbankfile zur virtual_alias_maps-Datei.
     # vim /etc/postfix/virtual_alias_maps
    /etc/postfix/virtual_alias_maps
    # Kapitel 5.2.2 virtual: Weiterleitung und virtuelle Mailadressen
    # Lookup-Tabelle zum Verwalten der virtuellen eMailadressen.
    # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels  
    #
    #           $ postmap /etc/postfix/virtual_alias_maps
    #
    # die zugehörige Datenbank erzeugt werden.
    #
    # catch all - Sämtliche eMailadressen werden 1:1 umgeschrieben. Aus 
    # webmaster@wetter.nausch.org wird webmaster@nausch.org.
    @wetter.nausch.org                      @nausch.org
     
    # eine einzelne Adresse gezielt umschreiben. Alle Nachrichten die an 
    # admin@wetterstation-pliening.info addressiert sind, gehen an 
    # michael@nausch.org.
    admin@wetterstation-pliening.info       michael@nausch.org
    michael@nausch.org                      django@nausch.org
    root@nausch.org                         django@nausch.org
    virusalert@nausch.org                   django@nausch.org
    postmaster@nausch.org                   django@nausch.org

virtual_alias files in Verbindung mit postfixadmin

Verwalten wir die Domänen und Nutzerkonten mit Hilfe von Postfixadmin, werden wir nachfolgend in unsere Postfix-Konfigurationsdatei /etc/postfix/main.cf folgenden Block einfügen.

# Django : 2014-10-15 - virtuelle Mail-Domains und Mailboxen mit Anbindung an
#          das mySQL-Datenbankbackend (Verwaltung mit Hilfe von postfixadmin)
# default: virtual_mailbox_domains = $virtual_mailbox_maps
#          virtual_alias_maps = $virtual_maps
#          virtual_mailbox_maps =
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
 
virtual_alias_maps =      proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf
 
virtual_mailbox_maps =    proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_mailbox_maps.cf

Die zugehörigen Dateien, haben dann folgende Inhalte.

mysql_virtual_domains_maps.cf
 # vim /etc/postfix/mysql_virtual_domains_maps.cf
/etc/postfix/mysql_virtual_domains_maps.cf
# Django : 2013-02-07
# Definition der Datenbankanbindung zur Abfrage der virtuellen Domaenen
#
user = postfix_user
password = rbgsDK39DeM2b2btx9iMHfzd
hosts = mariadb.dmz.nausch.org
dbname = postfix
query = SELECT domain FROM domain WHERE domain='%s' AND active = '1'
mysql_virtual_alias_maps.cf
 # vim /etc/postfix/mysql_virtual_alias_maps.cf
/etc/postfix/mysql_virtual_alias_maps.cf
# Django : 2012-02-07
# Definition der Datenbankanbindung zur Abfrage der virtual Alias Maps
#
user = postfix_user
password = rbgsDK39DeM2b2btx9iMHfzd
hosts = mariadb.dmz.nausch.org
dbname = postfix
query = SELECT goto FROM alias WHERE address='%s' AND active = '1'
mysql_virtual_alias_domain_maps.cf
 # vim /etc/postfix/mysql_virtual_alias_domain_maps.cf
/etc/postfix/mysql_virtual_alias_domain_maps.cf
# Django : 2013-02-07
# Definition der Datenbankanbindung zur Abfrage der virtual Alias Domain Maps
#
user = postfix_user
password = rbgsDK39DeM2b2btx9iMHfzd
hosts = mariadb.dmz.nausch.org
dbname = postfix
query = SELECT goto FROM alias,alias_domain WHERE alias_domain.alias_domain = '%d' AND
           alias.address = CONCAT('%u', '@', alias_domain.target_domain) AND alias.active = 1
           AND alias_domain.active='1'
mysql_virtual_alias_domain_catchall_maps.cf
 # vim /etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf
/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf
# Django : 2013-02-07
# Definition der Datenbankanbindung zur Abfrage der virtual Alias Domain Catchall Maps
#
user = postfix_user
password = rbgsDK39DeM2b2btx9iMHfzd
hosts = mariadb.dmz.nausch.org
dbname = postfix
query = SELECT goto FROM alias,alias_domain WHERE alias_domain.alias_domain = '%d' AND
           alias.address = CONCAT('@', alias_domain.target_domain) AND alias.active = 1
           AND alias_domain.active='1'
mysql_virtual_mailbox_maps.cf
 # vim /etc/postfix/mysql_virtual_mailbox_maps.cf
/etc/postfix/mysql_virtual_mailbox_maps.cf
# Django : 2013-02-07
# Definition der Datenbankanbindung zur Abfrage der virtual Mailbox Maps
#
user = postfix_user
password = rbgsDK39DeM2b2btx9iMHfzd
hosts = mariadb.dmz.nausch.org
dbname = postfix
query = SELECT maildir FROM mailbox WHERE username='%s' AND active = '1'
mysql_virtual_alias_domain_mailbox_maps.cf
 # vim /etc/postfix/mysql_virtual_alias_domain_mailbox_maps.cf
/etc/postfix/mysql_virtual_alias_domain_mailbox_maps.cf
# Django : 2012-10-09
# Definition der Datenbankanbindung zur Abfrage der virtual Alias Domain Mailbox Maps
#
user = postfix_user
password = rbgsDK39DeM2b2btx9iMHfzd
hosts = mariadb.dmz.nausch.org
dbname = postfix
query = SELECT maildir FROM mailbox,alias_domain WHERE alias_domain.alias_domain = '%d'
           AND mailbox.username = CONCAT('%u', '@', alias_domain.target_domain) AND
           mailbox.active = 1 AND alias_domain.active='1'

bcc

Ergänzend zu den aus dem RPM enthaltenen Loogup_Tabellen, legen wir uns noch zwei weitere Tabellen an, nämlich die recipient_bcc_maps und die sender_bcc_maps.

bcc-Dateien

recipient_bcc_maps
  • recipient_bcc_maps Lookup-Tabelle für Blindcopies einer oder mehrerer Empfangsadressen zu einem oder mehrer Zieladressen.
    recipient_bcc_maps.db Datenbankfile zur recipient_bcc_maps-Datei.
     # vim /etc/postfix/recipient_bcc_maps
    /etc/postfix/recipient_bcc_maps
    # Django : 2014-06-11
    # Kapitel 5.2.3 bcc-Tabelle: Blindcopy einer oder mehrerer Empfangsadressen.
    #
    # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels 
    # $ postmap /etc/postfix/recipient_bcc_maps
    # die zugehörige Datenbank erzeugt werden.
    #
    # catch all, alle Nachrichten einer bestimmten (Empfangs-)Domäne kopieren
    #@pml010080.intra.nausch.org            mailsave@nausch.org
    #
    # alle Nachrichten eines einzelnen Empfängers kopieren
    #weather@nausch.org                     mailsave@nausch.org
    #
    #f2b-reports@nausch.org                 michi@mail.sskm.de
  • sender_bcc_maps Lookup-Tabelle für Blindcopies einer oder mehrerer Absenderadressen zu einem oder mehrer Zieladressen.
    sender_bcc_maps.db Datenbankfile zur sender_bcc_maps-Datei.
     # vim /etc/postfix/sender_bcc_maps
    /etc/postfix/sender_bcc_maps
    # Django : 2014-06-11
    # Kapitel 5.2.3 bcc-Tabelle: Blindcopy einer oder mehrerer Sendeadressen.
    #
    # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels  
    # $ postmap /etc/postfix/sender_bcc_maps
    # die zugehörige Datenbank erzeugt werden.
    #
    # catch all, alle Nachrichten einer bestimmten Domäne kopieren
    #@pml010080.intra.nausch.org            mailsave@nausch.org
    #
    # alle Nachrichten eines einzelnen Absenders kopieren
    #weather@nausch.org                     mailsave@nausch.org
    #
    #fail2ban@vml000080.dmz.nausch.org      michi@mail.sskm.de

In der Sektion LOOKUP-TABELLEN definieren wir nun die zuvor vorgestellten Lookup-Tabellen in der Hauptkonfigurationsdatei main.cf.

 # vim /etc/postfix/main.cf
...
 
################################################################################
## LOOKUP-TABELLEN
#
# Django : 2014-10-15 - default Datenbank Typ für die Befehle newaliases, 
#          postalias und postmap auf das performantere btree umgestellt.
# default default_database_type = hash
default_database_type = btree
 
# Django : 2014-10-15 - Trennzeichen zwischen Usernamen und Adresserweiterung 
# default: recipient_delimiter =
recipient_delimiter = +
 
# Django : 2014-10-15 - Alias-Tabelle für die Zustellung von lokalen Nachrichten
#          durch den MDA (Mail Delivery Agent) "local". Nach Änderungen an der
#          Tabelle /etc/aliases ist "newaliases" zum Neubau des Datenbankfiles
#          notwendig!
# default: alias_maps = hash:/etc/aliases, nis:mail.aliase
alias_maps = hash:/etc/aliases
#            btree:/etc/mailman/aliases
alias_database = hash:/etc/aliases
 
# Django : 2014-10-15 - Optionale Lookup Tabelle mit allen gültigen Empfängern
#          der in $relay_domains aufgeführten Domains
# default: relay_recipient_maps =
relay_recipient_maps =
#                         btree:/etc/mailman/virtual-mailman
#                         btree:/etc/mailman/roleaccounts 
 
# Django : 2014-10-15 - virtuelle Mail-Domains und Mailboxen mit Anbindung an
#          das mySQL-Datenbankbackend (Verwaltung mit Hilfe von postfixadmin)
# default: virtual_mailbox_domains = $virtual_mailbox_maps
#          virtual_alias_maps = $virtual_maps
#          virtual_mailbox_maps =
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
 
virtual_alias_maps =      proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf
 
virtual_mailbox_maps =    proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_mailbox_maps.cf
 
# Django : 2014-10-15 - BCC-Adress Lookup Tabelle mit deren Hilfe Nachrichten 
#          einzelner oder mehrerer Empfänger automatisch an einen weiteren 
#          Empfänger geschickt werden.
# default: recipient_bcc_maps = 
recipient_bcc_maps = btree:/etc/postfix/recipient_bcc_maps
 
# Django : 2014-10-15 - BCC-Adress Lookup Tabelle mit deren Hilfe Nachrichten 
#          einzelner oder mehrerer Absender automatisch an einen weiteren 
#          Empfänger geschickt werden.
sender_bcc_maps = btree:/etc/postfix/sender_bcc_maps
 
# Django : 2014-10-16 - SMTP Lookup Tabelle mit deren Hilfe eMail-Adressen der
#          Empfänger im SMTP-Envelope und im Header der eMail beim Verlassen
#          des MTA via SMTP umgeschrieben werden können.
# default: smtp_generic_maps =   
smtp_generic_maps = btree:/etc/postfix/smtp_generic_maps
 
# Django : 2014-10-16 - LMTP Lookup Tabelle mit deren Hilfe eMail-Adressen der
#          Empfänger im SMTP-Envelope und im Header der eMail beim Verlassen
#          des MTA zum MDA via LMTP umgeschrieben werden können.
# default: smtp_generic_maps =   
lmtp_generic_maps = btree:/etc/postfix/lmtp_generic_maps
 
# 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
 
# Django : 2014-10-16 - Lookup-Tabelle zum Aktivieren von "Bounce-Nachrichten"
#          an den Absender einer eMail über nicht existierende eMail-Adressen 
#          mit Angabe der neu zu nutzenden eMailadresse des Empfängers.
# default: relocated_maps = 
relocated_maps = btree:/etc/postfix/relocated_maps
 
# Django : 2015-10-15 - Ergebnisse der Adress-Verification cachen
#          Kapitel 12.2.2 Dynamische Empfänger-Verifizierung
#          Kapitel 9.5.5 envelope sender überprüfen
# default: address_verify_map = btree:$data_directory/verify_cache

Bevor wir uns nun tiefer in die einzelnen Restrictions eintauchen machen wir uns mit den Grundlagen vertraut.

Permit-Regeln

  • permit
    Liefert generell ein OK und beendet die Prüfung an der Stelle.
  • permit_mynetworks
    Akzeptiert eine eingelieferte eMail, sofern der Client aus einem vertrauenswürdigem Netz kommt. Die Defintion welches IP-Netz vertrauenswürdig ist, erfolgt über die beiden Parameter $mynetworks und $mynetworks_style.
  • permit_sasl_authenticated
    Akzeptiert eine eingelieferte eMail, sofern sich der Client erfolgreich mit SMTP-Auth authentifiziert hat.
  • permit_tls_clientcerts
    Akzeptiert eine eingelieferte eMail, sofern der Fingerprint des SSL/TLS-Client-Zertifikates in $relay_clientcerts gefunden wurde.
  • permit_mx_backup
    Akzeptiert eine eingelieferte eMail, sofern ein MX-Record der Empfängerdomäne auf unseren Mailserver zeigt und unser Mailserver damit ein nachrangiger, also ein MX-Record mit numerisch höherer Priorität, Mailserver ist.

Reject-Regeln

  • reject
    Liefert generell ein REJECT und beendet die Prüfung an der Stelle. Dem einliefernden Client wird ein fataler Fehler (5xx) signalisiert.
  • reject_non_fqdn_sender
    Blockiert die eMail, sofern die Absender-Adresse keinen FQDN1) besitzt, dies ist dann der Fall, wenn die Adresse nur aus einem Hostnamen aber keiner Domäne besteht.
  • reject_non_fqdn_recipient
    Blockiert die eMail, sofern die Empfänger-Adresse keinen FQDN2) besitzt, dies ist dann der Fall, wenn die Adresse nur aus einem Hostnamen aber keiner Domäne besteht.
  • reject_unauth_destination
    Es wird solange ein REJECT geliefert, solange nicht:
    • die Zieladresse in der Tabelle $relay_domains gelistet ist, oder
    • unser Mailserver für diese Domäne Final Destination ist. Die Domäne muss dabei entweder in $mydestination, $virtual_alias_domains oder in $inet_interfaces vorkommen.
  • reject_unknown_sender_domain
    Blockiert die eMail, sofern die Absendseradresse im DNS weder ein gültiger A- noch MX-Record verfügbar ist.
  • reject_unknown_recipient_domain
    Blockiert die eMail, sofern die Empfängeradresse im DNS weder ein gültiger A- noch MX-Record verfügbar ist.
  • reject_rbl_client
    Blockiert die eMail, sofern die Client-IP-Adresse in der jeweils genannten rbl_domain(RBL)3) geblacklistet ist.
    • reject_rbl_client zen.spamhaus.org Blockiert die eMail, wenn die Client-IP-Adresse bei zen.spamhaus.org geblacklistet ist.
    • reject_rbl_client ix.dnsbl.manitu.net Blockiert die eMail, wenn die Client-IP-Adresse bei ix.dnsbl.manitu.net geblacklistet ist.
    • reject_rbl_client bl.spamcop.net Blockiert die eMail, wenn die Client-IP-Adresse bei bl.spamcop.net geblacklistet ist.
    • reject_rbl_client dnsbl.njabl.org Blockiert die eMail, wenn die Client-IP-Adresse bei dnsbl.njabl.org geblacklistet ist.
  • reject_rhsbl_client multi.uribl.com
    Blockiert die eMail, sofern der Client-Hostname in der verwendeten rhsbl_domain(RHSBL)4) gelistet ist.
  • reject_plaintext_session
    Liefert einen REJECT, wenn die Verbindung nicht TLS transportverschlüsselt ist.

SMTP Recipient Restrictions

Nachfolgende Definitionen fügen wir nun am Ende der /etc/postfix/main.cf ein. Hierzu benutzen wir wie immer den Editor unserer Wahl.

 # vim /etc/postfix/main.cf
...

################################################################################
## SMTP RECIPIENT RESTRICTIONS
#
# Django : 2014-10-29 - Schutz unserer Empfänger mit Hilfe der Recipient 
#          Restrictions 
# default: smtpd_recipient_restrictions =
smtpd_recipient_restrictions =
#          Postmaster, abuse und andere aufgaben- oder funktionsgebundene 
#          eMail-Adressen (Role-Accounts) whitelisten
           check_recipient_access btree:/etc/postfix/access_recipient-rfc

#          Black- und Whitelisting       (Kapitel 8.2.3 White- und Blacklisting)
           check_client_access cidr:/etc/postfix/access_client
           check_helo_access btree:/etc/postfix/access_helo
           check_sender_access btree:/etc/postfix/access_sender
           check_recipient_access btree:/etc/postfix/access_recipient

#          Unsere eigenen Nutzer zulassen-/erlauben             
#                                (Kapitel 8.2.2 Relaying erlauben und verbieten)
           permit_sasl_authenticated
           permit_mynetworks

#          RBL überprüfen               (Kapitel 10.11 Realtime Blackhole Lists)
           reject_rbl_client zen.spamhaus.org
           reject_rbl_client ix.dnsbl.manitu.net
           reject_rbl_client bl.spamcop.net
           reject_rhsbl_client multi.uribl.com

#          Greylisting via postgrey checken via Unix-Socket
#                                          (Kapitel 9.2.5 postgrey installieren)
#          check_policy_service unix:postgrey/socket,

#          Policyd-Weight check over TCP-Connection 
#                                      (Kapitel 9.3 policyd-weight installieren)
#          check_client_access btree:/etc/postfix/policyd_weight_client_whitelist,
#          check_policy_service inet:127.0.0.1:12525,

#          Dynamische Prüfung auf existente Relay-Empfänger
#                            (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung)
           reject_unverified_recipient

#          Backupserver (MX) erlauben
#          permit_mx_backup

#          alles andere an relaying verbieten   
#                                (Kapitel 8.2.2 Relaying erlauben und verbieten)
           reject_unauth_destination

#          Quota-Status-Policy-Daemon am Dovecot-Backend-System
#          Dovecotbuch (ISBN 978-3-95539-74-7) Seite 219 ff.  
#                          (Kapitel 11.11 "Der Quota-Policy-Server für Postfix")
           check_policy_service inet:10.0.0.77:10000

#          Zu guter Letzt alles durchlassen, was bis jetzt noch nicht 
#          beanstandet wurde
           permit

SMTP Relay Restrictions

Nachfolgende Definitionen fügen wir nun am Ende der /etc/postfix/main.cf ein.

 # vim /etc/postfix/main.cf
...

################################################################################
## SMTP RELAY RESTRICTIONS
#
# Django : 2014-10-27 - Definition, wer über unseren MX relayen darf oder nicht. 
#          http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions
# default: smtpd_relay_restrictions = permit_mynetworks, 
#          permit_sasl_authenticated, defer_unauth_destination
#
smtpd_relay_restrictions =
# Unsere eigenen Nutzer zulassen-/erlauben
           permit_sasl_authenticated
           permit_mynetworks
# Backupserver (MX) erlauben
#           permit_mx_backup
# alles andere an relaying verbieten, d.h. mit einem finalen error 550 abweisen
           reject_unauth_destination

Somit ergibt sich vorerst folgende Hauptkonfigurationsdatei /etc/postfix/main.cf.

 # less /etc/postfix/main.cf
/etc/postfix/main.cf
################################################################################
#                                                                              #
#    Django : 2014-10-15 - Musterkonfiguration Postfix 2.11 unter CentOS 7     #
#                                                                              #
################################################################################
 
################################################################################
## INSTALLATIONS-KONFIGURATIONS INFORMATIONEN 
#
# Folgende Default-Parameter werden benutzt, sobald eine neue Postfix-Version 
# installiert wird.
#
# Django : 2014-10-31 - Vollständiger Pfad zum Postfix sendmail Programm, dem
#          zu senmail kompatiblen sendmail Befehl.
# default: sendmail_path = /usr/sbin/sendmail
sendmail_path = /usr/sbin/sendmail.postfix
 
# Django : 2014-10-31 - Vollständiger Pfad zum Postfix newaliases Programm, dem
#          zu sendmail kompatiblen Programm zum Anlegen der Alias Datenbanken.
# default: newaliases_path = /usr/bin/newaliases
newaliases_path = /usr/bin/newaliases.postfix
 
# Django : 2014-10-31 - Vollständiger Pfad zum Postfix qmail-Programm, dem zu
#          sendmail kompatiblen Programm zum Anzeigen der Maile-Queues
# default: mailq_path = /usr/bin/mailq
mailq_path = /usr/bin/mailq.postfix
 
# Django : 2014-10-31 - Gruppe für die Befehle mail submission und queue
#          management. Die Gruppe muss eine numerische eigene ID haben
#          und darf nicht mit anderen Benutzeraccounts geteilt werden,
#          auch nicht mit dem Postfix User! 
# default: setgid_group = postdrop 
setgid_group = postdrop
 
# Django : 2014-10-31 - Pfad für die Postfix Postfix HTML Dokumentation.
# default: html_directory
html_directory = no
 
# Django : 2014-10-31 - Pfad für die Postfix online man-pages.
# default: manpage_directory = /usr/local/man
manpage_directory = /usr/share/man
 
# Django : 2014-10-31 - Pfadangabe für die Postfix Beispielkonfigurationsdateien.
#          Dieser Parameter ist obsolete seit Postfix 2.1.
# default: sample_directory = /etc/postfix
sample_directory = /usr/share/doc/postfix-2.11.3/samples
 
# Django : 2014-10-31 - Pfadangabe für die Postfix README Dateien.
# default: readme_directory = no
readme_directory = /usr/share/doc/postfix-2.11.3/README_FILES
 
 
################################################################################
## PFADANGABEN DER LOKALEN INSTALLATION 
#
# Django : 2014-10-31 - Definition des Speicherortes für die Queue-Dateien von
#          Postfix. Dies ist auch der root-Pfad, falls Postfix in einer
#          chroot-Umgebung laufen sollte. In der Datei examples/chroot-setup
#          findet man bei Bedarf nützliche Hinweise und Beispiele, die 
#          beschreiben, wie man Postfix in einer chroot-Umgebung aufsetzen und 
#          betreiben kann. 
# default: queue_directory = /var/spool/postfix
queue_directory = /var/spool/postfix
 
# Django : 2014-10-31 - Vollständiger Pfad zu allen postXXX-Programmen.
# default: command_directory = /usr/sbin
command_directory = /usr/sbin
 
# Django : 2014-10-31 Vollständiger Pfad zum Verzeichnis, in dem sich alle
#          postfix Daemon Programme (die z.B. auch in der master.cf
#          aufgeführt sind) befinden. Das Verzeichnis muss root gehören!
# default: daemon_directory = /usr/libexec/postfix
daemon_directory = /usr/libexec/postfix
 
# Django : 2014-10-31 - Datenverzeichnis, in dem Postfix alle variablen Daten
#          ablegt, wie z.B. Caches, Zufallszahlen ect. pp. Das Verzeichnis 
#          muss dem nachfolgendem "mail_owner" gehören!
# default: data_directory = /var/lib/postfix
data_directory = /var/lib/postfix
 
 
################################################################################
## RECHTE BEI QUEUES UND PROZESSEN
#
# Django : 2014-10-31 - Definition des Nutzers, unter dem die meisten Postfix
#          Daemons laufen und mit dem die Queue-Dateien geschrieben werden.
#          Die User muss unique sein, d.h. er darf weder einer anderen Gruppe 
#          noch einem Anderen User angehören, sowie fremde Dateirechte und 
#          Prozesse auf dem System besitzen! Also unbedingt einen separaten 
#          Nutzer verwenden! 
# default: mail_owner = postfix
mail_owner = postfix
 
# Django : 2014-10-31 - Festlegung der Defaultrechte, die vom LDA (Local 
#          Delivery Agent) verwendet werden, wenn dieser Nachrichten in eine 
#          externe Datei schreibt, oder einem anderen Befehl übergibt.
#          Der Parameter wird auch verwendet, sollten keine userbezogenen
#          Vorgaben vorhanden sein. 
#          Auf keinen Fall einen privilegierten Nutzer oder gar den Benutzer
#          postfix verwenden!
# default: default_privs = nobody
default_privs = nobody
 
################################################################################
## DEBUGGING 
#
# Django : 2014-10-31 - Mit dem Parameter "debug_peer_level" wird festgelegt
#          um welchen Faktor der Logging-Level erhöht wird, wenn ein SMTP 
#          Client, ein Hostname oder eine IP-Adresse zu den Definitionen des
#          nachfolgenden "debug_peer_list"-Parameters passt.
# default: debug_peer_level = 2
debug_peer_level = 2
 
# Django : 2014-10-31 : Definition einer Liste aus Netzwerk-Adressen,
#          Namen, IP-Adressen oder entsprechender Postfix-Listen 
#          "type:name", für die der Loglevel gemäß dem obigen Loglevelwert
#          erhöht werden soll.
#          Bsp: debug_peer_list = 127.0.0.1
#               debug_peer_list = some.domain
#               cidr:/etc/postfix/debug_peer_list
# default: debug_peer_list =
 
# Django : 2014-10-13 - Debugger-Befehlszeile
#          Die Option "debugger_command" definiert den kompletten Debug-Aufruf,
#          das ausgeführt werden soll, sofern der Postfix Daemon mit der 
#          Option -D gestartet wurde.
#          Am Ende der Befehlskette sollte man ein "... & sleep 5" anfügen, 
#          damit damit der Debugger genügend Zeit hat loszulegen, bevor das 
#          Programm aufgerufen wird.
#
#          Da wir kein X-System auf unserem Mailserver installiert haben (wozu 
#          auch?), verwenden wir nachfolgendes Beispiel. Als Ergebnis erhalten 
#          wir damit eine Datei mit dem Namen des Prozesses und der zugehörigen 
#          ID, die im Konfigurationsverzeichnis abgespeichert wird.
#
debugger_command =
           PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont;
           echo where) | gdb $daemon_directory/$process_name $process_id 2>&1
           >$config_directory/$process_name.$process_id.log & sleep 5
 
 
################################################################################
## ZUSTÄNDIGKEITEN, VERTRAUENSWÜRDIGE NETZE UND NETZWERKK-DEFINITIONEN
#
# Django : 2014-10-15 - Hostname auf "offiziellen" DNS-MX-Record Namen gesetzt
# default: myhostname = FQDN
myhostname = mx01.nausch.org
 
# Django : 2014-10-15 - Domainpart der lokal generierten Nachrichten gesetzt
# default: myorigin = $myhostname
myorigin = $mydomain
 
# Django : 2014-10-15 - Für welche Domains ist unser Mailserver zuständig,
#          also final destination? Zusätzlich zu den Defaultwerten soll der MTA 
#          auch noch Nachrichten für die beiden Sub-Domains lists.nausch.org 
#          (Mailman) und dmarc.nausch.org (DMARC-Reportmails) annehmen.
# default: mydestination = $myhostname, localhost.$mydomain, localhost
mydestination = 
                $myhostname
                localhost.$mydomain
                localhost
                lists.nausch.org
                dmarc.nausch.org
 
# default: unbekannte Empfänger sollen abgewiesen und nicht mit einem
#          temporären Fehler 450 abgewiesen werden.
unknown_local_recipient_reject_code = 550
 
# Django : 2014-10-15 - Soll bei einem unbekanntem Ziel der genaue Tabellenname
#          bei der Ablehnung genannt werden?
# default: show_user_unknown_table_name = yes 
show_user_unknown_table_name = no
 
# Django : 2014-10-15 - auf allen Interfaces und Protokollen (IPv4 und IPv6) 
#          soll gelauscht werden 
# default: inet_interfaces = all
# default: inet_protocols = all
 
# Django : 2014-10-15 - Grundsätzlich soll erst einmal unser Mailserver nur dem
#          eigenen Host trauen, sonst niemanden! 
# default: mynetworks_style = subnet
mynetworks_style = host
 
mynetworks =
                127.0.0.0/8
                [::1]/128
                10.0.0.0/24
                10.0.10.0/26
                130.185.109.34/32
                130.185.109.87/32
 
# Django : 2015-10-15 - Backup-Mailserver explizit erlauben
# default: permit_mx_backup_networks =
permit_mx_backup_networks = 88.217.171.167/32
 
 
################################################################################
## ROUTING _ WEITERLEITEN VON NACHRICHTEN AN DAS EIGENTLICHE ZIEL
#
# Django : 2014-10-15 - Relayhost: Alle Nachrichten werden an den Relayhost
#          smtp-out.dmz.nausch.org gesendet.
# default: relayhost =
# relayhost = [smtp-out.dmz.nausch.org]
 
# Django : 2014-10-15 - Backup-Relayhost: Sollte der $relayhost nicht erreichbar
#          sein, soll sich unser MTA an den backup-relayhost 
#          smtp-backup.dmz.nausch.org senden
# default: smtp_fallback_relay = $fallback_relay 
# smtp_fallback_relay = [smtp-backup.dmz.nausch.org]
 
# Django : 2014-10-15 - Relay Domains: Postfix als eingehendes Mailrelay vor 
#          einem anderen Server
# default: relay_domains = $mydestination 
relay_domains = btree:/etc/postfix/relay_domains
 
# Django : 2014-10-15 - Nachrichten für eine bestimmte Richtung sollen
#          abweichend von den MX-Definitionen im DNS an dedizierte Ziele
#          geroutet/weitergeleitet werden.
# default: transport_maps =
transport_maps = btree:/etc/postfix/transport_maps
 
# Django : 2014-10-15 - Definition zur Erreichbarkeit unseres MDA-Servers 
#          Dovecot-IMAP
# default: virtual_transport = virtual
virtual_transport = lmtp:[10.0.0.77]:24
 
 
################################################################################
## QUEUEING-VERHALTEN
#
# Django : 2014-10-18 - Queue-Lifetime auf 3 Tage heruntersetzen, defininiert
#          die maximale Zeit, die der MX versuchen darf, eine Nachricht zuzu-
#          stellen
# default: maximal_queue_lifetime = 5d
maximal_queue_lifetime = 3d
 
# Django : 2014-03-17- Bounce-Queue-Lifetime auf 3 Tage heruntersetzen, die
#          der MTA versuchen soll eine Bouncenachricht zuzustellen.
# default: bounce_queue_lifetime = 5d
bounce_queue_lifetime = 3d
 
 
################################################################################
## NACHRICHTENGROESSE UND ZUSTELLVERSUCHE/-MENGEN 
#
# Django : 2014-10-18 Maximale Nachrichtengröße festlegen. Maximale Nachrichten-
#          größe einer Nachricht incl. der Headerinformationen darf maximal 
#          50 MB ( 52428800 = 50*1024*1024 ) betragen, darüber verweigert 
#          Postfix die Annahme. 
# default: message_size_limit = 10240000
message_size_limit = 52428800
 
# Django : 2014-10-18 Maximale Mailboxgröße einer einzelnen Mailbox bzw. 
#          Maildir-Fiels. Der Wert darf nicht kleiner als die maximale 
#          Nachrichtengröße (message_size_limit) sein.
# default: mailbox_size_limit = 10240000
mailbox_size_limit = 52428800
 
# Django : 2010-10-28 - Rate Limiting (DOS-Attacken verhindern) maximale
#          Zustellung limitieren (Kapitel 24 des Buches Postfix)
#          (Kapitel 13.14 Rate-Limiting gegenüber Clients durchsetzen)
#          Basiszeiteinheit für die Kalkulation der rate-limits
# default: anvil_rate_time_unit = 60s
#
#          Maximale Anzahl gleichzeitiger Verbindungen pro einliefernenden Host
# default : smtpd_client_connection_count_limit = 50 
smtpd_client_connection_count_limit = 20
#
#          Maximale Anzahl von Verbindungsversuchen je definierter Zeiteinheit 
#          (anvil_rate_time_unit) pro einliefernden Host
# default: smtpd_client_connection_rate_limit = 0
smtpd_client_connection_rate_limit = 20
#
#          Maximale Anzahl von erlaubten Empfänger Adressen je definierter 
#          Zeiteinheit (anvil_rate_time_unit) pro einliefernden Host
# default: smtpd_client_recipient_rate_limit = 0
smtpd_client_recipient_rate_limit = 50
#
#          Maximale Anzahl von erlaubten Anzahl von eMails je definierter Zeit-
#          einheit (anvil_rate_time_unit) pro einliefernden Host
# deafault: smtpd_client_message_rate_limit = 0
smtpd_client_message_rate_limit = 50
#
#          Welche Cleints sollen vom Rate-Limeting ausgenommen werden? Per
#          Default sind dies alle Clients aus dem eigenen Netzwerk $mynetworks
# default: smtpd_client_event_limit_exceptions = 
#          ${smtpd_client_connection_limit_exceptions:$mynetworks}
#
#          Wie oft soll der anvil-Daemon Statistikdaten ins Maillog schreiben?
# default: anvil_status_update_time = 600s         
#
#          Ausgehende Verbindungen der Delivery-Clients limitieren. Für jeden
#          einzelnen Transport kann bei Bedarf eine eigene Rate definiert 
#          werden.
# default: default_destination_rate_delay = 0s
#          error_destination_rate_delay = $default_destination_rate_delay
#          lmtp_destination_rate_delay = $default_destination_rate_delay
#          local_destination_rate_delay = $default_destination_rate_delay
#          relay_destination_rate_delay = $default_destination_rate_delay
#          retry_destination_rate_delay = $default_destination_rate_delay
#          smtp_destination_rate_delay = $default_destination_rate_delay
#          virtual_destination_rate_delay = $default_destination_rate_delay
#          Ausgehende Nachrichten des MAilinglistenservers auf 2,5 Minuten
#          setzen
smtp_destination_rate_delay = 150s
 
 
################################################################################
## RÜCKMELDUNGEN BEEINFLUSSEN UND INDIVIDUALISIEREN
#
# Django : 2014-10-18 - Greeting Banner bei der 220er Begrüßung des MTA
smtpd_banner = $myhostname ESMTP $mail_name
 
# Django : 2014-10-16 - Extra-Footer bls zweite Zeiler jeder Fehlermeldungen 
#          anfügen
smtpd_reject_footer = \c. Contact your postmaster/admin for technical assistance. He can achieve our postmaster via email: postmaster@nausch.org or via fax: +49 8121 883179. In any case, please provide the following information in your problem report: This error message, time ($localtime), client ($client_address) and server ($server_name).
 
# Django : 2014-10-16 - Anzeige des Tabellen-Namens, in der der Empfänger
#          nicht gefunden wurde. Das unterdrücken macht unter Umständen die
#          Fehlersuche etwas aufwändiger, aber Externen geht diese Detailinfo
#          im Grunde nichts an. 
# default: show_user_unknown_table_name = yes
show_user_unknown_table_name = no
 
# Django : 2014-10-24 - Adressverifikationsdetails unterdrücken
#          Weder den numerischen SMTP-reply-Code, noch den enhanced status code
#          zurückgeben. Lediglich "Recipient address lookup failed" zurückmelden.
# default: unverified_recipient_reject_reason =
unverified_recipient_reject_reason = Recipient address lookup failed
 
# Django : 2014-10-24 - Adressverifikationsdetails unterdrücken
#          Weder den numerischen SMTP-reply-Code, noch den enhanced status code
#          zurückgeben. Lediglich "Recipient address lookup failed" zurückmelden.
# default: unverified_sender_reject_reason =
unverified_sender_reject_reason = Sender address lookup failed
 
# Django : 2014-10-18 Definition der benutzerspezifischen und individualisierten 
#          Bounce-Nachrichten mit deutsch- und englischsprachigen Texten aktiviert
# default: bounce_template_file =
bounce_template_file = /etc/postfix/bounce.de-DE.cf
 
# Django : 2014-10-18 - Delivery Status Notification (DSN) selectiv sperren
#          oder freigeben
# default: smtpd_discard_ehlo_keyword_address_maps =
smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_access
 
# Django : 2014-10-18 - SMTP-Kommando VRFY sperren, mit dem eine einfache und
#          schnelle Addressverifizierung möglich ist.
# default: disable_vrfy_command = no
disable_vrfy_command = yes
 
# Django : 2015-10-08 - Fehlercode bei Verwendung der Option
#          reject_plaintext_session beim Einsatz von verpflichtender
#          TLS-Transportverschlüsselung.
#          https://tools.ietf.org/html/rfc3463#section-3.8
# default: plaintext_reject_code = 450
# plaintext_reject_code = 573
 
 
################################################################################
## LOOKUP-TABELLEN
#
# Django : 2014-10-15 - default Datenbank Typ für die Befehle newaliases, 
#          postalias und postmap auf das performantere btree umgestellt.
# default default_database_type = hash
default_database_type = btree
 
# Django : 2014-10-15 - Trennzeichen zwischen Usernamen und Adresserweiterung 
# default: recipient_delimiter =
recipient_delimiter = +
 
# Django : 2014-10-15 - Alias-Tabelle für die Zustellung von lokalen Nachrichten
#          durch den MDA (Mail Delivery Agent) "local". Nach Änderungen an der
#          Tabelle /etc/aliases ist "newaliases" zum Neubau des Datenbankfiles
#          notwendig!
# default: alias_maps = hash:/etc/aliases, nis:mail.aliase
alias_maps = hash:/etc/aliases
#            btree:/etc/mailman/aliases
alias_database = hash:/etc/aliases
 
# Django : 2014-10-15 - Optionale Lookup Tabelle mit allen gültigen Empfängern
#          der in $relay_domains aufgeführten Domains
# default: relay_recipient_maps =
relay_recipient_maps =
#                         btree:/etc/mailman/virtual-mailman
#                         btree:/etc/mailman/roleaccounts 
 
# Django : 2014-10-15 - virtuelle Mail-Domains und Mailboxen mit Anbindung an
#          das mySQL-Datenbankbackend (Verwaltung mit Hilfe von postfixadmin)
# default: virtual_mailbox_domains = $virtual_mailbox_maps
#          virtual_alias_maps = $virtual_maps
#          virtual_mailbox_maps =
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
 
virtual_alias_maps =      proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_catchall_maps.cf
#
virtual_mailbox_maps =    proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
                          proxy:mysql:/etc/postfix/mysql_virtual_alias_domain_mailbox_maps.cf
 
# Django : 2014-10-15 - BCC-Adress Lookup Tabelle mit deren Hilfe Nachrichten 
#          einzelner oder mehrerer Empfänger automatisch an einen weiteren 
#          Empfänger geschickt werden.
# default: recipient_bcc_maps = 
recipient_bcc_maps = btree:/etc/postfix/recipient_bcc_maps
 
# Django : 2014-10-15 - BCC-Adress Lookup Tabelle mit deren Hilfe Nachrichten 
#          einzelner oder mehrerer Absender automatisch an einen weiteren 
#          Empfänger geschickt werden.
sender_bcc_maps = btree:/etc/postfix/sender_bcc_maps
 
# Django : 2014-10-16 - SMTP Lookup Tabelle mit deren Hilfe eMail-Adressen der
#          Empfänger im SMTP-Envelope und im Header der eMail beim Verlassen
#          des MTA via SMTP umgeschrieben werden können.
# default: smtp_generic_maps =   
smtp_generic_maps = btree:/etc/postfix/smtp_generic_maps
 
# Django : 2014-10-16 - LMTP Lookup Tabelle mit deren Hilfe eMail-Adressen der
#          Empfänger im SMTP-Envelope und im Header der eMail beim Verlassen
#          des MTA zum MDA via LMTP umgeschrieben werden können.
# default: smtp_generic_maps =   
lmtp_generic_maps = btree:/etc/postfix/lmtp_generic_maps
 
# 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
 
# Django : 2014-10-16 - Lookup-Tabelle zum Aktivieren von "Bounce-Nachrichten"
#          an den Absender einer eMail über nicht existierende eMail-Adressen 
#          mit Angabe der neu zu nutzenden eMailadresse des Empfängers.
# default: relocated_maps = 
relocated_maps = btree:/etc/postfix/relocated_maps
 
# Django : 2015-10-15 - Ergebnisse der Adress-Verification cachen
#          Kapitel 12.2.2 Dynamische Empfänger-Verifizierung
#          Kapitel 9.5.5 envelope sender überprüfen
# default: address_verify_map = btree:$data_directory/verify_cache
 
 
################################################################################
## SMTP RECIPIENT RESTRICTIONS
#
# Django : 2014-10-29 - Schutz unserer Empfänger mit Hilfe der Recipient 
#          Restrictions 
# default: smtpd_recipient_restrictions =
smtpd_recipient_restrictions =
#          Postmaster, abuse und andere aufgaben- oder funktionsgebundene 
#          eMail-Adressen (Role-Accounts) whitelisten
           check_recipient_access btree:/etc/postfix/access_recipient-rfc
 
#          Black- und Whitelisting       (Kapitel 8.2.3 White- und Blacklisting)
           check_client_access cidr:/etc/postfix/access_client
           check_helo_access btree:/etc/postfix/access_helo
           check_sender_access btree:/etc/postfix/access_sender
           check_recipient_access btree:/etc/postfix/access_recipient
 
#          Unsere eigenen Nutzer zulassen-/erlauben             
#                                (Kapitel 8.2.2 Relaying erlauben und verbieten)
           permit_sasl_authenticated
           permit_mynetworks
 
#          RBL überprüfen               (Kapitel 10.11 Realtime Blackhole Lists)
           reject_rbl_client zen.spamhaus.org
           reject_rbl_client ix.dnsbl.manitu.net
           reject_rbl_client bl.spamcop.net
           reject_rhsbl_client multi.uribl.com
 
#          Greylisting via postgrey checken via Unix-Socket
#                                          (Kapitel 9.2.5 postgrey installieren)
#          check_policy_service unix:postgrey/socket,
 
#          Policyd-Weight check over TCP-Connection 
#                                      (Kapitel 9.3 policyd-weight installieren)
#          check_client_access btree:/etc/postfix/policyd_weight_client_whitelist,
#          check_policy_service inet:127.0.0.1:12525,
 
#          Dynamische Prüfung auf existente Relay-Empfänger
#                            (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung)
           reject_unverified_recipient
 
#          Backupserver (MX) erlauben
           permit_mx_backup
 
#          alles andere an relaying verbieten   
#                                (Kapitel 8.2.2 Relaying erlauben und verbieten)
           reject_unauth_destination
 
#          Quota-Status-Policy-Daemon am Dovecot-Backend-System
#          Dovecotbuch (ISBN 978-3-95539-74-7) Seite 219 ff.  
#                          (Kapitel 11.11 "Der Quota-Policy-Server für Postfix")
           check_policy_service inet:10.0.0.77:10000
 
#          Zu guter Letzt alles durchlassen, was bis jetzt noch nicht 
#          beanstandet wurde
           permit
 
 
################################################################################
## SMTP RELAY RESTRICTIONS
#
# Django : 2014-10-27 - Definition, wer über unseren MX relayen darf oder nicht. 
#          http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions
# default: smtpd_relay_restrictions = permit_mynetworks, 
#          permit_sasl_authenticated, defer_unauth_destination
#
smtpd_relay_restrictions =
# Unsere eigenen Nutzer zulassen-/erlauben
           permit_sasl_authenticated,
           permit_mynetworks,
# Backupserver (MX) erlauben
           permit_mx_backup,
# alles andere an relaying verbieten, d.h. mit einem finalen error 550 abweisen
           reject_unauth_destination

Zur Aktivierung unserer Konfiguration benutzen wir systemctl.

 # systemctl restart postfix

Da keine Rückmeldung erfolgte können wir davon ausgehen, dass alle unsere Konfigurationsoptionen unseren Wünschen entsprechend gesetzt wurden.

Wir können aber auch den Status unseres Mailservers abfragen.

 # systemctl status postfix
postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled)
   Active: active (running) since Mon 2014-11-03 22:35:18 CET; 3s ago
  Process: 3222 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
  Process: 3206 ExecReload=/usr/sbin/postfix reload (code=exited, status=0/SUCCESS)
  Process: 3236 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
  Process: 3234 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
  Process: 3231 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
 Main PID: 3309 (master)
   CGroup: /system.slice/postfix.service
           ├─3309 /usr/libexec/postfix/master -w
           ├─3310 pickup -l -t unix -u
           └─3311 qmgr -l -t unix -u

Nov 03 22:35:17 vml000087.dmz.nausch.org systemd[1]: Starting Postfix Mail Transport Agent...
Nov 03 22:35:18 vml000087.dmz.nausch.org postfix/master[3309]: daemon started -- version 2.11.3, configuration /etc/postfix
Nov 03 22:35:18 vml000087.dmz.nausch.org systemd[1]: Started Postfix Mail Transport Agent.

Links


1) , 2)
Full Qualified Domain Name
3)
Realtime Blackhole List
4)
Right-Hand Sided Blacklist
Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
  • centos/mail_c7/mta_4.txt
  • Zuletzt geändert: 20.04.2018 10:46.
  • (Externe Bearbeitung)