• Teilen
  • Bookmark "Mailserver für einen Homeserver" auf del.icio.us
  • Bookmark "Mailserver für einen Homeserver" auf Digg
  • Bookmark "Mailserver für einen Homeserver" auf Reddit
  • Bookmark "Mailserver für einen Homeserver" auf StumbleUpon
  • Bookmark "Mailserver für einen Homeserver" auf Facebook
  • Bookmark "Mailserver für einen Homeserver" auf Twitter
  • Bookmark "Mailserver für einen Homeserver" auf Slashdot

Mailserver für einen Homeserver

Die folgende Anleitung erklärt, wie du einen funktionierenden Mailserver hinter einem Router mit dynamischer IP einrichten kannst. Hierfür wird als „Basis“ Postfix und Dovecot verwendet. Weiterhin kommen Fetchmail zum Abrufen von Mails von anderen Servern, Sieve zum Erstellen einfacher Filterregeln, sowie Postgrey, ClamAV, SpamAssassin und AmavisNew zur Spam- und Virenbekämpfung zum Einsatz.
Diese Anleitung ist zwar für Homeserver konzipiert, kann aber auch für Root- und V-Server verwendet werden. Der große Unterschied liegt in der Verwendung eines Relayhosts.

Softwarevoraussetzungen: Paketverwaltung | Texteditor | siehe weiter unten
Schwierigkeitsgrad: Schwer
Ausgetestet mit folgenden Betriebssystemen: Ubuntu | Debian (Lenny, Squeeze, Wheezy teilweise Probleme bei Dovecot-Postfix Integration) | teilweise auch andere Distributionen

Achtung! sudo: In dieser Anleitung verdeutlicht der Befehl sudo, dass die folgende Codezeile mit Root-Rechten ausgeführt werden muss. In normalen Ubuntu Installationen (Root-/VServer siehe Debian) kann dies durch den Befehl sudo erreicht werden.
Bei Debian wird bei der Installation ein Passwort für den Root-Benutzer festgelegt, so kann man sich entweder direkt als Root oder als „normaler“ Benutzer mit Eingabe von su als Root einloggen (Root-Passwort benötigt) → sudo bleibt dann überflüssig!

Voraussetzungen

Folgende Voraussetzungen müssen erfüllt werden:

  1. E-Mail Adresse bei Arcor
  2. eine dynamische DNS (zum Beispiel bei DynDNS)
  3. statische IP-Adressen im lokalen Netzwerk
  4. Weiterleitung von Port 25 an den Host mit dem Mailserver
  5. du hast den Beitrag Einführung gelesen

Wenn du alle erfüllt hast, kannst du nun mit den einzelnen Diensten starten. Falls du Fragen hast, kannst du dich per E-Mail an mich wenden (support[at]mein.homelinux[dot]com).

Funktionen

Diese Funktionen wird der Mailserver nachher besitzen:

  1. Mails unter der dynamischen DNS empfangen (Absender und Empfänger du@deine_dyDNS.com)
  2. Mailboxen für alle Systembenutzer
  3. Mails filtern und sortieren
  4. Mails auf Spam und Viren überprüfen
  5. IMAP+POP3
  6. Verschlüsselung der Verbindungen

Postfix

Wir fangen mit Postfix an, da er die grundlegenden Funktionen unseres Mailservers beinhaltet.

Benötigte Software-Pakete

Folgende Pakete werden benötigt:

postfix             #das "Grundpaket"
libsasl2-modules    #weil wir uns bei Arcor authentifizieren müssen
mailutils           #um das Ganze zu testen 

Hinweis: Während der Installation werden einem Fragen bezüglich Postfix gestellt, diese werden im nächsten Abschnitt erläutert, also bitte nicht abbrechen oder einfach „durch klicken“.

also installieren wir diese:

user@server:~$ sudo apt-get install postfix libsasl2-modules mailutils

Grundkonfiguration

In diesem Abschnitt geht es um die Fragen, die von Postfix gestellt werden. Hinweis: Haken können mit der [Leertaste] gesetzt werden; nächster Eintrag kann mit [TAB] erreicht werden; bestätigt wird mit der [Eingabetaste].

1. Frage: Allgemeine Art der Konfiguration -> wir wählen "Internet mit Smarthost"  -> weiter mit [Eingabetaste]
2. Frage: System-E-Mail-Name -> wir tragen den Namen der dynamischen DNS ein     -> weiter mit [Eingabetaste]

Das waren nun leider nicht alle Fragen, deshalb lassen wir den Assistent nocheinmal laufen:

user@server:~$ sudo dpkg-reconfigure postfix

Und beantworten diese Fragen wie folgt (die Reihenfolge kann variieren!):

1. Frage: Allgemeine Art der Konfiguration -> wir wählen "Internet mit Smarthost"  -> weiter mit [Eingabetaste]
2. Frage: System-E-Mail-Name -> wir tragen den Namen der dynamischen DNS ein     -> weiter mit [Eingabetaste]
3. Frage: SMTP-Relay-Server -> wir tragen "mail.arcor.de" ein -> weiter mit [Eingabetaste]
4. Frage: Empfänger von E-Mails an Root und Postmaster -> wir tragen den Systembenutzer ein, der für den Homeserver zuständig ist -> weiter mit [Eingabetaste]
5. Frage: Weitere Rechner, für die E-Mail akzeptiert werden soll (leere Eingabe: keine): -> hier lassen wir die bereits eingetragenen Hostnamen stehen und fügen die lokale ip des servers und 127.0.0.1 bzw. andere IP-Adressen über die der Server erreichbar ist (auch weiter dynamische DNSen)) -> weiter mit [Eingabetaste]
6. Frage: Synchrone Aktualisierungen(..) -> wir wählen "nein" -> weiter mit [Eingabetaste]
7. Frage: lokale Netze -> hier werden die Rechner eingetragen, die nachher den Server zum Mailversand benutzen wollen eingetragen (durch Komma getrennt) -> weiter mit [Eingabetaste] 
--Alle weiteren Fragen können bei den Standarteinstellungen belassen werden--

Nun haben wir die Grundkonfiguration abgeschlossen!

Mail über Arcor versenden

Lokale Mails werden jetzt zugestellt, nun müssen wir noch dafür sorgen, dass auch externe Empfänger ihre Mail erhalten. Dazu richten wir eine Authentifizierung am Arcor Smarthost ein.

Dazu öffnen wir die /etc/postfix/main.cf:

user@server:~$ sudo nano /etc/postfix/main.cf

und fügen unten folgendes ein:

smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password

Danach legen wir an /etc/postfix/sasl_password:

user@server:~$ sudo touch /etc/postfix/sasl_password

Öffnen diese mit nano:

user@server:~$ sudo nano /etc/postfix/sasl_password

Achtung: Kommentarzeichen (#) weglassen! Ansonsten schlägt die Authentifizierung fehl.

und füllen sie mit folgendem Inhalt (Kommentarzeichen (#) weglassen):

mail.arcor.de username:passwort    #username durch Benutzername bei arcor ersetzen, passwort durch das Login-Passwort für den Account bei arcor ersetzen.
mail.arcor.de ich:meinpasswort     #Beispiel

Danach führen wir diese Befehle aus:

user@server:~$ sudo chmod 600 /etc/postfix/sasl_password       #Rechte anpassen
user@server:~$ sudo postmap /etc/postfix/sasl_password         #In Datenbank umwandeln
user@server:~$ sudo service postfix restart                #Postfix neustarten

Testen

Bevor wir nun weitermachen, führen wir einen Test durch, dazu betrachten wir mit einem Terminal die logs:

user@server:~$ sudo tail -f  /var/log/mail.log

und in dem anderen versenden wir eine Mail:

user@server:~$ echo "Testtext" | mailx -s "Testbetreff"  Empfänger@provider.de   #Empfänger darf nicht lokal sein! (also nicht: ich@localhost)
user@server:~$ echo "hallo wie gehts?" | mailx -s "hallo"  herbert.gerhardt@gmail.com        #Beispiel

Die Logs sollten dann so aussehen:

Aug 20 20:19:45 HOST postfix/pickup[27137]: 92BB5614ED: uid=1000 from=<USER>
Aug 20 20:19:45 HOST postfix/cleanup[27202]: 92BB5614ED: message-id=<20100820181945.92BB5614ED@HOST>
Aug 20 20:19:45 HOST postfix/qmgr[27138]: 92BB5614ED: from=<USER@dynDNS>, size=392, nrcpt=1 (queue active)
Aug 20 20:19:48 HOST postfix/smtp[27204]: 92BB5614ED: to=<EMPFÄNGER>, relay=mail.arcor.de[151.189.21.116]:25, delay=3.4, delays=0.37/0.18/1.7/1.1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 078DF21246B)
Aug 20 20:19:48 HOST postfix/qmgr[27138]: 92BB5614ED: removed

Demnach haben wir jetzt schon einmal einen (fast) funktionstüchtigen Postfix….

Kleinigkeiten

Natürlich lassen sich auch noch diverse Dinge anpassen.

Absender setzen

Unter Umständen will man für bestimmte Benutzer einen anderen Absender setzen. Zum Beispiel, dass Mail aus PHP heraus nicht als Absender www-data@dynDNS sondern noreply@dynDNS.
Dazu fügt man der /etc/postfix/main.cf folgende Zeile hinzu:

sender_canonical_maps = hash:/etc/postfix/sender_canonical

Danach öffnen wir /etc/postfix/sender_canonical mit nano:

user@server:~$ sudo nano /etc/postfix/sender_canonical

und fügen folgendes ein:

www-data noreply@dynDNS   #nun hat www-data nicht mehr den Absender www-data sonder noreply, dynDNS sollte durch die eigene dynamische DNS ersetzt werden.
user1 user2@dynDNS        #hier verschickt user1 unter dem Absender von user2
user3 user2@gmail.com     #und hier user3 unter seiner/einer gmail Adresse

Nun führt man noch folgende Befehle aus:

user@server:~$ sudo postmap /etc/postfix/sender_canonical
user@server:~$ sudo service postfix restart 

und die Absender sind manipuliert!

Aliase

Aliase bieten eine Möglichkeit der Umleitung. Als erstes öffnet man die Datei /etc/aliases:

user@server:~$ sudo nano /etc/aliases

der Inhalt wird folgendermaßen festgelegt:

postmaster: root                #mail, die an postmaster gerichtet ist, wird an root weitergeleitet

In dieser Art kann weiter ergänzt werden (Beispiele)(auf “:“ achten):

#interne weiterleitung:
webmaster: root       #mail, die an webmaster gerichtet ist, geht an root
www-data: root        #mail, die an www-data soll, kommt bei root an
root: user1           #mail, die für root bestimmt ist, geht an user1
#externe weiterleitung:
user2: user2@gmail    #mail für user2 wird an seine gmail-adresse geschickt
#"nicks"
coolz: user3          #user3 ist nun unter coolz@dynDNS erreichbar
icke: user4           #und user4 hat noch seine alias icke, so lassen sich extra mailboxen für jeden seiner Nicknamen einsparen, durch Anlegen eines Alias

Nach erfolgreicher Änderung sind noch folgende Befehle nötig:

user@server:~$ sudo newaliases                    #aliase übernehmen
user@server:~$ sudo service postfix restart   #postfix neustartem

Verschlüsselung

Postfix unterstützt natürlich auch Verschlüsselung via TLS/SSL. Diese ist unter Umstände standardmäßig aktiviert, trotzdem sollte man erst einmal überprüfen, ob TLS wirklich aktiviert ist.
In der /etc/postfix/main.cf muss dazu folgendes stehen:

smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls = yes

und zwar ohne # davor!

Achtung: Clients die kein TSL/SSL anbieten werden dann abgewiesen! Somit kann Mail von Providern/ISPs/Servern, die kein TSL/SSL sprechen nicht angenommen werden! Diese Einstellung sollte gut überlegt und abgewogen werden!

Soll TLS/SSL nicht nur angeboten, sondern auch erzwungen werden, kann noch folgende Zeile eingefügt werden:

smtpd_enforce_tls = yes

Veraltet: SMTPS

Früher erfolgte die TLS/SSL Verschlüsselung nicht über den normalen SMTP Port (25), sondern über den seperaten SMTPS Port (465). Wenn wie oben beschrieben TLS/SSL für Postfix eingerichtet wurde ist dieser Schritt somit nur noch bei Verwendung sehr alter Mailclients oder gesperrtem SMTP Port nötig.
Um nun SMTPS zu aktivieren öffnet man /etc/postfix/master.cf:

user@server:~$ sudo nano /etc/postfix/master.cf

und entfernt dort vor folgenden Zeilen das #-Zeichen:

smtps     inet  n       -       -       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes

Anschließend sollte man postfix noch neustarten:

user@server:~$ sudo service postfix restart

Dovecot

Dovecot ist ein leicht zu konfigurierender IMAP und POP3 Server, der sich unter anderem in postfix integrieren lässt.

Software-Pakete

Folgende Pakete werden benötigt

dovecot-common       #dovecot
dovecot-postfix      #Integration in postfix (in Debian nicht enthalten)
dovecot-imapd        #Unterstützung für IMAP
dovecot-pop3d        #Unterstützung für POP3
dovecot-sieve        #Unterstützung für Sieve (erst ab Wheezy bzw. Precise (12.04 LTS) nötig!)

Ubuntu

Unter Ubuntu installieren wir die Pakete wie folgt:

user@server:~$ sudo apt-get install dovecot-common dovecot-imapd dovecot-pop3d dovecot-postfix

Das Paket dovecot-postfix integriert darauf hin dovecot in postfix. Ab Precise (12.04 LTS) sollte zusätzlich noch das Paket dovecot-sieve installiert werden:

user@server:~$ sudo apt-get install dovecot-sieve
Hinweise zu dovecot-postfix

Dieses Paket ändert den mailbox_command in Postfix. Darüber hinaus werden bestimmte Paramter, die in /etc/dovecot/dovecot.conf gesetzt werden durch Konfigurationsdateien in /etc/dovecot/conf.d/ überschrieben. Im Normalfall ist dies nicht tragisch, sondern sogar erwünscht. Bei besonderen Konfigurationen kann dies jedoch der Grund eines Fehlverhaltens sein. Wenn Konfigurationsparameter nicht übernommen werden, sollte man zuerst einen Blick in folgende Dateien werfen (falls jene existieren):

/etc/dovecot/conf.d/01-mail-stack-delivery.conf     #Bis jetzt nur bei Natty entdeckt
/etc/dovecot/conf.d/01-dovecot-postfix.conf         #Bis jetzt bei Lucid entdeckt (evtl. auch bei anderen Ubuntu-Version vorhanden??)
/etc/dovecot/conf.d/*                               #Falls keine der oberen Dateien, das Ganze mit einer Wildcard (''*'') versuchen

Debian

dovecot-postfix scheint es unter Debian nicht zu geben, deshalb integrieren wir Dovecot dort nachher manuell in Postfix. Die Pakete werden unter Debian so installiert:

user@server:~$ sudo apt-get install dovecot-common dovecot-imapd dovecot-pop3d

Ab Wheezy sollte noch dovecot-sieve installiert werden:

user@server:~$ sudo apt-get install dovecot-sieve

Hinweis: IPv6

Sollte bei der Installation von Dovecot folgender Fehler auftauchen:

dovecot-imapd (1:2.1.7-2) wird eingerichtet ...

Creating config file /etc/dovecot/conf.d/20-imap.conf with new version
[....] Restarting IMAP/POP3 mail server: dovecotError: socket() failed: 
Address family not supported by protocol
Error: service(imap-login): listen(::, 143) failed: Address family not 
supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(imap-login): listen(::, 993) failed: Address family not 
supported by protocol
Fatal: Failed to start listeners
  failed!
invoke-rc.d: initscript dovecot, action "restart" failed.
dpkg: Fehler beim Bearbeiten von dovecot-imapd (--configure):
  Unterprozess installiertes post-installation-Skript gab den Fehlerwert 
1 zurück

(..) #noch mehr Fehler dieser Art

…, kann dieser Fehler behoben werden, wenn IPv6 aktiviert wird und anschließend die Pakete nochmals konfiguriert/installiert werden:

user@server:~$ sudo modprobe ipv6
user@server:~$ sudo apt-get -f install

Konfiguration

Bevor die Konfiguration beginnen kann, muss zunächst überprüft werden, welche Version von Dovecot auf dem System installiert ist:

user@server:~$ dpkg -l | grep dovecot
ii  dovecot-common                        1:2.1.7-2                          Transitional package for dovecot
(..)

Hier ist also ein Dovecot 2.x installiert. Alternativ kann auch die Version 1.x installiert sein. Im Folgenden wird zwischen diesen beiden Versionen unterschieden. Der Grund dafür liegt in veränderten Pfaden zu den Konfigurationsdateien.

SSL

Dovecot 1.x

Um SSL zu nutzen, muss in der /etc/dovecot/dovecot.conf folgendes stehen:

# Protocols we want to be serving:
#  imap imaps pop3 pop3s
protocols = imap imaps pop3 pop3s

und vor den Pfaden zu den Zertifikaten muss das Rautezeichen (#) entfernt werden:

# PEM encoded X.509 SSL/TLS certificate and private key. They're opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root.
ssl_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
ssl_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
Dovecot 2.x

In der /etc/dovecot/conf.d/10-ssl.conf muss hierfür das Rautezeichen vor ssl entfernt werden:

# SSL/TLS support: yes, no, required. <doc/wiki/SSL.txt>
ssl = yes

Auch sollten in der gleichen Datei die Pfade zu den Zertifikaten einkommentiert sein (ohne # davor versehen) – also so aussehen:

# PEM encoded X.509 SSL/TLS certificate and private key. They're opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Included doc/mkcert.sh can be used to easily generate self-signed
# certificate, just make sure to update the domains in dovecot-openssl.cnf
ssl_cert = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem

Dovecot an Postfix anpassen (als LDA)

Dovecot 1.x

Dazu muss in der /etc/dovecot/dovecot.conf der LDA von Dovecot aktiviert werden, dazu sucht man den Abschnitt LDA:
##
## LDA specific settings
##

Hinweis: die “(…)“ symbolisieren, dass in dieser Vorlage der dort stehende Code ausgelassen wurde, weil an ihm nichts verändert wird.

Diesen passt man wie folgt an:

protocol lda {
  # Address to use when sending rejection mails.
  postmaster_address = postmaster@localhost

(...)

  # Support for dynamically loadable plugins. mail_plugins is a space separated
  # list of plugins to load.
  #mail_plugins =
   mail_plugins = sieve
   mail_plugin_dir = /usr/lib/dovecot/modules/lda

(...)

}
Dovecot 2.x

Hinweis: die “(…)“ symbolisieren, dass in dieser Vorlage der dort stehende Code ausgelassen wurde, weil an ihm nichts verändert wird.

Hier öffnen wir die /etc/dovecot/conf.d/15-lda.conf und passen diese wie folgt an:

# Address to use when sending rejection mails.
# Default is postmaster@<your domain>.
postmaster_address = postmaster@localhost

(...)

protocol lda {
  # Space separated list of plugins to load (default is global mail_plugins).
  mail_plugins = $mail_plugins sieve
}
(...)

Soll es für Sieve später möglich sein nicht existierende Unterordner anzulegen, können in obiger Datei gleich noch folgende Parameter geändert werden (optional):

# Should saving a mail to a nonexistent mailbox automatically create it?
lda_mailbox_autocreate = yes

# Should automatically created mailboxes be also automatically subscribed?
lda_mailbox_autosubscribe = yes

Erweiterung für Debian: Dovecots LDA mit Postfix

Wie bereits erwähnt muss man in Debian selbst Hand anlegen, um es Postfix zu ermöglichen, den LDA von Dovecot zu verwenden. Nachdem der LDA von Dovecot (siehe übergeordnetes Kapitel) aktiviert wurde, muss Postfix noch etwas angepasst werden.

Dazu fügen wir in der /etc/postfix/main.cf

user@server:~$ sudo nano /etc/postfix/main.cf

am Ende folgende Zeile ein:

mailbox_command = /usr/lib/dovecot/deliver 

..und starten Postfix neu (reload reicht unter Umständen auch schon aus):

user@server:~$ sudo service postfix restart

Anschließend kann auch Sieve mit Debian verwendet werden.

Hinweis: Es kann sein, dass diese Zeile nicht genügt und der Dovecot-LDA von Postfix nicht richtig genutzt werden kann. Siehe dazu bitte im Dovecot Wiki für Version 1.x bzw. Version 2.x.

Rechte anpassen

Nun müssen wir noch die Rechte anpassen:

user@server:~$ sudo chmod 644 /etc/dovecot/dovecot.conf 

Dovecot neustarten

Nun starten wir Dovecote neu:

user@server:~$ sudo service dovecot restart

Testen

wir betrachten nun das Mail-log:

user@server:~$ sudo tail -f /var/log/mail.log

Nun verschicken wir eine Mail an einen lokalen Systembenutzer:

user@server:~$ echo "Testtext" | mailx -s "Testbetreff"  user@localhost

und schauen, was in den Logs vor sich geht.
Wenn die Konfig stimmt erscheint solch eine Nachricht:

Aug 20 23:03:12 HOST postfix/qmgr[6646]: 6B9C5616B4: from=<user@dynDNS>, size=382, nrcpt=1 (queue active)
Aug 20 23:03:12 HOST dovecot: deliver(user): msgid=<20100820210312.6B9C5616B4@HOST>: saved mail to INBOX
Aug 20 23:03:12 HOST postfix/local[6896]: 6B9C5616B4: to=<user@localhost>, relay=local, delay=0.53, delays=0.38/0.01/0/0.14, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver -c /etc/dovecot/conf.d/01-dovecot-postfix.conf -n -m "${EXTENSION}")
Aug 20 23:03:12 HOST postfix/qmgr[6646]: 6B9C5616B4: removed

Als letztes greifen wir mit einem E-mail Clienten (z.B.: Evolution) auf den Mailserver zurück (via IMAP oder POP3) mit den Benutzerdaten (Benutzername/Passwort) eines Systembenutzers, dabei müsste diese Nachricht in den Logs auftauchen:

Aug 20 23:03:19 HOST dovecot: imap-login: Login: user=<user>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS

…und der Mailclient ruft schön die gerade eben versendete Mail ab…

Problembehebung

Falls eine Fehlermeldung erscheint, die darauf hinwiest, dass die „Mailboxen nicht gefunden“ werden konnten:

Oct  2 14:40:42 host dovecot: imap-login: Login: user=<user>, method=PLAIN, rip=192.168.2.1, lip=192.168.2.1, TLS
Oct  2 14:40:42 host dovecot: IMAP(user): mail_location not set and autodetection failed: Mail storage autodetection failed with home=/home/user
Oct  2 14:40:42 host dovecot: IMAP(user): Fatal: Namespace initialization failed

…, sollte zunächst überlegt werden, ob der Mailserver Mbox oder Maildir verwenden soll. Ein Vergleich findest du hier. Steht die Wahl fest, kann fortgefahren werden.

Für Dovecot Version 1.x folgende Zeile in der /etc/dovecot/dovecot.conf im Abschnitt
##
## Mailbox locations and namespaces
##

hinzufügen:

#wenn mbox verwendet werden soll
mail_location = mbox:~/mail:INBOX=/var/mail/%u  
#bei verwendung von maildir:
mail_location = maildir:~/Maildir  

Bei Dovecot 2.x in der /etc/dovecot/conf.d/10-mail.conf den Parameter mail_location wie folgt setzen:

#wenn mbox verwendet werden soll
mail_location = mbox:~/mail:INBOX=/var/mail/%u  
#bei verwendung von maildir:
mail_location = maildir:~/Maildir  

Anschließend die Testprozedur samt Neustart von Dovecot wiederholen.

Sollte Dovecot dann immer noch den Dienst mit folgender Meldung quittieren:

Aug 20 01:45:26 HOST dovecot: lda(user): Error: open(/var/mail/user) failed: Permission denied (euid=1000(user) egid=1000(user) missing +w perm: /var/mail, we're not in group 8(mail), dir owned by 0:8 mode=0775)
Aug 20 01:45:26 HOST dovecot: lda(user): Error: Opening INBOX failed: Mailbox doesn't exist: INBOX
Aug 20 01:45:26 HOST dovecot: lda(user): msgid=<20120819232757.94DB521C4A@HOST>: save failed to open mailbox INBOX: Internal error occurred. Refer to server log for more information. [2012-08-20 01:45:25]
Aug 20 01:45:26 HOST dovecot: lda(user): Error: BUG: Saving failed to unknown storage
Aug 20 01:45:26 HOST postfix/local[29616]: B504921C57: to=<user@HOST>, relay=local, delay=515, delays=514/0.12/0/1.2, dsn=4.3.0, status=deferred (temporary failure)

hilft das Ändern der Berechtigungen von /var/mail evtl. weiter (die Lösung ist aber nicht unbedingt ideal):

user@server:~$ sudo chmod 777 /var/mail

Anmerkung: Root-Login

Hinweis: bei diesem Befehl wird nach einem Passwort gefragt, dieses Passwort dient später zum Login über Dovecot.

Dovecot lässt standardmäßig keine root-Logins zu, deshalb müssen z.B. Dockstar-Benutzer ein extra Benutzer angelegen, auf den die Mails umgeleitet werden:

user@server:~$ sudo adduser BENUTZER    #BENUTZER durch zu erstellenden Benutzer ersetzten
user@server:~$ sudo adduser ich         #Beispiel mit Benutzer ich

Auf den erstellten Benutzer sollen nun die Mails für root weitergeleitet werden, dazu bearbeitet man die /etc/aliases

user@server:~$ sudo nano /etc/aliases

und fügt am Ende der Datei folgendes ein

root: BENUTZER           #BENUTZER durch denn erstellten Benutzer ersetzten
root: ich                #Beispiel mit Benutzer ich

danach ladet man die Aliase neu und startet Postfix neu:

user@server:~$ sudo newaliases
user@server:~$ sudo service postfix restart

Sieve

Sieve ist ein Filter zum Filtern von E-Mails. So wie wir jetzt unseren Mailserver konfiguriert haben, entfällt das manuelle Hochladen und Einsetzen einer Filterdatei. Jeder Benutzer hat seinen eigenen Filter, der die Mails filtert, die an ihn gerichtet sind. Um eine Ordnerstruktur nutzen zu können, in die Sieve Mails sortiert wird IMAP benötigt!

Filter anlegen

Wir müssen einfach nur in dem Home des jeweiligen Systembenutzers folgende Datei anlegen:

.dovecot.sieve

und diese mit dem Filterskript füllen. Diese Datei legen wir folgender maßen an:

user@server:~$ touch ~/.dovecot.sieve            # "~" entspricht dem Home des Users, mit dem gerade auf dem Server gearbeitet wird

und öffnen sie so:

user@server:~$ nano .dovecot.sieve

Filter definieren

In diesem Tutorial werden wir nicht alle Sieve Möglichkeiten durch nehmen. Es geht hier nur um das Grundlagenverständnis. Eine sehr umfangreiche Anleitung findet sich auf tty1.net. Weitere Informationen finden sich in der Wikipedia und auf ubuntuusers.de. Zusätzlich ist ein Blick in die Referenz auf mozdev.org empfehlenswert. In diesem Fall wird unser Server wird nicht über sieveshell angesprochen! Die Filterdatei muss nur unter ~/.dovecot.sieve abgelegt werden.

Einfaches Beispiel

Im Dateiheader der Filterdatei müssen die Erweiterungen stehen, die benötigt werden:

require "fileinto";  /* Modul zur Verschiebung der Mails, immer erforderlich */
require "reject";    /* Modul zur Zurückweisung, optional */
require "vacation";  /* Modul für Abwesenheitsbenachrichtigungen, optional */

Anschließend folgt das Skript:

if header :contains "from" ["amazon.de", "amazon.com"] { fileinto "INBOX.amazon"; }                                  #wenn der Header der E-Mail als Absender "amazon.de" oder "amazon.com" enthällt landet sie im Posteingang im Ordner "amazon"
elsif header :is "subject" "weekly newsletter" { fileinto "INBOX.newsletter.weekly-newsletter"; }                    #wenn der Header als Betreff "weekly newsletter" genau enthällt wird er nach "INBOX.newsletter.weekly-newsletter" verschoben
elsif allof (header :contains "from" "neu@web.de", header :contains "subject" "news") { fileinto "INBOX.sinnlos"; }  # wenn der Header also Absender "neu@web.de" und Betreff "news" enthällt, wird er nach "INBOX.sinnlos" verschoben.
else { fileinto "INBOX"; }                                                                                           #alles andere landet im Posteingang (INBOX)

Nochmal zum Aufbau:

if      #startet mit "if"
elsif   #ansonsten, wenn...
elsif
elsif
(..)    #noch mehr "elsif" (so viele du brauchst)
elsif
else    #der Rest, auf den keine der Kriterien zutreffen steht am Schluss mit "else"


Übersicht über alle möglichen Befehle:
findet sich hier weitere Beispiele

Hinweis zur IMAP-Server Ordnerstruktur:
In IMAP Ordnerstrukturen gibt es keine “/“ diese werden durch “.“ ersetzt. Wenn die E-Mail in den Eingang gelangen soll (und nicht in SPAM, TRASH und co.) muss immer ein INBOX davor stehen.
Beispiel:
Im E-Mailprogramm legen wir im Posteingang den Ordner spam an. Der Pfad, den sieve nutzen müsste wäre INBOX.spam.

Einfacher: ManageSieve

Um die Filterregeln direkt über das Mailprogramm (MUA) verwalten zu können, nutzen wir ManageSieve. Wie du ManageSieve in deinem MUA nutzen kannst, erfährst du in der Dokumentation zu jenem.

Dovecot 1.x

Hier erweitert man den protocols Parameter in der /etc/dovecot/dovecot.conf um managesieve:

# Protocols we want to be serving:
#  imap imaps pop3 pop3s
protocols = imap imaps pop3 pop3s managesieve

Dovecot 2.x

In Dovecot 2.x installiert man statt dessen das Paket dovecot-managesieved und startet Dovecot neu (falls dies nicht bereits durch die Installationsroutine erledigt wurde):

user@server:~$ sudo apt-get install dovecot-managesieved

Fetchmail

Fetchmail dient dazu Mails von einem anderen Mailserver abzuholen. So können die Mails dann lokal von Sieve sortiert und eingeordnet werden.

Benötigte Pakete

Es wird folgendes Pakete benötigt:

fetchmail

dieses installieren wir so:

user@server:~$ sudo apt-get install fetchmail

Konfigurieren

Die Konfiguration erfolgt über die /etc/fetchmailrc für alle Benutzer global.

Wir öffnen /etc/fetchmailrc wie folgt:

user@server:~$ sudo nano /etc/fetchmailrc

Der Inhalt wird folgender maßen festgelegt:

## Allgemeine Einstellungen
set postmaster "richard"      #postmaster eintragen; hier: richard
set bouncemail
set no spambounce
set properties ""
set syslog
set daemon 300                #alle wie viel Sekunden solle Fetchmail ausgeführt werden.


## Beispielsyntax:
poll MAILSERVER with proto IMAP/POP3
       user 'USERNAME_AUF_EMAILSERVER' there with password 'PASSWORT' is 'SYSTEMBENUTZER_FÜR_DEN_DIE_MAILS_SIND' here options keep ssl

## Beispiel: 
#hier holt der Systembenutzer richard seine Mails per POP3 von web.de mit seinem Nutzernamen richard@web.de
#sein Passwort bei web.de ist "sagichnicht"
#die Mails werden auf dem Server nicht gelöscht (keep) und verschlüsselt abgerufen (ssl)
#er setzt interval3, so dass fetchmail nur alle 3 Mal Ausführen seine Mails holt (web.de freemail Nutzer können nur alle 15 Minuten E-Mails abholen)
poll pop3.web.de with proto POP3 interval 3
       user 'richard@web.de' there with password 'sagichnicht' is 'richard' here options keep ssl


## anderes Beispiel:
#Der Systembenutzer herbert holt seine Mails vom IMAP-Server von Googlemail.
#dort hat er den Nutzernamen "herbert.seigel", mit seinem Passwort "bekommstdunicht"
#anders als richard löscht fetchmail die gerade eben abgeholten E-Mails ("keep" fehlt)
#auch er lädt seine Mails verschlüsselt ("ssl")
poll imap.googlemail.com with proto IMAP 
       user "herbert.seigel@googlemail.com" there with password "bekommstdunicht" is "herbert" here ssl

Fetchmail als Daemon

Um die Mails nun regelmäßig abzurufen, müssen wir fetchmail noch als Daemon starten, dazu öffnen wir die Datei /etc/default/fetchmail:

user@server:~$ sudo nano /etc/default/fetchmail

und setzen START_DAEMON von „no“:

# Declare here if we want to start fetchmail. 'yes' or 'no'
START_DAEMON=no

auf „yes“:

# Declare here if we want to start fetchmail. 'yes' or 'no'
START_DAEMON=yes

danach starten wir fetchmail:

user@server:~$ sudo service fetchmail start

Testen

Nun beginnt fetchmail in den festgelegten Abständen Mails abzurufen.
Zum Überwachen kann man das Mail-Log verwenden:

user@server:~$ sudo tail -f /var/log/mail.log


das könnte zum Beispiel bei 3 E-Mails, die nicht gelöscht werden so aussehen:

Aug 23 21:05:16 HOST[11130]: Nachricht NUTZER@ANBIETER:3 von 3 wird gelesen (1038 Bytes) nicht gelöscht

Aus Fehlermeldungen kann man meistens den Grund entnehmen.

Spam- und Virenfilter

Wenn der ISP die Emails nicht, oder nur unzulänglich auf Viren und Spam überprüft, oder der Homeserver der direkte Empfänger für eine Domain ist, empfiehlt es sich Möglichkeiten zur Spam- und Virenbekämpfung zu installieren. Maßnahmen zur Spam- und Virenbekämpfung sind für den Betrieb eines einfachen Mailservers keine Voraussetzung, und daher natürlich optional. Diese 3 Programme sind die Grundbausteine für ein einfache und schnelle Grundinstallation zur Spam- und Virenbekämpfung.

amavisd-new	#dient zur Integration von Spam- und Virenfiltern in einen MTA
clamav-daemon	#Virenscanner
spamassassin	#Spamfilter
user@server:~$ sudo apt-get install amavisd-new clamav-daemon spamassassin

Hinweis: Der Kampf gegen Viren und Spam ist keine exakte Wissenschaft, weshalb es immer wieder zu einer falschen Klassifizierung (false positive) kommen kann. Um seinen Mailserver genau an die eigenen Bedürfnisse anzupassen benötigt es mitunter einiges an Geduld. Fortgeschrittene Linux-Kenntnisse sind dabei ebenfalls von Vorteil.

ClamAV

Um ClamAV für die Verwendung mit AmavisNew vorzubereiten muss lediglich der Benutzer clamav der Gruppe amavis hinzugefügt werden.

user@server:~$ sudo adduser clamav amavis


Weitere Änderungen müssen nicht vorgenommen werden. Der ClamAV-Daemon wird automatisch neu gestartet und aktuakisiert seine Signaturdatenbanken dank des Pakets clamav-freshclam regelmäßig. Die Anzahl der Aktualisierungen pro Tag kann recht einfach geändert werden. Üblicherweise ist hier ein Wert von 24 (1x pro Stunde) voreingestellt, ClamAV empfiehlt allerdings 96 (4x pro Stunde).

user@server:~$ sudo nano /etc/clamav/freshclam.conf
# Check for new database 4 times per day
Checks 24


Um eine Aktualisierung der Signaturdatenbanken von Hand auszuführen oder die Aktualität zu überprüfen kann mit folgendem Befehl ein Update erzwungen werden.

user@server:~$ sudo freshclam


ClamAV kann bereits mit einer Vielzahl von Dateitypen umgehen. AmavisNew informiert unter /var/log/mail.log bei jedem Neustart über bereits installierte und noch fehlende Decoder für Dateitypen. Um bestimmte Dateitypen zu unterstützen können weitere Decoder bei Bedarf nachinstalliert werden.

Dateiendung Paket
.F deaktiviert1)
.lzo lzop
.rpm rpm
.7zip p7zip
.rar unrar-free
.arj arj
.arc nomarch
.zoo zoo
.lha deaktiviert2)
.doc ripole
.cab cabextract
.exe arj/unrar-free


Nun muss der Daemon noch neu gestartet werden um unsere Änderungen zu übernehmen.

user@server:~$ sudo service clamav-daemon restart

SpamAssassin

Um SpamAssassin beim Systemstart zu laden und regelmäßig Ausschau nach neuen Filterregeln zu halten, muss die Datei /etc/default/spamassassin editiert werden, und die Werte für ENABLED und CRON auf 1 gesetzt werden.

user@server:~$ sudo nano /etc/default/spamassassin
# Change to one to enable spamd
ENABLED=1
(...)
# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1
user@server:~$ sudo service spamassassin start
Razor und Pyzor

Falls die Filterregeln von SpamAssassin nicht ausreichen, können weitere Datenbanken hinzugefügt werden. Die Pakete razor und pyzor werden automatisch erkannt und können einzeln oder gemeinsam nachinstalliert werden.

user@server:~$ sudo apt-get install razor pyzor
user@server:~$ sudo service spamassassin restart


Abhängig von der Hardware des Homeservers und der installierten Programme können diese beiden Pakete nicht nur die Mailzustellung ausbremsen, sondern auch das gesamte System verlangsamen. How do I get SpamAssassin to run faster?

AmavisNew

Die Konfigurationsdateien von AmavisNew befinden sich im Verzeichnis /etc/amavis/conf.d/. Die Dateien in diesem Verzeichnis sind numerisch geordnet. Dateien mit einer höheren Nummer überschreiben dabei die Konfiguration einer Datei mit niedrigerer Nummer. Es wird nicht empfohlen diese Dateien selbst zu editieren. Besser ist es die vorhandenen Dateien als Referenz zu verwenden, und die eigentliche Konfiguration in /etc/amavis/conf.d/50-user oder einer neuen Datei zu speichern.

user@server:~$ sudo nano /etc/amavis/conf.d/50-user

Wenn der Virenscanner/Spamfilter deaktiviert werden soll, müssen die entsprechenden Zeilen mit “#“ auskommentiert werden.

@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

In der Standardeinstellung wird am Beginn des Betreffs ein '***SPAM*** ' eingefügt, um Spam zu kennzeichnen. Dies kann aber durchaus lästig sein, wenn eine Email irrtümlich als Spam klassifiziert wurde. Vor allem in der Anfangszeit, wenn die Werte noch nicht an die eigenen Bedürfnisse angepasst wurden, ist es sinnvoller die Email im Header zu kennzeichen, und über entsprechende Filter in den Spam-Ordner zu verschieben.

#$sa_spam_subject_tag = '***SPAM*** ';
$sa_spam_subject_tag = undef;

In der nächsten Option wird festgelegt ab welchem Wert Informationen zum Spam-Status in den Header der Nachricht geschrieben werden. Desto höher der Wert, desto wahrscheinlicher ist die Nachricht Spam. Um die Funktion des Spamfilters zu prüfen, und die Informationen im Header bei jeder Email anzuzeigen, sollte dieser Wert zunächst sehr niedrig eingestellt werden. Dies kann nach erfolgreichen Tests wieder auf den Standardwert zurückgesetzt werden.

#$sa_tag_level_deflt  = 2.0;
$sa_tag_level_deflt = -999;

Die nächste Einstellung legt fest, ab welchem Wert eine Nachricht eindeutig (X-Spam-Flag YES) als Spam gekennzeichnet wird.

$sa_tag2_level_deflt = 6.31;

Ab welchem Wert soll AmavisNew tun, was unter $final_spam_destiny festgelegt wurde.

$sa_kill_level_deflt = 6.31;

Hier wird festgelegt, was mit Emails passieren soll, die eindeutig als Spam gekennzeichnet wurden. Um zu kontrollieren, ob die eingestellten Werte unseren Bedürfnissen entsprechen werden die Nachrichten akzeptiert, von Postfix an Dovecot ausgeliefert und vom LDA-Plugin Sieve gefiltert. Mögliche Optionen sind D_PASS3), D_BOUNCE4), D_REJECT5), D_DISCARD6).

$final_spam_destiny=D_PASS;

Ausgabe im Header der Email in Form von X-Virus-Scanned Debian amvisd-new at server.localhost.

$X_HEADER_LINE = "Debian $myproduct_name at $mydomain";

Wenn im Header trotz einer sehr niedrigen Einstellung von $sa_tag_level_deflt keine Informationen ausgegeben werden, müssen die Domains korrekt angegeben werden.

#@local_domains_acl = ( ".$mydomain" );
#@local_domains_acl = ( ".$mydomain","localhost","hostname",".domain" );
@local_domains_acl = ( "." );


Nun muss der Daemon noch neu gestartet werden, um alle Einstellungen zu übernehmen.

user@server:~$ sudo service amavis restart 

Integration in Postfix

Da alle wichtigen Einstellungen von ClamAV, SpamAssassin, AmavisNew getätigt wurden kann Postfix nun mitgeteilt werden, dass er die Emails von AmavisNew (an Port 10024) überprüfen lässt, bevor er sie wieder entgegen nimmt (an Port 10025) und an Dovecot ausliefert.

user@server:~$ sudo postconf -e content_filter=smtp-amavis:[127.0.0.1]:10024

Hinweis: Der Befehl postconf -e fügt den angebenen Parameter direkt in die Konfigurationsdatei /etc/postfix/main.cf ein, und lädt die Konfiguration von Postfix anschließend neu. Bestehende Parameter werden dabei überschrieben, was die Konfigurationsdatei einfach und frei von Redundanzen hält. Durch das automatische Einlesen der Datei wird die neue Konfiguration sofort übernommen, und die zusätzliche Eingabe von postfix reload oder service postfix reload ist nicht mehr notwendig.






user@server:~$ sudo nano /etc/postfix/master.cf 

Achtung: Die Leerzeichen am Anfang der Zeilen sind beabsichtigt und dürfen nicht entfernt werden!

Das Folgende muss am Ende der Datei hinzugefügt werden.

smtp-amavis unix -      -       n     -       2  smtp
  -o smtp_data_done_timeout=1200
  -o smtp_send_xforward_command=yes
  -o disable_dns_lookups=yes
  -o max_use=20

127.0.0.1:10025 inet n    -       n       -       -     smtpd
  -o content_filter=
  -o smtpd_delay_reject=no
  -o smtpd_client_restrictions=permit_mynetworks,reject
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o smtpd_data_restrictions=reject_unauth_pipelining
  -o smtpd_end_of_data_restrictions=
  -o smtpd_restriction_classes=
  -o mynetworks=127.0.0.0/8
  -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,no_milters
  -o local_header_rewrite_clients=
user@server:~$ sudo service postfix reload

Spam- und Virenfilter testen

Die Konfiguration ist soweit abgeschlossen. Nun sollte noch die Funktionstüchtigkeit des Mailservers überprüft werden.

user@server:~$ sudo echo "testtext" | mail -s "testbetreff" benutzername

Eine erfolgreiche Zustellung sollte etwa so aussehen.

postfix/pickup[5010]: D6D8C1FE32: uid=0 from=<root>
postfix/cleanup[5021]: D6D8C1FE32: message-id=<20110603101628.D6D8C1FE32@server.localhost>
postfix/qmgr[5008]: D6D8C1FE32: from=<root>, size=292, nrcpt=1 (queue active)
postfix/smtpd[5027]: connect from localhost[127.0.0.1]
postfix/smtpd[5027]: 0E664226D8: client=localhost[127.0.0.1]
postfix/cleanup[5021]: 0E664226D8: message-id=<20110603101628.D6D8C1FE32@server.localhost>
postfix/qmgr[5008]: 0E664226D8: from=<root>, size=906, nrcpt=1 (queue active)
amavis[4994]: (04994-01) Passed CLEAN, <root> -> <benutzer@server.localhost>, Message-ID: <20110603101628.D6D8C1FE32@server.localhost>, mail_id: h5pxwOuOL8Jd, Hits: 0, size: 292, queued_as: 0E664226D8, 3868 ms
postfix/smtp[5022]: D6D8C1FE32: to=<benutzer@server.localhost>, orig_to=<benutzer>, relay=127.0.0.1[127.0.0.1]:10024, delay=4.4, delays=0.18/0.28/0.03/3.9, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=04994-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 0E664226D8)
postfix/qmgr[5008]: D6D8C1FE32: removed
dovecot: deliver(benutzer): msgid=<20110603101628.D6D8C1FE32@server.localhost>: saved mail to INBOX
postfix/local[5015]: 0E664226D8: to=<benutzer@server.localhost>, relay=local, delay=0.1, delays=0.02/0/0/0.08, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver)
postfix/qmgr[5008]: 0E664226D8: removed


Nun versenden wir auch noch eine Spammail.

user@server:~$ sudo sendmail benutzername < /usr/share/doc/spamassassin/examples/sample-spam.txt
postfix/pickup[5010]: 86DCA226D5: uid=0 from=<root>
postfix/cleanup[5021]: 86DCA226D5: message-id=<GTUBE1.1010101@example.net>
postfix/qmgr[5008]: 86DCA226D5: from=<root>, size=935, nrcpt=1 (queue active)
postfix/smtpd[5037]: connect from localhost[127.0.0.1]
postfix/smtpd[5037]: 3253F226DF: client=localhost[127.0.0.1]
postfix/cleanup[5021]: 3253F226DF: message-id=<GTUBE1.1010101@example.net>
postfix/qmgr[5008]: 3253F226DF: from=<root>, size=1696, nrcpt=1 (queue active)
amavis[4995]: (04995-01) Passed SPAM, <root> -> <benutzer@server.localhost>, quarantine: s/spam-sTwxatzfn-i8.gz, Message-ID: <GTUBE1.1010101@example.net>, mail_id: sTwxatzfn-i8, Hits: 1004.054, size: 935, queued_as: 3253F226DF, 3700 ms
postfix/smtp[5022]: 86DCA226D5: to=<benutzer@server.localhost>, orig_to=<benutzer>, relay=127.0.0.1[127.0.0.1]:10024, delay=3.8, delays=0.09/0/0.03/3.7, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=04995-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 3253F226DF)
postfix/qmgr[5008]: 86DCA226D5: removed
dovecot: deliver(benutzer): msgid=<GTUBE1.1010101@example.net>: saved mail to INBOX
postfix/local[5011]: 3253F226DF: to=<benutzer@server.localhost>, relay=local, delay=0.28, delays=0.06/0/0/0.22, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver)
postfix/qmgr[5008]: 3253F226DF: removed

Greylisting

Greylisting ist eine einfache und ressourcenschonende Möglichkeit um Spam zu reduzieren. Dabei wird dem versendenten Mailserver beim ersten Zustellversuch eine Meldung über einen temporären Fehler übermittelt. Wenn der versendente Mailserver nach einer bestimmten Zeit erneut versucht diese Nachricht zuzustellen, wird diese und alle weiteren Nachrichten des selben Absenders akzeptiert. Diese Methode funktioniert deshalb so gut, weil viele Programme von Spamversendern nicht RFC-konform arbeiten, und somit die übermittelte Fehlermeldung ignorieren. Beim Versandt über eigene Mailserver fehlen oft Kapazitäten, um so viele (ein Großteil der ISPs verwendet Greylisting) Nachrichten erneut zuzustellen. Weiters können die Absender durch die Zeitverzögerung mit den bis dahin möglicherweise schon aktualisierten Blacklisten von z.B. SpamAssassin geblockt werden.

Hinweis: Greylisting macht nur dann Sinn, wenn der eigene Mailserver auch der direkte Empfänger einer Nachricht ist. Wenn die Nachrichten ausschließlich über einen MRA wie fetchmail abgeholt werden ist Greylisting nutzlos.

Installation von Postgrey

Mit Postgrey kann Greylisting ohne viel Aufwand auf unserem Mailserver aktiviert werden.

user@server:~$ sudo apt-get install postgrey

Konfiguration von Postgrey

Unter /etc/default/postgrey können nun die Einstellungen vorgenommen werden.

user@server:~$ sudo nano /etc/default/postgrey

Durch die Option –inet=10023 kann der verwendete Port eingestellt werden. Diesen können wir bei Bedarf ändern, und müssen uns für später merken. Mit –delay=300 können wir definieren, nach welchem Zeitraum eine erneute Zustellung frühestens akzeptiert wird. Der Zeitraum bis zu einem erneuten Zustellversuch ist dabei vom versendenten Mailserver abhängig. Weitere mögliche Optionen sind unter man postgrey ersichtlich.

# you may want to set
#   --delay=N   how long to greylist, seconds (default: 300)
#   --max-age=N delete old entries after N days (default: 35)
# see also the postgrey(8) manpage
POSTGREY_OPTS="--inet=10023 --delay=300"


Nun muss Postfix noch mitgeteilt werden, dass er Postgrey verwenden soll.

user@server:~$ sudo nano /etc/postfix/main.cf

Am Ender der Zeile von smtpd_recipient_restrictions wird nun check_policy_service inet:127.0.0.1:10023 hinzugefügt. Wenn in /etc/default/postgrey ein anderer Port definiert wurde, muss er entsprechend adaptiert werden.

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023


Um die neue Konfiguration zu übernehmen muss die Konfiguration von Postfix noch neu geladen werden.

user@server:~$ sudo postfix reload

Funktionstest von Postgrey

Im Logfile unter /var/log/mail.log sollten nun ähnliche Einträge zu sehen sein, sobald eine neue Nachricht eintrifft.

postgrey[11389]: action=greylist, reason=new, client_name=smtp.example.net, client_address=10.10.10.10, sender=absender@example.net, recipient=empfaenger@example.com
postfix/smtpd[11648]: NOQUEUE: reject: RCPT from smtp.example.net[10.10.10.10]: 450 4.2.0 <empfaenger@example.com>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/example.com.html; from=<absender@example.net> to=<empfaenger@example.com> proto=ESMTP helo=<smtp.example.net>

Wenn der sendente Mailserver es nach der eingestellten Zeit (Standardwert ist 5 Minuten) nochmals probiert, sollte eine ähnliche Meldung zu sehen.

postgrey[11728]: action=pass, reason=triplet found, delay=400, client_name=smtp.example.net, client_address=10.10.10.10, sender=absender@example.net, recipient=empfaenger@example.com

Die Serverkonfiguration ist abgeschlossen

Ja, der Mailserver wäre fertig - aber ein Mailserver ist niemals fertig, spätestens mit dem nächsten Ubuntu Update muss du dich wieder per SSH auf deinen Server verbinden und eventuell Fehler beheben.
Ein Mailserver bietet die Grundlage für viele weitere Dienste, ohne Mailserver ist eine Server kein vollständiger Server. Nun kannst du Logs, Warnungen deines Servers empfangen und unter deiner dynDNS E-Mails versenden. Falls du nun noch mehr willst, kannst du dir Cyrus anschauen, ein wesentlich komplizierter IMAP und POP3 Server.

E-Mail-Clients

Um deinen Server voll ausnutzen zu können benötigst du noch einen E-Mail-Client (auch MUA bzw. Mail User Agent genannt). Um deine Emails direkt am Server in der Konsole zu lesen eignet sich Mutt.

user@server:~$ sudo apt-get install mutt
user@server:~$ mutt

Als E-Mail-Clients für deinen Desktoprechner sind Evolution und Thunderbird zu empfehlen. Die beiden sind auch mit etwas mehr Funktionen und Komfort ausgestattet. Vergiss nicht, dass dein Postfix keine Authentifizierung benötigt, wenn du ihn richtig konfiguriert hast, Dovecot nutzt die Systempasswörter und -benutzernamen zum Login.

Natürlich kannst du zusätzlich Squirrelmail als Weboberfläche installieren, dazu gibt es eine empfehlenswerte Anleitung auf ubuntuusers.de.

Sieve-Filter mit Thunderbird verwalten

Eine bequeme Möglichkeit die Filter von Sieve aus der Ferne zu bearbeiten bietet das von Mozilla entwickelte Thunderbird-Addon Sieve. Um dem Addon den Zugriff auf die Imap-Ordner zu erlauben muss in Dovecot lediglich managesieve aktiviert werden. Dies ist im Abschnitt ManageSieve beschrieben.
Sobald das Addon in Thunderbird installiert und dieser neu gestartet wurde, erscheint dort ein weiterer Punkt in der Kontenverwaltung namens Sieve-Einstellungen. Dort muss zuerst der Punkt Ja, dieser Server unterstützt Sieve aktiviert werden, dann können auch schon die Einstellungen für das E-Mail-Konto vorgenommen werden. Das Addon verwendet in der Standardkonfiguration die selben Zugangsdaten wie das E-Mail-Konto; das sollte im Allgemeinen korrekt sein, und muss nicht verändert werden. Sobald auf Filter bearbeiten geklickt wird, versucht das Addon bereits mit dem Server Kontakt aufzunehmen. Um Fehler bei der Authentifikation leichter zu finden öffnen wir zuerst eine Konsole und überwachen das Log:

user@server:~$ tail -f /var/log/mail.log

Sollte Thunderbird beim Verbindungsversuch ein unbekanntes Zertifikat entdecken, muss dieses erlaubt werden. Danach sollte ein ähnlicher Eintrag im Log zu sehen sein:

dovecot: managesieve-login: Login: user=<benutzername>, method=PLAIN, rip=192.168.0.1, lip=192.168.0.2, TLS

Die Kommunikation zwischen unserem E-Mail-Client und dem Server funktioniert nun, und es können die ersten Filter erstellt (und aktiviert) werden. Es gelten dabei die selben Vorgaben wie hier beschrieben.


chrisge 2013/12/09 21:10

1) , 2) Informationen dazu sind in der Datei /etc/amavis/conf.d/01-debian zu finden.
3) Die Nachricht wird unabhängig vom Inhalt zum Empfänger geleitet. Falls eine Quarantäne definiert wurde wird dort eine Kopie der Nachricht gespeichert. Den Empfänger in @*_lovers_maps einzutragen ist gleichbedeutend mit der Einstellung $final_*_destiny = D_PASS;.
4) Die Nachricht wird dem Empfänger nicht zugestellt. Eine Benachrichtigung über die nicht erfolgte Zustellung (non-delivery notification) wird von amavisd-new erstellt und dem Absender zugesandt. Ausnahmen: Eine Benachrichtigung (delivery status notification) wird nicht versandt, wenn die Email mit einem Virus infiziert ist, der unter @viruses_that_fake_sender_maps eingetragne wurde, oder wenn die Nachricht von einer Mailingliste (Precedence: bulk|list|junk) stammt, oder wenn der Spamwert den in $sa_dsn_cutoff_level definierten Wert übersteigt. Wenn eine Quarantäne definiert wurde, wird dort eine Kopie der Nachricht gespeichert. Falls keine Quarantäne definiert wurde ist die Nachricht verloren, dem Absender wurde jedoch eine Benachrichtigung über die nicht erfolgte Zustellung gesendet.
5) Die Email wird dem Empfänger nicht zugestellt. Amavisd-new weist die Nachricht mit einer typischen 550 oder 554 Meldung (reject response) zurück. Der versendende MTA kann daraufhin eine entsprechende Benachrichtigung verfassen (reject notice), und an den Absender schicken. Diese Benachrichtigung ist nicht so informativ als jene die amavisd-new mit der Option D_BOUNCE verfassen würde. Deshalb ist D_BOUNCE gegenüber D_REJECT bevorzugt. Wenn amavisd-new als vorgezogener Proxy-Filter verwendet wird, sollte D_BOUNCE nicht gegenüber D_REJECT bevorzugt werden, aber das wird weder empfohlen, noch wird es unterstützt. Grundsätzlich ist D_DISCARD hier die beste Option, da eine Benachrichtigung an den Absender bei einer Spammail meistens nicht zustellbar ist, oder schlimmer, der Absender ist vorhanden, wurde jedoch gefälscht. Wenn eine Quarantäne definiert wurde, wird dort eine Kopie der Nachricht gespeichert. Falls nicht ist die Nachricht verloren, aber der Absender wurde informiert, dass die Nachricht zurückgewiesen wurde.
6) Die Email wird nicht an den Empfänger zugestellt und der Absender wird für gewöhnlich NICHT benachrichtigt. Wenn eine Quarantäne definiert wurde, wird dort eine Kopie der Nachricht gespeichert. Falls nicht ist die Nachricht verloren. Es gibt jedoch zusätzliche Einstellungen, welche es ermöglichen eine Benachrichtigung an den Absender zu verschicken, dass eine unerwünschte Nachricht gefunden wurde.

Diskussion

Christoph Winklerchrisge, 2012/08/20 02:15

[20.08.2012] Änderungen:

  • an Dovecot 2.x angepasst
  • Formatierung überarbeitet
  • sonstige kleine Fehler beseitigt
Martin Guest, 2013/02/04 22:15

Erstmal danke für das ausführliche how to Hab eine frage: ich benutze no-ip als Dynamic ip Ist im Router eingetragen geht alles ohne Probleme Hab eine Domain bei 1und1 via cname auf die no-ip Adresse geleitet Apache, FTP geht alles… Könnte ich jetzt mit dieser Anleitung Emails von meiner 1und1 Domain über meinen server verschicken z.B User1@meinedomain.com ?

Christoph Winklerchrisge, 2013/02/04 22:37

Ja, das wäre prinzipiell möglich :-)
Wenn du aber eh eine Domain bei 1und1 hast, könntest du da mal schauen, ob du da einen Relay-Zugang bekommst. Das wäre dann eine wesentlich schönere Lösung (im Vergleich zu Absender fälschen über Arcor).

MartinGuest, 2013/02/05 16:58

Erstmal Danke für die schnelle Antwort . Kla wäre es mir lieber die Mails über den richtigen 1und1 Server laufen zu lassen (oder wie meinßt du das?) Aber sobald man da die DNS Einstellung ändert funktsioniern die Email konnten nicht mehr. Wenn ich also den Mail Server über meine Domain laufen lasse muss ich dann hier bei der Anleitung noch irgendetwas beachten?

MartinGuest, 2013/02/05 17:24

Also ich nehme den relay-Zugang von arcor

Christoph Winklerchrisge, 2013/02/05 18:40

Ich würde den SMTP-Relay (also den Postausgangsserver) von 1und1 statt den von Arcor nehmen. Das geht natürlich nur, wenn das in deinem Tarif auch inbegriffen ist. Dann könntest du die Mails über den Postausgangsserver von 1und1 verschicken und mit deinem Server für deine Domain empfangen.
Wenn du statt dessen lieber komplett den Mailservice von 1und1 verwenden möchtest (1und1 empfängt dann auch deine Mails), müsstest du die MX Records so wie ursprünglich lassen oder falls das nicht geht an die vorgeschlagenen Settings von 1und1 anpassen. Die E-Mail Konten bei 1und1 müssten dann eigentlich auch wieder funktionieren (bei Domainfactory ist es zumindest so).

Würdest du trotzdem diese Anleitung nehmen, gäbe es zusätzlich eigentlich nichts zu beachten :-)

EinNeulingGuest, 2013/06/10 14:16

Tolle Anleitung! Vielen lieben Dank! :-)

Christoph Winklerchrisge, 2013/06/10 17:44

Keine Ursache ;-)

rogerGuest, 2013/08/03 13:22

Auch von mir Daumen hoch. Sensationell umfangreich beschrieben.

Ich hätte noch eine winzige Frage. Auf meinem lokalen Server (mit einem Forum) sollen überhaupt keine Mails empfangen werden. Ich möchte nur, dass der Server mir und angemeldeten Nutzern über meinen Relay-Account Benachrichtigungen schickt.

Mein Ansatz wäre in der PF Config

inet_interfaces = 127.0.0.1

zu verwenden.

Wenn ich es richtig verstehe, sollte das genau dazu führen, dass außer vom localhost keine Mails mehr empfangen werden.

Vielen Dank für die Mühe. 8-)

Christoph Winklerchrisge, 2013/08/03 17:40

inet_interfaces = 127.0.0.1 würde dazu führen, dass Postfix nur auf 127.0.0.1 lauscht. Dann können keine Mails von außerhalb mehr empfangen werden, weil der SMTP Port dann zu ist. Das ist nur dann wirklich sinnvoll, wenn der MX der verwendeten Absenderdomain auf ein anderes Ziel verweist. Ansonsten hast du Probleme, wenn mal eine Mail zurückkommt (z.B. weil nicht zustellbar). Wenn dein System hinter einer Firewall sitzt, kannst du dort auch einfach den SMTP Port schließen – hat den gleichen Effekt.
Wenn du statt dessen festlegen willst, für welche Domains Mails angenommen werden sollen, kannst du dies mit mydestination = host1, host2, … konfigurieren.

MarcusGuest, 2013/08/13 10:00

Super Tutorial - das beste, was mir zu Mailserver bislang untergekommen ist. Ich habe soeben - dank Deiner Anleitung - die gesamte Config auf meinem raspberrypi zum Laufen gebracht, und hoste jetzt meine Mails zuhause (NSA lässt grüßen), rufe sie per fetchmail dann immer direkt von meinem eigentlichen Hoster (V-Server) und lösche sie dort.

Ich habe allerdings noch eine Frage: Ich würde natürlich auch gerne von extern (über meinen Dyndns) Mails an Postfix verschicken. Leider ist bislang nur Port 25 offen. Und das ist natürlich schlecht.

Wie bekomme ich das verschlüsselt auf Port 465 oder 587 umgebogen?

Marcus

Christoph Winklerchrisge, 2013/08/13 17:20

Vielen Dank für das Lob!
Ich habe den Abschnitt Verschlüsselung bei Postfix mal passend erweitert, daraus müsste jetzt klar werden, wie du TLS/SSL over SMTP erzwingen kannst, SMTPS (Port 465) ist eigentlich nicht mehr nötig.

TimGuest, 2013/08/17 23:07

extrem gutes tutorial . allerdings ist der letzte teil nicht gaaaanz komplett. du gehst da nur auf dovecot 1.x ein nicht auf 2.x. In 2 gibt es die zeilen so nicht mehr

# Protocols we want to be serving: imap imaps pop3 pop3s managesieve
# If you only want to use dovecot-auth, you can set this to "none".
#protocols = imap imaps
protocols = imap imaps pop3 pop3s managesieve

statdessen muss in der datei “/usr/share/dovecot/protocols.d/managedsieve.potocols“ das managedsieve eingetragen werden

Christoph Winklerchrisge, 2013/08/18 05:13

Vielen Dank für das Lob und vor allem für den Hinweis!
Im letzten Teil (den zu Thunderbird?) hat sich tatsächlich ein Fehler eingeschlichen. Im oberen Teil der Anleitung wurde managesieve bereits an Dovecot 2.x angepasst – im unteren Teil aber nicht.
Allerdings müsste normalerwiese keine Anpassung der /usr/share/dovecot/protocols.d/managedsieve.potocols nötig sein, sondern nur eine Installation von dovecot-managsieved (siehe hier). Oder funktioniert managesieve bei dir nur nach Anpassung der erwähnten Datei?

TimGuest, 2013/08/18 21:23

habe roundcube installiert und da funktionierte das nur wenn ich die datei editiert habe. vorher stand nur „sieve“ drinn. allerdings musste ich noch mehr editieren und kann aus diesem grund nicht genau sagen ob das managedsieve in der datei nötig war oder nicht

Christoph Winklerchrisge, 2013/08/19 00:36

Mhh, seltsam. Ich finde in keiner Doku ein Verweis auf /usr/share/dovecot/protocols.d/managedsieve.potocols. Auch kommt es mir höchst seltsam vor eine Datei in /usr/share/ für einen solchen Zweck zu editieren. Wenn ich in nächster Zeit Hinweise über die Notwendigkeit der Veränderung dieser Datei erhalte, werde ich's in die Anleitung aufnehmen.
dovecot-managesieved hast du aber installiert?

MarcusGuest, 2013/08/18 02:59

Und noch eine kleine Ergänzung im Zusammenhang mit managesieve und dovecot 2:
Damit managesieve vernünftig läuft sollten bei dovecot 2 in der
/etc/dovecot/conf.d/15-lda.conf
die Zeilen

# Should saving a mail to a nonexistent mailbox automatically create it?
lda_mailbox_autocreate = yes

# Should automatically created mailboxes be also automatically subscribed?
lda_mailbox_autosubscribe = yes

AUSKOMMENTIERT werden, ansonsten kann sieve keine entsprechenden Unterordner anlegen.

Christoph Winklerchrisge, 2013/08/18 05:23

Vielen Dank! Ich hab das mal als optionalen Punkt eingepflegt.

MarcusGuest, 2013/08/18 10:07

Nochmals danke für das feine Tutorial. Ich hätte das nie so gut hinbekommen, ich habe schon für diesen Fall echt das Internet durchforstet. Ich setze Deine Config auf einem raspberryPi ein, meine Mails hole und lösche ich gleich per fetchmail bei meinem Provider (V-Server von Strato). Alle meine Clients (Rechner, Tablet, Smartphone) greifen via Dyndns auf den kleinen raspberry zu (mit 32GB Karte). Der Versand von Emails erfolgt wieder direkt über den Provider, und da ich das imap Proto verwenden, werden sie auch sauber im „Sent“ Ordner einsortiert. Nachts wird ein Image von der der raspberry Karte auf mein Nas gezogen, alle paar Stunden werden die Maildir Verzeichnisse ebenso auf mein Nas kopiert. Sieve habe ich erst dank Deines Tuotorials kennengelernt.

Also: Nochmals fetten Dank!

Christoph Winklerchrisge, 2013/08/18 22:34

Freut mich, dass das Tut dir weitergeholfen hat :-)

TimGuest, 2013/08/18 22:54

habe gerade noch eine Ergänzung entdeckt:

Port 25 weiterzuleiten reicht nicht wenn auch Mails empfangen werden sollen.Zum Empfangen muss auch port 143 (imap) freigegeben werden, sonst funktionieren z.B. Outlook oder Outlook-Express nicht. Die Programme können sonst nur senden aber nicht empfangen.

Christoph Winklerchrisge, 2013/08/19 00:23

Zum Empfangen von Mails muss auf dem Router definitiv nur Port 25 auf den Server weitergeleitet werden, also nach „außen“ offen sein. Der Client braucht selbstverständlich Zugriff auf IMAP und SMTP, sonst kann er entweder nur Mails abrufen oder verschicken. Ich gehe in dem Tut davon aus, dass der Client im internen Netzwerk sitzt, ansonsten muss natürlich noch 143 geöffnet/weitergeleitet werden.

timGuest, 2013/08/19 08:38

das ist es ja wenn ich auf dyndns weiterleite geht alles übers i-net und nicht übers netzwerk. ich trag ja auch meine dyndns weiterleitung in den clienten ein. ohne dyndns muss ich nichtmal port 25 freigeben geht ja dann auch über das netzwerk oder hab ich da nen denkfehler ??? hier gings mit outlook nur wenn ich auch port 143 öffne, obwohl der server im netzwerk sitzt.

Christoph Winklerchrisge, 2013/08/19 20:57

In den Clienten kannst du einfach die interne IP des Servers eintragen (wenn sie im gleichen Netzwerk hocken). Dann musst du im Router nur Port 25 öffnen. Der SMTP-Port (Port 25) muss offen sein damit der Server unter der DynDNS Mails empfangen kann.
Du kannst natürlich auch in den Clients die DynDNS verwenden, was aber nur Sinn macht, wenn sie nicht im lokalen Netz hocken. In diesem Fall muss im Router dann aber Port 25 und 143 offen sein.

timGuest, 2013/08/19 23:42

ok dann passt es wenn ich die ports beide öffne meine abfrage erfolgt per handy mal per wlan mal per i-net und deswegen im clienten auch für ein und ausgang die dyndns. thx. wenn ich jetzt noch das icinga hinbekomme mit 8 servern bin ich glücklich *gg*

OlliPGuest, 2013/09/07 16:16

Eine prima Anleitung… Bislang habe ich alles bis FETCHMAIL (einschließlich) installiert. Fetchmail holt aber keine Nachrichten ab. Der Start kann nur über /etc/default/fetchmail start erfolgen. Ich bekomme aber keine Nachricht. Nur der nächste Prompt/Eingabe-Aufforderung erscheint. Hast du eine Idee?

Vielen Dank schon einmal Gruß OlliP

Christoph Winklerchrisge, 2013/09/08 15:15

Probiere mal einen Debug Run mit sudo service fetchmail debug-run. Holt fetchmail dann Mails ab bzw. enthält die Ausgabe Fehlermeldungen?

OlliPGuest, 2013/09/08 18:13

Hi chrisge,
also der Start vom Fetchmail sieht wie folgt aus:

sudo /etc/init.d/fetchmail start
Edit /etc/default/fetchmail to start/stop fetchmail
sudo /etc/default/fetchmail debug-run start

gibt keine Ausgabe - holt aber auch keine Mails ab
Was kann ich tun??

Gruß
OlliP

Christoph Winklerchrisge, 2013/09/08 22:02

Bei /etc/default/fetchmail handelt es sich um eine Konfigurationsdatei und kein Init-Skript! Damit ist klar, warum fetchmail nicht startet. Du müsstest eigentlich (wenn du die Datei nicht schon ausführbar gemacht hast, was nicht empfehlenswert ist) command not found als Ausgabe erhalten.
Wenn du fetchmail starten willst, musst du dies so tun:

sudo /etc/init.d/fetchmail start      # früher so
sudo service fetchmail start          # mittlerweile so

Ich hatte folglich

sudo /etc/init.d/fetchmail debug-run

gemeint (ohne start dahinter).
Anhand der Ausgabe von /etc/init.d/fetchmail start kann ich allerdings das Problem erkennen – ändere in der /etc/default/fetchmail folgenden Abschnitt von

START_DAEMON=no

auf

START_DAEMON=yes

Anschließend müsstest du fetchmail mit

sudo service fetchmail start

starten können. Das ist im Abschnitt Fetchmail als Daemon übrigens exakt so beschrieben ;-)

OlliPGuest, 2013/09/10 08:26

Hallo chrisge,

vielen Dank für die Antwort. Das fetchmail-Problem ist gelöst… aktuell geht es aber nicht weiter.

Vielen Dank - nochmals

Gruß

OlliP

le_petitGuest, 2013/11/21 23:06

wie muss die sasl_password aussehen, wenn ich 2 user auf meinem Mailserver habe und jeder eine andere gmx-adresse als Absender verwenden möchte?

Gruß LP

Christoph Winklerchrisge, 2013/11/22 20:23

Für dein Problem gibt es zwei Lösungen:

  • Du bearbeitest wie im Abschnitt Absender setzen beschrieben die /etc/postfix/sender_canonical. Auf diese Weise werden die Absender der beiden User „gefälscht“, d.h. im Absender steht nicht mehr der Arcor-Account (dient in dieser Anleitung als SMTP-Relay) über den die E-Mail versendet wurde, sondern der GMX-Account des jew. Benutzers. Das funktioniert in der Regel aber recht gut. Nachvollziehen kann das der Empfänger z.B. anhand des Headers der Mail.
  • Aufwändiger wird es, wenn du die Mails der User jew. über einen anderen GMX-Account (also Relayhost) leiten willst. Sodass „wahre“ Absenderadresse und Absenderadresse übereinstimmen. Dazu liefert die Google zum Stichwort Postfix Multiple Relayhosts z.B. Multiple SMTP Relay oder Using Separate SMTP Gateways based on Email Domains.

Die erste Methode ist in dieser Anleitung ausführlich beschrieben. Die zweite Variante kann ich dir nur empfehlen, wenn die Mails der User auch wirklich über GMX gehen müssen. Also das Fälschen der Absender für dich ausgeschlossen ist.

le_petitGuest, 2013/12/04 21:26

Danke für dein Input. Ich habe es jetzt nach folgender Anleitung fast gelöst: Sender-abhängige Authentifizierung

Das funktioniert alles super von lokal aus. Sobald ich mich mit meinem Laptop über meine dyndns.org eine Mail verschicken will, bekomme ich folgenden Eintrag im Log:

NOQUEUE: reject: RCPT from XYZ.t-ipconnect.de[XXX.XXX.XXX.XXX]: 554 5.7.1 <XXXX@web.de>: Relay access denied; from=<XXX@gmx.de> to=<XXX@web.de> proto=ESMTP helo=<[192.168.178.20]>

Wenn ich im lokalen Netz mich mit Thunderbird oder Icedove mit Dovecot verbinde kann ich Mails von beiden „Mailkonten“ verschicken. Hier noch meine main.cf:

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

myhostname = rpi2.fritz.box
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = XXX.dyndns.org, rpi2.fritz.box, localhost.fritz.box, localhost, 192.168.178.7, 127.0.0.1
relayhost = mail.gmx.net
mynetworks = 127.0.0.0/8, 192.168.178.0/24
mailbox_size_limit = 0
message_size_limit = 52428800
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
##########
smtp_sender_dependent_authentication = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_connection_cache_on_demand = no
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_dependent
sender_canonical_maps = hash:/etc/postfix/sender_canonical
mailbox_command = /usr/lib/dovecot/deliver

An was kann es liegen?

Christoph Winklerchrisge, 2013/12/04 22:48

Das liegt daran, dass du mynetworks auf 127.0.0.0/8, 192.168.178.0/24. D.h. wenn doch dich in deinem lokalen Netz (192.168.178.0/24) befindest, kannst du Mails ohne Authentifizierung verschicken. Von extern geht das natürlich nicht (und sollte auch nicht), da du ansonsten ein offenes Relay hättest (jeder könnte Mails über deinen Mailserver verschicken).
Entweder legst du dir ein VPN zu (z.B. OpenVPN) und trägst das dem entsprechende Netz in mynetworks ein (natürlich muss sich dein Laptop dann in das VPN einwählen) oder du richtest eine SASL-Authentifizierung in Postfix ein. In dem verlinkten Ubuntuusers.de Wikieintrag wird darauf sogar eingegangen – allerdings mit dem Hinweis, dass dieser Abschnitt der Anleitung veraltet ist.

le_petitGuest, 2013/12/05 09:14

Was meinst du mit „ohne Authentifizierung“? Letztendlich logge ich mich mit dem Mailprogramm per Nutzername und Passwort an. Ich hatte einen Test auf „offenes Relay“ durchgeführt. Die Aussage war, ich hätte kein offenes Relay. GMX lässt sowieso keine „alternativen“ Absender zu!

Christoph Winklerchrisge, 2013/12/06 19:32

Falls du zusätzlich zu dieser Anleitung nichts weiter konfiguriert hast (außer der Relay Geschichte), geschieht die Authentifizierung bei Postfix via IP-Adresse. D.h. Postfix überprüft ob deine IP mit der in mynetworks eingetragenen Hosts/Subnets übereinstimmt. Wenn dies der Fall ist, kann dieser Rechner Mail über deinen Server verschicken und zwar ohne Benutzerauth (probiers mal aus, Postfix wird bei Mail aus deinem lokalen Netz keinen User/Passwort fordern).
Du müsstest nun SASL-Authentifizierung in Postfix konfigurieren, dann könnte sich dein Laptop (und jeder externe Rechner) wie in Dovecot mit Benutzername und Passwort authentifizieren und anschließend Mail versende.

blppGuest, 2013/12/07 21:20

Klasse Anleitung, die endlich mal funktioniert und alles, was man für einen Mailserver braucht, auch enthält und genau erklärt.

Habe alles auf einem Raspberry Pi installiert und läuft hervorragend. Mails werden mit Fetchmail von div. Providern abgeholt, über Postfix an Dovecot weitergeleitet. Das kann ich dann entweder mit Roundcube oder Thunderbird öffnen und über verschiedene Identitäten (also die verschiedenen Provider) Mails versenden.

DANKE!

MDegelmannGuest, 2013/12/08 14:12

Hallo Super tut.

ist das erste das auch alles enthält was ich schon lange gesucht habe.

Habe aber ein Probelm mit dem Managesieve habe ich genau an deine anleitung gehalten und benutze Thunderbird aber es tut sich nichts erhalte auch keine mitteilung im log das versucht wird eine verbindung aufzubauen.

benutze Dovecot 2.xxx habe Dovecot-managesieved aber geht nichts :(

Christoph Winklerchrisge, 2013/12/09 18:35

Welche Debian Version/welches Release verwendest du? Funktioniert Sieve, wenn du wie in der Anleitung beschrieben testweise eine .dovecot.sieve mit ein paar Regeln anlegst? Was spuckt dir folgender Befehl aus?

user@server:~$ dpkg -l | grep dovecot
MDegelmannGuest, 2013/12/09 19:33

Benutze Debian Linux 7.2

Sieve geht mit deiner anleitung ohne probleme und ordnet die Mails richtig zu so funtioniert alles

es geht nur das bearbeiten der .dovecot.sieve liste über Thunderbird nicht :(

user@server:~$ dpkg -l | grep dovecot

bekomme ich das zurück

ii  dovecot-common                        1:2.1.7-7                              all          Transitional package for dovecot
ii  dovecot-core                          1:2.1.7-7                              armhf        secure mail server that supports mbox, maildir, dbox and mdbox mailboxes
ii  dovecot-gssapi                        1:2.1.7-7                              armhf        GSSAPI authentication support for Dovecot
ii  dovecot-imapd                         1:2.1.7-7                              armhf        secure IMAP server that supports mbox, maildir, dbox and mdbox mailboxes
ii  dovecot-ldap                          1:2.1.7-7                              armhf        LDAP support for Dovecot
ii  dovecot-managesieved                  1:2.1.7-7                              armhf        secure ManageSieve server for Dovecot
ii  dovecot-mysql                         1:2.1.7-7                              armhf        MySQL support for Dovecot
ii  dovecot-pgsql                         1:2.1.7-7                              armhf        PostgreSQL support for Dovecot
ii  dovecot-pop3d                         1:2.1.7-7                              armhf        secure POP3 server that supports mbox, maildir, dbox and mdbox mailboxes
ii  dovecot-sieve                         1:2.1.7-7                              armhf        sieve filters support for Dovecot
ii  dovecot-sqlite                        1:2.1.7-7                              armhf        SQLite support for Dovecot
Christoph Winklerchrisge, 2013/12/09 21:10

Die Pakete hast du alle installiert und ich nehme mal an, dass die Configs auch alle passen. Ich hab das jetzt mal versucht auf Wheezy (auf einem Raspberry Pi) nachzuvollziehen und habe festgestellt, dass die Pakete wie oben in der Anleitung erwähnt ohne modprobe ipv6 gar nicht richtig konfiguriert werden. Falls dir die /etc/dovecot/conf.d/20-managesieve.conf fehlt, solltest du mal folgendes machen:

user@server:~$ sudo modprobe ipv6
user@server:~$ sudo apt-get -f install

Anschließend müsste Dovecot auf Port 4190 lauschen:

user@server:~$ sudo netstat -tulpen | grep 4190
tcp        0      0 0.0.0.0:4190            0.0.0.0:*               LISTEN      0          98074       9379/dovecot    
tcp6       0      0 :::4190                 :::*                    LISTEN      0          98075       9379/dovecot

…und die Geschichte funktionieren. Wenn nicht, könntest du mir die Ausgabe von doveconf -n oder doveconf -a zukommen lassen, aber bitte über Pastebin oder ähnliches (auf Grund der Länge nicht hier posten).

MDegelmannGuest, 2013/12/09 21:59

Also habe es jetzt mal versucht

aber dennoch kein nen zugriff sehe in der log datei

Dovecot -n und . -a habe ich mal als text in meine cloud geladen link anklicken müsste gehen

https://dl.dropboxusercontent.com/u/57730789/Dovecot/Dovecot%20-a.txt https://dl.dropboxusercontent.com/u/57730789/Dovecot/Dovecot%20-n.txt

Christoph Winklerchrisge, 2013/12/10 19:09

Seltsam, die Configs passen eigentlich. War die /etc/dovecot/conf.d/20-managesieve.conf nun vorhanden oder hattest du auch die Probleme mit den unkonfigurierten Paketen?
Könntest du die Ausgabe von folgendem Befehl posten:

user@server:~$ sudo netstat -tulpen | grep dovecot
MDegelmannGuest, 2013/12/10 19:15

Hallo

verstehe das selber auch nicht habe heute nochmal alles durch gesehen :(

Also ich habe die 20-managesieve.conf ist aber alles auskommentiert habe aber keine ahnung was wo angemacht werden muss :(

hier die ausgabe vom „user@server:~$ sudo netstat -tulpen | grep dovecot“

tcp        0      0 0.0.0.0:4190            0.0.0.0:*               LISTEN      0          3002        2342/dovecot
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN      0          3050        2342/dovecot
tcp        0      0 0.0.0.0:995             0.0.0.0:*               LISTEN      0          3026        2342/dovecot
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      0          3024        2342/dovecot
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      0          3048        2342/dovecot
tcp6       0      0 :::4190                 :::*                    LISTEN      0          3003        2342/dovecot
tcp6       0      0 :::993                  :::*                    LISTEN      0          3051        2342/dovecot
tcp6       0      0 :::995                  :::*                    LISTEN      0          3027        2342/dovecot
tcp6       0      0 :::110                  :::*                    LISTEN      0          3025        2342/dovecot
tcp6       0      0 :::143                  :::*                    LISTEN      0          3049        2342/dovecot
Christoph Winklerchrisge, 2013/12/11 20:02

Die Ports passen, eigentlich müsste es gehen. Bist du sicher, dass du den Client richtig konfiguriert hast? Du könntest testweise in der /etc/dovecot/conf.d/20-managesieve.conf alle Zeilen, bei denen nach dem Kommentar kein Leerzeichen auskommentieren, sodass die Datei dann in etwa so aussieht und Dovecot neustarten.
Zu Dovecot und managesieve findet sich leider kaum Doku im Netz. Ich hab noch folgendes gefunden. Die dortigen Änderung könntest du in deine /etc/dovecot/conf.d/20-managesieve.conf einpflegen. Falls das alles nichts bringt und dir die Lösung des Problems am Herzen liegt, kannst du dich gerne bei mir via Jabber, Mail oder Skype melden (wirkliches Debugging geht so einfacher/schneller).

MDegelmannGuest, 2013/12/11 20:18

ok ich werde das morgen mal testen und melde mich wieder bei dir muss erst mal Arbeiten gehen :(

bis Morgen dann

PS Skype ist eftl besser kann man sowas echt besser machen.

zilleGuest, 2014/03/13 20:58

das versteht doch kein mensch, wieviel ist das nur um mails senden emfangen zu können, ich steige da nirgendswo hinter.

Christoph Winklerchrisge, 2014/03/14 00:07

Und das soll mir jetzt was bringen? Wie wäre es, wenn du konkrete Fragen stellen würdest?
Um mit eigenem Server Mail senden und empfangen zu können, brauchst du (in der Minimalkonfiguration) eigentlich nur Dovecot und Postfix. Auf einem Server mit fester IP, ist die Konfiguration von Postfix sogar noch einfacher. Wenn du da aber wie aus deinem überflüssigem Kommentar ersichtlich „nirgendwo hinter[steigst]“ wäre es vielleicht besser dich ordentlich in die Materie einzulesen oder die Sache einfach zu lassen, bevor ne weitere Spamschleuder am Netz hängt ;-)

le_petitGuest, 2014/06/11 21:20

Dank deiner Anleitung läuft mein Mailserver perfekt auf dem Raspberry Pi.

Heut klappt das Versenden über gmx.de nicht oder nur ab und zu (web.de geht), (SASL authentication failed; server mail.gmx.net[212.227.17.190] said: 454 Temporary authentication failure) und postfix wiederholt ständig den Versand. Hier meine Frage, wie oft macht das Postfix? Was passiert, wenn Postfix die Mail nicht zustellen kann? Sehe ich das nur im mail.log?

Christoph Winklerchrisge, 2014/06/12 20:08

Die Mail landet dann in der Mail Queue, deren Inhalt du mit mailq oder postqueue -p abfragen kannst. Postfix wird bei einem Zustellfehler in bestimmten Abständen wieder versuchen, die Mail zuzustellen.
Einzelne Mails kannst du dann mit postsuper -d ID aus der Warteschlange löschen. Mit postqueue -f zwingst du Postfix die Mails zu versenden.

theMarioGuest, 2014/06/12 20:28

Hallo,

Auch 2014 läuft es mit der Anleitung wunderbar. Mein rPi bekommt das alles hin, aber, ich wäre ja nicht am schreiben, hätte ich nicht ein Problem. Zwischen dem Abholen von Mails bei und dem Ablegen in ~/Maildir vergehen drei Stunden. Allerdings betrifft das nicht alle Mailuser. Fetchmail rackert sich ab und postfix scheint auf der faulen Haut zu liegen. Am Ende liegt es ohnehin an mir. Bin mit Sicherheit nur zu blind zum Lesen heute. Also, wer nimmt mich mal bitte bei der Hand und stubbst meine Nase auf die Lösung, die ich blindes Huhn nicht finde.

Danke.

Christoph Winklerchrisge, 2014/06/14 12:07

Gibt es eine Gemeinsamkeit der betroffenen User (gleicher Mail-Anbieter, …)? In diesem Zusammenhang ist natürlich das mail.log äußerst interessant. Was findet sich darin, wenn fetchmail Mail eines prolematischen Users abholt? Mit sudo service fetchmail debug-run wird fetchmail noch redseliger.

theMarioGuest, 2014/06/15 01:51

Guten Abend,
leider habe ich deine Nachricht zu spät gesehen und bin aktuell nicht zu Hause. Ich kann wohl meinen rPi via vpn besuchen und ihn ein paar Fragen via putti stellen, jedoch kann ich von hier aus (wlan mit gesperrten Ports^^ - ein Schelm, der jetzt denkt, was er denkt… ) keine Mails versenden und die Person, welche sich selbst eine Mail schicken könnte, liegt im Schlummerland und wie das so ist, man muß ja immer lieb sein… .
Ansonsten, wie im (geänderten Logausschnitt - Mailadressennamen Usernamen SubdomainName ) zu erkennen ist, ist der Mailanbieter der Gleiche.

Mir ist auch nur eine abweichende Zeile aufgefallen. Die Ursache kann ich nicht nachvollziehen, da beide User eigentlich alles gleich eingestellt haben, bzw. ich nicht weiß, wo ich da noch etwas ändern könnte. Schau selbst.

Jun 10 06:07:32 rpi fetchmail[3207]: 925 messages (925 seen) for GUTER.USER@freenet.de at mx.freenet.de (30760126 octets).
Jun 10 06:07:34 rpi fetchmail[3207]: 29 messages (28 seen) for PROBLEM.USER@freenet.de at mx.freenet.de (2670399 octets).
Jun 10 06:07:34 rpi postfix/smtpd[5484]: connect from localhost[::1]
Jun 10 06:07:34 rpi postfix/smtpd[5484]: 92AC65E824: client=localhost[::1]
Jun 10 06:07:34 rpi postfix/cleanup[5488]: 92AC65E824: message-id=<2.1.1.36484.13517034.48200734348@mail.eltern.de>
Jun 10 06:07:34 rpi fetchmail[3207]: reading message PROBLEM.USER@freenet.de@mx.freenet.de:29 of 29 (18475 octets) not flushed
Jun 10 06:07:34 rpi postfix/qmgr[3162]: 92AC65E824: from=<community@mail.eltern.de>, size=18853, nrcpt=1 (queue active)
Jun 10 06:07:34 rpi postfix/smtpd[5484]: disconnect from localhost[::1]
Jun 10 06:07:34 rpi dovecot: lda(PROBLEM.USER-User.Name): msgid=<2.1.1.36484.13517034.48200734348@mail.eltern.de>: saved mail to INBOX
Jun 10 06:07:34 rpi postfix/local[5489]: 92AC65E824: to=<PROBLEM.USER-User.Name@localhost>, relay=local, delay=0.54, delays=0.27/0.07/0/0.2, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver -c /etc/dovecot/conf.d/01-mail-stack-delivery.conf -m "${EXTENSION}")
Jun 10 06:07:35 rpi postfix/qmgr[3162]: 92AC65E824: removed
Jun 10 06:08:36 rpi fetchmail[3207]: 925 messages (925 seen) for GUTER.USER@freenet.de at mx.freenet.de (30760126 octets).
Jun 10 06:08:38 rpi fetchmail[3207]: 29 messages (29 seen) for PROBLEM.USER@freenet.de at mx.freenet.de (2670411 octets)

Jun 10 06:46:33 rpi fetchmail[3207]: 925 messages (925 seen) for GUTER.USER@freenet.de at mx.freenet.de (30760126 octets).
Jun 10 06:46:34 rpi fetchmail[3207]: 29 messages (29 seen) for PROBLEM.USER@freenet.de at mx.freenet.de (2670411 octets).
Jun 10 06:47:36 rpi fetchmail[3207]: 926 messages (925 seen) for GUTER.USER@freenet.de at mx.freenet.de (30778554 octets).
Jun 10 06:47:36 rpi postfix/smtpd[5788]: connect from localhost[::1]
Jun 10 06:47:36 rpi postfix/smtpd[5788]: C9D465E933: client=localhost[::1]
Jun 10 06:47:36 rpi postfix/cleanup[5792]: C9D465E933: message-id=<2.1.1.36484.13517034.48200856367@mail.eltern.de>
Jun 10 06:47:36 rpi fetchmail[3207]: reading message GUTER.USER@freenet.de@mx.freenet.de:926 of 926 (18428 octets) not flushed
Jun 10 06:47:36 rpi postfix/qmgr[3162]: C9D465E933: from=<community@mail.eltern.de>, size=18802, nrcpt=1 (queue active)
Jun 10 06:47:37 rpi postfix/smtpd[5788]: disconnect from localhost[::1]
Jun 10 06:47:37 rpi dovecot: lda(GUTER.USER-User.Name): msgid=<2.1.1.36484.13517034.48200856367@mail.eltern.de>: saved mail to INBOX
Jun 10 06:47:37 rpi postfix/local[5793]: C9D465E933: to=<GUTER.USER-User.Name@mail.Subdomain.no-ip.org>, orig_to=<GUTER.USER-User.Name@localhost>, relay=local, delay=0.54, delays=0.21/0.06/0/0.26, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver -c /etc/dovecot/conf.d/01-mail-stack-delivery.conf -m "${EXTENSION}")
Jun 10 06:47:37 rpi postfix/qmgr[3162]: C9D465E933: removed
Jun 10 06:47:38 rpi fetchmail[3207]: 29 messages (29 seen) for PROBLEM.USER@freenet.de at mx.freenet.de (2670411 octets).
Jun 10 06:48:40 rpi fetchmail[3207]: 926 messages (926 seen) for GUTER.USER@freenet.de at mx.freenet.de (30778566 octets).
Jun 10 06:48:41 rpi fetchmail[3207]: 29 messages (29 seen) for PROBLEM.USER@freenet.de at mx.freenet.de (2670411 octets).

Die Unterchiede sind hier. Jedoch … bringt mir das den Umstand, das ein User seine Mails gleich bekommt, und der Andere drei Stunden später?

Jun 10 06:07:34 rpi postfix/local[5489]: 92AC65E824: to=<PROBLEM.USER-User.Name@localhost>, relay=local, delay=0.54, delays=0.27/0.07/0/0.2, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver -c /etc/dovecot/conf.d/01-mail-stack-delivery.conf -m "${EXTENSION}")
Jun 10 06:47:37 rpi postfix/local[5793]: C9D465E933: to=<GUTER.USER-User.Name@mail.Subdomain.no-ip.org>, orig_to=<GUTER.USER-User.Name@localhost>, relay=local, delay=0.54, delays=0.21/0.06/0/0.26, dsn=2.0.0, status=sent (delivered to command: /usr/lib/dovecot/deliver -c /etc/dovecot/conf.d/01-mail-stack-delivery.conf -m "${EXTENSION}")

Wo habe ich da Mist gebaut?

LG
Mario

Christoph Winklerchrisge, 2014/06/15 13:12

Das sieht alles eigentlich ziemlich ordentlich aus. Die Mail wurde ja gleich an Dovecot übergeben. Den Unterschied zwischen den beiden Usern findest du wahrscheinlich in der /etc/aliases (bei dem „guten“ geht die Mail wahrscheinlich über einen Alias von user@localhost an user@mail.Subdomain.no-ip.org, wird aber auch zugestellt). Kam die Mail hier wirklich drei Stunden Später an oder zeigt dir das nur der Mailclient an?

theMarioGuest, 2014/06/15 15:58

Der Mailclient alias Roundcube auf dem rPi zeigt die gleiche Zeit, wie beim Mailanbieter. Die Mail selbst wird aber erst drei Stunden später bei Roundcube angezeigt und Thunderbird lädt sie auch erst drei Stunden später vom rPi. Vom Mailanbieter kann der gleiche Thunderbird sie natürlich auch zur gleichen Zeit abholen, wie der rPi.

Christoph Winklerchrisge, 2014/06/16 19:25

Das ist tatsächlich seltsam. Schreib mir mal bitte eine Mail mit den Configs (Dovecot, Postfix, fetchmailrc) und den Ausgaben von postconf -n.

Geben Sie Ihren Kommentar ein. Wiki-Syntax ist zugelassen:
 
  • Teilen
  • Bookmark "Mailserver für einen Homeserver" auf del.icio.us
  • Bookmark "Mailserver für einen Homeserver" auf Digg
  • Bookmark "Mailserver für einen Homeserver" auf Reddit
  • Bookmark "Mailserver für einen Homeserver" auf StumbleUpon
  • Bookmark "Mailserver für einen Homeserver" auf Facebook
  • Bookmark "Mailserver für einen Homeserver" auf Twitter
  • Bookmark "Mailserver für einen Homeserver" auf Slashdot
Sonstiges
Drucken/exportieren
Archiv

Archivierter Inhalt der alten Seite