Zhiliang Hu | 11 Mar 16:25 2016

recepient's email address truncated

I use a procmail recipe like the following for a number of small lists:

ReplyTo = "Reply-To: `formail -xFrom:`"

:0 c
* ^(To|Cc):.*listone <at> mydomain.name
* ? formail -X"From " -xFrom: -xSender: -xReply-To: -xResent-From: \
      | /var/list/.bin/multigram -b1 -m -l 28668 \
    :0 c

    :0 fwh
    | formail -I "Reply-To: $ReplyTo"
      ! `cat /home/myaccount/etc/listone.txt`

Everything works fine for quite some time. Lately there were some 
occasional email bounces on *some users*, on *some* list mails (not 
consistent). The bounce shows that the recepient's email address was 
truncated (4-5 letters chopped off from the right side). Test mails 
from the same server machine to the same email address goes just fine.
I double checked the email list file for any non-ascii characters etc
and it was clean.

Because this is hardly repeatable, I am not sure what else I should look 
at? Any advice would be appreciated.

(Continue reading)

Bernard Schoenacker | 28 Jan 16:55 2016

my first procmail rules


it's possible to look any recipe in my first procmailrc ?

see the attachment


Attachment (procmailrc-1.gz): application/gzip, 2088 bytes
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
Danny de Bont | 21 Jan 16:34 2016

Appending contents to file

Hi guys,

Currently I am managing my Debian servers via simple commands in the Subject of a mail message with an empty body ...

Procmail would read the Subject and then perform a certain command ...

For example:
If I want to start an Ftp server I would send an email with "Ftp start" as the subject ... it works o.k for my needs ...

However ... I want to send more complicated commands in the Body and not the Subject ...

For example:
When procmail gets an email with say "Execute command" in the Subject ... I want procmail to pipe the command contained in the body (a one line BASH command) to BASH ...

Here is an example of a command I would send in the Body:
echo -e "\rLT 4>Body of email message\r\r" > /dev/ttyS1

Any pointers?


procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
@lbutlr | 17 Jan 08:33 2016

Transform part of a message body

I get some emails sometimes that have a long line of characters, usually used to mark a huge set of footers

Something like

Text goes here

(or maybe -’s *’s or other characters.

I’d like to modify a message with, say, a line of 10 or more repeated characters and change that line to be a
signature delimiter.

If this would be better done at the MTA (postfix) then that’s fine. I do need to only modify plain text
messages, however.


I think I found your marbles.

procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
Penguinfriend | 6 Oct 13:22 2015

Create a rule for utf8 subject


I wonder if anybody have a solution for the following example

* ^Subject:.*PGPKEY

if the Subject line is coded like this will never be a hit


How do I handle this so I will get a hit in the relevant case

@lbutlr | 5 Oct 04:45 2015

Changing the subject

I have some meals that are sent to a custom email address. I have no control over how the emails are formed
(they are from a remote device) but the part of the email that is important is in the body, so I tried this to
put the information in the more accessible subject:

* ARG ?? ^^alert^^
    SUBJECT=`formail -I ""`

    | formail -I"Subject: $SUBJECT”

    # Send an SMS alert


ARG = alert TO = kreme+alert <at> kreme.com FROM = device <at> remote.device
procmail: [35385] Sun Oct  4 20:35:40 2015
procmail: Match on "^^alert^^"
procmail: Assigning "TRAP=mv "$LASTFOLDER" "${LASTFOLDER}:2,S""
procmail: Executing "formail,-I,"
procmail: Assigning "SUBJECT=
Alert Text is here, and yes a blank line is part of the alert text"
procmail: Match on "| formail -I"Subject: $SUBJECT""
procmail: Extraneous filter-flag ignored

So, I am doing something wrong in the :fw, I guess. I did look up how to do this, not trusting my memory, but that
matches what I found

procmail: Assigning "LASTFOLDER=INCLUDERC=/home/kreme/.sms_procmail"
procmail: Opening "INCLUDERC=/home/kreme/.sms_procmail"
procmail: Error while writing to "INCLUDERC=/home/kreme/.sms_procmail”

That seems odd.

procmail: Assigning "LASTFOLDER=.alerts/new/1444012540.35385_1.mail.covisp.net"
procmail: Notified comsat: "kreme <at> 0:/home/kreme/Maildir//.alerts/new/1444012540.35385_1.mail.covisp.net"
procmail: Assigning "EXITCODE=0"
procmail: Executing "mv,.alerts/new/1444012540.35385_1.mail.covisp.net,.alerts/new/1444012540.35385_1.mail.covisp.net:2,S"

I have other recipes that call the sms_procmail file and send messages properly.

What did I miss?


"Making music should not be left to the professionals." -  Michelle

procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
Ian Zimmerman | 8 Sep 01:21 2015

Computed list of destinations?

Is there any way for procmail to deliver to a computed or dynamically
determined list of mailboxes or addresses?

The lack of loops in the procmailrc "language" makes "no" the obvious
answer, but I thought there might be a trick the assembled experts know.


Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.
Eric Smith | 16 Aug 11:06 2015

egrep matches, but procmail recipe not

The following (negative) procmail patterns do not match:

* ! ^(Subject|From):.*sunglas
* ! ^(Subject|From):.*Sunglasses
* ! ^(Subject|From):.*Oakley
* ! ^(Subject|From):.*Ray*Ban
* ! ^(Subject|From):.*?utf-

procmail logs:
procmail: Match on ! "^(Subject|From):.*sunglas"
procmail: Match on ! "^(Subject|From):.*Sunglasses"
procmail: Match on ! "^(Subject|From):.*Oakley"
procmail: Match on ! "^(Subject|From):.*Ray*Ban"
procmail: Match on ! "^(Subject|From):.*?utf-"

However, when I test with egrep for a (positive) match with these patterns, then they do match.

$ cat test_patterns

$ egrep -i -f test_patterns rayban.mail
From: "RayBan Sunglasses" <service <at> uqmpkfx.com>
Subject: =?utf-8?B?UmF5QmFuIFN1bmdsYXNzZXMgIiA=?=
From: "RayBan Sunglasses" <service <at> zvzlxaw.com>
Subject: =?utf-8?B?UmF5QmFuIFN1bmdsYXNzZXMgIiA=?=

What is wrong with my procmail recipes?

Ian Zimmerman | 9 Aug 08:47 2015

environment passed from sendmail?

(Posted a few days ago in comp.mail.sendmail, no reaction.)

Hi.  I haven't administered sendmail myself in a long time; ever since I
adopted Debian as my preferred OS, I have used their default MTA, which
was first smail, then exim; so excuse me if this question is nooby.  But
my mail does pass through a server running sendmail [call it S] on its
way to me, and not being root on $S I can't quite dig in and investigate

I use procmail to forward my mail from $S to my personal server.  I
believe this is enabled with the feature_local_procmail configuration
macro (not sure of spelling).  In any case, I don't have a .forward
file, only a .procmailrc.  Now I'd like to do some tricky things with
procmail and it would help to have some info from the MTA (example: the
envelope sender and recipient, and the sendmail local id of the
message).  Is there a way for sendmail to pass these items to procmail
in the environment, and if so is it on by default on the sendmail side?

I can't test that just by invoking env or printenv from procmail,
because procmail discards almost all of the environment unless it's
started with the -p flag, and I think the way sendmail invokes procmail
on $S is without -p.

If it turns out that sendmail does pass such environment items but
procmail discards them, would it help to bypass the direct procmail
delivery and use a .forward file instead, with the line

 |/usr/bin/procmail -p /home/me/.hidden_procmailrc

IOW, would sendmail still pass the env items to a pipe delivery running
from within a .forward?

Thanks for any ideas.

Exim, for example, passes the SENDER, RECIPIENT, and MESSAGE_ID
environment variables to any pipe delivery, either those invoked from
.forward files or configured directly in exim.


Please *no* private copies of mailing list or newsgroup messages.
Rule 420: All persons more than eight miles high to leave the court.
Eric Smith | 5 Aug 09:16 2015

Command died with status 134Reply-To:


I have recently introduced some bug in my procmail scripts which results
intermittently in the following sender non-delivery notification:
Command died with status 134: "/usr/bin/procmail -a "$EXTENSION"". Command output: Aborted

However (and this might be because of some redundancy in my scripts) the mail is actually delivered to me.

Is there any clue in the above error message as to where I might look to fix this?

Chuck Martin | 13 Jun 03:11 2015

Re: Matching literal dot in To

On Fri, Jun 12, 2015 at 06:50:52PM -0500, Moby wrote:
> On 06/12/2015 04:56 PM, Chuck Martin wrote:
> >On Fri, Jun 12, 2015 at 04:02:27PM -0500, Moby wrote:
> >>:0w
> >>* ^To:.*\..* <at> .*
> >>| $DELIVERTO -a $CYUSER -m "jdotrejects" $CYUSER
> >>
> >>The log snippet is:
> >>procmail: Match on "^To:.*\..* <at> .*"
> >>
> >>Here are header snippets from the particular email:
> >>
> >>From: "GameStop PowerUp Rewards" <GameStop <at> e.gamestop.com>
> >>To: "gamestop <at> abc-def.com" <gamestop <at> abc-def.com>
> >I see your problem here.  Look at that last line, and how it matches
> >your pattern:
> >
> >> To: "gamestop <at> abc-def.com" <gamestop <at> abc-def.com>
> >  \_/\________________/^\____________/^\__________/
> > ^To:       .*        \.      .*       <at>     .*
> >
> Many thanks.  I see the issue now - but cannot think of an easy fix short of
> sending the message to an external script for processing. Would you have any
> ideas on how to handle situations like this?  I now realize
> I would also need to handle the case where the To: line has multiple
> recipients, I would need to check ~each~ email address as to whether it has
> a dot in it or not.

For a single address, you could put this somewhere ahead of the recipe:

TO=`formail -cx 'To:' | sed -re 's/.*<(.* <at> [^ >]*)>.*/\1/;s/^ *//;s/ *$//'`

That will extract the first address only, if there are multiple addresses
in the "To:" line, and strip any whitespace from the beginning and/or
end, if present (this may be the case if there were no angle brackets in
the address, like if the address was alone, without a name).

Then in the recipe itself, change this:

* ^To:.*\..* <at> .*

to this:

* ? test -n "$TO" && grep '.*\..* <at> .*' "$TO"

The 'test -n "$TO"' part makes sure $TO isn't empty, as it might be if
there was no "To:" line in the header, and the grep looks for the dot
in the address.

If there are more addresses, then the question I would ask is what is
it you're looking for exactly?  Should it be considered a match if any
address has a dot, or only if all of them have dots?  What's your reason
for checking for the dot?  The solution depends on that answer, and
could be pretty complex.

By the way, my reply to you was supposed to go to the list, so I'm sending
this to the list, where it should have been in the first place.  My first
attempt at replying to the list had the wrong address in the "From:" line
(it wasn't the one used to subscribe to this list, and I think it got
blocked), and when I tried to resend it, I did a regular reply instead
of a list-reply.  Sorry about that.


This address uses a whitelist.  If you aren't in my whitelist, you can
only send me e-mail if you send to an appropriately tagged address (it
includes +sometag between the username and  <at> ).  Finger my untagged e-mail
address for a tag guaranteed good for 24 hours if you're unsure.  If I've
sent you mail recently, you're temporarily whitelisted automatically.