URL: https://www.overclockers.at/linux/greylisting-secondary-mx_252595/page_1 - zur Vollversion wechseln!
Das ist jetzt zwar nicht wirklich linux-related, ich poste es dennoch mal hier ins Subforum...
Folgendes Szenario:
1 Domain, 2 MX Records (mit unterschiedlicher Prio/Preference). Auf Server 1 (prefered) läuft Greylisting, dieser weist mit SMTP-Code 450 ab,
auf Server 2 kein Greylisting (nicht auf meinem Mist gewachsen).
Nun passiert folgendes, jemand schickt eine Mail, dieser Host wird gegreylisted und mit Statuscode 450 abgewiesen, jetzt probiert dieser dann sofort
die Mail an MX2 zuzustellen.
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 probieren 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?!
würde mal annehmen, dass es das Standard-Verhalten eines MTA ist, den secondary zu versuchen, wenn der primary die Nachricht nicht annimmt. Auf das wird man auf der empfangenden Seite wenig Einfluss haben.
persönlich würde ich die Sichherheitsmaßnahmen auf allen MX gleich aufbauen - gibt ja auch genug spammer, die gleich direkt den secondary ansprechen.
und freu dich wenn dann office365 daherkommt, die ändern zwischen den attempts nämlich auch noch die hosts von denen sie raussenden
@uon:
das ist richtig, greylisting auf receiver-mailadresse+sender-ip ist sowieso defacto tot, ist ja auch bei google mit deren mta-farm das gleiche, da kannst sonst gleich alles whitelisten...
Bei Postfix ist es das Standardverhalten (option: smtp_skip_4xx_greeting), bei sendmail ebenso, hab dann auch noch einen thread bei ietf.org gefunden, wo man aber zu keinem direkten Konsens kam, deshalb die Frage ob das wirklich nicht festgelegt wurde was in dem Fall zu tun ist und hier jeder sein eigenes Süppchen kocht...
RFC5321
https://tools.ietf.org/html/rfc5321
Einerseits:
[...]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. However, there MAY also be a configurable
limit on the number of alternate addresses that can be tried. In any
case, the SMTP client SHOULD try at least two addresses.[...]
Andererseits:
4yz Transient Negative Completion reply
[...]Each reply in this category might have a different time value, but the SMTP client SHOULD try again. [...]
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025