[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] mime-aware filtering?

From: Paul Vixie
Subject: Re: [Nmh-workers] mime-aware filtering?
Date: Fri, 22 Jun 2012 20:08:35 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

On 6/22/2012 7:53 PM, David Levine wrote:
> Paul wrote:
>> i realized yesterday that the ever-increasing
>> base64-ization of mail is starting to break my procmail
>> filters, some of which look into the body of the message.

whoa. blast from the past.

> I've been feeling a need for that recently, too.  While I
> wouldn't mind moving away from procmail, this is its only
> drawback for me.
> Could a filter that decodes just the base64-encoded parts of
> a message solve the problem?  It should be fairly simple,
> esp. if it can rely on an existing decoder such as base64,
> openssl, or MIME::Base64.  And if it doesn't worry about
> signature verification.

i think the solution space is bimodal.

if someone is willing to write what they need in perl, they can create a
MIME data structure and surf that from within perl. mh need do nothing
except continue as it does now to supply files and filenames to such
outboard tools.

for people who aren't willing to do that, MH would need to be able to
export the structure of a message in a way that a shell script could
iterate through the parts, asking MH to provide a file or file name of
each attachment. none of these should still be in wire format, in case
the thing that shell script wants to do is call "grep". so base64 and
quoted printable would be undone by MH before the file or file name was
given to the shell script for handling.

> I run a script that de-base64's text/plain parts of messages
> so that I can grep them.  I invoke it manually after inc'ing
> the message, but automatically decoding upstream would save
> me a step.  It uses nmh programs (mhlist, and mhshow or
> mhstore) so is too kludgy other than as a proof of concept
> that maybe has been a bit too successful.

i consider MH's basic mailbox format to be flawed in a MIME world for
which MH was never designed or redesigned. every attachment should be in
its own file, even if that meant that messages were directories no
longer files themselves.

note, i know we can't do that and i know why. i am not proposing it.

but it still ought to be possible to write a shell script that does
something like:

mhpath $foo | while read msg; do
    mhparts $msg | while read part; do
        grep $bar `mhfile $part`

in other words we need a message number format change, something like
"1.4" for message 1 part 4, and "43.2.1" for message 43 part 2 subpart
1, and so on. we need some command like "mhparts" that can output the
list of parts in a message, which might be just the message number if
it's not using MIME. and every other part of the MH tool set needs to be
able to cope with the extended syntax. and we need something like
"mhfile" which will either return the reference to the actual message
file if there's no MIME or it's a single part without qp or base64, or
which will create a /var/tmp file containing the MIME part in completely
decoded ascii or binary or whatever, if there are more than one part or
the one part is encoded in any way.

i imagine an "mhclean" command to remove this session's temp files. i
don't know how else to put a lifetime on them.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]