Zunächst werden wieder einmal ein paar paketspezifische USE-Flags gesetzt.

# cat>>/etc/portage/package.use<<EOF
mail-mta/postfix dovecot-sasl
mail-filter/dspam virtual-users
net-mail/dovecot managesieve sieve suid
EOF

Zusammengefasst sorgen diese dafür, dass Postfix sich gegen die Datenbasis von Dovecot authentifizieren kann, dass dspam mit virtuellen Benutzern funktioniert und Dovecot mit Sieve-Unterstützung kompiliert wird. Letzteres ist heutzutage unheimlich wichtig. Entsprechende Frontends gibt es z. B. mit SmartSieve, KMail oder einem Addon für Mozilla Thunderbird.

Anschließend muss noch ein Sicherheitsfeature von Portage konfiguriert werden - allerdings nur, wenn in der /etc/make.conf das Feature suidctl eingetragen wurde.

# cat>/etc/portage/suidctl.conf<<EOF
/usr/libexec/dovecot/deliver
/usr/bin/dspam
/usr/bin/dspamc
EOF

Danach kann die benötigte Software endlich installiert werden:

# emerge postfix dovecot dspam policyd-weight postgrey

Nachdem alle Programme installiert wurden, können über den Dovecot-Ebuild später benötigte SSL-Parameter erstellt werden.

# emerge --config dovecot

Das spätere Mailsystem wird mit virtuellen Benutzern und virtuellen Domains arbeiten. Das hat den Vorteil, dass nicht für jeden E-Mail-Benutzer ein eigener Systembenutzer angelegt werden muss. Stattdessen werden die entsprechenden Dateien dem Benutzer vmail ("Virtual Mail") zugeordnet. Dieser wird mit folgenden Kommandos erstellt und anschließend das Mailspool-Verzeichnis zugeordnet.

# useradd -d /var/spool/mail/ -s /sbin/nologin -U vmail
# chown vmail /var/spool/mail

Aus Sicherheitsgründen wird der MDA von Dovecot nur für den Benuzter root und die Gruppe mail ausführbar sein. Das ist notwendig, da für das Programm das SUID-Bit gesetzt wird, damit eine Zustellung unter einer anderen Benutzerkennung möglich wird.

# chgrp mail /usr/libexec/dovecot/deliver
# chmod 04750 /usr/libexec/dovecot/deliver

Nun kann das SSL-Zertifikat sowie der Private Key für Dovecot angelegt werden. Bei der Abfrage der Parameter sollten möglichst sinnvolle Werte vergeben werden und bei der Eigenschaft Common Name muss unbedingt der Domainname angegeben werden, unter dem der IMAP-Server später erreichbar ist (z. B. example.com oder mail.example.com).

# cd /etc/ssl/dovecot
# openssl genrsa -aes256 -out server.key.passwd 2048
# openssl rsa -in server.key.passwd -out server.key
# rm server.key.passwd
# openssl req -new -key server.key -out server.csr
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
# cat server.key server.crt>server.pem
# chmod 400 *
# chown dovecot *

Die Konfiguration von Dovecot selbst ist recht übersichtlich. Es werden nur die unbedingt notwendigen Einstellungen geändert, ansonsten werden die Defaultwerte übernommen.

# cat>dovecot.conf<<EOF
protocols = imap imaps managesieve
ssl_cert_file = /etc/ssl/dovecot/server.pem
ssl_key_file = /etc/ssl/dovecot/server.key
mail_location = maildir:/var/spool/mail/%d/%n/Maildir
mail_uid = vmail
mail_gid = vmail

protocol managesieve {
  sieve = /var/spool/mail/%d/%n/sieve
  sieve_storage = /var/spool/mail/%d/%n/sieve-scripts
}

protocol lda {
  # Hier unbedingt die richtige, gültige Postmaster-Adresse eintragen!
  postmaster_address = postmaster@example.com
  sendmail_path = /usr/sbin/sendmail
  mail_plugins = cmusieve
}

auth default {
  mechanisms = plain login cram-md5

  passdb passwd-file {
    args = /etc/dovecot/passwd
  }

  userdb static {
    args = uid=vmail gid=vmail home=/var/spool/mail/%d/%n
  }

  socket listen {
    master {
      # Master socket provides access to userdb information. It's typically
      # used to give Dovecot's local delivery agent access to userdb so it
      # can find mailbox locations.
      #path = /var/run/dovecot/auth-master
      #mode = 0600
      # Default user/group is the one who started dovecot-auth (root)
      user = mail
      #group =
    }
    client {
      path = /var/spool/postfix/private/auth
      mode = 0660
      user = postfix
      group = postfix
    }
  }
}

plugin {
  sieve = /var/spool/mail/%d/%n/sieve
}
EOF

Nachdem die Konfiguration gespeichert wurde, sollte der Aufruf von `dovecot -n` folgende Ausgabe produzieren:

# 1.1.11: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.18-92.1.18.el5.028stab060.2 i686 Gentoo Base System release 2.0.0 simfs
protocols: imap imaps managesieve
ssl_cert_file: /etc/ssl/dovecot/server.pem
ssl_key_file: /etc/ssl/dovecot/server.key
login_dir: /var/run/dovecot/login
login_executable(default): /usr/libexec/dovecot/imap-login
login_executable(imap): /usr/libexec/dovecot/imap-login
login_executable(managesieve): /usr/libexec/dovecot/managesieve-login
mail_uid: vmail
mail_gid: vmail
mail_location: maildir:/var/spool/mail/%d/%n/Maildir
mail_executable(default): /usr/libexec/dovecot/imap
mail_executable(imap): /usr/libexec/dovecot/imap
mail_executable(managesieve): /usr/libexec/dovecot/managesieve
mail_plugin_dir(default): /usr/lib/dovecot/imap
mail_plugin_dir(imap): /usr/lib/dovecot/imap
mail_plugin_dir(managesieve): /usr/lib/dovecot/managesieve
sieve_storage(default):
sieve_storage(imap):
sieve_storage(managesieve): /var/spool/mail/%d/%n/sieve-scripts
sieve(default):
sieve(imap):
sieve(managesieve): /var/spool/mail/%d/%n/sieve
auth default:
  mechanisms: plain login cram-md5
  passdb:
    driver: passwd-file
    args: /etc/dovecot/passwd
  userdb:
    driver: static
    args: uid=vmail gid=vmail home=/var/spool/mail/%d/%n
  socket:
    type: listen
    client:
      path: /var/spool/postfix/private/auth
      mode: 432
      user: postfix
      group: postfix
    master:
      path: /var/run/dovecot/auth-master
      mode: 384
      user: mail
plugin:
  sieve: /var/spool/mail/%d/%n/sieve

Um neue Benutzer anzulegen, muss die Datei /etc/dovecot/passwd editiert werden. Das Format ist dabei localpart@example.com:Passwort.
Das Passwort kann durch das Programm `dovecotpw` generiert werden. Auf meinem System werden dabei folgende Verfahren unterstützt:

# dovecotpw -l
CRYPT MD5 MD5-CRYPT SHA SHA1 SHA256 SMD5 SSHA PLAIN CLEARTEXT CRAM-MD5 HMAC-MD5 DIGEST-MD5 PLAIN-MD4 PLAIN-MD5 LDAP-MD5 LANMAN NTLM OTP SKEY RPA

Es könnten im Prinzip auch Klartextpasswörter in der Datei stehen, aus offensichtlichen Gründen ist davon jedoch abzuraten. Zu empfehlen ist ein mit CRAM-MD5 gehashtes Passwort.

Das Passwort kann folgendermaßen generiert werden:

# dovecotpw -s CRAM-MD5

Die Ausgabe von `dovecotpw` muss dann in /etc/dovecot/passwd eingetragen werden.

Die Datei kann z. B. folgendermaßen aussehen:

# cat /etc/dovecot/passwd
alice@example.com:{CRAM-MD5}9186d855e11eba527a7a52ca82b313e180d62234f0acc9051b527243d41e2740
bob@example.org:{CRAM-MD5}e02d374fde0dc75a17a557039a3a5338c7743304777dccd376f332bee68d2cf6

Dovecot ist nun fertig konfiguriert und kann gestartet und in den entsprechenden Runlevel eingetragen werden.

# /etc/init.d/dovecot start
# rc-update add dovecot

Sollte irgendetwas schiefgelaufen sein, sind die ausführlichen Fehlermeldungen in den Logs unter /var/log/mail.* zu finden.

Als nächstes steht der MTA Postfix auf der Liste. Ähnlich wie bei der dovecot.conf werden in der /etc/postfix/main.cf nur die nötigsten Einstellungen gespeichert. Alle übrigen Werte werden aus der Defaultkonfiguration übernommen.

Die Konfiguration orientiert sich an der im RootForum.de Wiki dokumentierten Postfix-Konfiguration.

# cd /etc/postfix
# cat>main.cf<<EOF
queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
mail_owner = postfix

mydestination = localhost
mynetworks_style = host

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, permit
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_reverse_client_hostname, permit
smtpd_data_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, permit
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient,
  reject_unknown_recipient_domain, check_recipient_mx_access cidr:/etc/postfix/mx_access, reject_unauth_destination,
  check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_policy_service inet:127.0.0.1:12525,
  check_policy_service inet:127.0.0.1:10030, permit
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, permit

virtual_mailbox_domains = /etc/postfix/virtual_domains
virtual_mailbox_maps = hash:/etc/postfix/virtual_users
virtual_alias_maps = hash:/etc/postfix/virtual_aliases
virtual_transport = dspam
dspam_destination_recipient_limit = 1

smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/postfix/server.crt
smtpd_tls_dh1024_param_file = /etc/ssl/postfix/dh_1024.pem
smtpd_tls_dh512_param_file = /etc/ssl/postfix/dh_512.pem
smtpd_tls_key_file = /etc/ssl/postfix/server.key
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache
smtpd_tls_security_level = may
smtpd_use_tls = yes
EOF

Nachdem die Konfiguration gespeichert wurde, sollte der Aufruf von `postconf -n` folgende Ausgabe produzieren:

broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
mail_owner = postfix
mydestination = localhost
mynetworks_style = host
queue_directory = /var/spool/postfix
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_reverse_client_hostname, permit
smtpd_data_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining, permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, permit
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient,  reject_unknown_recipient_domain, check_recipient_mx_access cidr:/etc/postfix/mx_access, reject_unauth_destination,  check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, check_policy_service inet:127.0.0.1:12525,  check_policy_service inet:127.0.0.1:10030, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, permit
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/postfix/server.crt
smtpd_tls_dh1024_param_file = /etc/ssl/postfix/dh_1024.pem
smtpd_tls_dh512_param_file = /etc/ssl/postfix/dh_512.pem
smtpd_tls_key_file = /etc/ssl/postfix/server.key
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache
smtpd_use_tls = yes
virtual_alias_maps = hash:/etc/postfix/virtual_aliases
virtual_mailbox_domains = /etc/postfix/virtual_domains
virtual_mailbox_maps = hash:/etc/postfix/virtual_users
virtual_transport = dspam

Für die Zustellung der E-Mails durch den Dovecot MDA bzw. dspam müssen noch zwei Transports in der /etc/postfix/master.cf eingetragen werden. Wichtig ist dabei, dass alle anderen Einträge unverändert bleiben.

# cat>>master.cf<<EOF
dovecot unix    -       n       n       -       -      pipe
  flags=DRhu user=mail:mail argv=/usr/libexec/dovecot/deliver -f ${sender} -d ${user}@${nexthop} -n -m ${extension}

dspam                unix   -   n   n   -   -   pipe
  flags=DORhqu user=mail argv=/usr/bin/dspam --user ${recipient} --deliver=innocent,spam -f ${sender} -d ${user}@${nexthop} -n -m ${extension}
EOF

Der dovecot-Transport kann benutzt werden, wenn auf die Filterung durch dspam verzichtet werden soll. In diesem Fall muss auch der Wert für virtual_transport in der main.cf auf dovecot geändert werden.

Die übrigen Einstellungen sind hauptsächlich noch nötig, um einigen Spam von dem System fernzuhalten. So werden beispielsweise angebliche Gegenstellen aus privaten IP-Blöcken oder von Broadcast und Multicast Netzen von vorneherein abgewiesen, da diese im Internet prinzipiell nicht geroutet werden.

# cat>mx_access<<EOF
0.0.0.0/8         REJECT Domain MX in broadcast network
10.0.0.0/8        REJECT Domain MX in RFC 1918 private network
127.0.0.0/8       REJECT Domain MX in loopback network
169.254.0.0/16    REJECT Domain MX in link local network
172.16.0.0/12     REJECT Domain MX in RFC 1918 private network
192.0.2.0/24      REJECT Domain MX in TEST-NET network
192.168.0.0/16    REJECT Domain MX in RFC 1918 private network
224.0.0.0/4       REJECT Domain MX in class D multicast network
240.0.0.0/5       REJECT Domain MX in class E reserved network
248.0.0.0/5       REJECT Domain MX in reserved network
EOF

# postmap mx_access

Die folgenden Einträge sorgen dafür, dass syntaktisch inkorrekte bzw. "seltsame" Empfängeradressen ebenfalls von vorneherein abgewiesen werden. Das Gegenteil soll für die Adressen für die Role accounts postmaster, hostmaster und abuse gelten. E-Mails an diese Adressen müssen immer angenommen werden.

# cat>recipient_checks.pcre<<EOF
/^\@/             550 Invalid address format.
/[!%\@].*\@/      550 This server disallows weird address syntax.
/^postmaster\@/   OK
/^hostmaster\@/   OK
/^abuse\@/        OK
EOF

# postmap recipient_checks.pcre

# cat>virtual_aliases<<EOF
@example.com alice@example.com
@example.org alice@example.com
EOF

# postmap virtual_aliases

Die Aufrufe von postmap(1) müssen unbedingt nach jeder Änderung dieser Dateien erfolgen, damit Postfix mit dem aktuellen Datenbestand arbeitet.

Kommen wir nun zu dem, was wir eigentlich erreichen wollten: Zur Einrichtung der Domains und Benutzerkonten, welche später E-Mails empfangen und versenden können sollen.

In der Datei /etc/postfix/virtual_domains ist einfach eine Liste der Domains, die von dem Mailsystem verarbeitet werden sollen. Dabei steht je eine Domain in einer Zeile.

# cat>virtual_domains<<EOF
example.com
example.org
EOF

Die virtuellen Benutzer und das Verzeichnis, in dem deren E-Mails später gespeichert werden sollen, stehen in der Datei /etc/postfix/virtual_users. Wiederum steht je ein Benutzer und dessen Verzeichnis in einer Zeile. Das Verzeichnis ist nach dem Schema DOMAIN/USER aufgebaut.

# cat>virtual_users<<EOF
alice@example.com example.com/alice
bob@example.org example.org/bob
EOF

# postmap virtual_users

Die Aliase in /etc/mail/aliases sind bereits weitgehend sinnvoll konfiguriert. Es fehlt lediglich noch ein Alias für den Role account root, das auf eine gültige E-Mail-Adresse verweisen muss.

# echo "root: alice@example.com">>/etc/mail/aliases
# newaliases

Wichtig ist hierbei, dass im Gegensatz zu allen Einträgen in anderen Dateien, hier anschließend ein Aufruf von newaliases(1) erfolgt.

Die Postfix-Konfiguration ist somit ebenfalls komplett. Es fehlen lediglich noch das SSL-Zertifikat und der Private Key. Analog zum Vorgehen bei Dovecot werden auch hier die notwendigen Dateien generiert.

# cd /etc/ssl/postfix
# openssl genrsa -aes256 -out server.key.passwd 2048
# openssl rsa -in server.key.passwd -out server.key
# rm server.key.passwd
# openssl req -new -key server.key -out server.csr
# openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
# cat server.key server.crt>server.pem
# openssl dhparam -out dh_1024.pem -2 -rand /dev/urandom 1024
# openssl dhparam -out dh_512.pem -2 -rand /dev/urandom 512
# chmod 400 *
# chown postfix *

Als letztes Glied in der Kette fehlt nun noch der Spamfilter dspam. Die Konfiguration sollte genau überprüft und an die konkreten Anforderungen angepasst werden. Hier wird beispielsweise eine Berkeley DB als Backend verwendet, was bei vielen Zugriffen und vielen Benutzern eher suboptimal ist.

# cd /etc/dspam
# cat>dspam.conf<<EOF
Home /var/spool/dspam
StorageDriver /usr/lib/dspam/libhash_drv.so
TrustedDeliveryAgent "/usr/libexec/dovecot/deliver"
UntrustedDeliveryAgent "/usr/libexec/dovecot/deliver -d %u -n"
EnablePlusedDetail      on
OnFail error

Trust root
Trust dspam
Trust mail
Trust nobody

TrainingMode teft
TestConditionalTraining on
Feature whitelist
Algorithm graham burton
Tokenizer chain
PValue bcr

WebStats on

Preference "spamAction=deliver"
Preference "signatureLocation=headers"  # 'message' or 'headers'
Preference "showFactors=off"

AllowOverride trainingMode
AllowOverride spamAction spamSubject
AllowOverride statisticalSedation
AllowOverride enableBNR
AllowOverride enableWhitelist
AllowOverride signatureLocation
AllowOverride showFactors
AllowOverride optIn optOut
AllowOverride whitelistThreshold

# --- Hash ---
HashRecMax              98317
HashAutoExtend          on
HashMaxExtents          0
HashExtentSize          49157
HashPctIncrease 10
HashMaxSeek             10
HashConnectionCache     10

Notifications   off

PurgeSignatures 14          # Stale signatures
PurgeNeutral    90          # Tokens with neutralish probabilities
PurgeUnused     90          # Unused tokens
PurgeHapaxes    30          # Tokens with less than 5 hits (hapaxes)
PurgeHits1S     15          # Tokens with only 1 spam hit
PurgeHits1I     15          # Tokens with only 1 innocent hit

LocalMX 127.0.0.1
SystemLog on
UserLog   on
Opt out
#MaxMessageSize 4194304

ProcessorURLContext on
ProcessorBias on
StripRcptDomain off
EOF

Nachdem jede Komponente konfiguriert wurde (bei postgrey und policyd-weight ist das nicht notwendig), können alle beteiligten Programme gestartet und in die jeweiligen Runlevel eingetragen werden, damit diese auch bei einem Neustart geladen werden.

# /etc/init.d/policyd-weight start
# /etc/init.d/postgrey start
# /etc/init.d/postfix start
# rc-update add policyd-weight
# rc-update add postgrey
# rc-update add postfix

Das gesamte Mailsystem ist damit komplett. Insgesamt ist das System recht speichersparend, was der allgemeinen Performance des vServers zu Gute kommen dürfte.

# vzfree
VPS Speichernutzung:
Momentan genutzt:       35.1797 MB
Zugesichert:            512 MB
Maximal nutzbar:        1074 MB

Das System benötigt rund 35 MB Speicher im Idle-Zustand für ein ausgewachsenes Mailsystem mit Spamabwehrmaßnahmen und serverseitiger Filter. Neue Benutzer und Domains können sehr schnell und einfach durch Bearbeitung der zuvor angelegten Dateien (virtual_users, virtual_domains usw.) angelegt werden.

Es gibt jedoch auch einige Überlegungen und Anmerkungen zu dem vorgestellten System:

• Die Mailbenutzer selbst haben keine Möglichkeit, auf ihre Einstellungen Einfluss zu nehmen. Das ist bei wenigen Benutzern noch tolerierbar, ab einer gewissen Anzahl wird es jedoch lästig. Abhilfe könnte ein Webinterface schaffen, über das die Benutzer ihre Einstellungen verwalten können. Die meisten fertigen Webinterfaces setzen jedoch ein (R)DBMS wie MySQL oder einen Verzeichnisdienst wie LDAP voraus, in dem die Einstellungen gespeichert werden. Beides ist in dem vorgestellten Setup nicht eingerichtet.


• Der installierte Spamfilter dspam muss zunächst trainiert werden, um optimale Ergebnisse zu liefern. Dazu sind etwa 200 Ham-Mails notwendig und idealerweise genausoviele Spam-Mails.


• dspam ist natürlich nicht perfekt und so können Mails ab und zu falsch klassifiziert werden (false negatives bzw. false positives). Bei dem vorgestellten Setup hat der Benutzer keinerlei Möglichkeit, falsch klassifizierte E-Mails durch den Spamfilter lernen zu lassen.

Diese Punkte können bei Bedarf in einem späteren Beitrag behandelt und nachgerüstet werden.

Ein weiterer Kritikpunkt betrifft den vServer von EUserv direkt: Leider kann der PTR Resource Record (auch bekannt als Reverse DNS, Reverse Domain usw.) für die IP-Adresse des Virtual-Servers bei EUserv derzeit nicht geändert werden. Standardmäßig lautet der Eintrag auf den Hostname des ausgelieferten Systems, also z. B. 81-89-XXX-XXX.blue.kundencontroller.de.

Das schränkt die Nützlichkeit als Mailserver extrem ein, da manche restriktiv konfigurierten Systeme keine E-Mails von Hosts mit solchen "generischen" Hostnamen annehmen. Diese werden als Indiz für eine dynamisch vergebene IP-Adresse gewertet, wie sie bei vielen Dialup-Anbietern genutzt werden.

Da eine Änderung des PTR Resource Records für die normalen dedizierten Server bei EUserv möglich ist, wird dieses Feature vermutlich spätestens mit der Markteinführung der virtuellen Server nachgereicht. Falls nicht, wäre das ein massives Manko des Produkts - sofern man es ernsthaft benutzen möchte.

Im nächsten Beitrag wird es voraussichtlich um die Einrichtung eines Webservers auf dem virtuellen Server gehen. In einem Folgebeitrag könnte ich etwas über die Nutzung von Exim anstatt Postfix bei diesem Mailsetup schreiben.

Allgemein würde ich mich über etwas Feedback freuen, ob die Beiträge überhaupt jemand liest oder diese nur unnötig Speicherplatz auf dem Server belegen.