Installation und Konfiguration eines kompletten Mailservers basierend auf RedHat Linux / Fedora Core mit Hilfe von postfix, amavisd-new, Spamassassin, OpenAntivirus / ClamAV, uw-IMAP, Squirrelmail

Copyright © 2006 by Stefan Bielenberg

E-Mail: stefan(dot)bielenberg(at)web(dot)de

Revision: Feb 03, 2009

`"

Contents

1  Geschichte machen
2  Überblick behalten
3  Disk-Jockey spielen
    3.1  Vorbereitungen
    3.2  Installation von RedHat oder Fedora Core
    3.3  Austauschen des Mailservers und Test
4  Zur Post gehen
    4.1  Postfix als Standalone Mailserver
        4.1.1  Die Datei aliases
        4.1.2  Die Datei local_domains
        4.1.3  Die Datei transport
        4.1.4  Die Datei virtual
    4.2  Postfix als Relaying Mailserver
    4.3  Postfix mit Smarthost und AUTH
5  Zum (An)Schlag ausholen
    5.1  Installation von SpamAssassin
    5.2  Konfiguration von SpamAssassin
6  Feinde entdecken
    6.1  Installation von amavis-new
    6.2  Konfiguration von amavis-new
7  Gegenma ßnamen einleiten
    7.1  ClamAV installieren
    7.2  ClamAV konfigurieren
    7.3  ClamAV in Amavisd-new aktivieren
    7.4  OpenAntivirus installieren
    7.5  OpenAntivirus konfigurieren
    7.6  OpenAntivirus in Amavisd-new aktivieren
    7.7  Alles testen
8  Wer da?
    8.1  Installation und Konfiguration von SMTP-Auth
9  Sicher befördern
    9.1  Anlegen von Server-Zertifikaten
        9.1.1  Die eigene CA sein
        9.1.2  Server-Zertifikate erstellen
        9.1.3  Letzte Schritte
    9.2  Konfiguration von TLS/SSL
    9.3  Nochmal alles Testen
10  Zu Diensten sein
    10.1  Installation von POP3, POP3S, IMAP und IMAPS
    10.2  Konfiguration von POP3, POP3S, IMAP und IMAPS
    10.3  Noch sicherer mit IMAP und CRAM-MD5
11  Reinlassen
    11.1  Installation und Konfiguration von Squirrelmail
    11.2  Hinzufügen von Plugins
A  Aussperren
    A.1  Hinweise für die Sicherung mit einer Firewall
B  Zwei auf einen Streich - Mail-Logging
C  Ein FTP Server mit VSFTPD
D  Zeitsynchronisation mit NTP
E  Nachlesen
    E.1  Antivirus
    E.2  Amavis / Scanner
    E.3  Postfix
    E.4  TLS/SSL
    E.5  SMTP-AUTH
    E.6  SpamAssassin
    E.7  Sonstige

1  Geschichte machen

Ich habe diese Dokumentation geschrieben, nicht weil sie völlig neue Erkenntnisse vermitteln soll, sondern weil sie eine Zusammenfassung aller von mir gefundenen und genutzten Dokumentationen über das Erstellen von Mailserver, die im Internet zu finden sind, darstellen soll. Und es gibt viele dieser Dokumentationen, allerdings keine, die alle diese Programme zusammenfasst und miteinander zu einem Produkt/Paket verbindet.
Daher Dank an alle, die wissend oder unwissend zu diesem Dokument beigetragen haben. Auf diesem Wege auch an Ralf Spenneberg, dessen Artikel [1] diesem Dokument als Vorlage diente.

2  Überblick behalten

Dieses Dokument beschreibt die Installation eines kompletten Mailservers bestehend aus folgenden Komponenten:

3  Disk-Jockey spielen

3.1  Vorbereitungen

Da Du einen Mailserver installieren willst, solltest Du folgende Partitionsstruktur beachten:
Wobei der Platz, den /var benötigt ausreichend groß gewählt werden sollte.

3.2  Installation von RedHat oder Fedora Core

Bei der Installation halte Dich vor allem an die Richtlinien im Installationshandbuch. Wenn Du noch keine Software hast, dann gehe zu z.B. ftp://ftp.redhat.com/pub/redhat/linux/9/en/iso/i386/ (für RedHat 9.0) oder zu z.B. ftp://tux.cprm.net/pub/ftp.redhat.com/fedora/linux/core/1/i386/iso/ (für Fedora Core 1) und lade Dir die ISO-Packages herunter. Eine Installationsanleitung findest Du bestimmt unter http://www.redhat.com.
Installiere mit der Distribution auch gleich folgende Software von den CD's mit:
Wenn Du das vergessen solltest, dann kannst Du diese Programme ja jederzeit mit dem Befehl
    # rpm -U -v dateiname.rpm

von der CD nachinstallieren. Ich werde später an den entsprechenden Stellen noch einmal speziell darauf hinweisen was zu installieren ist.

3.3  Austauschen des Mailservers und Test

Seit Version 7.3 liefert RedHat alle Distributionen immer mit zwei Mailservern aus: postfix und sendmail. Da nur immer ein Programm am Port 25 horchen kann ist (wohl aus historischen Gründen immer) sendmail als Standard-Mailserver konfiguriert. Um zu überprüfen, welches Programm zur Zeit installiert ist, tippst Du:
    # alternatives --display mta

    mta - status is auto.
    link currently points to /usr/sbin/sendmail.sendmail
    /usr/sbin/sendmail.sendmail - priority 90 slave mta-mailq:
    /usr/bin/mailq.sendmail slave mta-newaliases:
    /usr/bin/newaliases.sendmail slave mta-rmail:
    /usr/bin/rmail.sendmail slave mta-mailqman:
    /usr/share/man/man1/mailq.sendmail.1.gz slave mta-newaliasesman:
    /usr/share/man/man1/newaliases.sendmail.1.gz slave mta-aliasesman:
    /usr/share/man/man5/aliases.sendmail.5.gz
    /usr/sbin/sendmail.postifx - priority 30 slave mta-mailq:
    /usr/bin/mailq.postfix slave mta-newaliases:
    /usr/bin/newaliases.postfix slave mta-rmail:
    /usr/bin/rmail.postfix slave mta-mailqman:
    /usr/share/man/man1/mailq.postfix.1.gz slave mta-newaliasesman:
    /usr/share/man/man1/newaliases.postfix.1.gz slave mta-aliasesman:
    /usr/share/man/man5/aliases.postfix.5.gz Current "best" version is
    /usr/sbin/sendmail.sendmail.

Um den MTA von sendmail auf postfix zu ändern tippst Du weiterhin:
    # alternatives --config mta

    There are 2 programs which provide "mta".

    Selection   Command
    -----------------------------------------
    *+ 1        /usr/sbin/sendmail.sendmail
       2        /usr/sbin/sendmail.postfix

    Enter to keep the default[*], or type selection number: 2

Dieses Kommando richtet postfix als Mailserver auf Deinem System ein, erstellt die entsprechenden Bootdateien und erzeugt ebenfalls eine Konfiguration mit der man schon vorzüglich arbeiten kann.
Nun solltest Du das System neu booten um ganz sicher zu stellen, dass alle Prozesse korrekt gestartet sind. Achte auch auf folgende Zeile beim Booten:
    # service postfix status
    master (pid 9864) is running

Wenn Du gebootet hast, dann können wir schon mal den Mailserver testen. Dazu machen wir ein telnet auf Port 25:
    # telnet localhost 25
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    220 station.example.com ESMTP Postfix
    quit
    221 Bye
    Connection closed by foreign host.

Wenn der Mailserver antwortet, dann hast Du schon den ersten Schritt geschafft, gehe weiter auf LOS und ziehe 4000 ein...

4  Zur Post gehen

Wie alle Mailserver kann auch postfix auf zwei verschiedene Arten installiert werden. Entweder als Standalone-MTA, der die Email annimmt und ins Internet verteilt oder als Relaying MTA, der die Email entgegennimmt und an einen richtigen Mailserver weiterleitet.

4.1  Postfix als Standalone Mailserver

Ein Standalone Mailserver sendet und empfängt Email selber. Das bedeutet aber auch, dass er nötigenfalls eine FQDN benötigt, da es sonst manche Mailserver ablehnen von ihm Email zu empfangen. Es ist recht einfach eine Konfiguration dafür zu erstellen. Du benötigst einfach folgende Einstellungen in Deiner /etc/postfix/main.cf:
    # all information mail goes to postmaster
    soft_bounce = no

    # tell the postmaster about mail problems
    # notify_classes = resource, software, bounce, policy
    notify_classes = resource, software, policy

    # zum Testen Code 450 (später erneut versuchen) einstellen
    # wenn alles getestet, dann umstellen auf Code 550 (ablehnen)
    # unknown_local_recipient_reject_code = 550
    unknown_local_recipient_reject_code = 450

    # Queue directory and chroot
    queue_directory = /var/spool/postfix

    # Location of the post* commands
    command_directory = /usr/sbin

    # Location of the postfix daemon commands
    daemon_directory = /usr/libexec/postfix

    # Privileges
    mail_owner = postfix

    # FQDN of the mailserver
    myhostname=host.example.com

    # Domain to serve
    mydomain=example.com

    # Domain to masquerade as
    myorigin=$mydomain

    # ip addresses to listen on
    inet_interfaces = all

    # Names to receive email for
    mydestination=$mydomain $myhostname localhost localhost.$mydomain

    ######### to separate domains ###########
    # Virt domain names to receive email for (all users here have to defined in virtual_alias_maps,
    # if not they are rejected!!!)
    virtual_alias_domains = /etc/postfix/local_domains

    # define all users for domains in virtual_alias_domains (if not the are rejected!!!)
    virtual_alias_maps = hash:/etc/postfix/virtual
    #########################################

    # ip addresses to relay emails for
    mynetworks=192.168.0.0/24, 127.0.0.0/8

    # show mailserver name for all
    smtpd_banner = $myhostname ESMTP $mail_name

    # tell the postmaster about mail problems
    notify_classes = resource, software, policy

    # IF a relayhost is used for the connection
    # to the internet
    # relayhost=[$mail.myprovider]

    # how to restrict the delivery of the email
    smtpd_recipient_restrictions = permit_mynetworks, check_relay_domains, reject_unauth_destination

    # Aliases database
    alias_database = hash:/etc/postfix/aliases

    # if we have more then one domain
    virtual_maps = hash:/etc/postfix/virtual

    # if we want to change the way of transport
    transport_maps = hash:/etc/postfix/transport

    # if dns resolution is not permanently available
    # disable_dns_lookups=yes

Die Konfiguration in /etc/postfix/master.cf musst Du in diesem Schritt noch nicht verändern. Sie sieht bis jetzt noch folgendermaßen aus:
#=====================================================================
# service type private unpriv chroot wakeup maxproc command + args
#              (yes)   (yes)  (yes)  (never) (50)
#=====================================================================
smtp      inet n       -      y      -      -       smtpd
#smtps    inet n       -      y      -      -       smtpd \
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
#submission inet n     -      y      -      -       smtpd \
-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
#628      inet n       -      n      -      -       qmqpd
pickup    fifo n       -      y      60     1       pickup
cleanup   unix n       -      y      -      0       cleanup
#qmgr     fifo n       -      y      300    1       qmgr
qmgr      fifo n       -      y      300    1       nqmgr
rewrite   unix -       -      y      -      -       trivial-rewrite
bounce    unix -       -      y      -      0       bounce
defer     unix -       -      y      -      0       bounce
flush     unix n       -      y      1000?  0       flush
smtp      unix -       -      y      -      -       smtp
showq     unix n       -      y      -      -       showq
error     unix -       -      y      -      -       error
local     unix -       n      n      -      -       local
virtual   unix -       n      n      -      -       virtual
lmtp      unix -       -      n      -      -       lmtp

Weitere Informationen findet man in [2] oder in [3].

4.1.1  Die Datei aliases

In dieser Datei stehen alle Benutzernamen und ihre Aliases für die Suche nach lokalen Benutzern. Ein paar Beispiele:
    # ein lokaler Benutzer mit verschieden Mail-Adressen
    heinz.mustermann:       heinz
    hmustermann:            heinz
    heinzilein:             heinz
    hm:                     heinz
    # eine lokale Mailing Liste
    info:                   meier, mueller, schmidt, lehmann
    # eine lokale Mailing Liste mit externen Mailempfängern
    info_all:               meier, mueller, schmidt, lehmann, stefan@ibm.de, koch@siemens.de

4.1.2  Die Datei local_domains

In dieser Datei stehen alle virtuellen Domainen, für die Mails angenommen werden sollen. Die locale Domain muß hier nicht rein, denn wir haben sie ja schon in mydomain in der main.cf eingetragen. Sie ist die einzige reale Domain.
Ein paar Beispiele:
    example.de
    test.de
    test-test.com
    killer.org

4.1.3  Die Datei transport

Sollen Mails für einige Domains oder User speziell weitergeleitet werden, dann stehen hier die Regeln dafür. Ein paar Beispiele:
    # Zustellung von eMail erfolgt normal
    telmecsa.com    local:
    # Weiterleitung auf anderen Mailserver
    teletext.de     smpt:mail.example2.de

4.1.4  Die Datei virtual

In dieser Datei stehen die virtuellen Aliases/Maps von existierenden lokalen Benutzern. Im Gegensatz zu aliases können hier auch Domains zu den Usernamen geschrieben werden. User, die hier nicht definiert sind, existieren nicht und Ihre eMail werden nicht angenommen. Daher muß für jeden existierenden internen Benutzer hier eine eMail-Adresse zugeordnet werden
Ein paar Beispiele:
    # hier ein normaler Eintrag für eine Domain mit einem realen User,
    # aber mit verschiedenen virtuellen eMail-Namen. Somit kommen alle
    # Mails an "meier" an, egal wie man ihn schreibt
    bieli.de                anything
    postmaster@example1.de  postmaster
    meier@example1.de       meier
    maier@example1.de       meier
    meyer@example1.de       meier
    mayer@example1.de       meier

    # hier ein Beispiel, wie an alle virtuellen Benutzer einer Domain
    # in eine andere holen kann, ohne alles extra noch mal zu schreiben:
    @example1.de            @example1.com

    # Beispiel für ein Catch-All: nimme alle eMails an diese Domain an
    # und weise sie dem User "test" zu
    @example4.com           test

    # Umleitung von einer virtuellen externen Domain, die lokal nicht
    # existiert auf einen lokalen User. So kann man gut mehrere
    # gleiche Mail-Namen benutzen und auf andere interne Umlenken
    import@example1.es      import_example1
    export@example1.es      export_example1

    import@example2.com     import_example2
    export@example2.com     export_example2

    import@example3.com     import_example3
    export@example3.com     export_example3

4.2  Postfix als Relaying Mailserver

Wenn postfix als Relaying Mailserver eingerichtet werden soll, bedeutet das, dass die ankommenden Emails an einen offiziellen Haupt-Mailserver weitergereicht werden, der diese dann ausliefert. Ein Beispiel dafür ist ein Abteilungs-Mailserver, der nur für die Emails einer speziellen Abteilung zuständig ist, sonst aber nicht öffentlich auftritt oder von anderen Abteilungen Emails übernimmt.
Soll der MTA als Relay arbeiten, dann müssen einige Optionen anders eingestellt werden; ansonsten bleiben die Einstellungen, so wie in Kapitel 4.1.
Die geänderten Zeilen von /etc/postfix/main.cf sehen wie folgt aus:
    # Internal Mailserver (IP address)
    internal_mail = x.x.x.x

    # ip addresses to relay emails for
    mynetworks=$internal_mail, 127.0.0.0/8

    # how to restrict the delivery of the email
    smtpd_recipient_restrictions = permit_mynetworks, check_relay_domains, reject_unauth_destination

    # if a relayhost is used for the connection
    # to the internet
    # relayhost=[$mail.myprovider]

Änderungen an der /etc/postfix/master.cf sind auch bei dieser Konfiguration nicht notwendig, allerdings benötigt man bei den meisten Relay-MTAs auch keinen lokalen Auslieferungsservice, daher folgende Konfiguration:
#=====================================================================
# service type private unpriv chroot wakeup maxproc command + args
#              (yes)   (yes)  (yes)  (never) (50)
#=====================================================================
smtp      inet n       -      y      -      -       smtpd
#smtps    inet n       -      y      -      -       smtpd \
-o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
#submission inet n     -      y      -      -       smtpd \
-o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
#628      inet n       -      n      -      -       qmqpd
pickup    fifo n       -      y      60     1       pickup
cleanup   unix n       -      y      -      0       cleanup
#qmgr     fifo n       -      y      300    1       qmgr
qmgr      fifo n       -      y      300    1       nqmgr
rewrite   unix -       -      y      -      -       trivial-rewrite
bounce    unix -       -      y      -      0       bounce
defer     unix -       -      y      -      0       bounce
flush     unix n       -      y      1000?  0       flush
smtp      unix -       -      y      -      -       smtp
showq     unix n       -      y      -      -       showq
error     unix -       -      y      -      -       error
#local    unix -       n      n      -      -       local
virtual   unix -       n      n      -      -       virtual
lmtp      unix -       -      n      -      -       lmtp

Weiterhin benötigt diese Konfiguration Eintragungen in der Datei /etc/postfix/transport, welche die Methoden der Auslieferung an interne Mailserver enthält. Diese Datei sollte folgendes enthalten:
    example.com smtp:[ip_internal_mail]

Um die Änderungen daran festzuschreiben und zu aktivieren tippe:
    # postmap /etc/postfix/transport

Weitere Informationen findet man in [2] oder in [3].

4.3  Postfix mit Smarthost und AUTH

Manchmal ist es aus einigen Gründen nicht möglich selbst eMails an andere Mailserver auszuliefern, bzw. diese nehmen keine Mails von unserem Server entgegen. Günde dafür könnten sein:
Dann ist es sinnvoll einen sogenannten Smarthost zu benutzten. Das sind Mailserver (meist vom eigenen Provider), die von unserem Server Mails zur Auslieferung an andere Mailserver entgegennehmen. Damit geben wir zwar die Verantwortung für die Zustellung von Mails an einen anderen Server ab, aber das kann in manchen Fällen die einzige Lösung zu Auslieferung von Mails an bestimmte andere Server sein.
Manchmal ist der Smarthost so gut konfiguriert, dass er automatisch erkennt wer bei ihm seine Mails abliefern darf. Z.B. erkennt manchmal der Mail-Relay eines Providers, welche Rechner (welche IP-Adressen) zu seinem Netzwerk gehören und lässt ein Relay zu. In diesem Fall reicht die Aktivierung der folgenden Zeile in der /etc/postfix/main.cf:
    relayhost=[smtp.myprovider.de]

Meistens erlauben diese Smarthost aber nur ein Relay per Authentifizierung. Dann muß die /etc/postfix/main.cf um folgende Zeilen ergänzt werden:
    relayhost = smtp.myprovider.de
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    smtp_always_send_ehlo = yes
    smtp_sasl_security_options = noanonymous

Um die SASL-Authentifizierung zu aktivieren ist es nötig weitere Software-Pakete zu installieren. Welche und wie, dass wird in Kapitel 8.1 genauer erklärt.
In der Datei /etc/postfix/sasl_passwd werden die Passwörter für die Authentifizierung wie folgt abgelegt:
    smtp.myprovider.de benutzername:passwort

Danach ist noch ein postmap /etc/postfix/sasl_passwd Einlesen der Konfiguration des Services mit service postfix reload notwendig. Das wars.

5  Zum (An)Schlag ausholen

SpamAssassin (kurz SA) ist ein Mail-Filter, welcher versucht, SPAM1 (also unerwünschte Werbemails) als solchen zu erkennen und markieren. SA sucht mit Hilfe von Regeln nach Mustern, welche in Werbemails auftreten. Insbesondere werden dazu der Mailbody, also der eigentliche Text der Mail, sowie die Anhänge (Attachments) untersucht. Spamassassin bewertet dabei die eingehende Mail aufgrund zahlreicher Bedingungen und vergibt als Ergebnis einen Zahlenwert, den 'Spam-Level'. Dieser Wert liegt nahe bei Null, wenn der Brief (wahrscheinlich) Spam-frei ist, er kann aber je nach Umfang der Mail beliebig groß sein. Erfahrungen haben gezeigt, dass ein Spam-Level größer als 6 bereits ein zuverlässiger Indikator für Spam darstellt. Der eigentliche Text der Mail wird nicht abgeändert und keine Mail ohne Zutun des Benutzers wird gelöscht.
Der Benutzer hat nun zwei Möglichkeiten, auf Grund dieses Spam-Levels Maßnahmen zu ergreifen:
Er kann entweder diesen Wert mit Hilfe seines Mail-Programms selbst auswerten und bestimmen, ab welchem Spam-Level er eingehende Email z.B. in einem separaten Ordner ablegt, indem er in seinem Mail-Programm einen passenden Filter definiert. (Diese Möglichkeiten haben alle Benutzer, allerdings gibt es Einschränkungen bei den Mail-Programmen.) Oder er bedient sich des speziellen Filterprogrammes procmail, das es auch erlaubt, aussortierte Mail ungelesen zu löschen. Im Gegensatz zu der anderen Möglichkeit werden so SPAM-Mails erst gar nicht heruntergeladen, wenn man per POP3 oder IMAP seine Emails lesen möchte.

5.1  Installation von SpamAssassin

Seit RedHat 8.0 ist SpamAssassin in der Distribution enthalten und kann so einfach mitinstalliert werden. Ebenfalls werden folgende Pakete benötigt und müssen mitinstalliert werden:
Installiere die genannten Pakete entweder bei der Installation, nachträglich von den CD's:
    # rpm -U -v <Dateiname>.rpm

oder wenn Du beim RedHat/Fedora-Netzwerk angemeldet bist mit:
    # yum install <Programmname>

ACHTUNG: bei der Installation von OpenSSL gibt es bei älteren Version von Redhat oder Fedora einiges zu beachten.
SpamAssassion benötigt die neueste Version von OpenSSL und OpenSSL-devel (zur Zeit 0.9.7a), allerdings brauchen andere Programme auf dem Computer immer noch die ältere Version 0.9.6. Um beide Bibliotheken vorrätig zu halten empfehle ich erst Version 0.9.6 zu installieren, dann in das Verzeichnis /lib zu wechseln und dort einen Link auf die Bibliotheken zu setzen (wenn es nicht schon automatisch erledigt wurde):
    # ln -s /lib/libssl.0.9.6 /lib/libssl.o.2
    # ln -s /lib/libcrypto.0.9.6 /lib/libcrypto.o.2

Danach bitte OpenSSL Version 0.9.7a (vielleicht gibt es schon neuere Versionen?) installieren und das ganze wiederholen:
    # ln -s /lib/libssl.0.9.7a /lib/libssl.o.4
    # ln -s /lib/libcrypto.0.9.7a /lib/libcrypto.o.4

5.2  Konfiguration von SpamAssassin

In unserer Installation wird SpamAssassin direkt von amavis-new als Filter aufgerufen, daher sind weitere Konfigurationen nicht notwendig. Später kann man gegebenenfalls noch die Datei /etc/amavisd.conf anpassen, denn dort gibt es auch noch einige Einstellungen zu SpamAssassin.
SpamAssassin ist schon sehr gut vorkonfiguriert, möchte man trotzdem noch Änderungen vornehmen, dann kann man das in /etc/mail/spamassassin tun. In local.cf z.B. mit den Befehlen:
    whitelist_from @guteDomain.com
    whitelist_from heinz@andereGuteDomain.de
    blacklist_from @boeseDomain.com
    blacklist_from teufel@andereBoeseDomain.de

Wenn man mit den Optionen von SpamAssassin nicht vertraut ist kann man sich unter http://www.yrex.com/spam/spamconfig.php auch eine Konfiguration automatisch erstellen lassen und diese Datei als local.cf abspeichern. Ebenso kann man sich auch als User dort seine persönliche Konfigurations-Datei erstellen und diese als user.prefs in seinem Home-Verzeichnis in /home/<user>/.spamassassin abspeichern. Diese überschreibt dann die Einstellungen, die in der globalen local.cf gemacht wurden.
ACHTUNG: sollte der Zugriff auf die persönlichen SpamAssassin-Konfigurationsdateien in /home/<user>/.spamassassin nicht funktionieren, dann am Besten das Verzeichnis löschen und neu anlegen. Die user.prefs sollte man sich natürlich aufgehoben haben. Neue Hash-Dateien für die persönlich angepasste Spam-Suche kann man jederzeit aus einzelnen oder gesammelten Spam-Mails erstellen, die doch noch in der persönlichen Mailbox gelandet sind. Kommandos kombiniert aus:
    sa-learn [--ham|--spam] [--file|--mbox] spam.[mail|mbox]

erledigen das für Dich.
Ich persönlich sammle Spam der durchkommen konnte in einer MBOX namens doch.junk und Junk, der keiner ist in einer Datei kein.junk. Ab und zu rufe ich dann meine eigene 'Learn'-Datei auf und beim nächsten Mal landen dann auch diese Mails an der richtigen Stelle:
    echo
    echo "Lerne spam: doch.junk ..."
    sa-learn --spam --mbox Mail/doch.junk --showdots
    echo
    echo "Lerne ham: kein.junk ..."
    sa-learn --ham --mbox Mail/kein.junk --showdots
    echo
    echo "Fertig!"

6  Feinde entdecken

Amavis (Kurzform für A Mail Virus Scanner) selber ist kein Virenscanner, sondern nur ein Aufsatz für einen Mailserver, der die meist kommandozeilenbasierten Linux-Virenscanner benutzen kann. Amavis nimmt dabei die E-Mail vom MTA entgegen, extrahiert die zu überprüfenden Daten und wendet beliebige Virenscanner darauf an. Meldet einer dieser Virenscanner eine Infektion, stoppt Amavis die Auslieferung der Mail und versendet stattdessen eine entsprechende Warnmeldung.
In der neuesten Version (die wir benutzen werden) arbeitet Amavis als Daemon und SpamAssassin wurde ebenfalls integriert. Es bringt also nichts, wenn auf dem selben Rechner auch noch Spamassassin als Daemon läuft. Wir testen das mit:
    # service spamassassin status

      und

    # chkconfig --list | grep spamassassin

Wenn der Daemon läuft, bzw. wenn dort 3:Aus steht (unterer Befehl), können wir Ihn mit folgenden Befehlen ausschalten und deaktivieren:
    # service spamassassin stop

      und

    # chkconfig --level 3 spamassassin off

6.1  Installation von amavis-new

Leider ist z.Z. Amavis-new noch kein Bestandteil von RedHat oder Fedora, daher muss das Programm von Hand installiert werden. Die Arbeit kann man sich erleichtern, wenn man die entsprechenden RPM's zur Hand hat. Außerdem benötigt Amavis noch einige weitere Perl-Pakete und Archivierungsprogramme, wie z.B. zoo, arc und rar.
Die RPM-Pakete für die Installation von Amavis-new kannst man bei Dag Wieers unter http://dag.wieers.com/packages/amavisd-new/ finden. Um stets aktuell zu sein, kann man Dags Repositories auch in yum oder up2date einbinden. Weiter Infos dazu findet man auch auf den Webseiten von Dag.
Weitere benötigte Pakete kann man von den RedHat/Fedora-CDs installieren oder man findet sie auch bei Dag Wieers:
Alle RPM-Pakete installiert man mit:
    # rpm -U -v dateiname.rpm

oder mit:
    # rpm -U -v *.rpm

Nach der Installation sollte man überprüfen, ob in /etc/passwd nun ein Benutzer amavis vorhanden ist und in url/etc/mail/aliases die Email-Aliase 'virusalert', 'postfix' und 'spampolice' angelegt wurden.
Editiere ebenfalls die Datei /etc/postfix/aliases oder /etc/mail/aliases (sollte ein Link sein) und ändere alle Aliase, die Emails nach root senden so, dass sie sie danach nach 'postfix' schicken.
Amavis unterstützt nun die folgenden Virenscanner, darunter auch den OpenAntivirus und den ClamAV, die wir später versuchsweise installieren wollen. Für einen Produktionsserver empfehle ich allerdings immer noch einen der anderen, kommerziellen Virenscanner. Ich persönlich habe gute Erfahrungen mit Panda Antivirus machen können (http://www.pandasoftware.com/download/linux/linux.asp). Die Kommandozeilenversion ist Freeware und eine ältere Version der Signaturdatei ist auch mit dabei. Allerdings sollte man diese so bald wie möglich durch eine neue ersetzen. Bei mir beendeten sich allerdings Linux-Versionen kleiner als 7.x mit einem SIGINT.

6.2  Konfiguration von amavis-new

Nach der Installation von Amavis ist es nun notwendig diesen zur Zusammenarbeit mit postfix zu konfigurieren. Dazu sind einige Änderungen in der /etc/postfix/master.cf erforderlich.
Füge folgende Zeilen ein und beachte bitte: keine Leerzeichen bei den Optionsanweisungen (bei Gleichheitszeichen, oder Kommata) verwenden!
    127.0.0.1:10025 inet n - n - - smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_delay_reject=no
        -o smtpd_helo_restrictions=
        -o smtpd_client_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject_unauth_destination
        -o mynetworks=127.0.0.0/8
        -o strict_rfc821_envelopes=yes
        -o smtpd_error_sleep_time=0
        -o smtpd_soft_error_limit=1001
        -o smtpd_hard_error_limit=1000
        -o smtpd_client_connection_count_limit=0
        -o smtpd_client_connection_rate_limit=0
        -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks


    smtp-amavis unix - - y - 2 smtp
        -o smtp_data_done_timeout=1200
        -o myhostname=mail.test.de
        -o smtp_send_xforward_command=yes
        -o disable_dns_lookups=yes

Der erste Teil fügt einen zusätzlichen SMTP-Listener auf Port 10025 hinzu. Dieser Daemon wird von Amavis dazu genutzt die gescannten Email wieder an den MTA zurückzugeben.
Nun füge folgende Zeile in die Datei /etc/postfix/main.cf ein:
    content_filter = smtp-amavis:[127.0.0.1]:10024

Mit diesem Befehl wird 'postfix' angewiesen alle Emails für das Filtern am Amavis auf localhost auf Port 10024 zu schicken. Dort werden die Emails bearbeitet und über Port 10025 (siehe oben) wieder zurück an 'postfix' gesendet.
Bitte jetzt die Datei /etc/amavisd.conf öffnen und die Zeilen suchen in denen steht:
    $mydomain = 'mail.domain.com';

    $daemon_user  = 'sweep';
    $daemon_group = 'sweep';

    @local_domains_acl = ( ".$mydomain" );

    $log_level = 0;

    $final_virus_destiny        = D_DISCARD;
    $final_banned_destiny       = D_BOUNCE;
    $final_spam_destiny         = D_DISCARD;
    $final_bad_header_destiny   = D_PASS;

    $warnvirussender = 1;
    $warnspamsender = 1;
    $warnbannedsender = 1;
    $warnbadsender = 1;
    $warnvirusrecip = 1;
    $warnbannedrecip = 1;

    $mailfrom_notify_admin     = "virusalert\@$mydomain";
    $mailfrom_notify_recip     = "virusalert\@$mydomain";
    $mailfrom_notify_spamadmin = "spam.police\@$mydomain";

Diese Zeilen nun ersetzen durch:
    $mydomain = 'mymail.mydomain.com';

    $daemon_user  = 'amavis';
    $daemon_group = 'amavis';

    # Die Prüfungen sollen für alle von Postfix verwalteten
    # Domains und Subdomains durchgeführt werden
    @local_domains_maps = ( [".$mydomain", "localhost"], read_hash("/etc/postfix/local_domains") );

    $log_level = 2;

    # Hat heutzutage sowieso kein Zweck mehr den Sender
    # der Virenmail zu informieren, durch die falschen Absenderadressen.
    $final_virus_destiny      = D_DISCARD;
    $final_banned_destiny     = D_BOUNCE;
    # Ebenso bei Spam
    $final_spam_destiny       = D_DISCARD;
    $final_bad_header_destiny = D_PASS;

    # Notify virus sender?  Bloß nicht!
    $warnvirussender = 0;   # (defaults to false (undef))
    # Notify spam sender?   Bloß nicht!
    $warnspamsender = 0;    # (defaults to false (undef))
    # Notify sender of banned files?  Kann man machen.
    $warnbannedsender = 1;  # (defaults to false (undef))
    # Notify sender of syntactically invalid header containing non-ASCII characters? Bloß nicht!
    $warnbadsender = 0;     # (defaults to false (undef))
    # Notify virus (or banned files) RECIPIENT? Wie man möchte, ich finde es sinnvoll.
    $warnvirusrecip = 1;    # (defaults to false (undef))
    $warnbannedrecip = 1;   # (defaults to false (undef))
    $warnbadhrecip = 1;     # (defaults to false (undef))

    $mailfrom_notify_admin     = "virusalert\@$mydomain";
    $mailfrom_notify_recip     = "virusalert\@$mydomain";
    $mailfrom_notify_spamadmin = "spampolice\@$mydomain";

Folgende Einstellungen für Spamassassin (in der /etc/amavis.conf) habe ich bei mir ausprobiert, aktiviert und halte sie für sinnvoll:
    $sa_tag_level_deflt  = -999;   # zeige Spam-Infos im Mail-Header immer an
    $sa_tag2_level_deflt = 5.00;   # markiere als Spam
    $sa_kill_level_deflt = 15.00;  # erweiterte Aktion (delete)

    $sa_spam_subject_tag = '***SPAM*** ';

Damit Amavis schon beim Systemstart automatisch mitgestartet wird, müssen wir noch folgenden Befehl ausführen, wenn es nicht schon bei der Installation (rpm) durchgeführt wurde:
    # chkconfig --level 3 amavisd on

Dann starten wir den 'amavisd'-Daemon mal im Debug-Modus, um zu testen, ob alles richtig installiert und konfigueriert wurde:
    # service amavisd debug

Mit Control-C brechen wir den Testlauf ab. Jetzt fehlen nur noch ein paar Eintragungen in der Datei /etc/amavisd.conf und wir sind erst einmal fertig. Vorher müssen wir aber noch den zu benutzenden Virenscanner installieren.

7  Gegenmaßnamen einleiten

7.1  ClamAV installieren

Für die Installation von OpenAntivirus (OAV) benötigen wir die entsprechenden RPM-Dateien.
Wie auch schon zuvor holen wir uns das am besten von den Repository-Seiten von Dag Wieers unter http://dag.wieers.com/packages/clamav/ und installieren es mit:
    # rpm -U -v dateiname.rpm

7.2  ClamAV konfigurieren

Möglicherweise müssen wir noch in den Dateien /etc/clamd.conf und /etc/freshclam.conf den User von 'clamav' nach 'amavis' ändern (Achtung: gleichen User wie in der /etc/amavisd.conf benutzen).
Zum Test starten wir mal den ClamAV Daemon mit:
    # service clamd start

Wenn alles geklappt hat, sollte ClamAV als Daemon laufen, seine Signatur-Dateien finden und an Port 3310 lauschen. Überprüfen Sie bitte die Logfiles unter /var/log/clamav/clamd.log und /var/log/clamav/freshclam.log auf Probleme!

7.3  ClamAV in Amavisd-new aktivieren

Dazu muß in der Datei /etc/amavisd.conf folgendes hinzugefügt werden:
    ### http://www.clamav.net/
    ['ClamAV-clamd',
      \&ask_daemon, ["CONTSCAN {}\n", '127.0.0.1:3310'],
      qr/\bOK$/, qr/\bFOUND$/,
      qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ],

7.4  OpenAntivirus installieren

Für die Installation von OpenAntivirus (OAV) benötigen wir:
Das J2RE holen wir uns am Besten als RPM von http://java.sun.com und installieren es mit:
    # rpm -U -v j2re-xxx.rpm

OpenAntivirus (wie brauchen nur den ScannerDaemon) gibt es in http://sourceforge.net/projects/openantivirus/ und die aktuellen Viren-Signaturdateien in http://www.openantivirus.org/latest.php. Den Inhalt des OAV-Archives kopieren wir am Besten nach /opt/openantivirus und den Inhalt des Signatur-Archives in ein Unterverzeichnis dort, so dass OAV seine Daten finden kann.
Zum Test starten wir dort mal den ScannerDaemon mit:
    # java -jar Scannerdaemon.jar

Wenn alles geklappt hat, sollte OAV als Daemon laufen, seine Signatur-Dateien finden und an Port 8127 lauschen.

7.5  OpenAntivirus konfigurieren

Damit OAV schon beim Systemstart automatisch mitgestartet wird, erweitern wir die Startdatei /etc/rc.local mit folgenden Befehlen:
    if [ -f /opt/openantivirus/ScannerDaemon.sh ]; then
        cd /opt/openantivirus
        ./ScannerDaemon.sh > /dev/null 2>&1
        echo -n $"Starting OpenAntivirus-Scanner..."
        cd /root
    fi

Dann erstellen wir eine Datei Scannerdaemon.sh im Verzeichnis /opt/openantivirus und schreiben in Abhängigkeit, wo bei uns das J2RE liegt:
    /usr/java/j2re_xxx/bin/java -jar ScannerDaemon.jar &

7.6  OpenAntivirus in Amavisd-new aktivieren

Dazu muß in der Datei /etc/amavisd.conf folgendes hinzugefügt werden:
    ### http://www.openantivirus.org/
    ['OpenAntiVirus ScannerDaemon (OAV)',
      \&ask_daemon, ["SCAN {}\n", '127.0.0.1:8127'],
      qr/^OK/, qr/^FOUND: /, qr/^FOUND: (.+)/ ],

7.7  Alles testen

So jetzt wollen wir mal alles per Hand starten um zu sehen, ob es auch so funktioniert, wie wir es uns gedacht haben.
Als erstes starten wir OpenAntivirus in einer eigenen Konsole mit:
    # java -jar /opt/openantivirus/ScannerDaemon.sh

Dann können wir amavis-new in einer anderen Konsole im Debug-Modus starten:
    # amavisd debug

Als letztes folgt dann Postfix mit dem Kommando:
    # postfix reload

Wenn wir jetzt eine Email per Hand verschicken und vielleicht noch den Eicar-Virus mit dazupacken (zu finden unter http://www.eicar.org/anti_virus_test_file.htm), dann sollte schon einiges zu sehen sein.
    # mail -s "Test" benutzername < eicar.com

Der auf Port 8127 (OpenAV) oder 3310 (ClamAV) horchende Virenscanner sollte den Virus bemerken (siehe Virus-Konsolen-Ausgabe) und an Amavis zurückmelden (siehe Amavis-Konsolen-Ausgabe). Amavis wird diese Virus-Mail in Quarantäne schicken (siehe Quarantäne-Verzeichnis in ...) und Postfix sollte an root und an den Versender der verseuchten Email je eine andere Meldung schicken.
Das gleiche können wir jetzt auch mal mit einer Spam-Mail versuchen. Eine sehr starke Spam-Mail (mit Spam-Level ab 15.00) sollte auch ins Quarantäne-Verzeichnis geschickt werden und weniger starke gehen als Spam gekennzeichnet weiter an den Empfänger, der sie dann mit Procmail oder mit Hilfe seines Mail-Clienten (Thunderbird, Seamonkey) aussortieren kann. Mails mit einem Spam-Level <5.00 erhalten einen Vermerk von SpamAssassin und gehen ebenfalls an den Empfänger. Jede Email wird im Header als von 'Amavis und SpamAssassin gescannt' gekennzeichnet.
Weitere E-Mails zum Testen von SpamAssassin findet man in /usr/share/doc/amavisd-new-xxxxxxxx/test-messages/. Mit ihnen kann man differenziertes Verhalten testen.
Wenn das alles geklappt hat, dann können wir ja mal den Rechner neu booten und beobachten, ob Postfix, Amavis und OpenAntivirus nun gestartet werden - wenn nicht, dann bitte noch einmal die ganze Installation überprüfen und nachbessern.
Ein verbessertes Mailsystem sollte nun auf Ihrem Rechner laufen. In den folgenden Kapiteln kümmern wir uns nun um die Verbesserung und Sicherung des System mit folgenden Komponenten und Verfahren:

8  Wer da?

Historisch gesehen sind alle SMTP-Server offen für das Versenden von Email; wenn sie auch noch im Internet stehen, kann die ganze Welt über sie Mail oder auch Spam verschicken. Um das zu verhindern wurde unter anderem auch SMTP-Auth entwickelt, so können nur User Emails über diesen Server versenden, wenn sie sich vorher durch ein Passwort authentifiziert haben.

8.1  Installation und Konfiguration von SMTP-Auth

Für die Authentifizierung gibt verschiedene Methoden. Im folgenden werde ich die Installation beispielhaft an 'saslauth' und 'saslauthdb' erklären.
Zuerst müssen wir Cyrus-SASL2 und damit wahrscheinlich folgende Programme (abhängig von der Authentifizierungsmethode) von den CD's nachinstallieren:
Danach bearbeiten wir die Datei /usr/lib/sasl2/smtpd.conf und tragen dort die zu verwendende Methode ein:
    pwcheck_method: saslauthd
    mech_list: DIGEST-MD5 CRAM-MD5 PLAIN LOGIN

Da wir nur die oben genannten Protokolle zur Authentifizierung benutzen wollen, muss dort nicht mehr drinstehen. Aber Achtung: die Reihenfolge der Protokolle bestimmt die Abarbeitungsreihenfolge durch den 'saslauthd'! Das heisst, erst versucht er die Authentifizierung mit DIGEST-MD5, dann mit CRAM-MD5 usw. Wenn also ein User keinen Eintrag in der /etc/sasldb2 hat (Protokoll CRAM-MD5), dann wird so lange in der Liste weitergesucht, bis eine andere Authentifizierungsmethode greift, z.B. funktioniert das Protokoll PLAIN, wenn der User einen Account auf dem Rechner hat. Funktioniert keine, dann wird mit einer Fehlermeldung abgebrochen.
Dann starten wir wieder 'setup' auf der Konsole und in 'Dienste' aktivieren wir 'saslauthd'. Nun müssen wir den Dienst beim ersten Mal noch von Hand starten, bzw. nach einem Systemneustart würde dieser Service dann auch laufen:
    service saslauthd start

Bitte darauf achten, dass der 'saslauthd' mit der Option 'pam' gestartet wird (siehe in /etc/sysconfig/saslauthd)!!!
Um Postfix auch noch zu informieren, dass wir ab sofort SMTP-Auth benutzen wollen müssen wir folgende Änderungen in der /etc/postfix/main.cf machen:
    smtpd_sasl_auth_enable = yes

    #Wert für realm, normalerweise der Hostname
    #wird aber von SASL selbstständig durch "hostname" gefunden,
    #daher hier bitte auskommentieren
    #smtpd_sasl_local_domain =

    #Zusatz-Optionen: Keine anonyme-Anmeldung verwenden
    smtpd_sasl_security_options = noanonymous

    #Wieder ein Workaround für ältere Clients und Outlook
    #damit auch Outlook die AUTH-Methoden erkennen kann
    broken_sasl_auth_clients = yes

    #nur SASL Zugänge erlauben
    smtpd_recipient_restrictions = permit_sasl_authenticated, reject_unauth_destination

    #ODER meine Netze und SASL erlauben
    smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

Jetzt fehlt uns nur noch ein Benutzername und ein Passwort für alle User oder für jeden einzelnen Benutzer. Ganz wie es die Policy des Mailservers vorsieht. Ich zeige hier kurz, wie man einen Benutzer einrichtet.
Das Programm für den Eintrag eines Benutzers heisst saslpasswd2 (ACHTUNG: nicht saslpasswd benutzen, das ist für eine ältere Version des Programmes gedacht). Seine Einträge macht dieses Programm in /etc/sasldb2 und benutzt wird es folgendermaßen:
    # saslpasswd2 -c <userid>

Man kann das auch nicht-interaktiv machen:
    # echo "pAsSwOrD" | saslpasswd2 -p -c Username

Danach sollte zur Probe z.B. im Mozilla unter Edit®Mail&Newsgroup Account Settings®Outgoing Server(SMTP) der SMTP-Server eingestellt werden und mit Ihm die Authentifizierungsmethode mit Userid und Passwort.

9  Sicher befördern

TLS/SSL sorgt für die sichere Beförderung der Email-Daten einerseits zwischen Mail-Client und SMTP-Server sowie andererseits zwischen verschiedenen SMTP-Servern.
Um diese Verschlüsselung zu erreichen benötigen wir postfix mit TLS/SSL-Unterstützung und ein Server-Zertifikat2, welches von uns selber (durch einen CA-Schlüssel) unterschrieben wird. Dafür werden wir unsere eigene Certificate Authority (CA) sein.

9.1  Anlegen von Server-Zertifikaten

Um verschlüsselt miteinander kommunizieren zu können braucht jeder Server, der mit TLS/SSL arbeiten will folgende Komponenten:
Wenn das jetzt einer irgendwie nicht verstanden hat, ist es auch egal, Hauptsache die nun folgenden Schritte werden so ausgeführt und abgearbeitet, wie beschrieben. Einfach Augen zu und durch.
Besten Dank an Lutz Jänicke für seine Webseite[4].

9.1.1  Die eigene CA sein

Normalerweise sollten die Schlüssel, die wir in 9.1.2 für den Mailserver erstellen von einer bekannten CA (wie z.B. VeriSign, Thawte, RSA Security) unterschrieben werden. Allerdings ist das nicht in allen Fällen (Testrechner, interne Server) notwendig, da es viel Geld kostet. Also basteln wir uns unsere eigene CA.
OpenSSL sollte installiert sein. Daher können wir gleich in einem sicheren Verzeichnis, z.B. /root/zertifikate,
    # CA.pl -newca

auf der Kommandozeile eintippen3.
Ist dieses Programm nicht installiert kann man sich auch folgende Toolsammlung von http://www.openssl.org/contrib/ssl.ca-0.1.tar.gz laden oder eine neue CA.pl z.B. von http://www.mit.edu/afs/net.mit.edu/reference/source/openssl-0.9.7-beta3/apps/CA.pl. Eine Dokumentation zur Benutzung von CA.pl findet man unter http://www.openssl.org/docs/apps/CA.pl.html.
Die Angaben, die man jetzt machen muss sollten sorgfältig überlegt sein, da man jetzt die Schlüssel der alles zertifizierenden Instanz erzeugt. Will man z.B. mit dieser CA auch alle weiteren Schlüssel der Firma (Email-Schlüssel, Webserver-Zertifikate) signieren, dann sollte man als Namen gleich den Name der Firma mit allen Angaben wählen.
Damit alle Benutzer weltweit den Mailserver-Schlüssel (den wir im nächsten Schritt erstellen) auch überprüfen können müssen wir den öffentlichen Schlüssel der CA auch veröffentlichen, damit die Benutzer ihn z.B. auch in Ihren Webbrowser integrieren können. Die Zertifikate der bekannten Firma sind ja auch schon im Browser enthalten (siehe Edit®Preferences®Privicy & Security ®Certificates®Manage Certificates®Authorities), jetzt fehlt nur noch unser eigener CA-Schlüssel. Das kann man entweder von Hand in dem oben genannten Dialog (®Import) machen oder automatisch über ein Perl-CGI-Script, welches man im Webserver integriert und das den Pfad zu unserem CA-Schlüssel kennt:
    #!/usr/local/bin/perl -T

    require 5.003;
    use strict;
    use CGI;

    # hier müssen der Pfad und der Name des CA-Zertifikates
    # angegeben werden - könnte bei Ihnen abweichen
    my $cert_dir = "/usr/local/ssl/certs";
    my $cert_file = "CAcert.pem";

    my $query = new CGI;

    my $kind = $query->param('FORMAT');
    if($kind eq 'DER') { $cert_file = "CAcert.der"; }

    my $cert_path = "$cert_dir/$cert_file";

    open(CERT, "<$cert_path");
    my $data = join '', <CERT>;
    close(CERT);
    print "Content-Type: application/x-x509-ca-cert\n";
    print "Content-Length: ", length($data), "\n\n$data";

    1;

Nun reicht es aus im Browser einfach das Script aufzurufen und das CA-Zertifikat wird automatisch in den Browser eingebunden.
Hat man das Zertifikat nicht über den Browser (egal ob Explorer oder Mozilla/Firefox) in die Zertifikat-Datenbank geladen und installiert, dann wird weiterhin jedes Programm das dieses CA-Zertifikat dort in der Datenbank sucht meckern, dass es den Aussteller der Server-Zertifikate nicht finden kann. Das ist nicht schlimm, nervt aber, da man dabei immer Bestätigungsbuttons drücken muß.

9.1.2  Server-Zertifikate erstellen

Normalerweise läuft das Erstellen eines Zertifikates in zwei von einander getrennten Schritten ab:
Daher ist das Erstellen der Server-Zertifikate ist ein bisschen komplizierter, denn wir müssen folgendes beachten: ein normal erstelltes Schlüsselpaar ist noch einmal durch ein Passwort geschützt, damit nicht jeder der es besitzt (gestohlen hat) sofort an die Schlüsselpaare herankommt. Man muss also vorher ein Passwort eingeben um sie zu benutzten. Das bedeutet in unserem Fall, immer wenn der Rechner - und damit auch Postfix mit TLS/SSL-Unterstützung - startet, wird er an einer bestimmten Stelle anhalten und nach dem Passwort für die Server-Schlüssel fragen. Wenn wir das nicht wollen und ein Schlüsselpaar ohne Passwort erstellen wollen, müssen wir folgende Patch vor der Erstellung der Server-Zertifikate in die Datei CA.pl einspielen. Dazu sollten wir zuerst eine Kopie der Datei (z.B. CA_neu.pl erstellen und diese dann an der Stelle:
        exit 0;
    } elsif (/^-newcert$/) {
        # create a certificate
        system ("$REQ -new -x509 -keyout newreq.pem -out newreq.pem $DAYS");
        $RET=$?;
        print "Certificate (and private key) is in newreq.pem\n"
    } elsif (/^-newreq$/) {
        # create a certificate request
        system ("$REQ -new -keyout newreq.pem -out newreq.pem $DAYS");
        $RET=$?;
        print "Request (and private key) is in newreq.pem\n";
    } elsif (/^-newca$/) {

durch folgenden Code ersetzen (patchen):
        exit 0;
    } elsif (/^-newcert$/) {
        # create a certificate
        system ("$REQ -new -x509 -nodes -keyout newreq.pem -out newreq.pem $DAYS");
        $RET=$?;
        print "Certificate (and private key) is in newreq.pem\n"
    } elsif (/^-newreq$/) {
        # create a certificate request
        system ("$REQ -new -nodes -keyout newreq.pem -out newreq.pem $DAYS");
        $RET=$?;
        print "Request (and private key) is in newreq.pem\n";
    } elsif (/^-newca$/) {

Mit dieser neuen CA_neu.pl erstellen wir nun die Server-Zertifikate. Nun müssen wir natürlich bei den Angaben auch den Namen des Server angeben (z.B. mail.mydomain.com):
    # CA_neu.pl -newreq

und unterschreiben die neue erstellten Schlüssel mit:
    # CA_new.pl -sign

9.1.3  Letzte Schritte

Nun müssen wir die Schlüssel in die richtigen Verzeichnisse kopieren:
  1. Der öffentliche Schlüssel der CA cacert.pem geht nach /etc/postfix/cacert.pem.
  2. Das der öffentliche Schlüssel des Servers newcert.pem (auch Server-Zertifikat genannt) geht nach /etc/postfix/cert.pem.
  3. Der private Schlüssel des Server newreq.pem (auch Request genannt) geht nach /etc/postfix/priv_key.pem.
Jetzt müssen wir noch die richtigen Rechte setzen. Die beiden cert-Dateien sind öffentlich, daher:
    # chmod 644 cacert.pem
    # chmod 644 cert.pem

Der Server-Key ist privat daher:
    # chmod 600 priv_key.pem

9.2  Konfiguration von TLS/SSL

TLS/SSL ist bereits in SASL2 integriert und damit von uns schon installiert. Jetzt muss es nur noch aktiviert werden. Dazu editieren wir als erstes /etc/postfix/master.cf und aktivieren 3 Zeilen, die bis jetzt deaktiviert waren:
    smtps       inet    n   -   n   -   -   smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes
    submission  inet    n   -   n   -   -   smtpd -o smtpd_enforce_tls=yes -o smtpd_sasl_auth_enable=yes
    tlsmgr      fifo    -   -   n   300 1   tlsmgr

Damit haben wir jetzt "SMTP over SSL" auf Port 465 und "SMTP over TLS" auf Port 25 zur Verfügung. Je nachdem welche Varianten die Mail-Clients verfügen kann man dann über die eine oder andere Weise seine Mails verschicken.
In der /etc/postfix/main.cf müssen wir dann noch die Konfigurationsanweisungen für die Benutzung von TLS/SSL setzen:
    smtpd_tls_loglevel = 1

    smtp_tls_note_starttls_offer = yes
    smtpd_tls_received_header = yes

    # TLS (server side)
    smtpd_tls_key_file = /etc/certificates/SMTPpriv_key.pem
    smtpd_tls_cert_file = /etc/certificates/SMTPcert.pem
    smtpd_tls_CAfile = /etc/certificates/cacert.pem
    smtpd_use_tls = yes

    # TLS (client side)
    smtp_tls_key_file = /etc/certificates/SMTPpriv_key.pem
    smtp_tls_cert_file = /etc/certificates/SMTPcert.pem
    smtp_tls_CAfile = /etc/certificates/cacert.pem
    smtp_use_tls = yes

    # nur für ältere Outlook[Express]-Clients, die Port 465 benutzen
    # dann aber auch die entsprechende Zeile in der master.cf
    # aktivieren!!!
    #smtpd_tls_wrappermode = no

    smtpd_tls_session_cache_database = sdbm:/etc/postfix/smtpd_scache

    # SASL related variables for TLS
    smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
    smtpd_tls_auth_only = no

Nun müssen wir natürlich Postfix auch noch einmal neu starten und fertig:
    # service postfix reload

9.3  Nochmal alles Testen

Um zu sehen, ob auch TLS/SSL funktioniert machen wir wieder ein telnet auf den Mailserver:
    # telnet localhost 25
    Trying 127.0.0.1...
    Connected to localhost.
    Escape character is '^]'.
    220 mail.test.de ESMTP Postfix

    EHLO test.com

    250-mail.test.de
    250-PIPELINING
    250-SIZE 10240000
    250-VRFY
    250-ETRN
    250-STARTTLS
    250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
    250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5
    250-XVERP
    250 8BITMIME

    quit

    221 Bye
    Connection closed by foreign host.

Solltest Du auch folgende Zeilen sehen:
    250-STARTTLS
    250-AUTH PLAIN LOGIN DIGEST-MD5 CRAM-MD5
    250-AUTH=PLAIN LOGIN DIGEST-MD5 CRAM-MD5

Ist alles in Ordnung und Du kannst das ganze jetzt mit einer Email ausprobieren. Dazu stellen wir zur Probe z.B. im Mozilla unter Edit®Mail & Newsgroup Account Settings®Outgoing Server(SMTP) zusätzlich 'Use secure connection (SSL) - When available' ein. Nun sollte die Kommunikation und die Email-Übertragung immer verschlüsselt erfolgen. Wenn man sehen will, was genau passiert, kann man in der Datei /var/log/maillog die Log-Ausgaben lesen.
Eine vollkommen verschlüsselte Kommunikation sieht dann wie folgt aus. Man erkennt schon wie die Mail vom Mailserver angenommen wird, wie die Zertifikate und Schlüssel ausgetauscht werden, wie die Mail weiter an Amavis gesendet wird, wie Amavis seinen Filter drüberlaufen lässt.
connect from mail.test.de[192.168.100.41]
setting up TLS connection from mail.test.de[192.168.100.41]
SSL_accept:before/accept initialization
SSL_accept:error in SSLv2/v3 read client hello A
SSL_accept:error in SSLv3 read client hello B
SSL_accept:error in SSLv3 read client hello B
SSL_accept:SSLv3 read client hello B
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:error in SSLv3 read client certificate A
SSL_accept:error in SSLv3 read client certificate A
SSL_accept:SSLv3 read client key exchange A
SSL_accept:error in SSLv3 read certificate verify A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data
TLS connection established from mail.test.de[192.168.100.41]: TLSv1 with cipher
        DHE-RSA-AES256-SHA (256/256 bits)
DA81373AA3: client=mail.test.de[192.168.100.41], sasl_method=CRAM-MD5, sasl_username=tux@mail
DA81373AA3: message-id=<4006BB0E.6010505@test.de>
DA81373AA3: from=<heinz@test.de>, size=600, nrcpt=1 (queue active)
disconnect from mail.test.de[192.168.100.41]
(04135-01) ESMTP::10024 /var/amavis/amavis-20040115T170919-04135: <heinz@test.de> -> <root@test.de>
Received: SIZE=600 from mail.test.de ([127.0.0.1]) by localhost (mail[127.0.0.1])
(amavisd-new, port 10024) with ESMTP id 04135-01 for <root@test.de>; Thu, 15 Jan 2004 17:09:19 +0100(CET)
(04135-01) Checking: <heinz@test.de> -> <root@test.de>
(04135-01) spam_scan: hits=0 tests=
(04135-01) FWD via SMTP: [127.0.0.1:10025] <heinz@test.de> -> <root@test.de>
starting TLS engine
connect from unknown[127.0.0.1]
connect from mail.test.de[192.168.100.41]
setting up TLS connection from mail.test.de[192.168.100.41]
SSL_accept:before/accept initialization
SSL_accept:error in SSLv2/v3 read client hello A
SSL_accept:error in SSLv3 read client hello B
SSL_accept:error in SSLv3 read client hello B
SSL_accept:SSLv3 read client hello B
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:error in SSLv3 read client certificate A
SSL_accept:error in SSLv3 read client certificate A
SSL_accept:SSLv3 read client key exchange A
SSL_accept:error in SSLv3 read certificate verify A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data
TLS connection established from mail.test.de[192.168.100.41]: TLSv1 with cipher
        DHE-RSA-AES256-SHA (256/256 bits)
DA81373AA3: client=mail.test.de[192.168.100.41], sasl_method=CRAM-MD5, sasl_username=test@mail
DA81373AA3: message-id=<4006BB0E.6010505@test.de>
DA81373AA3: from=<heinz@test.de>, size=600, nrcpt=1 (queue active)
disconnect from mail.test.de[192.168.100.41]
Jan 15 17:09:19 mail amavis[4135]: (04135-01) ESMTP::10024 /var/amavis/amavis-20040115T170919-04135:
        <heinz@test.de> -> <root@test.de> Received: SIZE=600 from mail.test.de ([127.0.0.1]) by
        localhost (mail[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04135-01 for <root@test.de>;
        Thu, 15 Jan 2004 17:09:19 +0100 (CET)
(04135-01) Checking: <heinz@test.de> -> <root@test.de>
(04135-01) spam_scan: hits=0 tests=
(04135-01) FWD via SMTP: [127.0.0.1:10025] <heinz@test.de> -> <root@test.de>
starting TLS engine
connect from unknown[127.0.0.1]
AC61874105: client=unknown[127.0.0.1]
AC61874105: message-id=<4006BB0E.6010505@test.de>
AC61874105: from=<heinz@test.de>, size=1020, nrcpt=1 (queue active)
(04135-01) Passed, <heinz@test.de> -> <root@test.de>, Message-ID: <4006BB0E.6010505@test.de>, Hits: 0
(04135-01) TIMING [total 4667 ms] - SMTP EHLO: 3 (0%), SMTP pre-MAIL: 0 (0%), mkdir tempdir: 0 (0%),
        create email.txt: 0 (0%), SMTP pre-DATA-flush: 3 (0%), SMTP DATA: 32 (1%), body hash: 1 (0%),
        mkdir parts: 22 (0%), mime_decode: 23 (0%), get-file-type: 147 (3%), decompose_part: 10 (0%),
        parts: 0 (0%), AV-scan-1: 28 (1%), SA msg read: 1 (0%), SA parse: 1 (0%), SA check: 4317 (92%),
        fwd-connect: 34 (1%), fwd-mail-from: 1 (0%), fwd-rcpt-to: 1 (0%), write-header: 5 (0%),
        fwd-data: 0 (0%), fwd-data-end: 32 (1%), fwd-rundown: 1 (0%), unlink-1-files: 3 (0%), rundown: 2 (0%)
DA81373AA3: to=<root@test.de>, relay=127.0.0.1[127.0.0.1], delay=5, status=sent (250 2.6.0 Ok,
        id=04135-01, from MTA: 250 Ok: queued as AC61874105)
disconnect from unknown[127.0.0.1]
AC61874105: to=<root@test.de>, relay=local, delay=0, status=sent (mailbox)

10  Zu Diensten sein

10.1  Installation von POP3, POP3S, IMAP und IMAPS

Standardmäßig ist der Dienst POP3 für die Benutzung installiert. Da alle vier Dienste von einem Programm (uw-IMAP) bereitgestellt werden, müssen wir die anderen, nicht aktiven Dienste nun auch noch aktivieren. Das passiert mit dem Programm 'Setup' auf der Kommandozeile und dort über den Menüpunkt Dienste. Einfach nur ein Kreuz bei iPOP3s, IMAP und IMAPS setzen und fertig.
Wenn uw-IMAP noch nicht installiert ist oder die Dienste in 'Setup' noch nicht existieren, dann müssen wir noch von den CD's nachinstallieren.

10.2  Konfiguration von POP3, POP3S, IMAP und IMAPS

Nun, da die Dienste aktiviert sind, müssen für die entsprechenden verschlüsselten Versionen noch die Zertifikate angepasst werden. Wir benutzen als Zertifikate die gleichen, die wir in Kapitel 9.1.1 erstellt und für die Sicherung des SMTP-Verkehrs durch TLS/SSL verwendet haben. Allerdings benötigt uw-IMAP anscheinend den Key und das Zertifikat in einer Datei. Daher gehen wir in das Verzeichnis /etc/postfix wo unsere Zertifikate liegen und machen dort:
    # cat priv_key.pem cert.pem > cert+key.pem

    # cd /usr/share/ssl/certs/

    # ln -s /etc/postfix/cert+key.pem imapd.pem
    # ln -s /etc/postfix/cert+key.pem ipop3d.pem

Damit haben wir Key und Zertifikat in eine Datei geschrieben, sind in das Verzeichnis gewechselt, von wo uw-IMAP die PEM-Dateien erwartet und haben zwei Links auf unsere gerade erstellte PEM-Datei gesetzt.
Jetzt sollte beim Abfragen mit einem Mailprogramm (wenn Verschlüsselung für POP oder IMAP eingestellt wurde) auch das richtige Zertifikat angezeigt werden.

10.3  Noch sicherer mit IMAP und CRAM-MD5

Bei manchen (modernen) Mail-Clients gibt es die Möglichkeit sich noch sicherer und zwar mit "Secure authentication" auf einem IMAP-Server einzuloggen. Dazu wird eine spezielle Authentifizierungsmethode mit CRAM-MD5 angewendet, so wird vermieden, dass Klartextpasswörter über das Netz übertragen und somit abgehört werden können.
In unserem uw-IMAP-Server ist diese Möglichkeit schon eincompiliert. Wir müssen sie nur noch aktivieren, indem wir für alle User, die diese spezielle Methode des Login benutzen wollen, eine Datei /etc/cram-md5.pwd anlegen und in ihr den User und ein Passwort ablegen. Aber Achtung: die User müssen in der Datei /etc/passwd existieren, sollten aber ein anderes Passwort für den CRAM-MD5-Login benutzen. Die Rechte der Datei müssen mit chmod auf 600 gesetzt werden, da die Passwörter dort im Klartext abgelegt werden.
Bei mir sieht diese Datei folgendermaßen aus:
    # CRAM-MD5 authentication database
    # Entries are in form: user<one tab>password
    # Lines starting with "#" are comments

    heinz   heinz
    meier   killer

Nachdem diese Datei angelegt wurde nimmt uw-IMAP nicht mehr automatisch die Daten aus der /etc/passwd sondern nun aus der /etc/cram-md5.pwd (nur wenn der User dort vorhanden ist, ansonsten wird auch weiterhin die /etc/passwd verwendet).

11  Reinlassen

Squirrelmail ist ein Webmailer, ähnlich WebAccess von Microsoft für seinen MS Exchange Server. Man kann so seine Mail-Accounts einfach und überall verfügbar über das Internet, nur mit Hilfe eines Browsers, erreichen.
Squirrelmail lässt sich auf einfache Weise um die verschiedensten Funktionen (Kalender-, Adressbuch-, Filesharing-Funktion) erweitern.

11.1  Installation und Konfiguration von Squirrelmail

Wenn Squirrelmail noch nicht auf dem Rechner installiert ist, kann man mit RPM auch dieses Paket von den CD's nachinstallieren.
Für Änderungen und Anpassungen bearbeitet man die Datei /etc/squirrelmail/config.php. Für Änderungen am Webserver kann man die Datei /etc/httpd/conf.d/squirrelmail.conf anpassen. In Ihr steht auch wie der Webmailer vom Browser aus aufgerufen wird.
Wenn man denn dann schon in diesem Verzeichnis ist, kann man auch gleich die Pfade für die Web-Server-Zertifikate in /etc/httpd/conf.d/ssl.conf anpassen. Dazu passt man in dieser Datei folgende Zeilen an:
    SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt
    SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key

Damit sie dann nachher folgendermaßen aussehen und somit auf unser schon in Kapitel 9.1.2 erstelltes Zertifikat verweisen:
    SSLCertificateFile /etc/postfix/cert.pem
    SSLCertificateKeyFile /etc/postfix/priv_key.pem

11.2  Hinzufügen von Plugins

Das Hinzufügen von Plugin ist sehr einfach. Im Prinzip sind folgende Schritte dazu auszuführen:
  1. Wechsel in das Verzeichnis Plugins:
                # cd plugins/
            
    
  2. Entpacke das Plugin in das Verzeichnis mit:
                # tar -xzf /your/path/to/plugin-x.x.tgz
            
    
  3. Gehe ins Verzeichnis config und starte das Konfigurationsprogramm mit:
                # cd ../../config/
                # ./conf.pl
            
    
  4. Wähle nun Option 8 und füge das Plugin hinzu.
  5. Speichern und fertig.

A  Aussperren

A.1  Hinweise für die Sicherung mit einer Firewall

Bei der Sicherung des Mailserver sollte man schon die ganzen neu hinzugekommenen offenen Ports beachten und überprüfen, ob sie nur für interne Zugriffe oder auch für externe Zugriffe notwendig sind.
Zur Übersicht hier eine Auflistung aller benutzten Port und ihre Zuordnung zu Programmen oder Protokollen:
    Proto Recv-Q Send-Q Local Address        Foreign Address          State
    tcp     0      0    *:imaps                  *:*                  LISTEN
    tcp     0      0    *:pop3                   *:*                  LISTEN
    tcp     0      0    *:pop3s                  *:*                  LISTEN
    tcp     0      0    *:imap                   *:*                  LISTEN
    tcp     0      0    mail:10024 (amavis-new)  *:*                  LISTEN
    tcp     0      0    mail:10025 (amavis-new)  *:*                  LISTEN
    tcp     0      0    *:submission (postfix)   *:*                  LISTEN
    tcp     0      0    mail:783 (SpamAssassin)  *:*                  LISTEN
    tcp     0      0    *:ssh                    *:*                  LISTEN
    tcp     0      0    *:smtp                   *:*                  LISTEN
    tcp     0      0    *:smtps                  *:*                  LISTEN
    tcp     0      0    *:http                   *:*                  LISTEN
    tcp     0      0    *:https                  *:*                  LISTEN
    tcp     0      0    mail:8127(OpenAntivirus) *:*                  LISTEN

B  Zwei auf einen Streich - Mail-Logging

Ein Mailserver unter Linux ist zwar was Tolles und Mächtiges, was es jederzeit mit Exchange aufnehmen kann, allerdings, ganz im Gegensatz zum MS Produkt, sieht man davon leider wenig. Kein Klicki-Bunti, nicht was sich bewegt oder blinkt. Man selber als Admin kann zwar in die Logs schauen, was eigentlich ausreicht, aber anderen nicht sagt. Daher ist es ganz nützlich, wenn man dem Kunden was Graphisches und Aussagekräftiges zeigen kann. Damit er weiß wofür er bezahlt hat.
Dabei helfen uns die beiden Tools:
Mailgraph findet man unter http://people.ee.ethz.ch/~dws/software/mailgraph/, Pflogsumm auf der Webseite von Jim Seymour http://jimsun.linxnet.com/postfix_contrib.html und eine deutsche Version davon auf den Seiten von Patrick Koetter unter http://postfix.state-of-mind.de/patrick.koetter/pflogsumm/. Beide Programme sind gut dokumentiert und lassen sich einfach installieren. Dabei bitte an die mitgelieferten Dokus halten.
Mailgraph kommt mit einem Start-Skript für /etc/rc.d/init.d/, was zumindest bei Redhat basierten Systemen einwandfrei funktioniert, und zwei Dateien: mailgraph.cgi und mailgraph.pl.
mailgraph.cgi wird nach /var/www/cgi-bin/ kopiert und mailgraph.pl nach /usr/local/bin/.
Pflogsumm kopiert man ebenfalls einfach nach /usr/local/bin/.
Ich habe beide Programme in einem Skript zusammengefasst. Das war für mich übersichtlicher. Und so geht es:
Die Datei mailgraph.cgi editieren und folgenden Code hinzufügen:
In der Funktion "sub print_html()" vor der Stelle "print <<FOOTER;"
einfach "&print_pflogsumm('en');" einfügen.

An das Ende des Skriptes einfach folgende Funktion anhängen:

sub print_pflogsumm
{
    my $lang = shift;
    my $pflog = '/usr/local/bin/pflogsumm';
    my $cat = '/bin/cat';
    my $maillog = '/var/log/maillog*';
    my $prog = $pflog."_".$lang;

    $output = `$cat $maillog | $prog -d today`;

    print "<br><br><br><hr><H1><a name='teil2'>More Mail Statistics for $host</a></H1>\n";
    print "<PRE>$output</PRE>\n";
}

Nun ist es noch so, dass Mailgraph zwar Bounces (schwarz), Rejects (rot), Viren (gelb) und Spam (grau) korrekt und schön unterschiedlich farbig darstellt, bei Spam allerdings nur den ganz schlimmen Spam, der per Amavis-new im Quarantäne-Verzeichnis landet, ohne das der Empfänger ihn je zu sehen bekommt; bei mir Spam mit mehr als 20 Spam-Punkten. Wenn man sich jeden erkannten und markierten Spam, bei mir mehr als 5 Spam-Punkte, anzeigen lassen will, dann muss man folgende Zeile in der Datei mailgraph.pl hinzufügen:
In der Funktion "sub process_line($)" unter der Zeile:

    elsif($text =~ /^\([0-9-]+\) (Passed|Not-Delivered)\b.*\bquarantine spam/) {
        event($time, 'spam'); # amavisd-new-20030616 and earlier
    }

folgende Zeile hinzufügen:

    elsif($text =~ /^\([0-9-]+\) SPAM-TAG\b.*\bYes/) {
        event($time, 'spam'); # um allen erkannten Spam zu sehen
    }

Nun kann man sich an der Ausgabe von Mailgraph und Pflogsumm erfreuen und hat gegebenenfalls ein gutes Argument im Ärmel, wenn man mit dem Chef um das nächste Update für den veralteten Virenscanner kämpfen muss (siehe die vielen gelben Balken in den Grafiken).

C  Ein FTP Server mit VSFTPD

Angenommen wird eine Installation, bei der alle lokalen User, d.h. alle, die einen Account auf dem Rechner besitzen, Lese- und Schreibzugriff in einer chroot-Umgebung auf Ihr Homeverzeichnis haben; anonymer FTP-Zugriff wird verboten.
Installiert werden muss dazu das entsprechende RPM-Paket, wenn es nicht schon bei der Installation mitinstalliert wurde. Ebenfalls muss das Programm 'setup' auf der Konsole gestartet werden und in 'Dienste' aktivieren wir 'vsftpd'. Nun müssen wir den Dienst beim ersten Mal noch von Hand starten, bzw. nach einem Systemneustart würde dieser Service dann auch selbstständig starten: /etc/rc.d/init.d/vsftpd.
Folgende Einstellung sind in der /etc/vsftpd/vsftpd.conf zu machen:
    anonymous_enable=NO
    local_enable=YES
    write_enable=YES
    local_umask=002

    #anon_upload_enable=YES
    #anon_mkdir_write_enable=YES

    dirmessage_enable=YES
    connect_from_port_20=YES

    #chown_uploads=YES
    #chown_username=whoever

    #xferlog_file=/var/log/vsftpd.log
    xferlog_enable=YES
    xferlog_std_format=YES
    log_ftp_protocol=YES

    #idle_session_timeout=600
    #data_connection_timeout=120

    #nopriv_user=ftpsecure

    #async_abor_enable=YES
    #ascii_upload_enable=YES
    #ascii_download_enable=YES

    ftpd_banner=Willkommen zum FTP Service auf Test.de

    #deny_email_enable=YES
    #banned_email_file=/etc/vsftpd.banned_emails

    chroot_local_user=YES
    #chroot_list_enable=YES
    #chroot_list_file=/etc/vsftpd.chroot_list

    #ls_recurse_enable=YES
    pam_service_name=vsftpd
    userlist_enable=YES
    #enable for standalone mode
    listen=YES
    tcp_wrappers=YES

D  Zeitsynchronisation mit NTP

Benötigt wird dazu das Paket ntp. Wenn es noch nicht installiert sein sollte, dann bitte mit rpm -U <Paketname> nachinstallieren.
Bitte die Datei /etc/ntp.conf editieren und folgende Angaben machen:
    # generell Zugriff verbieten
    restrict default ignore

    # Zugriff von folgenden internen Netzwerken zulassen
    restrict 192.168.100.0 mask 255.255.255.0 notrust nomodify notrap
    restrict 192.168.200.0 mask 255.255.255.0 notrust nomodify notrap

    # externe Server für den Zeitabgleich definieren
    server 129.132.2.21
    server 192.93.2.20
    server 130.149.17.21
    server 130.149.17.8
    restrict 129.132.2.21 mask 255.255.255.255 nomodify notrap noquery
    restrict 192.93.2.20 mask 255.255.255.255 nomodify notrap noquery
    restrict 130.149.17.21 mask 255.255.255.255 nomodify notrap noquery
    restrict 130.149.17.8 mask 255.255.255.255 nomodify notrap noquery

    # drift-File setzen
    driftfile /var/lib/ntp/drift
    broadcastdelay  0.008

Dann mit setup auf der Kommandozeile den NTPD als Service aktivieren und danach mit /etc/rc.d/init.d/ntpd start starten.
Ab jetzt sollte der NTPD auf diesem System laufen, regelmäßig Verbindung zu anderen Time-Servern aufnehmen und nötigenfalls die Systemuhr in kleinen und unauffälligen Schritten anpassen.
Will man die Systemuhr brutal und sofort auf die richtige Zeit einstellen (Achtung: das macht das Probleme beim Servermanagement.) kann man den Befehl ntpdate <NTP-Servername> dazu benutzen.
Um zu überprüfen, ob NTP auch richtig läuft kann man sich mit ntpq -p eine kleine Statistik dazu anzeigen lassen.

E  Nachlesen

Alle Anregungen dazu wurden im Internet gefunden. Die genutzten Seiten werden hier - mit Besten Dank an die Autoren - , noch einmal nach Themen geordnet, aufgelistet:

E.1  Antivirus

E.2  Amavis / Scanner

E.3  Postfix

E.4  TLS/SSL

E.5  SMTP-AUTH

E.6  SpamAssassin

E.7  Sonstige

References

[1]
Ralf Spenneberg. Implementing a SPAM and virus scanning mail server using RedHat Linux 8.0 and amavis-new. December 2003.
[2]
Kyle D. Dent. Postfix: The Definitive Guide. O'Reilly, 1th edition, 2003.
[3]
Peer Heinlein. Das Postfixbuch. Open Source Press, 2nd edition, 2004.
[4]
Lutz Jänicke. Postfix/TLS - A TLS extension for POSTFIX. http://www.aet.tu-cottbus.de/personen/jaenicke/pfixtls/doc/index.html.

Footnotes:

1Die Bezeichnung SPAM stammt von einem Sketch aus Monty Python's Flying Circus, der vom britischen Dosenfleisch gleichen Namens handelt.
2Ich weiss nicht, warum immer über Server-'Zertifikate' gesprochen wird, dabei ist es ebenso ein Schlüsselpaar aus öffentlichen und privaten Schlüsseln, wobei der öffentliche Schlüssel unterschrieben (zertifiziert) ist, wie z.B. bei GnuPG oder PGP. Es hört sich wahrscheinlich einfach nur besser an: Zertifikat. :-)
3Wenn das nicht funktioniert, ist OpenSSL wohl nicht vollständig installiert oder die Pfade stimmen nicht.


File translated from TEX by TTH, version 3.80.
On 03 Feb 2009, 19:50.