SMTP, Code 450 und multiple MX Records
Nicht direkt postfix-related, vl. kann mir dennoch jemand helfen
Folgendes Szenario: 1 Domain, 2 MX Records (mit unterschiedlicher Prio/Preference). Auf Server 1 (prefered) läuft Greylisting
Nun passiert folgendes, jemand schickt eine Mail, dieser Host wird gegreylisted am MX1 und mit Statuscode 450 abgewiesen, jetzt probiert dieser dann sofort die Mail an MX2 zuzustellen, das funktioniert auch.
Ich konnte weder im SMTP-RFC (davon gibts auch schon mehrere Versionen wie ich festgestellt habe) noch sonst im Internet eine eindeutige Aussagen finden, vl. weis hier aber jemand besser bescheid:
Muss der Sending-MTA wenn er mit 450 abgewiesen wurde warten und beim gleichen Mailserver nochmal einen Zustellversuch unternehmen oder muss er tatsächlich sofort zum 2. MX connecten und dort versuchen das Mail zuzustellen?! Gibts da irgendwie ein best-behaviour oder ist das generell ungeregelt?! Postfix ist ja beeinflussbar (smtp_skip_4xx_greeting), sendmail machts auch so (try next in list) jedoch würde mich generell interessieren ob das irgendwo festgeschrieben ist oder interpretationssache?
Vg, Christoph
-- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Germany-f21717.html
Im Auftrag von kern
Nun passiert folgendes, jemand schickt eine Mail, dieser Host wird gegreylisted am MX1 und mit Statuscode 450 abgewiesen, jetzt probiert dieser dann sofort die Mail an MX2 zuzustellen, das funktioniert auch.
Ich konnte weder im SMTP-RFC (davon gibts auch schon mehrere Versionen wie ich festgestellt habe) noch sonst im Internet eine eindeutige Aussagen finden, vl. weis hier aber jemand besser bescheid:
Muss der Sending-MTA wenn er mit 450 abgewiesen wurde warten und beim gleichen Mailserver nochmal einen Zustellversuch unternehmen oder muss er
Warum sollte er "müssen" ? Du gibst doch mit den beiden MX Einträgen an "Wenn Problem dann nimm den anderen" :-)
Und warum ist MX 2 anders aufgebaut als MX 1 ?? Für was hast du 2 MX'se ? Wie hoch ist dein Mailaufkommen ? Ist einer der MX'se am Dialin und nicht dauerhaft erreichbar? Ist der MX1 überlastet ?
Grundsätzlich gilt : Wenn 2 MX'se dann sollten BEIDE mit denselben Restriktionen betrieben werden. Ansonsten wirst du erleben das der erste mit Greylisting bald nicht mehr so häufig von den Spamer genutzt wird wie der 2. Auf dem die Mails "problemloser" angenommen werden :-)
Mit freundlichen Grüßen
Uwe Drießen -- Software & Computer
Netzwerke, Server. Wir vernetzen Sie und Ihre Rechner !
Uwe Drießen Lembergstraße 33 67824 Feilbingert
Tel.: 06708660045
Hallo Christoph,
Am Mittwoch, 28. November 2018, 07:55:24 CET schrieb kern:
Folgendes Szenario: 1 Domain, 2 MX Records (mit unterschiedlicher Prio/Preference). Auf Server 1 (prefered) läuft Greylisting
Nun passiert folgendes, jemand schickt eine Mail, dieser Host wird gegreylisted am MX1 und mit Statuscode 450 abgewiesen, jetzt probiert dieser dann sofort die Mail an MX2 zuzustellen, das funktioniert auch.
Ich konnte weder im SMTP-RFC (davon gibts auch schon mehrere Versionen wie ich festgestellt habe) noch sonst im Internet eine eindeutige Aussagen finden, vl. weis hier aber jemand besser bescheid:
Muss der Sending-MTA wenn er mit 450 abgewiesen wurde warten und beim gleichen Mailserver nochmal einen Zustellversuch unternehmen oder muss er tatsächlich sofort zum 2. MX connecten und dort versuchen das Mail zuzustellen?! Gibts da irgendwie ein best-behaviour oder ist das generell ungeregelt?!
üblicherweise wird der Sender alle vorhandenen MX durchprobieren bis er Erfolg hat. Maßnahmen wie Greylisting machen nur Sinn, wenn sie auf allen MX gleichermaßen eingesetzt werden.
Gruß, Gregor
Am 2018-11-28 15:55, schrieb kern:
[..] Ich konnte weder im SMTP-RFC (davon gibts auch schon mehrere Versionen wie ich festgestellt habe) noch sonst im Internet eine eindeutige Aussagen finden, vl. weis hier aber jemand besser bescheid:
https://tools.ietf.org/html/rfc5321#section-5.1 vielleicht..?
| When the lookup succeeds, the mapping can result in a list of | alternative delivery addresses rather than a single address, because | of multiple MX records, multihoming, or both. To provide reliable | mail transmission, the SMTP client MUST be able to try (and retry) | each of the relevant addresses in this list in order, until a | delivery attempt succeeds. [..] In any | case, the SMTP client SHOULD try at least two addresses.
Und ja, da steht »..MUST be able to try .. each of..« und »..SHOULD try at least two«... Heisst also eher eigene Interpretation jedes einzelnen Produkts ;) Adressen der Reihe nach durchgehen kann er ja (<- »MUST« erfüllt) und in seiner Interpretation von »SHOULD« geht er der Reihe nach alle durch - ich glaube mir ist auch kein Produkt bekannt, was das nicht genauso tut..
Grüsse Christian
Am 28.11.2018 um 17:59 schrieb Christian Bricart:
Am 2018-11-28 15:55, schrieb kern:
[..] Ich konnte weder im SMTP-RFC (davon gibts auch schon mehrere Versionen wie ich festgestellt habe) noch sonst im Internet eine eindeutige Aussagen finden, vl. weis hier aber jemand besser bescheid:
https://tools.ietf.org/html/rfc5321#section-5.1 vielleicht..?
| When the lookup succeeds, the mapping can result in a list of | alternative delivery addresses rather than a single address, because | of multiple MX records, multihoming, or both. To provide reliable | mail transmission, the SMTP client MUST be able to try (and retry) | each of the relevant addresses in this list in order, until a | delivery attempt succeeds. [..] In any | case, the SMTP client SHOULD try at least two addresses.
Und ja, da steht »..MUST be able to try .. each of..« und »..SHOULD try at least two«... Heisst also eher eigene Interpretation jedes einzelnen Produkts ;) Adressen der Reihe nach durchgehen kann er ja (<- »MUST« erfüllt) und in seiner Interpretation von »SHOULD« geht er der Reihe nach alle durch - ich glaube mir ist auch kein Produkt bekannt, was das nicht genauso tut..
Genau, er geht sie der Reihe nach durch, aber viele Spammer-Systeme kontaktieren bewusst zunächst den 2. Eintrag, genau unter der Annahme, dass dort evtl. der Schutz schwächer ist.
Dagegen kann man auch nicht viel machen, da man ja kaum herausbekommen kann, ob dieses spezielle System den ersten Client tatsächlich erreichen konnte. Somit kann man von der Serverseite her das "Try... in this order" nicht einfordern oder die Nichteinhaltung sanktionieren, dann könnte es zur Ablehnung vollkommen legitimen traffics kommen. Wenn man zwei Systeme "bewirbt", müssen diese daher entweder das gleich Schutzniveau haben oder das zweite ist nur ein "SMTP-Eimer", der im Normalfall sofort weiterleitet an #1 und im Fehlerfall als Puffer dient. Dieses Setup hat aber andere Nachteile, daher würde ich es im allgemeinen nicht empfehlen.
Grüße JC
On 28.11.18 19:35, Jakob Curdes wrote:
Genau, er geht sie der Reihe nach durch, aber viele Spammer-Systeme kontaktieren bewusst zunächst den 2. Eintrag, genau unter der Annahme, dass dort evtl. der Schutz schwächer ist.
das ist richtig - also die Annahme, dass der "Backup-MX" (für den Spam-Versender erkennbar an der niedrigeren MX-Prio, lies: grösserer Wert) bei manchen Leuten schlechter konfiguriert ist und dort mehr Chance besteht den Müll loszuwerden..
(Jetzt könnte man natürlich auch gleichzeitig argumentieren, dass es dann genau die Richtigen trifft .. ;-) )
Dagegen kann man auch nicht viel machen, da man ja kaum herausbekommen kann, ob dieses spezielle System den ersten Client tatsächlich erreichen konnte. Somit kann man von der Serverseite her das "Try... in this order" nicht einfordern oder die Nichteinhaltung sanktionieren, dann könnte es zur Ablehnung vollkommen legitimen traffics kommen. Wenn man zwei Systeme "bewirbt", müssen diese daher entweder das gleich Schutzniveau haben oder das zweite ist nur ein "SMTP-Eimer", der im Normalfall sofort weiterleitet an #1 und im Fehlerfall als Puffer dient. Dieses Setup hat aber andere Nachteile, daher würde ich es im allgemeinen nicht empfehlen.
..ich kenne durchaus Setups, bei denen der Connect auf den MX-20 einen Eintrag ähnlich Greylisting-Tripel) erzeugt, *jeden* Mailversuch aber prinziell mit 4xx temporär ablehnt und beim "hochhangeln" (lies: statt an der MX-Prio "runterhangeln") auf den eigentlich aktiven MX-10 dort nachschaut, ob der Client es vorher bei MX-20 versucht hat -> dann hart abweisen weil das legitime Clients eben genau nicht tun.. Sowas *kann* man sogar auf dem selben Host (postmulti oder container) realisieren - falls man irgendweche Netzwerk-Kommunikations-Ausfälle scheut, die zum querabfragen des Tripels nötig sind... bspw gemeinsame sqlite auf dem selben Host und gut.. ;-)
Christian
..ich kenne durchaus Setups, bei denen der Connect auf den MX-20 einen Eintrag ähnlich Greylisting-Tripel) erzeugt, *jeden* Mailversuch aber prinziell mit 4xx temporär ablehnt und beim "hochhangeln" (lies: statt an der MX-Prio "runterhangeln") auf den eigentlich aktiven MX-10 dort nachschaut, ob der Client es vorher bei MX-20 versucht hat -> dann hart abweisen weil das legitime Clients eben genau nicht tun.. Sowas *kann* man sogar auf dem selben Host (postmulti oder container) realisieren - falls man irgendweche Netzwerk-Kommunikations-Ausfälle scheut, die zum querabfragen des Tripels nötig sind... bspw gemeinsame sqlite auf dem selben Host und gut.. ;-)
Christian
Das ist dann aber keinesfalls standardkonform, weil ich ja nur messen kann, ob ich selbst zum Empfang bereit war, nicht ob. z.B. Routingprobleme verhindert haben, dass der Client es beim höherwertigen MX versuchen konnte. Es ist ja heute auch kein großes Problem mehr, zwei Server mit sehr ähnlichen Konfigurationen zu betreiben. So habe ich dann auch echte Redundanz falls auf meiner Seite wirklich was ausfällt.
JC
Hallo zusammen,
Am Mittwoch, 28. November 2018, 19:35:39 CET schrieb Jakob Curdes:
aber viele Spammer-Systeme kontaktieren bewusst zunächst den 2. Eintrag, genau unter der Annahme, dass dort evtl. der Schutz schwächer ist.
Meine Erfahrung ist, dass viele Spammer _nur_ den Backup-MX anfragen (zumindest war das damals[tm] so, als ich meinen "Faulpelz-MX" eingerichtet habe - aktuelle Statistiken habe ich leider keine)
Ich habe dann einen Backup-MX eingerichtet, der den ganzen Tag nur 450 I'm a "Faulpelz", please use the primary MX sagt. Den Spammern hat es offenbar gefallen, die haben mir die Bude eingerannt ;-) und mein Greylisting auf dem "richtigen" Mailserver hatte fast nichts mehr zu tun.
Falls das jemand nachbauen will: https://blog.cboltz.de/archives/45-Faulpelz-MX.html (huch, ist das schon 10 Jahre her?)
Einziger Nachteil des Faulpelz-MX ist, dass man eine IP damit verbrät - deshalb habe ich momentan keinen Faulpelz-MX mehr im Einsatz. Wenn ich irgendwann mal wieder eine IP mit unbenutztem Port 25 habe, werde ich den Faulpelz wieder zur Arbeit schicken ;-)
Gruß
Christian Boltz
participants (6)
-
Christian Boltz -
Christian Bricart -
Gregor Hermens -
Jakob Curdes -
kern -
Uwe Drießen