[gelöst] maildrop vs. procmail

Debian macht sich hervorragend als Web- und Mailserver. Schau auch in den " Tipps und Tricks"-Bereich.
Benutzeravatar
weshalb
Beiträge: 1265
Registriert: 16.05.2012 14:19:49

Re: maildrop vs. procmail

Beitrag von weshalb » 01.07.2017 15:04:58

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

Re: maildrop vs. procmail

Beitrag von TomL » 01.07.2017 18:46:32

weshalb hat geschrieben: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.

:roll:

Benutzeravatar
weshalb
Beiträge: 1265
Registriert: 16.05.2012 14:19:49

Re: maildrop vs. procmail

Beitrag von weshalb » 01.07.2017 22:25:51

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

TomL

Re: maildrop vs. procmail

Beitrag von TomL » 02.07.2017 10:32:20

weshalb hat geschrieben: ↑ zum Beitrag ↑
01.07.2017 22:25:51
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
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] maildrop vs. procmail

Beitrag von scientific » 02.07.2017 11:40:02

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
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: [gelöst] maildrop vs. procmail

Beitrag von TomL » 02.07.2017 12:36:09

scientific hat geschrieben: ↑ zum Beitrag ↑
02.07.2017 11:40:02
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.

Benutzeravatar
weshalb
Beiträge: 1265
Registriert: 16.05.2012 14:19:49

Re: [gelöst] maildrop vs. procmail

Beitrag von weshalb » 03.07.2017 09:32:28

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

Re: [gelöst] maildrop vs. procmail

Beitrag von TomL » 03.07.2017 10:47:35

weshalb hat geschrieben: ↑ zum Beitrag ↑
03.07.2017 09:32:28
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
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] maildrop vs. procmail

Beitrag von scientific » 03.07.2017 15:27:08

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.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: [gelöst] maildrop vs. procmail

Beitrag von TomL » 03.07.2017 16:50:28

scientific hat geschrieben: ↑ zum Beitrag ↑
03.07.2017 15:27:08
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
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: [gelöst] maildrop vs. procmail

Beitrag von scientific » 03.07.2017 17:38:07

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.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

TomL

Re: [gelöst] maildrop vs. procmail

Beitrag von TomL » 03.07.2017 19:37:49

scientific hat geschrieben: ↑ zum Beitrag ↑
03.07.2017 17:38:07
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

Re: [gelöst] maildrop vs. procmail

Beitrag von TomL » 03.07.2017 21:27:13

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.

Antworten