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 conecept to the "body" of "B" flag, perhaps something like "A" (for
attachments),
Can't be A/a -- both are already well used.
M perhaps.
whihc 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? Sor somehow end up with multiple messages within a
single instance of procmail?
Handling nested MIME parts, or "multipart/alternative" parts would have some
defintional challenges.
Ya don't say.
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 prodcedural language).
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
If you wanted a MIME-Aware mail processing tool, start with stripmime or
mimencode and write a formail-esque filter tool.
Another capability that might be useful is for procmail to decrypt
attachments, given sufficient direction/authorizaion by the user.
Again, a function best left to an external helper app - it'd be more
desireable 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.
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.
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_single/Mutt-GnuPG-PGP-HOWTO.html>
What do the procmail gurus/users/advocates think aobut the idea of
upgrading procmail's understanding of MIME-encoded mail?
Just the RFC compiliant MIME, or all of it?
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.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail