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)