At 16:13 2001-12-11 -0800, Gary Funck did say:
> 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.
Officially, it 'clones' it. See 'man clone' - very much like fork, and for
the purposes of discussing the basic operation, I use 'fork', since people
are more familiar with that.
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,
See 'man clone' - info can conveniently be passed via a callback. I
haven't examined the source code to see exactly what it's doing, but this
seems like a reasonable thing to expect, since the function supports it.
:0 M:
{ #BEGIN ITERATIVE BLOCK
# ... executed once for each MIME attachment
} #END ITERATIVE BLOCK
Okay (this is much the idea I had with my aforementioned 'c'-like
behaviour), except that when you want to continue along with any specific
attachment, how do you do that? What if you want to still process the
other attachments? "Oh, there's an attachment which interests us..." --
how do you continue to the following rulesets with that attachment *AND*
still manage to complete processing of the other attachments?
The limitations of a linear language implementation rear their ugly head.
Within the scope of the block, special variables might be introduced which
contain information about the attachment currently under consideration.
Well, one could use some "new" option that creates an array of some type,
which contains information about mime attachments (that that array must be
able to point to OTHER arrays). It might be a LOT easier if the MIME
extensions were able to just eliminate MIME overheads (ignore that an
attachment is embedded within another MIME block, and merely evaluate for
the final resulting list of attachments). After all, the MIME helper
should really be eliminating the concept of MIME wrappers and presenting
the final result, right? Might not be as "powerful" as having all the bits
of data about intermediate MIME blocks, but it'd be easier to implement,
and a lot easier to use...
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.
'formime' ?
Another question: what primitives would procmail need to *generate* MIME
attachments or to manipulate the various attachments within a MIME-encoded
e-mail?
Base-64 encoding, MIME Escaping (for text which merely needs an escape here
and there), different character sets (I trust that nobody here expected
that MIME encoding isn't just for 8-bit data?), generation and pairing of
unique MIME boundaries, creation of filename and type headers, to name a
few. Why not add richtext and HTML (both creation and stripping) to the mix.
Do you strip HTML only if the message arrived with an HTML mime type, or
because you detected it to actually be HTML (which some mail clients will do)?
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
[snip]
PLAINTEXT=|stripmime.pl
:0
* PLAINTEXT ?? some text
action
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?
Because there isn't one all-encompassing helper tool, and none of the
people who want MIME support seem bent on it enough to actually go and
write it.
I'm in the camp that doesn't care about MIME enough to sit down and write
an all-encompassing helper tool: for now, it's a LOT less work to use a few
rules that isolate that a specific mime attachment appears to be present or
not.
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.
The technical difficulties define the difference between a clean
implementation and a dirty one which can make a good tool unuseable.
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.
Picture this: procmail is configured as the LDA. The sysadm doesn't giver
a d*ck about MIME this-or-that, and has no immediate desire to add
upgrading yet another tool to his plate. JoeUser (a fictitious individual,
but one whom we've seen many a post on this list from), isn't the sysadm,
but DOES want to use procmail to perform some message filtering. In fact,
he wants MIME support. Okay, procmail is LDA, and he can't replace the
system-wide copy of procmail - but as long as his script is calling an
external helper app to do the MIME munging, he shouldn't have much trouble
simply providing a user-local copy of a mime helper. No need to wait for
the busy sysadm to update the procmail on the server (which hopefully is
relatively current, but the point is, it doesn't need to be up-to-the-minute).
Further, I'd just as soon not see procmail being updated every two days as
some other MIME tweakage becomes necessary because of a new version of
OutBreak, or a new mime type is created (wouldn't it make sense for the
MIME decoder to KNOW about mime types? Perhaps an external config file
would help, much like Apache has). For those who want the
latest-n-greatest MIME thingamajig (and are willing to contend with other
changes which may have been introduced in what may be a development branch
of the codebase), they can fetch and build it - without necessitating a
change of the base procmail version.
> 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?
I'm thinking there are some blades I don't want on my swiss army knife,
because they're going to make it unwieldy. Better to get a hatchet and use
that, than to try to stuff one into your SAK.
---
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