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

[Jon Steinhart]

Paul Vixie writes:
> 
> On 2012-06-26 2:28 AM, Jon Steinhart wrote:
> > Paul Vixie writes:
> >
> >> let's start talking about what it should look like?
> > Well, for starters, it shouldn't include any threatening commmentary!
> > Big thing that I think that it needs other than cleanup is the ability
> > to scan for attachment part headers instead of stopping at the end of
> > regular headers.
> 
> well that didn't take long. :-).
> 
> m_getfld() is the heart of MH. everything about the storage and access
> model is contained in it, either by its signature or its logic. i'm
> opposed to grafting MIME onto it with a couple more arguments that if
> non-NULL will trigger additional behaviour.
> 
> so when i say "let's talk about what m_getfld should look like" i really
> mean "let's talk about what MH's storage and access model should be."
> 
> int
> m_getfld (int state, unsigned char *name, unsigned char *buf,
>           int bufsz, FILE *iob)
> 
> your move.
> 
> paul

OK, well, I understand your point of view here but I really don't think
that my point of view is really different.  As far as I can tell (once
I get past the dire warnings), the m_getfld looks for stuff in a mail
message and stops once it gets what it needs.  It was designed in the
age before MIME, so its notion of what constituted headers was limited.
Now, MIME did many things that maybe should have been kept separate in
hindsight, but one of them was to extend the definition of headers.  So,
I'm proposing that m_getfld be extended so that it finds these "extended"
headers.  I'm not presently suggesting that it be extended to be able to
decode the multiple body parts that MIME squeezes into the old definition
of body.

As I said in an email years ago, I'd be happy to be able to have scan
optionally do something like this:

1695+ 06/26 Paul Vixie         Re: [Nmh-workers] mime-aware filtering?<<On
1695.1                         image/png name="foo"
1695.2                         application/pdf

It would be nice to be able to decode the body parts to flesh out the part
subject lines but even without that it would be a huge improvement.

I realize that this could all be done by hacking a script around mhlist
but that is really ugly.

Biggest internal structural change that I can think of is that we might
want some array of fields indexed by part number, or a tree of fields.

Jon