Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
centos:mail_c7:mta_6 [04.11.2014 16:07. ] – [Postfix] django | centos:mail_c7:mta_6 [22.07.2019 15:00. ] (aktuell) – Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 7: | Zeile 7: | ||
Will man " | Will man " | ||
- | ==== Postfix | + | ==== Konfiguration |
In der Postfix-Konfigurationsdatei // | In der Postfix-Konfigurationsdatei // | ||
# vim / | # vim / | ||
Zeile 62: | Zeile 62: | ||
</ | </ | ||
+ | Damit nun unser Postfix SMTP-Server auch diese Zustellungsart verwendet kann, benötigen wir noch einen Eintrag in der **[[centos: | ||
+ | # vim / | ||
+ | <file bash / | ||
+ | # Lookup-Tabelle zum Aktivieren einer alternativen Mailrouting bei der | ||
+ | # Zustellung an einen weiteren Mailserver. Nach dem Ändern und/oder | ||
+ | # Erweitern der Tabelle, muß noch mittels: | ||
+ | # $ postmap / | ||
+ | # | ||
+ | # die zugehörige Datenbank erzeugt werden. | ||
+ | # | ||
+ | # Alle eMails, die an Subdomains von nausch.org gerichtet sind | ||
+ | # (" | ||
+ | # intra.nausch.org (MX-Records) weitergeleitet. (keine " | ||
+ | # | ||
- | ==== Dovecot ==== | + | # Alle eMails, die an die Domain tachtler.net gerichtet sind, werden an |
+ | # den bzw. die Mailserver der Mail-Domäne t-offline.de (MX-Records) | ||
+ | # weitergeleitet. (keine " | ||
+ | # tachtler.net | ||
+ | # Mails an backup.nausch.org werden an den Mailserver (A-Record) auf Port 25 | ||
+ | # mit Namen mail.intra.nausch.org geschickt. | ||
+ | # | ||
+ | # Django : 2013-02-21 | ||
+ | # eMails an den Fax-Server an den Host vml000020 weiterleiten | ||
+ | fax.nausch.org | ||
+ | # eMails an den Key-Server sollen an den Host vml000030 weitergeleitet | ||
+ | # werden. | ||
+ | keyserver.nausch.org | ||
+ | # Django : 2013-02-22 | ||
+ | # eMails an den Mailinglisten-Server an das Programm mailman weiterreichen | ||
+ | # | ||
+ | # Django : 2014-11-04 | ||
+ | # eMails der Maildomäne nausch.org an das Programm dovecot-lda weiterleiten | ||
+ | nausch.org | ||
+ | </ | ||
+ | <WRAP center round important> | ||
+ | **WICHTIG**: | ||
+ | Diese Art der Anbindung ist jedoch nicht zu empfehlen und zwar aus folgenden drei Gründen! | ||
+ | - Der Mailtransport ist nicht sehr performant, da für jede Mailzustellung ein separater Prozess gestartet werden. | ||
+ | - Sind eMails mit mehreren Empfängern an den Dovecot-Server zu übergeben, so muss diese eMail entsprechend oft einzeln an jeden Empfänger übergeben werden. | ||
+ | - Eine dynamische Empfängervalidierung ist bei **dovecot-lda** **__nicht__** möglich! | ||
+ | <WRAP center round tip> | ||
+ | Darüber hinaus ist bei einer eventuell späteren Migration des Dovecot-IMAP-Servers auf einen separaten Server der Umprogrammierungsaufwand ungemein größer, als bei der nachfolgend beschriebenen Anbindungsvariante via **LMTP**. Also empfiehlt es sich lieber gleich, es // | ||
+ | </ | ||
+ | </ | ||
+ | ===== LMTP - MTA und MDA auf gleichem bzw. getrennten Host(s) ===== | ||
+ | ==== Postfix (LMTP) ==== | ||
+ | Da unser Mailserver nicht nur für die Hauptdomäne **// | ||
+ | Postfix nimmt immer dann Post außerhalb unseres **$mynetworks** an, wenn er sich zuständig fühlt. Hierzu kennt Postfix drei Klassen von Domains: | ||
+ | - echte Domains **$mydestination** \\ Diese Variante haben wir schon bei der [[centos: | ||
+ | - zu relayende Domains **$relay_domains** \\ Mit diese Variante haben wir uns bereits bei der Anbingung unseres Mailservers an ein Backend-Mailgateway im Kapitel [[centos: | ||
+ | - virtuelle Domains **$virtual_alias_domains** \\ Eine alternative Einbindung virtueller Domains ist die Verwendung von **virtual_alias_domains** und **virtual_alias_maps** | ||
+ | <WRAP round important> | ||
+ | Dabei ist es logisch ausgeschlossen, | ||
+ | Da wir unsere Maildomänen und Nutzerkonten mit Hilfe von [[centos: | ||
+ | === Konfiguration === | ||
+ | In der Postfix-Konfigurationsdatei // | ||
+ | # vim / | ||
+ | <code bash>... | ||
+ | # Django : 2014-10-15 - virtuelle Mail-Domains und Mailboxen mit Anbindung an | ||
+ | # das mySQL-Datenbankbackend (Verwaltung mit Hilfe von postfixadmin) | ||
+ | # default: virtual_mailbox_domains = $virtual_mailbox_maps | ||
+ | # virtual_alias_maps = $virtual_maps | ||
+ | # virtual_mailbox_maps = | ||
+ | virtual_mailbox_domains = proxy: | ||
+ | virtual_alias_maps = proxy: | ||
+ | proxy: | ||
+ | proxy: | ||
+ | # | ||
+ | virtual_mailbox_maps = proxy: | ||
+ | proxy: | ||
+ | ... | ||
+ | </ | ||
+ | Für den Transport definieren wir nun den **[[centos: | ||
+ | # vim / | ||
+ | <code bash>... | ||
+ | # Django : 2014-10-15 - Definition zur Erreichbarkeit unseres MDA-Servers | ||
+ | # Dovecot-IMAP | ||
+ | # default: virtual_transport = virtual | ||
+ | virtual_transport = lmtp: | ||
+ | </ | ||
+ | === Konfiguration aktivieren === | ||
+ | Zur Aktivierung unserer Konfiguration benutzen wir **systemctl**. | ||
+ | # systemctl restart postfix | ||
+ | |||
+ | Da keine Rückmeldung erfolgte können wir davon ausgehen, dass alle unsere Konfigurationsoptionen unseren Wünschen entsprechend gesetzt wurden. | ||
+ | |||
+ | Wir können aber auch den Status unseres Mailservers abfragen. | ||
+ | # systemctl status postfix | ||
+ | < | ||
+ | | ||
+ | | ||
+ | Process: 3222 ExecStop=/ | ||
+ | Process: 3206 ExecReload=/ | ||
+ | Process: 3236 ExecStart=/ | ||
+ | Process: 3234 ExecStartPre=/ | ||
+ | Process: 3231 ExecStartPre=/ | ||
+ | Main PID: 3309 (master) | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | Nov 03 22:35:17 vml000087.dmz.nausch.org systemd[1]: Starting Postfix Mail Transport Agent... | ||
+ | Nov 03 22:35:18 vml000087.dmz.nausch.org postfix/ | ||
+ | Nov 03 22:35:18 vml000087.dmz.nausch.org systemd[1]: Started Postfix Mail Transport Agent. | ||
+ | </ | ||
+ | |||
+ | ==== Dovecot (LMTP) ==== | ||
+ | Auch auf Seiten unseres Dovecot-Servers muss eine kleine Konfigurationserweiterung erfolgen. | ||
+ | === Konfiguration === | ||
+ | Zur Anbindung des **MUA**((**M**ail **U**ser **A**gent)) **Dovecot** an unseren **MTA**((**M**ail **T**ransport **A**gent)) **Postfix** nutzen wir das Protokoll **LMTP**. | ||
+ | In der Konfigurationsdatei // | ||
+ | |||
+ | Statt der vorbereiteten Variante über einen Unix-Datei-Socket, | ||
+ | |||
+ | Als erstes werden wir nun die nötige LMTP-Konfiguration in der **10-master.conf** festlegen. | ||
+ | # vim / | ||
+ | <file bash / | ||
+ | |||
+ | service lmtp { | ||
+ | unix_listener lmtp { | ||
+ | #mode = 0666 | ||
+ | } | ||
+ | |||
+ | # Create inet listener only if you can't use the above UNIX socket | ||
+ | # | ||
+ | # Avoid making LMTP visible for the entire internet | ||
+ | #address = | ||
+ | #port = | ||
+ | #} | ||
+ | # Django : 2014-07-22 | ||
+ | # Einlieferung der Nachrichten via LMTP | ||
+ | inet_listener lmtp { | ||
+ | address = 10.0.0.70 | ||
+ | port = 24 | ||
+ | } | ||
+ | } | ||
+ | |||
+ | ... | ||
+ | </ | ||
+ | |||
+ | === Aktivierung === | ||
+ | Zum Aktivieren unserer Konfigurationsänderung führen wir einen **reload** des dovecot-Daemons durch. | ||
+ | # systemctl reload dovecot.service | ||
+ | |||
+ | Der **Reload** wurde im maillog dokumentiert. Bei Bedarf können wir den Status unseres Dovecot_Servers abfragen. | ||
+ | # systemctl status dovecot.service | ||
+ | < | ||
+ | | ||
+ | | ||
+ | Process: 23610 ExecReload=/ | ||
+ | Main PID: 22063 (dovecot) | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | |||
+ | Jul 23 21:32:16 vml000070.dmz.nausch.org dovecot[23587]: | ||
+ | Jul 23 21:47:21 vml000070.dmz.nausch.org systemd[1]: Reloading Dovecot IMAP/POP3 email server. | ||
+ | Jul 23 21:47:21 vml000070.dmz.nausch.org dovecot[22063]: | ||
+ | Jul 23 21:47:21 vml000070.dmz.nausch.org systemd[1]: Reloaded Dovecot IMAP/POP3 email server. | ||
+ | Jul 23 21:47:21 vml000070.dmz.nausch.org dovecot[23587]: | ||
+ | Hint: Some lines were ellipsized, use -l to show in full. | ||
+ | </ | ||
+ | |||
+ | ==== Dynamische Empfänger-Verifizierung ==== | ||
+ | <WRAP round info>Im vorgenannten Konfigurationsbeispiel werden für alle Empfänger Nachrichten angenommen, die in der statischen Lookup-Tabelle gelistet ist. Was ist nun aber, wenn das Backend-System wiederum die Annahme einer weitergeleiteten Nachricht verweigert? Richtig, unser Mailserver würde diese als Bounce zurück zum Absender schicken. Dies wollen wir eben sowenig, wie den zusätzlichen Pflegeaufwand für die richtige und aktuelle relay_recipients-Tabelle!< | ||
+ | </ | ||
+ | </ | ||
+ | Den notwendigen Konfigurationseintrag finden wir bereits in der Hauptkonfigurationsdatei von unserem **Postfix 2.11.3** unter **CentOS 7.x**. | ||
+ | # grep verify / | ||
+ | |||
+ | | ||
+ | |||
+ | Postfix wird mit Hilfe des Moduls **verify** versuchen, noch während der Annahme der Bachricht von einem fremden Mailserver, beim Backend-System in Erfahrung zu bringen, ob dieses die Nachricht auch abnehmen würde. Ist dies der Fall, reicht Postfix die Nachricht an das Backend weiter. Anderenfalls wird die Annahme der Nachricht verweigert. Damit nun der Mailserver nicht jedesmal nachfragen muss, werden wir ihm hierzu eine kleine Datenbanktabelle spendieren, die auch nach einen Neustart des Servers zur Verfügung stehen kann. | ||
+ | |||
+ | === Konfiguration === | ||
+ | Als erstes legen wir uns ein Datenverzeichnis, | ||
+ | # mkdir / | ||
+ | |||
+ | # chown postfix.root / | ||
+ | |||
+ | # chmod 700 / | ||
+ | |||
+ | Als nächstes definieren wir noch die entsprechende Datenbank, bzw. den Ort wo Postfix diese Datenbank abspeichern wird. Hierzu tragen wir in die Konfigurationsdatei // | ||
+ | # vim / | ||
+ | |||
+ | <code bash>... | ||
+ | |||
+ | # Django : 2015-10-15 - Ergebnisse der Adress-Verification cachen | ||
+ | # Kapitel 12.2.2 Dynamische Empfänger-Verifizierung | ||
+ | # Kapitel 9.5.5 envelope sender überprüfen | ||
+ | # default: address_verify_map = btree: | ||
+ | address_verify_map = btree:/ | ||
+ | </ | ||
+ | |||
+ | Dann aktivieren wir in der Section **[[centos: | ||
+ | # (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung) | ||
+ | | ||
+ | # vim / | ||
+ | <code bash>################################################################################ | ||
+ | ## SMTP RECIPIENT RESTRICTIONS | ||
+ | # | ||
+ | # Django : 2014-10-29 - Schutz unserer Empfänger mit Hilfe der Recipient | ||
+ | # Restrictions | ||
+ | # default: smtpd_recipient_restrictions = | ||
+ | smtpd_recipient_restrictions = | ||
+ | # Postmaster, abuse und andere aufgaben- oder funktionsgebundene | ||
+ | # eMail-Adressen (Role-Accounts) whitelisten | ||
+ | | ||
+ | |||
+ | # Black- und Whitelisting | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | # Unsere eigenen Nutzer zulassen-/ | ||
+ | # (Kapitel 8.2.2 Relaying erlauben und verbieten) | ||
+ | | ||
+ | | ||
+ | |||
+ | # RBL überprüfen | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | # Greylisting via postgrey checken via Unix-Socket | ||
+ | # (Kapitel 9.2.5 postgrey installieren) | ||
+ | # check_policy_service unix: | ||
+ | |||
+ | # Policyd-Weight check over TCP-Connection | ||
+ | # (Kapitel 9.3 policyd-weight installieren) | ||
+ | # check_client_access btree:/ | ||
+ | # check_policy_service inet: | ||
+ | |||
+ | # Dynamische Prüfung auf existente Relay-Empfänger | ||
+ | # (Kapitel 12.2.2 Dynamische Empfänger-Verifizierung) | ||
+ | | ||
+ | |||
+ | # Backupserver (MX) erlauben | ||
+ | | ||
+ | |||
+ | # alles andere an relaying verbieten | ||
+ | # (Kapitel 8.2.2 Relaying erlauben und verbieten) | ||
+ | | ||
+ | |||
+ | # Quota-Status-Policy-Daemon am Dovecot-Backend-System | ||
+ | # Dovecotbuch (ISBN 978-3-95539-74-7) Seite 219 ff. | ||
+ | # (Kapitel 11.11 "Der Quota-Policy-Server für Postfix" | ||
+ | | ||
+ | |||
+ | # Zu guter Letzt alles durchlassen, | ||
+ | # beanstandet wurde | ||
+ | | ||
+ | </ | ||
+ | |||
+ | |||
+ | === Konfiguration aktivieren === | ||
+ | Zur Aktivierung unserer Konfiguration benutzen wir **systemctl**. | ||
+ | # systemctl reload postfix | ||
+ | |||
+ | Da keine Rückmeldung erfolgte können wir davon ausgehen, dass alle unsere Konfigurationsoptionen unseren Wünschen entsprechend gesetzt wurden. | ||
+ | |||
+ | Wir können aber auch den Status unseres Mailservers abfragen. | ||
+ | # systemctl status postfix | ||
+ | < | ||
+ | | ||
+ | | ||
+ | Process: 3222 ExecStop=/ | ||
+ | Process: 4482 ExecReload=/ | ||
+ | Process: 3236 ExecStart=/ | ||
+ | Process: 3234 ExecStartPre=/ | ||
+ | Process: 3231 ExecStartPre=/ | ||
+ | Main PID: 3309 (master) | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | Nov 04 19:10:44 vml000087.dmz.nausch.org systemd[1]: Reloading Postfix Mail Transport Agent. | ||
+ | Nov 04 19:10:44 vml000087.dmz.nausch.org postfix/ | ||
+ | Nov 04 19:10:44 vml000087.dmz.nausch.org systemd[1]: Reloaded Postfix Mail Transport Agent. | ||
+ | Hint: Some lines were ellipsized, use -l to show in full. | ||
+ | </ | ||
+ | |||
+ | === Datenpflege der Empfangsaddressen === | ||
+ | Die Pflege der verify-Datenbank übernimmt dabei Postfix selbst, trägt neue Adressen ein und löscht auch regelmäßig alte Einträge - kurz und gut, der Postfix betreibt also eine Art // | ||
+ | # postconf address_verify_positive_refresh_time | ||
+ | |||
+ | | ||
+ | |||
+ | Nach Ablauf der sieben Tage wird das verify-Modul eine bereits bekannte und positiv gekennzeichnete eMailadresse erneuit beim Zielserver anfragen und die Aktualität des Datensatzes überprüfen. | ||
+ | |||
+ | # postconf address_verify_positive_expire_time | ||
+ | |||
+ | | ||
+ | |||
+ | Erst nach Ablauf von 31 Tagen wird eine bekannte und positive Adresse aus der Datenbank entfernt. Da aber bereits nach 7 Tagen eine Überprüfung der Adresse stattfindet, | ||
+ | |||
+ | # postconf address_verify_negative_refresh_time | ||
+ | |||
+ | | ||
+ | |||
+ | Nach drei Stunden wird das verify-Modul eine noch nicht existente gecachte Empfänger-Adresse beim Zielserver erneut anfragen. | ||
+ | |||
+ | # postconf address_verify_negative_expire_time | ||
+ | |||
+ | | ||
+ | |||
+ | Nicht existierende Empfängeradressen werden maximal drei Tage vorgehalten und dann gelöscht. | ||
+ | |||
+ | # postconf address_verify_sender | ||
+ | |||
+ | | ||
+ | |||
+ | # postconf double_bounce_sender | ||
+ | |||
+ | | ||
+ | |||
+ | Dieser Parameter legt fest, mit welchem // | ||
+ | |||
+ | ===== Tests ===== | ||
+ | <WRAP round important> | ||
+ | ==== Einlieferung via LMTP beim backend-System ==== | ||
+ | Als erstes testen wir, ob wir von unserem SMTP-Server aus beim IMAP-Server auf Port 24 (**LMTP**) eine Nachricht einliefern können. Damit wir uns beim Tippen nicht die Finger brechen und/oder vertippen, greifen wir auf das Hilfsprogramm **[[http:// | ||
+ | # swaks --to django@nausch.org --from michael@nausch.org --header-X-Test "test email" --server 10.0.0.77 --protocol LMTP | ||
+ | < | ||
+ | === Connected to 10.0.0.77. | ||
+ | <- 220 imap.nausch.org Dovecot ready. | ||
+ | -> LHLO vml000087.dmz.nausch.org | ||
+ | <- 250-imap.nausch.org | ||
+ | <- 250-8BITMIME | ||
+ | <- 250-ENHANCEDSTATUSCODES | ||
+ | <- 250 PIPELINING | ||
+ | -> MAIL FROM:< | ||
+ | <- 250 2.1.0 OK | ||
+ | -> RCPT TO:< | ||
+ | <- 250 2.1.5 OK | ||
+ | -> DATA | ||
+ | <- 354 OK | ||
+ | -> Date: Tue, 04 Nov 2014 19:17:15 +0100 | ||
+ | -> To: django@nausch.org | ||
+ | -> From: michael@nausch.org | ||
+ | -> Subject: test Tue, 04 Nov 2014 19:17:15 +0100 | ||
+ | -> X-Mailer: swaks v20130209.0 jetmore.org/ | ||
+ | -> X-Test: test email | ||
+ | | ||
+ | -> This is a test mailing | ||
+ | | ||
+ | -> . | ||
+ | <- 250 2.0.0 < | ||
+ | -> QUIT | ||
+ | <- 221 2.0.0 OK | ||
+ | === Connection closed with remote host. | ||
+ | </ | ||
+ | |||
+ | Im Maillog des empfangendem System wird die erfolgreiche Zustellung entsprechend protokolliert. | ||
+ | < | ||
+ | Nov 4 19:17:15 vml000077 dovecot: lmtp(django@nausch.org): | ||
+ | Nov 4 19:17:15 vml000077 dovecot: lmtp(django@nausch.org): | ||
+ | Nov 4 19:17:15 vml000077 dovecot: lmtp(6588): Disconnect from 10.0.0.87: Successful quit | ||
+ | </ | ||
+ | |||
+ | ==== erfolgreiche Einlieferung via SMTP beim frontend-System ==== | ||
+ | Als nächstes liefern wir eine Nachricht bei unserem SMTP-Server auf Port **25** ein. Auch hier benutzen wir als Hilfsmittel **swaks**. | ||
+ | # swaks --to django@nausch.org --from michael@nausch.org --header-X-Test "test email" --server 10.0.0.87 --protocol SMTP | ||
+ | < | ||
+ | === Connected to 10.0.0.87. | ||
+ | <- 220 mx01.nausch.org ESMTP Postfix | ||
+ | -> HELO pml010048 | ||
+ | <- 250 mx01.nausch.org | ||
+ | -> MAIL FROM:< | ||
+ | <- 250 2.1.0 Ok | ||
+ | -> RCPT TO:< | ||
+ | <- 250 2.1.5 Ok | ||
+ | -> DATA | ||
+ | <- 354 End data with < | ||
+ | -> Date: Tue, 04 Nov 2014 20:53:54 +0100 | ||
+ | -> To: django@nausch.org | ||
+ | -> From: michael@nausch.org | ||
+ | -> Subject: test Tue, 04 Nov 2014 20:53:54 +0100 | ||
+ | -> X-Mailer: swaks v20130209.0 jetmore.org/ | ||
+ | -> X-Test: test email | ||
+ | | ||
+ | -> This is a test mailing | ||
+ | | ||
+ | -> . | ||
+ | <- 250 2.0.0 Ok: queued as 904BBC00088 | ||
+ | -> QUIT | ||
+ | <- 221 2.0.0 Bye | ||
+ | === Connection closed with remote host. | ||
+ | </ | ||
+ | Im Maillog werden nun mehrere Dinge dokumentiert. | ||
+ | |||
+ | | ||
+ | Der Client **vml000020.dmz.nausch.org** mit der IP **10.0.0.20** hat sich mit dem SMTP-Server verbunden. | ||
+ | | ||
+ | Das Cleanup-Modul hat die Message-ID **< | ||
+ | | ||
+ | | ||
+ | | ||
+ | Der verify-Daemon erstellt eine Test-Nachricht und schickt diese an den Zielserver. Da die Adresse zustellbar ** status=deliverable (250 2.1.5 ok)** ist, entfernt der Queue-Manager die Testnachricht wieder. | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | Die Nachricht wird dem einliefernden Mailclient abgenommen. | ||
+ | | ||
+ | | ||
+ | Die Nachricht wurde erfolgreich an das backend-System übergeben. | ||
+ | |||
+ | ==== Zustellversuch an nicht existierenden Empfänger via SMTP beim frontend-System ==== | ||
+ | Als nächstes versuchen wir eine Nachricht an einen nicht existierenden Empfänger zu schicken. | ||
+ | $ swaks --to paeddrigg@nausch.org --from michael@nausch.org --header-X-Test "test email" --server 10.0.0.87 --protocol SMTP | ||
+ | < | ||
+ | === Connected to 10.0.0.87. | ||
+ | <- 220 mx01.nausch.org ESMTP Postfix | ||
+ | -> HELO pml010048 | ||
+ | <- 250 mx01.nausch.org | ||
+ | -> MAIL FROM:< | ||
+ | <- 250 2.1.0 Ok | ||
+ | -> RCPT TO:< | ||
+ | <** 450 4.1.1 < | ||
+ | -> QUIT | ||
+ | <- 221 2.0.0 Bye | ||
+ | === Connection closed with remote host. | ||
+ | </ | ||
+ | Die Annahme der Nachricht wurde verweigert, da die Adresse nicht überprüft werden konnte. | ||
+ | Im Maillog sieht man nun sehr schön wieder den Versuch die Adresse zu überprüfen. | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | Hier wurde nun der Status **status=undeliverable** gemeldet, da der Empfänger nicht erreichbar war. | ||
+ | ==== verify-Datenbank ==== | ||
+ | Werfen wir nun einen Blick in die verify-Datenbank von Postfix können wir für beide Beispiele die entsprechenden Einträge finden. | ||
+ | # postmap -s btree:/ | ||
+ | | ||
+ | | ||
+ | | ||
+ | ====== Links ====== | ||
+ | * **⇐ [[centos: | ||
+ | * **⇒ [[centos: | ||
+ | * **[[centos: | ||
+ | * **[[wiki: | ||
+ | * **[[http:// | ||
- | FIXME | ||