Restrictions

Um Spam vorab einzuschränken, können wir postfix Regeln in Form von Restriktionen in die Hand geben.
Zum Beispiel, haben wir ja bereits (per default ist das so) festgelegt, dass postfix KEIN "open relay" ist.

root# postconf smtpd_recipient_restrictions
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
root#

Hier legten wir fest, dass Niemand ausser clients eMail in die weite Welt senden dürfen, die member von "$mynetworks" sind. Ausserdem dürfen bzw. werden keine eMail angenommen, die nicht für eine destination (domain) bestimmt ist, die an unserem mailserver gehostet wird.

Folgende Parameter sind für uns interessant:

• smtpd_delay_reject
  legt fest, dass jegliche Regel erst nach "RCPT TO:" greifen soll, da manche clients es einfach net akzeptieren wollen, wenn sie vor RCPT TO: einen reject bekommen - die würden einfach gleich wieder probieren, auf die gleiche Art zu feuern
• smtpd_client_restrictions
  greift vor HELO
• smtpd_helo_required
  hier sagte ich mit yes, dass ein HELO/EHLO notwendig ist
• smtpd_sender_restrictions
  bei MAIL FROM:
• smtpd_recipient_restrictions
  greift nach RCPT TO
• smtpd_data_restrictions
  für den data-part
• header_checks
  für den header
• body_checks
  für den Textteil
• strict_rfc821_envelopes
  yes/no - legt fest, ob die geschriebenen eMail-Adressen in MAIL FROM bzw. RCPT TO streng konform gehen müssen mit rfc821 - das kann nach hinten los gehen, da es einige clients gibt, die sich eben nicht so streng daran halten -

Wenn Restriktionen gesetzt werden, dann ist immer abzuwägen, ob es mehr spammer oder "gut Freund"-eMail angät.
Guter Tip am Rande: den nachfolgend beschriebenen Parametern kann ein "warn_if_reject" vorangestellt werden, was bedeutet, dass man in den mail-logfiles eine Warnung hingeschrieben bekommt, dass die Restriction gegriffen hätte, wäre sie scharf gewesen. Das ist also zuper, wenn man gewisse restrictions nur testen möchte!

mögliche Werte

Wenn "smtpd_delay_reject = yes" gilt, dann greifen die restrictions oberhalb bis inklusive RCPT TO: erst unmittelbar nach RCPT TO:!
Was so verwirrend ist, am Anfang, ist, dass z.B. smtpd_recipient_restrictions AUCH restrictions den Sender, den Client oder des helo/ehlo beinhalten kann! Denn, der Parameter sagt nicht aus, dass die Regeln nur den recipient angehen, sondern vielmehr, dass die Regel an der Stelle RCPT TO: (nach Eingabe) gechecked werden. Das bedeutet, unsere allermeisten Regeln machen ohnehin in diesem Parameter Sinn!

Es gilt wieder die Form:
param = wert1 wert2 wert3
oder Sie schreiben die Werte untereinander ...
Wichtig - die Parameternamen müssen am Zeilenanfang beginnen.
UND
die Reihenfolge der Werte sind wichtig - ähnlich zur Firewall

• reject_unauth_destination
• reject_non_fqdn_sender
• reject_invalid_hostname
• reject_non_fqdn_hostname
• reject_unlisted_recipient
• reject_unknown_hostname
• reject_unknown_sender_domain
• reject_rbl_client xxxxx
  diverse blackhole lists
• permit
• reject
• check_client_access </pfadzu/lookup-table>
  lookup-table enthät hostnames oder IP-Adressen als key, und die Aktion als value
• check_recipient_access </pfadzu/lookup-table>
  
• check_sender_access </pfadzu/lookup-table>
  
• check_helo_access </pfadzu/lookup-table>