Although I value the benefits of "minimalism" that have been suggested in
reply to my query asking about the possibility of procmail being more
MIME-friendly, allow me to continue to take the advocate position, mostly
just to explore the limits of the proposal a bit.
Sean wrote:
Sent: Monday, December 10, 2001 8:04 PM
To: procmail-users(_at_)procmail(_dot_)org
Subject: Re: what if procmail knew about MIME?
At 18:25 2001-12-10 -0800, Gary Funck wrote:
How would it be done? One method might employ a new flag, which
is similar
in concept to the "body" of "B" flag, perhaps something like "A" (for
attachments),
Can't be A/a -- both are already well used.
M perhaps.
Okay.
which would tell procmail to decode the body of message into
multiple MIME parts (if they exist), and construct special dummy "header"
fields that can be checked for in the standard way in the filter
patterns.
Uhm, this raises a big red flag for me. How do you propose that procmail
will handle each of these separate attachments - like 'c' does, forking
another procmail? Or somehow end up with multiple messages within a
single instance of procmail?
Hmmm, I didn't know that the 'c' flag caused procmail to fork off a new copy
of procmail. Is that what your saying above? If it does fork a new copy,
how does procmail know where in the script file to start processing, or the
state of the stack of file includes?
Handling nested MIME parts, or "multipart/alternative" parts
would have some
definitional challenges.
Ya don't say.
Hey, that's why I'm asking for ideas/solutions. :)
Keep in mind that procmail is a linear scripting language, not a
procedural
one (you can't recursively call something -- the closest we have is
INCLUDERC, and that's a really bad substitute for callable functions
available in a procedural language).
Yup. I've pretty familiar with procmail features/behavior at this point.
One idea, might be to define attachment processing as an iteration of the a
block directly following an "M" flagged block. Something like this:
#
# Process each MIME attachment.
#
:0 M:
{ #BEGIN ITERATIVE BLOCK
# ... executed once for each MIME attachment
} #END ITERATIVE BLOCK
This introduces a form of iteration without doing too much damage to
procmail's "language". From an implementation point of view, it might get
tricky, for one thing because of potential dynamics introduced by embedded
INCLUDERC's and/or variable assignments. Perhaps the existing method of
handling INCLUDERC's can be used to deal with this dynamic behavior?
Within the scope of the block, special variables might be introduced which
contain information about the attachment currently under consideration.
This use of the iterative block seems to handle top-level attachments fairly
well, but there would still be a definitional question regarding nested
attachments. Perhaps in this case, a full nested invocation of procmail,
might be necessary. To make such a nested invocation "work", it might be
necessary to first generate a new "dummy" mail message containing the
embedded MIME attachment, and then "delivering" this dummy message to
procmail. The additional support from procmail might only be the generation
of this dummy message containing the sub-attachment. Invoking procmail in
this way would not be predetermined by procmail's processing of the recipe,
but rather via an explicit user-written action.
To summarize, the following additions to procmail are suggested:
1) recognizing MIME attachments
2) special processing of blocks marked with the 'M' flag: procmail iterates
over the action part of the rule, exactly once for each MIME attachment.
3) add a new action that directs procmail to create a new mail message
(details on the fields in that message to be determined), and to then
recursively call (fork) procmail to process the sub-attachment.
Alternatively, perhaps 'formail' might be extended to tell it to perform
iterations across MIME-attachments within a message. This sort of activity
would be similar in concept to formail's "mailbox split" or "digest split"
capabilities that it has today.
Another question: what primitives would procmail need to *generate* MIME
attachments or to manipulate the various attachments within a MIME-encoded
e-mail?
Another convenient flag might be "t" which tells procmail to make a best
effort to convert MIME attachments to text, where possible and
applicable.
Conversion should be the function of an external filter app. It
shouldn't
be stuffed into procmail itself. As it is, one can already filter the
message through a script such as stripmime:
:0f
* somecondition
| stripmime.pl
Yup, I'm sure that most of us have added that sort of processing at one
time/other to our procmail scripts.
The idea behind the suggestion (and the related suggestion of decoding
encrypted messages) is: By decoding/translating the message into text within
procmail, we then make it possible for procmail recopies to look within the
message "body" so that it might look for word sequences or patterns that are
otherwise useful as part of the message filing and message filtering
functions that procmail performs. If I base-encode a text message and send
it to you as a MIME attachment, and your procmail recipe is looking, for
example, for the string "procmail" in the body of the message -- it will
likely not see the printable contents of the message, but only see the base
encoded, apparently meaningless sequence of characters.
If you wanted a MIME-Aware mail processing tool, start with stripmime or
mimencode and write a formail-esque filter tool.
for reference,
stripmime: http://www.phred.org/~alex/stripmime.html
demime: http://scifi.squawk.com/demime.html
mimencode:
http://www.doc.ic.ac.uk/csg/manuals/all-manual-pages/hpux/usr/local/man/man1
/mmencode.1.html
mimencode: ftp://thumper.bellcore.com/pub/nsb/mm2.7.tar.Z
unmime: http://plan9.escet.urjc.es/magic/man2html/1/unmime
unmime: http://home.sol.no/gisle/enjoy/mimelite.html
If these tools are the preferred/recommended method of handling MIME, then
why do we continue to see complex procmail scripts which attempt to
recognize and decode MIME? I think there is a "gap" between Procmail's
current capabilities and the capabilities of the programs mentioned above,
and that mail delivery/filtering solutions which must deal with MIME
require some additional tools and support - independent of whether the new
faculties appear in procmail or elsewhere. If we looked only at user
needs/requirements - i. e., a simple, reliable method for handling and
filtering MIME-encoded mail, and didn't over-emphasize the technical
difficulties - integrating MIME-handling into a procmail filter would seem
like a natural extension of its existing capabilities.
Another capability that might be useful is for procmail to decrypt
attachments, given sufficient direction/authorization by the user.
Again, a function best left to an external helper app - it'd be more
desirable to offload the weird mime bugs caused by various non-standards
compliant mail clients (OutBreak springs to mind) to a separate
tool anyway
- I wouldn't want to have to update procmail every time OutBreak came up
with a novel new way to ignore established standards.
Why is updating procmail any better/worse than having to update the external
helper app? Or, the millions of copies of Symantec's Anti-virus program for
that matter? From the point of view of the system administrator - the
existing mail scanning software isn't meeting its intended function, and the
software must be updated - it doesn't much matter if procmail or a helper
program is updated. Such is the price of legacy and interoperability.
decrypting the body simply for the purposes of matching it
against a pattern
could certainly be useful. Detecting whether a message is properly
authenticated (before filing) might also be useful.
You mean, such as piping the message into gnupg or whatever to check the
signature? I must have missed where this was declared not possible to do
under the present system.
Perhaps there aren't enough generally accepted encodings for
encrypted/signed messages to warrant consideration as a basic facility
within procmail.
pgpenvelope:
<https://sourceforge.net/docman/display_doc.php?docid=3877&group_id=1628>
See also the perl scripts at:
<http://www.david-guembel.de/kmail-gpg.html>
(sending your public key automatically)
<http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_si
ngle/Mutt-GnuPG-PGP-HOWTO.html>
What do the procmail gurus/users/advocates think about the idea of
upgrading procmail's understanding of MIME-encoded mail?
Just the RFC compliant MIME, or all of it?
"all of it" - or at least as much as can be gleaned from current practice.
Perhaps a switch might be added to accept the "permissive" or "strict"
interpretation of MIME?
While I wish dealing with some MIME things was easier, the fact remains
that the bulk of the problem with MIME messages are the lack of
consistency
from one originating app to the next. Passing the message through a fixup
filter could do a lot for dealing with that.
Perhaps so. But the key phrase (IMO) above is "While I wish dealing with
some MIME things was easier ...". If our goal today is to process/filter
*all* mail, including MIME mail, what tools are available to do that easily,
quickly, and reliably? Why isn't adding MIME-capability to procmail a
natural extension of its capabilities? (a rhetorical question, you and David
T. have already offered some valid criticisms of this idea).
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail