Smarthost-Problematik

[JeWe]

Hi,

wir setzen NSP in der aktuellen Version 15.5 ein. Der Server mit der GW-Rolle ist im Exchange 2019 (on Premise) als Smarthost eingetragen, um Mails zu versenden. Passt soweit. Jetzt haben wir allerdings das Problem, dass einige Mails nicht mehr angenommen werden, weil unsere Sender-IP gleichzeitig die Router-IP ist, mit der wir ins Internet gehen und diese IP mit einem anderen Namen aufgelöst wird. T-Online blockt uns pauschal (Bad / None reputation), bei anderen fallen wir durch die Prüfung. Und wir haben natürlich jahrelang die Mails über dieselbe IP verschickt. Das T-Online-Problem lässt sich scheinbar mit einer Mail an tobr@rx.t-online.de lösen. Verschärft wird dieses Problem nun aber noch dadurch, dass wir eine redundante Internetanbindung haben. Soll heißen, dass es sein kann, dass unsere Mails über eine weitere IP (natürlich mit anderer Namensauflösung) verschickt werden. Gibt es für dieses Problem eine Lösung?

Gruß

 

[JanJäschke]

Hey,

vom generellen Prinzip her ist das eigentlich kein Problem.
Ihr müsst nur sicherstellen, dass zu euren verwendenden Namen und IPs immer eine Auflösung möglich ist.
Soll heißen ihr braucht die:

• RDNS einträge für die Gateway IPs, das können auch die Namen eures Routers sein
• MX Records für beide IPs (falls das dann auch inbound gilt)
• A records für die im EHLO genutzten Namen
• SPF der die IPs entsprechend beinhaltet

Wenn ich nun spontan nichts vergessen habe solltet ihr dann auch per-se keinen Ärger mit den meisten haben.
Die Reputation der IPs hat natürlich noch Impact, aber das könnt ihr nur selbst auf Anfrage immer bereinigen lassen. Wenn die T-Online IP aber schon lange genutzt wurde und ihr sonst nie SPAM o.ä. verschickt habt sollte die generell passen.


Gruß
Jan

 

[JeWe]

Hi Jan,

vielen Dank für Deine Rückmeldung!

• Die RDNS-Einträge für die Router können wir nicht setzen, weil nicht in unserem Bereich
• Die MX-Records muss ich nur erweitern (Eintrag für Mailserver schon vorhanden), wenn es um den Mailempfang geht, richtig? Für den Versand spielen die keine Rolle.
• Die A-Records für EHLO teste ich noch einmal

Viele Grüße

 

[StefanCink]

Wenn ihr eine statische IP-Adresse habt, müsst ihr an den Provider herantreten und ihn um einen RDNS-Eintrag dafür bitten. Bei der Telekom geht das auf jeden Fall.
Gruß Stefan

 

[JeWe]

Gerade ist ein Beispiel eingetrudelt, beim Versuch, eine Mail rauszuschicken, kommt diese Antwort:

Remote Server returned '554 5.7.1 < #5.7.1 smtp;550 5.7.1 <mail@hans.dampf.de>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: xx.unseredomain.de, MTA hostname: router1235@provider.de[xxx.xxx.xxx.xxx] (helo/hostname mismatch)>'

Welcher DNS-Eintrag müsste dann durch den Provider gesetzt sein? xx.unseredomain.de ist der MX-Eintrag, kann also nicht verwendet werden. Sorry, wenn ich dumme Fragen stelle, bin kein Mail-Experte...

Gruß

 

[JanJäschke]

Gerade ist ein Beispiel eingetrudelt, beim Versuch, eine Mail rauszuschicken, kommt diese Antwort:

Remote Server returned '554 5.7.1 < #5.7.1 smtp;550 5.7.1 <mail@hans.dampf.de>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: xx.unseredomain.de, MTA hostname: router1235@provider.de[xxx.xxx.xxx.xxx] (helo/hostname mismatch)>'

Welcher DNS-Eintrag müsste dann durch den Provider gesetzt sein? xx.unseredomain.de ist der MX-Eintrag, kann also nicht verwendet werden. Sorry, wenn ich dumme Fragen stelle, bin kein Mail-Experte...

Gruß

Also prinzipiell müsste der Provider den RDNS setzen.
Das würde aber für den Wortlaut deiner Meldung nicht helfen. Da der Provider vermutlich den Namen auch nicht ändern wird, müsstest du den EHLO auf „router1235@provider.de“. Vlt ließt sich das grade aber mit den Infos auch nur doof

 

[869288141]

Hallo Jewe,
dazu muss ich leider ein paar Worte loswerden... weil sowas oftmals dazu führt, dass der Postmaster der empfangenen Seite mit Fragen/Probleme/Kritik konfrontiert wird, obwohl die Ursache vermeidlich auf der Senderseite liegt.

Sorry, wenn ich dumme Fragen stelle, bin kein Mail-Experte...

Es gibt zwei Möglichkeiten:

• Du setzt dich intensiv mit der Thematik auseinander.
• Du lässt das einen Experten administrieren und verwalten.

Der Betrieb von SMTP Proxy/Releay/Mailserver ist seit Jahren nichts mehr was nebenbei läuft. Das Thema wird immer komplexer/umfangreicher und es wird nicht mehr einfacher. Es gibt so viele Themen zu beackern.

Verschärft wird dieses Problem nun aber noch dadurch, dass wir eine redundante Internetanbindung haben

Lass mich raten... die redundante Internetanbindung sieht so aus, dass du es zwei 0815 (Business) Leitungen sind (z.B. 1x DTAG, 1x Vodafone). Somit zwei dedizierte öffentliche IP-Adressen, welche nicht beim Ausfall von Leitung 1 auf 2 übertragen werden. In diesem Fall ist langfristig nur ein zweiter Server mit der NSP Gateway Rolle sinnvoll. Zusätzlich 4 NAT Regeln auf der Firewall, damit eine klare 1:1 Zuordnung von öffentliche IP-Adresse zu NSP Gateway stattfindet.

Gruß,
Daniel

 

[JeWe]

Hi Daniel,

sehr späte Rückmeldung, ich weiß...

Danke aber für Deinen Hinweis!
Wir haben zwei Leitungen beim selben Provider über BGP angebunden, dementsprechend auch zwei IP-Adressen. Der zweite Server mit GW-Rolle erschließt sich mir nicht ganz, wozu?
Im Prinzip müsste es doch reichen, zwei NAT-Regeln auf der FW einzurichten?

Wäre cool, wenn Du mir da noch auf die Sprünge helfen könntest.

Viele Grüße
Jens

 

[869288141]

Hallo Jens,

Wir haben zwei Leitungen beim selben Provider über BGP angebunden, dementsprechend auch zwei IP-Adressen.

In der Regel hat man BGP in Kombination mit einem IP Subnetz. Um genau dem Szenario mit zwei IP-Adressen aus dem Weg zu gehen (Welches ich oben beschrieben habe). Fällt die Leitung A aus, übernimmt die Leitung B bzw. per BGP wird das Subnetz einfach über Leitung B announced. Sprich alle Services, sind weiterhin (im besten Fall ohne Unterbrechung) über die bisherige IP-Adresse erreichbar.

Woher kommt nun die zweite IP-Adresse her?

Im Prinzip müsste es doch reichen, zwei NAT-Regeln auf der FW einzurichten?

Im Prinzip kann das funktionieren. Es sind pro IP-Adresse zwei NAT Regeln. Wobei gerade bei ausgehend, immer nur ein Weg genommen werden kann. Was aber dazu führen wird, dass du eingehend entweder DNS-Round Robin machen musst. Weil der NSP nur mit einem FQDN im HELO antworten kann. Was natürlich auch eine gewisse Fehleranfälligkeit mit sich bringt. Zum anderen wird vermutlich auch NSP Probleme machen, wenn die E-Mail auf Leitung A rausgeht und auf Leitung B der Rückläufer kommt. Weil NSP von zwei Leitungen, und zwei IP-Adressen nichts weiß.

Abgesehen davon ihr fahrt eigentlich mit redundanten Leitungen, einem BGP + Subnetz einen Porsche. Hingegen fahrt ihr im Bereich Redundanz von Services einen Trabi. Der vermutlich mehr Probleme macht als nutzen haben wird. Daher investiere die paar Euro in die zweite Gateway Rolle und bau eine saubere Lösung auf. Die auch den Ansprüchen entsprechen und zu gleich Nerven schont.

Remote Server returned '554 5.7.1 < #5.7.1 smtp;550 5.7.1 <mail@hans.dampf.de>: Recipient address rejected: Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; MTA helo: xx.unseredomain.de, MTA hostname: router1235@provider.de[xxx.xxx.xxx.xxx] (helo/hostname mismatch)>'

Da würden wir euch nach 3 Versuchen direkt auf unsere DNSBL für 30 Tage setzen. Und bei jedem weiteren Versuch erneut für 30 Tage.


Gruß,
Daniel

 

[JeWe]

Danke Daniel!

Ich habe das jetzt über eine SourceNAT-Regel gelöst, funktioniert zumindest auf unserer Hauptleitung. Da ich mir das Wochenende nicht versauen will, werde ich am Montag mal testen, was passiert, wenn ich das Kabel der Hauptleitung abziehe.
Stand jetzt funktioniert es.

Der aktuelle Empfänger, der betroffen ist, reagiert zum Glück etwas nachsichtiger, bei erneutem Versuch kommt dies:
Recipient address rejected: temporarily blocked because of previous errors - retrying too fast. penalty: 30 seconds x 0 retries.

Ich konnte jetzt aber nach der erstellten FW-Regel auch dorthin eine Mail schicken, zumindest zeigt NSP die als "Erfolgreich verschickt" an, eine ablehnende Antwortmail bekomme ich auch nicht.

Am Montag liefere ich gern noch ein Update, ob das jetzt über beide Leitungen klappt.

Vielen Dank und ein schönes Wochenende!
Jens

 

[869288141]

Schön zu hören. Drück dir die Daumen, dass du keine weitere Minute investieren musst.
Schade das du auf die Frage nicht eingegangen bist...

Der aktuelle Empfänger, der betroffen ist, reagiert zum Glück etwas nachsichtiger, bei erneutem Versuch kommt dies:

Wird sich vermutlich ändern... die großen Plattformen sind bereits seit Jahren im Austausch. Inzwischen haben auch in Deutschland große Unternehmen/Konzerne sich recht gut vernetzt. Da werden mittelfristig die Daumenschrauben angezogen. Weil genau solche schwäbische Konstrukte binden auf deiner Seite Arbeitszeit und ggf. auf der Gegenstelle. Das ist Zeit, welcher unser Helpdesk/E-Mail Engineer an anderer Stelle fehlt und keiner bezahlen möchte.

 

[JeWe]

Hi Daniel,

Schade das du auf die Frage nicht eingegangen bist...

Sorry, meintest Du die Frage, woher die zweite IP-Adresse kommt?
Mir erschließt sich der Ablauf ohnehin nicht, vielleicht kann mich jemand erhellen. Sind wir mit unserer Hauptleitung verbunden, bekamen die Mailempfänger als IP unseres Mailservers nicht die korrekte IP, sondern die IP des Routers unseres Providers, also quasi unsere Gegenstelle ins Internet. Fällt die Hauptleitung aus, wird per BGP auf die Ausfallleitung geschwenkt. Dort steht natürlich ein anderer Router, deshalb auch eine andere IP, die nach außen gegeben wird. Warum auch immer diese jeweilige IP verwendet wird (wurde).

Viele Grüße
Jens

 

[869288141]

Also... bei solchen Lösungen haben die Router jeweils eine dedizierte, öffentliche IP-Adresse. Das Subnetz wird in der Regel vom ISP vorgeben und ist in 99% der Fälle für den Kunden uninteressant.

Hinter dem Router des ISP (Netzabschluss) platzieren die Kunden in der Regel eine Firewall bzw. bei redundanten Anbindung ebenfalls einen Cluster. Je nach Firewall Hersteller muss jede Firewall auch eine öffentliche IP-Adresse haben. Da gibt es leider Unterschiede. Für den Cluster wird eine virtuelle IP-Adresse aus dem IP Subnetz vergeben, in welchem sich auch die Router des ISP befinden.

Wer für das Routing das Protokoll BGP verwendet, hat in der Regel ein zusätzliches öffentliches IP Subnetz (z.B. 10.10.10.0/27). Dieses routet der ISP entsprechend auf die virtuelle IP-Adresse des Firewall Clusters.
Für die Verwendung des IP Subnetzes 10.10.10.0/27 gibt es nun zwei Optionen:

• Das Subnetz wird in die DMZ geroutet. Das macht es einfacher, die Services auch mit IPv6 anzubinden. Von Loopback Routing, gerade beim Zugriff aus dem LAN, nicht zu sprechen.
• IP-Adressen aus dem Subnetz werden mit Hilfe von NAT an die Server in der DMZ (oder sogar LAN) weitergeleitet.

Mich würde brennend interessieren welcher ISP und welches Produkt bei euch im Einsatz ist. Weil aktuell klingt es für mich so, als würden deine Kollegen von NOC eine suboptimale Konfiguration implementiert zu haben.