Konfiguration unseres MTAs Postfix 3.x unter CentOS 7

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 eMails 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.

Postfix from the scratch

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:

Wir stoppen den vorhandenen Postfix-SMTP-Server.
```
 # systemctl stop postfix
```
Anschließend wechseln wir in das Konfigurationsverzeichnis /etc/postfix/.
```
 # cd /etc/postfix
```

Nun löschen oder verschieben wir die nicht benötigten Dateien:

löschen

 # rm canonical generic header_checks relocated virtual transport \
      main.cf main.cf.proto master.cf.proto -f

verschieben

 # mkdir -p /etc/postfix/.orig/

 # mv canonical generic header_checks relocated virtual transport \
      main.cf main.cf.proto master.cf.proto /etc/postfix/.orig/ -f

Anlegen einer leeren main.cf.
```
 # touch main.cf
```

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

/etc/postfix/
├── access
├── dynamicmaps.cf
├── dynamicmaps.cf.d
├── main.cf
├── master.cf
└── postfix-files

 # ls -Al  /etc/postfix/

total 12
-rw-r--r--. 1 root root  164 Jan 17 17:09 dynamicmaps.cf
drwxr-xr-x. 2 root root    6 Jan 17 17:09 dynamicmaps.cf.d
-rw-r--r--. 1 root root    0 Jan 27 17:50 main.cf
-rw-r--r--. 1 root root 6295 Jan 17 17:09 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.

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 tiefer gehende Informationen 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 
#
# Der Kopatibilitäts Level definiert, welche Standardeinstellungen Postfix für 
# die Einstellungen main.cf und master.cf verwendet. Diese Standardeinstellungen 
# werden sich im Laufe der Zeit voraussichtlich ändern!
#
# Damit die Lauffähigkeit des Postfix-Daemon nicht gefährdet wird der Daemon
# rückwärtskompatible Standardeinstellungen verwenden und dies auch entsprechend
# protokollieren. So kann bei einer Migration definiert werden,  ob rückwärts-
# kompatible Standardeinstellungen in main.cf oder master.cf dauerhaft 
# vorgenommen werden müssen.
#
# Nach erfolgter Überprüfung ist der compatibility_level, wie in der Datei 
# /usr/share/doc/postfix-3.*/README_FILES/RELEASE_NOTES 
# empfohlen, entsprechend anzupassen.
#
# Django : 2019-01-27 - Kompatibilitäts-Level der Postfix 3 Installation
#          Standardwert 2 definiert eine Neuinstalltion und kein (!) Upgrade.
# default: compatibility_level = 2
compatibility_level = 2
 
# Folgende Default-Parameter werden benutzt, sobald eine neue Postfix-Version 
# installiert wird.
#
# Django : 2019-01-27 - 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 : 2019-01-27 - 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 : 2019-01-27 - 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 : 2019-01-27 - 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 : 2019-01-27 - Pfad für die Postfix Postfix HTML Dokumentation.
# default: html_directory
html_directory = no
 
# Django : 2019-01-27 - Pfad für die Postfix online man-pages.
# default: manpage_directory = /usr/local/man
manpage_directory = /usr/share/man
 
# Django : 2019-01-27 - 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-3.3.2/samples
 
# Django : 2019-01-27 - Pfadangabe für die Postfix README Dateien.
# default: readme_directory = no
readme_directory = /usr/share/doc/postfix-3.3.2/README_FILES
 
# Django : 2019-01-27 - Pfadangabe für das Postfix Metadirectory
# default: meta_directory = /etc/postfix
meta_directory = /etc/postfix
 
# Django : 2019-01-27 - Pfadangabe für das SHLIB-Verzeichnis
# default: shlib_directory = /usr/lib/postfix
shlib_directory = /usr/lib/postfix

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 : 2019-01-27 - 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 : 2019-01-27 - Vollständiger Pfad zu allen postXXX-Programmen.
# default: command_directory = /usr/sbin
command_directory = /usr/sbin
 
# Django : 2019-01-27 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 : 2019-01-27 - 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

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

 # vim /etc/postfix/main.cf

################################################################################
## RECHTE BEI QUEUES UND PROZESSEN
#
# Django : 2019-01-27 - 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 : 2019-01-27 - 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

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

 # vim /etc/postfix/main.cf

################################################################################
## DEBUGGING 
#
# Django : 2019-01-27 - 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 : 2019-01-27 : 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 : 2019-01-27 - 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

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 : 2019-01-27 - Hostname auf "offiziellen" DNS-MX-Record Namen gesetzt
# default: myhostname = FQDN
myhostname = mx1.nausch.org
 
# Django : 2019-01-27 - Domainpart der lokal generierten Nachrichten gesetzt
# default: myorigin = $myhostname
myorigin = $mydomain
 
# Django : 2019-01-27 - 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
 
# Django : 2019-01-27 - Ablehnung unbekannter 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 : 2019-01-27 - 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 : 2019-01-27 - auf allen Interfaces und Protokollen (IPv4 und IPv6) 
#          soll gelauscht werden 
# default: inet_interfaces = all
# default: inet_protocols = all
 
# Django : 2019-01-27 - 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/25
 
# Django : 2019-01-27 - Backup-Mailserver explizit erlauben
# default: permit_mx_backup_networks =
permit_mx_backup_networks = 88.217.171.167/32

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 : 2019-01-27 - Relayhost: Alle Nachrichten werden an den Relayhost
#          smtp-out.dmz.nausch.org gesendet.
# default: relayhost =
# relayhost = [smtp-out.dmz.nausch.org]
 
# Django : 2019-01-27 - 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 : 2019-01-27 - Relay Domains: Postfix als eingehendes Mailrelay vor 
#          einem anderen Server
# default: relay_domains = $mydestination 
relay_domains = btree:/etc/postfix/relay_domains
 
# Django : 2019-01-27 - 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 : 2019-01-27 - Definition zur Erreichbarkeit unseres MDA-Servers 
#          Dovecot-IMAP
# default: virtual_transport = virtual
virtual_transport = lmtp:[imap.dmz.nausch.org]:24

relay_domains

relay_domains Lookup-Tabelle zur Definition der Domänen für die unser Mailserver Nachricht annehmen soll.
relay_domains.db Datenbankfile zur relay_domains-Datei.

 # vim /etc/postfix/relay_domains

/etc/postfix/relay_domains

# Django : 2019-01-27
# Kapitel 12.1 Postfix als eingehendes Mailrelay vor einem anderen Server
# Lookup-Tabelle zur Definition der Domänen für die unser Mailserver Nachricht annehmen soll.
# Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels  
# 
#                  $ postmap /etc/postfix/relay_domains
#
# die zugehörige Datenbank erzeugt werden.                                                              
#                                                                                                       
# Relevant ist erst eimal nur die erste Spalte. Die zweite Spalte dient nur zum Erhalten der Tabellenstruktur und
# kann daher z.B. als Hinweisfeld zum Dokumentieren verwendet werden.                                            
# Beispiel:                                                                                                      
# omni128.de                    meine eigene Domäne                                                              
#                                                                                                                
# Da für jede Domäne auch ein Transportweg definiert werden muss, erledigen wir die Definition des selbigen gleich 
# hier in dieser Tabelle, in dem wir die Spalte zwei hierzu verwenden.                                             
#nausch.org                     lmtp:[10.0.0.70]:24

transport_maps

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

# Django : 2019-01-27
# 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_maps
#
# 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

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 : 2019-01-27 - 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 : 2019-01-27- Bounce-Queue-Lifetime auf 3 Tage heruntersetzen, die
#          der MTA versuchen soll eine Bouncenachricht zuzustellen.
# default: bounce_queue_lifetime = 5d
bounce_queue_lifetime = 3d

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 : 2019-01-27 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 : 2019-01-27 Maximale Mailboxgröße einer einzelnen Mailbox bzw. 
#          Maildir-Files. Der Wert darf nicht kleiner als die maximale 
#          Nachrichtengröße (message_size_limit) sein.
# default: mailbox_size_limit = 10240000
mailbox_size_limit = 52428800
 
# Django : 2019-01-27 - 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
# default: smtpd_client_message_rate_limit = 0
smtpd_client_message_rate_limit = 50
#
#          Welche Clients 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!

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 : 2019-01-27 - Greeting Banner bei der 220er Begrüßung des MTA
smtpd_banner = $myhostname ESMTP $mail_name
 
# Django : 2019-01-27 - Extra-Footer als 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 : 2019-01-27 - 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 : 2019-01-27 - 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 : 2019-01-27 - 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 : 2019-01-27 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 : 2019-01-27 - 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 : 2019-01-27 - SMTP-Kommando VRFY sperren, mit dem eine einfache und
#          schnelle Addressverifizierung möglich ist.
# default: disable_vrfy_command = no
disable_vrfy_command = yes
 
# Django : 2019-01-27 - 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.

Port 25MUA - MSA VerkehrTCP/IP - Port 587MDA(Mail Delivery Agent)Dovecot IMAP-ServerTCP/IP - Port 24MTA(Mail Transport Agent)andere SMTP-Server (Relayhosts)im Internet bzw. IntranetTCP/IP - Port 25MailmanWeitergabe der eMailan Mailinglisten / wie Mailmanoder via UUCP ...mailboxPostfix - Queue"mailbox"lokale ZustellungLookup Table canonical_mapsÜbersetzungstabelle zumUmschreiben von nicht-lokalenEmpfängeradressenLookup Table virtual_mapsTabelle mit der Empfängeradressealler lokalen, virtuellen undentfernten eMailadressenRealtime Blockhole ListsNutzung von RBL zum Prüfenvon einliefernden Hostsreverse DNS-Abfrage z.B.bei SPAMHAUSLookup Table relocated_mapsTabelle für die Bounce-Nachrichtenmit Angabe der neuen eMailadressebei verzogenen Accounts.Lookup Table access_clientLookup Table access_heloLookup Table access_recipientLookup Table access_recipient-rfcLookup Table access_senderTabellen zum Black- und Whitelistenan Hand der IP-Adrese, Hostname,Empfänger oder SenderLookup Table transport_mapsTabelle zur adressabhängigenWeiterleitung an einenweiteren (finalen) MTA.Lookup Table /etc/aliasesTabelle mit der lokalen eMailsan lokale Empfänger zugewiesenwerden können.Lookup Table .forwardTabelle zur Steuerung vonautomatischen AnwesenheitsnachrichtenLookup Table generic_mapsTabelle zum Umschreibenvon eMailadressenbeim Versenden.Lookup Table lmtp_generic_mapsTabelle zum Umschreiben von EmpfängereMail-Adressen im Envelope und Header

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 : 2019-01-27 - 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 : 2019-01-27 - Trennzeichen zwischen Usernamen und Adresserweiterung 
# default: recipient_delimiter =
recipient_delimiter = +

Mit Hilfe der aliases-Tabelle lassen sich lokale eMailadressen umschreiben und so die Nachrichten an andere Postfächer 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 : 2019-01-27 - 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 : 2019-01-27 - 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!

Die für Postfix relevante Konfigurationsoptionen sind hierbei alaias_maps und alias_database.

# Django : 2019-01-27 - 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
alias_database =          hash:/etc/aliases

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 corresponding action.

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

       multi-line text
              A logical line starts with non-whitespace text. A line that starts with whitespace continues a log‐
              ical line.

EMAIL ADDRESS PATTERNS
       With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, pat‐
       terns 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 table. By default, Post‐
       fix   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  pos‐
              sible.

              NOTE  1: The access map lookup key must be in canonical form: do not specify unnecessary null char‐
              acters, 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 table, or until further truncation is not pos‐
              sible.

              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 char‐
              acters, 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 autho‐
              rization 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 spec‐
       ified 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 numerical  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, disconnect 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 interoper‐
                     ability 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 specified, otherwise reply with a generic  error  response  mes‐
              sage.

       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  mes‐
              sage.

              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, with Postfix 3.0 only
              the last action will be used.

              This feature is available in Postfix 3.0 and later.

       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 destination is described in the manual page of  the  corresponding  delivery
              agent.  More information about external content filters is in the Postfix FILTER_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 recipi‐
              ent's transport but not the next-hop destination, specify an empty filter destination (Postfix  2.7
              and  later),  or specify a transport: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 features.

              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 significant fraction of $maxi‐
              mal_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  cannot  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).  When multiple REDIRECT actions fire, only the last one takes effect.

              Note: this action overrides the FILTER action, and currently overrides all recipients of  the  mes‐
              sage.

              This feature is available in Postfix 2.1 and later.

       INFO optional text...
              Log  an informational record with the optional text, together with client information and if avail‐
              able, with helo, sender, recipient and protocol information.

              This feature is available in Postfix 3.0 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 sta‐
       tus code is specified in an access table, it is subject to modification. 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 transform 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 expres‐
       sions. 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  bro‐
       ken 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  sub‐
       strings 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 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.

       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  exam‐
       ple  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 information.
       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

       Wietse Venema
       Google, Inc.
       111 8th Avenue
       New York, NY 10011, 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 : 2019-01-27
# 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 : 2019-01-27
# 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 : 2019-01-27
# 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
webmaster@      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 : 2019-01-27
# 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 : 2019-01-27
# 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

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 map‐
       ping 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) com‐
       mand.  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/canonical" to rebuild an indexed file after changing the corre‐
       sponding 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_re‐
       write_clients = static:all".

       Typically, one would use the canonical(5) table to replace login names by Firstname.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  charac‐
              ter is a `#'.

       multi-line text
              A logical line starts with non-whitespace text. A line that starts with whitespace continues a log‐
              ical line.

TABLE SEARCH ORDER
       With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, each
       user@domain query produces a sequence of query patterns as described below.

       Each  query  pattern  is sent to each specified lookup table before trying the next query pattern, until a
       match is found.

       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  pro‐
              duce 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 $mydestina‐
              tion, 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 precedence.

              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
              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.

       ·      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 expres‐
       sions. 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  sub‐
       strings 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 broken 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  sum‐
       mary. 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  incomplete  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 envelope_sender,  envelope_recipi‐
              ent, 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 information.
       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

       Wietse Venema
       Google, Inc.
       111 8th Avenue
       New York, NY 10011, 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 : 2019-01-27
# 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 : 2019-01-27
# 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

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 charac‐
ter is a `#'.

multi-line text
A logical line starts with non-whitespace text. A line that starts with whitespace continues a log‐
ical line.

TABLE SEARCH ORDER
With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, each
user@domain query produces a sequence of query patterns as described below.

Each query pattern is sent to each specified lookup table before trying the next query pattern, until a
match is found.

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 $mydestina‐
tion, 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 precedence.

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 expres‐
sions. 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 sub‐
strings 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 broken 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 sum‐
mary. See postconf(5) for more details including examples.

smtp_generic_maps
Address mapping lookup table for envelope and header sender and recipient addresses while deliver‐
ing 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 information.
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

Wietse Venema
Google, Inc.
111 8th Avenue
New York, NY 10011, USA

GENERIC(5)

Auch hier editieren wir nicht diese Vorlage- und Musterdatei /etc/postfix/generic, 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

# Django : 2019-01-27
# 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

# Django : 2019-01-27
# 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

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) com‐
mand. 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/relocated" to rebuild an indexed file after changing the corre‐
sponding 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 charac‐
ter is a `#'.

· A logical line starts with non-whitespace text. A line that starts with whitespace continues a log‐
ical line.

TABLE SEARCH ORDER
With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, pat‐
terns 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 $mydestination, 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 expres‐
sions 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 sub‐
strings 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 broken 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 sum‐
mary. 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 information.
DATABASE_README, Postfix lookup table overview
ADDRESS_REWRITING_README, address rewriting guide

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

List of lookup tables for relocated users or sites.