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>>
Subject: =?utf-8?B?UmF5QmFuIFN1bmdsYXNzZXMgIiA=?=
From: "RayBan Sunglasses" <service <at>>
Subject: =?utf-8?B?UmF5QmFuIFN1bmdsYXNzZXMgIiA=?=
(Continue reading)

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

(Continue reading)

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>>
> >>To: "gamestop <at>" <gamestop <at>>
> >I see your problem here.  Look at that last line, and how it matches
> >your pattern:
> >
> >> To: "gamestop <at>" <gamestop <at>>
> >  \_/\________________/^\____________/^\__________/
> > ^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:

(Continue reading)

Moby | 12 Jun 06:00 2015

Matching literal dot in To

I use the following to match a literal dot in the To field, the dot 
(period) has to occur prior to the  <at>  character.  The recipe is:

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

For some reason, the recipe matches some (but not all, I have not found 
a pattern yet) addressees in the To field where there is no dot in the 
To address prior to the  <at>  sign.  Logging shows the match occurring, but 
of course it does not give a reason why.

Any ideas on how to trouble shoot further?

Regards and thanks in advance for any help.



They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor
safety.  -- Benjamin Franklin
@lbutlr | 30 May 00:38 2015

Time-based filtering in Procmail

Wondering if anyone has done anything with procmail and time based filtering.

For example, doing something different if a message arrive between midnight and 6am.

It’s just some regex and the top Received line, but I’d rather not duplicate work.



Adolescence is the period between childhood and adultery

procmail mailing list   Procmail homepage:
procmail <at>
shanew | 19 May 23:17 2015

Limit user actions in .procmailrc

I'm updating a fairly old and very idiosyncratic mail system, and one
of the features of this system is that only explicitly listed users
can call external commands from within a .procmailrc.  I think this is
actually accomplished by having both a "regular" procmail for the
listed users, but a "hobbled" procmail that was locally compiled to
disallow such things, but in any case, I'm wondering what options I
have to recreate similar functionality?

Is there something equivalent to sendmail's smrsh functionality for

I've looked briefly at jailkit and jk_procmailwrapper, but it has
pretty limited documentation and makes it look like users already need
to live in jailed shells as well as requiring a non-standard mailbox
location, so it's definitely not my first choice.

Another idea that occurred to me would be to prevent .procmailrc
execution by setting DROPPRIVS equal to "no" in the system
/etc/procmailrc unless the LOGNAME value appears in a file that listed
allowed users?  Does this even seem do-able?  I don't know if this
would be an acceptable solution for us, but I won't even bother trying
if it's not possible (or just a plain "Bad Idea").

Somewhat related to that, is it possible to set DROPPRIVS to yes, and
then change it to no later in /etc/procmailrc?  I'm thinking of a
situation where the system procmailrc might look for a user with a
vacation message setup, drop to being them to run vacation, and then
set DROPPRIVS=no to prevent any .procmail from being executed.

Thanks for any insight you might have to offer
(Continue reading)

@lbutlr | 30 Apr 22:40 2015


Apologies, please ignore.


Say, give it up, give it up, television's taking its toll That's enough,
that's enough, gimme the remote control I've been nice, I've been good,
please don't do this to me Turn it off, turn it off, I don't want to
have to see
@lbutlr | 29 Apr 18:30 2015

Stripping extra stuff from text

I have the following which generates a 140 character blog for sending me an SMS alert:

MSGTEXT=`/usr/local/bin/formail -I ""`
SMSTEXT=`echo $MSGTEXT | lynx --dump --dont_wrap_pre -stdin | tr '\n' ' ' | /usr/bin/cut -c1-140`

      | (formail -brt -I"Subject: ${CLEANFROM}" \
        -I"To: ${MOBILE}" \
        -I"From: lbuter <at>"; \
        echo $SMSTEXT) | $SENDMAIL -t

This works fine, but I end up with text like:

SMS:    This is the body of the email. It should be more than 140 characters to    = test if the cut pipe is working and
if this message will be 

As you can see, I have leading spaces, and an extraneous =, but if I remove lynx from the chain, I will get HTML
crap in the message on those messages.

Is there a simple way to remove any extra space AND encoding cruft, or do I just need to stack up some tr or sed


"Why, you stuck-up, half-witted, scruffy-looking... NERFHERDER!"
"Who's Scruffy looking?"
@lbutlr | 23 Mar 18:22 2015

strange error in my procmailrc

when the procmailrc hands off mail for my personal account it logs an error:

User me <at> has a .procmailrc, processing...
date: illegal time format
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ... 
            [-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]

None of the other accounts with .procmailrcs log this error, but when I look in my .procmailrc for date:

$ grep date /home/me/.procmailrc 
DATE=`date '+%d-%b-%Y'`
MDATE=`date '+%Y-%m'`
YDATE=`date '%Y'`
LONGDATE=`date "+%y-%b-%d %I:%M:%S %z"`
LOG="`date`${NL}Checking Spam Status... "
  LOG="done. `date`$NL"
  LOG="Delivered `date`$NL"
LOG="Delivered `date`$NL”

None of these seem like they should be throwing any sort of error. They all execute fine from the command line
and date is in /bin/ so I don’t think it could be a path problem. Also, there are not errors logged to my
procmailk log file, only to the global log file/


'You don't think you've had enough, do you?' he said. I KNOW WHEN I'VE
HAD ENOUGH. 'Everyone says that, though. I KNOW WHEN EVERYONE'S HAD
ENOUGH. --Moving Pictures

procmail mailing list   Procmail homepage:
(Continue reading)

Alan Clifford | 23 Mar 16:22 2015

Any dangers with this recipe?

I know I'm probably being petty and unreasonable but there we are.  A 
couple of events have really annoyed me.

Firstly, I politely asked a company to stop sending emails to an address. 
They said the couldn't and I think they quoted the data protection act. 
They said I had to do it myself on their website.  Hmmm, was that true?

The second event was a company that sent me several emails on the same day 
to an address that only appears as a contact address on my website.  I 
wondered if I could persuade them to stop.  As I don't want the website 
email address to be repeated here, I've used xxxx <at> in the 
recipe below.

I've attempted to target specific people at the company concerned to annoy 
them with their own email spew. devnull <at> is rejected by 
sendmail so hopefully no mail loop.  And I tagged my gmail address I use 
for testing onto the the list of recipients so I could see what I was 
sending out.

Any problems/dangers?

* ^to:.*xxx <at> example\.com
* ^from:.*michael <at> smmexevent\.com
   :0 c
   | $SENDMAIL -oi -f devnull <at> 
michael <at>, <at>,postmaster <at>,domain-admin <at>

(Continue reading)