[gelöst] maildrop vs. procmail

[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.