Discussion:
Modifying message, continuing as normal
(too old to reply)
Matt Armstrong
1997-08-19 18:35:07 UTC
Permalink
I've had this question about procmail for a while, but now I have a
use for it (stripping richtext from all my incoming mail, as our
in-house switch to NT has proliferated Netscape and Eudora mail
readers and, accordingly rich text, to an unbearable level).

I'd like to do something like:

:0:
* Content-Type:.*enriched/text
| my-strip-enriched-executable

But I'd like it to be a non-delivering recipe (but instead a
"modifying" recipe).

Preferable I'd like to be able to just insert this rule without
changing the rest of my procmail script.
--
matta
Timothy J Luoma
1997-08-19 18:44:30 UTC
Permalink
Author: Matt Armstrong <***@geoworks.com>
Original-Date: 19 Aug 1997 11:35:07 -0700
Post by Matt Armstrong
* Content-Type:.*enriched/text
| my-strip-enriched-executable
But I'd like it to be a non-delivering recipe (but instead a
"modifying" recipe).
:0fhw
* Content-Type:.*enriched/text
| my-strip-enriched-executable

That should do it .... the 'w' flag assumes that your program is good about
exitcodes.

You might want to look at mimeencode, a program that does this sort of conversion.

And, of course, you should make a backup of all mail before modifying it
when using new recipes

TjL
Michael Stone
1997-08-19 20:05:15 UTC
Permalink
Post by Matt Armstrong
:0fhw
* Content-Type:.*enriched/text
| my-strip-enriched-executable
IIRC, the lowercase h will feed the header to the pipe, which is not the
intent. An uppercase H will make the regexp check the header, but will
feed the whole message to the pipe. Depending on how the stripper
program works (i.e., whether it will screw up header fields) it might be
necessary to do something like (also relabeling the content type):

:0 H
* Content-Type:whatever
{
:0 fhw
| formail -I "Content-Type: text/plain"

:0 fbw
| stripperprog
}

I _think_ that will feed the header to formail and the body to the
converter, and I _think_ procmail will put everything back together, but
I'm not certain. (Testing this would be a good idea, and I'd do so if
I had time :) One other thing that occurs to me (yeah, I forgot a lot
with my first email) is that the enriched version has a better than
usual chance of being encoded. If this is going to be a problem for
the conversion program, and if your sendmail doesn't autoconvert to
8bit, you'll want to put an 8 bit converter higher up in your
procmailrc. If qp isn't going to be a problem, you still might want
to put another condition like "*!content-transfer-encoding:[ ]base64"
in, because your converter will probably do bad things to base64.
--
Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver,
***@itri.loyola.edu finger, or email with "Subject: get pgp key"
Martin Ramsch
1997-08-19 20:40:12 UTC
Permalink
Post by Michael Stone
Post by Matt Armstrong
:0fhw
* Content-Type:.*enriched/text
| my-strip-enriched-executable
IIRC, the lowercase h will feed the header to the pipe, which is not the
intent. An uppercase H will make the regexp check the header, but will
feed the whole message to the pipe. [...]
Because I tend to mix all these flags up all the time, I tried to make
sort of a short reference card.

Thought I should share it with the audience here -- maybe it's of any
use to others (or some experts can report inaccuracies to me?).

Here it is:
#--- txt.rchelp -------------------------------------------------------
# Format of procmail recipes:
# : [number] [flags] [ : [locallockfile] ]
# <zero or more conditions (one per line)>
# <exactly one action line>
# with:
# number = number of conditions (unless conditions start with '*')
# conditions = Procmail regular expressions, which are ANDed
# plus the following prefixes:
# ! - invert condition
# $ - evaluate remainder according to sh substitution rules
# ? - use exitcode of specified program
# < - check mail length to be shorter than ...
# > - ... to be bigger ...
# var ?? - match against value of this variable (B=body, H=head)
# \ - quote any of the special chars at start of line
# flags = H - egrep the header (default) --> concerns conditions
# B - egreb the body --> concerns conditions
# D - distinguish upper and lower case --> concerns conditions
# (default case insensitive)
# A - "and", recipe depends on condition of last recipe without "A"
# a - recipe depends on success of action of preceeding recipe
# E - "else if", execute if preceeding recipe didn't match
# e - "error", execute if action of preceeding recipe failed
# h - feed header to pipe (default: hb) --> concerns actions
# b - feed body to pipe (default: hb) --> concerns actions
# f - pipe as filter (includes "c")
# c - make "carbon copy"/"continue" even if recipe matches
# w - "wait" for filter or program to finish
# W - like "w" but suppress program failure messages
# i - "ignore" write errors to pipe --> concerns '|' and '!' actions
# r - raw mode (default for delivery to /dev/null)
# : = use local lock file for this recipe
# actions has:
# ! - forward to all specified mail addresses (seperated by commas)
# | - pipes mail (as given by h/b) into specified program
# var=| - ... and store output in var (in this case continuing!)
# { - start of nesting block
# anything else is a mailbox name to deliver to (and stop then)
#----------------------------------------------------------------------

Regards,
Martin
--
Martin Ramsch <***@ieee.org> <URL: http://home.pages.de/~ramsch/ >
Michael Stone
1997-08-19 19:44:29 UTC
Permalink
Post by Matt Armstrong
* Content-Type:.*enriched/text
| my-strip-enriched-executable
But I'd like it to be a non-delivering recipe (but instead a
"modifying" recipe).
OTTOMH:

:0 fHw
* Content-Type:.*enriched/text
| formail -I "Content-Type: text/plain" | mystripexec

Note that you don't need a lock file as there isn't any danger from
contention. I'm also assuming that the content type is correct; I'm
not familiar with a mime type "enriched/text". Unless you are trying
to match things like "this is real enriched/text" I'd also recommend
changing the .* to "[ ]+" where there is a space and a tab between
the brackets. I can't remember offhand whether having two pipes like
this is legal; you might have to wrap that expression in parentheses
or break it into two:

:0 fHw
* Content-Type:.*enriched/text
| formail -I "Content-Type: text/plain"

:0 Afw
| mystripexec

In this case, the second condition executes if the first was true.

Mike Stone
--
Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver,
***@itri.loyola.edu finger, or email with "Subject: get pgp key"
Matt Armstrong
1997-08-19 21:13:20 UTC
Permalink
Post by Michael Stone
Post by Matt Armstrong
* Content-Type:.*enriched/text
| my-strip-enriched-executable
But I'd like it to be a non-delivering recipe (but instead a
"modifying" recipe).
Huh? :-)
Post by Michael Stone
:0 fHw
* Content-Type:.*enriched/text
| formail -I "Content-Type: text/plain" | mystripexec
Thanks for your help. I ended up with this:

:0 fhw
* ^Content-Type:[ ]*text/enriched\/.*
| formail -i "Content-Type: text/plain$MATCH"

:0 afbw
| enriched2plain


Deconstruction:

First rule:

* f flag means "consider pipe as filter" -- this was the piece I
was missing.
* h flag means pipe header only into filter.
* w means wait till filter is done before continuing.
* The condition looks for a Content-Type header that begins with
text/enriched, and remembers everything after that in $MATCH.
There is a space and tab between the brackets.
* The formail line replaces the text/enriched with text/plain,
keeping the rest of the line and adding an Old-Content-Type:
header with the old value (my own use).

Second rule:
* a flag means execute only if the first did successfully.
* b flag means pipe body only into filter (enriched2plain screws up
the mail headers).
* f and w flags, see above
* the enriched2plain utility was posted to this list a week ago by
***@bristol.com


No more enriched/text! Next step is to send an auto-reply reminding
the sender that they annoy most everyone who gets their message. I'll
just adapt my vacation recipes.
--
matta
Timothy J Luoma
1997-08-19 21:24:59 UTC
Permalink
Author: Matt Armstrong <***@geoworks.com>
Original-Date: 19 Aug 1997 14:13:20 -0700
Post by Matt Armstrong
Huh? :-)
Off The Top Of My Head
Post by Matt Armstrong
No more enriched/text! Next step is to send an auto-reply reminding
the sender that they annoy most everyone who gets their message. I'll
just adapt my vacation recipes.
Have fun....

TjL
J. Daniel Smith
1970-01-01 00:00:00 UTC
Permalink
Matt Armstrong writes on 19 August 1997 at 14:13:20
Post by Matt Armstrong
[...]
* the enriched2plain utility was posted to this list a week ago by
while I posted the code to this list, the correct reference is RFC1523
"The text/enriched MIME Content-type".
Post by Matt Armstrong
No more enriched/text! Next step is to send an auto-reply reminding
the sender that they annoy most everyone who gets their message. I'll
this is starting to get off the topic of "procmail" itself...but,
since you are going to be using "procmail" to send your
auto-replies... :-)

Please consider two things
* a lot of auto-replies only serve to upset people by flooding them
with "useless" mail. I've got my system set up to limit
auto-replies to at most once every three days (once/week when I'm
on vacation). You also need to take the "usual steps" to
minimize mail-loops and the like.

* technically, it is mostly *your* problem that you can't deal with
MIME's text/enriched. The date on RFC1523 is Sept-1993, almost
four years ago; plenty of time to update your MUA. And even
"dumb" ASCII terminals can do bold/underlining/highlighting. If
you want to solve your problem using a filter in procmail rather
than a different MUA, that's fine; but I'd think twice about an
auto-reply.

Dan
------------------- message is author's opinion only ------------------
J. Daniel Smith <***@bristol.com> http://www.bristol.com/~DanS
Bristol Technology B.V. +31 33 450 50 50, ...51 (FAX)
Amersfoort, The Netherlands {info,jobs}@bristol.com
Continue reading on narkive:
Loading...