procmail filtert heute keine Mails von der Liste
Moin Liste, ich habe hier ein sehr merkwürdiges Problem: Seit heute landen alle Mails von der Liste nicht mehr im entsprechenden Postfach sondern landen in meiner inbox. Hat jemand ähnliches bemerkt, hat sich am Header der Listenmails entscheidendes geändert? ich filtere mit folgendem procmail-filter: :0f * ^TO*suse-linux* Mail/suse Aber das funktioniert nicht mehr. Ich habe das übrigens auf zwei Rechnern unabhängig voneinander festgestellt. Weder auf meinem Laptop noch auf meinem Desktop-PC wird richtig gefiltert. Die letzte auf beiden Rechnern richtig gefilterte Mail hatte die ID: <27292.1086213822@joergli.vollmer.local> Das Filterkriterium ist aber nach meinem Verständnis doch nach wie vor erfüllt. Die Listenmails gehen doch noch immer an suse-linux@suse.com. Hat jemand ein Idee oder stehe ich gerade ganz und gar auf dem Schlauch? Gruß Hannes
Hallo, Am Thu, 03 Jun 2004, Hannes Vogelmann schrieb:
ich filtere mit folgendem procmail-filter:
:0f
Das ist keine Filterregel!
* ^TO*suse-linux* Mail/suse
Verwende doch MAILDIR=$HOME/Mail am Anfang der procmailrc, statt das Mail ueberall anzugeben... ==== :0 * ^X-Mailinglist:.*suse-linux$ Mail/suse ==== -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Hallo David, Am Don, 03 Jun 2004, schrieb David Haller:
Hallo,
Am Thu, 03 Jun 2004, Hannes Vogelmann schrieb:
ich filtere mit folgendem procmail-filter:
:0f
Das ist keine Filterregel!
Bisher hat das funktioniert, und ich habe noch unzählige andere Filter die genauso aufgebaut sind, und die funktionieren auch. Nur dieser suse-Filter tut nicht mehr. man procmailrc sagt: f Consider the pipe as a filter Oder mache ich mir da ein falsches Bild?
* ^TO*suse-linux* Mail/suse
Verwende doch
MAILDIR=$HOME/Mail
OK, wär ne Sache.
am Anfang der procmailrc, statt das Mail ueberall anzugeben...
==== :0 * ^X-Mailinglist:.*suse-linux$ Mail/suse ====
Hmmm, nutzt leider nix. Die Mails werden auch so noch bis zum letzten Filter (eigentlich kein Filter sondern eine finale Umleitung) durchgereicht, der da heißt: :0: * ^TO* Mail/inbox Gruß Hannes
Hallo, Am Thu, 03 Jun 2004, Hannes Vogelmann schrieb:
Am Don, 03 Jun 2004, schrieb David Haller:
Am Thu, 03 Jun 2004, Hannes Vogelmann schrieb:
ich filtere mit folgendem procmail-filter:
:0f
Das ist keine Filterregel!
man procmailrc sagt:
f Consider the pipe as a filter
Oder mache ich mir da ein falsches Bild?
Das f ist nur interessant, wenn man die Mail in einer Pipe an ein Programm weiterreicht, z.B. an formail: :0 f * foo | formail -A 'X-foo: ' Interessant dabei ist, dass durch eine Filterregel die Mails durchwandern und _nicht_ einsortiert werden. Was procmail ohne die Pipe macht weiss ich nicht.
:0 * ^X-Mailinglist:.*suse-linux$ Mail/suse
Hmmm, nutzt leider nix. Die Mails werden auch so noch bis zum letzten Filter (eigentlich kein Filter sondern eine finale Umleitung) durchgereicht, der da heißt:
:0: * ^TO* Mail/inbox
Das ist falsch. Wie uebrigens auch deine Originale RE. Procmail verwendet Extendet Regular-Expressions wie egrep, siehe dazu man 7 regex. Als finale Umleitung brauchst du eh keine Bedingung, und mit gesetztem MAILDIR also nur: :0 inbox Mein Filter funktioniert definitiv. Es sei denn du hast 'MAILDIR' falsch gesetzt oder so. Schreib mal 'VERBOSE=on' vor die erste Regel in die procmailrc und definier mit LOGFILE= eine Logdatei und lass ein 'tail -f' auf diese Logdatei los, wenn du mails einsortieren willst. Schick mir im Zweifelsfall mal per PM die komplette procmailrc. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
Hallo David, jetz habe ich möglicherweise herausgefunden, wo hier der Hund begraben liegt. Kann es sein, dass procmail nichts mehr einsortiert, wenn eine Mailbox eine bestimmte Größe überschritten hat? Ich habe jetzt mal testhalber eine neue und leere Mailbox Namens suse erstellt, und siehe da, es tut wieder, sowohl mit Deinem als auch mit meinem Filter. Auf beiden Rechnern war die Mailbox exakt gleichen Inhalts und etwa 50MB groß. Am Don, 03 Jun 2004, schrieb David Haller:
Hallo,
Am Thu, 03 Jun 2004, Hannes Vogelmann schrieb:
Am Don, 03 Jun 2004, schrieb David Haller:
Am Thu, 03 Jun 2004, Hannes Vogelmann schrieb:
ich filtere mit folgendem procmail-filter:
:0f
Das ist keine Filterregel!
man procmailrc sagt:
f Consider the pipe as a filter
Oder mache ich mir da ein falsches Bild?
Das f ist nur interessant, wenn man die Mail in einer Pipe an ein Programm weiterreicht, z.B. an formail:
:0 f * foo | formail -A 'X-foo: '
Interessant dabei ist, dass durch eine Filterregel die Mails durchwandern und _nicht_ einsortiert werden. Was procmail ohne die Pipe macht weiss ich nicht.
scheint dann wohl so zu funktionieren, als wäre das f nicht da.
:0 * ^X-Mailinglist:.*suse-linux$ Mail/suse
Hmmm, nutzt leider nix. Die Mails werden auch so noch bis zum letzten Filter (eigentlich kein Filter sondern eine finale Umleitung) durchgereicht, der da heißt:
:0: * ^TO* Mail/inbox
Das ist falsch. Wie uebrigens auch deine Originale RE. Procmail verwendet Extendet Regular-Expressions wie egrep, siehe dazu man 7 regex. Als finale Umleitung brauchst du eh keine Bedingung, und mit gesetztem MAILDIR also nur:
:0 inbox
Gut sehe ich ein, allerdings ist mir jetzt nicht klar, warum es den zweiten Doppelpunkt nicht braucht. Man procmailex sagt doch in seinem ersten Beispiel: :0: * ^TOscuba scubafile Was ist da der entscheidende Unterschied?
Mein Filter funktioniert definitiv. Es sei denn du hast 'MAILDIR' falsch gesetzt oder so. Schreib mal 'VERBOSE=on' vor die erste Regel in die procmailrc und definier mit LOGFILE= eine Logdatei und lass ein 'tail -f' auf diese Logdatei los, wenn du mails einsortieren willst.
Stimmt, der funktioniert. Allerdings kann ich den Fehler jetzt nicht mehr reproduzieren, weil ich die Mailbox entrümpelt habe und jetzt ist sie so klein, dass der Fehler eben nicht mehr auftritt. Da müssen erst wieder ein paar Monate Listenmails auflaufen. Gute Nacht, Hannes
Hallo, Am Fri, 04 Jun 2004, Hannes Vogelmann schrieb:
jetz habe ich möglicherweise herausgefunden, wo hier der Hund begraben liegt. Kann es sein, dass procmail nichts mehr einsortiert, wenn eine Mailbox eine bestimmte Größe überschritten hat?
Kann ich mir nicht vorstellen. Auch mein angestaubtes $ procmail -v 2>&1 | head -1 procmail v3.13.1 1999/04/05, Copyright (c) 1999, Stephen R. van den Berg hat mit mailboxen von > 300 MB und > 50k Mails absolut keine Probleme. BTW: mein aktuelles suse-linux ist gerade 56 MB gross... Ich koennte mir aber vorstellen, dass mein procmail noch keinen largefile-support hat und somit bei > 2GB scheitern wuerde ;)
Ich habe jetzt mal testhalber eine neue und leere Mailbox Namens suse erstellt, und siehe da, es tut wieder, sowohl mit Deinem als auch mit meinem Filter. Auf beiden Rechnern war die Mailbox exakt gleichen Inhalts und etwa 50MB groß.
50 MB??? *ding* *da war doch was...* Kann es sein, dass du in postfix(!) die Mailbox-Groesse auf dem default (eben ca. 50 MB) gelassen hast? Warum postfix allerdings "wegsortierte" mboxen interessieren sollten waere mir auch schleierhaft.
Am Don, 03 Jun 2004, schrieb David Haller:
Am Thu, 03 Jun 2004, Hannes Vogelmann schrieb:
Am Don, 03 Jun 2004, schrieb David Haller:
Am Thu, 03 Jun 2004, Hannes Vogelmann schrieb:
ich filtere mit folgendem procmail-filter:
:0f
Das ist keine Filterregel!
man procmailrc sagt:
f Consider the pipe as a filter
Oder mache ich mir da ein falsches Bild?
Das f ist nur interessant, wenn man die Mail in einer Pipe an ein Programm weiterreicht, z.B. an formail:
:0 f * foo | formail -A 'X-foo: '
Interessant dabei ist, dass durch eine Filterregel die Mails durchwandern und _nicht_ einsortiert werden. Was procmail ohne die Pipe macht weiss ich nicht.
scheint dann wohl so zu funktionieren, als wäre das f nicht da.
Das nehme ich auch an -- bzw. hoffe es ;)
:0 * ^X-Mailinglist:.*suse-linux$ Mail/suse
Hmmm, nutzt leider nix. Die Mails werden auch so noch bis zum letzten Filter (eigentlich kein Filter sondern eine finale Umleitung) durchgereicht, der da heißt:
:0: * ^TO* Mail/inbox
Das ist falsch. Wie uebrigens auch deine Originale RE. Procmail verwendet Extendet Regular-Expressions wie egrep, siehe dazu man 7 regex. Als finale Umleitung brauchst du eh keine Bedingung, und mit gesetztem MAILDIR also nur:
:0 inbox
Gut sehe ich ein, allerdings ist mir jetzt nicht klar, warum es den zweiten Doppelpunkt nicht braucht. Man procmailex sagt doch in seinem ersten Beispiel:
:0: * ^TOscuba scubafile
Was ist da der entscheidende Unterschied?
==== man procmailrc ==== :0 [flags] [ : [locallockfile] ] [..] Local lockfile If you put a second (trailing) ':' on the first recipe line, then procmail will use a locallockfile (for this recipe only). You can optionally specify the locallock file to use; if you don't however, procmail will use the destination filename (or the filename following the first '>>') and will append $LOCKEXT to it. ==== Da ich ein globales lockfile spezifiziert habe (wo weiss ich grad nicht) bekomme ich mit dem 2ten ':' immer eine Fehlermeldung im log, dass schon ein lockfile verwendet wird (oder so aehnlich, hab grad kein aelteres procmail.log da). Verwende im Zweifelsfall den Doppelpunkt nach den [optionalen] Flags, das muellt dir im schlimmsten Falle das logfile mit o.g. Meldungen voll. Also: :0: inbox waere die "catchall" Regel am Ende der procmailrc (aequivalent kann man auch einfach z.B. "DEFAULT=$MAILDIR/inbox" definieren -- ich hab aber trotz DEFAULT obige "catchall" Regel ;)).
Mein Filter funktioniert definitiv. Es sei denn du hast 'MAILDIR' falsch gesetzt oder so. Schreib mal 'VERBOSE=on' vor die erste Regel in die procmailrc und definier mit LOGFILE= eine Logdatei und lass ein 'tail -f' auf diese Logdatei los, wenn du mails einsortieren willst.
Stimmt, der funktioniert. Allerdings kann ich den Fehler jetzt nicht mehr reproduzieren, weil ich die Mailbox entrümpelt habe und jetzt ist sie so klein, dass der Fehler eben nicht mehr auftritt. Da müssen erst wieder ein paar Monate Listenmails auflaufen.
s.o. -dnh -- If you haven't got time to RTFM, you haven't got time to whine on this mailing list.
participants (2)
-
David Haller -
Hannes Vogelmann