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

[Paul Vixie]

On 2012-06-26 11:18 PM, Jeffrey Honig wrote:
> A few points on this discussion:
>
> 1) The person who promised to re-write the API was an Internet Elder.
>  Google it.

and after that... bite me.

> 2) Callbacks vs data structures
>
>    One reason you might want to have callbacks is that the content
> might be GPG or otherwise encrypted and you may want to prompt the
> user.  You could of course put methods/callbacks in the data structure
> to handle this.

i think a part handler could read/write from a mime_part_t into a gnupg
pipe either way. we may want to offer a recursive iterator that does the
callback thing, for callers who prefer working that way. but such
callers would have to maintain their own ancestor-state to know which
leg of an alternative-multipart they were in, and so on. so it's not
obviously easier, just different.

> 3) Expanding MIME messages into dirs
>
>    a) Don't forget about encrypted content when using a cache,  you
> probably don't want to cache it.

i agree that you certainly would not want to cache the cleartext. but
caching a second copy of the crypted text, where the part it was in got
copied to a file somewhere and all the base64 got decoded, is no big deal?

>    b) If you use .msgnum.mime would most clients ignore the dirs (i.e.
> .55.mime)?

all the mh directory processors i've written (or in the case of uw imap,
that i've patches) ignore dirent's whose name begin with a dot, before
they bother to stat() it to see if it's a directory or not. i think we
could ignore those who don't. but i still prefer not to permanently
unpack mimeballs. the authoritative source of a message is what came in
over SMTP, with a received: header added. in fact i'd've been willing to
keep the \r\n line terminations, though that ship has already sailed.
anything that's non-canonical should be in a separate storage container,
such as nmh-cache.

paul