Dovecot Sieve-Regeln

[sieben]

Hallo Hacker,

ich bastle gerade an einem Postfix + dovecot Mailserver rum. Das Setup soll um Sieve-Support erweitert werden, was auch mit dovecot als LDA ganz einfach zu bewerkstelligen ist.

Ein Problem an dem ich gerade hänge ist, dass Benutzer reject-Regeln bauen können, die natürlich nicht zum reject sondern zum bounce führen, weil die Sieveregeln erst durchlaufen werden, wenn Postfix die Mail angenommen und zum LDA durchgereicht hat. Leider finde ich bei Dovecot weder eine Möglichkeit einzelne Regeln einzuschränken um das Pseudo-reject ganz zu verbieten, noch eine Möglichkeit das zu prüfen solange die Mail noch eingeliefert wird um dann einfach direkt zu rejecten.

Da ich Backscatter-Spam so gut wie möglich einschränken möchte ist meine Überlegung gerade schon so weit einen Daemon in Perl zusammenzukleben zu wollen, den ich bei Postfix in die smtpd_recipient_restrictions hängen kann um direkt nach dem RCPT TO das passende sieve-file zu parsen und dann ensprechend dunno oder reject zu liefern.

Die Arbeit würde ich mir da natürlich gerne ersparen, wenn es schon irgendeine schlauere Möglichkeit gibt.

Jemand eine tolle Idee?

 

[Chromatin]

Zu Sieve kann ich an der Stelle nix sagen, jedoch zum mittlerweile wirklich ernsten Problem der Bounces.

Wenn Du schon Hand anlegen willst, kann ich dir zwecks Filterung unbedingt den qpsmtpd empfehlen - da kann Postfix auch als Backend laufen.
Zum einen gibts schon sehr viele und alle moeglichen Tests und zum anderen ist das Schreiben von Plugins (Perl) sehr sehr leicht und man muss da nix mehr rausparsen, wenn man bestimmte Daten der Mail haben will.

Du kannst dich via qpsmtpd im gesamten Einlieferungsprozess durch "hooks" reinhängen und an jeder beliebigen Stelle Tests machen und die Mail rejecten/bouncen oder einfach wegwerfen. Dadurch hast du 1. wenig Mail im Backend und 2. weniger bounces, bzw. backscatter, was bei grossen Systemen nach meiner Erfahrung echte Probleme mit sich bringt.
Wenn Du die Plugins etwas aufbohrts, kannst du sogar je User seperate Configs anlegen (wenn du Langeweile hast, kannste sogar globalere Sieve Regeln in eigenen Plugins abbilden ).

 

[sieben]

Der Tipp war gut, qpsmtpd kannte ich noch nicht, aber wir haben uns dann doch für den Perl-Daemon entschieden, weil die Lösung als weniger Wartungsintensiv angenommen wurde. Aber ich glaub ich spiel damit mal ein bisschen auf meinem Privatserver rum.

Es gibt zum Glück ein paar brauchbare Perl-Module zum Sieve-Regeln parsen, was ziemlich widerlich sein kann, weil die im Verhältnis zu anderen Regeln stehen können. Damit wird nun wirklich alles rejected und nicht mehr gebounced. Zwischenzeitlich haben wir als Workaround den Sieveport dicht gemacht und das editieren der Regeln nur aus einem Roundcube-Plugin heraus erlaubt, welches um entsprechende Regelauswahl beschnitten war. (Das durfte in kleineren Setups vielleicht als Lösung durchaus ausreichen)

Ganz interessante Anekdote am Rand ist: Ich habe einen mx20 im DNS gefunden der ins Leere zeigte. Als ich den entfernt habe kam auf einen Schlag drastisch mehr Spam rein. Viele Spammer scheinen also schon per Default am mx20 zustellen zu wollen, in der Hoffnung das der Spam da ungeprüft durchkommt. Ich hab den DNS-Record wieder gesetzt und muss mir da mal was überlegen. Teergrube oder RBL-Futter oder so..

 

[Chromatin]

interessant mit den mx20 (oder höher?). Das hatte ich bisher noch nicht so wahrgenommen.


Unabhaengig davon ist es aber grundsätzlich nach-wie-vor ein lästiges Problem, insbesondere die Bounces, die wie Pest und Segen sind und in kleineren Netzen fuer echte Probleme sorgen, alleine was die Ressourcen der Filter angehen.

Wenn Du tiefgreiferendes Interesse hast, auch bzlg. ipv6 und Blacklisting, dann join doch gerne auch die Liste der Anti Spam Research Group (der IETF) IRTF Anti-Spam Research Group (ASRG). Meistens ziemlich ruhig auf der Liste, aber ab und an ist gut was los. Das ist allerings eher langfristig angelegte "Forschunsdiskussion"...join it