Rat zu scheinbar komplexerer Mailserver - Firewall - DNS Problematik (MX)
Hallo,
es gelingt mir leider nicht unseren externen Firewall-Experten und unseren DNS/Domänenprovider 1und1 gemeinsam dazu zu kriegen, das die Mailserver-MX-Auflösung so tut wie sie soll.
Was passiert: die MX-Auflösung von draussen auf unsere Mailadresse remote.firma.de löst nicht richtig auf, was bestimmte Clients zum Ablehnen der Mails veranlasst (z.B. Off.365).
Wie war der Status:
bis zur Aktivierung der neuen Sophos UTM125 hat unser Exchange über die frühere Fritzbox brav seine Mails auf den Smarthost 1und1 abgegeben, dort wurden die von 1und1 verschickt.
Unsere Hauptdomäne firma.de hatte bei 1und1 in deren DNS-Verwaltung einen MX mit höchster Prio auf remote.firma.de sowie weitere niedriger priorisierte MXe auf z.B. MX00.kundenserver.de.
Das sah in etwa so aus für "firma.de":
MX @ remote.firma.de - Prio 10
MX @ mx00.kundenserver.de - Prio 20
MX @ mx01.kundenserver.de - Prio 30
A remote unsere-IP -
Dann gab es die Subdomäne 'remote.firma.de' mit folgenden Einträgen:
A remote unsere-IP -
MX remote mx00.kundenserver.de - Prio 20
MX remote mx01.kundenserver.de - Prio 30
Alles lief, es gab keine sichtbaren Probleme.
Nun ist die Sophos dazugekommen als Smarthost für den Exchange und hängt zwischen Mailserver und Internet (nun SIP-Trunk ohne Fritzbox). Die Mails soll sie direkt verschicken ohne 1und1, soweit klar.
Aber: wenn nun z.B. MXTOOLBOX "remote.firma.de" MX-mäßig auflösen soll, kommt 'mx00.kundenserver.de' zurück - was die Antspam-Engines der Empfänger aktiviert, da die "remote.firma.de" erwarten.
MXTOOLBOX liefert dafür bei 'firma.de' für MX 'remote.firma.de'.
Was tue ich in meiner Not bis dato: ich lasse die Sophos die Mails beim 'Smarthost' 1und1 abgeben; das kann's aber nicht dauerhaft sein.
Habe nun am Strohhalm hängend all die mx00/1.kundenserver.de's in der DNS von 1und1 rausgeworfen und interessanterweise funktioniert die Mailzustellung immer noch, wenngleich ich nicht weiß warum.
Kann mir jemand einen Hinweis geben was da strubbelig ist? Meine beiden ext. Partner verweisen auf ihre Unschuld...
Danke Euch!
es gelingt mir leider nicht unseren externen Firewall-Experten und unseren DNS/Domänenprovider 1und1 gemeinsam dazu zu kriegen, das die Mailserver-MX-Auflösung so tut wie sie soll.
Was passiert: die MX-Auflösung von draussen auf unsere Mailadresse remote.firma.de löst nicht richtig auf, was bestimmte Clients zum Ablehnen der Mails veranlasst (z.B. Off.365).
Wie war der Status:
bis zur Aktivierung der neuen Sophos UTM125 hat unser Exchange über die frühere Fritzbox brav seine Mails auf den Smarthost 1und1 abgegeben, dort wurden die von 1und1 verschickt.
Unsere Hauptdomäne firma.de hatte bei 1und1 in deren DNS-Verwaltung einen MX mit höchster Prio auf remote.firma.de sowie weitere niedriger priorisierte MXe auf z.B. MX00.kundenserver.de.
Das sah in etwa so aus für "firma.de":
MX @ remote.firma.de - Prio 10
MX @ mx00.kundenserver.de - Prio 20
MX @ mx01.kundenserver.de - Prio 30
A remote unsere-IP -
Dann gab es die Subdomäne 'remote.firma.de' mit folgenden Einträgen:
A remote unsere-IP -
MX remote mx00.kundenserver.de - Prio 20
MX remote mx01.kundenserver.de - Prio 30
Alles lief, es gab keine sichtbaren Probleme.
Nun ist die Sophos dazugekommen als Smarthost für den Exchange und hängt zwischen Mailserver und Internet (nun SIP-Trunk ohne Fritzbox). Die Mails soll sie direkt verschicken ohne 1und1, soweit klar.
Aber: wenn nun z.B. MXTOOLBOX "remote.firma.de" MX-mäßig auflösen soll, kommt 'mx00.kundenserver.de' zurück - was die Antspam-Engines der Empfänger aktiviert, da die "remote.firma.de" erwarten.
MXTOOLBOX liefert dafür bei 'firma.de' für MX 'remote.firma.de'.
Was tue ich in meiner Not bis dato: ich lasse die Sophos die Mails beim 'Smarthost' 1und1 abgeben; das kann's aber nicht dauerhaft sein.
Habe nun am Strohhalm hängend all die mx00/1.kundenserver.de's in der DNS von 1und1 rausgeworfen und interessanterweise funktioniert die Mailzustellung immer noch, wenngleich ich nicht weiß warum.
Kann mir jemand einen Hinweis geben was da strubbelig ist? Meine beiden ext. Partner verweisen auf ihre Unschuld...
Danke Euch!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 399271
Url: https://administrator.de/forum/rat-zu-scheinbar-komplexerer-mailserver-firewall-dns-problematik-mx-399271.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
10 Kommentare
Neuester Kommentar
Dann gab es die Subdomäne 'remote.firma.de' mit folgenden Einträgen:
A remote unsere-IP -
MX remote mx00.kundenserver.de - Prio 20
MX remote mx01.kundenserver.de - Prio 30
A remote unsere-IP -
MX remote mx00.kundenserver.de - Prio 20
MX remote mx01.kundenserver.de - Prio 30
Sollte da nicht noch ein
MX remote <eureip> - Prio 10
Manuel
von draussen auf unsere Mailadresse remote.firma.de
Komisch. Normale ITler verwenden dafür auch mail.firma.de oder email.firma.de Einen Mail Server "remote" zu nennen ist schon skurril. Aber im Endeffekt kannst du ihn auch "horst" oder "willi" nennen, das ist nicht der Punkt.Der Punkt ist wenn sie extern schon nicht richtig auflöst dann liegt es primär logischerweise erstmal NICHT an der Firewall, denn die hat damit nichts zu tun sondern am Provider DNS der ja euren MX Eintrag hält.
Hier sollte man also mit nslookup oder dig erstmal sehen das das sauber funktioniert bevor man weitermacht.
1u1 ist da also der Buhmann bzw. der der dort eure MX Einträge verwaltet !
Hallo,
das ist doch aber auch klar.
der MX eintrag für "remote.firma.de" darf doch auch nicht interessieren, wird aber korrekt ausgegeben gemäß deinen Einstellungen.
Du musst erst mal den MX für "firma.de" von MXTOOLBOX überprüfen lassen.
Und dann geleich mal die ersten Frage, nen Reverse DNS Eintrag setzten lassen?
das ist doch aber auch klar.
der MX eintrag für "remote.firma.de" darf doch auch nicht interessieren, wird aber korrekt ausgegeben gemäß deinen Einstellungen.
Du musst erst mal den MX für "firma.de" von MXTOOLBOX überprüfen lassen.
Und dann geleich mal die ersten Frage, nen Reverse DNS Eintrag setzten lassen?
Zitat von @mabies:
ja, der MX für "firma.de" liefert "remote.firma.de".
Der MX für "remote.firma.de" liefert aber mx00.kundenserver.de zurück.
nslookup aus dem Firmennetz heraus bringt nur DNS-Timeouts.
Und ja, RDNS ist bei Telekom als IP-Vergeber mit remote.firma.de gesetzt.
Und nochmal ja, der Name ist skurril, hat aber mit Migrationen aus der Vergangenheit zu tun und wurde irgendwie nie angepackt. Willi wäre auch nett.
ja, der MX für "firma.de" liefert "remote.firma.de".
Der MX für "remote.firma.de" liefert aber mx00.kundenserver.de zurück.
nslookup aus dem Firmennetz heraus bringt nur DNS-Timeouts.
Und ja, RDNS ist bei Telekom als IP-Vergeber mit remote.firma.de gesetzt.
Und nochmal ja, der Name ist skurril, hat aber mit Migrationen aus der Vergangenheit zu tun und wurde irgendwie nie angepackt. Willi wäre auch nett.
Mal egal ober der Name skurril ist. Was interessiert der MX eintrag für die Domain "remote.firma.de" ? Dieser kommt doch nicht zum Tragen.
Die für dich wichtige Domain ist doch "firma.de" und der MX Eintrag dafür. Deswegen funktioniert doch auch die Zustellung. Das diese teilweise abgelehnt werden ist ein anderer Grund.
Klar du könntest auch die Subdomain löschen und einen normalen A Record für den host "remote" und deine IP machen. Früher ging das bei 1und1 nicht. Kommt aber unterm strich auf's selbe raus und wird dein Problem nicht lösen.
Edit: Sorry ein Kleiner Fehler. Das die Zustellung geht ist ne andere Thematik. Der MX Eintrag wird ja nur dafür benötigt das du E-Mails Empfangen kannst. Zum Versenden spielt er erst mal keine Rolle, abgesehen von der E-Mail Filterung. Und hier ist ja deine Sende Domain "firma.de" der Zugehörige MX Eintrag "remote.firma.de" die IP wird dann über den A Record dieser Subdomain aufgelöst und muss der IP des Mailserver's von dir Entsprechen, sonst könntest du auch nicht empfangen.
Und warum wussten das weder 1und1 noch der Firewaller ?
1. Ist das klassisch, dass Massenwebhoster meist erst in L3 (zu denen man kaum bis nie kommt) Bescheid wissen (ist auch nicht deren Business).
2. Schlecht bzw zu sehr nach Kostenfaktor ausgewählt? Offensichtlich mangelt es an Basisnetzwerkwissen.
Korrekt
VG