Postfix ist die gängigste Alternative zu dem Standard-Email-Programm Sendmail in der Unix/Linux-Welt. Postfix ist schneller, einfach zu konfigurieren und ein sicherer MTA (Mail Transfer Agent).

Bitte beachten - Für den erfolgreichen Betrieb eines eigenen MailExchangers - e-Mail-Servers sollten Sie im Besitz einer festen IP-Adresse sein !!!

Jede ernst zunehmende Linux-Distribution sollte ein vorkonfiguriertes Postfix-Paket mit sich bringen. Deswegen ist eine Installation auch unter CentOS eine Sache des Paket-Managers yum.

Ab hier werden root-Rechte zur Ausführung der nachfolgenden Befehle benötigt. Um root zu werden geben Sie bitte folgenden Befehl ein:

$ su -
Password: 

Um evtl. Probleme zu vermeiden, sollte der aktuelle MTA - Sendmail mit folgendem Befehl gestoppt werden:

# service sendmail stop
Shutting down sm-client:                                   [  OK  ]
Shutting down sendmail:                                    [  OK  ]

Um das starten des noch aktuelle MTA - Sendmail dauerhaft, auch nach einem Systemstart zu verhindern, kann folgender Befehl genutzt werden. Hier wird der MTA - Sendmail aus den Start-Scripten der einzelnen Runlevel des Betriebssystems herausgenommen:

# chkconfig sendmail off

Eine Installation sollte immer über folgenden Befehl erfolgen:

# yum postfix install

Nach der Installation, kann mit folgendem Befehl überprüft werden, was alles im Paket postfix.i386 enthalten ist:

# rpm -qil postfix | more
Name        : postfix                      Relocations: (not relocatable)
Version     : 2.3.3                             Vendor: CentOS
Release     : 2.1.el5_2                     Build Date: Thu 14 Aug 2008 11:06:38 PM CEST
Install Date: Mon 24 Nov 2008 12:52:19 PM CET      Build Host: builder16.centos.org
Group       : System Environment/Daemons    Source RPM: postfix-2.3.3-2.1.el5_2.src.rpm
Size        : 8332580                          License: IBM Public License
Signature   : DSA/SHA1, Fri 15 Aug 2008 12:59:49 PM CEST, Key ID a8a447dce8562897
URL         : http://www.postfix.org
Summary     : Postfix Mail Transport Agent
Description :
Postfix is a Mail Transport Agent (MTA), supporting LDAP, SMTP AUTH (SASL),
TLS
/etc/pam.d/smtp.postfix
/etc/postfix
/etc/postfix/LICENSE
/etc/postfix/TLS_LICENSE
/etc/postfix/access
/etc/postfix/bounce.cf.default
/etc/postfix/canonical
/etc/postfix/generic
/etc/postfix/header_checks
/etc/postfix/main.cf
/etc/postfix/main.cf.default
/etc/postfix/makedefs.out
/etc/postfix/master.cf
/etc/postfix/post-install
/etc/postfix/postfix-files
/etc/postfix/postfix-script
/etc/postfix/relocated
/etc/postfix/transport
/etc/postfix/virtual
/etc/rc.d/init.d/postfix
/usr/bin/mailq.postfix
/usr/bin/newaliases.postfix
/usr/bin/rmail.postfix
/usr/lib/sasl/smtpd.conf
/usr/lib/sasl2/smtpd.conf
/usr/lib/sendmail.postfix
/usr/libexec/postfix
/usr/libexec/postfix/anvil
/usr/libexec/postfix/bounce
/usr/libexec/postfix/cleanup
/usr/libexec/postfix/discard
/usr/libexec/postfix/error
/usr/libexec/postfix/flush
/usr/libexec/postfix/lmtp
/usr/libexec/postfix/local
/usr/libexec/postfix/master
/usr/libexec/postfix/nqmgr
/usr/libexec/postfix/oqmgr
/usr/libexec/postfix/pickup
/usr/libexec/postfix/pipe
/usr/libexec/postfix/proxymap
/usr/libexec/postfix/qmgr
/usr/libexec/postfix/qmqpd
/usr/libexec/postfix/scache
/usr/libexec/postfix/showq
/usr/libexec/postfix/smtp
/usr/libexec/postfix/smtpd
/usr/libexec/postfix/spawn
/usr/libexec/postfix/tlsmgr
/usr/libexec/postfix/trivial-rewrite
/usr/libexec/postfix/verify
/usr/libexec/postfix/virtual
/usr/sbin/postalias
/usr/sbin/postcat
/usr/sbin/postconf
/usr/sbin/postdrop
/usr/sbin/postfix
/usr/sbin/postkick
/usr/sbin/postlock
/usr/sbin/postlog
/usr/sbin/postmap
/usr/sbin/postqueue
/usr/sbin/postsuper
/usr/sbin/qshape
/usr/sbin/sendmail.postfix
/usr/sbin/smtp-sink
/usr/sbin/smtp-source
/usr/share/doc/postfix-2.3.3
/usr/share/doc/postfix-2.3.3/README-Postfix-SASL-RedHat.txt
/usr/share/doc/postfix-2.3.3/README_FILES
/usr/share/doc/postfix-2.3.3/README_FILES/AAAREADME
/usr/share/doc/postfix-2.3.3/README_FILES/ADDRESS_CLASS_README
/usr/share/doc/postfix-2.3.3/README_FILES/ADDRESS_REWRITING_README
/usr/share/doc/postfix-2.3.3/README_FILES/ADDRESS_VERIFICATION_README
/usr/share/doc/postfix-2.3.3/README_FILES/BACKSCATTER_README
/usr/share/doc/postfix-2.3.3/README_FILES/BASIC_CONFIGURATION_README
/usr/share/doc/postfix-2.3.3/README_FILES/BUILTIN_FILTER_README
/usr/share/doc/postfix-2.3.3/README_FILES/CDB_README
/usr/share/doc/postfix-2.3.3/README_FILES/CONNECTION_CACHE_README
/usr/share/doc/postfix-2.3.3/README_FILES/CONTENT_INSPECTION_README
/usr/share/doc/postfix-2.3.3/README_FILES/DATABASE_README
/usr/share/doc/postfix-2.3.3/README_FILES/DB_README
/usr/share/doc/postfix-2.3.3/README_FILES/DEBUG_README
/usr/share/doc/postfix-2.3.3/README_FILES/DSN_README
/usr/share/doc/postfix-2.3.3/README_FILES/ETRN_README
/usr/share/doc/postfix-2.3.3/README_FILES/FILTER_README
/usr/share/doc/postfix-2.3.3/README_FILES/INSTALL
/usr/share/doc/postfix-2.3.3/README_FILES/IPV6_README
/usr/share/doc/postfix-2.3.3/README_FILES/LDAP_README
/usr/share/doc/postfix-2.3.3/README_FILES/LINUX_README
/usr/share/doc/postfix-2.3.3/README_FILES/LMTP_README
/usr/share/doc/postfix-2.3.3/README_FILES/LOCAL_RECIPIENT_README
/usr/share/doc/postfix-2.3.3/README_FILES/MAILDROP_README
/usr/share/doc/postfix-2.3.3/README_FILES/MILTER_README
/usr/share/doc/postfix-2.3.3/README_FILES/MYSQL_README
/usr/share/doc/postfix-2.3.3/README_FILES/NFS_README
/usr/share/doc/postfix-2.3.3/README_FILES/OVERVIEW
/usr/share/doc/postfix-2.3.3/README_FILES/PACKAGE_README
/usr/share/doc/postfix-2.3.3/README_FILES/PCRE_README
/usr/share/doc/postfix-2.3.3/README_FILES/PGSQL_README
/usr/share/doc/postfix-2.3.3/README_FILES/QMQP_README
/usr/share/doc/postfix-2.3.3/README_FILES/QSHAPE_README
/usr/share/doc/postfix-2.3.3/README_FILES/RELEASE_NOTES
/usr/share/doc/postfix-2.3.3/README_FILES/RESTRICTION_CLASS_README
/usr/share/doc/postfix-2.3.3/README_FILES/SASL_README
/usr/share/doc/postfix-2.3.3/README_FILES/SCHEDULER_README
/usr/share/doc/postfix-2.3.3/README_FILES/SMTPD_ACCESS_README
/usr/share/doc/postfix-2.3.3/README_FILES/SMTPD_POLICY_README
/usr/share/doc/postfix-2.3.3/README_FILES/SMTPD_PROXY_README
/usr/share/doc/postfix-2.3.3/README_FILES/STANDARD_CONFIGURATION_README
/usr/share/doc/postfix-2.3.3/README_FILES/TLS_README
/usr/share/doc/postfix-2.3.3/README_FILES/TUNING_README
/usr/share/doc/postfix-2.3.3/README_FILES/ULTRIX_README
/usr/share/doc/postfix-2.3.3/README_FILES/UUCP_README
/usr/share/doc/postfix-2.3.3/README_FILES/VERP_README
/usr/share/doc/postfix-2.3.3/README_FILES/VIRTUAL_README
/usr/share/doc/postfix-2.3.3/README_FILES/XCLIENT_README
/usr/share/doc/postfix-2.3.3/README_FILES/XFORWARD_README
/usr/share/man/man1/mailq.postfix.1.gz
/usr/share/man/man1/newaliases.postfix.1.gz
/usr/share/man/man1/postalias.1.gz
/usr/share/man/man1/postcat.1.gz
/usr/share/man/man1/postconf.1.gz
/usr/share/man/man1/postdrop.1.gz
/usr/share/man/man1/postfix.1.gz
/usr/share/man/man1/postkick.1.gz
/usr/share/man/man1/postlock.1.gz
/usr/share/man/man1/postlog.1.gz
/usr/share/man/man1/postmap.1.gz
/usr/share/man/man1/postqueue.1.gz
/usr/share/man/man1/postsuper.1.gz
/usr/share/man/man1/qshape.1.gz
/usr/share/man/man1/sendmail.postfix.1.gz
/usr/share/man/man1/smtp-sink.1.gz
/usr/share/man/man1/smtp-source.1.gz
/usr/share/man/man5/access.5.gz
/usr/share/man/man5/aliases.postfix.5.gz
/usr/share/man/man5/body_checks.5.gz
/usr/share/man/man5/bounce.5.gz
/usr/share/man/man5/canonical.5.gz
/usr/share/man/man5/cidr_table.5.gz
/usr/share/man/man5/generic.5.gz
/usr/share/man/man5/header_checks.5.gz
/usr/share/man/man5/ldap_table.5.gz
/usr/share/man/man5/master.5.gz
/usr/share/man/man5/mysql_table.5.gz
/usr/share/man/man5/nisplus_table.5.gz
/usr/share/man/man5/pcre_table.5.gz
/usr/share/man/man5/pgsql_table.5.gz
/usr/share/man/man5/postconf.5.gz
/usr/share/man/man5/regexp_table.5.gz
/usr/share/man/man5/relocated.5.gz
/usr/share/man/man5/tcp_table.5.gz
/usr/share/man/man5/transport.5.gz
/usr/share/man/man5/virtual.5.gz
/usr/share/man/man8/anvil.8.gz
/usr/share/man/man8/bounce.8.gz
/usr/share/man/man8/cleanup.8.gz
/usr/share/man/man8/defer.8.gz
/usr/share/man/man8/discard.8.gz
/usr/share/man/man8/error.8.gz
/usr/share/man/man8/flush.8.gz
/usr/share/man/man8/lmtp.8.gz
/usr/share/man/man8/local.8.gz
/usr/share/man/man8/master.8.gz
/usr/share/man/man8/oqmgr.8.gz
/usr/share/man/man8/pickup.8.gz
/usr/share/man/man8/pipe.8.gz
/usr/share/man/man8/proxymap.8.gz
/usr/share/man/man8/qmgr.8.gz
/usr/share/man/man8/qmqpd.8.gz
/usr/share/man/man8/scache.8.gz
/usr/share/man/man8/showq.8.gz
/usr/share/man/man8/smtp.8.gz
/usr/share/man/man8/smtpd.8.gz
/usr/share/man/man8/spawn.8.gz
/usr/share/man/man8/tlsmgr.8.gz
/usr/share/man/man8/trace.8.gz
/usr/share/man/man8/trivial-rewrite.8.gz
/usr/share/man/man8/verify.8.gz
/usr/share/man/man8/virtual.8.gz
/var/spool/postfix
/var/spool/postfix/active
/var/spool/postfix/bounce
/var/spool/postfix/corrupt
/var/spool/postfix/defer
/var/spool/postfix/deferred
/var/spool/postfix/flush
/var/spool/postfix/hold
/var/spool/postfix/incoming
/var/spool/postfix/maildrop
/var/spool/postfix/pid
/var/spool/postfix/private
/var/spool/postfix/public
/var/spool/postfix/saved
/var/spool/postfix/trace

Folgender Benutzer wurde ebenfalls angelegt, was mit folgende Befehl überprüft werden kann:

# cat /etc/passwd | grep post
postfix:x:89:89::/var/spool/postfix:/sbin/nologin

Desweiteren wurden auch folgende Gruppen angelegt, was mit folgendem Befehl überprüft werden kann:

# cat /etc/group | grep post
mail:x:12:mail,postfix
postdrop:x:90:
postfix:x:89:

Um das Starten des neuen MTA - Postfix auch nach einem System-(re)-start auch in Zukunft dauerhaft zu realisieren, kann folgender Befehl genutzt werden. Hier wird der MTA - Postfix zu den Start-Scripten der einzelnen Runlevel des Betriebssystem hinzugefügt:

# chkconfig postfix on

Ein Überprüfung, ob nur noch der Postfix in den einzelnen Runlevel des Betriebssystems bei einem system-(re)-start mit gestartet wird und der Sendmail nicht mehr, kann mit folgenden Befehlen abgefragt werden:

# chkconfig --list | grep sendmail
sendmail        0:off   1:off   2:off   3:off   4:off   5:off   6:off

und

# chkconfig --list | grep postfix
postfix         0:off   1:off   2:on    3:on    4:on    5:on    6:off

Um einen komfortablen Wechsel zwischen den MTA's - Sendmail und Postfix zu realisieren, sollten noch folgende RPM unter CentOS installiert werden:

• system-switch-mail.noarch - The Mail Transport Agent Switcher.
• system-switch-mail-gnome.noarch - A GUI interface for Mail Transport Agent Switcher.

Die Installation kann mit folgendem Befehl durchgeführt werden:

# yum install system-switch-mail system-switch-mail-gnome

Nach einer erfolgreichen Installation, kann durch folgenden Befehl die grafische Benutzeroberfläche des system-switch-mail-Tools aufgerufen werden:

# system-switch-mail

Hier kann dann bequem Postfix ausgewählt werden und anschließend mit der linken Maustaste der [OK]-Button (Knopf) angeklickt werden. Das Ergebnis dieser Aktion sollte dann mit folgender Anzeige enden:

Das system-switch-mail-Tool ermöglicht es Postfix so zu nutzen, als wäre noch ein Sendmail installiert!

Das system-switch-mail-Tool startet den Postfix ebenfalls gleich!

Da Postfix nicht ganz allein im jeweiligen System steht, sondern auch Abhängigkeiten zu anderen Komponenten wie z.B.

• named - BIND - DNS-Server
• iptables - Paketfilter

hat, sind auch Konfigurationen dieser Komponenten erforderlich.

Falls im Netzwerk, egal ob privat oder öffentlich, ein eigener DNS-Server betrieben wird, muss dieser auch eine korrekte Antwort auf die Frage nach dem MailExchanger (e-Mail Austauscher) geben können.

Auf die Grundlagen und Einzelheiten der Konfiguration eines DNS-Servers wie z.B. BIND, kann aus Gründen der Komplexität hier an dieser Stelle nicht eingegangen werden. Aber die notwendigen Konfigurationen, welche ein Grund- bzw. etwas fortgeschritteneres Wissen über DNS erfordern, werden hier kurz dargestellt.

Die korrekte Antwort auf die Frage nach dem MailExchanger, dem MX-Record des DNS-Servers sollte in etwa wie folgt aussehen und kann mit folgendem Befehl abgefragt werden:

# dig tachtler.net MX

; <<>> DiG 9.3.4-P1 <<>> tachtler.net MX
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38333
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; QUESTION SECTION:
;tachtler.net.                  IN      MX

;; ANSWER SECTION:
tachtler.net.           86400   IN      MX      10 mx1.tachtler.net.

;; AUTHORITY SECTION:
tachtler.net.           86400   IN      NS      ns.tachtler.net.

;; ADDITIONAL SECTION:
mx1.tachtler.net.       86400   IN      A       88.217.171.167
ns.tachtler.net.        86400   IN      A       192.168.0.1

;; Query time: 5 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Tue Nov 25 23:09:25 2008
;; MSG SIZE  rcvd: 99

In dem vorangegangenen Beispiel antwortet ein lokaler, nach außen ins Internet nicht sprechender und nur für das lokale Netzwerk zuständiger DNS-Server.

Auf die Frage des so ermittelten MailExchangers - hier mx1.tachtler.net kann dann auch direkt gefragt werden und zwar mit folgendem Befehl:

dig mx1.tachtler.net

; <<>> DiG 9.3.4-P1 <<>> mx1.tachtler.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5096
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;mx1.tachtler.net.              IN      A

;; ANSWER SECTION:
mx1.tachtler.net.       86400   IN      A       88.217.171.167

;; AUTHORITY SECTION:
tachtler.net.           86400   IN      NS      ns.tachtler.net.

;; ADDITIONAL SECTION:
ns.tachtler.net.        86400   IN      A       192.168.0.1

;; Query time: 5 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Tue Nov 25 23:13:52 2008
;; MSG SIZE  rcvd: 83

WICHTIG - Hier wird deutlich, das auch ein lokaler, nach außen ins Internet nicht sprechender und nur für das lokale Netzwerk zuständige DNS-Server, eine feste IP-Adresse auf die Frage nach dem MailExchanger geben sollte!

Ebenso wichtig wie die Forward-DNS-Auflösung ist die Reverse-DNS-Auflösung, auch für einen lokalen, nach außen ins Internet nicht sprechender und nur für das lokale Netzwerk zuständigen DNS-Server.

Die Antwort auf eine Reverse-DNS-Anfrage über die feste IP-Adresse - hier 88.217.171.167 sollte dann wie folgt lauten und kann mit nachfolgendem Befehl abgefragt werden:

# dig -x 88.217.171.167

; <<>> DiG 9.3.4-P1 <<>> -x 88.217.171.167
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21078
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;167.171.217.88.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
167.171.217.88.in-addr.arpa. 86400 IN   PTR     mx1.tachtler.net.

;; AUTHORITY SECTION:
167.171.217.88.in-addr.arpa. 86400 IN   NS      ns.tachtler.net.

;; ADDITIONAL SECTION:
ns.tachtler.net.        86400   IN      A       192.168.0.1

;; Query time: 5 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Tue Nov 25 23:20:35 2008
;; MSG SIZE  rcvd: 108

Auch hier, antwortet der lokale, nach außen ins Internet nicht sprechender und nur für das lokale Netzwerk zuständige, DNS-Server.

WICHTIG - Was auf keinen Fall passieren sollte ist, folgende Antwort auf eine Reverse-DNS-Anfrage - hier die IP-Adresse 88.217.171.167, welche wieder mit nachfolgendem Befehl durchgeführt werden kann:

# dig -x 88.217.171.167

; <<>> DiG 9.3.4-P1 <<>> -x 88.217.171.167
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21078
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;167.171.217.88.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
167.171.217.88.in-addr.arpa. 86400 IN   PTR     host-88-217-171-167.customer.m-online.net.

;; AUTHORITY SECTION:
167.171.217.88.in-addr.arpa. 86400 IN   NS      ns.tachtler.net.

;; ADDITIONAL SECTION:
ns.tachtler.net.        86400   IN      A       192.168.0.1

;; Query time: 5 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Tue Nov 25 23:20:35 2008
;; MSG SIZE  rcvd: 108

WICHTIG - Bei einer Antwort auf die Reverse-DNS-Anfrage wie oben dargestellt, können verschiedene MailExchanger welche ein sogenanntes Greylisting betreiben - siehe hier Greylisting - den e-Mail Verkehr mit dem MailExchanger ablehnen, da auf die Frage bei einer Reverse-DNS-Anfrage anstelle von

• mx1.tachtler.net

die Antwort:

• host-88-217-171-167.customer.m-online.net

zurückgegeben wird!

Es ist daher auch erforderlich, beim ISP die Reverse-DNS-Auflösung so abzuändern, oder beim Hostmaster abändern zu lassen, dass hier die erwartete Antwort

• mx1.tachtler.net

auch gegeben wird!

Hier ein Beispiel für die Reverse-DNS-Anfrage bei einem ISP, welche mit folgendem Befehl durchgeführt werden kann. (Die Kenntnis einer IP eines DNS-Servers des ISP ist hier erforderlich !!!):

# dig @212.18.0.5 -x 88.217.171.167

; <<>> DiG 9.3.4-P1 <<>> @212.18.0.5 -x 88.217.171.167
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33348
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; QUESTION SECTION:
;167.171.217.88.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
167.171.217.88.in-addr.arpa. 2015 IN    PTR     mx1.tachtler.net.

;; AUTHORITY SECTION:
171.217.88.in-addr.arpa. 54721  IN      NS      ns1.m-online.net.
171.217.88.in-addr.arpa. 54721  IN      NS      ns3.m-online.net.
171.217.88.in-addr.arpa. 54721  IN      NS      ns4.m-online.net.
171.217.88.in-addr.arpa. 54721  IN      NS      ns2.m-online.net.

;; ADDITIONAL SECTION:
ns4.m-online.net.       82683   IN      A       212.114.171.64
ns2.m-online.net.       73879   IN      A       212.18.3.8
ns1.m-online.net.       73775   IN      A       212.18.0.8
ns1.m-online.net.       73334   IN      AAAA    2001:a60:0:11::53
ns3.m-online.net.       79062   IN      A       217.160.128.148

;; Query time: 29 msec
;; SERVER: 212.18.0.5#53(212.18.0.5)
;; WHEN: Tue Nov 25 23:37:43 2008
;; MSG SIZE  rcvd: 264

Nun zurück zur Frage, wie muss ein lokaler, nach außen ins Internet nicht sprechender und nur für das lokale Netzwerk zuständige DNS-Server konfiguriert werden, dass dieser auf die Forward-DNS-Anfrage die richtige Antwort gibt.

Im der Zonen-Datei für die - hier Domäne tachtler.net muss der Eintrag wie folgt aussehen (relevanter Ausschnitt aus der Zonen-Datei):

$TTL    86400
@                                       IN      SOA     ns.tachtler.net.        root.nss.tachtler.net. (
                                                        2008112501      ; serial
                                                        3H              ; refresh
                                                        15M             ; retry
                                                        1W              ; expiry
                                                        1D )            ; minimum

                                        IN      NS      ns.tachtler.net.

                                        IN      MX 10   mx1.tachtler.net.

mx1.tachtler.net.                       IN      A       88.217.171.167

...

Die Frage, wie muss ein lokaler, nach außen ins Internet nicht sprechender und nur für das lokale Netzwerk zuständige DNS-Server konfiguriert werden, dass dieser auf die Reverse-DNS-Anfrage die richtige Antwort gibt, kann wie folgt beantwortet werden.

Es wird eine Zonen-Datei benötigt, welche nur auf die eigene feste IP-Adresse abgestimmt ist, der Dateinamen muss wie folgt gewählt werden:

• 167.171.217.88.in-addr.arpa

Der Inhalt dieser Zonen-Datei sollte dann, wie folgt aussehen (komplette Zonen-Datei):

$TTL    86400
@                                       IN      SOA     ns.tachtler.net.        root.nss.tachtler.net. (
                                                        2008112501      ; serial
                                                        3H              ; refresh
                                                        15M             ; retry
                                                        1W              ; expiry
                                                        1D )            ; minimum

                                        IN      NS      ns.tachtler.net.

                                        IN      PTR     mx1.tachtler.net.

Da hier eine zusätzliche Zonen-Datei für die Reverse-DNS-Auflösung erstellt wurde, muss diese auch noch in der /etc/named.conf eingetragen werden. Ein Eintrag muss dann wie folgt aussehen (relevanter Ausschnitt aus der Zonen-Datei):

...

zone "tachtler.net" IN {
                type master;
                file "tachtler.net";
};


zone "0.168.192.in-addr.arpa" IN {
                type master;
                file "0.168.192.in-addr.arpa";
};

zone "167.171.217.88.in-addr.arpa" IN {
                type master;
                file "167.171.217.88.in-addr.arpa";
};

...

WICHTIG - Dies gilt auch, wenn mit Views gearbeitet wird!

Was bei der Erstellung von neune Zonen-Dateien gerne übersehen wird, gerade dann wenn eine vorhandene Zonen-Datei kopiert wird, ist das setzen der richtigen Datei-Rechte. Dies kann mit folgenden Befehlen wie folgt durchgeführt werden:

# chown root.named 167.171.217.88.in-addr.arpa

und

# chmod 640 167.171.217.88.in-addr.arpa

und sollte dann folgendes Ergebnis liefern, wenn der nachfolgender Befehl eingegeben wird:

# ll /var/named/
total 12
-rw-r----- 1 root named 615 Nov 25 22:44 0.168.192.in-addr.arpa
-rw-r----- 1 root named 237 Nov 25 22:44 167.171.217.88.in-addr.arpa
-rw-r----- 1 root named 679 Nov 25 22:44 tachtler.net

Zum Abschluss ist nun noch ein restart - erneutes Starten des DNS-Servers mit folgendem Befehl notwendig, welcher in etwa nachfolgende Ausgaben in der Log-Datei /var/log/named.log erzeugen sollte:

# service named restart

Ausgabe in der Log-Datei /var/log/named.log:

Nov 25 22:45:05 nss named[3044]: shutting down: flushing changes
Nov 25 22:45:05 nss named[3044]: stopping command channel on 127.0.0.1#953
Nov 25 22:45:05 nss named[3044]: no longer listening on 127.0.0.1#53
Nov 25 22:45:05 nss named[3044]: no longer listening on 192.168.0.1#53
Nov 25 22:45:05 nss named[3044]: exiting
Nov 25 22:45:07 nss named[1205]: starting BIND 9.3.4-P1 -u named -4 -t /var/named/chroot
Nov 25 22:45:07 nss named[1205]: found 1 CPU, using 1 worker thread
Nov 25 22:45:07 nss named[1205]: loading configuration from '/etc/named.conf'
Nov 25 22:45:07 nss named[1205]: no IPv6 interfaces found
Nov 25 22:45:07 nss named[1205]: listening on IPv4 interface lo, 127.0.0.1#53
Nov 25 22:45:07 nss named[1205]: listening on IPv4 interface eth1, 192.168.0.1#53
Nov 25 22:45:07 nss named[1205]: command channel listening on 127.0.0.1#953
Nov 25 22:45:07 nss named[1205]: zone 0.in-addr.arpa/IN/localhost_resolver: loaded serial 42
Nov 25 22:45:07 nss named[1205]: zone 0.0.127.in-addr.arpa/IN/localhost_resolver: loaded serial 1997022700
Nov 25 22:45:07 nss named[1205]: zone 0.168.192.in-addr.arpa/IN/localhost_resolver: loaded serial 2008112501
Nov 25 22:45:07 nss named[1205]: zone 255.in-addr.arpa/IN/localhost_resolver: loaded serial 42
Nov 25 22:45:07 nss named[1205]: zone 167.171.217.88.in-addr.arpa/IN/localhost_resolver: loaded serial 2008112501
Nov 25 22:45:07 nss named[1205]: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN/localhost_resolver: loaded serial 1997022700
Nov 25 22:45:07 nss named[1205]: zone localdomain/IN/localhost_resolver: loaded serial 42
Nov 25 22:45:07 nss named[1205]: zone localhost/IN/localhost_resolver: loaded serial 42
Nov 25 22:45:07 nss named[1205]: zone tachtler.net/IN/localhost_resolver: loaded serial 2008112501
Nov 25 22:45:07 nss named[1205]: zone 0.168.192.in-addr.arpa/IN/tachtler.net: loaded serial 2008112501
Nov 25 22:45:07 nss named[1205]: zone 167.171.217.88.in-addr.arpa/IN/tachtler.net: loaded serial 2008112501
Nov 25 22:45:07 nss named[1205]: zone tachtler.net/IN/tachtler.net: loaded serial 2008112501
Nov 25 22:45:07 nss named[1205]: running

Damit sollte die Konfiguration des DNS-Servers abgeschlossen sein.

Um von außen und nach außen e-Mails empfangen und senden zu können, sind entsprechende Freischaltungen im Paktefilter, hier iptables notwendig. Es müssen eingehende e-Mails und ausgehende e-Mails über den üblichen Port 25 empfangen und zugestellt werden können. Folgende Konfigurationen sind also minimal, für den Server auf dem Postfix läuft notwendig (iptables Version 1.3.5):

Für eingehende e-Mails

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT

Für ausgehende e-Mails

iptables -A OUTPUT -o eth0 -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT

Die eigentliche Konfiguration von Postfix findet in verschiedenen Dateien statt. Folgende Dateien sind hier in dieser beispielhaften Konfiguration von Postfix davon betroffen und werden entweder verändert, oder neu angelegt:

• /etc/postfix/main.cf - Hauptkonfigurationsdatei
• /etc/postfix/master.cf - Konfiguration der Postfix-Module
• /etc/aliases - Aliases Datei, gültig für viele MTA's, nicht nur Postfix
• /etc/postfix/virtual - Aufgeteilt in zwei Dateien
  • /etc/postfix/virtual_alias_domains - Alias Definitionen für Domains ( neu)
  • /etc/postfix/virtual_alias_maps - Alias Definitionen für e-Mail-Adressen ( neu)
• /etc/postfix/canonical - Aufgeteilt in zwei Dateien
  • /etc/postfix/sender_canonical_maps - Umschreiben (SMTP-Envelop, e-Mail-Header) Absenderadresse ( neu)
  • /etc/postfix/recipient_canonical_maps - Umschreibung (SMTP-Envelop, e-Mail-Header) Empfängeradresse ( neu)
• /etc/postfix/generic - Aufgeteilt in zwei Dateien
  • /etc/postfix/smtp_generic_maps - Umschreiben (SMTP-Envelop, e-Mail-Header) bei durch SMTP das System verlassende e-Mails ( neu)
  • /etc/postfix/lmtp_generic_maps - Umschreiben (SMTP-Envelop, e-Mail-Header) bei durch LMTP das System verlassende e-Mails ( neu)
• /etc/postfix/transport - Datei umbenannt in
  • /etc/postfix/transport_maps - Abweichende Zustellung der e-Mail über alternatives Mailrouting ( neu)
• /etc/postfix/relocated - Datei umbenannt in
  • /etc/postfix/relocated_maps - Empfänger verzogen Rückmeldungen bei geänderten e-Mail-Empfängern ( neu)
• /etc/postfix/header_checks - e-Mail-Header (Kopfinformationen) Filtern ( neu)
• /etc/postfix/body_checks - e-Mail-Body (Inhaltinformationen) Filtern ( neu)
• /etc/postfix/bounce.de-DE.cf - Template-Datei für deutsch/english-Texte beim bounce (Rückgabe) einer e-Mail ( neu)

Die Hauptkonfigurationsdatei von Postfix.

Dies sind die Parameter, welche schon von der Linux Distribution CentOS abgeändert wurden, welche mit nachfolgendem Befehl aufgelistet werden können:

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
unknown_local_recipient_reject_code = 550

* postconf -n listet die Einstellungen in der main.cf auf, welche nicht dem Standard entsprechen.

Dies sind die Parameter, welche zusätzlich zu den Parameter, welche schon von der Linux Distribution CentOS abgeändert wurden, noch verändert werden sollten, um einen Postfix zu betreiben, der den eigenen Wünschen, in diesem Fall meinen, entspricht:

* Nicht in Gebrauch, wenn smtpd_discard_ehlo_keyword_address_maps eingesetzt wird!

Dies sind die Parameter, welche nach einer Anpassungen als BEISPIEL dienen können und mit folgendem Befehl aufgelistet werden können:

# postconf -n
address_verify_map = btree:/var/spool/postfix/data/verify
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
body_checks = pcre:/etc/postfix/body_checks
bounce_queue_lifetime = 1d
bounce_template_file = /etc/postfix/bounce.de-DE.cf
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
header_checks = pcre:/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
lmtp_generic_maps = btree:/etc/postfix/lmtp_generic_maps
mail_owner = postfix
mailbox_transport = cyrus
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
masquerade_domains = tachtler.net
maximal_queue_lifetime = 1d
message_size_limit = 20480000
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, $myorigin
myhostname = mx1.tachtler.net
mynetworks = 127.0.0.0/8, 192.168.0.0/28, 88.217.171.167/32
myorigin = nss.tachtler.net
newaliases_path = /usr/bin/newaliases.postfix
parent_domain_matches_subdomains = 
                                 debug_peer_list,     
                                 fast_flush_domains,     
                                 mynetworks,     
                                 permit_mx_backup_networks,      
                                 qmqpd_authorized_clients,
                                 relay_domains
permit_mx_backup_networks = 88.217.187.21/32
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
recipient_canonical_maps = btree:/etc/postfix/recipient_canonical_maps
relay_domains = 
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sender_canonical_maps = btree:/etc/postfix/sender_canonical_maps
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtp_generic_maps = btree:/etc/postfix/smtp_generic_maps
smtp_tls_loglevel = 1
smtp_use_tls = yes
smtpd_client_connection_count_limit = 20
smtpd_client_recipient_rate_limit = 20
smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_access
smtpd_helo_required = yes
smtpd_recipient_restrictions = 
                             check_recipient_access btree:/etc/postfix/check_recipient_access_rfc,    
                             check_client_access cidr:/etc/postfix/check_client_access,      
                             check_helo_access btree:/etc/postfix/check_helo_access,     
                             check_sender_access btree:/etc/postfix/check_sender_access,     
                             check_recipient_access btree:/etc/postfix/check_recipient_access,  
                             reject_non_fqdn_sender,  
                             reject_non_fqdn_recipient,      
                             reject_unknown_sender_domain,   
                             reject_unknown_recipient_domain,        
                             permit_sasl_authenticated,      
                             permit_mynetworks, 
                             reject_rbl_client zen.spamhaus.org,      
                             reject_rbl_client ix.dnsbl.manitu.net,  
                             reject_rbl_client bl.spamcop.net,       
                             reject_rbl_client dnsbl.njabl.org,      
                             reject_rhsbl_client multi.uribl.com,        
                             check_client_access btree:/etc/postfix/check_client_access_policyd_weight,      
                             check_policy_service inet:127.0.0.1:12525,      
                             check_policy_service unix:postgrey/socket,  
                             reject_unverified_recipient,    
                             permit_mx_backup,       
                             reject_unauth_destination,      
                             permit
smtpd_tls_CAfile = /etc/pki/postfix/certs/CAcert.pem
smtpd_tls_cert_file = /etc/pki/postfix/certs/cert.pem
smtpd_tls_key_file = /etc/pki/postfix/private/key.pem
smtpd_tls_received_header = yes
smtpd_use_tls = yes
transport_maps = btree:/etc/postfix/transport_maps
unknown_address_reject_code = 550
unknown_client_reject_code = 550
unknown_hostname_reject_code = 550
unknown_local_recipient_reject_code = 550
unknown_relay_recipient_reject_code = 550
unknown_virtual_alias_reject_code = 550
unknown_virtual_mailbox_reject_code = 550
unverified_recipient_reject_code = 577
unverified_sender_reject_code = 577
virtual_alias_domains = btree:/etc/postfix/virtual_alias_domains
virtual_alias_maps = btree:/etc/postfix/virtual_alias_maps

Folgende Änderungen gegenüber der Standard-Konfigurationsdatei /etc/postfix/master.cf wurden durchgeführt:

• # Tachtler
  # AMaViS - Incoming and forward to AMaViS listen on Port 10024
  smtp      inet  n       -       n       -       -       smtpd
          -o smtpd_proxy_filter=127.0.0.1:10024
          -o content_filter=

Diese Änderung bewirkt, dass Postfix alle eingehenden e-Mails an AMaViS zur weiteren Prüfung, noch innerhalb des SMTP-Envelop-Dialogs weiterreicht.

Dabei ist zu beachten, das AMaViS auf 127.0.0.1, Port 10024 lauscht!

• # Tachtler
  # AMaViS - Outgoing from AMaViS, BACK to Postfix 
  127.0.0.1:10025 inet  n       -       n       -       -       smtpd
          -o content_filter=
          -o smtpd_proxy_filter=
          -o smtpd_authorized_xforward_hosts=127.0.0.0/8
          -o smtpd_client_restrictions=
          -o smtpd_helo_restrictions=
          -o smtpd_sender_restrictions=
          -o smtpd_recipient_restrictions=permit_mynetworks,reject
          -o smtpd_data_restrictions=
          -o mynetworks=0.0.0.0/32,127.0.0.0/8,192.168.0.0/24
          -o recesive_override_options=no_unknown_recipient_checks

Diese Änderung bewirkt, dass alle geprüften e-Mails von AMaViS zur Zustellung/Ablehnung an Postfix zurückgegeben werden.

Dabei ist zu beachten, dass um einen loop zu verhindern, hier auf einem anderen Port als dem Standard e-Mail Port von Postfix - nämlich Port 25 - sondern auf Port 10025 die geprüften e-Mails wieder an Postfix zurückgegeben werden. Dies geschieht ebenfalls alles über localhost

• # Tachtler
  # AMaViS - Incoming and forward to AMaViS listen on Port 10024
  pickup    fifo  n       -       n       60      1       pickup
          -o content_filter=smtp:[127.0.0.1]:10024

Diese Änderung bewirkt, dass Postfix alle eingehenden e-Mails an AMaViS zur weiteren Prüfung, noch innerhalb des SMTP-Envelop-Dialogs weiterreicht - auch, wenn diese lokal über pickup eingeliefert werden!

Die relevanten Änderungen gegenüber der Standard-Konfiguration, sind mit folgendem Kommentar

# Tachtler

versehen.

Hier die komplette Konfigurationsdatei, welche unter /etc/postfix zu finden ist und den Namen master.conf trägt:

#
# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
# Tachtler
# AMaViS - Incoming and forward to AMaViS listen on Port 10024
smtp      inet  n       -       n       -       -       smtpd
        -o smtpd_proxy_filter=127.0.0.1:10024
        -o content_filter=
# Tachtler
# AMaViS - Outgoing from AMaViS, BACK to Postfix 
127.0.0.1:10025 inet  n       -       n       -       -       smtpd
        -o content_filter=
        -o smtpd_proxy_filter=
        -o smtpd_authorized_xforward_hosts=127.0.0.0/8
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o smtpd_data_restrictions=
        -o mynetworks=0.0.0.0/32,127.0.0.0/8,192.168.0.0/24
        -o recesive_override_options=no_unknown_recipient_checks
#submission inet n       -       n       -       -       smtpd
#  -o smtpd_enforce_tls=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#smtps     inet  n       -       n       -       -       smtpd
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#628      inet  n       -       n       -       -       qmqpd
# Tachtler
# AMaViS - Incoming and forward to AMaViS listen on Port 10024
pickup    fifo  n       -       n       60      1       pickup
        -o content_filter=smtp:[127.0.0.1]:10024
cleanup   unix  n       -       n       -       0       cleanup
qmgr      fifo  n       -       n       300     1       qmgr
#qmgr     fifo  n       -       n       300     1       oqmgr
tlsmgr    unix  -       -       n       1000?   1       tlsmgr
rewrite   unix  -       -       n       -       -       trivial-rewrite
bounce    unix  -       -       n       -       0       bounce
defer     unix  -       -       n       -       0       bounce
trace     unix  -       -       n       -       0       bounce
verify    unix  -       -       n       -       1       verify
flush     unix  n       -       n       1000?   0       flush
proxymap  unix  -       -       n       -       -       proxymap
smtp      unix  -       -       n       -       -       smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay     unix  -       -       n       -       -       smtp
        -o fallback_relay=
#       -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq     unix  n       -       n       -       -       showq
error     unix  -       -       n       -       -       error
discard   unix  -       -       n       -       -       discard
local     unix  -       n       n       -       -       local
virtual   unix  -       n       n       -       -       virtual
lmtp      unix  -       -       n       -       -       lmtp
anvil     unix  -       -       n       -       1       anvil
scache    unix  -       -       n       -       1       scache
#
# ====================================================================
# Interfaces to non-Postfix software. Be sure to examine the manual
# pages of the non-Postfix software to find out what options it wants.
#
# Many of the following services use the Postfix pipe(8) delivery
# agent.  See the pipe(8) man page for information about ${recipient}
# and other message envelope options.
# ====================================================================
#
# maildrop. See the Postfix MAILDROP_README file for details.
# Also specify in main.cf: maildrop_destination_recipient_limit=1
#
maildrop  unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
#
# The Cyrus deliver program has changed incompatibly, multiple times.
#
old-cyrus unix  -       n       n       -       -       pipe
  flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user}
# Cyrus 2.1.5 (Amos Gouaux)
# Also specify in main.cf: cyrus_destination_recipient_limit=1
cyrus     unix  -       n       n       -       -       pipe
  user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}
#
# See the Postfix UUCP_README file for configuration details.
#
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
#
# Other external delivery methods.
#
ifmail    unix  -       n       n       -       -       pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp     unix  -       n       n       -       -       pipe
  flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient

Die Aliases-Datei /etc/aliases ist für viele MTA's gültig, nicht nur für Postfix. Aus historischen Gründen ist diese Konfigurationsdatei nicht unter /etc/postfix sondern unter /etc zu finden.

Hier wird als Beispiel ein Benutzer, welchen es so im System als „richtigen“ Benutzer gar nicht gibt, mit dem Namen rsyslog zusätzlich zu den bereits vordefinierten „Aliasen“ der Konfigurationsdatei /etc/aliases hinzugefügt. Alle e-Mails welche an diesen Benutzer z.B. lokal verschickt werden, sollen in das Postfach des Benutzers root zugestellt werden.

Die relevanten Änderungen gegenüber der Standard-Konfiguration, sind mit folgendem Kommentar

# Tachtler

versehen.

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

# Tachtler
# rsyslog group mail settings
rsyslog:        root

Wie in der Konfigurationsdatei /etc/aliases schon zu lesen ist,

#       >>>>>>>>>>      The program "newaliases" must be run after
#       >> NOTE >>      this file is updated for any changes to
#       >>>>>>>>>>      show through to sendmail.

müssen Änderungen an dieser Datei erst noch in ein hash-Format, mithilfe des Programms newaliases umgewandelt werden!

Dies gilt nicht nur, wie zu lesen ist, für den MTA Sendmail, sondern auch für den MTA Postfix!

Jedoch gibt es für Postfix zwei Möglichkeiten die Aliases-Datei /etc/aliases in ein hash-Format umzuwandeln.

Die erste Möglichkeit ist, weiterhin den Befehl

• newaliases (den Sendmail Umsteigern bekannt)

zu verwenden, oder die zweite Möglichkeit

• postalias

einzusetzen!

Ein Aufruf zur Umwandlung der Konfigurationsdatei /etc/aliases in das hash-Format, könnte wie folgt aussehen:

# postalias /etc/aliases

Ein Überprüfung, ob der Befehl erfolgreich war, kann anhand des Datums der Datei /etc/aliases.db mit folgendem Befehl nachvollzogen werden (Umwandlung war in diesem Beispiel der 2. Dezember):

# ll /etc/aliases*
-rw-r--r-- 1 root root   1568 Dec  2 16:22 /etc/aliases
-rw-r----- 1 root smmsp 12288 Dec  2 16:24 /etc/aliases.db

Es bietet sich an, e-Mail-Weiterleitungen in /etc/aliases für technische Benutzer einzusetzen!

Die Konfigurationsdatei /etc/postfix/virtual_alias_domains verwaltet Domain-Definitionen die als Alias für die Annahme von e-Mail für bestimmte Domains stehen.

Hier wird als Beispiel die Annahme von e-Mails für eine Subdomain, hier dokuwiki.tachtler.net beschrieben.

Dafür ist die Konfigurationsdatei /etc/postfix/virtual_alias_domains mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/virtual_alias_domains

Danach sollte der Inhalt wie folgt aussehen:

dokuwiki.tachtler.net        irgendetwas

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss muss auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/virtual_alias_domains

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/virtual_alias_domains.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/virtual_alias_domains*
-rw-r--r-- 1 root root  531 Dec  3 09:11 /etc/postfix/virtual_alias_domains
-rw-r--r-- 1 root root 8192 Dec  3 09:14 /etc/postfix/virtual_alias_domains.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

Die Konfigurationsdatei /etc/postfix/virtual_alias_maps verwaltet Alias-Definitionen, ähnlich wie die Konfigurationsdatei /etc/aliases. Auch hier wird die Annahme von e-Mail für bestimmte Empfänger realisiert.

WICHTIG - Jedoch sollten hier nur Domains stehen bzw. mit Aliasen versehen werden, welche NICHT in $mydomain, $myorigin, $myhostname, localhost.$mydomain, localhost Verwendung finden!

Hier wird als Beispiel die Annahme von e-Mails für eine e-Mail-Adresse, hier @dokuwiki.tachtler.net beschrieben. Wobei es völlig egal ist, welcher Empfänger vor dem „@“-Zeichen steht, dieser wird übernommen. Z.B aus postmaster@dokuwiki.tachtler.net wird postmaster@tachtler.net.

Dafür ist die Konfigurationsdatei /etc/postfix/virtual_alias_maps mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/virtual_alias_maps

Danach sollte der Inhalt wie folgt aussehen:

@dokuwiki.tachtler.net        @tachtler.net

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss muss auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/virtual_alias_maps

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/virtual_alias_maps.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/virtual_alias_maps*
-rw-r--r-- 1 root root   40 Dec  3 09:12 /etc/postfix/virtual_alias_maps
-rw-r--r-- 1 root root 8192 Dec  3 09:14 /etc/postfix/virtual_alias_maps.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

Es bietet sich an, e-Mail-Weiterleitungen in /etc/postfix/virtual_alias_maps für virtuelle Benutzer oder allgemeine Adressen einzusetzen!

ACHTUNG - Ab Postfix Version 2.2 wird canonical als Standard NUR für lokale erzeugte e-Mails genutzt !!!
* Für eine erweiterte Nutzung ist ein neuer Parameter local_header_rewrite_clients entsprechend anzupassen !

Die Konfigurationsdatei /etc/postfix/sender_canonical_maps ist ebenfalls in der Lage e-Mail-Adressen durch andere zu ersetzen. Aber nicht nur das, canonical geht weiter und schreibt Absenderadressen nicht nur im SMTP-Envelop, sondern auch im e-Mail-Header um.

Das ist einer der wenigen Ausnahmen, in denen der MTA Postfix den e-Mail-Header verändert!

Hier wird als Beispiel das Absenden von e-Mails mit einer e-Mail-Adresse, hier @dokuwiki.tachtler.net beschrieben. Wobei es völlig egal ist, welcher Empfänger vor dem „@“-Zeichen steht, dieser wird übernommen. Z.B aus postmaster@dokuwiki.tachtler.net wird postmaster@tachtler.net.

Dafür ist die Konfigurationsdatei /etc/postfix/sender_canonical_maps mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/sender_canonical_maps

Danach sollte der Inhalt wie folgt aussehen:

@dokuwiki.tachtler.net        @tachtler.net

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss muss auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/sender_canonical_maps

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/sender_canonical_maps.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/sender_canonical_maps*
-rw-r--r-- 1 root root  644 Dec  4 13:12 /etc/postfix/sender_canonical_maps
-rw-r--r-- 1 root root 8192 Dec  4 13:28 /etc/postfix/sender_canonical_maps.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

ACHTUNG - Ab Postfix Version 2.2 wird canonical als Standard NUR für lokale erzeugte e-Mails genutzt !!!
* Für eine erweiterte Nutzung ist ein neuer Parameter local_header_rewrite_clients entsprechend anzupassen !

Die Konfigurationsdatei /etc/postfix/recipient_canonical_maps ist ebenfalls in der Lage e-Mail-Adressen durch andere zu ersetzen. Aber nicht nur das, canonical geht weiter und schreibt Empfängeradressen nicht nur im SMTP-Envelop, sondern auch im e-Mail-Header um.

WICHTIG ist, dass die Empfänger e-Mail-Adresse nicht nur in /etc/postfix/recipient_canonical_maps eingetragen ist, sondern auch in /etc/postfix/virtual_alias_maps, da sonst die Annahme für z.B. admin@dokuwiki.tachtler.net verweigert werden würde!

Das ist einer der wenigen Ausnahmen, in denen der MTA Postfix den e-Mail-Header verändert!

Hier wird als Beispiel der Empfang von e-Mails mit einer e-Mail-Adresse, hier admin@dokuwiki.tachtler.net beschrieben. Hier wird aus admin@dokuwiki.tachtler.net die e-Mail-Adresse root@tachtler.net.

Dafür ist die Konfigurationsdatei /etc/postfix/recipient_canonical_maps mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/recipient_canonical_maps

Danach sollte der Inhalt wie folgt aussehen:

admin@dokuwiki.tachtler.net        root@tachtler.net

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss muss auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/recipient_canonical_maps

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/recipient_canonical_maps.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/recipient_canonical_maps*
-rw-r--r-- 1 root root  701 Dec  5 11:51 /etc/postfix/recipient_canonical_maps
-rw-r--r-- 1 root root 8192 Dec  5 12:03 /etc/postfix/recipient_canonical_maps.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

Die Konfigurationsdatei /etc/postfix/smtp_generic_maps ist ebenfalls in der Lage e-Mail-Adressen durch andere zu ersetzen. Aber nicht nur das, smtp_generic_maps geht weiter und schreibt Absenderadressen nicht nur im SMTP-Envelop, sondern auch im e-Mail-Header um, wie der „große Bruder“ canonical, jedoch erst dann, wenn diese per SMTP das System verlassen!

Das ist auch einer der wenigen Ausnahmen, in denen der MTA Postfix den e-Mail-Header verändert!

Hier wird als Beispiel das Absenden von e-Mails mit einer e-Mail-Adresse, hier rsyslog@nss.tachtler.net beschrieben. Hier wird aus rsyslog@nss.tachtler.net die e-Mail-Adresse rsyslog@tachtler.net.

Dafür ist die Konfigurationsdatei /etc/postfix/smtp_generic_maps mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/smtp_generic_maps

Danach sollte der Inhalt wie folgt aussehen:

rsyslog@nss.tachtler.net        rsyslog@tachtler.net

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss muss auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/smtp_generic_maps

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/smtp_generic_maps.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/smtp_generic_maps*
-rw-r--r-- 1 root root   47 Dec  5 13:03 /etc/postfix/smtp_generic_maps
-rw-r--r-- 1 root root 8192 Dec  5 13:38 /etc/postfix/smtp_generic_maps.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

Die Konfigurationsdatei /etc/postfix/lmtp_generic_maps ist ebenfalls in der Lage e-Mail-Adressen durch andere zu ersetzen. Aber nicht nur das, lmtp_generic_maps geht weiter und schreibt Absenderadressen nicht nur im SMTP-Envelop, sondern auch im e-Mail-Header um, wie der „große Bruder“ canonical, jedoch erst dann, wenn diese per LMTP das System verlassen!

Das ist auch einer der wenigen Ausnahmen, in denen der MTA Postfix den e-Mail-Header verändert!

Hier wird als Beispiel das Absenden von e-Mails mit einer e-Mail-Adresse, hier rsyslog@nss.tachtler.net beschrieben. Hier wird aus rsyslog@nss.tachtler.net die e-Mail-Adresse rsyslog@tachtler.net.

Dafür ist die Konfigurationsdatei /etc/postfix/lmtp_generic_maps mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/lmtp_generic_maps

Danach sollte der Inhalt wie folgt aussehen:

rsyslog@nss.tachtler.net        rsyslog@tachtler.net

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss muss auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/lmtp_generic_maps

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/lmtp_generic_maps.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/lmtp_generic_maps*
-rw-r--r-- 1 root root   47 Dec  5 13:36 /etc/postfix/lmtp_generic_maps
-rw-r--r-- 1 root root 8192 Dec  5 13:38 /etc/postfix/lmtp_generic_maps.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

WICHTIG - Die Konfiguratiosndatei /etc/postfix/transport_maps wird hier NUR theoretisch dargestellt!

Dei Konfigurationsdatei /etc/postfix/transport_maps dient dazu, ein vom Standard abweichendes Mailrouting zu realisieren. Relevant ist dies z.B. dann, wenn Postfix als Relay-Host, vor einem anderen e-Mail-Server zum Einsatz kommt und dafür ein besonderes Routing erforderlich ist.

Die Erstellung und die Umwandlung von einer Text-Datei in das hash-Format oder sogar das btree-Format ist identisch mit allen anderen Konfigurationsdateien, die mit dem Postfix eigenen Programm postmap umgewandelt werden!

WICHTIG - Die Konfiguratiosndatei /etc/postfix/relocated_maps wird hier NUR theoretisch dargestellt!

Dei Konfigurationsdatei /etc/postfix/relocated_maps dient dazu, falls eine e-Mail mit einem dem eigenen Postfix nicht bekannten Empfänger z.B. verzogen@tachtler.net eingeliefert wird, NICHT wie es in diesem Fall üblich wäre, eine e-Mail mit der Fehlermeldung 554 oder einer Bounce-Mail zu quittieren,

...
<verzogen@tachtler.net>: unknown user: "verzogen"

sondern, wenn die e-Mail-Adresse sich lediglich geändert hat, dem Absender die neue e-Mail-Adresse mitzuteilen!

...
<verzogen@tachtler.net>: user has moved to neueadresse@tachtler.net

Heutzutage ist die Konfigurationsdatei /etc/postfix/relocated_maps nahezu bedeutungslos, da

1. die wenigsten Nutzer die Bounce-Antwort verstehen, oder gar lesen
2. da es für die meisten Administratoren ein leichtes ist, die e-Mails einfach über einen Eintrag in der Konfigurationsdatei /etc/postfix/virtual_alias_maps weiterzuleiten!

Auf den Einsatz kann verzichtet werden!

Die hier in dieser Konfigurationsdatei durchgeführte Filterung, bezieht sich auf die Informationen im e-Mail-Header, wie z.B. „From“, „Subject“ usw.

Ein Beispiel für eine solche Konfigurationsdatei könnte wie folgt aussehen. Hier wird als erstes alles nicht gefiltert, was von localhost kommt, aber es wird alles gefiltert, was von spam.com kommt. Darüberhinaus kann jedes Feld des e-Mail-Headers gefiltert werden.

/^Received: from localhost/            IGNORE

/^Received:.*spam\.com                 REJECT Header-Spamschutzregel RECD-1000

# Weitere Beispiele

if /^From:/i
/^From:.*spam.org/                     REJECT Header-Spamschutzregel FROM-1001
Endif

if /^To:/i
/^To:.*spam.net/                       REJECT Header-Spamschutzregel TOTO-1002
Endif

if /^Subject:/i
/^Subject:.*Gratisaktion.*/            REJECT Header-Spamschutzregel SUBJ-1003
Endif

# Spezielles Beispiel
/^(To|From|Cc|Reply-To):.*@spam.gov/   REJECT Header-Spamschutzregel MULT-1004

WICHTIG - Ein Aufruf für die Umwandlung der Konfigurationsdatei /etc/postfix/header_checks in das regexp-Format oder noch besser in das Format pcre von postmap, ist NICHT erforderlich. Es wird bei regexp oder pcre die ACSII-Datei als solches von Postfix interpretiert!

WICHTIG - Bei Änderungen ist ein reload von Postfix notwendig!

Die hier in dieser Konfigurationsdatei durchgeführte Filterung, bezieht sich auf die Informationen im e-Mail-Body.

Ein Beispiel für eine solche Konfigurationsdatei könnte wie folgt aussehen. Hier wird im Text der e-Mail nach dem Vorkommen von „spam.org“, „spam.net“, oder „spam.com“ gesucht!

/.*spam\.(org|net|com)/                REJECT Body-Spamschutzregel TEXT-1000

WICHTIG - Ein Aufruf für die Umwandlung der Konfigurationsdatei /etc/postfix/body_checks in das regexp-Format oder noch besser in das Format pcre von postmap, ist NICHT erforderlich. Es wird bei regexp oder pcre die ACSII-Datei als solches von Postfix interpretiert!

WICHTIG - Bei Änderungen ist ein reload von Postfix notwendig!

Dies ist eine Template-Datei (Vorlagen-Datei) für deutsch/english-Sprachige Texte beim bounce (Rückgabe) einer e-Mail.

Diese Template-Datei kann unter folgendem Link heruntergeladen werden:

• Postfix Howtos, Guides and Tipps by Ralf Hildebrandt and Patrick Koetter

und hat folgenden Inhalt:

# $Id: bounce.de-DE.cf 15 2005-12-27 18:33:49Z patrick $
#
# Deutsch-sprachige Vorlagen fuer Postfix Zustell-Status-Benachrichtigungen
# (engl. DSN, Delivery Status Notification)
#
# Uebersetzt und an die deutsche Sprache angepasst von Patrick Koetter
# <p@state-of-mind.de> und Ralf Hildebrandt <ralf.hildebrandt@charite.de>.
#
# Folgen Sie den Anweisungen der bounce(5) manual page, um die in dieser Datei
# enthaltenen Zustell-Status-Benachrichtigungen in Ihren Postfix-Server
# einzubinden.


# failure_template
# Das failure_template kommt zum Einsatz, wenn der empfangende Mail-Server die
# Nachricht entweder zurueckgewiesen hat oder wenn die Nachricht nicht
# innerhalb eines vorgegebenen Zeitraums ($maximal_queue_lifetime) zugestellt
# werden konnte.
#
# In beiden Faellen wird der Inhalt von failure_template zusammen mit der
# urspruenglich gesendeten Nachricht und dem Fehler, der die Benachrichtigung
# hervorgerufen hat an den Absender der E-Mail gesendet.

failure_template = <<EOF
Charset: iso-8859-1
From: MAILER-DAEMON (Mail Delivery System)
Subject: Rueckgabe nicht zustellbarer Nachricht an Absender
Postmaster-Subject: Postmaster Copy: Undelivered Mail

Dies ist eine automatisch generierte Nachricht des $mail_name E-Mail-Dienstes.
Dieser Dienst wird auf dem Server $myhostname betrieben und teilt Ihnen
folgendes mit:


    Ihre Nachricht konnte an einen oder mehrere Empfaenger nicht zugestellt
    werden. Ein Problem-Bericht, sowie Ihre uspruengliche Nachricht wurden an
    das Ende dieser Nachricht angehaengt.


Fuer weitere Hilfe kontaktieren Sie bitte den fuer Sie zustaendigen
<postmaster>.

Senden Sie dazu den an diese E-Mail angefuegten Problem-Bericht mit.
Den Inhalt Ihrer urspruenglichen Nachricht koennen Sie - zum Schutz Ihrer
Privatsphaere - entfernen; er ist fuer eine Fehler-Diagnose nicht zwingend
notwendig.

                   Der $mail_name E-Mail-Dienst

                        INTERNATIONAL VERSION

This is the $mail_name program at host $myhostname.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

EOF


# delay_template
# Das delay_template kommt zum Einsatz, wenn sich die Zustellung einer
# Nachricht verzoegert - die Zustellung wird so lange versucht, bis der Postfix
# Server sie wegen Ueberschreitung der $maximal_queue_lifetime abbrechen muss.
#
# Anmerkung:
# Die Standardvorgaben in Postfix sehen vor, dass Zustell-Verzoegerungen in
# Stunden ($delay_warning_time_hours) und die maximale Lebenszeit einer
# Nachricht in der Postfix Zustell-Warteschlange in Tagen
# ($maximal_queue_lifetime_days) angegeben werden.
#
# Alternativ koennen Sie anstatt der genannten Zeiteinheiten auch Sekunden,
# Minuten oder Wochen angeben, indem Sie die aktuelle Zeiteinheit des
# Parameters durch _seconds, _minutes oder _weeks austauschen und den
# begleitenden Text in der Vorlage anpassen.

delay_template = <<EOF
Charset: iso-8859-1
From: MAILER-DAEMON (Mail Delivery System)
Subject: Nachricht wurde verzoegert (Zustellung wird weiter versucht)
Postmaster-Subject: Postmaster Warning: Delayed Mail

Dies ist eine automatisch generierte Nachricht des $mail_name E-Mail-Dienstes.
Dieser Dienst wird auf dem Server $myhostname betrieben und teilt Ihnen
folgendes mit:


    Eine von Ihnen gesendete Nachricht konnte seit $delay_warning_time_hours
    Stunden nicht zugestellt werden.
    
    Sie muessen die Nachricht nicht noch einmal senden. Der $mail_name
    E-Mail-Dienst wird so lange versuchen Ihre Nachricht zuzustellen,
    bis sie $maximal_queue_lifetime_days Tage alt ist.

    Sollte eine Zustellung bis in $maximal_queue_lifetime_days Tagen nicht
    gelingen, wird der $mail_name E-Mail-Dienst die Zustellung abbrechen und
    Sie davon in Kenntnis setzen.


Fuer weitere Hilfe kontaktieren Sie bitte den fuer Sie zustaendigen
<postmaster>.

Senden Sie dazu den, in dieser E-Mail angefuegten, Problem-Bericht mit.
Den Inhalt Ihrer urspruenglichen Nachricht koennen Sie, zum Schutz Ihrer
Privatsphaere, entfernen; er ist fuer eine Fehler-Diagnose nicht zwingend
notwendig.

                   Der $mail_name E-Mail-Dienst


                        INTERNATIONAL VERSION

This is the $mail_name program at host $myhostname.

####################################################################
# THIS IS A WARNING ONLY.  YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
####################################################################

Your message could not be delivered for $delay_warning_time_hours hour(s).
It will be retried until it is $maximal_queue_lifetime_days day(s) old.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The $mail_name program
EOF


# success_template
# Das success_template kommt zum Einsatz, wenn eine Nachricht an ein Postfach
# zugestellt wurde, wenn ein Alias-Name oder eine Liste von Empfaengern in ihre
# Zieladressen aufgeloest wurde oder wenn eine Nachricht an ein System
# zugestellt wurde, das im Dialog mit Ihrem Postfix-Server keine
# DSN-Faehigkeiten erkennen lies.
#
# Achtung:
# Sie duerfen fuer diese Art von Zustell-Status-Benachrichtigung kein
# Postmaster-Subject: angeben.

success_template = <<EOF
Charset: iso-8859-1
From: MAILER-DAEMON (Mail Delivery System)
Subject: Bericht ueber erfolgreiche Zustellung

Dies ist eine automatisch generierte Nachricht des $mail_name E-Mail-Dienstes.
Dieser Dienst wird auf dem Server $myhostname betrieben und teilt Ihnen
folgendes mit:


    Ihre Nachricht wurde erfolgreich an die E-Mail-Server der am Ende dieser
    E-Mail aufgelisteten Empfaenger ausgeliefert.

    Falls Sie eine Zustellbericht angefordet haben und der empfangende
    E-Mail-Server diese Funktionalitaet unterstuetzt erhalten Sie
    auch von diesem E-Mail-Server eine entsprechende Benachrichtigung.


                   Der $mail_name E-Mail-Dienst


                        INTERNATIONAL VERSION

This is the $mail_name program at host $myhostname.

Your message was successfully delivered to the destination(s)
listed below. If the message was delivered to mailbox you will
receive no further notifications. Otherwise you may still receive
notifications of mail delivery errors from other systems.

                   The $mail_name program
EOF


# verify_template
# Das verify_template kommt zum Einsatz, wenn Adress-Ueberpruefung (sendmail
# -bv adresse...) oder ausfuehrliche Protokollierung (sendmail -v adresse...)
# angefordert wurde.
#
# Achtung:
# Sie duerfen fuer diese Art von Zustell-Status-Benachrichtigung kein
# Postmaster-Subject: angeben.

verify_template = <<EOF
Charset: iso-8859-1
From: MAILER-DAEMON (Mail Delivery System)
Subject: Zustellbericht (Mail Delivery Status Report)

Dies ist eine automatisch generierte Nachricht des $mail_name E-Mail-Dienstes.
Dieser Dienst wird auf dem Server $myhostname betrieben und teilt Ihnen
folgendes mit:


    Sie haben einen Empfaenger-Adressen-Bericht angefordert. Der Bericht wurde
    an diese Nachricht angehaengt.


                   Der $mail_name E-Mail-Dienst


                        INTERNATIONAL VERSION

This is the $mail_name program at host $myhostname.

Enclosed is the mail delivery report that you requested.

                   The $mail_name program
EOF

Die „Restriktionen“ sind sozusagen die Schaltzentrale des Postfix.

Um zu verhindern, dass der MTA Postfix nicht jede an ihn gerichtete e-Mail annimmt und z.B. SPAM erfolgreich ablehnen kann, ist es erforderlich ein Regelwerk zu definieren, mit Hilfe dessen festgelegt werden kann, wann der MTA Postfix e-Mails annehmen, oder ablehnen soll.

Diese Festlegungen erfolgt mit Hilfe der Restrictions.

Der entscheidende Moment, an dem Postfix SPAM und auch andere unerwünschten e-Mails zurückweisen kann bzw. erst gar nicht annimmt, ist der Einlieferungszeitpunkt!

Was Postfix nicht annimmt, braucht auch nicht weiterverarbeitet zu werden! Analog dem Briefverkehr wird festgelegt, welche e-Mails überhaupt in die Briefkästen geworfen werden können und dürfen und welche nicht!

Folgende Restrictions sind in Postfix möglich:

• smtpd_client_restrictions - Prüfungen, welche beim „connect“ (Verbinden) durchgeführt werden
• smtpd_helo_restrictions - Prüfungen, welche nach dem „HELO/EHLO“ durchgeführt werden
• smtpd_sender_restrictions - Prüfungen, welche nach der Bekanntgabe von „MAIL FROM:“ durchgeführt werden
• smtpd_recipient_restrictions - Prüfungen, welche nach dem „RCPT TO:“, durchgeführt werden - Zusätzliche aufgeteilt in fünf Dateien und welche weitere Konfigurations-Angaben beinhaltet!
  • /etc/postfix/check_recipient_access_rfc - RFC-Konforme Prüfungen von Empfängeradressen (z.B. postmaster, abuse usw.) ( neu)
  • /etc/postfix/check_client_access - White- und Blacklisting für Client-IP-Adressen ( neu)
  • /etc/postfix/check_helo_access - White- und Blacklisting für HELO/EHLO-Server ( neu)
  • /etc/postfix/check_sender_access - White- und Blacklisting für Absenderadressen ( neu)
  • /etc/postfix/check_recipient_access - White- und Blacklisting für Empfängeradressen ( neu)
• smtpd_data_restrictions - Prüfungen, welche nach dem „DATA“ durchgeführt werden
• smtpd_end_of_data_restrictions - Prüfungen, welche nach erfolgter e-Mail-Übertragung durchgeführt werden

WICHTIG - In der hier nachfolgend dargestellten Konfiguration wird ausschließlich - smtpd_recipient_restrictions genutzt!

* (Der Grund hierfür, kann ausführlich und anschaulich im Buch Das Postfix-Buch nachgelesen werden!)

In dieser Konfigurationsdatei werden die Pflichtadressen jedes MTA (Mail Transport Agends) eingetragen.

Dies wird von RFC 822 und von RFC 2142 gefordert!

Eine Unterlassung der Annahme für e-Mails an mindestens diese beiden Adressen, kann evtl. zur folge haben, dass ein Eintrag auf sog. „Blacklists“ wie z.B. rfc-ignorant.org erfolgt, was für einen erfolgreichen Betrieb eines eigenen e-Mail-Servers nicht gerade förderlich sein dürfte!

Dafür ist die Konfigurationsdatei /etc/postfix/check_recipient_access_rfc mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/check_recipient_access_rfc

Danach sollte der Inhalt mindestens wie folgt aussehen:

postmaster@tachtler.net        OK
abuse@tachtler.net             OK

oder, für alle Domains für die sich der MTA „zuständig“ fühlt

postmaster@                    permit_auth_destination
abuse@                         permit_auth_destination

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss muss auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/check_recipient_access_rfc

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/check_recipient_access_rfc.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/check_recipient_access_rfc*
-rw-r--r-- 1 root root   51 Dec 12 13:08 /etc/postfix/check_recipient_access_rfc
-rw-r--r-- 1 root root 8192 Dec 12 13:08 /etc/postfix/check_recipient_access_rfc.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

In dieser Konfigurationsdatei können IP-Adressen oder sogar ganze Netzwerkbereiche eingetragen werden!

WICHTIG - Es können in einer „noramlen“ access-Tabelle keine Netzwerkmasken angegeben werden. Darum kann es sinnvoll sein, hier den Konfiguratiosndatei-Typ cidr zu verwenden!

Dafür ist die Konfigurationsdatei /etc/postfix/check_client_access mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/check_client_access

Danach sollte der Inhalt der Konfigurationsdatei z.B. wie folgt aussehen:

127.0.0.0/8             OK
192.168.0.0/24          OK

10.0.0.0/8              REJECT
172.16.0.0/12           REJECT

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

WICHTIG - Ein Aufruf für die Umwandlung der Konfigurationsdatei /etc/postfix/check_client_access in das cidr-Format von postmap ist NICHT erforderlich. Es wird bei cidr die ACSII-Datei als solches von Postfix interpretiert!

WICHTIG - Bei Änderungen ist ein reload von Postfix notwendig!

In dieser Konfigurationsdatei werden die „HELO/EHLO“-Kennungen eingetragen.

Dafür ist die Konfigurationsdatei /etc/postfix/check_helo_access mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/check_helo_access

Danach kann der Inhalt auch leer bleiben!

Als Trennzeichen zwischen den Einträgen (falls vorhanden), sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss kann auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/check_helo_access

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/check_helo_access.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/check_helo_access*
-rw-r--r-- 1 root root    0 Dec 15 10:18 /etc/postfix/check_helo_access
-rw-r--r-- 1 root root 8192 Dec 15 10:19 /etc/postfix/check_helo_access.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

In dieser Konfigurationsdatei werden die Absender e-Mail-Adressen eingetragen.

Dafür ist die Konfigurationsdatei /etc/postfix/check_sender_access mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/check_sender_access

WICHTIG - Danach sollte der Inhalt auch vorerst leer bleiben! - Jedoch sollten keine Einträge mit OK erfolgen!

Als Trennzeichen zwischen den Einträgen (falls vorhanden), sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss kann auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/check_sender_access

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/check_sender_access.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/check_sender_access*
-rw-r--r-- 1 root root    0 Dec 15 10:23 /etc/postfix/check_sender_access
-rw-r--r-- 1 root root 8192 Dec 15 10:23 /etc/postfix/check_sender_access.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

In dieser Konfigurationsdatei werden die Empfänger e-Mail-Adressen eingetragen.

Dafür ist die Konfigurationsdatei /etc/postfix/check_recipient_access mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/check_recipient_access

WICHTIG - Danach sollte der Inhalt auch vorerst leer bleiben!

Als Trennzeichen zwischen den Einträgen (falls vorhanden), sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss muss auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/check_recipient_access

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/check_recipient_access.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/check_recipient_access*
-rw-r--r-- 1 root root    0 Dec 15 10:28 /etc/postfix/check_recipient_access
-rw-r--r-- 1 root root 8192 Dec 15 10:29 /etc/postfix/check_recipient_access.db
-rw-r--r-- 1 root root   51 Dec 12 13:08 /etc/postfix/check_recipient_access_rfc
-rw-r--r-- 1 root root 8192 Dec 12 13:08 /etc/postfix/check_recipient_access_rfc.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

Unter Policy Delegation ist die Möglichkeit von Postfix über einen UNIX-Socket oder eine TCP-Verbindung im Klartext bekannte technische Merkmale einer e-Mail an einen Policy-Daemon zu übermitteln. Dieser Policy-Daemon trifft dann eine Entscheidung über die weitere Behandlung der e-Mail und liefert dieses Ergebnis dann an Postfix zurück.

Einer dieser Policy-Daemon's bietet die Möglichkeit Greylisting über Postgrey zu betreiben.

Nach Möglichkeit sollte auf die Installation über ein RPM-Paket zurückgegriffen werden. Unter folgendem Link kann ein entsprechendes RPM-Paket heruntergeladen werden:

• Postgrey - Dag Wieers Repository

Folgende Perl-Module sind zur Ausführung von Postgrey notwendig:

• BerkeleyDB
  • perl-BerkeleyDB - Dag Wieers Repository
• IO::Multiplex
  • perl-IO-Multiplex - Dag Wieers Repository
• Net::Server
• Net::Server::Multiplex
• Net::Server::Daemonize
  • perl-Net-Server - Dag Wieers Repository

Unter CentOS besteht die Möglichkeit eine Installation über folgende Befehle durchzuführen, ausgehend davon das sich die RPM-Pakete im Verzeichnis /tmp befinden:

# yum localinstall --nogpgcheck /tmp/perl-BerkeleyDB-0.36-1.el5.rf.i386.rpm

# yum localinstall --nogpgcheck /tmp/perl-IO-Multiplex-1.10-1.el5.rf.noarch.rpm

# yum localinstall --nogpgcheck /tmp/perl-Net-Server-0.97-1.el5.rf.noarch.rpm

# yum localinstall --nogpgcheck /tmp/postgrey-1.31-1.el5.rf.noarch.rpm

Nach der Installation, kann mit folgendem Befehl überprüft werden, was alles im Paket postgrey.i386 enthalten ist:

# rpm -qil postgrey | more
Name        : postgrey                     Relocations: (not relocatable)
Version     : 1.31                              Vendor: Dag Apt Repository, http://dag.wieers.com/apt/
Release     : 1.el5.rf                      Build Date: Fri 22 Feb 2008 04:21:47 PM CET
Install Date: Thu 18 Dec 2008 01:36:41 PM CET      Build Host: lisse.leuven.wieers.com
Group       : System Environment/Daemons    Source RPM: postgrey-1.31-1.el5.rf.src.rpm
Size        : 101072                           License: GPL
Signature   : DSA/SHA1, Tue 26 Feb 2008 02:24:57 AM CET, Key ID a20e52146b8d79e6
Packager    : Dag Wieers <dag@wieers.com>
URL         : http://postgrey.schweikert.ch/
Summary     : Postfix Greylisting Policy Server
Description :
Postgrey is a Postfix policy server implementing greylisting.  When a request
for delivery of a mail is received by Postfix via SMTP, the triplet CLIENT_IP /
SENDER / RECIPIENT is built.  If it is the first time that this triplet is
seen, or if the triplet was first seen less than 5 minutes, then the mail gets
rejected with a temporary error. Hopefully spammers or viruses will not try
again later, as it is however required per RFC.
/etc/postfix/postgrey_whitelist_clients
/etc/postfix/postgrey_whitelist_clients.local
/etc/postfix/postgrey_whitelist_recipients
/etc/rc.d/init.d/postgrey
/usr/sbin/postgrey
/usr/sbin/postgreyreport
/usr/share/doc/postgrey-1.31
/usr/share/doc/postgrey-1.31/COPYING
/usr/share/doc/postgrey-1.31/Changes
/usr/share/doc/postgrey-1.31/README
/usr/share/doc/postgrey-1.31/README-rpm
/usr/share/man/man8/postgrey.8.gz
/var/spool/postfix/postgrey

Folgender Benutzer wurde ebenfalls angelegt, was mit folgende Befehl überprüft werden kann:

# cat /etc/passwd | grep post
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
postgrey:x:100:103::/var/spool/postfix/postgrey:/sbin/nologin

Desweiteren wurden auch folgende Gruppen angelegt, was mit folgendem Befehl überprüft werden kann:

# cat /etc/group | grep post
mail:x:12:mail,postfix
postdrop:x:90:
postfix:x:89:
postgrey:x:103:

Um das Starten des Postgrey auch nach einem System-(re)-start auch in Zukunft dauerhaft zu realisieren, kann folgender Befehl genutzt werden. Hier wird Postgrey zu den Start-Scripten der einzelnen Runlevel des Betriebssystem hinzugefügt:

# chkconfig postgrey on

Ein Überprüfung, ob nur noch der Postgrey in den einzelnen Runlevel des Betriebssystems bei einem system-(re)-start mit gestartet wird, kann mit folgenden Befehlen abgefragt werden:

# chkconfig --list | grep postgrey
postgrey        0:off   1:off   2:on    3:on    4:on    5:on    6:off

Abschließend ist ein Start von Postgrey notwendig, was mit folgendem Befehl realisiert werden kann:

# service postgrey start
Starting postgrey:                                         [  OK  ]

Die Ausgabe der „Start“-Meldung des Postgrey in der Log-Datei /var/log/maillog sollte in etwa wie folgt aussehen und kann mit folgendem Befehl Abgefragt werden (nur relevanter Ausschnitt):

# cat /var/log/maillog
...
Dec 18 13:57:11 nss postgrey[16526]: Process Backgrounded
Dec 18 13:57:11 nss postgrey[16526]: 2008/12/18-13:57:11 postgrey (type Net::Server::Multiplex) starting! pid(16526)
Dec 18 13:57:11 nss postgrey[16526]: Binding to UNIX socket file /var/spool/postfix/postgrey/socket using SOCK_STREAM#012
Dec 18 13:57:11 nss postgrey[16526]: Setting gid to "103 103"
Dec 18 13:57:11 nss postgrey[16526]: Setting uid to "100"
...

Um Postgrey in Postfix einzubinden, bestehen zwei Möglichkeiten:

1. Über einen UNIX-Socket, falls sich Postfix und Postgrey auf einem Server befinden
2. Über eine TCP-Verbindung

Ein Definition in der /etc/postfix/main.cf würde in diesem Fall wie folgt aussehen (nur relevanter Ausschnitt):

...
        reject_rhsbl_client blackhole.securitysage.com,
        check_policy_service unix:postgrey/socket,
        reject_unverified_recipient,
...

Ein Definition in der /etc/postfix/main.cf würde in diesem Fall wie folgt aussehen (nur relevanter Ausschnitt):

...
        reject_rhsbl_client blackhole.securitysage.com,
        check_policy_service inet:127.0.0.1:10023,
        reject_unverified_recipient,
...

Abschließend ist ein Neustart des Postfix mit folgendem Befehl notwendig:

# service postfix restart
Shutting down postfix:                                     [  OK  ]
Starting postfix:                                          [  OK  ]

Ein weiterer dieser Policy-Daemon's bietet die Möglichkeit erweiterte gewichtete Prüfungen über policyd-weight zu realisieren.

Nach Möglichkeit sollte auf die Installation über ein RPM-Paket zurückgegriffen werden. Unter folgendem Link kann ein entsprechendes RPM-Paket heruntergeladen werden:

• policyd-weight - SourceForge.net

Folgende Perl-Module sind zur Ausführung von policyd-weight notwendig:

• Unix-Syslog
  • perl-Unix-Syslog - Dag Wieers Repository

Unter CentOS besteht die Möglichkeit eine Installation über folgende Befehle durchzuführen, ausgehend davon das sich die RPM-Pakete im Verzeichnis /tmp befinden:

# yum localinstall --nogpgcheck /tmp/perl-Unix-Syslog-1.0-1.el5.rf.i386.rpm

# yum localinstall --nogpgcheck /tmp/policyd-weight-0.1.14b17-1.noarch.rpm

Nach der Installation, kann mit folgendem Befehl überprüft werden, was alles im Paket policyd-weight.noarch enthalten ist:

# rpm -qil policyd-weight | more
]# rpm -qil policyd-weight | more
Name        : policyd-weight               Relocations: (not relocatable)
Version     : 0.1.14b17                         Vendor: (none)
Release     : 1                             Build Date: Tue 03 Jun 2008 07:46:52 AM CEST
Install Date: Sun 21 Dec 2008 11:37:27 AM CET      Build Host: c4-lx-infbld01.corp1.local
Group       : Applications/System           Source RPM: policyd-weight-0.1.14b17-1.src.rpm
Size        : 189293                           License: GPL
Signature   : (none)
Packager    : Morgan Weetman <morganweetman@users.sourceforge.net>
URL         : http://www.policyd-weight.org
Summary     : Weighted Postfix SMTPD policy daemon written entirely in perl.
Description :
policyd-weight is a Perl policy daemon for the Postfix MTA (2.1 and later) intended to eliminate forged envelope senders and HELOs (i.e. in bogus mails). It allows you to score DNSBLs (RBL/RHSBL), HELO, MAIL FR
OM and client IP addresses before any queuing is done. It allows you to REJECT messages which have a score higher than allowed, providing improved blocking of spam and virus mails. policyd-weight caches the mos
t frequent client/sender combinations (SPAM as well as HAM) to reduce the number of DNS queries.
/etc/init.d/policyd-weight
/etc/policyd-weight.conf
/usr/sbin/policyd-weight
/usr/share/doc/policyd-weight-0.1.14b17/COPYING
/usr/share/doc/policyd-weight-0.1.14b17/LICENSE
/usr/share/doc/policyd-weight-0.1.14b17/changes.txt
/usr/share/doc/policyd-weight-0.1.14b17/documentation.txt
/usr/share/doc/policyd-weight-0.1.14b17/policyd-weight.conf.sample
/usr/share/doc/policyd-weight-0.1.14b17/todo.txt
/usr/share/man/man5/policyd-weight.conf.5.gz
/usr/share/man/man8/policyd-weight.8.gz

Folgender Benutzer wurde ebenfalls angelegt, was mit folgende Befehl überprüft werden kann:

# cat /etc/passwd | grep polw
polw:x:101:502:policyd-weight daemon:/home/polw:/sbin/nologin

Desweiteren wurden auch folgende Gruppen angelegt, was mit folgendem Befehl überprüft werden kann:

# cat /etc/group | grep polw
polw:x:502:

Um das Starten des policyd-weight auch nach einem System-(re)-start auch in Zukunft dauerhaft zu realisieren, kann folgender Befehl genutzt werden. Hier wird policyd-weight zu den Start-Scripten der einzelnen Runlevel des Betriebssystem hinzugefügt:

# chkconfig policyd-weight on

Ein Überprüfung, ob nur noch der policyd-weight in den einzelnen Runlevel des Betriebssystems bei einem system-(re)-start mit gestartet wird, kann mit folgenden Befehlen abgefragt werden:

# chkconfig --list | grep policyd-weight
policyd-weight  0:off   1:off   2:on    3:on    4:on    5:on    6:off

Abschließend ist ein Start von policyd-weight notwendig, was mit folgendem Befehl realisiert werden kann:

# service policyd-weight start
Starting policyd-weight:                                   [  OK  ]

Die Ausgabe der „Start“-Meldung des policyd-weight in der Log-Datei /var/log/maillog sollte in etwa wie folgt aussehen und kann mit folgendem Befehl Abgefragt werden (nur relevanter Ausschnitt):

# cat /var/log/maillog
...
Dec 21 11:38:05 nss postfix/policyd-weight[24246]: warning: Got SIGINT. Daemon terminated.
Dec 21 11:43:25 nss postfix/policyd-weight[24320]: policyd-weight 0.1.14 beta-17 started and daemonized. conf:/etc/policyd-weight.conf; GID:502 502 EGID:502 502 UID:101 EUID:101; taint mode: 0
Dec 21 11:43:25 nss postfix/policyd-weight[24320]: warning: cache_query: $csock couln't be created: connect: No such file or directory, calling spawn_cache()
Dec 21 11:43:25 nss postfix/policyd-weight[24322]: cache spawned
...

Folgender Befehl, überprüft das laufen der benötigten Prozesse:

# ps aux | grep policyd-weight
polw     24320  0.0  0.8  12448  7996 ?        Ss   11:43   0:00 policyd-weight (master)
polw     24322  0.0  0.7  12448  7604 ?        Ss   11:43   0:00 policyd-weight (cache)
root     24353  0.0  0.0   3912   688 pts/2    R+   11:48   0:00 grep policyd-weight

Folgender Befehle zeigen, auf welchem Port policyd-weight (standardmäßig) lauscht:

]# netstat -tulpen | grep policyd
tcp        0      0 127.0.0.1:12525             0.0.0.0:*                   LISTEN      0          197701     24320/policyd-weigh

und wie policyd-weight gestartet wurde:

# lsof -i :12525
COMMAND     PID USER   FD   TYPE DEVICE SIZE NODE NAME
policyd-w 24320 polw    4u  IPv4 197701       TCP localhost.localdomain:12525 (LISTEN)

Um policyd-weight in Postfix einzubinden, muss folgende Definition in der /etc/postfix/main.cf erfolgen und würde in diesem Fall wie folgt aussehen (nur relevanter Ausschnitt):

...
        reject_rhsbl_client blackhole.securitysage.com,
        check_policy_service inet:127.0.0.1:12525,
        check_policy_service unix:postgrey/socket,
...

Abschließend ist ein Neustart des Postfix mit folgendem Befehl notwendig:

# service postfix restart
Shutting down postfix:                                     [  OK  ]
Starting postfix:                                          [  OK  ]

Um z.B. für gewisse Clients eine Ausnahme zu definieren, da bei kleineren aber durchaus auch bei größeren Providern, ein MX-Cluster (ein Verbund von mehreren Rechner mit derselben Aufgabe) sich verbergen können und gerade auch hier es vorkommt, dass diese nicht immer richtig konfiguriert sind, können in einer Ausnahme-Tabelle diese gepflegt werden.

Um für diesen Fall, Probleme bei der Bewertung von diesen e-Mails zu vermeiden, und dadurch evtl. „false positives“ zu produzieren, kann eine Ausnahme-Tabelle mit den z.B. Namen /etc/postfix/check_client_access_policyd_weight definiert werden und in der Konfigurationsdatei /etc/postfix/main.cf von Postfix wie folgt eingebunden werden (nur relevanter Ausschnitt):

...
        reject_rhsbl_client blackhole.securitysage.com,
        check_client_access btree:/etc/postfix/check_client_access_policyd_weight,
        check_policy_service inet:127.0.0.1:12525,
...

Hier wird als Beispiel die Annahme von e-Mails für example.com beschrieben.

Dafür ist die Konfigurationsdatei /etc/postfix/check_client_access_policyd_weight mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/check_client_access_policyd_weight

Danach sollte der Inhalt wie folgt aussehen:

example.com             OK

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

Zum Abschluss muss auch hier diese Text-Datei in ein hash-Format, oder besser noch in das Format btree mithilfe des Postfix eigenen Befehls postmap umgewandelt werden.

Der Aufruf für die Umwandlung in das z.B. btree-Format lautet wie folgt:

# postmap btree:/etc/postfix/check_client_access_policyd_weight

Anschließend sollte eine neue Datei mit dem Namen /etc/postfix/check_client_access_policyd_weight.db entstanden sein.

Dies kann mit folgendem Befehl überprüft werden:

# ll /etc/postfix/check_client_access_policyd_weight*
-rw-r--r-- 1 root root    0 Dec 21 12:33 /etc/postfix/check_client_access_policyd_weight
-rw-r--r-- 1 root root 8192 Dec 21 12:34 /etc/postfix/check_client_access_policyd_weight.db

Damit ist die Umwandung in das btree-Format abgeschlossen.

SPAM läst meist auch nicht lange auf sich warten, wie folgendes Beispiel aus der LOG-Datei /var/log/maillog zeigt:

Dec 21 16:31:14 nss postfix/smtpd[25550]: connect from 124-11-193-25.static.tfn.net.tw[124.11.193.25]
Dec 21 16:31:16 nss postfix/policyd-weight[25555]: child: spawned
Dec 21 16:31:17 nss postfix/policyd-weight[25555]: weighted check:  NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 CL_IP_NE_HELO=1.5 RESOLVED_IP_IS_NOT_HELO=1.5 HELO_NUMERIC=2.5 (check from: .yahoo. - helo: .88.217.171.167. - helo-domain: .167.)  FROM_NOT_FAILED_HELO(DOMAIN)=3; <client=124.11.193.25> <helo=88.217.171.167> <from=jk9l3g4jle@yahoo.com> <to=sseenndd1201@yahoo.com.hk>; rate: 4
Dec 21 16:31:17 nss postfix/policyd-weight[25555]: decided action=550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: 88.217.171.167, MTA hostname: 124-11-193-25.static.tfn.net.tw[124.11.193.25] (helo/hostname mismatch); <client=124.11.193.25> <helo=88.217.171.167> <from=jk9l3g4jle@yahoo.com> <to=sseenndd1201@yahoo.com.hk
>; delay: 1s
Dec 21 16:31:17 nss postfix/smtpd[25550]: NOQUEUE: reject: RCPT from 124-11-193-25.static.tfn.net.tw[124.11.193.25]: 550 5.7.1 <sseenndd1201@yahoo.com.hk>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: 88.217.171.167, MTA hostname: 124-11-193-25.static.tfn.net.tw[124.11.193.25] (helo/hostname
 mismatch); from=<jk9l3g4jle@yahoo.com> to=<sseenndd1201@yahoo.com.hk> proto=SMTP helo=<88.217.171.167>
Dec 21 16:31:17 nss postfix/smtpd[25550]: lost connection after RCPT from 124-11-193-25.static.tfn.net.tw[124.11.193.25]
Dec 21 16:31:17 nss postfix/smtpd[25550]: disconnect from 124-11-193-25.static.tfn.net.tw[124.11.193.25]

Der Einsatz des Sender Policy Frameworks ist eher nicht zu empfehlen! Das (SPF) schreibt fest, welche MTA Mail Transport Agent ausgehend für den Versandt von e-Mails einer Domain zulässig ist!

Es würde auch die Möglichkeit verhindern, e-Mails mit eigener Absender-e-Mail-Adresse über einen dritten Rechner zu versenden. Es wäre also nur möglich e-Mails auch über den Mail-Server zu versenden, auf dem auch das Postfach liegt! Also wär der Versand über ein z.B. WebFormular, oder eine Web-Grußkarte über einen Drittanbieter NICHT möglich!

Deshalb sollte eine Sender Policy Framework (SPF) Definition so gewählt werden, das diese Beschränkung nicht greift.

Über folgende Seite kann ein Dialog durchlaufen werden, mit dem eine Sender Policy Framework (SPF) erstellt werden kann:

• Sender Policy Framework (SPF) - Definitionen erstellen

Die durch diesen Link erstellte Information muss dann in den DNS-Server wie folgt eingebunden werden (relevanter Ausschnitt - bind):

tachtler.net.                           IN      TXT     "v=spf1 ip4:88.217.171.167/32 a mx include:tachtler.net ?all"

Die ob enstehende Information setzt sich wie folgt zusammen:

Um weitere Informationen erhalten zu können, kann folgender Link genutzt werden:

• Sender Policy Framework (SPF) - Definitions-Erklärungen

Unter der Abkürzung DSN verbirgt sich hier im Zusammenhang Delivery Status Notifications - was so viel wie Benachrichtigung an den Absender über die normalen Bounce-Nachrichten hinaus bedeutet. Evtl. auch als „Benachrichtigung über gelesen an den Absender“ bekannt. Letztendlich vordert hier der Absender einer e-Mail Informationen (auch über eine erfolgreich zugestellte e-Mail) vom eigenen MTA Mail Transport Agent an. Folgende Beispiele sollen dieses Verfahren verdeutlichen.

Nachrichten an den Absender z.B. bei:

• MAIL FROM: user@example.com RET=FULL, bedeutet: Bei einem Bounce der Nachricht, soll die original e-Mail vollständig zurück gesandt werden!
• MAIL FROM: user@example.com ENVID=„envelop-id“, bedeutet: Legt eine ID fest, welche bei einem Bounce zurückgeschickt werden soll!

• RCPT TO: user@example.com NOTIFY=NEVER, bedeutet: Der Absender möchte nie auch bei nicht erfolgreicher Zustellung benachrichtigt werden!
• RCPT TO: user@example.com NOTIFY=SUCCESS, bedeutet: Der Absender möchte bei erfolgreicher Zustellung benachrichtigt werden!
• RCPT TO: user@example.com NOTIFY=FAILURE, bedeutet: Der Absender möchte bei nicht erfolgreicher Zustellung benachrichtigt werden!
• RCPT TO: user@example.com NOTIFY=DELAY, bedeutet: Der Absender möchte bereits bei einer verzögerten Zustellung benachrichtigt werden!
• RCPT TO: user@example.com ORCPT=user@example.example.com, bedeutet: Gibt den ursprünglichen Empfänger an, von dem aus die e-Mail weitergeleitet wurde!

Die einzelnen Möglichkeiten sind ebenfalls sinnvoll miteinander kombinierbar!

Aufgrund von evtl. unerwünschter Server-Last oder auch von Informationen über die eigene Infrastruktur, welche durch Delivery Status Notifications (DSN) erzeugt bzw. preis gegeben werden, kann es unerwünscht sein Delivery Status Notifications (DSN) zuzulassen!

Es sind nur wenige Parameter notwendig um Delivery Status Notifications (DSN) zu deaktivieren. Eine Deaktivierung kann auch, je nach Herkunft des Clients deaktiviert werden. Letztere Option soll anhand eines Beispiels durchgeführt werden. Dabei soll nur für die evtl. lokal vorhandenen Clients - Delivery Status Notifications (DSN) erlaubt sein, für alle anderen Clients NICHT!

Dazu ist es notwendig unter folgendem Parameter in der Konfigurationsdatei /etc/postfix/main.cf nachfolgende Datei zu definieren (relevanter Ausschnitt):

...
smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/esmtp_access
...

Dabei gibt es zwei Optionen, welche jeweils hinter der entsprechenden IP-Adresse und der dazugehörigen Subnetz-Maske stehen dürfen:

1. silent-dicard - Es werden keine LOG-Meldungen geschrieben
2. dsn - Verschweigt im SMTP-Dialog die DSN-Fähigkeit vollständig!

WICHTIG - Es können in einer „normalen“ access-Tabelle keine Netzwerkmasken angegeben werden. Darum kann es sinnvoll sein, hier den Konfigurationsdatei-Typ cidr zu verwenden!

Dafür ist die Konfigurationsdatei /etc/postfix/esmtp_access mit folgendem Befehl neu zu erstellen:

# touch /etc/postfix/esmtp_access

Danach sollte der Inhalt der Konfigurationsdatei z.B. wie folgt aussehen:

192.168.0.0/24          silent-discard
0.0.0.0/0               silent-discard, dsn
::/0                    silent-discard, dsn

Falls weitere „Schlüsselwörter“ vom HELO/EHLO ausgeschlossen werden sollen, müssen diese ebenfalls hier aufgenommen werden und ggf. die Option smtpd_discard_ehlo_keywords auskommentiert werden, da ein Einsatz beider Optionen NICHT möglich ist!

Evtl. kann der Inhalt der Konfigurationsdatei z.B. auch wie folgt aussehen:

192.168.0.0/24          pipelining, silent-discard
0.0.0.0/0               pipelining, silent-discard, dsn
::/0                    pipelining, silent-discard, dsn

Als Trennzeichen zwischen den beiden Einträgen, sollte am besten die [TAB]-Taste verwendet werden, es ist aber auch die Trennung durch [Leerzeichen] möglich!

WICHTIG - Ein Aufruf für die Umwandlung der Konfigurationsdatei /etc/postfix/esmtp_access in das cidr-Format von postmap ist NICHT erforderlich. Es wird bei cidr die ACSII-Datei als solches von Postfix interpretiert!

WICHTIG - Bei Änderungen ist ein reload von Postfix notwendig!

Zum Abschluss kann ein Test über den Aufruf von telnet an mx1.tachtler.net gerichtet, Aufschluss über die Möglichen HELO/EHLO Möglichkeiten des MTA geben:

# telnet mx1.tachtler.net 25
Trying 88.217.171.167...
Connected to mx1.tachtler.net (88.217.171.167).
Escape character is '^]'.
220 mx1.tachtler.net ESMTP Postfix
EHLO mx1.tachtler.net
250-mx1.tachtler.net
250-SIZE 10240000
250-ETRN
250-ENHANCEDSTATUSCODES
250 8BITMIME
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Postfix bietet die Möglichkeit ein Rate-Limiting für Clients einzusetzen. Dabei wird das in Postfix normalerweise bereits eingebundene und aktive Modul - anvil genutzt. Beim Rate-Limiting wird überprüft

1. wie viele Verbindungen pro Zeiteinheit ein Client aufbauen darf
2. wie viele Empfänger pro Zeiteinheit bei einem Client zulässig sind

Zuerst ist es sinnvoll die Standardwerte der einzelnen Parameter zu kennen. Mit den nachfolgenden Befehlen können die Standardwerte ermittelt werden:

Zeiteinheit des Moduls - anvil

# postconf -d anvil_rate_time_unit
anvil_rate_time_unit = 60s

Erlaubte Anzahl von Verbidungen, pro Zeiteinheit eines Clients

# postconf -d smtpd_client_connection_count_limit
smtpd_client_connection_count_limit = 50

Erlaubte Anzahl von Empfängern, pro Zeiteinheit eines Clients

# postconf -d smtpd_client_recipient_rate_limit
smtpd_client_recipient_rate_limit = 0

* smtpd_client_recipient_rate_limit = 0 bedeuetet unlimitiert

Eine Limitierung kann durchaus sinnvoll sein!

Um eine Limitierung in Postfix festzulegen, können folgende Definitionen in der /etc/postfix/main.cf durchgeführt werden (nur relevanter Ausschnitt):

...
smtpd_client_connection_count_limit = 10
smtpd_client_recipient_rate_limit = 10
...

Abschließend ist ein Neustart des Postfix mit folgendem Befehl notwendig:

# service postfix restart
Shutting down postfix:                                     [  OK  ]
Starting postfix:                                          [  OK  ]

Wie andere MTA's auch, bietet Postfix die Möglichkeit „Wartezeiten“ welche in sogenannten Queue's realisiert werden variablen einzustellen.

Ein Beispiel dafür ist, wie lange Postfix versucht eine e-Mail zuzustellen, wenn der annehmende MTA diese aktuell nicht annimmt, bevor Postfix diese e-Mail als „gebounct“ - als unzustellbar - zurückweist und eine Bounce-Nachricht an den Absender zustellt.

Auch hier der Befehl, wie der Standardwert für die Versuche eine e-Mail zuzustellen, abgefragt werden kann:

# postconf -d maximal_queue_lifetime
maximal_queue_lifetime = 5d

Der Absender einer e-Mail würde also erst nach fünf Tagen erfahren, dass seine e-Mail nicht zugestellt werden konnte!

Ebenso gibt es einen Wert für die „Wartezeit“ von „gebouncten“ e-Mails. Dies wäre praktisch die Information an den Absender, dass die e-Mail nicht zugestellt werden konnte, die ebenfalls NICHT zugestellt werden kann.

Auch hier der Befehl, wie der Standardwert für die Versuche eine „Bounce“-e-Mail zuzustellen, abgefragt werden kann:

# postconf -d bounce_queue_lifetime
bounce_queue_lifetime = 5d

Die eingestellten Werte von fünf Tagen scheinen in der heutigen Zeit etwas lang und auch für das Verständnis vieler e-Mail-Nutzer sehr lange. Deshalb ist die Korrektur der Werte auf z.B. drei Tage oder gar einen Tag durchaus sinnvoll!

Um eine Änderung der Werte in Postfix zu realisieren, können folgende Definitionen in der /etc/postfix/main.cf durchgeführt werden (nur relevanter Ausschnitt):

...
maximal_queue_lifetime = 1d
bounce_queue_lifetime = 1d
...

Abschließend ist ein Neustart des Postfix mit folgendem Befehl notwendig:

# service postfix restart
Shutting down postfix:                                     [  OK  ]
Starting postfix:                                          [  OK  ]

Bevor mit der grundlegenden Konfiguration von Postfix-SASL begonnen werden kann, ist sicherzustellen, dass der der Daemon - saslauthd gestartet ist.

Um das Starten von saslauthd auch nach einem System-(re)-start auch in Zukunft dauerhaft zu realisieren, kann folgender Befehl genutzt werden. Hier wird saslauthd zu den Start-Scripten der einzelnen Runlevel des Betriebssystem hinzugefügt:

# chkconfig saslauthd on

Ein Überprüfung, ob saslauthd in den einzelnen Runlevel des Betriebssystems bei einem system-(re)-start mit gestartet wird, kann mit folgenden Befehlen abgefragt werden:

# chkconfig --list | grep saslauthd
saslauthd       0:off   1:off   2:on    3:on    4:on    5:on    6:off

Es gibt verschiedene Möglichkeiten der Authentifizierung von Postfix gegen SASL. Standardmäßig authentifiziert sich Postfix gegen den Daemon saslauthd, wie beschrieben!

Wenn als pwcheck_method: saslauthd angegeben ist, sind NUR die Methoden PLAIN und LOGIN nur erlaubt!

Dabei ist die Standardeinstellung in der Konfigurationsdatei /etc/sysconfig/saslauthd ist folgende:

# Directory in which to place saslauthd's listening socket, pid file, and so
# on.  This directory must already exist.
SOCKETDIR=/var/run/saslauthd

# Mechanism to use when checking passwords.  Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled with the ablity to use.
MECH=pam

# Additional flags to pass to saslauthd on the command line.  See saslauthd(8)
# for the list of accepted flags.
FLAGS=

Un die Standardeinstellung der Konfigurationsdatei /usr/lib/sasl2/smtpd.conf ist folgende:

pwcheck_method: saslauthd

Um nun die Authentifizierung gegen LDAP zu erreichen, sind folgende Änderungen an den Konfigurationsdateien notwendig. Zuerst /etc/sysconfig/saslauthd:

# Directory in which to place saslauthd's listening socket, pid file, and so
# on.  This directory must already exist.
SOCKETDIR=/var/run/saslauthd

# Mechanism to use when checking passwords.  Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled with the ablity to use.
# Tachtler
# default: MECH=pam
MECH=ldap

# Additional flags to pass to saslauthd on the command line.  See saslauthd(8)
# for the list of accepted flags.
FLAGS=

und die Konfigurationsdatei /usr/lib/sasl2/smtpd.conf:

pwcheck_method: auxprop
log_level: 3
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5

Wenn als pwcheck_method: auxprop angegeben ist, sind AUCH die Methoden CRAM-MD5 und DIGEST-MD5 erlaubt!

WICHTIG Jetzt müssen die LDAP-Aufruf-Parameter festgelegt werden, was die Anlage einer neuen Konfigurationsdatei im Verzeichnis /etc mit dem Namen saslauthd.conf erfordert, was mit folgendem Befehl realisiert werden kann:

# touch /etc/saslauthd.conf

Die Konfigurationsdatei /etc/saslauthd.conf sollte folgenden Inhalt haben:

ldap_servers: ldap://ldap.tachtler.net
ldap_search_base: dc=tachtler,dc=net
ldap_bind_dn: cn=Superbenutzer,dc=tachtler,dc=net
ldap_bind_pw: geheim
ldap_scope: sub
ldap_uidattr: uid
ldap_filter_mode: yes
ldap_filter: uid=%U

Zuletzt müssen noch in der Konfigurationsdatei /etc/postfix/main.cf folgende Einstellungen hinzugefügt werden:

smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes

Eine Anmeldung via telnet würde dann folgendes Ergebnis liefern:

# telnet mx1.tachtler.net 25
Trying 88.217.171.167...
Connected to mx1.tachtler.net (88.217.171.167).
Escape character is '^]'.
220 mx1.tachtler.net ESMTP Postfix
EHLO mx1.tachtler.net
250-mx1.tachtler.net
250-SIZE 10240000
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
250-AUTH=DIGEST-MD5 CRAM-MD5 PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Falls ein Backup-Server für Postfix eingesetzt werden soll sind folgende Schritte durchzuführen. Es wird hier davon ausgegangen, dass folgendes Szenario umgesetzte wird:

• MX-Server Priorität 10: mx1.tachtler.net (eigener MX-Server)
• MX-Server Priorität 20: mx1.nausch.org (backup MX-Server)

und natürlich auch umgekehrt!!! - Diese „umgekehrte Konfiguration“ wird hier beschrieben!

Die Richtigkeit der DNS-Einträge, kann mit folgendem Befehl überprüft werden (nur relevanter Auszug aus der Antowrt des Befehls):

# dig tachtler.net MX
...
;; ANSWER SECTION:
tachtler.net.           86400   IN      MX      10 mx1.tachtler.net.
tachtler.net.           86400   IN      MX      20 mx1.nausch.org.
...

Es soll ein sogenannter „Store-and-Forward“ - Backup-Server umgesetzt werden. Hier werden die e-Mails vom Backup-Server angenommen und bei Widerverfügbarkeit an den eigentlichen MX-Server dann zugestellt.

Folgende Einstellung muss in der Konfigurationsdatei /etc/postfix/master.cf überprüft werden:

...
verify    unix  -       -       n       -       1       verify
...

* Falls das Modul verify nicht aktiv sein sollte, sollte dieses aktiviert werden!

Dies dient später dem Backup-Server zur dynamischen Überprüfung, ob er für die entsprechende e-Mail-Adresse überhaupt e-Mails entgegennehmen darf bzw. kann! Falls ein positives Ergebnis zu Annahme für eine e-Mail-Adresse erfolgt, wird dieses Ergebnis in einer lokalen Datenbank (Berkely DB) für einen gewissen Zeitraum zwischengespeichert!

HINWEIS - Die Überprüfung erfolgt, wenn VRFY nicht aktiv ist über HELO, MAIL FROM, RCPT TO, QUIT

Folgende Änderungen sind an der Konfigurationsdatei /etc/postfix/main.cf durchzuführen:

Zuerst einmal sollte disable_vrfy_command = no eingestellt sein. Dies ist der Default-Wert, also muss hier kein Eintrag in der Konfigurationsdatei /etc/postfix/main.cf erfolgen!

Die folgende Änderung dient zum Aufbau einer Datei mit „erlaubten e-Mail-Adressen“ durchgeführt werden:

...
# Backup-Mailserver Verification Database
#
address_verify_map = btree:/var/spool/postfix/data/verify
permit_mx_backup_networks = 88.217.187.21/32
...

Als nächstes muss noch der Rückgabe-Wert, falls eine ungültige e-Mail-Adresse vom Backup-Server angefragt wird, von 450 auf 550 abgeändert werden, was mit folgendern ergänzung durchgeführt werden kann:

...
unverified_recipient_reject_code = 577
...

Als letztes muss noch sichergestellt werde, dass die Prüfungen unter smtpd_recipient_restrictions wie folgt in der richtigen Reihenfolge an der richtigen Stelle stehen:

...
# Greylisting check over UNIX-Socket - active -
        check_policy_service unix:postgrey/socket,
# Check dynamicly existing Relay-Recipient
        reject_unverified_recipient,
# Allow Backup-MX
        permit_mx_backup,
# Deny all other Relaying
        reject_unauth_destination,
...

Anschließend muss ein Verzeichnis mit dem Namen /var/sool/postfix/data mit nachfolgendem Befehl angelegt werden:

# mkdir /var/spool/postfix/data

Die entsprechenden Besitzrechte können mit folgendem Befehl wie folgt angepasst werden:

# chown -R postfix.root /var/spool/postfix/data

Die entsprechenden Zugriffsrechte können mit folgendem Befehl wie folgt angepasst werden:

# chmod -R 700 /var/spool/postfix/data/

Jetzt ist der Zeitpunkt für einen ersten Test gekommen, um zu sehen ob der auch korrekt konfiguriert ist!

Unter dem folgendem Link, kann ein solcher Test durchgeführt werden. WICHTIG - Die Firewall z.B. iptables sollte jetzt auf Port 25 (SMTP) offen sein!

• http://www.abuse.net/relay.html

Ein Ergebnis eines Testes sollte dann wie folgt aussehen:

Mail relay testing
Connecting to 88.217.171.167 for anonymous test ...

<<< 220 mx1.tachtler.net ESMTP Postfix
>>> HELO www.abuse.net
<<< 250 mx1.tachtler.net
Relay test 1
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@abuse.net>
<<< 250 2.1.0 Ok
>>> RCPT TO:<securitytest@abuse.net>
<<< 450 4.1.1 <securitytest@abuse.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 2
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest>
<<< 250 2.1.0 Ok
>>> RCPT TO:<securitytest@abuse.net>
<<< 504 5.5.2 <spamtest>: Sender address rejected: need fully-qualified address
Relay test 3
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<>
<<< 250 2.1.0 Ok
>>> RCPT TO:<securitytest@abuse.net>
<<< 450 4.1.1 <securitytest@abuse.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 4
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<securitytest@abuse.net>
<<< 450 4.1.1 <securitytest@abuse.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 5
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@tachtler.net>
<<< 250 2.1.0 Ok
>>> RCPT TO:<securitytest@abuse.net>
<<< 450 4.1.1 <securitytest@abuse.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 6
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<securitytest%abuse.net@[88.217.171.167]>
<<< 450 4.1.1 <securitytest%abuse.net@[88.217.171.167]>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 7
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<securitytest%abuse.net@tachtler.net>
<<< 450 4.1.1 <securitytest%abuse.net@tachtler.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 8
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<"securitytest@abuse.net">
<<< 450 4.1.1 <securitytest@abuse.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 9
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<"securitytest%abuse.net">
<<< 504 5.5.2 <securitytest%abuse.net>: Recipient address rejected: need fully-qualified address
Relay test 10
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<securitytest@abuse.net@[88.217.171.167]>
<<< 450 4.1.1 <securitytest@abuse.net@[88.217.171.167]>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 11
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<"securitytest@abuse.net"@[88.217.171.167]>
<<< 450 4.1.1 <securitytest@abuse.net@[88.217.171.167]>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 12
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<securitytest@abuse.net@tachtler.net>
<<< 450 4.1.1 <securitytest@abuse.net@tachtler.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 13
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<@[88.217.171.167]:securitytest@abuse.net>
<<< 450 4.1.1 <securitytest@abuse.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 14
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<@tachtler.net:securitytest@abuse.net>
<<< 450 4.1.1 <securitytest@abuse.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 15
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<abuse.net!securitytest>
<<< 504 5.5.2 <abuse.net!securitytest>: Recipient address rejected: need fully-qualified address
Relay test 16
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<abuse.net!securitytest@[88.217.171.167]>
<<< 450 4.1.1 <abuse.net!securitytest@[88.217.171.167]>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test 17
>>> RSET
<<< 250 2.0.0 Ok
>>> MAIL FROM:<spamtest@[88.217.171.167]>
<<< 250 2.1.0 Ok
>>> RCPT TO:<abuse.net!securitytest@tachtler.net>
<<< 450 4.1.1 <abuse.net!securitytest@tachtler.net>: Recipient address rejected: undeliverable address: host smtp.abuse.net[208.31.42.109] said: 553 Not a valid address at abuse.net (5.1.1) (in reply to RCPT TO command)
Relay test result
All tests performed, no relays accepted.