Mailserver: Unterschied zwischen den Versionen

Aus xinux.net
Zur Navigation springen Zur Suche springen
 
(33 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
−
Die “Internet text messages” waren eine der ersten Anwendungen des Internet. Es war damals eine fantastische Vorstellung, Textnachrichten innerhalb von Sekunden von einem Rechner zu einem anderen über Tausende von Kilometern hinweg zuzustellen.
+
*[[Mailserver-Komplett]]
−
Heute werden diese text messages E-Mails genannt. Für deren Transport haben sich zwei verschiedene Protokolle herauskristallisiert.
+
*[[Mailserver-Best-Practice]]
−
Simple Mail Transfer Protocol (SMTP)
+
*[[Openrelay check]]
−
Unix to Unix Copy (UUCP)
+
*[[Mail tools]]
−
SMTP wird heute für fast alle E-Mails verwendet. Es definiert die Kommunikation von Start- und Zielrechner per TCP/IP zur Übermittlung der Nachrichten. Das UUCP-Protokoll dient eigentlich dazu, Dateien von einem Unixrechner zu einem anderen zu kopieren. Hierbei werden im ersten Schritt Dateien zum Kopieren vorgemerkt (gespoolt). Dann wird im zweiten Schritt eine Verbind­ung zum anderen Rechner aufgebaut, wobei es mehrere Arten der Kontaktaufnahme gibt, z.B. direkte Modemverbindung oder TCP/IP. Danach werden über diese Verbindung die Dateien zum Zielrechner kopiert.
+
*[[imap befehle]]
−
Da die mit UUCP zu kopierenden Dateien vor der Übertragung komprimiert werden können, eignet es sich gut für Systeme mit langsamen Netzverbindungen oder Wählleitungen.
+
*[[postfix]]
−
Da UUCP keine TCP/IP-Verbindung erfordert, eignet es sich ideal zur E-Mail-Anbindungvon Hochsicherheitssystemen
+
*[[postfix-commands]]
−
Die Konfiguration von UUCP wird nur noch in Einzelfällen benötigt, so dass sich dieses Skript auf SMTP beschränkt.
+
*[[dovecot]]
 +
*[[roundcube]]
 +
*[[spamassassin]]
 +
*[[Greylisting]]
 +
*[[qmail.schema]]
 +
*[[postfix ldap]]
 +
*[[postfix Backup MX]]
 +
*[[S/MIME]]
 +
*[[postfix tls erzwingen]]
 +
*[[Mail Proxy Protokoll]]
  
−
=Arbeitsweise des Protokolls SMTP=
+
=Links=
−
Die Aufgabe von SMTP ist der zuverlässige und effiziente Transport von Mail (Senden und Emp­fangen). SMTP ist unabhängig von dem unterliegenden Netzprotokoll, normalerweise wird jedoch TCP verwendet und die Kommunikation geht über den TCP-Port 25.
+
*http://www.whisperedshouts.de/dokumente/postfix-und-ldap-part-1-openldap-konfigurieren
−
Der Sender erhält vom Benutzer den Auftrag, eine Mail zuzustellen. Dieser baut nun eine bidirek­tionale Verbindung zum Empfänger auf, der entweder das direkte Ziel der Nachricht oder ein Nachrichtenübermittler auf der Strecke zum Ziel ist. Im letzteren Falle sorgt dieser für die weitere Verbindung zum Zielrechner. Der Sender schickt Kommandos, die vom Empfänger akzeptiert oder abgelehnt werden können. Dieser ist nun für die Zustellung beim Benutzer verantwortlich.
+
*http://wanderingbarque.com/howtos/mailserver/mailserver.html
−
Anders als bei UUCP werden die Mails sofort zugestellt, sofern der Empfänger erreichbar ist
+
*http://acidx.net/wordpress/2014/06/installing-a-mailserver-with-postfix-dovecot-sasl-ldap-roundcube/
 +
*http://davmail.sourceforge.net/index.html
  
−
==SMTP-Versand per telnet==
+
=Migration=
−
Diese Kommunikation erfolgt in einzelnen Schritten, die alle nacheinander auszuführen sind:
+
*[[imapsync]]
−
Angabe des Absenders
+
*http://wiki2.dovecot.org/Migration
−
Syntax
+
*http://www.scalix.com/forums/viewtopic.php?f=9&t=14116
−
MAIL FROM: <Absender>
 
−
Zuerst ist anzugeben, wer die E-Mail verschickt.
 
−
MAIL FROM: thomas@xinux.de
 
−
 
 
−
Angabe des Empfängers
 
−
Syntax
 
−
RCPT TO: <Empfänger>
 
−
Danach folgt der Empfänger der Nachricht; um sie an mehrere Empfänger zu verschicken, verwendet man dieses Kommando einfach mehrmals.
 
−
 
 
−
RCPT TO: martin@tuxmen.de
 
−
Übertragung des E-Mailtextes
 
−
Syntax
 
−
DATA <Text> .
 
−
Nach dem DATA-Kommando werden alle folgenden Zeilen als Nachrichtentext interpretiert, bis ein einzelner Punkt am Zeilenanfang eingegeben wird.Als Subject geben
 
−
wir “testmail von thomas” an.
 
−
 
 
−
DATA
 
−
Subject: testmail von thomas
 
−
 
 
−
Hallo Martin!
 
−
Dies ist eine Testmail per SMTP.
 
−
.
 
−
Beenden der Übertragung
 
−
Syntax
 
−
QUIT
 
−
Man kann über eine Verbindung mehrere E-Mails verschicken; am Ende muss man QUIT eingeben, um die Verbindung ordentlich zu trennen.
 
−
QUIT
 
−
Und hier nochmal komplett:
 
−
 
 
−
 
 
−
pate:/etc/postfix# telnet neelix.talaxia.de 25
 
−
Trying 85.10.194.199...
 
−
Connected to neelix.talaxia.de.
 
−
Escape character is '^]'.
 
−
220 neelix.talaxia.de ESMTP Postfix (Debian/GNU)
 
−
MAIL FROM: thomas@xinux.de
 
−
250 Ok
 
−
RCPT TO: martin@tuxmen.de
 
−
250 Ok
 
−
DATA
 
−
354 End data with <CR><LF>.<CR><LF>
 
−
Subject: testmail von thomas
 
−
 
 
−
Hallo Martin!
 
−
Dies ist eine Testmail per SMTP.
 
−
 
 
−
gruss
 
−
 
 
−
Thomas
 
−
.
 
−
250 Ok: queued as D44DF99009B
 
−
QUIT
 
−
221 Bye
 
−
 
 
−
 
 
−
==Voraussetzungen für den Versand über SMTP==
 
−
Damit ein Rechner E-Mail empfangen kann, muss er ständig eingeschaltet sein. Da dies für die meisten Client-Rechner nicht der Fall ist, gibt es so genannte Mailserver, die ständig aktiv sind und E-Mails für eine ganze Reihe von Benutzern empfangen und zwischenspeichern können
 
−
Die ständige Verfügbarkeit oder der passende MX-Eintrag des zuständigen DNS-Servers sind allgemein Voraussetzung für den Empfang von E-Mail
 
−
 
 
−
==Weitere Möglichkeiten für den Versand von E-Mail==
 
−
Wir wissen nun, wie E-Mail zum zuständigen SMTP-Server des Empfängers übermittelt wird. Es stellt jedoch häufig für den Sender ein Problem dar, den SMTP-Server direkt zu erreichen. So kann es sein, dass unter Umständen der SMTP-Server vorübergehend nicht erreichbar ist. Das kann vorkommen, wenn der Sender nur über eine Wählverbindung mit dem Internet verbunden ist oder wenn der SMTP-Server ausgefallen ist. Der Client müsste also beim Versenden jeder Mail eine Verbindung ins Internet aufbauen oder ggf. zu einem späteren Zeitpunkt probieren, die Mail zu versenden. Die Verbindung ins Internet ist in vielen Fällen auch durch eine Firewall gesperrt. Um diesen Problemen aus dem Weg zu gehen, haben SMTP-Server noch eine weitere Funktion:
 
−
Der Sender benutzt häufig seinen eigenen SMTP-Server, um ausgehende Mail zu versenden. Dieser kann sich dann darum kümmern, dass die Mail zum SMTP-Server des Empfängers transportiert wird. Somit kann die Mail - ohne Zutun des Senders - auch erst ausgeliefert werden, wenn der SMTP-Server des Empfängers erreichbar ist. Die Einrichtung des Clients ist recht einfach, da nur der eigene Mail-Server einzutragen ist. Früher war es üblich, dass E-Mails über mehrere SMTP-Server transportiert wurden, bis sie den Empfänger erreichte (Mail Relaying), heute stellt der sendende Mailserver dem Mailserver des Empfängers die Mail in der Regel direkt zu.
 
−
=Sendmail=
 
−
Sendmail war lange Zeit  Standardprogramm zum E-Mail-Transport im Internet . Seine Popularität verdankt es nicht zuletzt seiner Flexibilität, die eine Konfiguration allerdings erschwert. Leider ist der monolithische Sendmail alles andere als leicht zu pflegen. In solch ein "Multifunktions-Tool" schleichen sich zwangsläufig Fehler ein - eine neue Sicherheitslücke in Sendmail gehörte in der Vergangenheit zu den Treppenwitzen der Internet-Geschichte schlechthin.
 
−
 
 
−
=Alternativen=
 
−
 
 
−
Die beiden am häufigsten eingesetzten (freien) Alternativen zu Sendmail sind Dan Bernsteins Qmail und Postfix von Wietse Venema. Beide sind wie Sendmail im Quelltext frei verfügbar - Qmail unter der GPL, Postfix unter einer von der Mozilla Public License abgeleiteten Lizenz von IBM - und beide sind einfacher zu handhaben als das altehrwürdige Sendmail.
 
−
 
 
−
 
 
−
=Postfix=
 
−
 
 
−
Wieste's Ziel bei der Entwicklung von Postfix war, ein schnelles, einfach zu administrierendes und sicheres Programm(paket) zu entwickeln, das so weit wie möglich zu Sendmail kompatibel sein soll. Das Interessanteste an Postfix ist sein innerer Aufbau (siehe Grafik): es besteht aus mehreren kleinen Programmen, die über UNIX-Domain-Sockets kommunizieren. Auf diese Weise ist es viel einfacher, Probleme, Fehler oder Sicherheitsmängel in den Griff zu bekommen. Beispielsweise kommt Postfix ganz ohne setuid-M©chanismen aus. Deshalb ist es für einen potenziellen Angreifer unmöglich, Superuser-Rechte zu bekommen - selbst wenn er ein Sicherheitsloch von Postfix gefunden hätte. Sendmail hingegen muß unter UID 0 (root) laufen, zumindest in einer Standardinstallation und ohne größere Klimmzüge.
 
−
Ebenfalls aus Sicherheitsgründen arbeitet Postfix mit vier verschiedenen Queues: "maildrop", "incoming", "active" und "deferred". Lokal gesendete Mails landen in "maildrop" und werden von dort in die "incoming"-Queue kopiert, nachdem sie regelbasiert auf Größe, Inhalt und anderes überprüft wurden. In der "active" Queue landen die Mails, die der Queue-Manager gerade bearbeitet und ausliefert (lokal oder remote). Nachrichten, die Postfix nicht ausliefern kann (Dienst des Zielmailservers reagiert nicht, keine Route, keine Netzverbindung, ...), landen in der "deferred" Queue. Da Postfix immer nur eine Mail gleichzeitig bearbeitet und die "active" Queue klein hält, ist es unempfindlich gegen Ressourcenknappheit. Das Bearbeiten/Ausliefern von Mails kann also in keinem Fall, beispielsweise wegen eines vollen Dateisystems, blockiert werden.
 
−
 
 
−
 
 
−
 
 
−
Die Grafik zeigt den modularen Aufbau von Postfix. Hierbei bedeuten:
 
−
gelbe Ellipsen Programme
 
−
gelbe Kästen Mail-Queues oder -Dateien
 
−
blaue Kästen (Nachschlage-) Tabellen
 
−
Programme in der umrandeten Box laufen unter der Kontrolle des Postfix master Daemons.
 
−
Dateien in diesem Kasten gehören dem Postfix-Mail-System.
 
−
[[Datei:queue.jpg]]
 
−
 
 
−
 
 
−
==Installation von Postfix==
 
−
 
 
−
Vobereitung:  Im Verzeichniss /etc/skel sollte folgende Verzeichnisstruktur  angelegt werden:
 
−
 
 
−
pate:/etc/skel# tree .
 
−
.
 
−
`-- Maildir
 
−
    |-- cur
 
−
    |-- new
 
−
    `-- tmp
 
−
 
 
−
4 directories, 0 files
 
−
 
 
−
Wir brauchen das für den courier  imap Server (kommt weiter unten) 
 
−
 
 
−
 
 
−
Installiert wird Postfix mit dem Befehl
 
−
apt-get install postfix
 
−
Da auf einem Debiansyste meistens exim vorinstalliert ist und es sich bei Mailservern um Highländerpakete handelt wird vorgeschlagen exim zu entfernen.Dieses kann man bejahren.Danach gehts los mit der Debian-Konfiguration:
 
−
[[Datei:mail1.jpg]]
 
−
[[Datei:mail2.jpg]]
 
−
[[Datei:mail3.jpg]]
 
−
[[Datei:mail4.jpg]]
 
−
 
 
−
==Dateien und Verzeichnisse==
 
−
 
 
−
 
 
−
 
 
−
postfix startet oder stoppt das Postfix-System
 
−
 
 
−
postalias      erzeugt die aliases-table für Postfix aus /etc/aliases, das  Pendant zu postmap
 
−
 
 
−
postcat zeigt den Inhalt der Queues an
 
−
 
 
−
postconf listet alle Variablen aus der Postfix-Konfiguration auf,kann aber auch gleichzeitig Einstellungen in der main. cf verändern! So kann man bequem aus Skripten heraus die Postfix-Konfiguration anpassen.
 
−
 
 
−
postdrop nimmt e-Mails auf der Kommandozeile an und speist sie in die Queues ein
 
−
 
 
−
postkick        sendet an einzelne Postfix-Module Steuerbefehle
 
−
 
 
−
postlock        lockt für Postfix Mailboxen, kann in Skripten eingesetzt werden
 
−
 
 
−
postlog erzeugt eine Logmeldung für syslogd
 
−
 
 
−
postmap wandelt alle Tables von Postfix vom Text-Format in das hash-Format (. db). Neben
 
−
mailq das wohl wichtigste Tool
 
−
 
 
−
postqueue    listet die Mailqueue oder startet die Auslieferung daraus (flush); wird von mailq aufgerufen.
 
−
 
 
−
postsuper      verwaltet die Postfix-Queue
 
−
 
 
−
mailq listet den Inhalt der Mailqueues auf und zeigt den aktuellen Versandstatus oder Versandprobleme; ersetzt mailq von Sendmail.
 
−
 
 
−
newaliases ersetzt das Sendmail-Programm newaliases und ist im Prinzip postalias nur unter einem anderen Namen.
 
−
 
 
−
sendmail      Sendmail-kompatibles Interface für lokal erzeugte Mails. Es verhält sich exakt so, wie sich auch das Original verhalten würde, übergibt die e-Mails dann aber sofort an postdrop.
 
−
 
 
−
==Dateien und Verzeichnisse==
 
−
 
 
−
 
 
−
Da sich die Konfiguration von Postfix über mehrere Dateien erstreckt, ist es von Bedeutung, dass man die wichtigsten davon kennt, bevor man mit der Konfiguration beginnt
 
−
 
 
−
==Konfigurationdateien==
 
−
 
 
−
Postfixmaster Programm
 
−
/usr/sbin/postfix
 
−
 
 
−
Startdatei von postfix
 
−
/etc/init.d/postfix  start|stop|restart
 
−
 
 
−
Module und Unterprogramme
 
−
/usr/lib/postfix
 
−
 
 
−
Dokumentation
 
−
/usr/share/doc/postfix
 
−
 
 
−
Mailqueue Ordner
 
−
/var/spool/postfix
 
−
 
 
−
==Konfigurationverzeichnis /etc/postfix==
 
−
===master.cf  - Prozess Masterkonfigurationsdatei===
 
−
Aufbau der Datei master.cf
 
−
 
 
−
Das Postfix Paket selbst bringt ausführlich kommentierte Konfigurationsdateien mit. Der größte Teil der master.cf besteht aus Erläuterungen. Die Konfiguration erfolgt zeilenweise in einer Tabellenähnlichen Datenstruktur. Jede Zeile definiert hier eine Komponente des Postfixsystems, die vom Masterprozess gestartet werden kann. Die einzelnen Spalten steuern wie und wann der zentrale Daemon die jeweiligen Prozesse startet oder stoppt.
 
−
 
 
−
Eine Konfigurationszeile der Konfigurationsdatei beginnt immer in der ersten Spalte. Nach einem Zeilenumbruch wird sie nach einem Whitespace fortgesetzt. Es werden also keine \ benötigt um Zeilenumbrüche zu maskieren.
 
−
Bedeutung der einzelnen "Spalten"
 
−
Jede Konfigurationszeile ist in maximal 8 Spalten unterteilt. Die Spalten werden durch Whitespaces voneinander getrennt. In jeder Zeile haben die einzelnen Spalten dieselbe Bedeutung für die jeweilige Teilkomponente. Einige der Spalten sind mit einem Defaultwert vorbelegt. Wenn in dieser Spalte ein "-" eingetragen wird kommt der Defaultwert zum tragen.
 
−
*service
 
−
Hier wird der Service-Typ eingetragen, der zur folgenden Typ-Spalte passen muß. Jeder Bezeichner in dieser Spalte muss eindeutig sein.
 
−
Services, die in der zweiten Spalte als inet definiert werden, müssen auf eine Portnummer aufgelöst werden können. Das heisst, das dem hier eingetragenen Service in der Datei /etc/services eine Portnummer zugeordnet sein muss. Alternativ zum Eintrag in /etc/services kann auch direkt eine Portnummer angegeben werden. Der Portnummer oder dem Dienstbezeichner kann noch ein Hostname oder eine IP-Adresse vorangestellt werden. Der Master Daemon bindet sich dann nur an das konfigurierte Interface. Ein Eintrag hier kann also im Format [host|ip:]<service|port> (z.B: localhost:smtp) eingetragen werden
 
−
Ein hier angegebener Bezeichner für einen Service kann in einem transport adressiert werden. Dieses ist z.B. die empfohlene Vorgehensweise um die E-Mail an Cyrus Mailboxen auszuliefern.
 
−
*type
 
−
Dieses Feld bietet die Möglichkeit den Typ des in Spalte 1 definierten Services festzulegen. Mögliche Typen sind inet für Internet Sockets, unix für Unix-Domain Sockets und fifo für Named Pipes.
 
−
Falls eine E-Mail an ein Programm übergeben werden soll, wird in der master.cf ein Service des Typs unix eingestellt. In der "command" Spalte wird das Kommando pipe eingestellt, das eine E-Mail an ein externes Programm übergibt.
 
−
*private (Default ja)
 
−
Ein als privat gekennzeichneter Dienst darf nur vom Postfix-Mailsystem selbst angesprochen werden. Dieses ist auch die Defaulteinstellung. Dienste die als Internet Sockets definiert sind müssen als öffentlich ("n") deklariert werden.
 
−
*unpriv (Default ja)
 
−
Der Parameter unpriv legt fest, ob der Dienst mit mit der Userid eines unprivilegierten Accounts gestartet werden soll oder als root. Die Benutzer ID des unprivilegierten Accounts wird in main.cf mit dem Parameter mail_owner bestimmt. Wenn der Dienst mit den Rechten von root gestartet werden soll, wird hier ein "n" eingetragen.
 
−
*chroot
 
−
Mit chroot wird bestimmt, ob der Prozess in einer chroot Umgebung laufen soll. Die Basis dieser Umgebung ist das Verzeichnis in dem die Mail Queues von Postfix installiert sind. Dieses Verzeichnis wird mit Hilfe des Parameters queue_directory in der main.cf bestimmt. Alle Prozesse mit Ausnahme der als PIPE definierten und den Daemons die die virtuelle oder lokale Auslieferung von E-Mail übernehmen, können chroot gestartet werden.
 
−
*wakeup
 
−
Hier wird eingestellt, ob der in der "command" Spalte eingestellte Prozess in regelmässigen Abständen Aktionen durchführen soll, wie z.B. das Leeren die Queue.
 
−
*maxproc
 
−
Die maximale Anzahl Prozesse, die von diesem Service gestartet werden können.
 
−
*command
 
−
Das zu startende Kommando. Der Pfad ist relativ zum Postfix Kommandoverzeichnis (kann mit dem Parameter program_directory in main.cf eingestellt werden).
 
−
*args
 
−
Die Argumente, die dem Kommando der Spalte "command" übergeben werden. Für die von Postfix selbst bereitgestellten Kommandos kann hier mit Hilfe eines oder mehreren -v Schaltern ein umfangreicheres Logging eingestellt werden.
 
−
Das Pipe Kommando bietet die umfangreichste Liste von möglichen Argumenten. Die Bedeutung der einzelnen Parameter ist in der Manpage pipe(8) dokumentiert.
 
−
<pre>
 
−
#======================================================================
 
−
# service type  private unpriv  chroot  wakeup  maxproc command + args
 
−
#              (yes)  (yes)  (yes)  (never) (100)
 
−
#======================================================================
 
−
smtp inet  n      -      -      -      -      smtpd
 
−
pickup fifo  n      -      -      60      1      pickup
 
−
cleanup unix  n      -      -      -      0      cleanup
 
−
qmgr fifo  n      -      -      300    1      qmgr
 
−
rewrite unix  -      -      -      -      -      trivial-rewrite
 
−
bounce unix  -      -      -      -      0      bounce
 
−
defer unix  -      -      -      -      0      bounce
 
−
trace unix  -      -      -      -      0      bounce
 
−
verify unix  -      -      -      -      1      verify
 
−
flush unix  n      -      -      1000?  0      flush
 
−
proxymap unix  -      -      n      -      -      proxymap
 
−
smtp unix  -      -      -      -      -      smtp
 
−
relay unix  -      -      -      -      -      smtp
 
−
showq unix  n      -      -      -      -      showq
 
−
error unix  -      -      -      -      -      error
 
−
local unix  -      n      n      -      -      local
 
−
virtual unix  -      n      n      -      -      virtual
 
−
lmtp unix  -      -      n      -      -      lmtp
 
−
anvil unix  -      -      n      -      1      anvil
 
−
maildrop unix  -      n      n      -      -      pipe
 
−
  flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
 
−
uucp      unix  -      n      n      -      -      pipe
 
−
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
 
−
ifmail    unix  -      n      n      -      -      pipe
 
−
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
 
−
bsmtp    unix  -      n      n      -      -      pipe
 
−
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -d -t$nexthop -f$sender $recipient
 
−
scalemail-backend unix  -      n      n      -      2      pipe
 
−
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
 
−
</pre>
 
−
 
 
−
===main.cf  - Hauptkonfigurationsdatei===
 
−
 
 
−
wird angezeigt wenn man ein telnet hostname 25 macht
 
−
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
 
−
 
 
−
aktiviert die zusammenarbeit mit dem biff daemon
 
−
dieser zeigt auf de konsole an das mails eingegangen sind
 
−
biff = no
 
−
 
 
−
wenn ein name kein fqdn ist ,wird der domainname angehaengt
 
−
append_dot_mydomain = no
 
−
 
 
−
der fqdn der mailservers
 
−
myhostname = pate.provider.int
 
−
 
 
−
die domain des mailservers
 
−
mydomain  = provider.int
 
−
 
 
−
hostname der bei der lokalen erzeigung von emails benutzt wird
 
−
myorigin = /etc/mailname
 
−
 
 
−
tabelle der mailaliasen
 
−
alias_maps = hash:/etc/aliases
 
−
 
 
−
canonical tabelle der sender adressen
 
−
sender_canonical_maps = hash:/etc/postfix/canonical
 
−
 
 
−
transport tabelle => mailertable bei sendmail
 
−
transport_maps = hash:/etc/postfix/transport
 
−
 
 
−
virtuall tabelle
 
−
virtual_maps = hash:/etc/postfix/virtual
 
−
 
 
−
relocated_maps = hash:/etc/postfix/relocated
 
−
 
 
−
header_check = rexexp:/etc/postifx/header_check
 
−
 
 
−
domain fuer die postfix "final destination ist" ist. sie werden local zugestellt
 
−
mydestination = $myhostname, $mydomain, /etc/postfix/mydestination
 
−
 
 
−
ip nummern, die bei permit_mynetworks, permit_auth_destination und
 
−
reject_unauth_destination relayen duerfen
 
−
  mynetworks = 127.0.0.0/8, 192.168.86.0/24, 192.168.254.22
 
−
 
 
−
 
 
−
host ueber den alle ausgehenden mails geschickt werden, der mx record wird ignoriert
 
−
relayhost = neelix.talaxia.de
 
−
 
 
−
restrictions nach dem "RCPT TO:" abgesetzt wurde
 
−
smtpd_recipient_restrictions    = check_recipient_access hash:/etc/postfix/access
 
−
                              permit_mx_backup
 
−
                              permit_mynetwork
 
−
                              check_relay_domains
 
−
 
 
−
das programm das die mails an die localen postfaechern zustellt
 
−
mailbox_command = procmail -a "$EXTENSION"
 
−
 
 
−
maximal groesse der userpostfaecher danach wird gebounced
 
−
mailbox_size_limit = 0
 
−
 
 
−
trennzeichen um in der empfaenger adresse die maibox extention abzutrennen
 
−
recipient_delimiter = +
 
−
 
 
−
ip nummern auf denen postfix einen port oeffnet
 
−
inet_interface = all
 
−
nicht fqdn-namen in der mailadresse wird die §mydomain angehängt
 
−
append_dot_mydomain = yes
 
−
 
 
−
===Die Tabellen===
 
−
Die Tabellen bei Postfix werden als normale ASCII-Textdateien angelegt. Sie müssen danach noch in ein Datenbankformat umgewandelt werden. Dazu stehen zwei Tools zur verfügung.
 
−
*postalias für die aliases-tabelle
 
−
*postmap für den rest
 
−
 
 
−
 
 
−
====alias_maps = hash:/etc/aliases====
 
−
Die aliases-table definiert Mailaliase. Damit lassen sich lokale Adressen umschreiben und Mails in andere Postfächer umleiten. Sie liegt historischen Gründen im gegensatz zu den anderen Tabellen nicht unter /etc/postfix.
 
−
 
 
−
<pre>
 
−
#/etc/aliases
 
−
mailer-daemon: postmaster
 
−
postmaster: root
 
−
nobody: root
 
−
hostmaster: root
 
−
usenet: root
 
−
news: root
 
−
webmaster: root
 
−
www: root
 
−
ftp: root
 
−
abuse: root
 
−
noc: root
 
−
security: root
 
−
technik: thomas,martin,tina       
 
−
</pre>
 
−
Danach wird in das Datenbankformat umgewandelt:  postalias /etc/aliases
 
−
====virtual_maps = hash:/etc/postfix/virtual====
 
−
Damit lassen sich alle Adressen umschreiben.
 
−
Folgende Kriterien gelten hierbei:
 
−
<pre>
 
−
user@domain.de genau diese Mailadresse
 
−
@domain.de alle Adressen dieser Domain
 
−
user dieser User bei beliebigen Domains
 
−
domain.de definiert diese Domain als virtuelle Domain
 
−
 
 
−
 
 
−
#allgemeines freischalten der virtuellen domains. das blabla dient nur als platzhalter.
 
−
 
 
−
apfel.int                      blabla
 
−
birne.int                      blabla
 
−
delicius.int                    blabla
 
−
 
 
−
#vertrieb@apfel.int wird hier dem lokalen konto apfel-vertieb zu geordnet.
 
−
vertrieb@apfel.int     apfel-vertrieb
 
−
#webmaster@apfel.int wird hier dem lokalen apfel-webmaster zu geordnet.
 
−
webmaster@apfel.int            apfel-webmaster
 
−
 
 
−
#alles an die domain delicius.int wird hier dem lokalen apfel-sammel zu geordnet.
 
−
@delicius.int                  apfel-sammel
 
−
 
 
−
vertrieb@birne.int              birne-vertrieb
 
−
webmaster@birne.int            birne-webmaster
 
−
 
 
−
vertrieb@provider.int          provider-vertrieb
 
−
webmaster@provider.int      provider-webmaster
 
−
</pre>
 
−
 
 
−
Danach wird in das Datenbankformat umgewandelt:  postmap /etc/postfix/virtual
 
−
 
 
−
====sender_canonical_maps = hash:/etc/postfix/canonical====
 
−
 
 
−
Auch die canonical-Tabellen können Mailadressen umschreiben. Sie sind jedoch in der lage auch Absendeadressen umzuschreiben so ist es möglich. unschöner Absendeadressen durch schönere zuersetzen.
 
−
Es gibt drei Arten von canonical-Tabellen
 
−
 
 
−
*canonical_maps  -> Umwandlung bei Absende  und Empfängeradressen
 
−
*sender_canonical_maps-> Umwandlung bei Absendeadressen
 
−
*recipient_canonical_maps -> Umwandlung bei Empfängeradressen
 
−
#wandelt eine localen absender adresse in eine offizielle adresse um
 
−
root            technik@provider.int
 
−
#wandelt fuer alle konten absender in dies domain um
 
−
@pate.provider.int      @provider.int
 
−
 
 
−
Danach wird in das Datenbankformat umgewandelt  postmap /etc/postfix/virtual
 
−
 
 
−
====transport_maps = hash:/etc/postfix/transport====
 
−
Postfix kennt verschiedene Transport-Methodem e-Mails zuzustellen.  Über den Parameter default_transport kann man Postfix eine Standardmethode zuweisen.
 
−
Beispielsweise
 
−
*SMTP  -> Sendmail Transport Protokoll
 
−
*UUCP -> Unix 2 Unix Copy
 
−
*LMTP -> lokale Mail auslieferung
 
−
Man kann in der transport-Tabelle nun diesen Vorgabe ändern. Es wird dann unabhängig vom
 
−
MX-Record eine Mail über einen bestimmten Mailserver geschickt.
 
−
 
 
−
pate:/etc/postfix# dig  -t mx sympatel.de | grep -A 3 ";; ANSWER"
 
−
;; ANSWER SECTION:
 
−
sympatel.de.            86255  IN      MX      10 mail.sympatel.de.
 
−
sympatel.de.            86255  IN      MX      20 mforward.dtag.de.
 
−
 
 
−
# Mails für sympatel.de werden trotz der anderslautenten MX Records über neelix.talaxia.de
 
−
geschickt.
 
−
sympatel.de            esmtp:neelix.talaxia.de
 
−
 
 
−
Danach wird in das Datenbankformat umgewandelt  postmap /etc/postfix/transport
 
−
 
 
−
 
 
−
 
 
−
 
 
−
====relocated_maps = hash:/etc/postfix/relocated====
 
−
relocated  bounct unzustellbare Mails unter Angabe der neuen Mailadresse des verzogenen Accounts
 
−
 
 
−
#neue Adresse von bauer ist jetzt martin.bold@xinux.de
 
−
bauer@apfel.int        martin.bold@xinux.de
 
−
 
 
−
Danach wird in das Datenbankformat umgewandelt  postmap /etc/postfix/relocated
 
−
 
 
−
 
 
−
 
 
−
 
 
−
==Schutz durch Restrictions==
 
−
Der entscheidende Stelle, um Spam abzuwehren, ist der Einliefungszeitpunkt auf dem Mailserver.
 
−
Es soll also daum gehen, die Annahme von vorneherein abblocken zu können. Ob eine Mail angenommen werden darf, entscheidendet sich aus einem zusammenspiel von
 
−
 
 
−
 
 
−
*IP-Adresse des einliefernden Mailservers
 
−
 
 
−
*Empfänger der Mail
 
−
 
 
−
*Mailadresse des Absenders (unsicher)
 
−
 
 
−
*Password Authentifizierung (sicher)
 
−
 
 
−
Formale Kritierien (fehlerhafte SMTP Befehle)
 
−
 
 
−
 
 
−
===Wann wird geprüft?===
 
−
 
 
−
Die Prüfung kann jetzt zu verschiedenen Zeitpunkten durch geführt werden wobei hier gilt
 
−
je später der Zeitpunkt desto mehr informationen können ausgewertert werden. Es gibt hier
 
−
4 Möglichkeiten:
 
−
<pre>
 
−
Zeitpunkt
 
−
smtp_recipient_restrictions -> nach  RCPT TO:ziel@provider.int
 
−
check_sender_access typ:mapname
 
−
reject_unknown_recipient
 
−
permit_mx_backup
 
−
check_relay_domains
 
−
permit_auth_destination
 
−
 
 
−
smtp_sender_restrictions -> nach  MAIL FROM:quelle@provider.int
 
−
check_sender_access typ:mapname
 
−
reject_unknown_senderdomain
 
−
reject_non_fqdn_sender
 
−
 
 
−
smtp_helo_restrictions -> nach  HELO domain.de FROM:quelle@provider.int
 
−
check_helo_access
 
−
reject_unknown_hostname
 
−
reject_non_fqdn_hostname
 
−
reject_invalid_hostname
 
−
permit_naked_ip_adresse
 
−
 
 
−
smtp_client_restrictions -> nach dem CONNECT
 
−
reject_unauth_pipelining
 
−
permit
 
−
reject
 
−
warn_in_reject
 
−
check_client_access typ:mapname
 
−
reject_unknown_client
 
−
reject_maps_rbl
 
−
permit_mynetworks
 
−
</pre>
 
−
 
 
−
 
 
−
====check_sender_access hash:/etc/postfix/access====
 
−
Die Tabelle access erlaubt es, einzelne Adressen ,Nutzer oder Hosts für bestimmte Aktionen
 
−
freizugeben oder zu blocken. Die access-Tabelle trifft dabei immer Ja/Nein-Aussagen :
 
−
OK oder REJECT
 
−
<pre>
 
−
#restrictions nach dem "RCPT TO:" abgesetzt wurde
 
−
smtpd_recipient_restrictions      = check_recipient_access hash:/etc/postfix/access,
 
−
permit_mx_backup,
 
−
permit_mynetwork,
 
−
check_relay_domains
 
−
 
 
−
#/etc/postfix/access
 
−
provider.int OK
 
−
apfel.int OK
 
−
birne.int OK
 
−
delicius.int OK
 
−
tuxmen.int OK
 
−
</pre>
 
−
Danach wird in das Datenbankformat umgewandelt  postmap /etc/postfix/access
 
−
 
 
−
 
 
−
 
 
−
===Protokolle zum Abruf von E-Mail===
 
−
Nachdem die Mail im Postfach des Benutzers angekommen ist, muss sie irgendwie zum Mail-Client des Benutzers gelangen. In den seltensten Fällen hat der Mail-Empfänger einen direkten Zugang (login-Shell) zum Unix-Rechner. Somit muss der Benutzer sich die E-Mail vom Unix-Rechner ”abholen”. Es haben sich hier zwei Protokolle herauskristallisiert:
 
−
Post Office Protokoll - Version 3 (POP3)
 
−
Internet Message Access Protokoll - Version 4 (IMAP4)
 
−
Von den beiden Protokollen ist IMAP4 das deutlich komplexere und flexiblere. Trotzdem ist POP3 noch sehr weit verbreitet, da es weniger Server-Ressourcen verbraucht.
 
−
==POP3==
 
−
Das POP3-Protokoll bietet nicht viele Möglichkeiten; man kann sich am Server authentifizieren, erfährt, wie viele Nachrichten vorhanden und wie viele ungelesen sind und kann diese Nachrichten dann herunterladen und vom Server löschen.
 
−
Dies bedeutet, dass bei Verwendung eines POP3-Servers immer alle Nachrichten vor dem Lesen heruntergeladen werden müssen und es nicht möglich ist, die Nachrichten von zwei oder mehreren Rechnern aus abzurufen, da sie nur auf einem Rechner vorhanden sein werden
 
−
Es gibt bei vielen Mailprogrammen auch die Option “Nachrichten auf dem Server belassen”. Hierbei werden die Nachrichten einfach nur nicht gelöscht, so dass man sie beim nächsten Mal wieder herunterladen muss und somit nichts gewonnen hat
 
−
Beschreibung des Protokolls POP3
 
−
Ähnlich wie bei anderen Protokollen ist es auch hier möglich, die Verbindung zu einem POP3-Server ”von Hand” aufzubauen. Wir verwenden das Programm telnet, um den Abruf von E-Mail zu simulieren. Die Befehle von POP3 sind sehr einfach:
 
−
Authentifizierung
 
−
Syntax
 
−
<pre>
 
−
USER <benutzername> PASS <passwort>
 
−
Hier entspricht das Protokoll dem FTP-Protokoll, aber warum sollte man sich etwas Neues ausdenken müssen?
 
−
 
 
−
USER martin
 
−
PASS suxer
 
−
Übersicht
 
−
Syntax
 
−
LIST
 
−
Dieses Kommando gibt einem eine Liste von Nachrichtennummern und Längen der Nachrichten aus.
 
−
Nachricht lesen
 
−
Syntax
 
−
RETR <Nachrichtennummern>
 
−
Die Nachrichtennummer muss eine der Nummern aus der Ausgabe des LIST-Kommandos sein.
 
−
RETR 10
 
−
Nachricht löschen
 
−
Syntax
 
−
DELE <Nachrichtennummern>
 
−
Die entsprechende Nachricht wird unwiderruflich gelöscht.
 
−
DELE 10
 
−
Alles in allem ziemlich unspektakulär, deshalb hier das ganze nochmal zusammen:
 
−
pate:/etc/skel# telnet pate.provider.int 110
 
−
Trying 192.168.86.10...
 
−
Connected to pate.provider.int.
 
−
Escape character is '^]'.
 
−
+OK Qpopper (version 4.0.5) at localhost.localdomain starting.  <8228.1131614979@localhost.localdomain>
 
−
user martin
 
−
+OK Password required for martin.
 
−
pass suxer
 
−
+OK martin has 1 visible message (0 hidden) in 444 octets.
 
−
list
 
−
+OK 1 visible messages (444 octets)
 
−
1 444
 
−
.
 
−
retr 1
 
−
+OK 444 octets
 
−
Return-Path: <technik@provider.int>
 
−
X-Original-To: martin
 
−
Delivered-To: martin@pate.provider.int
 
−
Received: by pate.provider.int (Postfix, from userid 0)
 
−
        id 9F0A56A210; Thu, 10 Nov 2005 10:29:36 +0100 (CET)
 
−
To: martin@pate.provider.int
 
−
Message-Id: <20051110092936.9F0A56A210@pate.provider.int>
 
−
Date: Thu, 10 Nov 2005 10:29:36 +0100 (CET)
 
−
From: technik@provider.int (root)
 
−
X-UIDL: =/e!!#X)#!dbh"!@lp!!
 
−
 
 
−
Do Nov 10 10:29:36 CET 2005
 
−
.
 
−
dele 1
 
−
+OK Message 1 has been deleted.
 
−
list
 
−
+OK 0 visible messages (0 octets)
 
−
.
 
−
quit
 
−
+OK Pop server at localhost.localdomain signing off.
 
−
Connection closed by foreign host.
 
−
Die Installation einer POP3 Server ist unter Debian wie immer sehr einfach:
 
−
 
 
−
</pre>
 
−
 
 
−
apt-get install qpopper
 
−
 
 
−
 
 
−
Und zur Kontrolle:
 
−
 
 
−
pate:/etc/skel# netstat -ltp | grep pop3
 
−
tcp        0      0 *:pop3                  *:*                     LISTEN    759/inetd
 
−
 
 
−
==IMAP4==
 
−
Bei IMAP4 handelt es sich um ein deutlich komplexeres Protokoll, das alle Funktionen von POP3 unterstützt und über weitere Funktionen verfügt. So kann man die Kopfzeilen der Nachrichten, also Datum, Absender, Empfänger, Betreff usw. getrennt herunterladen, um eine Übersicht der Nachrichten zu erhalten. Nachrichten können direkt auf dem Server verschoben und gelöscht werden; die Authentifizierung kann verschlüsselt erfolgen, uvm.
 
−
Aus diesem Grund kann IMAP4 sehr gut in Intranets eingesetzt werden, in denen von mehreren Rechnern aus (z.B. Laptop und Arbeitsplatz) die gleiche E-Mail gelesen werden soll. Da die E-Mail zentral auf dem Server verbleibt, kann sie in das Backup-Konzept eingebunden werden, so dass der Ausfall eines Arbeitsplatzes keinen Verluste der E-Mail bedeutet. Hierzu ist allerdings auf eine entsprechende Leistungsfähigkeit des Servers zu achten.
 
−
 
 
−
===Courier-IMAP===
 
−
 
 
−
Courier-IMAP ist eine sehr große und mächtige Lösung, um Mails auf einem System zu verwalten. Die Installation und Konfiguration von Courier-IMAP ist aber gar nicht so schwer und aufwendig, wie es auf den ersten Blick erscheinen mag. Ein Grundsystem für einen oder mehrere User ist schnell zusammengestellt.
 
−
Da Courier-IMAP auf das Maildir-Format aufsetzt, muss jedoch gewährleistet sein, dass diese Mails bereits vorm Zugriff mit Courier in diesem Format vorhanden sind. Anders als im mbox-Format liegen die einzelnen Mails dabei jeweils in Unterverzeichnissen. Pro Folder (IMAP-Ordner) gibt es drei Unterverzeichnisse, nämlich new, cur und tmp. Das haben wir oben schon erledigt :)
 
−
 
 
−
====Installation von courier-imap===
 
−
<pre>
 
−
apt-get install courier-imap
 
−
Kontrolle
 
−
pate:~# netstat -lntp | grep 143
 
−
tcp        0      0 0.0.0.0:143            0.0.0.0:*              LISTEN    3665/couriertcpd
 
−
</pre>
 
−
Es gibt dann Zwei Konfigurationsdateien die in der Regel nicht angepasst werden müssen
 
−
 
 
−
pate:/etc/courier# cat authdaemonrc
 
−
 
 
−
#authmodulelist und authmodulelistorig legen die Art der Userauthentifizierung fest. daemons legt #die Anzahl der gleichzeitig laufenden Authentifizierungs-Daemons fest. Wenn nicht mehr als #ungefähr 20 Mailboxen gleichzeitig angesteuert werden sollen, reicht einer. Ansonsten ist die #Anzahl dementsprechend zu erhöhen.
 
−
 
 
−
authmodulelist="authpam"
 
−
authmodulelistorig="authcustom authcram authuserdb authldap authpgsql authmysql authpam"
 
−
daemons=5
 
−
version=""
 
−
 
 
−
authdaemonvar=/var/run/courier/authdaemon
 
−
<pre>
 
−
pate:/etc/courier# cat imapd
 
−
# Adresse wo der imap server lauschen soll
 
−
ADDRESS=0
 
−
# der Port der imap verwenden soll
 
−
PORT=143
 
−
#maxiamleAanzahl der imap daemons
 
−
MAXDAEMONS=40
 
−
 
 
−
#Maixmale Verbindungen per IP
 
−
MAXPERIP=20
 
−
 
 
−
#Datei der die Prozess id enthält Prozess ID
 
−
PIDFILE=/var/run/courier/imapd.pid
 
−
# Optionen der couriertcpd sollten nicht geändert werden
 
−
TCPDOPTS="-nodnslookup -noidentlookup"
 
−
#Wenn  AUTHMODULES="authdaemon", gesetzt ist “DO NOT CHANGE IT”
 
−
#Ändere den Parameter in der /etc/courier/autdaemon
 
−
AUTHMODULES="authdaemon"
 
−
#fuer das webminmodul
 
−
AUTHMODULES_ORIG="authdaemon"
 
−
 
 
−
#Debuglevel
 
−
DEBUG_LOGIN=0
 
−
# antwort auf das CAPABILITY-Kommando
 
−
IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE"
 
−
# custom keywords freischalten
 
−
IMAP_KEYWORDS=1
 
−
# für webadmin
 
−
IMAP_CAPABILITY_ORIG="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 IDLE"
 
−
# Idle-Timeout des IMAP-Servers
 
−
IMAP_IDLE_TIMEOUT=60
 
−
#SASL PLAIN authentifizierung nach STARTTLS erlauben
 
−
IMAP_CAPABILITY_TLS="$IMAP_CAPABILITY AUTH=PLAIN"
 
−
# wird von webadmin benutzt
 
−
IMAP_CAPABILITY_TLS_ORIG="$IMAP_CAPABILITY_ORIG AUTH=PLAIN"
 
−
# darf der Client auf dem Server Thread und SORT Kommandos ausführen? (erhöht die Serverlast!)
 
−
IMAP_DISABLETHREADSORT=0
 
−
# In allen Ordnern nach neuer Mail suchen (nur sinnvoll, wenn Mails auf dem Server in die
 
−
# Unterordner sortiert werden). Erhöht die Last auf dem Server!
 
−
IMAP_CHECK_ALL_FOLDERS=0
 
−
# Workaround für Fehlerhafte Clients
 
−
IMAP_OBSOLETE_CLIENT=0
 
−
# Maximale größe des Serverprozesses (64MB) – kann gegen DoS-Attacken schützen
 
−
IMAP_ULIMITD=65536
 
−
# sollte bei der benutzung von “shared folders” unbedingt aktiv sein!
 
−
IMAP_USELOCKS=1
 
−
# Index aller zugänglichen Ordner
 
−
IMAP_SHAREDINDEXFILE=/etc/courier/shared/index
 
−
#Idle-Modus (für Konkurrierende Updates)
 
−
IMAP_ENHANCEDIDLE=0
 
−
# Name des Trash-Folders (für Outlook-Kompatibilität sollte hier “Deleted Items” stehen)
 
−
IMAP_TRASHFOLDERNAME=Trash
 
−
# Trash-Folder nach 7Tagen, Sent-Folder nach 30Tagen löschen (bezieht sich auf CTIME-Stamp)
 
−
IMAP_EMPTYTRASH=Trash:7,Sent:30
 
−
# Mails löschen oder in den Mülleimer werfen?
 
−
IMAP_MOVE_EXPUNGE_TO_TRASH=0
 
−
 
 
−
#Zusatzfeature: Mails verschicken durch ablegen in diesem Ordner
 
−
OUTBOX=.Outbox
 
−
# dazu wird das folgende sendmail aufgerufen
 
−
SENDMAIL=/usr/sbin/sendmail
 
−
# Headerfeld in dem der Absender nochmals hinterlegt wird, wenn eine Mail wie oben verschickt
 
−
# wird
 
−
HEADERFROM=X-IMAP-Sender
 
−
# IMAPD starten? (wird von manchen Distributionen in Init-Skripten abgefragt)
 
−
IMAPDSTART=YES
 
−
# Pfad zum Maildir
 
−
MAILDIRPATH=Maildir
 
−
</pre>
 
−
 
 
−
==Sicherheit mit SSL==
 
−
Secure Socket Layer (SSL v2/3) bzw. der Nachfolger Transport Layer Security (TLS vl) stellen ein Verfahren dar, mit dem sich beliebige TCP/IP-Verbindungen ver­schlüsseln lassen.
 
−
Sie setzen dabei auf sehr niedriger TCP/IP-Ebene in der Übertragung an (für Pro­fis: OSI-Schicht 3). Anders als als PGP, das auf Applikationsebene arbeitet (z. B. in der Mailsoftware), sichert SSL/TLS unmittelbar die TCP/IP-Verbindung zwi­schen zwei Hosts. Das macht es so flexibel, denn nahezu jedes Protokoll, das mit einem einzelnen Verbindungskanal auskommt, lässt sich damit über SSL/TLS absichern. Bekannte Vertreter sind z. B. HTTPs, POPSs, IMAPs oder SMTPs.
 
−
SSL/TLS funktioniert dabei grundsätzlich wieder nach dem von PGP bekannten Double-Key-Verfahren, d. h., es können auch zwei Hosts eine abhörsichere Verbin­dung aufbauen, die sich vorher noch gar nicht kannten. Durch das Double-Key-Verfahren ist es unnötig, über einen zweiten gesicherten Kanal zu verfügen, über den ein Schlüssel transportiert werden kann. Auch ein von vornherein mitlau­schender Angreifer bekommt die Secret Keys nie in die Hände - und ist damit nicht in der Lage, die mitgeschnittene Kommunikation zu dekodieren.
 
−
Eine verschlüsselte Verbindung zu einem unbekannten Host aufzubauen ist also kein Problem - etwas anders sieht es bei der Frage der Authentifizierung aus. Es könnte ein Angreifer in der Mitte sitzen und die übertragenen Schlüssel durch eigene ausgetauscht haben. Nur durch das Double-Key-Verfahren allein können wir Verschlüsselung einsetzen, können aber nicht garantieren, dass wir auch tat­sächlich mit demjenigen Daten austauschen, von dem wir glauben, er sei unser Partner.
 
−
Dieses Problem löst eine Signierung eines Public Keys. Dabei steht eine so genann­te Certification Authority (CA) durch eine digitale Unterschrift dafür ein, dass sie sich höchstselbst davon überzeugt hat, dass dieser Schlüssel einer bestimmten Person oder Organisation gehört.
 
−
CAs sind dabei nicht vorbestimmt: Praktisch jeder kann seine eigene CA aufma­chen und seine eigenen oder die Schlüssel Dritter signieren. Nur stellt sich die Frage, ob der Rest der Welt diese selbstgemachten CAs kennt und ihnen vertraut.
 
−
Große professionelle CAs haben dafür gesorgt, dass ihre CA-Schlüssel in den üb­lichen Mail- und Webclients bereits fest eingebunden sind. Jeder dieser Clients kann die von diesen CAs signierten Schlüssel sofort als gesichert und vertrau­enswürdig übernehmen.
 
−
Bei selbtgebauten CAs fällt das weg: Die Schlüssel sind zwar signiert - aber eben­falls von einer dem Client unbekannten CA. Der Client muss also den Benutzer fragen, ob er dieser CA vertraut. In der Praxis ist das ein einmaliger Vorgang. An der Qualität der Verschlüsselung ändert das rein gar nichts - nur die Frage, ob dieser Schlüssel dem gehört, von dem er zu sein scheint, lässt sich nicht hundert­prozentig klären.
 
−
Deshalb werden sich auch viele Firmen weiterhin ihre Schlüssel teuer von be­kannten, etablierten CAs signieren lassen:
 
−
http://www.verisign.com http://www.thawte.com
 
−
Wichtig sind absolut sicher authentifizierte Schlüssel vor allem bei Web-Servern: Hier wird garantiert, dass ein HTTPs-Schlüssel tatsächlich zur angesprochenen Webseite einer Bank gehört, und nicht etwa einem Man-in-the-Middle, der den Schlüssel ausgetauscht hat und so unsere Daten und PIN-Nummern zum Online-Banking ausspionieren möchte. Weitere zentrale Einsatzgebiete sind z. B. das Über­tragen von Konto- oder Kreditkartendaten beim Online-Shopping - aber auch die Abfrage von e-Mail Postfächern per e-Mail oder dergleichen.
 
−
Auch Mailserver lassen sich über SSL/TLS sichern: POPSs, IMAPs und SMTPs sind sehr sinnvoll und wünschenswert, aber bislang leider kaum vertreten. Die eigentlichen Verfahren POPS, IMAP und SMTP kommen dabei wie gewohnt zum Einsatz, an ihnen ändert sich nichts! SSL/TLS ist ja gerade eine Verschlüsselung auf Transportebene, d. h., die gesamte Verbindung wird gesichert, und darüber läuft dann „normales" POPS ab. Genauer könnte man sagen: HTTP, POPS, IMAP, SMTP über SSL/TLS.
 
−
So gut wie alle heutigen Mailclients unterstützen das. Manchmal ist es direkt als POPSs oder IMAPs benannt, manchmal ist es etwas verklausuliert in der Konfi­guration zu finden: „Server erfordert sichere Verbindung." Auf jeden Fall sollten Sie Ihre Nutzer grundsätzlich anhalten, diese Verfahren zu benutzen - es gibt eigentlich keine Nachteile, außer etwas CPU-Last. Auch hausintern sollten Sie grundsätzlich Verschlüsseltes POPS und IMAP einsetzen: Ausgespähte Passwör­ter sind ein vollkommen überflüssiges Sicherheitsrisiko.
 
−
Die Frage der Authentifizierung des Mailservers spielt dabei eine unwichtigere Rolle als bei Web-Servern. Häufig werden deshalb selbstsignierte Schlüssel ein­gesetzt, denn das spart die Signierungsskosten einer kommerziellen CA. Der An­wender kann dann darauf vertrauen, dass der Schlüssel tatsächlich zu seinem Mailserver gehört. Denn anders als beim Web hat es der Nutzer i. d. R. nicht mit völlig fremden, wechselnden Webservern unbekannter Anbieter zu tun, sondern stets mit „seinem" Mailserver, auf dem sein Postfach liegt.
 
−
Mailclients warnen teilweise beim Aufbau von POP3s oder IMAPs-Verbindungen zu Servern mit selbstsignierten Schlüsseln. Doch da der Nutzer diese Schlüssel lokal akzeptieren und abspeichern kann, ist man für die Zukunft trotzdem ge­sichert und kann Authentizität garantieren: Würde ein Angreifer den Schlüssel austauschen, so würde das der Mailclient merken, denn der übertragene Schlüs­sel stimmt nicht mehr mit dem gespeicherten überein.
 
−
Nicht unbedingt die Authentifizierung ist es also, die uns treibt, sondern die Verschlüsselung der Mailverbindungen! Sowohl die e-Mails als auch der POP3/ IMAP-Dialog wird kodiert. Und dadurch gehen auch Zugangsdaten zum Post­fach nie im Klartext über das Netz.
 
−
SSL/TLS macht jedoch Systeme wie PGP keinesfalls überflüssig. Denn SSL/TLS sichert nur den Moment des Transports. In der Sekunde des Abrufs gehen alle Daten unlesbar über die Leitung. Auf dem Server selbst und auch auf dem Client liegen sie hingegen im Klartext vor, wie immer. Ein Angreifer könnte die Mails dort problemlos lesen. Auch sonst kann man nie sicherstellen, wie eine e-Mail an das Ziel gelangt. Die wenigsten Mailserver versuchen untereinander eine SMTPs-Verbindung aufzubauen, i. d. R. wird Klartext-SMTP verwendet. Wollen wir also den elektronischen Briefumschlag zukleben, brauchen wir PGP. Und wollen wir unsere Login-Daten geheim halten, brauchen wir SSL/TLS. Es ist keine Frage des „entweder-oder", sondern eine Frage des „sowohl-als auch"!
 
−
 
 
−
 
 
−
===Mails abholen mit IMAP-SSL===
 
−
 
 
−
Trotz seiner zusätzlichen Funktionalitäten überträgt IMAP sowohl Authentifizierung als auch die eigentlichen E-Mails unverschlüsselt.
 
−
Hier hilft das Zusatzpaket courier-imap-ssl. Installiert wird es durch den Aufruf voneinander
 
−
 
 
−
apt-get install courier-imap-ssl
 
−
 
 
−
Nach dem Download, vor der Installation erscheint ein Textfenster welches darauf hinweist, dass das Paket während der Installation ein selbstsigniertes Zertifikat generieren wird. Dieses ist zu demonstrationszwecken ausreichend. Für den Produktivbetrieb ist es jedoch unter Umständen angebracht das Zertfikat von einer offiziellen Zertifizierungsstelle unterschreiben zu lassen, so dass die Gültigkeit von jedem E-Mail-Client überprüft werden kann.
 
−
 
 
−
Nachdem das Paket installiert und das Zertifikat generiert ist sollte der imap-ssl Daemon starten.
 
−
Dies kann mit
 
−
 
 
−
pate:~# netstat -lntp | grep 993
 
−
tcp        0      0 0.0.0.0:993            0.0.0.0:*              LISTEN    16786/couriertcpd
 
−
 
 
−
überprüft werden.
 
−
Die Konfiguration ähnelt der des normalen IMAPd. Tatsächlich ist es sogar so, daß zuerst dessen Konfiguration eingelesen und dann durch den Inhalt von imapd-ssl ergänzt. Dadurch wird der Konfigurationsaufwand merklich verringert, da nicht alle Defaults noch einmal gesetzt werden müssen.
 
−
<pre>
 
−
pate:~# cat /etc/courier/imapd-ssl
 
−
#Port an dem imap-ssl lauschen soll
 
−
SSLPORT=993
 
−
#IP-Adresse (falls nich alle)
 
−
SSLADDRESS=0
 
−
#PID-Files
 
−
SSLPIDFILE=/var/run/courier/imapd-ssl.pid
 
−
IMAPDSSLSTART=YES
 
−
#IMAP-StartTLS-Funktionalität
 
−
IMAPDSTARTTLS=YES
 
−
#Login nur mit TLS, wenn Wert=1
 
−
IMAP_TLS_REQUIRED=0
 
−
COURIERTLS=/usr/bin/couriertls
 
−
TLS_PROTOCOL=SSL3
 
−
TLS_STARTTLS_PROTOCOL=TLS1
 
−
#Nur bestimmte Verschlüsselungsalgorithmen zulassen
 
−
# TLS_CIPHER_LIST="ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH"
 
−
#Pfad zur Zertifikatsdatei
 
−
TLS_CERTFILE=/etc/courier/imapd.pem
 
−
#Soll das Clientzertifikat überprüft werden (NONE=nein, PEER=wenn der Client ein Zertifikat
 
−
# vorlegt, REQUIREPEER=Fehler, wenn der Client kein Zertifikat vorlegt)
 
−
TLS_VERIFYPEER=NONE
 
−
#Sessioncache (experimentell)
 
−
TLS_CACHEFILE=/var/lib/courier/couriersslcache
 
−
TLS_CACHESIZE=524288
 
−
#Pfad zum Maildir
 
−
MAILDIRPATH=Maildir
 
−
</pre>
 
−
==Mails sicher verschicken: Postfix-mit TLS==
 
−
Um auch den Mailversand über Postfix sicher zu machen brauchen wir noch einige Pakete:
 
−
 
 
−
apt-get install postfix-tls libsasl2-modules-gssapi-heimdal libsasl2-modules sasl2-bin
 
−
 
 
−
Anders als bei Courier müssen wir das Zertifikat hier jedoch selbst generieren. Dabei hilft uns OpenSSL.
 
−
Die Befehle
 
−
/usr/lib/ssl/misc/CA.sh -newreq # zum erstellen einer Zertifizierungsanfrage
 
−
/usr/lib/ssl/misc/CA.sh -sign # zum unterschreiben der selben
 
−
und
 
−
openssl rsa < newreq.pem > key.pem # um einen Key ohne Passwort zu erhalten
 
−
 
 
−
sollten ausreichen, wenn schon eine CA existiert. Ansonsten kann eine solche vorher mit
 
−
/usr/lib/ssl/misc/CA.sh -newca
 
−
einfach erstellt werden.
 
−
 
 
−
Aschließend müssen die Zertifikate an die richtigen stellen kopiert werden:
 
−
cp newcert.pem /etc/postfix/cert.pem
 
−
cp key.pem /etc/postfix/key.pem
 
−
cp demoCA/cacert.pem /etc/postfix/CAcert.pem
 
−
chmod 400 /etc/postfix/*.pem
 
−
 
 
−
Damit ist Postfix vorbereitet. Nun muß TLS noch aktiviert werden. Hierzu werden folgende Einträge in der main.cf benötigt:
 
−
 
 
−
# aktiviert STARTTLS wenn Postfix Server ist:
 
−
smptd_use_tls = yes
 
−
 
−
# Loggt (nicht) in den Received-Zeilen:
 
−
smtpd_tls_received_header = no
 
−
 
−
smtpd_tls_key_file = /etc/postfix/key.pem
 
−
smtpd_tls_cert_file = /etc/postfix/cert.pem
 
−
smtpd_tls_CA_file = /etc/postfix/CAcert.pem
 
−
 
−
# Aktiviert STARTTLS wenn Postfix ausliefert:
 
−
smtp_use_tls = yes
 
−
 
−
smtp_tls_key_file = /etc/postfix/key.pem
 
−
smtp_tls_cert_file = /etc/postfix/cert.pem
 
−
smtp_tls_CA_file = /etc/postfix/CAcert.pem
 
−
 
 
−
 
 
−
Auch die master.cf muß angepasst werden:
 
−
 
 
−
smtps    inet  n      -      n      -      -      smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
 
−
587      inet  n      -      n      -      -      smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
 
−
 
 
−
(Diese beiden Zeilen sind dort wahrscheinlich schon vorhanden und müssen lediglich durch entfernen des Kommentarzeichens aktiviert werden)
 

Aktuelle Version vom 22. Juli 2021, 06:47 Uhr

Links

Migration

Abgerufen von „https://xinux.net/index.php?title=Mailserver&oldid=26109“