Erfahrungsbericht Hornet Security Antispam - 450 4.1.1 (Recipient address rejected: unverified address: Address verifica
Hallo,
ich wollte hier einmal von einem Fall berichten der mich Zeit und Nerven gekostet hat.
Ich habe fast eine Woche benötigt um mit dem Support das Problem lösen zu können.
Der sich aus meiner Sicht als Bug bei Hornet Security herrausgestellt hat.
Vieleicht hilft es ja mal Jemanden der das gleiche Problem hat.
Kurz für die ungeduldigen: Prüfe die SMTP-Adressen ob alle erreichbar sind. Besonders die erste IP.
Konstrukt
Ein Kunde betreibt einen Onpremise Exchange-Server und nutzt von Hornet Security (HS) Antispam und sMIME-Gateway davor.
Eingehende Mails landen via MX bei HS und werden per SMTP an den Exchange durch einen IP-Filter weitergeleitet.
Ausgehende Mails werden vom Exchange per SMTP-Smarthost an HS geschickt.
Die DNS-Einträge MX und SPF sind valide.
HS ruft per LDAP die Benutzer einer Gruppe vom AD an.
Die Adressüberprüfung der eingehenden Emails ist auf "SMTP" konfiguriert.
(HS prüft jede Email per SMTP gegen den Exchange-Server ob die Adresse bekannt und gültig ist.)
Alles funktioniert seit mehr als 12 Monaten störungsfrei.
Auf einmal konnte man an 2 Personen und fast alle Verteilergruppen des Exchange keine Mails von extern mehr empfangen.
Intern gab es keine Probleme.
Als Fehler erhielt der Versender "450 4.1.1 (Recipient address rejected: unverified address: Address verification in progress)".
Ein Test mit Telnet, sowohl aus dem LAN als auch WAN, funktioniert an alle Adressen problemlos.
Bei den Personen war dies einfach.
Sie waren nicht in der richtigen Gruppe und wurden deshalb per LDAP nicht gemeldet.
Wobei sich mir die Frage stellte warum dies überhaupt einen Einfluss auf das Empfangen von Mails hat.
Denn es ist SMTP-Verfikation eingestellt.
HS könnte mich wegen der Lizenzen durchaus anrufen/anschreiben, aber die Meldung passt dazu nicht.
Nach vielen Hin und Her mit dem Support wurde mir mitgeteilt, dass der Exchange via SMTP nicht erreichbar sei.
Das passt zu der Meldung.
Mein Test via WAN auf die IP funktioniert aber.
In HS kann man dafür mehrere IP-Adressen konfigurieren.
Format: IP:Port#Prio;IP:Port#Prio;IP:Port#Prio;
Dies ist mein Eintrag.
80.a.a.a:25#10;80.b.b.b:25#5
Und ja, die 80.a.a.a funktionierte nicht mehr.
Aber die 80.b.b.b mit der besseren Prio funktionierte ganz normal.
Ich habe 80.a.a.a gelöscht und nach 5 Stunden funktionierte alles wieder normal.
Fazit:
Aus unbekannten Grund hat HS nur die 1. IP-Adresse für die Adress-Validierung verwendet.
-> Bug
Wobei der Bug nur die Adress-Validierung betrifft. Die Zustellung an die 2. IP ist kein Problem.
Änderungen daran dauern bis zu 5 Stunden bis diese aktiv werden.
Das ist natürlich "doof" wenn einem der Kunde im Nacken sitzt.
Der Support brauchte ca. 1 Woche von meiner ersten Meldung "450 4.1.1 (Recipient address rejected: unverified address: Address verification in progress)" bis zu der Analyse, dass die 1. IP-Adresse nicht erreichbar sei.
Bei der Meldung sollte dies doch der 1. Vorschlag sein.
Auch könnte man mir eine Mail senden wenn mehrere Tage der SMTP nicht erreichbar war.
Viele Grüße
Stefan
ich wollte hier einmal von einem Fall berichten der mich Zeit und Nerven gekostet hat.
Ich habe fast eine Woche benötigt um mit dem Support das Problem lösen zu können.
Der sich aus meiner Sicht als Bug bei Hornet Security herrausgestellt hat.
Vieleicht hilft es ja mal Jemanden der das gleiche Problem hat.
Kurz für die ungeduldigen: Prüfe die SMTP-Adressen ob alle erreichbar sind. Besonders die erste IP.
Konstrukt
Ein Kunde betreibt einen Onpremise Exchange-Server und nutzt von Hornet Security (HS) Antispam und sMIME-Gateway davor.
Eingehende Mails landen via MX bei HS und werden per SMTP an den Exchange durch einen IP-Filter weitergeleitet.
Ausgehende Mails werden vom Exchange per SMTP-Smarthost an HS geschickt.
Die DNS-Einträge MX und SPF sind valide.
HS ruft per LDAP die Benutzer einer Gruppe vom AD an.
Die Adressüberprüfung der eingehenden Emails ist auf "SMTP" konfiguriert.
(HS prüft jede Email per SMTP gegen den Exchange-Server ob die Adresse bekannt und gültig ist.)
Alles funktioniert seit mehr als 12 Monaten störungsfrei.
Auf einmal konnte man an 2 Personen und fast alle Verteilergruppen des Exchange keine Mails von extern mehr empfangen.
Intern gab es keine Probleme.
Als Fehler erhielt der Versender "450 4.1.1 (Recipient address rejected: unverified address: Address verification in progress)".
Ein Test mit Telnet, sowohl aus dem LAN als auch WAN, funktioniert an alle Adressen problemlos.
Bei den Personen war dies einfach.
Sie waren nicht in der richtigen Gruppe und wurden deshalb per LDAP nicht gemeldet.
Wobei sich mir die Frage stellte warum dies überhaupt einen Einfluss auf das Empfangen von Mails hat.
Denn es ist SMTP-Verfikation eingestellt.
HS könnte mich wegen der Lizenzen durchaus anrufen/anschreiben, aber die Meldung passt dazu nicht.
Nach vielen Hin und Her mit dem Support wurde mir mitgeteilt, dass der Exchange via SMTP nicht erreichbar sei.
Das passt zu der Meldung.
Mein Test via WAN auf die IP funktioniert aber.
In HS kann man dafür mehrere IP-Adressen konfigurieren.
Format: IP:Port#Prio;IP:Port#Prio;IP:Port#Prio;
Dies ist mein Eintrag.
80.a.a.a:25#10;80.b.b.b:25#5
Und ja, die 80.a.a.a funktionierte nicht mehr.
Aber die 80.b.b.b mit der besseren Prio funktionierte ganz normal.
Ich habe 80.a.a.a gelöscht und nach 5 Stunden funktionierte alles wieder normal.
Fazit:
Aus unbekannten Grund hat HS nur die 1. IP-Adresse für die Adress-Validierung verwendet.
-> Bug
Wobei der Bug nur die Adress-Validierung betrifft. Die Zustellung an die 2. IP ist kein Problem.
Änderungen daran dauern bis zu 5 Stunden bis diese aktiv werden.
Das ist natürlich "doof" wenn einem der Kunde im Nacken sitzt.
Der Support brauchte ca. 1 Woche von meiner ersten Meldung "450 4.1.1 (Recipient address rejected: unverified address: Address verification in progress)" bis zu der Analyse, dass die 1. IP-Adresse nicht erreichbar sei.
Bei der Meldung sollte dies doch der 1. Vorschlag sein.
Auch könnte man mir eine Mail senden wenn mehrere Tage der SMTP nicht erreichbar war.
Viele Grüße
Stefan
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 13138260787
Url: https://administrator.de/contentid/13138260787
Ausgedruckt am: 23.11.2024 um 09:11 Uhr
1 Kommentar