Egal, um welchen Dienst es sich dreht, den Benutzern geht es immer zu langsam. Der Schwerpunkt des ADMIN-Magazins 05/2011 verrät, mit welchen Tools man ... (mehr)

Dovecot-Konfiguration

Die Nutzung von Dovecots »deliver« als MDA allein genügt jedoch noch nicht, um Sieve zu aktivieren, denn das Protokoll will zunächst noch konfiguriert werden. Auch hier gehen wir davon aus, dass die grundsätzliche Dovecot-Installation bereits funktionsfähig ist und Mails korrekt in die IMAP-Postfächer verteilt werden.

Die Konfiguration des Servers befindet sich unter Ubuntu in »/etc/dovecot/dovecot.conf« . Zwei wichtige Optionen befinden sich im Abschnitt »lda« , der zunächst aktiviert werden muss. Die dortige Option namens »postmaster_address« benennt den technischen Ansprechpartner für den Mailserver, der unter anderem in Bounces und Systemnachrichten angezeigt wird. Da es ohnehin sinnvoll ist, einen dedizierten Alias namens »postmaster« anzulegen, sollte dieser auch seinen Weg in die Konfiguration finden. In der Option »mail_plugins« wird die Sieve-Filterung schlussendlich aktiviert, denn Dovecot lädt die Erweiterung nur dann nach, wenn der Administrator dies explizit wünscht. Ein vollständiger »lda« -Abschnitt sieht so aus:

protocol lda {
postmaster_address = postmaster@firma.tld
mail_plugins = sieve
}

Mit »/etc/init.d/dovecot restart« liest der Server die Konfiguration neu ein.

Die Arbeit des Administrators ist an dieser Stelle eigentlich getan, denn sind alle Schritte erfolgreich umgesetzt, so steht Sieve jedem Nutzer des IMAP-Servers zur Verfügung. Im Folgenden soll daher gezeigt werden, wie jeder Anwender seine Filterregeln verwaltet und wie die Sieve-Syntax aufgebaut ist.

Grundsätzlich bringt jeder IMAP-Server seine eigene Sieve-Implementation mit, die sich in Details durchaus unterscheiden kann, beispielsweise im Dateinamen für die Filterbefehle oder im Namen der Plugins. In ihren Grundlagen ist die Sprache jedoch spezifiziert, und die wesentlichen Regeln sollten sich daher auch bei einem Wechsel des Mailservers problemlos übernehmen lassen. Die folgenden Ausführungen beziehen sich auf die Sieve-Implementation von Dovecot 1.2,1 wie es Ubuntu 10.04 als Paket mitliefert.

Standardmäßig liegen alle Sieve-Kontrolldateien im Home-Verzeichnis des jeweiligen Benutzers. Für einen ersten Test sollte am besten ein dedizierter Benutzer verwendet werden, um den regulären Mailbetrieb nicht zu gefährden, beispielsweise durch versehentlich gelöschte oder in falsche Ordner verschobene E-Mails. Generell ist Sieve zwar sehr anwenderfreundlich – so verhindert eine fehlerhafte Filterregel nicht etwa die Zustellung von E-Mails, sondern die Filterdatei wird in diesem Fall gar nicht geladen, und die Mails werden ungefiltert zugestellt. Bei einem hohen Mailaufkommen kann bereits das jedoch schon zu unschönen Effekten führen.

Protokoll

Bei der Dovecot-Implementation gibt es mehrere relevante Dateien. Zentral ist die Regeldatei ».dovecot.sieve« (mit Punkt am Anfang), in der alle Filterregeln gespeichert sind. Sie wird bei Änderungen automatisch mit dem Eintreffen der nächsten E-Mails als ».dovecot.svbin« vorcompiliert, damit die Abarbeitung beschleunigt wird. Wichtig ist zudem die Protokolldatei ».dovecot.sieve.log« , denn dort schreibt das Filtersystem standardmäßig seine Fehlermeldungen hinein, wenn Probleme auftreten. Im Fall von aktiven Urlaubsbenachrichtigungen existiert auch noch ».dovecot.lda-dupes« , die über alle verschickten Auto-Replies Buch führt.

Einen ersten Überblick über den Dateiaufbau liefert das folgende einfache Beispiel in Listing 2.

Listing 2

Sieve-Beispiel

 

Zunächst werden alle benötigten Erweiterungen geladen: in diesem Fall »fileinto« , was für das Verschieben von Nachrichten in andere Ordner verantwortlich zeichnet. Im zweiten Teil folgen die einzelnen Regeln, die Sieve nacheinander abarbeitet, wobei eine Raute Kommentarzeilen einleitet. In oben stehendem Beispiel werden Nachrichten, in deren Kopfzeile »X-Spam-Flag« das Wort »YES« enthalten ist, in den Junk-Ordner verschoben, was sich beispielsweise zum automatischen Verschieben von durch Spamassassin erkannten Werbenachrichten eignet. Um diese Regel zu testen, genügt eine E-Mail mit dem sogenannten GTUBE-Muster2. In der Datei »/var/log/mail.log« wird sogleich der erfolgreiche Filtervorgang angezeigt:

Aug 2 10:15:51 mail dovecot: deliver(sieve): sieve: msgid=<4E37B272.2060705@meinefirma.tld>: stored mail into mailbox 'Junk'

In der Sieve-Sprache wird also zunächst die Bedingung genannt, der dann die durchzuführende Aktion folgt. Sowohl Bedingungen als auch Aktionen lassen sich kombinieren, wie das Beispiel in Listing 3 zeigt.

Listing 3

Bedingungen und Aktionen

 

Zunächst werden innerhalb von runden Klammern drei Bedingungen festgelegt, die durch die Option »anyof« jeweils einzeln gültig sind. Anders ausgedrückt: Kommt auch nur eine der drei Kopfzeilen mit entsprechendem Inhalt vor, greift die Regel bereits. Die damit verbundenen Aktionen stehen darunter innerhalb geschweifter Klammern. Im obenstehenden Beispiel würden als Spam erkannte Nachrichten wieder in den Junk-Ordner verschoben, aber zudem als bereits gelesen gekennzeichnet werden. Den dazu nötigen Befehl »setflag« stellt die oben in der Datei geladene imap4flags-Erweiterung bereit.

Nützlich ist auch der abschließende Stop-Befehl, denn er besagt, dass – sofern die entsprechende Regel greift – keine weitere Aktion mehr für diese Nachricht abgearbeitet wird. Das ist unter anderem dann hilfreich, wenn Nachrichten von Mailinglisten oder Newslettern gekennzeichnet werden und für diese keine Urlaubsbenachrichtigung (siehe weiter unten) verschickt werden soll.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019