courier, dovecot, sieve, push mail

Monday, January 23. 2012

 Courier tat seine Arbeit an sich wunderbar, aber in der Integration von desktop- und mobilem Mailabruf stand es mir dann doch im Wege. Ich wollte

  • mail-Sortierung und -filterung auf dem Server
  • dazu gerne das sieve-Addon zu ThunderBird nutzen
  • push-mail für k-9 mail auf meinem android verlaesslich und doch batterieschonend einrichten

Das sprach für einen Wechsel von Courier zu dovecot. Dabei habe ich auf debian oldstable (Lenny) einige Varianten durchprobiert.

Ein paar hilfreiche WebSeiten vorweg, Migration to Dovecot (1.0), Courier to Dovecot 

courier -> dovecot 1.0

Der erste Anlauf blieb geradewegs im Rahmen des in der Distribution enthaltenen:

apt-get install dovecot-imapd dovecot-pop3d
dovecot --version  (1.0.15-2.3+lenny1)

Weiter, nach Maßgabe des dovecot-Wiki, mit dem Script zur Migration der Daten

cd /usr/local/bin
mkdir dovecot-mig
cd dovecot-mig/
wget http://www.dovecot.org/tools/courier-dovecot-migrate-1.0.pl
./courier-dovecot-migrate-1.0.pl --recursive --convert /home

Und zur Dovecot - Konfiguration:

Für SSL bietet dovecot.conf viele Felder aber ich wollte einfach das auch für Courier eingesetzte chained certificate weiterverwenden, ging so:

joe dovecot.conf

# chained certificate doppelt eintragen
ssl_cert_file = /etc/ssl/certs/startssl/mail.domain.tld.pem
ssl_key_file = /etc/ssl/certs/startssl/mail.domain.tld.pem

# dovecot 1.0 lauscht so an IPv4 und IPv6 
listen = [::] 

# Pfad zum maildir
mail_location = maildir:~/Maildir

# namespace wie courier
namespace private {
  prefix = INBOX.
  separator = .
  inbox = yes 
}

dovecot neu starten:

/etc/init.d/dovecot restart

Ergebnis? Beim ersten start des MUA (Thunderbird) gab es einen Wald von Messageboxen und Thunderbird war eine Weile beschaeftigt, Mails zu synchronisieren. Ansonsten gings soweit ohne Drama, nur das Mail-filtern wollte nicht.

 

courier -> dovecot 1.2

Im zweiten Anlauf habe ich, auf einem anderen server, die in den backports vorgehaltene Version dovecot 1.2 installiert:

# backports in sources.list eintragen
joe /etc/apt/sources.list
deb http://www.backports.org/debian lenny-backports main contrib non-free

# und der key dazu, sonst nervt apt-get bei jedem Aufruf
sudo wget -O - http://backports.org/debian/archive.key | sudo apt-key add -
sudo apt-get update
sudo apt-get -t lenny-backports install dovecot-common dovecot-pop3d dovecot-imapd

 

Weiter, nach Maßgabe des dovecot-Wiki, mit dem Script zur Migration der Daten in der version fuer dovecot 1.1+

cd /usr/local/bin
mkdir dovecot-mig
cd dovecot-mig/
wget http://www.dovecot.org/tools/courier-dovecot-migrate.pl
./courier-dovecot-migrate.pl --recursive --convert /home

 

# die Anpassungen der Konfig
joe /etc/dovecot/dovecot.conf

# managagesieve und lda bringen die Mailsortierung auf dem server zuwege
protocols = imap pop3 pop3s imaps managesieve lda

# sowohl auf IPv4 wie IPv6 lauschen
listen = *, [::] 

# im default verbietet dovecot Klartext-Passworte, aber hier haette es manche Klienten ausgesperrt
disable_plaintext_auth = no

# chained cert doppelt eintragen
ssl_cert_file = /etc/ssl/certs/startssl/mail.domain.tld.pem
ssl_key_file = /etc/ssl/certs/startssl/mail.domain.tld.pem

# lda ist der local delivery agent und stoesst das sieben und reindizieren der mails bei Auslieferung an
protocol lda {
postmaster_address = master@server.domain
mail_plugins = sieve
}

# sieve_dir ist das Verzeichnis, in dem Filterscripte abgelegt werden. unter dovecot 1.2 ist deren Name beliebig
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/mails/sieve
}

Konfig speichern und dovecot neu starten

/etc/init.d/dovecot restart

Damit der lda deliver nun auch benutzt wird, muss er postfix bekannt gemacht werden:

joe /etc/postfix/main.cf

mailbox_command = /usr/lib/dovecot/deliver
 
Speichern und geanderte Konfig laden:
/etc/init.d/postfix reload

Auch hier gab es mit Thunderbird zuerst mal Messageboxen und Resynchronisierung, aber dann liessen sich zur Belohnung Filterregeln für's serverseitige Filtern aus Thunderbird heraus editieren und es ging auch.


 dovecot 1.2 -> dovecot 2.0

den Anstoss für dieses Upgrade gab ein Blog-Artikel von Peter Kieser mit der Argumentation:

  • push funktioniert auf IMAP, indem zwischen dem Client und dem Server die Verbindung IDLE offengehalten wird. Alle paar Minuten werden "OK Still here"-Nachrichten ausgetauscht.
  • Wenn das geschieht, reaktiviert Android eine reihe ruhende Netzwerk-Funktionen und die ziehen Strom, je häufiger das geschieht, je mehr leidet die Batterielaufzeit.
  • K-9 hat als default einen refresh alle 24 Minuten, dovecot aber alle 2 Minuten.
  • mit dovecot 1.2 laesst sich daran per Config nichts ändern, Dovecot 2.0 hat dagegen einen Parameter imap_idle_notify_interval 

Dovecot 2.0 gibt es für Lenny als Prebuilt Binary, Upgrading Dovecot v1.2 to v2.0 im dovecot-wiki hilft auch weiter.
Als erstes /etc/dovecot/dovecot.conf in ein backup sichern, so dass im weiteren nichts verloren geht, auch wenn man im install die dovecot.conf durch die neue Version ersetzen laesst!

cp /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf.1-2

 

# apt sources.list erweitern
joe /etc/apt/sources.list
 
# lenny is oldstable
deb http://xi.rename-it.nl/debian/ oldstable-auto/dovecot-2.0 main

# speichern, dann key besorgen
wget -O - http://xi.rename-it.nl/debian/archive.key | apt-key add -
 
# und dovecot 2 installieren
apt-get update && apt-get upgrade
apt-get install dovecot-imapd dovecot-pop3d dovecot-managesieved

 

# die Konfigurationsdateien sehen für dovecot 2.0  einiges anders aus, die in dovecot 1.2 schon sehr umfangreiche dovecot.conf ist nun viel kuerzer und inkludiert stattdessen Konfigurationsdateien aus einem gesonderten Verzeichnis. Und optional eine local.conf, die ich mit diesen Einträgen angelegt habe:

 

# /etc/dovecot/local.conf
mail_location = maildir:~/Maildir
namespace {
  inbox = yes
  location = 
  prefix = INBOX.
  separator = .
  type = private
}
passdb {
  driver = pam
}
plugin {
  sieve = ~/.dovecot.sieve
  sieve_dir = ~/sieve
}
protocols = " imap pop3 sieve "
ssl_cert = </etc/ssl/certs/startssl/mail.domain.tld.crt
ssl_key = </etc/ssl/certs/startssl/mail.domain.tld.key
ssl_ca = </etc/ssl/certs/startssl/startssl.chain.class1.server.crt
 
service managesieve-login {
  inet_listener sieve {
    port = 4190
  }
  inet_listener sieve_deprecated {
    port = 2000
  }
}
 
userdb {
  driver = passwd
}
protocol imap {
  imap_idle_notify_interval = 29 mins
  mail_max_userip_connections = 60
}
 
protocol lda {
  postmaster_address = postmaster@datenwusel-hosting.de
  mail_plugins = sieve
  log_path = /var/log/dovecot/deliver.log
  info_log_path = /var/log/dovecot/deliver-info.log
}
disable_plaintext_auth = no
auth_cache_size = 5M
log_timestamp = "%Y-%m-%d %H:%M:%S "
 
Bei der Gelegenheit habe ich auch das courier-style - .pem beurlaubt und ssl key, cert, ca einzeln eingebunden. Mehr dazu hier.
Anschliessend dovecot neu starten und dann in /etc/postfix/main.cf eine kleine Änderung vornehmen:
mailbox_command = /usr/lib/dovecot/dovecot-lda -f "$SENDER" -a "$RECIPIENT"
 
Ich musste auch den Namen der Datei mit den Filterregeln umbenennen, da nur noch Dateien mit der extension .sieve interpretiert werden.
 
sieve error log

Wenn der lda bei der Abarbeitung des sieve-scriptes einen Fehler feststellt, etwa wg eines Tippfehlers, einen Ordner nicht findet, schreibt er eine Fehlermeldung in ~/.dovecot.sieve.log 

fail2ban - Regel für dovecot

Auch hierzu wird man im dovecot-wiki fündig.

 

push mail und (android-app) juice defender

Die beiden stehen sich schon im Weg, juice defender erzielt seine laufzeitverlängernden Wirkungen nicht zuletzt, indem es die Datenverbindung des smartPhone nur periodisch aktiviert. Mit den default-Einstellungen hatte es bei mir schon merklich was bewirkt, aber der push mail zuliebe habe ich es deaktiviert.

 

Zielkonflikt zwischen sieve und push-imap

Quasi als Schlussbemerkung hier, warum ich nach erfolgreicher Migration, upgrades, Konfiguration doch nicht ganz zufrieden wurde:

  • sieve unterstuetzt nun serverseitig mein Mail-Ablage-Modell eines weitverzweigten hierarchischen Ordnerbaums mit deutlich > 100 systematisch/thematischen Ordnern. Ich kann von verschiedenen Orten (desktop, smartPhone, fremder Rechner) und MUA (ThunderBird, K-9, WebMail) darauf zugreifen und finde alles sortiert.
  • imap-push zwischen dovecot (2.0) und k-9 funzt an sich auch wunderbar und mit dem auf 24//29 Minuten gestreckten Refresh-Interval auch halbwegs batterieschonend.
  • Aber: imap-push hält je "push-aktivem" Ordner eine imap-idle - Verbindung offen. Ein anderes Model (nur eine Verbindung zwischen Client und Server bleibt idle offen, notify übergibt den Pfad zum aktualisierten Ordner) ist in der Mache, aber derzeit eben Zukunftsmusik. Das heisst konkret: mit 2, 3, 5 aktiven Ordnern ist alles bene, mit 127 hängt und klemmt es an allen Enden.
  • mein Mail-Ablage-Modell dient dem Zweck, deduktiv/systematisch alte Mails wiederzufinden, imap-push dient dem Zweck, neue Mails sofort annonciert zu bekommen. Meine Wunschvorstellung war, dass k-9 und ThunderBird mir '''pling!''' sofort die neue Mail an ihrem systematischen Ort vor die Nase halten. Mit dem derzeitigen Stand der Protokolle geht das (bei vertretbarem Energieaufwand des smartPhone) aber nicht zusammen.
  • meine Loesung ist dafür bis auf weiteres:
    mobil: je ein account je Nutzung
    .
    • Ein Mail-account hält die hierarchische Ordnerliste, hier gibt es kein imap-push und keine regelmässige Synchronisierung, aktualisiert wird also nur bei Zugriff, und nur auf dem je gewünschten Pfad.
    • Ein zweiter Mail-Account bekommt per .forward die selben neuen Mails zugestellt, alles unsortiert in die INBOX. Push macht sein Ding und das macht es gut. Wenn ich wirklich zu der neuen Mail den Kontext der vorigen brauche, kann ich ja auf dem anderen Konto nachsehen.



Leider habe ich nicht zurückverfolgen können, was eigentlich den Auslöser davon darstellte, gefühlt schien das K9 - Mail meines android zu spinnen: neu angelegte Unterordner auf dem imap-Server wurden da nicht angezeigt und beim Abruf neuer Nachrichten gab es oft reihenweise Fehlermeldungen (ssl-handshake fail). Alle Versuche, K9 mit veränderten Einstellungen zu heilen, schlugen fehl. 
Bis ich mir dann mal die Zeit nahm, auf den Server zu schauen und dort im mail.log viele Fehlermeldungen wie diese fand:

imapd-ssl: Maximum connection limit reached for (und die IP)

Wobei an dem Server nicht eben viele Clienten hingen, sondern genau zwei: ein Thunderbird und eben K9 auf dem Androiden. Die in den Fehlermeldungen gelisteten IPs liessen sich ohne Zweifel und Ausnahme auf das Android-Telefon zurückführen.
Google lieferte mir einen vergleichbaren Problembericht von jmd., dermit Thunderbird und einem OSX Mail auch diesen Fehler sah und ihn dort auf Mail zurückführte, wie bei mir tauchte die IP des Rechners mit Thunderbird nie auf. Auch dort kam nicht heraus, warum eine anfangs funktionierende Einrichtung dann diese Fehler warf, aber eine Abhilfe habe ich gefunden.

In /etc/imapd-ssl habe ich diese beiden Einträge angefügt:

MAXDAEMONS=280
MAXPERIP=40

noch ein /etc/init.d/courier-imap-ssl restart und seither ist Ruhe und K9 kommt auch wieder klar.

In einem früheren Eintrag hatte ich startssl als Quelle für kostenlose Zertifikate für Server angesprochen, die kostenlosen Class 1 - Zertifikate gelten immer für eine Subdomain und die Domain selbst. Also zB. www.domain.tld und  domain.tld. Hier mein Waschzettel, um das Zertifikat für den Webserver der Domain, Courier (pop3s, imaps) und für die Serververwaltungen Webmin und ISPConfig2 einzubinden.

 
# Verzeichnis für die eigenen Certs anlegen 
mkdir -p  /etc/ssl/certs/startssl/
chmod 700 /etc/ssl/certs/startssl/

# den eigenen key und das von startssl signierte zertifikat hier speichern
# darauf achten bzw. kontrollieren, dass jede dieser Dateien mit einem \n endet
domain.tld.key
domain.tld.crt
chmod 600 domain.tld.key

# die certs von startssl herunterladen
wget https://www.startssl.com/certs/ca.pem
wget https://www.startssl.com/certs/sub.class1.server.ca.pem

# umbenennen ordnet
mv ca.pem startssl.ca.crt
mv sub.class1.server.ca.pem startssl.sub.class1.server.ca.crt

# die ganze Kette zusammenkopieren
cat startssl.sub.class1.server.ca.crt startssl.ca.crt >startssl.chain.class1.server.crt
cat domain.tld.{key,crt} startssl.chain.class1.server.crt >domain.tld.pem
chmod 600  domain.tld.pem

# fuer imap-ssl und pop-ssl eintragen 
# in den beiden .cnf den Pfad zum domain.tld.pem einzutragen funktioniert nicht, 
# courier erwartet das Zertifikat in oder unter /etc/courier
# was dagegen klappt ist ein symlink von dem Zertifikat nach imapd.pem bzw pop3d.pem
mv /etc/courier/imapd.pem /etc/courier/imapd.pem.bkp
mv /etc/courier/pop3d.pem /etc/courier/pop3d.pem.bkp
ln -s /etc/ssl/certs/startssl/domain.tld.pem /etc/courier/imapd.pem
ln -s /etc/ssl/certs/startssl/domain.tld.pem /etc/courier/pop3d.pem

# neu starten
/etc/init.d/courier-imap-ssl stop 
/etc/init.d/courier-imap-ssl start
/etc/init.d/courier-pop-ssl stop
/etc/init.d/courier-pop-ssl start


# fuer webmin eintragen
nano /etc/webmin/miniserv.conf

# dort den eintrag keyfile auskommentieren und stattdessen eintragen:
keyfile=/etc/ssl/certs/startssl/domain.tld.pem

# und neu starten
/etc/init.d/webmin restart


# für ispConfig auf domain.tld:81 einbinden
nano /root/ispconfig/httpd/conf/httpd.conf

# dort auskommentieren
##SSLCertificateFile /root/ispconfig/httpd/conf/ssl.crt/server.crt
##SSLCertificateKeyFile /root/ispconfig/httpd/conf/ssl.key/server.key
ggf. auch #SSLCertificateChainFile und #SSLCACertificateFile

# und stattdessen eintragen:
SSLCertificateFile /etc/ssl/certs/startssl/domain.tld.net.crt
SSLCertificateKeyFile /etc/ssl/private/domain.tld.net.key
SSLCertificateChainFile /etc/ssl/certs/startssl/startssl.chain.class1.server.crt
# neu starten
/etc/init.d/ispconfig_server restart


# für den Apache des betreffenden vhosts in dessen conf gleichermassen eintragen
SSLEngine on
SSLCertificateFile /etc/ssl/certs/startssl/domain.tld.net.crt
SSLCertificateKeyFile /etc/ssl/private/domain.tld.net.key
SSLCertificateChainFile /etc/ssl/certs/startssl/startssl.sub.class1.server.ca.crt

# neu starten
/etc/init.d/apache2 restart


# für postfix
mkdir -p /etc/postfix/ssl/startssl_cert
ln -s /etc/ssl/certs/startssl/domain.tld.crt /etc/postfix/ssl/startssl_cert/domain.tld.crt
ln -s /etc/ssl/certs/startssl/domain.tld.key /etc/postfix/ssl/startssl_cert/domain.tld.key
# 1 Zeile!
ln -s /etc/ssl/certs/startssl/startssl.chain.class1.server.crt 
/etc/postfix/ssl/startssl_cert/startssl.chain.class1.server.crt

# postfix' main.cf editieren und darin einfügen bzw. anpassen:
nano /etc/postfix/main.cf

#TLS Support
## smtpd
smtpd_tls_auth_only = no
smtpd_use_tls = yes

# eigener Key
smtpd_tls_key_file = /etc/postfix/ssl/startssl_cert/domain.tld.key
# eigenes Certificate
smtpd_tls_cert_file = /etc/postfix/ssl/startssl_cert/domain.tld.crt
# public der Certificate Authority
smtpd_tls_CAfile = /etc/postfix/ssl/startssl_cert/startssl.chain.class1.server.crt

smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

##smtp
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes

update:

# fuer dovecot (2.x):
nano /etc/dovecot/local.conf

ssl_cert = </etc/ssl/certs/startssl/domain.tld.crt
ssl_key = </etc/ssl/certs/startssl/domain.tld.key
ssl_ca = </etc/ssl/certs/startssl/startssl.chain.class1.server.crt

#fuer nrpe, bei mir icinga-nrpe-server

nano /etc/icinga-nrpe/nrpe.cfg

cert_file=/etc/ssl/certs/startssl/domain.tld.crt
cacert_file=/etc/ssl/certs/startssl/startssl.chain.class1.server.crt
privatekey_file=/etc/ssl/certs/startssl/domain.tld.key

Alternative Anleitung mit Beispielen für nginx, Lighttpd, Postfix, Dovecot, eJabberd, vsftpd

 

 

 

 

fail2ban fails to start

Thursday, January 27. 2011

I discovered loads of entries in mail.log logging dicionary attacks on port 110. And, going back in time, the logs showed more than just one dictionary being used, and it had been going for some time. Well, it litters the logs and you don't want to risk that finally one of them gets lucky with a user password so I searched for a way to stop the attacks.
I already used denyhosts against brute force attacks on ssh, which works fine but is limited to ssh. Instead I found out about fail2ban. 

It does what I need now but it took some smoothing of edges till I got there.

debian lenny, python 2.5.2 and fail2ban v 0.8.3 wouldn't play nice together. Fail2ban v0.8.3 apparently doesn't run with python2.5 but needs python2.4 instead

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496633 describes the sort of thing I experienced and I followed the workaround given there:

apt-get install python2.4
apt-get install fail2ban

now edit both /usr/bin/fail2ban-server and /usr/bin/fail2ban-client, first line, to point towards  python2.4 (and not python).

#!/usr/bin/python2.4

Now fail2ban ran but still wouldn't stop the attacks. I followed the howto at http://www.howtoforge.com/fail2ban_debian_etch and while I have found plenty of good advice on that site before and after, this one didn't just work. Additionally to the config described therein a file  filter.d/pop3d.conf was needed (which is easily supplied by 
cp courierlogin.conf pop3d.conf

Further on I had to remove a line from  jail.local until it looked like this:

[pop3d]
enabled = true
port = pop3   
filter = pop3d
logpath = /var/log/mail.log
maxretry = 5

One thing which irritated me debugging the problem was that fail2ban didn't report the errors in the log file even though I had the loglevel set up to 4. To get to see the errors I had to run two shells, running  
/usr/bin/fail2ban-server -x -f
in one of them and then 
/usr/bin/fail2ban-client reload
in the other one.

Update:

Later, I found thousands of log entries re SASL LOGIN:
Feb 10 16:55:42 pipit postfix/smtpd[21738]: warning: unknown[95.62.75.67]: SASL LOGIN authentication failed: authentication failure
Feb 10 16:55:49 pipit postfix/smtpd[21738]: warning: unknown[95.62.75.67]: SASL LOGIN authentication failed: authentication failure
Feb 10 16:55:56 pipit postfix/smtpd[21738]: warning: unknown[95.62.75.67]: SASL LOGIN authentication failed: authentication failure

There was a filter for SASL in the config but it didn't seem to catch them. Google once again found prior art  and the regexp from there did the job:

 failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: \w

(Page 1 of 1, totaling 4 entries)