>> I would be happy to discuss what we had in mind for filtering, in the>> event that hypermail might get filtering added in a native way.>> In general, I'm against introducing filtering in hypermail. Hypermail> converts mailboxes into HTML. Filtering should be done prior to the storage> in the mailbox, IMHO.>> procmail is a great tool for such kind of filtering.

Filtering was intended to do some things that were not obvious to
mailbox contents; you can tell me if procmail could do these things
to messages saved in a mailbox.

Our belief was that somebody has a mailbox that collected mail about
a subject (or series of subjects) and wants to publish them on the
web so that other people can easily see them. In the real world, such
a mailbox might have messages that the publisher doesn't want on the web,
and other messages where the "Subject:" field does not accurately describe
the contents.

Our intent with filtering was to allow some after-the-fact corrections
based on these realities. Our filters were designed to have three parts,
a subject match, a date match, and an action.

The subject match could match any subject, or provide a string to be
equal to the subject, or provide a string that might be contained in
the subject.

The date match could match any date, or have a date before a specified
date, or have a date after a specified date.

The action would be to either discard the message (meaning that it would
not have an HTML page generated for it), or to set the subject to a new
subject.

For example, if there were a chain of messages where people were replying
to previous messages but the subject changed, then a filter could be used
to reset the subject to something more descriptive, after a specified date.

That would make reading the HTML pages more informative.

The filtering was expected to be before hypermail processing itself was
performed, with a process that would empty the "real" mailbox and create
a "temporary" mailbox for hypermail input.

We had looked at more capable filters, but we had some difficulty finding
an intuitive way to build them through a GUI.

Our filtering was seen as a way of doing "fixups", not of routing messages
to a particular mailbox or blocking spam.