Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #6717 > unrolled thread

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

Back to article view | Back to de.comm.software.mailserver

Contents

  [Procmail] Regel speichert Mail, aber Mail ist weg. Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-02-23 17:20 +0000
    Re: [Procmail] ZEILENUMBRÜCHE – Regel speichert Mail, aber Mail ist weg. Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-02-23 17:23 +0000
      Re: [Procmail] ZEILENUMBRÜCHE – Regel speichert Mail, aber Mail ist weg. Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-02-23 17:24 +0000
    Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Markus Schaaf <mschaaf@elaboris.de> - 2023-02-23 18:46 +0100
      Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-02-24 12:17 +0000
        Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Christoph Brinkhaus <C.Brinkhaus@t-online.de> - 2023-02-24 13:28 +0000
        Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Markus Schaaf <mschaaf@elaboris.de> - 2023-02-24 14:32 +0100
          Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-02-24 18:41 +0000
    Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Matthias Andree <matthias.andree@gmx.de> - 2023-02-27 19:09 +0100
      Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-02-27 20:08 +0100
      Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-02-27 20:08 +0100
        Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Paul Muster <exp-311223@news.muster.net> - 2023-02-27 21:23 +0100
          [Maildrop] Filtern mit externen Programmen [war: Procmail – Regel speichert Mail, aber Mail ist weg.] Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-02-28 06:28 +0100
            Re: [Maildrop] Filtern mit externen Programmen [war: Procmail – Regel speichert Mail, aber Mail ist weg.] Paul Muster <exp-311223@news.muster.net> - 2023-02-28 07:12 +0100
              Re: [Maildrop] Filtern mit externen Programmen [war: Procmail – Regel speichert Mail, aber Mail ist weg.] Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-02-28 08:02 +0100
        Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Matthias Andree <matthias.andree@gmx.de> - 2023-03-03 21:38 +0100
          Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-03-04 08:06 +0100
            Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Matthias Andree <matthias.andree@gmx.de> - 2023-03-04 15:09 +0100
      Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Goetz Schultz <ng.expire1222@goetz.co.uk> - 2023-02-28 11:57 +0000
        Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Matthias Andree <matthias.andree@gmx.de> - 2023-03-03 21:41 +0100
          Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Goetz Schultz <ng.expire1222@goetz.co.uk> - 2023-03-04 11:57 +0000
            Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Matthias Andree <matthias.andree@gmx.de> - 2023-03-04 15:14 +0100
    Re: [Procmail] Regel speichert Mail, aber Mail ist weg. Michael Uplawski <michael.uplawski@uplawski.eu> - 2023-03-01 21:43 +0100

Page 1 of 2  [1] 2  Next page →

#6717 — [Procmail] Regel speichert Mail, aber Mail ist weg.

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-liste1@ding.org"
procmail: No match on "^(To|Cc):(.*\<)?mailing-liste2@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.adresse@irgendwo.tld"
procmail: Match on "^From:.*eine.adresse@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.adresse@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

[toc] | [next] | [standalone]

#6718 — Re: [Procmail] ZEILENUMBRÜCHE – Regel speichert Mail, aber Mail ist weg.

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

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

> 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-liste1@ding.org"
procmail: No match on "^(To|Cc):(.*\<)?mailing-liste2@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.adresse@irgendwo.tld"
procmail: Match on "^From:.*eine.adresse@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:382023 
procmail: Notified comsat:"michael@12019325:/home/michael/Mail/inbox" 
From eine.adresse@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

[toc] | [prev] | [next] | [standalone]

#6719 — Re: [Procmail] ZEILENUMBRÜCHE – Regel speichert Mail, aber Mail ist weg.

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

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

[toc] | [prev] | [next] | [standalone]

#6720

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

[toc] | [prev] | [next] | [standalone]

#6728

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)

[toc] | [prev] | [next] | [standalone]

#6729

Michael Uplawski <michael.uplawski@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.

[toc] | [prev] | [next] | [standalone]

#6730

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

[toc] | [prev] | [next] | [standalone]

#6734

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.

[toc] | [prev] | [next] | [standalone]

#6768

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.

[toc] | [prev] | [next] | [standalone]

#6769

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

[toc] | [prev] | [next] | [standalone]

#6770

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. 

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

[toc] | [prev] | [next] | [standalone]

#6771

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

[toc] | [prev] | [next] | [standalone]

#6773 — [Maildrop] Filtern mit externen Programmen [war: Procmail – Regel speichert Mail, aber Mail ist weg.]

Moin.

Paul Muster wrote:
> 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.

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@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 
-- 
Es ist an der Zeit

[toc] | [prev] | [next] | [standalone]

#6774 — Re: [Maildrop] Filtern mit externen Programmen [war: Procmail – Regel speichert Mail, aber Mail ist weg.]

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@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

[toc] | [prev] | [next] | [standalone]

#6775 — Re: [Maildrop] Filtern mit externen Programmen [war: Procmail – Regel speichert Mail, aber Mail ist weg.]

Paul Muster wrote:
> > # Filter ip-ranges: DELETE
> > :0
> > * !FROM_DAEMON
> > * !FROM_MAILER
> > * !^X-Loop: michael.uplawski@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
-- 
Es ist an der Zeit

[toc] | [prev] | [next] | [standalone]

#6783

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

[toc] | [prev] | [next] | [standalone]

#6785

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.

[toc] | [prev] | [next] | [standalone]

#6787

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.

[toc] | [prev] | [next] | [standalone]

#6776

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.

-- 

Cheers,
    G.

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

[toc] | [prev] | [next] | [standalone]

#6784

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?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comm.software.mailserver

csiph-web