SMTP, Code 450 und multiple MX Records

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

SMTP, Code 450 und multiple MX Records

kern
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
Reply | Threaded
Open this post in threaded view
|

AW: SMTP, Code 450 und multiple MX Records

Uwe Drießen
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



Reply | Threaded
Open this post in threaded view
|

Re: SMTP, Code 450 und multiple MX Records

Gregor Hermens-2
In reply to this post by kern
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
--
     @mazing           fon +49 8142 6528665
  Gregor Hermens       fax +49 8142 6528669
Brucker Strasse 12  [hidden email]
D-82216 Gernlinden   https://www.a-mazing.de/
Reply | Threaded
Open this post in threaded view
|

Re: SMTP, Code 450 und multiple MX Records

Christian Bricart
In reply to this post by kern
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
Reply | Threaded
Open this post in threaded view
|

Re: SMTP, Code 450 und multiple MX Records

Jakob Curdes

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

Reply | Threaded
Open this post in threaded view
|

Re: 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


Reply | Threaded
Open this post in threaded view
|

Re: SMTP, Code 450 und multiple MX Records

Jakob Curdes

> ..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

Reply | Threaded
Open this post in threaded view
|

Re: SMTP, Code 450 und multiple MX Records

Christian Boltz-2
In reply to this post by Jakob Curdes
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
--
> EinTablet kenne ich. - OT -
> Jetzt hat mich jemand nach einem Ablet gefragt?
Das ist ein Sondermodell für notorische Kaffeetrinker -
also für Leute die nicht so auf "T" stehen.
[> Bernd Adda und Mathias Homann in opensuse-de]