[Procmail] Regel speichert Mail, aber Mail ist weg.

[Michael Uplawski]

Guten Abend.

Ich habe diese Regel in meiner .procmailrc:
---------------
# accepted From addresses : do not filter
:0H
* ? grep -Fxi "$FROMTEST" "$ACCEPTLIST"
* !FROM_DAEMON
* !FROM_MAILER
/home/michael/Mail/inbox
---------------

Die beiden Variablen sind
FROMTEST=`formail -rtzxTo:`
ACCEPTLIST=$PMDIR/acceptlist

„acceptlist“ ist eine Datei mit Adressen, jeweils eine pro Zeile.

Nun zeigt mein Procmail-Log das Folgende an:
-----------------------
procmail: No match on "^(To|Cc):(.*\<)?mailing...@ding.org"
procmail: No match on "^(To|Cc):(.*\<)?mailing...@ding2.org"
procmail: No match on "^Subject:(.*)?.*Nature et Progrès.*"
procmail: Assigning "ACCEPTLIST=/home/michael/.procmail/acceptlist"
procmail: Executing "formail,-rtzxTo:"
procmail: Assigning "FROMTEST=eine.a...@irgendwo.tld"
procmail: Match on "^From:.*eine.a...@irgendwo.tld"
procmail: Assigning "LASTFOLDER=/home/michael/Mail/inbox"
procmail: Opening "/home/michael/Mail/inbox"
procmail: Acquiring kernel-lock
procmail: [1458] Thu Feb 23 17:54:38 2023
procmail: Notified comsat: "michael@12019325:/home/michael/Mail/inbox"
From eine.a...@irgendwo.tld Thu Feb 23 17:54:37 2023
Subject: =Gott sei Dank nichts Wichtiges=
Folder: /home/michael/Mail/inbox
-------------------------

In der Inbox finde ich alle neuen Mails, die Procmail ohnehin unbeschadet
überstehen, nur *nicht diese hier!* Das passiert jetzt immer öfter, ich
muss davon ausgehen, dass meine Regel kaputt ist.

Normalerweise mache ich bei solchen Regeln nur dämliche Fehler, die ich
dann nicht finde, weil ich ernsthaft nach komplizieren Sachverhalten
suche. In der Regel fehlen irgendwelche Symbole oder einzelne Buchstaben
irgendwo.

Sicher ist es auch diesmal wieder so. Habt Ihr bessere Augen als ich? Ich
erinnere mich daran, dass diese Acceptlist-Geschichte schon mal
funktioniert hat... „Aba ich hab' überhaups gar nix gemacht“ will ich
nicht schreiben, nur dass ich keine Ahnung habe.

Danke und schönen Abend.

Michael

[Michael Uplawski]

Thu, 23 Feb 2023 17:20:28 -0000 (UTC) / Michael Uplawski:

Verzeihung, die Zeilenumbrüche im OP sind kaputt. Ich versuche das
nochmal:

[Michael Uplawski]

Okay. Pan kann nicht superseden, nicht canceln und macht meine Code-
Fragmente kaputt.

Lasst es bleiben, mir fällt nichts mehr ein.

[Markus Schaaf]

Am 23.02.23 um 18:20 schrieb Michael Uplawski:

> Guten Abend.
>
> Ich habe diese Regel in meiner .procmailrc:
> ---------------
> # accepted From addresses : do not filter
> :0H
> * ? grep -Fxi "$FROMTEST" "$ACCEPTLIST"
> * !FROM_DAEMON
> * !FROM_MAILER
> /home/michael/Mail/inbox
> ---------------

Du lieferst an eine Datei, aber benutzt kein Lockfile. Nun wäre
es seltsam, wenn das immer ein Problem verursacht, aber wer weiß.
Vielleicht brauchst Du auch ein 'w' -- Ich habe keine Ahnung mehr
von procmail. :-)

MfG

[Michael Uplawski]

Thu, 23 Feb 2023 18:46:29 +0100 / Markus Schaaf:

>> Ich habe diese Regel in meiner .procmailrc:
>> ---------------
>> # accepted From addresses : do not filter
>> :0H
>> * ? grep -Fxi "$FROMTEST" >> "$ACCEPTLIST"
>> * !FROM_DAEMON
>> * !FROM_MAILER
>> /home/michael/Mail/inbox
>> ---------------
>
> Du lieferst an eine Datei, aber benutzt kein Lockfile. Nun wäre es
> seltsam, wenn das immer ein Problem verursacht, aber wer weiß.

Danke für das Stichwort.
Ich kann noch nicht sagen, ob das alles ist, aber ein Test macht mir schon
mal Hoffnung. Procmail verwendet das Lock automatisch nur, wenn in die
“System-Mailbox” geschrieben wird ($DEFAULT per default). Ich
identifiziere damit /var/mail/[user] und habe meine Regel angepasst.

Statt inbox, wird nach /var/mail/[user] geschrieben.

Das tut erstmal nicht weh, ich werde Ausschau halten, bis der erste
Treffer erzielt wird.

Cheerio

Michael
--
Whatever you do – try to have a reason to do it
(Winston Groom/Forrest Gump)

[Christoph Brinkhaus]

Michael Uplawski <michael....@uplawski.eu> schrieb:

Hallo Michael,

> Thu, 23 Feb 2023 18:46:29 +0100 / Markus Schaaf:
>
>>> Ich habe diese Regel in meiner .procmailrc:
>>> ---------------
>>> # accepted From addresses : do not filter
>>> :0H
>>> * ? grep -Fxi "$FROMTEST" >> "$ACCEPTLIST"
>>> * !FROM_DAEMON
>>> * !FROM_MAILER
>>> /home/michael/Mail/inbox
>>> ---------------
>>
>> Du lieferst an eine Datei, aber benutzt kein Lockfile. Nun wäre es
>> seltsam, wenn das immer ein Problem verursacht, aber wer weiß.
>
> Danke für das Stichwort.
> Ich kann noch nicht sagen, ob das alles ist, aber ein Test macht mir schon
> mal Hoffnung. Procmail verwendet das Lock automatisch nur, wenn in die
> “System-Mailbox” geschrieben wird ($DEFAULT per default). Ich
> identifiziere damit /var/mail/[user] und habe meine Regel angepasst.
>
> Statt inbox, wird nach /var/mail/[user] geschrieben.
>
> Das tut erstmal nicht weh, ich werde Ausschau halten, bis der erste
> Treffer erzielt wird.

Nur als Hinweis aus meiner Erinnerung:
Im procmail "Paket" gibt es ein Programmi formail, mit dem man mbox Dateien
wieder in procmail einspeisen kann.
Siehe https://www.trash.net/wissen/e-mail-2/procmail-howto/ ganz unten.
Mit dem Tool kann man sich das Warten ersparen.

Ein schönes Wochenende,
Christoph
--
Ist die Katze gesund
schmeckt sie dem Hund.

[Markus Schaaf]

Am 24.02.23 um 13:17 schrieb Michael Uplawski:

> Thu, 23 Feb 2023 18:46:29 +0100 / Markus Schaaf:
>
>>> Ich habe diese Regel in meiner .procmailrc:
>>> ---------------
>>> # accepted From addresses : do not filter
>>> :0H
>>> * ? grep -Fxi "$FROMTEST" >> "$ACCEPTLIST"
>>> * !FROM_DAEMON
>>> * !FROM_MAILER
>>> /home/michael/Mail/inbox
>>> ---------------
>>
>> Du lieferst an eine Datei, aber benutzt kein Lockfile. Nun wäre es
>> seltsam, wenn das immer ein Problem verursacht, aber wer weiß.
>
> Danke für das Stichwort.
> Ich kann noch nicht sagen, ob das alles ist, aber ein Test macht mir schon
> mal Hoffnung. Procmail verwendet das Lock automatisch nur, wenn in die
> “System-Mailbox” geschrieben wird ($DEFAULT per default). Ich
> identifiziere damit /var/mail/[user] und habe meine Regel angepasst.
>
> Statt inbox, wird nach /var/mail/[user] geschrieben.

Du kannst auch einfach das Flag angeben, welches Locking
aktiviert (ein Doppelpunkt):

:0:

(Wohingegen Du das `H` weglassen kannst, weil es default ist.)

MfG

[Michael Uplawski]

Fri, 24 Feb 2023 14:32:46 +0100 / Markus Schaaf:

> Du kannst auch einfach das Flag angeben, welches Locking aktiviert (ein
> Doppelpunkt):
>
> :0:
>
> (Wohingegen Du das `H` weglassen kannst, weil es default ist.)

Hervorrangend!
Die man-page musste ich schon mehrmals hervorholen, weil immer irgendwas
geklemmt hat. Den Wert Eurer Hinweise hier, könnt Ihr allerdings nur
unterschätzen. Ich weiß nicht, ob das daran liegt, dass *diese* man-page
schlechter geschrieben wäre, aber ich ziehe es ehrlich vor, wie oben auf 1
Ding pro Austausch gestoßen zu werden.

Den '?' Operator für Filter mit externen Programmen, zum Beispiel, habe
zig mal überlesen, bevor mir jemand ein ganzes Beispiel gezeigt hat.

Ehrlich! Auf einen verhunzten OP mehrere gute Antworten zu bekommen... das
war in de.* nicht immer so.

Schönes Wochenende!

Michael.
Cheerio oder was.

[Matthias Andree]

Am 23.02.23 um 18:20 schrieb Michael Uplawski:

> Guten Abend.
>
> Ich habe diese Regel in meiner .procmailrc:

procmail ist ein Vierteljahrhundert nicht gepflegt und hat
schwerwiegende Entwurfsfehler. So muss jede Form von Fehlerbehandlung
nach jedem einzelnen Filterrezept von Hand eingefügt werden.

Wirf das procmail weg und nimm, zum Beispiel, maildrop. Du musst dann
die Filter umschreiben, aber das wird sich auszahlen.

[Michael Uplawski]

Matthias Andree wrote:
> Wirf das procmail weg und nimm, zum Beispiel, maildrop. Du musst dann
> die Filter umschreiben, aber das wird sich auszahlen.

Ich habe bereits daran gedacht. Nus sind alle bisher eingetretenen
Fehlersituationen auf meine eigene Unbedarftheit zurückzuführen und
entsprechend waren sie jedes Mal durch – beigesteuerten oder erlesenen –
Sachverstand ausgeräumt.

Freilich kann ein einfacheres Programm Schwierigkeiten vermeiden helfen.

Ich kenne aber jetzt Procmail (ein bisschen) und bezweifle noch, dass
Maildrop leicht nachbaut, was ich mir mühsam zurechtgebastelt habe.

Zwar sind wir jetzt off-topic, aber eine Frage wäre: Kann maildrop mit
externen Programmen filtern und mit externen Programmaufrufen reagieren?

Wenn nicht, welche Procmail-Alternative kann das?

Danke

Michael
--
Es ist an der Zeit

[Michael Uplawski]

Matthias Andree wrote:
> Wirf das procmail weg und nimm, zum Beispiel, maildrop. Du musst dann
> die Filter umschreiben, aber das wird sich auszahlen.

Ich habe bereits daran gedacht. Nur sind alle bisher eingetretenen

[Paul Muster]

On 27.02.23 20:08, Michael Uplawski wrote:

> Zwar sind wir jetzt off-topic, aber eine Frage wäre: Kann maildrop mit
> externen Programmen filtern und mit externen Programmaufrufen reagieren?

Es gibt "xfilter" und "system". Ob du damit deine derzeitige
Konstruktion bauen kannst, weiß ich nicht. Du könntest sie ja mal vorzeigen.


mfG Paul

[Michael Uplawski]

Moin.

Hier ein Filter, der sich eines Skriptes bedient. Es werden Received-
Header gegen eine Liste von IPs verglichen:
--------------------------------
# Filter ip-ranges: DELETE
:0
* !FROM_DAEMON
* !FROM_MAILER
* !^X-Loop: michael....@uplawski.eu
* 1^0 ? ip_in_range ~/.procmail/del_range_list.txt >> $LOGFILE
/dev/null
--------------------------------

“system” liest sich interessant. “xfilter” ist aber wohl das Äquivalent
zum '?' Operator ..?

Cheeerio

[Paul Muster]

On 28.02.23 06:28, Michael Uplawski wrote:

> Hier ein Filter, der sich eines Skriptes bedient. Es werden Received-
> Header gegen eine Liste von IPs verglichen:
> --------------------------------
> # Filter ip-ranges: DELETE
> :0
> * !FROM_DAEMON
> * !FROM_MAILER
> * !^X-Loop: michael....@uplawski.eu
> * 1^0 ? ip_in_range ~/.procmail/del_range_list.txt >> $LOGFILE
> /dev/null
> --------------------------------
>
> “system” liest sich interessant. “xfilter” ist aber wohl das Äquivalent
> zum '?' Operator ..?

xfilter scheint hier die Antwort zu sein. Dein Skript muss dazu die
gesamte E-Mail zurückgeben - ergänzt um einen Header, der im folgenden
Schritt dann ausgewertet wird. Also so, wie auch Spamassassin in
Maildrop eingebunden werden kann:

<https://cwiki.apache.org/confluence/display/SPAMASSASSIN/IntegratedInCourierUsingMaildrop>


mfG Paul

[Michael Uplawski]

Paul Muster wrote:
> > # Filter ip-ranges: DELETE
> > :0
> > * !FROM_DAEMON
> > * !FROM_MAILER
> > * !^X-Loop: michael....@uplawski.eu
> > * 1^0 ? ip_in_range ~/.procmail/del_range_list.txt >> $LOGFILE
> > /dev/null
> > --------------------------------
> >
> > “system” liest sich interessant. “xfilter” ist aber wohl das Äquivalent
> > zum '?' Operator ..?
>
> xfilter scheint hier die Antwort zu sein. Dein Skript muss dazu die
> gesamte E-Mail zurückgeben - ergänzt um einen Header, der im folgenden
> Schritt dann ausgewertet wird. Also so, wie auch Spamassassin in
> Maildrop eingebunden werden kann:

Das verlangt also nach einer weiteren Aktion. Bisher reicht mir der
Ergebniswert aus der Skriptverarbeitung (1 oder 0).
Bleibt als letzte Hürde der Fakt, dass ich die Maildrop-Sprache nicht
verstehe und einiges an Zeit inverstieren muss, bevor das funktionieren
kann.

Mal sehen. Jetzt gehe ich aber erst mal Obstbäume beschneiden.

Vielen Dank jedenfalls.

Cheerio

Michael

[Goetz Schultz]

Procmail hat mittlerweile ein Update bekommen. Ich setze es immer noch
ein, bevor ich mich mich anderen Filtern herumschlagen muss und
entsprechende Fehler wiederhole.

--

Cheers,
G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
/"\
\ / ASCII Ribbon Campaign
X against HTML e-mail
/ \
---------------------------->8------------------------------

[Michael Uplawski]

N'Abend.

Ich selber wrote:
> Ich habe diese Regel in meiner .procmailrc:

(...)

> Folder: /home/michael/Mail/inbox

> In der Inbox finde ich alle neuen Mails, die Procmail ohnehin unbeschadet
> überstehen, nur *nicht diese hier!*

Abschließend zur Bestätigung: Das fehlende File-Lock war hier die
Ursache, zwei Auswege bestehen:
1.) Mail in die „System-Mailbox“ schreiben (/var/mail/[irgendwas])
2.) Das Lock durch den zusätzlichen Doppelpunkt zu Beginn der
Regeldefinition durchsetzen:
------------
:0:
* [Filterregeln]
/home/user/[Maildatei]
------------

Vielen Dank nochmal. ;)

[Matthias Andree]

Am 27.02.23 um 20:08 schrieb Michael Uplawski:

> Matthias Andree wrote:
>> Wirf das procmail weg und nimm, zum Beispiel, maildrop. Du musst dann
>> die Filter umschreiben, aber das wird sich auszahlen.
>
> Ich habe bereits daran gedacht. Nur sind alle bisher eingetretenen
> Fehlersituationen auf meine eigene Unbedarftheit zurückzuführen und
> entsprechend waren sie jedes Mal durch – beigesteuerten oder erlesenen –
> Sachverstand ausgeräumt. >
> Freilich kann ein einfacheres Programm Schwierigkeiten vermeiden helfen.

Wäre es nicht zielführend, eine leichter verständliche und robustere
Software einzusetzen?

> Ich kenne aber jetzt Procmail (ein bisschen) und bezweifle noch, dass
> Maildrop leicht nachbaut, was ich mir mühsam zurechtgebastelt habe.
>
> Zwar sind wir jetzt off-topic, aber eine Frage wäre: Kann maildrop mit
> externen Programmen filtern und mit externen Programmaufrufen reagieren?

Wüsste nicht, warum das off-topic wäre.
Kann es, über xfilter oder backticks (DIR=`cat config.txt`) oder system.
-> man maildropfilter
-> man maildropex

[Matthias Andree]

Am 28.02.23 um 12:57 schrieb Goetz Schultz:

> On 27/02/2023 18:09, Matthias Andree wrote:
>> Am 23.02.23 um 18:20 schrieb Michael Uplawski:
>>> Guten Abend.
>>>
>>> Ich habe diese Regel in meiner .procmailrc:
>>
>> procmail ist ein Vierteljahrhundert nicht gepflegt und hat
>> schwerwiegende Entwurfsfehler.  So muss jede Form von Fehlerbehandlung
>> nach jedem einzelnen Filterrezept von Hand eingefügt werden.
>>
>> Wirf das procmail weg und nimm, zum Beispiel, maildrop.  Du musst dann
>> die Filter umschreiben, aber das wird sich auszahlen.
>>
>
> Procmail hat mittlerweile ein Update bekommen. Ich setze es immer noch
> ein, bevor ich mich mich anderen Filtern herumschlagen muss und
> entsprechende Fehler wiederhole.
>

Welches Update wäre das?

[Michael Uplawski]

Matthias Andree wrote:
> > Ich habe bereits daran gedacht. Nur sind alle bisher eingetretenen
> > Fehlersituationen auf meine eigene Unbedarftheit zurückzuführen und
> > entsprechend waren sie jedes Mal durch – beigesteuerten oder erlesenen –
> > Sachverstand ausgeräumt. >
> > Freilich kann ein einfacheres Programm Schwierigkeiten vermeiden helfen.
>
> Wäre es nicht zielführend, eine leichter verständliche und robustere
> Software einzusetzen?

Der Einwand ist natürlich und kommt freilich nicht unerwartet.
Allerdings habe ich zwei Schwierigkeiten, die vielleicht mit dem Wunsch,
zu verkürzen, erklärt sind:

„leichter verständlich” ist eine Annahme. Vielleicht habe ich zu sehr
auf meinem suboptimalen Sachverstand insistiert. Gehen wir davon aus,
dass ich weniger von maildrop verstehe, als von procmail. Anzahl der
positiven Ergebnisse, die ich mit maildrop erziele: 0
procmail: ... hm. Identisch mit allen erfolgreich durchgeführten
Filteraktionen der letzten 10 bis 15 Jahre.

„robust” – schwieriger.
Wie oben geschrieben und zitiert, kann ich bisher keine Fehlersituation
auf Fehlfunktionen in Procmail zurückführen.

Es ist ja nicht ausgeschlossen, dass ich Procmail aufgeben werde und
mich exakt Maildrop zu interessieren beginnt.

Ich möchte aber nichts glauben und versuche, einen Großteil meiner
eigenen Handlungen auch begründen zu können... das kann ich nicht
kürzer.

Cheerio und schönes Wochendende

Michael
--
Whatever you do, try to have a reason to do it
... den hatte ich schon.

[Goetz Schultz]

Das hier: https://github.com/BuGlessRB/procmail

[Matthias Andree]

Am 04.03.23 um 08:06 schrieb Michael Uplawski:

> Matthias Andree wrote:
>>> Ich habe bereits daran gedacht. Nur sind alle bisher eingetretenen
>>> Fehlersituationen auf meine eigene Unbedarftheit zurückzuführen und
>>> entsprechend waren sie jedes Mal durch – beigesteuerten oder erlesenen –
>>> Sachverstand ausgeräumt. >
>>> Freilich kann ein einfacheres Programm Schwierigkeiten vermeiden helfen.
>>
>> Wäre es nicht zielführend, eine leichter verständliche und robustere
>> Software einzusetzen?
>
> Der Einwand ist natürlich und kommt freilich nicht unerwartet.
> Allerdings habe ich zwei Schwierigkeiten, die vielleicht mit dem Wunsch,
> zu verkürzen, erklärt sind:
>
> „leichter verständlich” ist eine Annahme. Vielleicht habe ich zu sehr
> auf meinem suboptimalen Sachverstand insistiert. Gehen wir davon aus,
> dass ich weniger von maildrop verstehe, als von procmail. Anzahl der
> positiven Ergebnisse, die ich mit maildrop erziele: 0
> procmail: ... hm. Identisch mit allen erfolgreich durchgeführten
> Filteraktionen der letzten 10 bis 15 Jahre.
>
> „robust” – schwieriger.
> Wie oben geschrieben und zitiert, kann ich bisher keine Fehlersituation
> auf Fehlfunktionen in Procmail zurückführen.

Das stimmt aber nicht, wie dieser Thread beweist.

Procmail verlangt von Dir, dass Du ihm sagst, dass es Dir nicht in die
Füße schießen soll.

Konkret: Procmail hat ein Verhalten "wenn die Regel fehlschlägt, nehm
ich halt die nächste". Es erfordert, und das steht so nicht explizit in
der Doku, dass Du die komplette Fehlerbehandlung selbst in Deinen
Recipes codierst. Hinter jedem Rezept ein

:0e
{EXITCODE=75}

oder so ablegst, um - unterstellend, dass sysexits.h den Code für
TEMPFAIL hernimmt und Dein MTA-MDA-Interface das rafft, den Fehler als
temporär abzubilden.


So, und jetzt ist Zeit fürs LART oder eine Merkbefreiung.
Ich geh mal suchen.

[Matthias Andree]

Am 04.03.23 um 12:57 schrieb Goetz Schultz:

> On 03/03/2023 20:41, Matthias Andree wrote:
>> Am 28.02.23 um 12:57 schrieb Goetz Schultz:
>>> On 27/02/2023 18:09, Matthias Andree wrote:
>>>> Am 23.02.23 um 18:20 schrieb Michael Uplawski:
>>>>> Guten Abend.
>>>>>
>>>>> Ich habe diese Regel in meiner .procmailrc:
>>>>
>>>> procmail ist ein Vierteljahrhundert nicht gepflegt und hat
>>>> schwerwiegende Entwurfsfehler.  So muss jede Form von
>>>> Fehlerbehandlung nach jedem einzelnen Filterrezept von Hand
>>>> eingefügt werden.
>>>>
>>>> Wirf das procmail weg und nimm, zum Beispiel, maildrop.  Du musst
>>>> dann die Filter umschreiben, aber das wird sich auszahlen.
>>>>
>>>
>>> Procmail hat mittlerweile ein Update bekommen. Ich setze es immer
>>> noch ein, bevor ich mich mich anderen Filtern herumschlagen muss und
>>> entsprechende Fehler wiederhole.
>>>
>>
>> Welches Update wäre das?
>
> Das hier: https://github.com/BuGlessRB/procmail

OK. Da steht aber nichts davon, dass die Entwurfsfehler beseitigt
wurden. Oder dass man den Leuten erklärt, wie sie Fehlerbehandlung
hinschreiben müssen, das ist tradiertes Anwendungswissen. Bugfixes in
HISTORY? Fehlanzeige, "lies selbst Git commits". Kann man machen.

Benutzerfreundlich wird der Schrott davon nicht.

Fedora 37 hat procmail 3.24 nicht gefunden. Für Debian ist der Port zu
schrottig als dass der auch nur nach testing dürfte:

"Migration status for procmail (3.22-27 to 3.24-1): BLOCKED:
Rejected/violates migration policy/introduces a regression"
<https://tracker.debian.org/pkg/procmail>

Also immer noch: Weg mit dem Scheiß.