Mailserver

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. Heute werden diese text messages E-Mails genannt. Für deren Transport haben sich zwei verschiedene Protokolle herauskristallisiert. Simple Mail Transfer Protocol (SMTP) Unix to Unix Copy (UUCP) 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. 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. Da UUCP keine TCP/IP-Verbindung erfordert, eignet es sich ideal zur E-Mail-Anbindungvon Hochsicherheitssystemen Die Konfiguration von UUCP wird nur noch in Einzelfällen benötigt, so dass sich dieses Skript auf SMTP beschränkt.

Arbeitsweise des Protokolls SMTP

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. 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. Anders als bei UUCP werden die Mails sofort zugestellt, sofern der Empfänger erreichbar ist

SMTP-Versand per telnet

Diese Kommunikation erfolgt in einzelnen Schritten, die alle nacheinander auszuführen sind: Angabe des Absenders Syntax 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. -

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:

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.

1. 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.

#======================================================================
# 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}

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. 1. postalias für die aliases-tabelle 2. 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.

1. /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

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:

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

1. allgemeines freischalten der virtuellen domains. das blabla dient nur als platzhalter.

apfel.int blabla birne.int blabla delicius.int blabla

1. vertrieb@apfel.int wird hier dem lokalen konto apfel-vertieb zu geordnet.

vertrieb@apfel.int apfel-vertrieb

1. webmaster@apfel.int wird hier dem lokalen apfel-webmaster zu geordnet.

webmaster@apfel.int apfel-webmaster

1. 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

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

1. canonical_maps -> Umwandlung bei Absende und Empfängeradressen 2. sender_canonical_maps-> Umwandlung bei Absendeadressen 3. recipient_canonical_maps -> Umwandlung bei Empfängeradressen

1. wandelt eine localen absender adresse in eine offizielle adresse um

root technik@provider.int

1. 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 1.SMTP -> Sendmail Transport Protokoll 2.UUCP -> Unix 2 Unix Copy 3.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.

1. 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

6.3.3.5 relocated_maps = hash:/etc/postfix/relocated relocated bounct unzustellbare Mails unter Angabe der neuen Mailadresse des verzogenen Accounts

1. 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

6.4 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)

6.4.1 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:

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

6.3.3.5 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

1. 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

1. /etc/postfix/access

provider.int OK apfel.int OK birne.int OK delicius.int OK tuxmen.int OK

Danach wird in das Datenbankformat umgewandelt postmap /etc/postfix/access

6.3.1 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. 6.3.2 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 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:

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

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 Es gibt dann Zwei Konfigurationsdateien die in der Regel nicht angepasst werden müssen

pate:/etc/courier# cat authdaemonrc

1. 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

pate:/etc/courier# cat imapd

1. Adresse wo der imap server lauschen soll

ADDRESS=0

1. der Port der imap verwenden soll

PORT=143

1. maxiamleAanzahl der imap daemons

MAXDAEMONS=40

1. Maixmale Verbindungen per IP

MAXPERIP=20

1. Datei der die Prozess id enthält Prozess ID

PIDFILE=/var/run/courier/imapd.pid

1. Optionen der couriertcpd sollten nicht geändert werden

TCPDOPTS="-nodnslookup -noidentlookup"

1. Wenn AUTHMODULES="authdaemon", gesetzt ist “DO NOT CHANGE IT”
2. Ändere den Parameter in der /etc/courier/autdaemon

AUTHMODULES="authdaemon"

1. fuer das webminmodul

AUTHMODULES_ORIG="authdaemon"

1. Debuglevel

DEBUG_LOGIN=0

1. antwort auf das CAPABILITY-Kommando

IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE"

1. custom keywords freischalten

IMAP_KEYWORDS=1

1. für webadmin

IMAP_CAPABILITY_ORIG="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 IDLE"

1. Idle-Timeout des IMAP-Servers

IMAP_IDLE_TIMEOUT=60

1. SASL PLAIN authentifizierung nach STARTTLS erlauben

IMAP_CAPABILITY_TLS="$IMAP_CAPABILITY AUTH=PLAIN"

1. wird von webadmin benutzt

IMAP_CAPABILITY_TLS_ORIG="$IMAP_CAPABILITY_ORIG AUTH=PLAIN"

1. darf der Client auf dem Server Thread und SORT Kommandos ausführen? (erhöht die Serverlast!)

IMAP_DISABLETHREADSORT=0

1. In allen Ordnern nach neuer Mail suchen (nur sinnvoll, wenn Mails auf dem Server in die
2. Unterordner sortiert werden). Erhöht die Last auf dem Server!

IMAP_CHECK_ALL_FOLDERS=0

1. Workaround für Fehlerhafte Clients

IMAP_OBSOLETE_CLIENT=0

1. Maximale größe des Serverprozesses (64MB) – kann gegen DoS-Attacken schützen

IMAP_ULIMITD=65536

1. sollte bei der benutzung von “shared folders” unbedingt aktiv sein!

IMAP_USELOCKS=1

1. Index aller zugänglichen Ordner

IMAP_SHAREDINDEXFILE=/etc/courier/shared/index

1. Idle-Modus (für Konkurrierende Updates)

IMAP_ENHANCEDIDLE=0

1. Name des Trash-Folders (für Outlook-Kompatibilität sollte hier “Deleted Items” stehen)

IMAP_TRASHFOLDERNAME=Trash

1. Trash-Folder nach 7Tagen, Sent-Folder nach 30Tagen löschen (bezieht sich auf CTIME-Stamp)

IMAP_EMPTYTRASH=Trash:7,Sent:30

1. Mails löschen oder in den Mülleimer werfen?

IMAP_MOVE_EXPUNGE_TO_TRASH=0

1. Zusatzfeature: Mails verschicken durch ablegen in diesem Ordner

OUTBOX=.Outbox

1. dazu wird das folgende sendmail aufgerufen

SENDMAIL=/usr/sbin/sendmail

1. Headerfeld in dem der Absender nochmals hinterlegt wird, wenn eine Mail wie oben verschickt
2. wird

HEADERFROM=X-IMAP-Sender

1. IMAPD starten? (wird von manchen Distributionen in Init-Skripten abgefragt)

IMAPDSTART=YES

1. Pfad zum Maildir

MAILDIRPATH=Maildir

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.

pate:~# cat /etc/courier/imapd-ssl

1. Port an dem imap-ssl lauschen soll

SSLPORT=993

1. IP-Adresse (falls nich alle)

SSLADDRESS=0

1. PID-Files

SSLPIDFILE=/var/run/courier/imapd-ssl.pid IMAPDSSLSTART=YES

1. IMAP-StartTLS-Funktionalität

IMAPDSTARTTLS=YES

1. Login nur mit TLS, wenn Wert=1

IMAP_TLS_REQUIRED=0 COURIERTLS=/usr/bin/couriertls TLS_PROTOCOL=SSL3 TLS_STARTTLS_PROTOCOL=TLS1

1. Nur bestimmte Verschlüsselungsalgorithmen zulassen
2. TLS_CIPHER_LIST="ALL:!ADH:RC4+RSA:+SSLv2:@STRENGTH"
3. Pfad zur Zertifikatsdatei

TLS_CERTFILE=/etc/courier/imapd.pem

1. Soll das Clientzertifikat überprüft werden (NONE=nein, PEER=wenn der Client ein Zertifikat
2. vorlegt, REQUIREPEER=Fehler, wenn der Client kein Zertifikat vorlegt)

TLS_VERIFYPEER=NONE

1. Sessioncache (experimentell)

TLS_CACHEFILE=/var/lib/courier/couriersslcache TLS_CACHESIZE=524288

1. Pfad zum Maildir

MAILDIRPATH=Maildir

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:

1. aktiviert STARTTLS wenn Postfix Server ist:

smptd_use_tls = yes

1. 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

1. 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)