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