[Postfixbuch-users] postfix für unerlaubten Zugriff/Benutzung optimieren / Policy

[Sandy Drobic]

Oliver Strixner wrote:

> Das erste, was du brauchst, ist eine sauber definierte Policy:
> - welche Mails präzise dein Server abweisen
> - welche er annehmen soll
> - wie die Priorität bezüglich Spambekämpfung, Bounces, DSN geregelt ist
> usw. usw.
> 
> Danach kannst du dich daran begeben, diese Policy umzusetzen in Regeln.
> 
> ##################################
> Hallo,
> 
> ok nach den vielen Informationen von der letzten Mail will ich diese
> erstmal verdauen und verstehen. Das System läuft jetzt mit einer leicht
> abgewandelten konfig (wie mitgegeben).
> 
> I) nun zum Entwickeln der Policy.
> 
> Meine Zielsetzung ist es, das mein Mailserver prinzipiell nur Mails
> bearbeitet, für die eingerichteten virtual_mailboxen bzw. die dazugehörigen
> forwardings.

Das ist bereits der Status, wenn Postfix "normal" konfiguriert ist. Per 
Default nimmt Postfix
- Mails für seine eigenen Domains an (ohne auth, permit_mynetworks etc.)
- Mails, die von vertrauenswürdigen Clients kommen (vertrauenswürdig ist dabei 
definiert als "liefert auf einen Check ein "ok/permit", bevor 
reject_unauth_destination abgefragt wird) für alle Domains.


> 1 Verschicken darf nur a  wer eine gültige (mailbox/forwarding)
> email-adresse besitzt (also im from part) b  da sasl_auth konfiguriert, nur
> wer sich authenfiziert hat (ist 1.a dann überflüssig?) c  die from
> email-adresse nicht gefälscht ist (geht das, wenn ja macht das sinn?)

Du kannst festlegen, dass User, die eine Mail relayen wollen und per smtp auth 
sich authentifizieren, nur mit der angegebenen Adresse senden dürfen.
http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch
http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch
http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps

Das ist etwas an Arbeit und kann auch zu erhöhtem Supportaufwand führen, wenn 
man allzu restriktiv ist.

> 2 Einliefern darf nur a  an eine gültige (mailbox/forwarding) email-adresse
> (also im to part) b  der absender kein bekannter spammer ist c   die
> Absender-Adresse nicht gefälscht ist (wenn das geht und sinn macht) d
> idealerweise wenn der content bekannte spam texte enthält (viagra, calis,
> poker, sparkasse.de ...)

Einliefern darf nur, wer bekannte Spam-Texte verwendet?!? [Kratz den Schädel...]

Der Rest sind Restriktionen wie RBLs und Header-/Body-Checks.
Wenn Amavisd-new im smtp_proxy_mode läuft, dann auch mit Spam-Check.


> alles andere sollte, wenn das "gut" für mich ist abgelehnt werden.

Ich mache das z.B. genau anders herum. Ich nehme alles an, sofern der Client 
auf einer Whitelist steht oder die Standard-RBLs und Tests besteht. Bei 
schlechter DNS-Einrichtung/Verdacht auf dynamischer IP setze ich noch weitere 
Checks herein wie Greylisting, weitere RBLs und einige lokale Checks.

Der Sinn des ganzen ist, dass Mails auch dann angenommen werden, wenn das DNS 
mal etwas spinnt. Das kann schneller passieren, als man denkt. Vor einigen 
Tagen ist eine unserer Leitungen gekündigt worden, aber ich hatte den 
zugehörigen DNS noch nicht umgelenkt, also funktionierte das meiste, aber 
vieles kam auch als "host unknown" zurück.

Meine Konfig hatte dann zwar einige zusätzliche Checks durchgeführt, aber die 
Mails kamen trotzdem durch, und das ist eine meiner Hauptprioritäten: 
gewünschte Mails müssen durchkommen.

> Den unterschied zwischen reject und bounce in der Wirkung ist mir noch
> etwas unklar. Da mein Ursprungsproblem wohl zu dem Thema backscatter gehört
> war wohl bouncen unangemessen.
> 
> II) was passiert beim rejecten? III) was passiert beim bouncen?

reject: Mail wird NICHT angenommen, sondern in einem Vorstadium bereits 
abgewiesen. Die Mail bleibt in der Verantwortlichkeit des sendenden Clients: 
Dieser muss die Mail jetzt an den Absender als Bounce zurückschicken, aber:
DIES IST DANN NICHT DEIN PROBLEM, SONDERN DASS DES SENDENDEN CLIENTS!!!

Bounce: Die Mail wird erst angenommen. Später wird dann festgestellt, dass die 
Mail nicht zugestellt werden kann, deshalb wird die Mail an den Absender 
zurückgeschickt.

Das Problem beim Bouncen ist, wenn es sich um Spam handelt, dann ist mit 
Sicherheit die Absenderadresse gefälscht. Jetzt schickt dein Server also eine 
Spam an eine gefälschte Absenderadresse.

Andere üble Lösung: Mail einfach löschen, wenn sie als Spam identifiziert wird:
Was passiert, wenn die Mail falsch als Spam erkannt wurde? Dann hast du einen 
Kunden/Mitarbeiter oder sogar Chef am Toben, der dann sogar vermutlich mit 
rechtlichen Konsequenzen drohen kann (nicht nur Kündigung, sondern auch 
strafrechtlich).

Deshalb ist es so wichtig, dass Bounces nicht nach außen geschickt werden. 
Einige Provider haben deshalb eigene Server eingerichtet, die nur Bounces 
verschicken. Wenn diese Server dann in Blacklists als Spamversender landen, 
ist der Schaden nicht so hoch.

Auch eine üble Lösung für ein mieses Problem.

> was mich auch erstaunt hat, war das es viele restrictions gibt die für
> bestimmte phasen gelten smtpd_client_restrictions = smtpd_helo_restrictions
> = smtpd_sender_restrictions = smtpd_recipient_restrictions = und nachher
> doch alles besser in eine gepackt wird. In sofern scheint das mit meinem
> Buch dann doch nicht ganz praxisnah gewesen zu sein oder ich hab dann doch
> was noch nicht richtig verstanden.

Solange "smtpd_delay_reject = yes" eingestellt ist (Standard bei Postfix), 
wird die Mail ohnehin erst nach dem Ende der smtpd_recipient_restrictions 
abgewiesen. Es kann also sein, dass Postfix bereits weiss, dass die Mail 
aufgrund des HELO abgewiesen wird, aber diese Entscheidung wird erst nach dem 
Empfang des RCPT TO dem Client mitgeteilt.

Solange du kein System hast, dass unter sehr starker Last läuft (Hälfte der 
verfügbaren smtpd-Prozesse sind ständig in Gebrauch), brauchst du dir über 
solche Optimierung keine Gedanken zu machen.

> IV) Gibts denn was verbindliches zu diesem Thema?

Allgemein ist eines ein Standard, der in Deutschland verbindlich ist, von ein 
paar Sonderfällen abgesehen:

Wenn dein Server eine Mail annimmt, ist er dafür verantwortlich mit allen 
Konsequenzen. Dies gilt für die Zustellung, Sorgfaltspflicht beim 
Serverbetrieb und der Entscheidung über Löschen, Annehmen etc.

Selbst die Entscheidung über das Ablehnen von Mails darf nicht willkürlich 
sein und kann unter Umständen das Wettbewerbsrecht ins Spiel bringen.

> V) das meine check_client_access nicht mit meiner mysql-tabelle nicht passt
> ist schon mal nicht so gut. wie bekomme ich den den bequemen eintrag von
> email-adressen und das postfix weiss welche emails er als gültig anerkennt.
>  passiert das automatisch durch Definition der angaben zu
> virtual-mailboxes? gibts ne variante wie man das auch mit mysql-tabellen
> lösen kann?

Postfix kennt 4 Adressklassen, wobei virtual_alias_domains in eine andere 
Klasse umgeschrieben werden müssen, übrig bleiben also 3 Klassen:

Klasse                   Map                      Voreinstellung
mydestination            local_recipient_maps     passwd.byname, $alias_maps
relay_domains            relay_recipient_maps     (leer)
virtual_mailbox_domains  virtual_mailbox_maps     (leer)
virtual_alias_domains    virtual_alias_maps       /etc/postfix/virtual

Gültige Empfänger sind als jeweils für die Domainklasse in einer Map 
bereitzustellen. Leer bedeutet hier, dass keine Empfängerprüfung stattfindet
Beispiel: "relay_recipient_maps ="

Je nach System und eigenen Daten muss man diese auf die eigenen Systeme 
umstellen. Postfix kann dafür mit verschiedenen Datenbank-Typen 
zusammenarbeiten. In deinem Fall wäre das mysql.

> 
> So ich glaub jetzt hab ich erstmal das wichtigste zusammengestellt. Falls
> noch jemand einen tipp hat welcher Quelle man besonders trauen kann, nur
> her damit. Nachdem mein Buch Postfix e,b,w von 2006 ist und beim googlen
> tausend verschiedene Lösungen angeboten werden. Wäre manchmal doch eine
> verlässliche Quelle mit guten HowTos praktisch.

Es gibt allgemeine How-Tos, aber die helfen dir für deine spezifischen Wünsche 
leider nicht weiter.

-- 
Sandy

Antworten bitte nur in die Mailingliste!
PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com