Frage zu ausgehenden Mails via Postfix

Domi

Member
Hallo Leute, ich habe da mal eine kleine Frage an Euch und hoffe das Ihr mir helfen könnt... falls das überhaupt funktioniert, wie ich mir das vorstelle.

Es geht um folgende Situation, Chef hat in seinem Thunderbird ein / zwei Gruppen erstellt, wo er Informationen versendet. Ob Sinn oder Unsinn lässt sich streiten, tut aber nichts zur Sache... :)

Nun hat er da ca. 100 Personen drin und ab und an meldet Thunderbird dann das eine Email Adresse nicht funktioniert. Keine Ahnung ob das jetzt vom Thunderbird kommt, oder vom Postfix... aber, kann man dem Postfix irgendwie sagen das er die Emails einfach raus senden soll?? Wenn dann ein Mail-Delivery zurück kommt, ist das so... aber er sucht sich immer einen Wolf, weil er die Fehlermeldungen nicht interpretieren kann und nervt mich dann immer :D

Frage ist nur... was müsste ich denn am besten anpassen?
Aktuell sehen die restrictions in der main.cf wie folgt aus,
Code:
smtpd_recipient_restrictions =
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 reject_unknown_sender_domain,
 reject_unknown_recipient_domain,
 permit_sasl_authenticated,
 permit_mynetworks,
 reject_rbl_client zen.spamhaus.org,
 check_policy_service inet:127.0.0.1:60000,
 reject_unverified_recipient,
 reject_unauth_destination,
 permit

smtpd_helo_restrictions =
 permit_mynetworks,
 permit_sasl_authenticated,
 reject_invalid_helo_hostname,
 reject_non_fqdn_helo_hostname

smtpd_sender_restrictions =
 reject_non_fqdn_sender,
 reject_unknown_sender_domain,
 permit_mynetworks,
 permit_sasl_authenticated
vielleicht hat ja jemand für mich einen Tipp, was man anpassen könnte. Dieser Server ist ein vServer der im RZ von Hetzner steht, Chef sendet die Mails vom Thunderbird an Postfix und Postfix schickt diese dann nur noch weiter. Also so ziemlich das übliche verfahren, wie man es von einer GMX oder T-Online Adresse auch kennt...

Gruß, Domi
 
Hmm, der Abschnitt sieht mir etwas konfus aus
# -> das bedeutet diese Beschränkungen werden bei RCPT TO geprüft
smtpd_recipient_restrictions =
# ist das nicht schon in den Sender-Restriction geprüft worden?
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
# dito ^^
reject_unknown_sender_domain,
# das wird wohl das Problem mit der Fehlermeldung beim Versand verursachen
reject_unknown_recipient_domain,
# Prüfen wir das nicht schon während des HELO?
permit_sasl_authenticated,
permit_mynetworks,
# Wäre das nicht sinnvoller bei den Sender-Restrictions? wir nehmen ja eh nur Mail für uns selbst an
reject_rbl_client zen.spamhaus.org,
check_policy_service inet:127.0.0.1:60000,
# auch das kann für die Fehlermeldung beim Versand sorgen
reject_unverified_recipient,
reject_unauth_destination,
permit
 
Moin TerraX,

ja das eine oder andere wird bestimmt doppelt gemoppelt sein. Ich habe hier oft im Forum auch Links zu Erklärungen der restrictions bekommen, mit der Bitte diese zu lesen. Habe ich auch getan, aber irgendwie sind diese immer noch ein totales Mysterium für mich :o :(

Neben helo, sender und recipient gibt es ja noch ein oder sogar zwei Regeln die er prüfen könnte, aber ich vermute mal dann bräuchte ich schon fast einen Strick.

Wenn ich das Prinzip der restrictions richtig verstanden habe, dann prüft er helo, sender und recipient nicht gleichzeitig, sonder nacheinander und diese Regeln geht er von oben nach unten durch, aber welche Regel nun wo genau Sinn macht und Unsinn ist, erklärt sich mir noch nicht so richtig.

Es funktioniert, keine Frage... aber wenn Chef dann irgendwann mal eine seiner Witz Mails versendet, oder irgendwo etwas über Angriffe, unsichere EDV etc. gefunden hat, kommt es irgendwann auch mal vor das die Mail nicht raus geht... Leider hatte ich mir dazu nie einen Screenshot gemacht, aber vorhin kam mir der Gedanke das ich mal anfrage ob jemand ungefähr weiß woran es harken könnte :o
 
Wie ist es denn mit der Reihenfolge, muss diese auch unbedingt beachtet, das ist es was mich auch oft verwirrt hat... vielleicht komme ich ja dann ein Schritt weiter mit meinem Verständnis.

Nachtrag: Also wenn ich mir von einem fertigen System, dass mit ISPconfig eingerichtet wurde, die main.cf anschaue, ist meine regel doch recht groß...
Code:
smtpd_recipient_restrictions =
 permit_mynetworks,
 permit_sasl_authenticated,
 check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf,
 reject_unauth_destination
 
Last edited by a moderator:
Wie ist es denn mit der Reihenfolge, muss diese auch unbedingt beachtet, das ist es was mich auch oft verwirrt hat... vielleicht komme ich ja dann ein Schritt weiter mit meinem Verständnis.

Nachtrag: Also wenn ich mir von einem fertigen System, dass mit ISPconfig eingerichtet wurde, die main.cf anschaue, ist meine regel doch recht groß...

Ja, die Reihenfolge ist absolut wichtig, sogar sicherheitskritisch (siehe auch: http://www.postfix.org/SMTPD_ACCESS_README.html#danger). Und ja, in Deiner main.cf gibt es "Optimierungspotential".
 
Diese Restrictions reichen für ein 0815-Setup:
Code:
smtpd_client_restrictions =
    sleep 1,
    reject_unknown_reverse_client_hostname,
    permit
smtpd_data_restrictions =
    reject_unauth_pipelining,
    permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions =
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    permit
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client ix.dnsbl.manitu.net,
    reject_rbl_client cbl.abuseat.org,
    permit
smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    permit
smtpd_sender_restrictions =
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    permit
 
Moin, habe mir das mal ein wenig angeschaut und auf einem meiner Testserver ein wenig durchgespielt... Kann es sein, dass der Parameter
Code:
smtpd_recipient_restrictions = reject_unauth_destination
gesetzt sein muss?

Ich hatte diesen einzelnen Parameter mal entfernt und bekam von Postfix sofort folgende Meldung zurück geschmättert, als ich vom Thunderbird eine Email versenden wollte...
Code:
fatal: parameter "smtpd_recipient_restrictions": specify at least one working instance of: check_relay_domains, reject_unauth_destination, reject, defer or defer_if_permit
 
Kann es sein, dass der Parameter
Code:
smtpd_recipient_restrictions = reject_unauth_destination
gesetzt sein muss?
Wenn Du noch einen alten Postfix verwendest, dann ja, denn smtpd_relay_restriktions gab es bei älteren Postfix noch nicht.
Muss dann direkt hinter permit_sasl_authenticated eingefügt werden.
 
Last edited by a moderator:
Joa, scheint dann eine ältere Version von Postfix zu sein... habe einfach die Version installiert, die mir bei apt vorgeschlagen wurde.
Code:
dpkg -l postfix*
ii  postfix               2.9.6-1~12.04.1
ii  postfix-mysql         2.9.6-1~12.04.1
Aber gut zu wissen und vielen Dank für die Informationen, ich werde es mal ausprobieren.

Gruß, Domi
 
Nabend Leute, eine kleine Frage zu dieser Geschichte habe ich noch kurz :)

Kann ich in der smtpd_client_restrictions = permit_sasl_authenticated hinzufügen, oder gibt es dann Probleme?
Code:
################
# SMTPD restrictions
smtpd_client_restrictions =
 permit_sasl_authenticated,
 sleep 1,
 reject_unknown_reverse_client_hostname,
 permit

Ein phpmailer Skript was ich gebaut habe, kann dann auf dieser Art die Mails schneller versenden und ackert nicht für 35 Mails um die 50 Sekunden rum :)

Gruß, Domi
 
Ja, kannst Du machen. Du kannst auch das sleep 1 dort rausnehmen, was nur zum Ausbremsen von Spambots und kaputten Mailclients drin ist.
 
Ja, kannst Du machen. Du kannst auch das sleep 1 dort rausnehmen, was nur zum Ausbremsen von Spambots und kaputten Mailclients drin ist.
Ne, ist alles top... Problem war nur das phpmailer sich von einer IP versucht hatte anzumelden, die keinen PTR besitzt und da hat Postfix sofort zu gemacht. Darum hatte ich diese Regel einfach zu geschoben und alles passt :)
 
Back
Top