kb

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
Nächste Überarbeitung Beide Seiten der Revision
kb [2012/01/06 13:35]
flacco
kb [2012/01/06 15:11]
flacco
Zeile 213: Zeile 213:
   * Amavis als content_filter zu nutzen.   * Amavis als content_filter zu nutzen.
  
-Die genannten Anforderungen ergeben ein recht komplexes Setup, daher widme ich mich hier den Hintergründen.+Die genannten Anforderungen ergeben ein recht komplexes Setup, daher widme ich mich hier den Hintergründen. Zunächst allerdings nur dem Teil der Einlieferung neuer Mails via //​**fetchmail**//​.
  
 Größte Schwierigkeit hierbei ist ein sauberes Mailrouting durch alle Komponenten. Dies beginnt bereits beim Fetchmail-Daemon. Zunächst ein schematischer Überblick über die Wege einer eingehenden Email: Größte Schwierigkeit hierbei ist ein sauberes Mailrouting durch alle Komponenten. Dies beginnt bereits beim Fetchmail-Daemon. Zunächst ein schematischer Überblick über die Wege einer eingehenden Email:
  
 +{{:​invis-postfix_dovecot.png|Überblick}}
  
 ==== fetchmail ==== ==== fetchmail ====
Zeile 240: Zeile 240:
  
 Eingetragen werden muss an dieser Stelle die lokale Domain des Servers. Eingetragen werden muss an dieser Stelle die lokale Domain des Servers.
 +
 +==== Postfix - Mail-Annahme====
 +
 +Postfix spielt die zentrale Rolle im gesamten Mail-Setup.
 +
 +Da wir es bezogen auf ein invis-Server-Setup "​lediglich"​ mit einem Mailserver in einem lokalen Netzwerk zu tun haben, werden die in der Grafik genannten Restrictions nicht konfiguriert. Unser Server bekommt emails entweder nur via //​**fetchmail**//​ oder von lokalen Benutzern eingeliefert. In beiden Fällen ist das Einliefern von Mails ohne Beschränkung erlaubt.
 +
 +Zunächst muss Postfix der eigene Zuständigkeitsbereich bekannt gemacht werden. Die zugehörigen Einstellungen werden in <​file>/​etc/​postfix/​main.cf</​file>​ vorgenommen.
 +
 +Die notwendigen Konfigurationen:​
 +
 +<​code>​
 +# INTERNET HOST AND DOMAIN NAMES
 +myhostname = server.invis-net.loc
 +
 +mydomain = invis-net.loc
 +masquerade_domains = $mydomain
 +
 +# SENDING MAIL
 +myorigin = $mydomain
 +
 +# RECEIVING MAIL
 +inet_interfaces = $myhostname,​ localhost
 +....
 +mydestination = $myhostname,​ $mydomain, localhost.$mydomain,​ localhost
 +</​code>​
 +
 +Dabei legt //​myhostname//​ den lokal gültigen FQDN und //​mydomain//​ die lokale Domain des Servers fest. Die Option //​myorigin//​ definiert beim Versand von Mails die Absende-Domain,​ so nicht angegeben. Die Option //​masquerade_domains//​ maskiert Subdomains oder Hostnamen in Email-Adressen mit der dahinter angegebenen Domain. D.h. Wird eine Mail von "​host1.invis-net.loc"​ versandt so würde Postfix im gezeigten Beispiel daraus schlicht "​invis-net.loc"​ machen. Emails versendende Hosts im lokalen Netz würden also hinter der lokalen Domain "​versteckt"​.
 +
 +Dies kann als zusätzliche Sicherheitsmaßnahme verstanden werden, die dabei hilft, das lokale Mailrouting vor Fehlern zu schützen.
 +
 +Über die Option //​inet_interfaces//​ wird festgelegt, auf welchen Netzwerkschnittstellen Postfix überhaupt Mails annimmt. Die hier getroffene Einstellung erlaubt die Annahme nur auf der Loopback-Schnittstelle sowie allen Schnittstellen denen der eigene FQDN zugewiesen wird. In der Praxis wird hier häufig einfach der Wert "​all"​ angegeben, was bedeutet, das Postfix die Einlieferung von Mails auf allen Schnittstellen des Servers erlaubt. Dies schließt auch das externe, mit dem Internet verbundene Netzwerk-Device mit ein. In Kombination mit einer fehlerhaft konfigurierten Firewall, kann das durchaus dazu führen, dass der Server von unerlaubter Seite als Mail-Relay missbraucht werden könnte.
 +
 +Die Option //​mydestination//​ legt die Ziele fest, für die Postfix Endpunkt der Email-Zustellung,​ also nicht weiterleitendes "​Relay"​ ist.
 +
 +Nach der Annahme einer Mail, muss diese an AMaViS weitergegeben werden. Für die Einbindung von AMaViS als Viren- und Spam-Filter stehen mit "​content_filter"​ und "​smtpd_filter_proxy"​ zwei deutlich unterschiedliche Wege zur Verfügung. Während sich AMaViS mit der "​smtpd_filter_proxy"​ Methode direkt in die Einliefernde SMTP-Sitzung einklinkt und diese bis zum Abschluss der Prüfung offen hält, schließt sich die "​content_filter"​ Methode an die erfolgte Einlieferung an. Ist auf einem Internet-Mailserver Methode 1 die deutlich bessere, da hier "​verseuchte"​ gar nicht erst angenommen werden, so macht dieses Vorgehen auf einem invis-Server keinen Sinn, da die Mails hier vom lokalen Fetchmail-Dienst eingeliefert werden und somit eine Blockade nicht Zielführend ist.
 +
 +Die Einbindung von AMaVis als Content-Filter findet an zwei Stellen im Postfix-Setup statt. In der Datei "​main.cf"​ erfolgt die eigentliche Integration des Filters durch Benennung eines "​Transportweges",​ welcher in <​file>/​etc/​postfix/​master.cf</​file>​ konfiguriert wird.
  
  • kb.txt
  • Zuletzt geändert: 2020/10/20 10:47
  • von flacco