E-Mail Weiterleitungen mit DOVECOT SIEVE ohne SPF DMARC und DKIM Konflikte

Die neue SIEVE Version 0.4.4 für Dovecot 2.2.15 enthält ein paar Neuigkeiten die ich zum Anlass nahm etwas zu experimentieren. Im Mittelpunkt stand das Weiterleiten von E-Mails ohne SPF, DMARC und DKIM Ablehnungen beim Empfänger auszulösen.

Einführung

Das klassische Weiterleiten von E-Mails wird heutzutage durch DKIM , SPF , DMARC erheblich erschwert. In aller Kürze: Es läuft darauf hinaus, dass die Authentizität von Versendern überprüft wird. Um Probleme beim Weiterleiten von E-Mails auszuschliessen gibt es praktisch nur zwei Methoden.

  1. das Sender Rewriting Scheme .
  2. Weiterleitung von E-Mail bei der der Weiterleitende selbst zum Absender wird und beim Empfänger auch als solcher authentifiziert wird.

Ich behandle in diesem Blog den Fall 2.

Wichtig

Die hier vorgestellte(n) Methode(n) sind nichts für Laien, denn wenn sie auch weitgehend ihren Zweck erfüllen sind diese nicht perfekt. Sie setzen ausserdem erheblichen Änderungen der Email Header in der Originalmail voraus. Ich habe mich auf die Hauptanwendungsfälle konzentriert und keine Sonderfäll getestet. Wer sich also entschliesst diesen Weg zu gehen sollte auf Überraschungen gefaßt sein!

Grundsätzlich gilt bei Weiterleitungen, dass man unbedingt verhindern muss dass SPAM weitergeleitet wird, das gilt hier ganz besonders, da die von mir beschriebenen Methoden darauf basieren das die weiterleitende Mailbox alle E-mails selbst mit DKIM signiert. Probleme bei der Reputation werden also dem Weiterleitenden zugeschrieben.

Variante 1

Ist Bounce sicher, d.h. sollte die E-Mail beim Empfänger abgelehnt werden, wird der Orginalsender von dieser Ablehnung mit einer Nachricht davon in Kenntnis gesetzt. Der Mailserver des Endempfängers wird als Absenderadresse die des Orginalsenders sehen.

Für DKIM DMARC und SPF spielt das keine Rolle denn diese Überprüfungen beziehen sich auf den From-Absender. Es ist aber nicht ausgeschlossen, dass der Empfänger weitere Mechanismen im Einsatz hat die auch den Envelope Sender z.B mit dem MX Eintrag einer Maildomain vergleichen usw.

Deshalb ist es sinnvoll, vor der Weiterleitung bestimmte Informationen aus der E-Mail zu entfernen, damit es nicht zu Komplikationen beim Bounce kommt. In 90-sieve.conf habe ich dazu folgendes eingetragen:

sieve_redirect_envelope_from = sender

Diese Einstellung entspricht dem üblichen Verfahren. Als Regel gebe ich dann folgendes an:

require ["fileinto", "editheader", "variables", "regex", "envelope"];
if true {
 deleteheader "Reply-To";
 if envelope :matches "From" "*" {
 addheader "Reply-To" "${1}";
 deleteheader "From";
 deleteheader "To";
 deleteheader "DKIM-Signature";
 deleteheader "DomainKey-Signature";
 deleteheader "X-DKIM";
 deleteheader "X-DomainKeys";
 addheader "From" "user@weiter.de";
 addheader "To" "user@ende.de";
 redirect "user@ende.de";
}
}

Variante 2

Diese Variante wäre eigentlich perfekt, denn hier wird auch der Envelope Sender umgeschrieben. Der Nachteil dieses Ansatzes ist aber, dass eine Ablehnung beim Empfänger dem Weiterleitenden zugestellt wird. Der Orginalabsender erfährt im Falle eines Bounces nicht, dass seine E-Mail nicht zugestellt wurde.

Bemerkung

SIEVE kann eine BOUNCE-Mail aus einem redirect nicht autoerkennen. Zur Lösung dieses Problems existiert die Spezifikation einer SIEVE Erweiterung. Sie ist aber heute, Ende 2014, noch nicht in Dovecot SIEVE integriert.

Da auch die Ablehnungsbenachrichtigung den SIEVE Filter durchläuft wird eine Schleife erzeugt. An deren Ende wird die Ablehnungsbenachrichtigung von Postfix verworfen. Dies kann man verhindern indem man einen Regelsatz vor die Weiterleitungsregel schaltet, der E-Mails mit der Absenderadresse des E-Mail Dienstes des Weiterleitungsservers in den Posteingangsordner des Weiterleitenden verschiebt.

So gehen diese wenigstens nicht verloren. Die bessere Methode wäre es den Wert des Reply-To-Headers in der Ablehnungsmail zur Weiterleitung der Ablehnungsmail an den Orginalsender zu nutzen. Dies ist mir leider nicht gelungen.

Meine Konfiguration für diese Variante in 90-sieve.conf lautet:

sieve_redirect_envelope_from = recipient

Hier die Regel dazu:

require ["fileinto", "editheader", "variables", "regex", "envelope"];
if address "From" "MAILER-DAEMON@mail.weiter.de" {
fileinto "INBOX"; stop; }
if true {
 deleteheader "Reply-To";
 if envelope :matches "From" "*" {
 addheader "Reply-To" "${1}";
 deleteheader "From";
 deleteheader "To";
 deleteheader "DKIM-Signature";
 deleteheader "DomainKey-Signature";
 deleteheader "X-DKIM";
 deleteheader "X-DomainKeys";
 addheader "From" "user@weiter.de";
 addheader "To" "user@ende.de";
 redirect "user@ende.de";
}
}

Die SIEVE Extension editheader muss man in der 90-sieve.conf bewußt aktivieren. Dies ist Absicht!

sieve_extensions = +notify +imapflags +editheader

UPDATE

Die SIEVE Version 0.4.4 enthält einen Bug!

Changelog v0.4.5:

+ Added a Pigeonhole version banner to doveconf output. This way, future
  bug reports will also include Pigeonhole version information.
- Fixed handling of implicit keep. Last version erroneously reported
  that implicit keep succeeded after an earlier failure, while it in
  fact had failed. Particularly occurred for mailbox quota errors.
- Fixed segfault occurring on SunOS systems when there is no active
  script.

Möglicherweise wird es auch demnächst noch eine Version 0.4.6 geben weil 0.4.5 ebenfalls einen Bug beim Kompilieren enthielt, ein Patch dazu ist aber bereits veröffentlicht.

UPDATE2

Stephan Bosch schrieb heute ( 30.11.2015 )

I have finally managed to implement the Sieve "foreverypart" and "mime" extensions (RFC 5703). These are now included in the main Mercurial repository and will be included in the next release.

D.h. ich kann meine Tests jetzt fortführen.


Comments

Comments are closed.