reject_unknown_recipient_domain - Wie ist eure Meinung dazu?

[magic]

Hallo,

Wie ist eure Meinung zu der Restriktion reject_unknown_recipient_domain von Postfix?? Ist es sinnvoll diese zu benutzten oder sollte man es besser sein lassen?? Es scheint ja auch ein paar richtige / echte Mailserver zu geben, die mit dieser Restrikion draußen bleiben...

Gruß
Maik

[dodolin]

Die Doku sagt dazu:

Code: Select all

reject_unknown_recipient_domain
    Reject the request when the RCPT TO address has no DNS A or MX record and Postfix is not final destination for the recipient address. 

Code: Select all

Es scheint ja auch ein paar richtige / echte Mailserver zu geben, die mit dieser Restrikion draußen bleiben... 

Wenn, dann sind das keine Mailserver, sondern Domains.
Aber trotzdem will ich nicht glauben, dass das False Positives machen kann. Der Postfix könnte die Mails doch eh nicht zustellen. Ergo ist es besser, den Schrott erst gar nicht anzunehmen, wenn er das schon vorher weiß.

[magic]

ähmm... ohh ja... :oops:

Da habe ich die Regel falsch interpretiert...

Aber die Regel die eigentlich meinte - jetzt habe ich es auch ausporbiert - ist
reject_unknown_client

Code: Select all

 reject_unknown_client
    Reject when the client hostname is unknown. The unknown_client_reject_code parameter specifies the response code to rejected requests (default: 450).

Was hälst du davon??

Insgesammt sehen meine Restriktionen so aus:

Code: Select all

smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_non_fqdn_hostname, reject_unknown_recipient_domain, reject_invalid_hostname, reject_unknown_sender_domain, reject_rbl_client,  reject_unauth_pipelining, reject_unknown_client, permit_mx_backup, reject_unauth_destination

Gruß
Maik

[dodolin]

permit_mx_backup halte ich für problematisch. Die Doku sagt dazu ebenfalls:

Use the optional permit_mx_backup_networks parameter to require that the primary MX hosts match a list of network blocks.

Dazu würde ich dringend raten, sofern man permit_mx_backup wirklich unbedingt nutzen muss. IMHO ist das nur nötig, wenn man wirklich eine riesige Anzahl Domains zu verwalten hat.

reject_unknown_client hat gewiss diverse False Positives (FP). Ob du gewillt bist, diese zu akzeptieren, musst du selbst entscheiden. Ich selbst würde wohl eher dazu übergehen, bei solchen "Wahrscheinlich Spam, aber FP nicht auszuschließen" Kriterien eher dazu übergehen, ein paar SA-Punkte zu vergeben oder die SMTP-Reply-Codes etwas zu verzögern, etc. - sodass echte Mails trotzdem noch zugestellt werden können. Geschmacksache. Große Provider wie AOL etc. haben ein Ã?quivalent zu reject_unknown_client z.B. laufen und erzwingen es. Davon betroffene Hosts werden also früher oder später sowieso Probleme bekommen, ihre Mails zuliefern.

[magic]

Hi dodolin,

Danke für deine Antwort!
Bei mir ist das eMailaufkommen (nicht SPAM) nicht so groß, es sind etwa 200 eMail am Tag, daher wollte ich mal wissen, wie andere es sehen.
Mit dem reject_unknown_client hatte ich bisher kaum FP, nur einem mit einer großen Werbeagentur in Hamburg. Aber deren Mailsserver war sowieso komisch, der hat trotz dem Reject der eMail tagelang versucht die eMail zu zustellen.....

Danke auch für en Hinweise zum permit_mx_backup... meine "riesige Anzahl Domains" besteht nur aus zwei Hände voll! ;-) Da brauch man das wohl noch nicht.

Gruß
Maik

[dodolin]

Aber deren Mailsserver war sowieso komisch, der hat trotz dem Reject der eMail tagelang versucht die eMail zu zustellen.....

Das könnte auch an deinem Postfix gelegen haben. Was ich bisher so in der Doku gelesen habe, gibt es einige Default-Einstellungen, dass ohne spezielle Konfiguration ein 4er (temporärer) Fehler ausgegeben wird. Dann ist es völlig korrektes Verhalten, wenn es die Gegenseite nochmals versucht. Du solltest sicherstellen, dass du einen 5er (permanenten) Fehlercode sendest, wenn du keine weiteren Zustellversuche dieser einen Mail mehr wünschst.

Da brauch man das wohl noch nicht.

Ja. In diesem Fall würde ich die Domains von Hand in der MTA-Konfig einstellen. Ist sicherer und im Notfall auch wesentlich einfacher zu debuggen.

[magic]

:oops:
ähmmm............
ups, das stand in dem Howto nicht... Aber du hast recht, es wurde ein 450 gesendet.
ein postconf ergab

Code: Select all

unknown_client_reject_code = 450

:(
naja, nun ist es ein Fehler weniger! :)

Danke
Maik

[dodolin]

ups, das stand in dem Howto nicht...

Das kommt davon, wenn man unreflektiert Howtos abtippt. Gerade im Bereich MTA und Spamverminderung ist das ein sehr kritisches Feld. IMHO sollte ein gutes Howto in diesem Bereich auf sämtliche Auswirkungen/Nebenwirkungen hinweisen, damit die Howto-Nutzer eine bessere Entscheidungsgrundlage Pro/Contra gewisse Techniken haben und nicht einfach nur abtippen, ohne sich genau über die Implikationen bewusst zu sein.

[magic]

Da geb ich dir recht! Ich hatte mir auch gedanken gemacht, was die einzelnen Restriktionen für Bedeutungen haben. Dabei habe ich auch für mich entschieden gehabt, dass das permit_mx_backup wohl nicht unbedingt verkehrt sei.
Nur über die Default Codes der Restriktionen hab ich mir keine gedanken gemacht, die hatte ich nicht auf dem Schirm.

gutes Howto in diesem Bereich auf sämtliche Auswirkungen/Nebenwirkungen hinweisen

Find ich auch, zu mal mir nicht sämtliche Aus- und Nebenwirkungen bekannt sind, bzw. erst im Betrieb auffallen. :( Liegt wahrscheinlich auch daran, dass ich mehr aus der Theorie weiß als aus Praxis.