Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
centos:mail_c6:mta_4 [04.06.2012 14:39. ] – angelegt django | centos:mail_c6:mta_4 [28.06.2015 12:56. ] – [relay_recipient_maps-Tabelle] django | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ====== Anbindung an einem Backend-Mailserver (Cyrus-IMAP-Server) ====== | ||
+ | In der Regel werden wir hinter unserem eigentlichen Mailserver ein Backend System bereithalten, | ||
+ | Hier kommt es nun im Detail darauf an, auf welchen Hosts unser Postfix-SMTP-Server und wo der Cyrus-IMAP-Server betrieben wird. | ||
+ | |||
+ | ===== MTA und MDA auf gleichem Host ===== | ||
+ | Als erstes betrachten wir den ganzen Konfogurationsaufwand, | ||
+ | |||
+ | ==== master.conf ==== | ||
+ | In der // | ||
+ | # vim / | ||
+ | <code bash>... | ||
+ | # Django : 2009-02-07 Aktiviert für MDA-Support cyrus aktiviert | ||
+ | # Cyrus 2.1.5 (Amos Gouaux) | ||
+ | # Also specify in main.cf: cyrus_destination_recipient_limit=1 | ||
+ | cyrus | ||
+ | user=cyrus argv=/ | ||
+ | ... | ||
+ | </ | ||
+ | ==== main.cf ==== | ||
+ | In der // | ||
+ | # vim / | ||
+ | < | ||
+ | # Django : 2009-02-07 Aktiviert für MDA-Support cyrus aktiviert | ||
+ | mailbox_transport = cyrus | ||
+ | cyrus_destination_recipient_limit=1 | ||
+ | ... | ||
+ | </ | ||
+ | |||
+ | |||
+ | ===== MTA und MDA auf getrennten Hosts ===== | ||
+ | Laufen die beiden Mailserverkomponenten auf getrennten Hosts, so ist der nötige Konfigurationsaufwand geringfügig größer. Nachfolgend gehen wir nun auf diese Details genauer ein. | ||
+ | |||
+ | ==== main.cf ==== | ||
+ | Für die individuelle Weiterleitung unserer Nachrichten benutzen wir die beiden Lookup-Tabellen: | ||
+ | - **transport_maps** | ||
+ | - **relay_domains** | ||
+ | Im ersten Schritt erweitern wir nun unsere Postfix-Konfigurationsdatei um folgende Zeilen. Hierzu nutzen wir wie immer den Editor unserer Wahl, so z.B. **vim**. | ||
+ | # vim / | ||
+ | <code bash># Django : 2012-02-06 | ||
+ | # Zur Weitergabe der angenommenen Nachrichten an das backend-System (Cyrus-IMAP-Server) verwenden wir | ||
+ | # eine separate Tabelle zur individuellen Weiterleitung. | ||
+ | relay_domains = btree:/ | ||
+ | |||
+ | # Lookup-Tabelle zum Aktivieren einer alternativen Mailrouting bei der Zustellung an einen weiteren Mailserver | ||
+ | transport_maps = btree:/ | ||
+ | </ | ||
+ | |||
+ | Die gerade definierten Lookup-Tabellen legen wir nun als nächstes an. | ||
+ | - **transport_maps**: | ||
+ | # 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 | ||
+ | # die zugehörige Datenbank erzeugt werden. | ||
+ | # | ||
+ | # Alle eMails, die an Subdomains von nausch.org gerichtet sind (" | ||
+ | # werden an den/die Mailserver von intra.nausch.org (MX-Records) weitergeleitet. (keine " | ||
+ | # | ||
+ | |||
+ | # Mails an backup.nausch.org werden an den Mailserver (A-Record) auf Port 25 mit Namen mail.intra.nausch.org geschickt. | ||
+ | # | ||
+ | </ | ||
+ | - **relay_domains**: | ||
+ | # Lookup-Tabelle zur Definition der Domänen, für die unser Mailserver Nachricht annehmen soll. | ||
+ | # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels | ||
+ | # die zugehörige Datenbank erzeugt werden. | ||
+ | # | ||
+ | # Relevant ist erst eimal nur die erste Spalte. Die zweite Spalte dient nur zum Erhalten der Tabellenstruktur und | ||
+ | # kann daher z.B. als Hinweisfled zum Dokumentieren verwendet werden. | ||
+ | # Beispiel: | ||
+ | # omni128.de | ||
+ | - **transport_maps __UND__ relay_domains**: | ||
+ | # Lookup-Tabelle zur Definition der Domänenm für die unser Mailserver Nachricht annehmen soll. | ||
+ | # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels | ||
+ | # die zugehörige Datenbank erzeugt werden. | ||
+ | # | ||
+ | # Relevanz ost erst eimal nur die erste Spalte. Die zweite Spalte dient nur zum Erhalten der Tabellenstruktur und | ||
+ | # kann daher z.B. als Hinweisfled zum Dokumentieren verwendet werden. | ||
+ | # Beispiel: | ||
+ | # omni128.de | ||
+ | # | ||
+ | # Da für jede Domäne auch ein Transportweg definiert werden muss, erledigen wir die Definition des selbigen gleich | ||
+ | # hier in dieser Tabelle, in dem wir die Spalte zwei hierzu verwenden. | ||
+ | nausch.org | ||
+ | omni128.de | ||
+ | wetterstation-pliening.info | ||
+ | ebersberger-liedersammlung.de | ||
+ | |||
+ | ==== master.conf ==== | ||
+ | In der // | ||
+ | # vim / | ||
+ | <code bash>... | ||
+ | local | ||
+ | ... | ||
+ | </ | ||
+ | |||
+ | ===== Überprüfung der Empfängeradressen auf dem Mailrelay ===== | ||
+ | ==== relay_recipient_maps-Tabelle ==== | ||
+ | Für die Entscheidung, | ||
+ | In der Konfigurationsdatei unseres Postfix-Mailservers ist hierzu ein entsprechender Eintrag bereits vorbereitet. | ||
+ | # vim / | ||
+ | <code bash># REJECTING UNKNOWN RELAY USERS | ||
+ | # | ||
+ | # The relay_recipient_maps parameter specifies optional lookup tables | ||
+ | # with all addresses in the domains that match $relay_domains. | ||
+ | # | ||
+ | # If this parameter is defined, then the SMTP server will reject | ||
+ | # mail for unknown relay users. This feature is off by default. | ||
+ | # | ||
+ | # The right-hand side of the lookup tables is conveniently ignored. | ||
+ | # In the left-hand side, specify an @domain.tld wild-card, or specify | ||
+ | # a user@domain.tld address. | ||
+ | # | ||
+ | relay_recipient_maps = hash:/ | ||
+ | </ | ||
+ | Die letzte Zeile aktivieren wir bei Bedarf einfach und legen uns in einem weiteren Schritt die zugehörige Tabelle an. | ||
+ | # vim / | ||
+ | In dieser lookup-Tabelle ist es nun nur wichtig, daß eine Adresse gelistet ist. Die zweite Spalte ist also hier nur zum Erhalt der Tabellenstruktur notwendig uns kann somit z.B als Bemerkungsfeld genutzte werden. | ||
+ | <file bash / | ||
+ | # Kapitel 12.2.1 Statische Empfängerlisten | ||
+ | # Lookup-Tabelle zur Definition der Empfänger, für die unser Mailserver Nachricht annehmen soll. | ||
+ | # Nach dem Ändern und/oder Erweitern der Tabelle, muß noch mittels | ||
+ | # die zugehörige Datenbank erzeugt werden. | ||
+ | # | ||
+ | # Relevant ist erst eimal nur die erste Spalte. Die zweite Spalte dient nur zum Erhalten der Tabellenstruktur und | ||
+ | # kann daher z.B. als Hinweisfled zum Dokumentieren verwendet werden. | ||
+ | # Beispiel: | ||
+ | bigchief@omni128.de | ||
+ | swat@nausch.org | ||
+ | </ | ||
+ | ==== 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 Konfogurationseintrag finden wir bereits in der Hauptkonfigurationsdatei von unserem **Postfix 2.6.6** unter **CentOS 6.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. | ||
+ | Als erstes legen wir nun das entsprechende Verzeichnis an und schenke es dem Nutzer Postfix. | ||
+ | # 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 **main.cf** folgenden Eintrag nach. | ||
+ | # vim / | ||
+ | |||
+ | <code bash># Postfix-eigene verify-Datenbank für die dynamische | ||
+ | # Empfänger-Überprüfung nutzen | ||
+ | address_verify_map = btree:/ | ||
+ | </ | ||
+ | |||
+ | Ferner aktivieren wir nich den in der [[centos: | ||
+ | <code bash># | ||
+ | # Django : 2012-02-06 | ||
+ | # Schutz durch Restrictions für unser SOHO | ||
+ | # | ||
+ | |||
+ | smtpd_recipient_restrictions = | ||
+ | # Postmaster, abuse und andere aufgaben- oder funktionsgebundene E-Mail-Adressen (Role-Accounts) whitelisten | ||
+ | check_recipient_access btree:/ | ||
+ | # Black- und Whitelisting | ||
+ | check_client_access cidr:/ | ||
+ | check_helo_access btree:/ | ||
+ | check_sender_access btree:/ | ||
+ | check_recipient_access btree:/ | ||
+ | # Unsauberer eMails nicht annehmen | ||
+ | reject_non_fqdn_sender, | ||
+ | reject_non_fqdn_recipient, | ||
+ | reject_unknown_sender_domain, | ||
+ | reject_unknown_recipient_domain, | ||
+ | # Unsere eigenen Nutzer zulassen-/ | ||
+ | permit_sasl_authenticated, | ||
+ | permit_mynetworks, | ||
+ | # RBL überprüfen (Kapitel 10.11 Realtime Blackhole Lists) | ||
+ | reject_rbl_client zen.spamhaus.org, | ||
+ | reject_rbl_client ix.dnsbl.manitu.net, | ||
+ | reject_rbl_client bl.spamcop.net, | ||
+ | reject_rbl_client dnsbl.njabl.org, | ||
+ | reject_rhsbl_client multi.uribl.com, | ||
+ | # Dynamische Prüfung auf existente Relay-Empfänger | ||
+ | reject_unverified_recipient, | ||
+ | # Backupserver (MX) erlauben | ||
+ | # | ||
+ | # alles andere an relaying verbieten | ||
+ | reject_unauth_destination, | ||
+ | # Zu guter Letzt alles durchlassen, | ||
+ | permit | ||
+ | </ | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | <WRAP round alert> | ||
+ | # tail -f / | ||
+ | < | ||
+ | Jun 4 22:11:20 vml000080 postfix/ | ||
+ | Jun 4 22:12:06 vml000080 postfix/ | ||
+ | Jun 4 22:12:06 vml000080 postfix/ | ||
+ | Jun 4 22:12:06 vml000080 postfix/ | ||
+ | Jun 4 22:12:06 vml000080 postfix/ | ||
+ | Jun 4 22:12:09 vml000080 postfix/ | ||
+ | Jun 4 22:12:17 vml000080 postfix/ | ||
+ | ... | ||
+ | </ | ||
+ | Das Beispiel zeigt einen erfolgreichen Überprüfungsversuch // **status=deliverable (250 2.1.5 ok)** // ). | ||
+ | |||
+ | Wir im Gegensatz versucht an einen nicht existierenden Empfänger eine Nachricht zuzustellen, | ||
+ | < | ||
+ | Jun 4 22:26:07 vml000080 postfix/ | ||
+ | Jun 4 22:26:37 vml000080 postfix/ | ||
+ | Jun 4 22:26:38 vml000080 postfix/ | ||
+ | Jun 4 22:26:38 vml000080 postfix/ | ||
+ | Jun 4 22:26:38 vml000080 postfix/ | ||
+ | Jun 4 22:26:40 vml000080 postfix/ | ||
+ | Jun 4 22:26:49 vml000080 postfix/ | ||
+ | ... | ||
+ | </ | ||
+ | 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:/ | ||
+ | <code bash> | ||
+ | peer.heinlein@nausch.org 2: | ||
+ | </ | ||
+ | ====== Links ====== | ||
+ | * **[[centos: | ||
+ | * **[[wiki: | ||
+ | * **[[http:// | ||
+ | |||
+ | ~~DISCUSSION~~ |