Re: Long lines with postmap

Victor.Duchovni@MorganStanley.com:
> On Sun, 9 May 2004, Wietse Venema wrote:
>
> > Additional comment: if the idea is to have postmap fold long header
> > lines, then the code should recognize that something is a header.
> >
> > It should not fold non-header text, and it probably also should
> > not apply header patterns to non-header text.
> >
> > In fact, one might want to invoke the mime_state() engine let it
> > do the hard work.
> >
> > postmap -M body -q... apply body patterns
> > postmap -M primary,mime,nested -q... apply header patterns
> >
>
> Yes, the MIME parser approach did occur to me, but it is not clear that
> test cases will always be complete messages. Sometimes they will be just
> random collections header-valued test verctors. So the two solutions solve
> different problems.
>
> With "-M" one might even want to specify separate RE map lists for each of
> the header types. Something along the lines of:
>
> $ postmap -Mheader=map[,map...] -Mmime=... -Mnested=... -q - bodymap ...

I wonder how we should add domain-specific knowledge to the postmap
command. Remember the aborted attempt to add CIDR (Classless
Inter-Domain Routing) support for creating maps. Now it's MIME
awareness in order to correctly match message headers.

What will be next? The partial lookup magic of canonical, virtual,
and *bcc maps? Automatic parent domain lookups as in relay_domains,
access maps and transport maps? All this might be useful for manual
simulations, but it must not lead to inflation of the postmap
command. The partial lookup and parent domain magic would have to
be made configurable instead of being hard coded.

These are some random thoughts.

Wietse