[gelöst] maildrop vs. procmail

[weshalb]

Das sind bloß Symlinks im Verzeichnis von sieve. Und da setzt offenbar jede Anwendung ihre eigenen. Das hat mit Sieve per se nix zu tun...

Ich meine mal gelesen zu haben, dass Sieve tatsächlich immer nur eine Datei verarbeiten kann.

[catdog2]

Ich meine mal gelesen zu haben, dass Sieve tatsächlich immer nur eine Datei verarbeiten kann.

Jein es wird halt immer nur ein Skript ausgeführt welches als solches gesetzt ist. Es gibt aber ein include Statement [1], man kann also auch mit mehreren Dateien arbeiten.

[1] https://tools.ietf.org/html/rfc6609

[scientific]

Ein ls -Al (ist der Alias zu l) auf das Sieve-Verzeichnis losgelassen ergibt:

Code: Alles auswählen

# l /var/spool/dovecot/sieve/jakob/
insgesamt 128
lrwxrwxrwx 1 jakob   jakob    15 Mai 24 22:42 jakob.sieve -> old-cyrus.sieve
-rw------- 1 dovecot mail   1454 Mai  6 00:11 jakob.sieve.log
-rw----rwx 1 jakob   jakob 10252 Mai  6 00:05 jakob.sieve.log.0
-rw-rw-rw- 1 jakob   mail  28113 Jun  9 00:14 jakob.svbin
-rw-rw-rw- 1 jakob   jakob 34532 Jun  9 00:00 old-cyrus.sieve
-rw-r--rwx 1 jakob   jakob 37286 Apr 11 01:33 old-cyrus.sieve.orig
-rw-rw-rw- 1 jakob   jakob    18 Mai 23 00:17 roundcube.sieve
drwxrwxrwx 1 jakob   jakob     0 Jun 25 11:37 tmp

old-cyrus.sieve ist die Sieve-Filterregel-Datei, welche ich von meinem früheren cyrus 1:1 übernommen und weitergeführt habe. roundcube.sieve wurde beim meinem Versuch mit Roundcube angelegt. Offenbar (ich hab die Config nicht mehr ganz so im Kopf) verwendet dovecot-sieve die Datei $USERNAME.sieve. Ob das nun ein Symlink oder eine "echte" Datei ist, scheint egal zu sein. Kann ich aber jetzt nicht beschwören.

lg scientific

[novalix]

Wenn ich das recht verstehe, läßt Du ja Postfix beim Mailempfang außen vor. Getmail holt die Mails gibt sie direkt an procmail, und dieses sortiert diese dann in die jeweiligen mboxes oder maildirs. In diesem Fall wäre es dann auch völlig egal, welcher MDA in der master.cf von Postfix wie konfiguriert ist. Den von @catdog2 ins Spiel gebrachten dovecot-eigenen Agent habe ich noch nie im stand alone Modus konfiguriert, und kenne dafür auch keine Anleitung.
Meines Erachtens nach wäre es sinnvoll, die abgeholten Mails in Postfix zu füttern und von dort aus weiter zu verarbeiten.
Aber vielleicht machst Du das ja schon. Geht aus Deinem Eingangspost allerdings nicht so hervor.

[weshalb]

Ich meine mal gelesen zu haben, dass Sieve tatsächlich immer nur eine Datei verarbeiten kann.

Jein es wird halt immer nur ein Skript ausgeführt welches als solches gesetzt ist. Es gibt aber ein include Statement [1], man kann also auch mit mehreren Dateien arbeiten.

[1] https://tools.ietf.org/html/rfc6609

War das nicht immer nur für eine zusätzliche globale Filterung gedacht? Auch das nützt nichts, wenn man mit verschiedenen Mailclients über Managesieve seine Sieveregeln bearbeiten will.

Bestes Beispiel> Ich nutze im Netzwerk ausschließlich Thunderbird, bin für mehrere Wochen nicht im Haus und greife nur über Roundcube oder Horde auf meine Mails zu. Sobald ich auch nur eine Filterregel ändern, dazu nehmen oder löschen möchte, muss ich alle Filterregeln neu anlegen, zumal beispielsweise Roundcube die bereits vorhandene Filterdatei erkennt, nur bearbeiten eben nicht. Ich weiß nach wie vor nicht, was die sich dabei gedacht haben.

[catdog2]

Bestes Beispiel> Ich nutze im Netzwerk ausschließlich Thunderbird, bin für mehrere Wochen nicht im Haus und greife nur über Roundcube oder Horde auf meine Mails zu. Sobald ich auch nur eine Filterregel ändern, dazu nehmen oder löschen möchte, muss ich alle Filterregeln neu anlegen, zumal beispielsweise Roundcube die bereits vorhandene Filterdatei erkennt, nur bearbeiten eben nicht. Ich weiß nach wie vor nicht, was die sich dabei gedacht haben.

Gegen kaputte Clients kann man nicht viel machen. Das passiert halt, wenn man die Textdarstellung vor dem Nutzer komplett verstecken will und einen auf klickbunt macht, das dann aber nicht vernünftig umgesetzt kriegt. In KMail kann ich z.B. die Skripte einfach direkt bearbeiten mit einem einen kleinen spezialisierten Editor, sicherlich auch ausbaufähig aber es steht zumindest nicht im Weg mit dem was es nicht kann.

[TomL]

Wenn ich das recht verstehe, läßt Du ja Postfix beim Mailempfang außen vor. Getmail holt die Mails gibt sie direkt an procmail, und dieses sortiert diese dann in die jeweiligen mboxes oder maildirs.

Richtig, genau so ist es derzeit.

Den von @catdog2 ins Spiel gebrachten dovecot-eigenen Agent habe ich noch nie im stand alone Modus konfiguriert, und kenne dafür auch keine Anleitung. Meines Erachtens nach wäre es sinnvoll, die abgeholten Mails in Postfix zu füttern und von dort aus weiter zu verarbeiten.
Aber vielleicht machst Du das ja schon. Geht aus Deinem Eingangspost allerdings nicht so hervor.

Und genau damit sprichst Du jetzt mein wirkliches Problem an.... das Zusammenspiel der Komponenten... was m.E. an keiner Stelle hinreichend und nachvollziehbar dokumentiert ist.

Dovecot hat -wenn ich das richtig verstanden habe- nicht nur einen Delivery-Agenten, sondern zwei, und beide können Sieve in ihr Protocoll einbauen. Es gibt also einmal den dovecot-lmtpd und dann noch Dovecot LDA... wobei ich annehme, dass dovecot-lda Bestandteil des Core-Paketes ist. Tatsache ist, der lda "is the worser solution..." bei den delivery agents. Diese Beurteilung habe ich aus der Dovecot-Mailingliste entnommen. Ich interpretiere das so , dass 'lda' Basis-Funktionen im Core zur Verfügung stellt,und Dovecot-lmtpd als eigenes Paket deutlich mehr Umfang beinhaltet... aber das beide eine solche Aufgabe erfüllen könnten. Ob meine Interpretation richtig ist weiss ich natürlich nicht... ist alles total schwer zu verifizieren.

Aber... das Paket Dovecot-lmtpd habe ich ja sowieso installiert... allein wegen der Zustellung rein lokaler Post. Das heisst, lokale Zustellung funktioniert ja jetzt schon. Und daraus resultiert die Frage, wie ich den weiteren lokalen Transport implementieren muss, um die von Getmail abgeholten Emails -die ja nun lokal vorliegen- an den lmtdp zu übergeben? Die Kernfrage ist, kann Getmail überhaupt selber direkt an den ltmpd übergeben oder muss ich den Umweg über Postfix wählen? Oder funktioniert das vielleicht alles auch nur über das "lda"-Protokoll? Sind direkte Wege von Getmail via Sieve nach Dovecot möglich, oder muss ich grundsätzlich Postfix einbinden?

Darübe hinaus ist auch noch managedsieve ein Thema. Ich möchte rein statische Verteilregeln implementieren, genau so, wie das eigentlich jetzt auch mit procmail abläuft. Ich verstehe das jetzt so, dass ich die sieve-Regeln im User-Dir hinterlegen (gemäß den Sieve-Vorgaben) und sieve als Plugin in das Protokoll übernehmen kann. Managedsieve als Backend zu Roundcube würde ich dann doch gar nicht brauchen.

Also eigentlich wäre mein Ziel, die Delivery-Funktion mit Sieve genauso geradlinig und statisch abzubilden, wie ich das jetzt mit procmail mache. Aber dafür findet man so gut wie nix an hilfreichen Informationen.

[novalix]

Aber... das Paket Dovecot-lmtpd habe ich ja sowieso installiert... allein wegen der Zustellung rein lokaler Post. Das heisst, lokale Zustellung funktioniert ja jetzt schon. Und daraus resultiert die Frage, wie ich den weiteren lokalen Transport implementieren muss, um die von Getmail abgeholten Emails -die ja nun lokal vorliegen- an den lmtdp zu übergeben? Die Kernfrage ist, kann Getmail überhaupt selber direkt an den ltmpd übergeben oder muss ich den Umweg über Postfix wählen? Oder funktioniert das vielleicht alles auch nur über das "lda"-Protokoll? Sind direkte Wege von Getmail via Sieve nach Dovecot möglich, oder muss ich grundsätzlich Postfix einbinden?

Ob Du Postfix grundsätzlich einbinden musst, weiß ich nicht. Aber, was spricht dagegen? Ich kenne ja Deine Anforderungen und Dein Setup nicht. Wenn Du mehrere User verwaltest, dann müssen die sich ja in jedem Fall bei Postfix authentifizieren, um Mail versenden zu können. Wenn eingehende mails erst einmal an Postfix übergeben werden, könnte das selbe user mapping greifen. Außerdem könntest Du die eingehenden Mails noch zusätzliche Schleifen durch irgendwelche Milter, Amavis, o.Ä. drehen lassen.

Sieve ist afaik selbst kein Delivery Agent, sondern das reine Filterregelprotokoll.

[scientific]

Bei mir liefert fetchmail die Emails an exim ab, der anhand der Empfängeradresse erkennt, dass es lokal zugestellt werden muss.
Wenn ich per mailx ein Email an jakob@localhost sende, weiß exim ebenfalls, dass es ein lokal zuzustellendes Mail ist und verwendet den Transport, den ich für lokale Zustellung definiert habe. In meinem Fall eben den dovecot-MDA.

[TomL]

Ob Du Postfix grundsätzlich einbinden musst, weiß ich nicht. Aber, was spricht dagegen?

Nee, eigentlich spricht nix dagegen, zumindest technisch nicht. Ich bin halt nur nicht so recht von der Notwendigkeit und der Sinnhaftigkeit überzeugt. Und postfix nur dazwischen zu schalten, weils möglich ist.... tja...ohne zu verstehen, dass es MUSS, tue ich mich schwer damit.

Worum gehts eigentlich... ?... ganz einfach: um die letztendliche Zustellung nach dem erfolgreich beendeten Prozess Getmail, also um die jeweilige Zustellung der Mail ins eigentliche/richtige Postfach. Und ich habe bereits einen Delivery-Agenten installliert, der jetzt schon zuverlässig funktioniert, und zwar den dovecot-lmtpd. Dieser Agent stellt ja heute schon lokale Post zu, nur in dem Fall bekommt er sie von Postfix.

Laut dovecot-wiki kann ich auch direkt im usereigenen accountindividuellen Getmail-Conf den Dovecot-Delivery eintragen, was dann in etwa so aussieht:

Code: Alles auswählen

[destination]
type = MDA_external
path = /usr/lib/dovecot/deliver
arguments = ("-e",)

Daraus verstehe ich, dass der Umweg über Postfix eigentlich nicht notwendig ist. An dem Punkt gibts nur 2 Probleme

1. Was kommt im Feld "arguments" rein?
2. Wie wird die Mail an das passende (!) Postfach zugestellt, bzw. wie/wo/von wem wird das Postfach ermittelt?

Zu 2. konnte ich finden, dass das wohl über einen sieve-Filter möglich ist, dem Beispiel entsprechend wie es 'weshalb' gepostet hat. Das Filter-Regeln verwendet werden und wo sie zu finden sind wird in der dovecot.conf eingetragen, lt. Web-Beispiele und weshalb's sehr ähnlichem Beispiel sieht das so aus:

Code: Alles auswählen

protocol lmtp {
  mail_plugins = $mail_plugins sieve
}
plugin {
   sieve = ~/.dovecot.sieve
   sieve_default = /var/lib/dovecot/sieve/default.sieve
   sieve_global = /var/lib/dovecot/sieve/global/
}

Mein Problem ist,dass ich im Moment nicht mehr die Zusammenhänge erfasse... weil ich keine Aussagen finde, darüber was muss oder was kann und wie überhaupt. Mir kommt es nur so komisch vor, wenn ich die Mails via Getmail runterlade, um sie dann an Postfix weiter zu reichen, der sie dann doch an Dovecot-lmtpd übergibt..... dem Dovecot-DA kanns doch eigentlich egal sein, von wem er die Post bekommt, dass geht ja (siehe oben) auch direkt von Getmail. Und Postfix selber selektiert ja auch nicht das schlussendlich richtige Postfach... das muss doch sowieso der LDA übernehmen.

Kerkerker... ist das kompliziert......


Das ist absolut clever:
https://listen.jpberlin.de/pipermail/do ... 00626.html

... erinnert mich an den Touristen, der fragt "Entschuldigung, kennen Sie den Weg nach sowieso" und der gefragte antwortet "Ja!" und geht weiter....

[weshalb]

2. Wie wird die Mail an das passende (!) Postfach zugestellt, bzw. wie/wo/von wem wird das Postfach ermittelt?

Ich denke mal durch getmail selbst, denn woher soll dovecot das wissen?

In Fetchmail, was ich immer noch benutze, sieht das so aus:

poll pop3.strato.de protocol pop3 user "user@emailadresse" there with password "Passwort" is "user@servername" here ssl

Edit: Ich habe jetzt einfach mal in fetchmail die Zuordnung zum User auf den Server weggelassen. Fetchmail holt die Mail ab und es beginnt das übliche Prozedere mit postfix, spamassassin und clamsmtpd, doch sie wird immer wieder an fetchmail zurück ausgeliefert und verschwindet dann im nirgendwo. Die Zurordnung der User zu den Mailboxen scheint also bei mir zumindest auf MRA Ebene stattzufinden.

[TomL]

Ich denke mal durch getmail selbst, denn woher soll dovecot das wissen?

In Fetchmail, was ich immer noch benutze, sieht das so aus:

Code: Alles auswählen

poll pop3.strato.de protocol pop3 [b]user "user@emailadresse" there[/b] with password "Passwort" [b]is "user@servername" here[/b] ssl

Es scheint so,als wäre es mit getmail das gleiche. Aber mittlerweile bin ich an einem Punkt angekommen, an dem es mich überfordert. Eigentlich war ja die Absicht, dass ich eine bessere Verarbeitung bezogen auf procmail erreichen wollte... deswegen ja auch die erste Überlegung nach maildrop zu wechseln.

Aber bei keiner Maßnahme habe ich das Gefühl, jetzt funktionierts und ist sogar besser als zuvor. Ich habe als Test mal novalix Vorschlag aufgegriffen und die Mails via postfix an den dovecot-lda geleitet... ja klappt... damit würde ich dann procmail gar nicht mehr benötigen. Aber wenn ich anschließend nach der Zustellung die Mailheader vergleiche, einmal via procmail zugestellt, die andere über postfix... dann sehe ich, dass die via procmail anscheinend "untouched" ist, und die via postfix um eine weitere Sende-Etappe erweitert wurde. Das ist wahrscheinlich nix schlimmes und man muss sich da vermutlich keinen Kopp drum machen.... aber was passiert mit diesen lokalen Informationen über mein Netz im "Antwort-Modus" oder beim "Weiterleiten"? Was wird dann alles mitgesendet? Also habe ich das erst Mal wieder rückgängig gemacht.

Die Versuche mti Getmail direkt zuzustellen gehen gar nicht.... no permissions.... ich kann nur nicht herausfinden, welche fehlen, oder für wen... auf die lokalen IMAP-Dirs ...?... auf den Auth-Socket...?... auf die dovecot-userdb...?... auf setuid für irgendwas... fehlen die Rechte für den User getmail, oder für den User, dessen UID verwendet wird...?... keine Ahnung. Die Fehlermeldungen 67 und 75 für irgendeine Deliver-Command-Nr sagen überhaupt nix.

Vor dem Hintergrund, wie einfach und zuverlässig das mit Procmail funktioniert, frage ich mich mittlerweile, ob man das überhaupt verbessern kann.

[weshalb]

Ja und hast du denn nun mal probiert, ob die direkte Übergabe an dovecot geht?

[TomL]

Ja und hast du denn nun mal probiert, ob die direkte Übergabe an dovecot geht?

Ja, sicher:

Die Versuche mti Getmail direkt zuzustellen gehen gar nicht.... no permissions...

Ich gehe mal davon aus, dass 'ich' resp. der Getmail startende User keine Rechte hat. Getmail wird zwar als "root" gestartet, führt aber einen Setuid auf die UID des entsprechenden Anwenders aus.... und das lehnt Dovecot ab. Dovecot kennt ja nur seine eigenen virtuellen User, Getmail verwendet aber die Linux-UID der User. Das es mit Postfix klappt, ist nicht weiter verwunderlich, weil Postfix den Auth-Socket bedienen kann und im Dovecot-Service als User und Gruppe berechtigt ist, was die User eben nicht sind. Das ist wahrscheinlich die Problemursache. Ich denke, dass ich das lösen könnte, in dem ich einfach eine passende Gruppe für den Service definieren würde... aber je mehr ich darüber nachdenke, umso fragwürdiger erscheinen mir die Vorteile.

Sowohl die Verwendung von Postfix (bzw. auch scientific's exim) zur letztendlichen Zustellung ins Postfach als auch die Zustellung via Getmail erfordern zwingend den Einsatz von Sieve... was ich jetzt ja gar nicht benötige. Mir ist das gestern abend vor dem Einschlafen auf einmal bewusst geworden. Es wird bei diesen Modellen immer die abgeholte Post vollständig ins Postfach zugestellt, einschließlich Spam. Das heisst, ich benötige dann Prozesse, die diesen Müll wieder entsorgen, also muss/sollte ich einen Filter installieren - wie z.B. Sieve.

Mit der Zustellung durch Procmail habe ich dieses Spam-Problem gar nicht erst. Die ganze Zustellung ist schnell, schnörkellos, direkt und im (anfangs ungeplanten) Nebeneffekt sofort gefiltert... 9 von 10 Spammails kommen also gar nicht erst in den Inboxes an. Der Grund dafür ist, dass ich nur die Mails zustelle, die meine echte EMail-Adresse in "to" oder "cc" enthalten, alles andere geht sofort in den Spam-Ordner des User-Postfachs. Das ist quasi ein umgekehrter (!) Filter. Ich filtere nicht Spam, sondern leite nur korrekt addressierte Post weiter - und genau diese Eigenschaft fehlt in 9 von 10 Spammails, die enthalten nämlich irgendwas in "to" oder "cc", aber fast nie meine echte Adresse. Mit diesem Verfahren ist das Spam-Problem ohne Zusatztools quasi vollständig gelöst. Dann gibts noch einen kleinen nichtbehandelten Rest, aber den regelt wieder Thunderbird sehr zufriedenstellend mit seiner Spam-Lernfunktion. Der Status Quo ist 'Spam ist derzeit kein Ballast'. Würde ich nun mit Postfix oder Getmail zustellen, ist dieser Effekt nicht mehr gegeben und ich brauche wieder die Zusatztools.

Ich schließe das jetzt hier als "gelöst" und werde die Installation so lassen, wie sie ist. Ich kanns drehen und wenden wie ich will, ich erkenne bei keiner Veränderung eine Verbesserung.

[scientific]

Mailinglisten kommen mit deinem Setup also nicht an. Damit würde bei mir rund die Hälfte der von mir erwünschten Emails im Spamordner bleiben...

Ich liefere die mit fetchmails geholten Emails bei exim ab, dort erfahren sie eine Spambehandlung (kennzeichnung in den Headern als Spam oder Ham) und exim liefert diese dann lokal bei dovecot (MDA) ab. Dovecot filtert mit Sieve anhande der Header die Spams in den Junkordner und die anderen anhand anderer Filterregeln in die IMAP-Ordner und - Unterordner der lokalen User.

False Negatives und False Positives sortiere ich im Thunderbird nachher um.
Täglich lasse ich Bogofilter den Spam und Ham täglich lernen. Die Erkennung läuft gut. Hab kaum mehr false negatives und positives mehr.
Zusätzlich hab ich spamassassin-Filter von Heinlein aktiv, die auch täglich geupdates werden.

Ich nutze auch die Klassifikation meiner Mailprovider.

Eine Veränderung der Header durch meinen Mailserver finde ich nicht weiter tragisch. Denn aldebaran@localhost ist sicher keine geschützte Domain, wo ich Probleme beim Antworten bekommen kann...

Lg scientific

[TomL]

Mailinglisten kommen mit deinem Setup also nicht an.

Das weiss ich im Moment nicht, weil ich mich damit noch nicht befasst habe. Wenn die Posts der Mailinglist ein gemeinsames Kennzeichen im Header haben, kann ich sie auch an ein bestimmtes Postfach zustellen. Haben sie ein gemeinsames Kennzeichen, in "from", "to" oder einem anderen definiertem Standardfeld? Wenn ja, ist das kein Problem - procmail kann bestens unterschiedlichste Filterregeln beachten.

Dieser Bogofilter und die Spambehandlung ist genau die Nachbearbeitung, die bei mir nicht notwendig ist. Ich brauche das nicht, weils eben nix nachzubearbeiten gibt. Aber das weiter zu erörtern ist unfruchtbar. Andere Anforderungen, andere Lösungen.

[weshalb]

und genau diese Eigenschaft fehlt in 9 von 10 Spammails, die enthalten nämlich irgendwas in "to" oder "cc"

Ich bin eben stichprobenartig die als Spam erkannten Mails eines kleinen Büros durchgegangen und kann deine Aussage nicht bestätigen. Da ist es eher umgekehrt.

Edit:

Mit diesem Verfahren ist das Spam-Problem ohne Zusatztools quasi vollständig gelöst. Dann gibts noch einen kleinen nichtbehandelten Rest, aber den regelt wieder Thunderbird sehr zufriedenstellend mit seiner Spam-Lernfunktion.

Also doch ein Zusatztool und dann noch ein clientseitiges? Ich mache das eben lieber serverseitig, was wiederrum Vorteile bei der Anbindung mehrerer Clients hat.

Ich verstehe jetzt auch noch nicht so richtig, inwiefern du weniger Tools(Schnickschnack) einsetzt. Du nutzt Getmail, Postfix, Dovecot ,Procmail und einen Spamfilter auf deinem Rechner.

Ich nutze für deine anberaumten Aufgaben Fetchmail, Postfix, Dovecot, Sieve und einen Spamfilter auf dem Server.

[TomL]

Also doch ein Zusatztool und dann noch ein clientseitiges?

Nein, nur Thunderbird, ohne Erweiterungen. Warum es funktioniert, weiss ich nicht.... aber hier funktioniert es zufriedenstellend.

[scientific]

Thunderbird hat einen eingebauten Spamfilter.

Alternativ kann man noch anhaken "Spamassassin vertrauen" oder so ähnlich. Dann nimmt TB die Header eines allfällig laufenden Spamassassin zum aussortieren von Spam und nicht den eingebauten bayesian Filter.

Ein anderer Client hat ev. keinen eingwbauten Spamfilter, damit funktioniert dein Konzept auch nicht mehr.

Was machst du übrigens mit Mails, wo du gewollterweise im BCC bist? Die landen bei dir auch im Spam...

Schätze mal, dein Setup klappt nur zufälligerweise gut, weil die Gewohnheiten deiner User momentan zum Setup passen. Ändert einer deiner User diese, kommen seine Mails nicht mehr an...

Aber du weißt eh, was du tust.

[TomL]

Was machst du übrigens mit Mails, wo du gewollterweise im BCC bist? Die landen bei dir auch im Spam...

Nein, tun sich nicht. Allerdings hatte ich daran bisher wirklich gar nicht gedacht und habs deshalb sofort probiert.... die Mails kommen tadellos an. Ich denke also weiterhin, dass meine vorhandenenen Filterregeln anscheinend doch korrket sind.

... kommen seine Mails nicht mehr an

So ein Unsinn... es gehen bei mir überhaupt keine Mails verloren. Das war sogar eine der primären Anforderungen und einer der Gründe, warum ich keinen Serverfilter will. Ausserdem hatte ich Dir genau das schon mal an anderer Stelle erklärt, warum ich keine serverseitige Beurteilung will, was der Anwender zu sehen bekommt und was nicht.

Ich hatte den Thread bereits auf gelöst gesetzt. Deshalb würde ich das jetzt hier gerne -soweit es mich betrifft- beenden... wir nähern uns nämlich wieder dem Pudding, der an die Wand genagelt werden soll und dem Lamentieren über Mutmaßungen und Probleme, die hier nicht mal theoretisch Probleme sind.

[scientific]

Dann hast du uns aber wesentliche infos vorenthalten. Du schriebst, dass du nur emails zustellst, die eine gültige lokale Adresse als to oder cc haben... Und jetzt schreibst du etwas anderes... Wo wir dich drauf aufmerksam gemacht haben.

Aber egal.

[TomL]

Dann hast du uns aber wesentliche infos vorenthalten. Du schriebst, dass du nur emails zustellst, die eine gültige lokale Adresse als to oder cc haben...

Sorry... nicht verärgert sein. Dein Hinweis war sogar sehr wichtig und dafür bin ich dankbar... ich habe diesen Fall nämlich wirklich übersehen.

Mein Filter behandelt "to" und "cc", Blind-CC habe ich schlichtweg vergessen. Irritierend ist jetzt für mich, das die BCC trotzdem absolut korrekt angekommen ist. Deshalb hatte ich mir sowieso vorgenommen, meinen Filter noch mal zu prüfen. Ich war der Meinung, dass mein RegEx-Ausdruck ab Zeilenanfang prüft.... und BCC ist eben nicht CC am Zeilenanfang. Das werde ich dieser Tage mal genauer untersuchen.

Ich will nur nicht mehr über den Sinn oder Unsinn von Tun oder Nichtun diskutieren. Letzten Endes ist das die richtige Lösung, bei der hinten genau das rauskommt, was man erwartet und was man vorgegeben hat. Warum BCC jetzt nicht fehlerhaft gelaufen ist, werde ich jedenfalls prüfen. Und der Hinweis war wirklich ok.

[TomL]

Das hat mir jetzt doch keine Ruhe gelassen.... BCC hätte eigentlich bei diesem Ausdruck "^TO_" fehlerhaft behandelt werden müssen... wurde es aber nicht.

"^TO_" ist verwirrenderweise nicht nur ein ab Zeilenanfang suchender Regex-Ausdruck (wovon ich bisher überzeugt war), sondern auch noch ein spezielles Procmail-Macro für genau diesen Fall, welches einen RegEx-Ausdruck generiert, der alle möglichen Varianten von "to:" erfasst, bei mir eben auch den von GMX generierten Envelope-Eintrag, damit die BCC-Mail überhaupt ankommen kann. Ich bin mal wieder positiv überrascht... und man lernt nie aus.