Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
centos:mail_c6:mta_2 [18.05.2012 12:02. ]
django [MXer mit unterschiedlichen Prioritäten]
centos:mail_c6:mta_2 [20.04.2018 10:43. ] (aktuell)
Zeile 1: Zeile 1:
 +====== DNS Einstellungen ======
 +Für den ordnungsgemäßen Betrieb unseres Mailservers ist es natürlich unabdingbar, dass unser Nameserver richtig konfiguriert wurde und saubere Rückmeldungen liefert. Vor allem mit Hinblick auf die Teilnahme am eMailverkehr mit anderen Mailservern ist hierbei gesondert zu achten!
 +===== DNS "MX-Beispiele" =====
 +Für den erfolgreichen Mailserverbetrieb müssen wir nun ein paar wichtige DNS-Konfigurationen vornehmen.
 +==== Zwei gleichberechtigte MXer ====
 +Nehmen wir mal als Beispiel die Domäne **omni128.de**. Dort haben wir zwei gleichberechtigte Mailserver stehen:
 +<code>$ dig omni128.de MX
 +
 +; <<>> DiG 9.3.4-P1 <<>> omni128.de MX
 +;; global options:  printcmd
 +;; Got answer:
 +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3017
 +;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 10
 +
 +;; QUESTION SECTION:
 +;omni128.de.                    IN      MX
 +
 +;; ANSWER SECTION:
 +omni128.de.             81640   IN      MX      10 mx01.schlund.de.
 +omni128.de.             81640   IN      MX      10 mx00.schlund.de.</code>
 +Beide Mailserver haben die Priorität **10** und werden daher im round-robin Betrieb angesprochen.
 +==== MXer mit unterschiedlichen Prioritäten ====
 +Im Gegensatz dazu haben wir bei **tachtler.net** zwei Mailserver mit unterschiedlicher Priorität:
 +   $ dig tachtler.net MX
 +<code>
 +; <<>> DiG 9.3.4-P1 <<>> tachtler.net MX
 +;; global options:  printcmd
 +;; Got answer:
 +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4317
 +;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
 +
 +;; QUESTION SECTION:
 +;tachtler.net.                  IN      MX
 +
 +;; ANSWER SECTION:
 +tachtler.net.           3600    IN      MX      10 mx00.udag.de.
 +tachtler.net.           3600    IN      MX      20 mx01.udag.de.
 +</code>
 +
 +Als erstes wird immer der **mx00** angesprochen und sollte dieser nicht reagieren, dann der Backupmailserver **mx01**
 +
 +==== MX als Cluster-/Einzelserverbetrieb ====
 +Im Gegensatz zu den beiden vorgenannten Varianten gibt es noch eine weitere dritte Option. Wie kucken uns dazu mal die Konstellation bei den //Lokalisten// an.
 +   $ dig lokalisten.de MX
 +<code>
 +; <<>> DiG 9.3.4-P1 <<>> lokalisten.de MX
 +;; global options:  printcmd
 +;; Got answer:
 +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53167
 +;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 7
 +
 +;; QUESTION SECTION:
 +;lokalisten.de.                 IN      MX
 +
 +;; ANSWER SECTION:
 +lokalisten.de.          295     IN      MX      10 smtp.lokalisten.de.
 +</code>
 +
 +Ob hier nun ein cluster oder "nur" ein Mailserver im Einsatz ist, kann man so nicht ermitteln.
 +===== DNS-Konfiguration für nausch.org =====
 +Gemäß unserer Konfiguration setzen wir nun für den Postfix-Mailserver **mx1.nausch.org** den DNS-Eintrag.
 +==== DNS Forward Auflösung ====
 +   $ dig @212.18.0.5 nausch.org MX
 +<code>; <<>> DiG 9.3.4-P1 <<>> @212.18.0.5 nausch.org MX
 +; (1 server found)
 +;; global options:  printcmd
 +;; Got answer:
 +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54013
 +;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
 +
 +;; QUESTION SECTION:
 +;nausch.org.                    IN      MX
 +
 +;; ANSWER SECTION:
 +nausch.org.             78155   IN      MX      10 mx1.nausch.org.</code>
 +Somit ist unser Mailserver schon mal für den ankommenden gewappnet.
 +
 +Betreiben wir unterschiedliche Zonen/Netzsegmente, so weisen wir diesen entsprechende MailGateWays zu. So können wir später auch recht einfach die oben genannten Möglichkeiten zur Lastverteilung und/oder Backupvarianten beim Verkehsfluss unserer eMails nutzen.
 +  * Beispiel **DMZ**: <code> $ nslookup -querytype=MX dmz.nausch.org</code> <code>Server:         10.10.0.120
 +Address:        10.10.0.120#53
 +
 +dmz.nausch.org  mail exchanger = 10 vml000080.dmz.nausch.org.</code>
 +  * Beispiel **Intranet**: <code> $ nslookup -querytype=MX intra.nausch.org</code> <code>Server:         10.20.0.120
 +Address:        10.20.0.120#53
 +
 +intra.nausch.org        mail exchanger = 10 pml000080.intra.nausch.org.</code>
 +   
 +==== DNS Forward Auflösung mit Backupmailserver====
 +   $ dig @212.18.0.5 nausch.org MX
 +<code>; <<>> DiG 9.2.4 <<>> @212.18.0.5 nausch.org MX
 +; (1 server found)
 +;; global options:  printcmd
 +;; Got answer:
 +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29032
 +;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
 +
 +;; QUESTION SECTION:
 +;nausch.org.                    IN      MX
 +
 +;; ANSWER SECTION:
 +nausch.org.             86400   IN      MX      20 mx1.tachtler.net.
 +nausch.org.             86400   IN      MX      10 mx1.nausch.org.
 +</code>
 +
 +Unsere Domäne **nausch.org** hat also nun zwei Mail-Exchanger, einen Hauptserver mit der höheren Priorität 10 und einen Bachup-Mailserver mit der Prio 20.
 +
 +==== DNS Reverse Auflösung ====
 +Da unser Mailserver auch direkt Mitteilung an andere Mailserver absetzen soll, müssen wir nun darauf achten, dass die reverse-Auflösung unserer Mailserver-IP-Adresse auf den richtigen Namne zurückverweist.
 +   $ dig -x 88.217.187.21
 +<code>
 +; <<>> DiG 9.3.4-P1 <<>> -x 88.217.187.21
 +;; global options:  printcmd
 +;; Got answer:
 +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7274
 +;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6
 +
 +;; QUESTION SECTION:
 +;21.187.217.88.in-addr.arpa.    IN      PTR
 +
 +;; ANSWER SECTION:
 +21.187.217.88.in-addr.arpa. 7200 IN     PTR     mx1.nausch.org.
 +</code>
 +
 +Andererseits würden wir nämlich mit sehr sehr hoher Wahrscheinlichkeit extreme Schwierigkeiten haben, wenn wir bei anderen Mailserver Post abliefern wollten, die SPAM-Abwehr-Mechanismen, wie z.B. **greylisting** oder ähnliches einsetzen.
 +
 +Nachfolgendes Beispiel eine Reverse-Auflösungen, wären demnach zum Scheitern verurteilt und sollten, wie bereits angesprochen, tunlichst vermieden werden!
 +   $ dig -x 88.217.83.134
 +<code>
 +; <<>> DiG 9.3.4-P1 <<>> -x 88.217.83.134
 +;; global options:  printcmd
 +;; Got answer:
 +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15144
 +;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 6
 +
 +;; QUESTION SECTION:
 +;134.83.217.88.in-addr.arpa.    IN      PTR
 +
 +;; ANSWER SECTION:
 +134.83.217.88.in-addr.arpa. 7200 IN     PTR     ppp-88-217-83-134.dynamic.mnet-online.de.
 +</code>
 +====== Links ======
 +  * **[[centos:mail_c6:start|Zurück zum Kapitel >>Mailserverinstallation unter CentOS 6<<]]**
 +  * **[[wiki:start|Zurück zu >>Projekte und Themenkapitel<<]]**
 +  * **[[http://dokuwiki.nausch.org/doku.php/|Zurück zur Startseite]]**
 +
  
  • centos/mail_c6/mta_2.txt
  • Zuletzt geändert: 20.04.2018 10:43.
  • (Externe Bearbeitung)