SMTP, Code 450 und multiple MX Records

[Christian Bricart]

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