Technischer Ablauf von Greylisting

[Yorin]

Hallo!

Ich habe ein paar Verständnisfragen zum konkreten technischen Ablauf von Greylisting.

Meinem Verständnis nach basiert Greylisting auf dem Abweisen einer "unbekannten" Mail mit der Ausgabe eines temporären Fehlers (450 oder 451). Liege ich da richtig? Gibt es da andere Formen der Rückmeldung oder andere Vorgangsweisen? Was wäre die "korrekteste" Vorgangsweise?

Falls es beim Adressaten alternative MX-Einträge gibt, was ist dann Mittel der Wahl nach Abweisung der Mail: Zustellversuch bei anderem MX oder erneuter Zustellversuch bei gleichem MX? Gibt es dafür jeweils irgendwelche (Quasi-)Standards bezüglich des Delays? Ist die anzuratende Vorgangsweise irgendwo spezifiziert?

Für jegliche Hilfe im Voraus vielen Dank!

Beste Grüße, Yorin

 

[marce]

https://de.wikipedia.org/wiki/Greylisting - recht gut zusammengefasst und die relevanten RFCs sind verlinkt.

 

[Yorin]

https://de.wikipedia.org/wiki/Greylisting - recht gut zusammengefasst und die relevanten RFCs sind verlinkt.

Vielen Dank für den Hinweis. In die Wikipedia hatte ich geschaut, bevor ich hier gefragt habe. Leider beantwortet der dortige Beitrag meine speziellen Fragen nicht, auch der englische Artikel, der etwas ausführlicher ist, nicht wirklich.

Ich hatte dann schon mal begonnen, das RFC 6647 anzulesen. Im Hinblick auf die technischen Abläufe bringt das schon ein wenig mehr Klarheit, hinsichtlich einer "best practice" oder einer allgemein üblichen Vorgangsweise, falls es eine solche geben sollte, jedoch nicht. Da werden halt diverse technische Optionen aufgezeigt, à la das kannst du so machen oder auch so...

Interessieren würde mich aber vor allem, wie Greylisting üblicherweise gehandhabt bzw. konfiguriert wird. Es kann nun aber natürlich gut sein, dass es einfach keinen üblichen Usus gibt. Was auch auch erklären würde, dass ich dazu im Netz nicht recht viel finde.

Behelfsweise habe ich mir nun mal die Standardwerte von Postgrey angesehen.

 

[danton]

Meist wird Greylisting mit einer Wartezeit von ein paar Minuten verwendet. Die Abweisung erfolgt durch einen temporären Fehler. Best Practice ist es, einfach die Zeit abzuwarten und dann die Mail erneut zuzustellen.
Einen anderen MX zu verwenden, bringt i.d.R. recht wenig, da in einem sauberen Setup alternativ MX die gleichen Massnahmen haben wie der primäre - also das Greylisting auch dort zuschlägt. Ein alternativer MX sollte IMHO nur verwendet werden, wenn er die gleiche Priorität hat oder der mit der höchsten Priorität nicht erreichbar ist.

 

[Yorin]

Die Abweisung erfolgt durch einen temporären Fehler.

Wie sollte der temporäre Fehler aussehen, damit der ausliefernde Mailserver erkennt, dass es sich um Greylisting handelt, er nach entsprechendem Zeitablauf einen erneuten Zustellversuch an den primären MX unternimmt und nicht an die alternativen MX sendet?

Häufig verwendet zu werden scheint der Bounce "451 Greylisted, please try again in X seconds". Ist das irgendwo spezifiziert?

 

[Joe User]

Im SMTP ist spezifiziert wie Mailserver mit temporären Fehlern (4xx) umgehen sollen und diese Vorgaben nutzt Greylisting aus, deshalb gibt es auch keinen Standard zu Greylisting.

Greylisting missbraucht also lediglich die 4xx im SMTP und nicht mehr.

Das Ganze funktioniert deshalb so gut, weil Spammer ihren Spam einfach nur möglichst schnell abkippen wollen und deshalb auf die konforme Behandlung von Statusmeldungen verzichten. Abkippen und weiter zum nächsten Mailserver, dort abkippen und wieder weiter, usw usw. Das Auswerten von Statuscodes ist zu aufwendig und zeitraubend und bringt Spammern somit keinen Verdienst ein, also wird es weggelassen und Greylisting funktioniert (noch).

Sobald Spammer Statuscodes auswerten und konform behandeln, wird Greylisting nicht mehr funktionieren.


Ansonsten: 451 ist korrekt, siehe SMTP.
Best practice siehe RFC 6647 Kapitel 5

 

[Yorin]

Im SMTP ist spezifiziert wie Mailserver mit temporären Fehlern (4xx) umgehen sollen

Ich finde im RFC 5321 nichts Spezifischeres als diese Passage aus dem Abschnitt 4.2.1:

4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again. The sender should return to the beginning of the command sequence (if any). It is difficult to assign a meaning to "transient" when two different sites (receiver- and sender-SMTP agents) must agree on the interpretation. Each reply in this category might have a different time value, but the SMTP client SHOULD try again. A rule of thumb to determine whether a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be successful if repeated without any change in command form or in properties of the sender or receiver (that is, the command is repeated identically and the receiver does not put up a new implementation).

Insbesonders bleibt meine Ausgangsfrage unklar: Falls es beim Adressaten alternative MX-Einträge gibt, was ist dann Mittel der Wahl nach Abweisung der Mail: Zustellversuch bei anderem MX oder erneuter Zustellversuch bei gleichem MX?

Man könnte nun aus "The sender should return to the beginning of the command sequence" herauslesen, dass ein erneuter Zustellversuch beim gleichen MX zu starten ist. Doch wirklich eindeutig finde ich das nicht.

Ansonsten: 451 ist korrekt, siehe SMTP.

Wobei nach der Lektüre des RFC mir nun 450 regelkonformer erscheint: "Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons)".

Best practice siehe RFC 6647 Kapitel 5

Naja, das hatte ich mir ja angesehen und finde dort kaum spezifische Vorgaben. Es werden recht breite Spielräume und allgemeine Vorgehensweisen empfohlen. Entsprechend heißt es dort auch unmissverständlich:

There is no specific recommendation as to the specific choice of 4yz code to be returned as a result of a greylisting delay.

 

[danton]

Ich finde im RFC 5321 nichts Spezifischeres als diese Passage aus dem Abschnitt 4.2.1:

Im Abschnitt 4.5.4 sind die Retry-Stragien beschrieben.

Insbesonders bleibt meine Ausgangsfrage unklar: Falls es beim Adressaten alternative MX-Einträge gibt, was ist dann Mittel der Wahl nach Abweisung der Mail: Zustellversuch bei anderem MX oder erneuter Zustellversuch bei gleichem MX?

Ich interpretiere Abschnitt 5.1 so, dass man bei gleicher Priorität einen anderen nehmen kann - bei gleicher Prio muß zufällig einer gewählt werden, um die Last zu verteilen. Da lt. RFC 6647 mehrere MX eine gemeinsame Greylist-DB nutzen sollten, spricht da nichts gegen.
Auch sollte das Verfahren kein anderes sein, wenn der Grund für den temporären Fehler Greylisting ist oder was anderes.

Wobei nach der Lektüre des RFC mir nun 450 regelkonformer erscheint:

Das kommt drauf an. Wenn du die Verbindung direkt beenden willst, muß es ein 421 sein.

 

[Yorin]

Vielen Dank für deine Einschätzungen.

Im Abschnitt 4.5.4 sind die Retry-Stragien beschrieben.

Ja, aber etwas Spezifisches, wie Mailserver mit temporären Fehlern umgehen sollen, finde ich dort weiterhin nicht. Da scheint es einen relativ weiten Spielraum zu geben.

Ich interpretiere Abschnitt 5.1 so, dass man bei gleicher Priorität einen anderen nehmen kann - bei gleicher Prio muß zufällig einer gewählt werden, um die Last zu verteilen. Da lt. RFC 6647 mehrere MX eine gemeinsame Greylist-DB nutzen sollten, spricht da nichts gegen.

Sehe ich genauso. Ich hatte allerdings wohl nicht deutlich gemacht, dass es mir um unterschiedlich priorisierte MX geht (was vermutlich die häufigere Konstellation ist).

Auch sollte das Verfahren kein anderes sein, wenn der Grund für den temporären Fehler Greylisting ist oder was anderes.

Logisch fände ich bei 450 erneuter Zustellversuch an selben MX, bei 451 Zustellversuch an alternativen MX.

Das kommt drauf an. Wenn du die Verbindung direkt beenden willst, muß es ein 421 sein.

Korrekt. Ist halt ein anderes Szenario.