Beschränkungen im SMTP Dialog

[jahlives]

About
Postfix, der SMTP Part der Mailstation, erlaubt es sehr detailliert auf allen Stufen des SMTP Dialogs Prüfungen anzulegen und darauf basierend Emails resp Clients abzulehnen.
Dazu bietet Postfix in der Konfigurationsdatei /usr/syno/mailstation/etc/main.cf diverse Einstellungsmöglichkeiten und Prüfungen der verschiedenen SMTP "Stationen". Zusätzlich - und das macht Postfix so flexibel - wird die Möglichkeit geboten bei jeder Stufe des SMTP Dialogs userspezifische reguläre Ausdrücke zu verwenden und entsprechend deren Resultaten zu reagieren.
Die Konfiguration von SMTP und den verschiedenen Stufen der Prüfung ist sehr umfangreich (gibt ganze Foren zu diesem Thema). Im folgenden möchte ich auch zwei sehr gute Beiträge zum Thema verweisen: Beitrag bei jimsun.linxnet.com (englisch) und eine gute deutsche Zusammenfassung bei chains.ch.
Auch kann es nicht schaden sich den Ablauf der SMTP Dialogs nochmals vor Augen zu führen. Denn an diesem Ablauf orientiert sich die Reihenfolge der Prüfungen. So ist es z.B. schlecht wenn eine HELO Prüfung nach der Sender Adress Prüfung gesetzt wird, denn angekommen bei der Senderdirektive ist das HELO bereits Geschichte: Das heisst also die Reihenfolge der Direktiven und ihrer Optionen (zumindest im 2. Abschnitt) ist wichtig für ein korrektes Alaufen der Prüfungen

Sinn und Zweck
Viele werden sich fragen, warum man überhaupt so einen Aufwand betreiben sollte. Kurs und bündig: Verminderung von Spam. Wiederum könnte man fragen: Aber warum denn man kann ja spamassassin einfach mit Postfix koppeln und der Spam fliegt raus. Wiederum kurze Antwort: Verminderung der Serverlast.
Was so offensichtlich Spam ist, dass es von den Postfix Regeln erkannt werden kann, sollte man dem Spamassassin gar nicht servieren. Neben dem Spamassassin wird so auch die Last auf dem Postfix vermindert. Denn die Emails werden so verworfen bevor auch nur eine Zeile in die Mailwarteschlange (und damit dem Dateisystem) geschrieben wurde. Ausserdem sind die regulären Ausdrücke von Postfix nicht so ressourcenhungrig wie diejenigen vom Spamassassin. Der SA kann u.U. tausende von regulären Ausdrücken habe und das geht auf die Zeit.
Ich habe das bei mir zu Hause getestet (ein Postfix Port mit Spamassassin und einer ohne). Die Verarbeitung ohne Spamassassin war in dem Moment wo ich auf Senden geklickt habe bereits abgeschlossen und die Email in der Inbox. Beim Versand via SA Port kann das bis zu 2 Sekunden dauern, ehe die Email im Eingang ist

Beispiel aus der main.cf
Nachfolgend findet ihr die Konfiguration, so wie ich sie bei meinem Postfix Server einsetze. Das soll ganz klar nicht "die Lösung" sein, sondern einfach zeigen wie man es machen kann. Dazu habe ich die Konfiguration in drei Abschnitte eingeteilt und werde die nacheinander abarbeiten und kommentieren. Dabei ist wie obenerwähnt die Reihenfolge beim 2. Abschnitt sehr wichtig!

smtpd_delay_reject = no
smtpd_helo_required = yes

smtpd_client_restritions = check_client_access regexp:/opt/etc/postfix/check_client, permit_mynetworks, reject_unknown_client, reject_rbl_client, reject_rhsbl_client
smtpd_helo_restrictions = check_helo_access regexp:/opt/etc/postfix/check_helo, permit_mynetworks,reject_unknown_hostname, reject_invalid_hostname, reject_non_fqdn_hostname
smtpd_sender_restrictions =  reject_unknown_sender_domain, check_sender_access regexp:/opt/etc/postfix/sendermaps
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_rbl_client pbl.spamhaus.org, reject_unauth_destination
smtpd_data_restrictions = reject_unauth_pipelining

body_checks = regexp:/opt/etc/postfix/body_check
mime_header_checks = regexp:/opt/etc/postfix/mime_check

Weiter geht's unten, der Thread wurde zu lang

 

[jahlives]

Beschränkungen im SMTP Dialog (II)

Weiter geht's
Hier als die Erklärungen zum Config File. Sorry der Thread wurde zu lange. Ich musste aufsplitten
1. Abschnitt
Hier setze ich zwei grundlegende Werte

• smtpd_delay_reject = no/yes
  Legt fest wann Postfix bei einer Regelverletzung reagieren soll. NO heisst ohne Delay also sofort bei der Feststellung und YES erst am Ende, wenn wie Empfängeradresse im SMTP Dialog ebenfalls übermittelt wurde
• smtpd_helo_required = yes/no
  Legt fest ob bei einer Verbindungsaufnahme durch den Client, das durch das RFC vorgeschriebene HELO resp EHLO Kommando verlangt wird oder eben nicht. Mailserver und Emailclients verwenden das immer, aber bei "Eigengewächsen" kann es sein, dass erwünschte Emails deswegen nicht ankommen. YES ist jedoch ein guter Wert, weil auch viele Spambots schlampig programmiert sind und das HELO häufig unterlassen

2. Abschnitt
Hier kommen also die entscheidenen Anweisungen für den Postfix und wie bereits erwähnt ist die Reihenfolge wichtig. Neben Standartchecks (z.B. reject_unknown_sednder_domain) sieht man mehrere Anweisungen die ein regexp:/ beinhalten. Dabei handelt es sich um Files mit regulären Ausdrücken, die Postfix beim SMTP Dialog ebenfalls verwenden soll.

• smtpd_client_restrictions
  Bevor der Server überhaupt einen SMTP Dialog für den Client öffnet wird diese Direktive ausgeführt. Dabei werden Prüfungen auf IP Basis des Clients ausgeführt (der Hostname kommt erst im HELO zum Zug)
  Zuerst lege ich über ein userspezifisches File einen oder mehrere reguläre Ausdrücke fest, bei denen der weitere Zugriff verboten wird. Hier kann man IP Adressen von bekannten Spammern einbauen
  

  /^.213\.76\.24\.12$/  REJECT  You're not allowed to connect to this system!

  Dann erlaube ich Clients aus dem gleichen Netzwerk grundsätzlich den Zugriff (permit_mynetworks). Diese Konfig erlaubt allen IPs aus dem gleichen Subnetz (siehe mynetworks-Konfig Variable in main.cf) den Zugriff. Wenn der Server direkt im Inet hängt (ohne Router mit NAT) dann sollte diese Variable sehr genau definiert werden. Für ein LAN ist es jedoch okay dem Subnetz den Zugriff zu gewähren.
  Dann werden ungültige Clients verworfen (ungültige IP Adressen) und dann erfolgt eine Prüfung ob die Client IP in einer Blacklist steht
• smtpd_helo_restrictions
  Dies ist die erste Stufe des SMTP Dialogs (der Server hat den Client grundsätzlich aktzeptiert)
  Wiederum prüfe ich zuerst mit einem RegExp File auf bekannte Spammer. Diesmal aber auf Domainnamen, da eigentlich im HELO Kommando der Hostname des sendenden Systems angegeben werden sollte
  

  /^.*mymainserver.com$/  REJECT  You're not allowed to connect to this system!

  Alles was von mymainserver.com kommt wird gleich verweigert
  Dann wiederum erlaube ich lokalen Clients den Zugriff.
  Danach kommt eine Prüfung ob der Hostname vorhanden ist, wenn nein und tschüss
  Dann eine Prüfung auf ungültige Hostnamen und darauf dass ein FQDN (fully qualified domain name) verwendet wurde
• smtpd_sender_restrictions
  Hier kann man eigentlich nicht furchtbar viel prüfen.
  Ich prüfe hier auf gültige Domainnamen. Also solche die einen DNS Record besitzen.
  Mittels eines reguläres Ausdrucks in einem File mache ich dann weitere Prüfungen auf den Sender
  

  if /^.*MY_DYNDNS_NAME\.MY_DYNDNS_DOMAIN\.net/
  !/^(user1|postmaster|root)@MY_DYNDNS_NAME\.MY_DYNDNS_DOMAIN\.net$/ 550 Forbidden Sender
  endif
  /(.*\.cn|.*\.sg|.*\.co|.*\.tw)$/ 550 Forbidden Top Level Domain
  /@MyMainServer.com/ 550 Go Home, Jerk!

  Für eine Emailadresse, die vorgibt vom meinem Server zu sein prüfe ich ob die Accounts lokal existieren und wenn nicht dann tschüss
  Zusätzlich prüfe ich auf verbotene TLDs bei Absender Adressen
• smtpd_recipient_restrictions
  Das ist eine sehr wichtige Konfigurationsvariable. Ein Fehler hier und euer System wird zum offenen Relay Server.
  Zuerst wird einem Client dessen User sich mit einem lokalen Account anmelden konnte, der Zugriff (auch auf den Relay) erlaubt.
  Dann das gleiche für Clients aus meinem Subnet.
  Nun kommt eine Prüfung der Adresse mittels einer Blacklist.
  Die letzte Anweisung sollte immer reject_unauth_destination lauten. Damit erlaubt der Postfix eine Email nur dann wenn der Account lokal existiert (natürlich nur wenn davor kein permit die Prüfung bereits abgebrochen hat). Setzt ihr die Var nicht, dann kann ein Sender, der beide permits nicht erfüllt, dessen Empfangsadresse aber auch nicht auf einer Blacklist steht JEDE Email Adresse als Empfänger angeben und der Server wird nicht-lokale Emails via Relay zustellen (offener Relay Server). Das bringt Euch dann, sobald ein Spammer das bemerkt hat, ganz schnell auf die schwarzen Listen der Provider.
  Anbei ein Ausschnitt aus dem SMTP Dialog meines Postfix mit einem Spammer von heute
  

  Transcript of session follows.
  
   Out: 220 MY_DNS_HOST ESMTP Postfix
       (2.5.5)
   In:  HELO mailer
   Out: 250 MY_DNS_HOST
   In:  MAIL FROM:[EMAIL="john34@gmail.com"]<john34@gmail.com>[/EMAIL]
   Out: 250 2.1.0 Ok
   In:  RCPT TO:[EMAIL="donald.presario@maximumlist.com"]<donald.presario@maximumlist.com>[/EMAIL]
   Out: 554 5.7.1 Service unavailable; Client host [117.66.194.98] blocked using
       pbl.spamhaus.org; [URL]http://www.spamhaus.org/query/bl?ip=117.66.194.98[/URL]

  In diesem Beispiel hat also die Blacklist Regel in recepient_restrictions zugeschlagen. Dies zeigt schön, dass die Optionen von links nach rechts abgearbeitet werden. Hätte der Client nicht auf der Backlist gestanden, dann hätte das reject_unauth_destination diese Email verworfen. Ohne diesen reject würde die Email ausgeliefert!!
  Ein ganz aufmerksamer Leser könnte jetzt rufen: "Hei deine Config scheint nicht zu funzen, sonst hätte obige Email bereits beim HELO Check verworfen werden müssen. Kein FQDN als Name!" So ist es mir zumindest ergangen als ich dieses Beispiel eingefügt habe. Aber nur Beruhigung ich habe den HELO check bei mir auskommentiert, da ich mal ein bissl mehr Spam kriegen möchte, um die regulären Ausdrücke zu verfeinern
• smtpd_data_restrictions
  Viele Spambot Schreiber ersparen sich die Mühe den SMTP Dialog ihrer Bots korrekt gemäss RFC zu implementieren oder reagieren/warten nicht korrekt auf Anworten des Servers. Häufig gesehen bei Spambots ist es, dass sie bereits direkt nach dem DATA Client Kommando mit der Datenübertragung anfangen wollten, bevor der Server sein "okay to send data" (unauthorized pipelining) schicken konnte. Solche Clients können bedenkenlos knallhart abgewürgt werden.

Die letzte Direktive muss man ein bisschen abgetrennt von den anderen beachten (man könnte sie auch in den 3. Abschnitt verfachten). Denn bei allen bis auf die letzte Direktive weiss der Client oder Spammer nicht ob die Empfangsadresse überhaupt existiert resp aktzeptiert wurde. Meist probieren Spammer bei einer Domain mehrere Emailadressen aus, bis sie eine finden die aktzeptiert wird.
Bei einer Fehlermeldung bei der letzten Direktive weiss der Client oder Spammer aber bereits, dass die Adresse aktzeptiert wurde. Und kann eine erneute Zustellung mit einem besseren Benehmen versuchen.

3. Abschnitt
Wie bereits oben erwähnt weiss der Client oder Spammer zu diesem Zeitpunkt bereits, dass die Emailadresse okay ist. Trotzdem ist Postfix noch in der Lage vor dem finalen "Message Accepted" auf den Inhalt der Email zu reagieren und den Empfang ggf zurückzuweisen.
Dazu werden 3 Direktiven verwendet, wovon ich selber aber nur zwei benutze. Erwähnen möchte ich trotzdem alle drei

• header_checks (in meinem Bsp nicht vorhanden)
  Hier habt ihr die Möglichkeit die Header Daten einer Email mit regulären Ausdrücken zu filtern (ja die Header einer Email gehören zu DATA)
  

  /^Subject:.*(viagra|casino).*/ REJECT I newer win something and already got a huge one, so piss off

  In dem Moment wo eine Betreffzeile mit viagra oder casino daherkommt, macht der Server mit der Meldung hinter REJECT dicht. Dies noch bevor der Client auch nur eine weitere Zeile schicken konnte
• mime_header_checks
  Dieses File ist dafür zuständig die einzelnen MIME Teile einer Email, die Attachments also anzuzeigen. Auch ein Plain Text ist ein Attachment in diesem Sinne, er wird einfach inline angezeigt.
  

  /name=[^>]*\.(lnk|asd|hlp|ocx|reg|bat|c[ho]m|cmd|exe|dll|vxd|pif|scr|hta|jse?|sh[mbs]|vb[esx]|ws[fh]|wmf)/ REJECT A part of this email contains a MIME type which is not allowed on this server

  Obiger regulärer Ausdruck wird die einzelnen MIME Bestandteile durchsuchen und bei angegebenen Fileextensions blockieren. Dabei werden nur die Header Daten eines MIME Bestandteils durchsucht (jau die Header eines Email Bestandteils gehören in den Body der Email und nicht in den globalen Headerereich)
• body_checks
  Hier geht es jetzt um den Inhalt der einzelnen MIME Bestandteile (man kann zwar auch hier auf die Header des Bestandteils zugreifen, ist jedoch in der mime_header_checks besser aufgehoben
  

  /.*(<a.*href=|http:\/\/|ftp:\/\/|mailto:).*(\.cn|\.sg|\.tw).*/ REJECT Found forbidden TLD in a link in body of this email!

  Obiger RegExp such nach Links mit verbotenen TLDs. Das sind in diesem Beispiel nicht nur HTML Links sondern auch Text Links, die mit http://,ftp:// oder mailto: anfangen.
  Auch hier wird wiederum noch während dem Empfang die Verbindung gekappt und der Client fliegt mit de hinter REJECT angegebenen Meldung raus

So ich glaube für heute habe ich genug geschrieben
Die Sache mit dem Spamassassin im Zusammenspiel mit Postfix werde ich später hier mal posten (einen Wiki Eintrag kann ich auch noch machen falls gewünscht).

Gruss

tobi

 

[jahlives]

Ergänzung..

Wenn ihr nicht riskieren wollt, dass alle Eure manuellen Änderungen an der main.cf eim nächsten Update der FW wieder weg sind, empfehle ich folgenden Weg
1) /usr/syno/mailastation/etc/main.cf in ein Verzeichnis unter /volume1/ kopieren
2) main.cf unter /usr/syno/mailstation/etc editieren und ziemlich weit oben folgenden Eintrag einfügen

alternate_config_directories = /opt/etc/postfix

3) dann könnt ihr die main.cf unter dem angegebenen Pfad nach Herzenslust bearbeiten und habt immer eine funktionierende Ursprungsversion im Default Verzeichnis. Nach einem FW Update müsst ihr einzig obige Zeile wieder in die Haupt-Konfig eintragen und den Postfix neustarten

 

[itari]

Gibt es irgendeinen Grund, warum dieses alles hier nicht im Wiki stehen darf? Hab grad nachgeschaut und darüber nichts gefunden.

Itari

 

[Trolli]

Hat Tobi doch geschrieben:

So ich glaube für heute habe ich genug geschrieben

Die Sache mit dem Spamassassin im Zusammenspiel mit Postfix werde ich später hier mal posten (einen Wiki Eintrag kann ich auch noch machen falls gewünscht).

 

[itari]

Hast recht, hatte ich nicht realisiert.

Itari

 

[jahlives]

Und wohin im Wiki? Unter "Allgemeine Themen", "Internetdienste" und "Mailstation"? Oder unter "Modding Themen" und "nicht unterstützte Konfigänderung" eine Kategorie Mailstation-Mod?
Wo würdet ihr das platzieren?

 

[Trolli]

Ich denke "nicht unterstützte Konfigurationsänderungen" und dort unter dem Titel "Mailstation-Mod" (oder Tuning) könnte schon ganz gut passen.

Trolli

 

[jahlives]

Wiki-Beitrag erstellt: http://www.synology-wiki.de/index.php/SMTP_Dialog_Restriktionen zudem unter Modding eine Kat Mailstation Mods gemacht

 

[Mexx]

@jahlives

danke, ist eine tolle anleitung!

weil wir grade bei der "main.cf" wo trage ich eine zweite domain ein, zur zeit kann ich ja im DSM nur eine Domain eintragen, würde aber gerne noch eine Domain per MX Record auf die DS loslassen

 

[HarryPotter]

# Specify a list of host or domain names, /file/name or type:table
# patterns, separated by commas and/or whitespace. A /file/name
# pattern is replaced by its contents; a type:table is matched when
# a name matches a lookup key (the right-hand side is ignored).
# Continue long lines by starting the next line with whitespace.
#
# See also below, section "REJECTING MAIL FOR UNKNOWN LOCAL USERS".
#
#mydestination = $myhostname, localhost.$mydomain, localhost
#mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
#mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
# mail.$mydomain, www.$mydomain, ftp.$mydomain
mydestination = $myhostname, www.deinedomain1.de, www.deinedomain2.de

 

[Mexx]

thx, und wie weis die DS nun wem welche Mail gehört!

Ich habe es zur Zeit so gelöst, alle User die intern auf die DS zugreifen können haben kein Emailkonto Zugang, da ich alleine das Passwort für jeden User verwalte um Missbrauch nach und von außen zu verhindern.

Für Email Konten habe ich extra User angelegt die wiederum nur per Outlook oder CubeMail auf ihre Mails zugreifen können aber nicht auf Freigaben der DS

nun habe ich zb User "xyz" der natürlich die Mail Adresse xyz@meinedomain1.at hat, wie mach ich nun das user xyz auch die mails von user aaa@meinedomain2.at zugewiesen bekommt?

 

[jahlives]

Zuerst muss du Postfix die Domainnamen bekannt geben für welche Postfix die Endstation sein soll (siehe HPs Post zu mydestination). Wenn also eine Email reinkommt mit einem Domainpart für den sich Portfix zuständig fühlt, dann schaut Postfix nach ob der User (also alles vor dem @) einem bekannten lokalen Account entspricht. Falls ja wird die Email zugestellt, falls nein kriegt der Client ein "REJECTED User not found in local recepient table"
Die Domainnamen sind Postfix eigentlich völlig schnuppe. Braucht Postfix nur um zu wissen für welche Domains er die lokale Mailzustellung versuchen soll

 

[Mexx]

das heisst "mydestination = $myhostname" muss ich nicht ändern nur dahinter die Domain anfügen ?

 

[jahlives]

$myhostname ist eine Variable, die weiter oben mit myhostname gesetzt wird. Meist ist dies der FQDN des Systems. Dahinter kannst du mit Leerzeichen getrennt soviele Alias wie du willst eintragen. Musst nur dafür sorgen, dass ein DNS Server die Alias Namen auch auf die IP der DS auflöst

 

[Mexx]

sorry bin heute etwas langsam mit dem begreifen, wird dran liegen das ich nicht schlafen konnt ^^

den teil mit dem DNS verstehe ich, habe ja einen DNS Admin Zugang für meine Domain´s wo ich die Records eintragen kann und auch die MX Records

nur wo zb. trage ich dann meine zweite Domain dann an, weil du schreibst weiter oben wird myhostname gesetzt ?

und muss ich das www.* angeben ?

# Specify a list of host or domain names, /file/name or type:table
# patterns, separated by commas and/or whitespace. A /file/name
# pattern is replaced by its contents; a type:table is matched when
# a name matches a lookup key (the right-hand side is ignored).
# Continue long lines by starting the next line with whitespace.
#
# See also below, section "REJECTING MAIL FOR UNKNOWN LOCAL USERS".
#
mydestination = $myhostname, localhost.$domainEINS
mydestination = $myhostname, localhost.$domainZWEI
#mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
# mail.$mydomain, www.$mydomain, ftp.$mydomain
mydestination = $myhostname, www.domainEINS.de, www.domainZWEI.de

würd das so passen (wobei die klein-großschreibung habe ich nur zum hervorheben benutzt)

 

[HarryPotter]

nein , falsch, nicht dreimal mydestination (die 2. überschreibt die erste), sondern genauso wie ichs im Beispiel weiter oben geschrieben habe. Also nur deien letzte Zeile, den Rest auskommentieren

 

[HarryPotter]

das heisst "mydestination = $myhostname" muss ich nicht ändern nur dahinter die Domain anfügen ?

Genau, sonst nix ändern

 

[jahlives]

Eine Zeile reicht, sonst passiert, das was HP geschrieben hat

[B][B][FONT=monospace]
[/FONT]mydestination = $myhostname, www.domainEINS.de, www.domainZWEI.de, localhost.domainEINS.de, localhost.domainZWEI.de, mail, mailhost, smtp.$myhostname
[/B][/B]

Schau dir auch mal die var mydomain in der Konfig an. Darüber definierst du die lokale Domain also z.B.

mydomain = localnet

und dann bei mydestination wiederverwenden z.B.

mydestination = $myhostname, $mydomain, mail.$mydomain, smtp.$mydomain