450 Undeliverable vs. 550 User Unknown

[Ebi]

Guten Morgen!

Ich hab hier noch ein kleines Problem mit den Return Codes vom Intranator PostFix im Zusammenhang mit der E-Mail-Weiterleitung an unseren Exchange-Server.

Wird eine E-Mail an einen unbekannten Empfänger vom Intranator empfangen, versucht der die Mail an den Exchange-Server weiterzuleiten. Das blockt der mit der Fehlermeldung "550 5.1.1 User Unknown". Der Intranator meldet daraufhin jedoch dem sendenden Mail-Server den Fehlercode 450.

Aus der Sicht des sendenden Servers sieht das ganze so aus:

RCPT TO: uucp@aviso-gmbh.de
450 <uucp@aviso-gmbh.de>: Recipient address rejected: undeliverable address: host exchangeserver.intranator-domain.lan[exchangeServerIp] said: 550 5.1.1 User unknown (in reply to RCPT TO command)

Nun gibt es das Problem, dass der sendende Mail-Server die Mail-Zustellung nur im Falle des Fehlercodes 550 abbricht, im Falle von 450 aber noch weiter versucht, die Mails zuzustellen. Da es sich bei den sendenden Server um die Backup-MX-Server unserer Domains handelt, ist das direkt auch unser Problem.

Wieso verändert der Intranator den Error Code? Was genau ist der Unterschied zwischen beiden Error Codes? Der Standard scheint sich hier weitestgehend auszuschweigen.

450 Requested mail action not taken: mailbox unavailable.
550 Requested action not taken: mailbox unavailable. (For example, the mailbox is not found, there is no access, or no relay is allowed).

Liebe Grüße und ein wunderschönes, ruhiges, besinnliches Weihnachtsfest!!

Jens Eberhardt

[Gerd von Egidy]

Hallo,

ich vermute mal, Sie leiten die Domain weiter und verwenden die Option "Empfängeradressen überprüfen". Dabei fragt der Intranator beim Zielserver an, ob die Adresse gültig ist, bevor er sie akzeptiert.

Der Intranator ist so eingestellt, daß er alle negativen Antworten (Code 400 und darüber) immer mit einem 450-Code beantwortet. Die intern verwendete Mailersoftware (Postfix) bietet nicht die Möglichkeit, den Code des Zielservers weiterzugeben. Wenn man jetzt alle Fehler mit einem 550 beantworten würde, würden während eines kurzen Ausfalls oder Umkonfigurierens des Zielservers (hier dem Exchange) alle Emails mit 550 dauerhaft abgelehnt werden. Deshalb verwenden wir hier den 450er Fehlercode (wie es auch die Standardeinstellung von Postfix ist).

Die Fehlercodes sind übrigens in RFC 2821 (http://www.ietf.org/rfc/rfc2821.txt), Kapitel 4.2.1 und folgende genau definiert.

Das Problem bei Ihrer Konfiguration ist, daß Ihr Backup-MX beliebige Zieladressen akzeptiert, ohne sie vorher zu prüfen. Spammer wissen dies und senden Ihre Mails deshalb oft geziehlt zum Backup-MX. Damit werden jede Menge unnötige Backscatter-Emails (siehe z.B. http://www.postfix.org/BACKSCATTER_README.html) erzeugt. Sie sollten Ihren Backup-MX daher so einstellen, daß er entweder alle gültigen Adressen kennt, oder ähnlich wie der Intranator vor der Annahme jeder Email prüft, ob der Empfänger gültig ist.

Herzliche Grüße,

v. Egidy

[Ebi]

Hallo.

Ihre Vermutung bezüglich der Konfiguration ist korrekt.

Da es sich bei den Backup-MX-Servern um durch einen externen Dienstleister gehostete Server handelt, können wir die Möglichkeit, alle gültigen Adressen dort zu hinterlegen, leider nicht wahrnehmen.

Die 2. Möglichkeit, nämlich die, dass der Backup-MX vorher schaut, ob der Empfänger auch erreichbar ist, klingt da schon interessanter. Aber da stellt sich mir die Frage, ob das technisch überhaupt möglich ist, wenn der Intranator immer die 450 als Fehlercode zurückgibt?? Der Backup-MX ist ja dann auch nicht schlauer als wie nach Annahme der Mail nach jetziger Konfiguration, oder gibt es hier noch einen besonderen Trick?

Liebe Grüße,
Jens Eberhardt

[DynAccess]

Hallo,

prinzipiell wäre es möglich, dass wir unsere Backup-MX mit Informationen bzgl. gültige eMail-Adressen füttern. Nur bedarf es hier der manuellen Eingabe durch den Benutzer in einem Frontend.
Im Falle der Backup-MX-Bereitstellung im Rahmen unserer DynAccess-Leistungen haben wir prinzipiell keine Möglichkeit der automatischen Erkennung auf Existenz der Empfänger-eMail-Adresse.
Ein on-the-fly-Test ist prinzipiell problematisch, da unsere Backup-MX i.d.R. dann angesprochen werden, ist der primäre eMail-Server ausgefallen und ein on-the-fly-Test nicht möglich.

Der Intranator hingegen hat direkten Kontakt zum eigentlichen SMTP-Server und kann sicherlich recht unproblematisch eine Liste von gültigen Adressen durch automatiserte Analyse erstellen und pflegen.

Fakt ist, dass der Intranator mit einem SMTP-Fehlercode von 450 dem sendenden SMTP-Server "please try again later" mitteilt.

Wir haben unsere Backup-MX-Server bereits um die Analyse der Intranator-Rückmeldung erweitert. D.h. registrieren wir ein
stat=Deferred: 450 <aaa@bbb.de>: Recipient address rejected: undeliverable address: host xxx.yyy.lan[192.168.1.2] said: 550 5.1.1 User unknown (in reply to RCPT TO command),
reagieren wir hierauf.

Kann es nur sein, dass nach wiederholtem Sendeversuch der Intranator die SMTP-Session abbricht bzw. keine Rückmeldung gibt? Dieses Problem macht uns gerade etwas Kopfzerbrechen.




Mit freundlichen Grüßen
Heiko Ambos

Ambos InterNet-Solutions

Hausanschrift: Am Wellsee 59c, D-24146 Kiel
Postanschrift: Postfach 1233, D-24011 Kiel

Tel.: 0700 - AmbosFon (12 Cent/min)
26267366
Fax.: 0700 - AmbosFax (12 Cent/min)
26267329
http://www.ambos-is.net
http://www.dynaccess.de

[Gerd von Egidy]

Hallo,

prinzipiell wäre es möglich, dass wir unsere Backup-MX mit Informationen bzgl. gültige eMail-Adressen füttern. Nur bedarf es hier der manuellen Eingabe durch den Benutzer in einem Frontend.

das ist klar. Aber ein Backup-MX, der Emails annimmt, ohne die Empfängeradressen zu überprüfen, ist heutzutage eine kritische Sache: Spammer versuchen häufig zuerst den Backup-MX. Wird dort die Email angenommen, kann aber nicht zugestellt werden, produziert der Backup-MX Backscatter-Emails. Und die machen mittlerweile einen großen Teil des Spam-Problems aus. Sie können von Spamfiltern nur schwer gefiltert werden, da es sich auch um erwünschte Non-Delivery-Reciepts handeln könnte.

Ich würde lieber auf den Backup-MX verzichten, wenn er keine korrekte Empfängerprüfung vornehmen kann.

Fakt ist, dass der Intranator mit einem SMTP-Fehlercode von 450 dem sendenden SMTP-Server "please try again later" mitteilt.

Der Grund dafür ist eben die Sache mit einem Zielserver, der kurzfristig eine Störung hat.

Kann es nur sein, dass nach wiederholtem Sendeversuch der Intranator die SMTP-Session abbricht bzw. keine Rückmeldung gibt? Dieses Problem macht uns gerade etwas Kopfzerbrechen.

Ein solches Verhalten ist nicht vorgesehen. Solange Sie den Intranator nicht mit Loginversuchen mit falschen Passwörtern bombardieren, sollten Sie nicht geblockt werden. Können Sie das Problem reproduzieren? Wenn ja, notieren Sie sich Datum und genaue Uhrzeiten der Verbindungsversuche. Anhand der maillog-Datei (Information > System > Logdateien) können wir dann höchstwahrscheinlich die Ursache erkennen. Sie können entweder den entsprechenden Ausschnitt hier posten oder auf unserer Webseite ein Support-Ticket anlegen und uns die gesamte Datei per Email schicken.

Herzliche Grüße,

v. Egidy

[Ebi]

Evtl. gibt es hier einen Zusammenhang zu folgendem Thema:

http://forum.intra2net.com/1012-conn...-exceeded.html

[Ebi]

Wäre es denn denkbar, den Benutzer über die Web-Administrationsoberfläche wählen zu lassen, ob postfix standardmäßig 450 oder 550 zurückgibt?

[Gerd von Egidy]

Hallo,

ja, das wäre schon möglich. Ich werde allerdings bei den Postfix-Entwicklern noch mal nachfragen, warum es keine Unterscheidung zwischen 4xx und 5xx gibt.

Herzliche Grüße,

v. Egidy

[Gerd von Egidy]

Hallo,

ich habe das Szenario nochmal nachgestellt und genauer untersucht. Ich habe doch noch eine Möglichkeit gefunden, wie der Intranator auf die unterschiedlichen Zielserverantworten unterschiedlich antworten kann.

Wenn der Zielserver nicht erreichbar ist oder ein 4xx-Code sendet, kann er mit 450 antworten, nur wenn der Zielserver wirklich ein 5xx-Code bringt, wird er mit 550 antworten.

Diese Funktion wird im nächsten Update enthalten sein.

Herzliche Grüße,

v. Egidy

[Ebi]

Guten A'md,

das klingt doch klasse! Vielen Dank für die Bemühungen!

Liebe Grüße,
Jens Eberhardt