[Mailman-Developers] Re: [Mailman-Users] Re: MIME messages

[Barry A. Warsaw]

[I've moved this discussion over to mailman-developers.  -BAW]

>>>>> "JCL" == J C Lawrence <claw@2wire.com> writes:

    JCL>   Ability to unroll quoted printable.

    JCL>   Ability to unroll base64 encoded plain text.

    JCL>   Ability to strip blocks from message parts that match
    JCL> stated patterns (eg Yahoo/MSN/Hotmail ads, corporate CYA
    JCL> statements, etc).

    JCL>   Ability to filter on line length (eg hold for moderation or
    JCL>   auto-discard/reject).  

Some of this will be added to mimelib when I get a chance.  On the
plus side, Python 2.1 and the future 2.2 has some nice support for all
this via its unicode codecs.  I.e. in the Python CVS there's now a
codec for quoted printable so you can essentially say something like:

    subject = msg['subject'].decode('quopri')

if your subject header is quoted as per RFC 2047.  I've only played
around with this stuff a little bit, to get a feel for what you can
do, so I haven't thought about APIs or doing the actual coding yet.

The downside is that I'm still targetting Mailman 2.1 at Python 2.0,
so some of these features may not be available.

Also, just some quick thoughts on de-mime-ing, which also address some
things that Chuq has brought up, re: regexp filtering,
auto-discarding, etc.

I'm of the opinion that regular expression predicates alone aren't
going to cut it, and that anything more complex is just way way too
complicated to attempt to expose through an email or web interface.
Complexity is already our enemy, IMHO.

So what I'm envisioning is an extensible architecture, a la the
message pipelines, where each filter is implemented in a separate
Python module, conforming to a particular, yet-to-be-defined API.
Mailman will provide a bunch of canned defaults, like
"strip-mime-leaving-only-text/plain" or "match-vbs-attachments".
There will probably be some kind of mix-in model for describing the
action to take when a filter module matches.

Then the admins can choose which filters they want, and what order
they want to run them in.  I'd actually envisioned something like this
for the delivery pipeline, but that (giving admins control) has turned
out to be not as necessary.

Even this may turn out to be too complex, so there may be yet another
level of abstraction that a site admin can glom together, so that a
list admin would be presented with a limited set of `rhythms',
`themes', or `styles' that they can pick and choose from.  I've
thought about a similar mechanism for list themes, like "announce-only
list" or "read-only mirror list".

The point is that there's a lot we can do very cleanly at the Python
level, but that the more configurability we expose at the web/email
interface, the less usable it becomes, IMHO.  So, I'm thinking
seriously about ways to preserve the power Mailman can provide to the
Python hacker while employing abstractions to reduce the cognitive
load on the list administrators and users.

-Barry