Good morning,

In my .procmailrc will this work to both append the email to an existing file
and also forward the email?

:0c
* ^subject:.*jacket.*puffy
$HOME/trash/forwarded
! person@domain.com

Thanks,

On Thu, 27 Oct 2022 14:50:40 +0000, me at wrote:

> Good morning,
>
> In my .procmailrc will this work to both append the email to an existing file
> and also forward the email?
>
> :0c
> * ^subject:.*jacket.*puffy
> $HOME/trash/forwarded
> ! person@domain.com

I haven't played with procmail recipes in a long time, so I may be wrong, but
I don't think that the above recipe will work.

According to procmailrc(5) ("man 5 procmailrc"), a procmail recipe consists of
- a single flags line,
- zero or more conditions, and
- exactly one action line

While your recipe satisfies the "single flag line" and "zero or more condition
line", it fails as you have more than one action line.

Since your recipe makes a carbon copy for delivery, procmail will execute the
recipe, and then pass the original email along to the next matching recipe.

So, you /should/ be able to accomplish your goal with two recipes. Something
like

:0c
* ^subject:.*jacket.*puffy
$HOME/trash/forwarded

:0c
* ^subject:.*jacket.*puffy
! person@domain.com

> Thanks,

For what it's worth, you can find some assistance both in the manual pages
and online. For procmail, I've depended on procmailrc(5), which explains
the format of the procmailrc, and procmailex(5), which provides some
examples. Additionally, I've used, and recommend, "Timo's procmail tips and
recipes", a web page at
http://www.abreau.net/howto/procmail/procmailrc-tips.html

HTH
--
Lew Pitcher
"In Skills, We Trust"

In article <tje5s0$mrn$1@reader2.panix.com>,
me at <my.address@is.invalid> wrote:
>
> Good morning,
>
>In my .procmailrc will this work to both append the email to an existing file
>and also forward the email?
>
> :0c
> * ^subject:.*jacket.*puffy
> $HOME/trash/forwarded
> ! person@domain.com

Speaking as a long time user of procmail - and one who has gotten
acclimated to its many quirks - I can say that the only way to know the
answer to your question is to test it and see. procmail is just plain
buggy in some respects, and you just have to learn to live with this.

I've read somewhere that the code has become unmaintainable, so whatever
bugs are there will remain there for eternity.

(Despite the above two paragraphs, I still use it and see no reasons to try
anything else)

Two general thoughts:
1) My general instinct would be to have two rules for the two actions.
I.e., use the same filter on each - one to do the first thing and
one to do the second.
2) The truly safe way to do this sort of thing is to have a single
action that pipes the mail to a shell script. Then, in the script,
you can do whatever you want.

--
"We are in the beginning of a mass extinction, and all you can talk
about is money and fairy tales of eternal economic growth."

- Greta Thunberg -

On Thu, 27 Oct 2022 15:16:59 +0000, Lew Pitcher wrote:

> On Thu, 27 Oct 2022 14:50:40 +0000, me at wrote:
>
>> Good morning,
>>
>> In my .procmailrc will this work to both append the email to an existing file
>> and also forward the email?
>>
>> :0c
>> * ^subject:.*jacket.*puffy
>> $HOME/trash/forwarded
>> ! person@domain.com
>
> I haven't played with procmail recipes in a long time, so I may be wrong, but
> I don't think that the above recipe will work.
>
> According to procmailrc(5) ("man 5 procmailrc"), a procmail recipe consists of
> - a single flags line,
> - zero or more conditions, and
> - exactly one action line
>
> While your recipe satisfies the "single flag line" and "zero or more condition
> line", it fails as you have more than one action line.
>
> Since your recipe makes a carbon copy for delivery, procmail will execute the
> recipe, and then pass the original email along to the next matching recipe.
>
> So, you /should/ be able to accomplish your goal with two recipes. Something
> like
>
> :0c
> * ^subject:.*jacket.*puffy
> $HOME/trash/forwarded
>
> :0c
> * ^subject:.*jacket.*puffy
> ! person@domain.com
>

For what it's worth, you can also accomplish this as a recipe with sub-recipes.
As in
:0c
* ^subject:.*jacket.*puffy
{
:0
$HOME/trash/forwarded

:0
! person@domain.com
}

This makes a carbon copy of the original email, and passes it on
to two sub-recipes, each which deliver the cc in their own way.

[snip]

--
Lew Pitcher
"In Skills, We Trust"

On Thu, 27 Oct 2022 15:36:52 +0000, Lew Pitcher wrote:

> On Thu, 27 Oct 2022 15:16:59 +0000, Lew Pitcher wrote:
>
>> On Thu, 27 Oct 2022 14:50:40 +0000, me at wrote:
>>
>>> Good morning,
>>>
>>> In my .procmailrc will this work to both append the email to an existing file
>>> and also forward the email?
>>>
>>> :0c
>>> * ^subject:.*jacket.*puffy
>>> $HOME/trash/forwarded
>>> ! person@domain.com
>>
>> I haven't played with procmail recipes in a long time, so I may be wrong, but
>> I don't think that the above recipe will work.
>>
>> According to procmailrc(5) ("man 5 procmailrc"), a procmail recipe consists of
>> - a single flags line,
>> - zero or more conditions, and
>> - exactly one action line
>>
>> While your recipe satisfies the "single flag line" and "zero or more condition
>> line", it fails as you have more than one action line.
>>
>> Since your recipe makes a carbon copy for delivery, procmail will execute the
>> recipe, and then pass the original email along to the next matching recipe.
>>
>> So, you /should/ be able to accomplish your goal with two recipes. Something
>> like
>>
>> :0c
>> * ^subject:.*jacket.*puffy
>> $HOME/trash/forwarded
>>
>> :0c
>> * ^subject:.*jacket.*puffy
>> ! person@domain.com
>>
>
> For what it's worth, you can also accomplish this as a recipe with sub-recipes.

Make that

:0c
* ^subject:.*jacket.*puffy
{
:0c
$HOME/trash/forwarded

:0
! person@domain.com
}

The first sub-recipe needs to pass a carbon copy on to the second sub-recipe,
otherwise the second sub-recipe won't get any mail at all.

Also, as Kenny suggested, the best way to determine if your recipes work is
to test them with procmail. I vaguely recollect being able to test at the
commandline by feeding test emails into procmail's stdin.

HTH
--
Lew Pitcher
"In Skills, We Trust"

On Thu, 27 Oct 2022 15:18:31 +0000, Kenny McCormack wrote:
[snip]

> Speaking as a long time user of procmail - and one who has gotten
> acclimated to its many quirks - I can say that the only way to know the
> answer to your question is to test it and see. procmail is just plain
> buggy in some respects, and you just have to learn to live with this.
>
> I've read somewhere that the code has become unmaintainable, so whatever
> bugs are there will remain there for eternity.

Apparently, while procmail development went dormant for over a decade, it
has restarted. In May 2020, Stephen R. van den Berg resumed development of
procmail and released v3.24 in Februry 2022.

You can find the current source code at https://github.com/BuGlessRB/procmail

[snip]
--
Lew Pitcher
"In Skills, We Trust"

In comp.unix.shell, Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> Kenny McCormack wrote:
>> Speaking as a long time user of procmail - and one who has gotten
>> acclimated to its many quirks - I can say that the only way to know the
>> answer to your question is to test it and see. procmail is just plain
>> buggy in some respects, and you just have to learn to live with this.

I find that is very rarely the case. The documentation is very poor in
some places,and the syntax is a nightmare, but buggy to the point of try
it and see only, no.

>> I've read somewhere that the code has become unmaintainable, so whatever
>> bugs are there will remain there for eternity.

The code is a nightmare to work with, eschewing every standard syntax
style, C with minimal white space, few comments, repeated use of
`goto`s, many functions that work on substring plus length instead of C
strings. I asked around in comp.lang.c if anyone knew a pretty printer
that could cope with it and got no good responses.

Here's a short sample function:

struct field**addfield(pointer,text,totlen)struct field**pointer;
const char*const text;const size_t totlen; /* add field to a linked list */
{ register struct field*p,**pp;int idlen;
for(pp=pointer;*pp;pp= &(*pp)->fld_next); /* skip to the end of the list */
(*pp=p=malloc(FLD_HEADSIZ+totlen))->fld_next=0;idlen=breakfield(text,totlen);
p->id_len=idlen>0?idlen:pp==&rdheader?0:-idlen; /* copy contents */
tmemmove(p->fld_text,text,p->Tot_len=totlen);
return pp;
}

With some effort I made the procmail helper tool formail able to decode
MIME-encoded words in headers, but never got that working in procmail
proper:

https://github.com/Eli-the-Bearded/procmail-formail

> Apparently, while procmail development went dormant for over a decade,
> it has restarted. In May 2020, Stephen R. van den Berg resumed
> development of procmail and released v3.24 in Februry 2022.

Huh, I did not know that.

> You can find the current source code at
> https://github.com/BuGlessRB/procmail

Snorted at tag "Two decades of fixes". I see that warrants a version
number bump from 3.22 to 3.24.

Elijah
------
has been using procmail well over two decades

Thu, 27 Oct 2022 08:46:53 Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
|
| :0c
| * ^subject:.*jacket.*puffy
| {
| :0c
| $HOME/trash/forwarded
|
| :0
| ! person@domain.com
| }
|

This worked great. Put it in yesterday and it just processed the first candidate.

Thank you,