-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As you know, Mailman 2 can filter the content of a message before it's
forwarded on to the list membership. It can reorganize the MIME
structure of a message, based on settings for MIME type and file
extension.
The rules are fairly complex though:
* If the outer MIME type or file extension matches a filter pattern,
the entire message is disposed of.
* If there are pass filters and the outer MIME type or file extension
does not match a …
[View More]pass filter, the message is disposed of.
* If a subpart's MIME type or file extension matches a filter pattern,
that part is disposed of.
* If there are pass filters and a subpart's MIME type or file
extension does not match a pass filter, the subpart is disposed of.
* After all that, multipart/alternatives can be collapsed.
* After all that, text/html parts can be converted to text/plain
* After all that, if the outer message's body is empty and it has
exactly one subpart, the subpart "becomes" the outer part.
Disposal of messages can be one of:
* Reject the message to the original author
* Forward the message to the list owner and discard
* Preserve the message in the 'bad' queue and discard
The Zen of Python says:
"Complex is better than complicated."
"If the implementation is hard to explain, it's a bad idea."
and I think the implementation is both complicated and hard to
explain, and the u/i is no model of comprehension. I'm not entirely
sure how people use this feature though.
Some of the python.org lists have pass-types allowing multipart/mixed,
multipart/alternative and text/plain, while filtering out various file
extensions.
So I'd like to solicit your input on how you use the feature, and if
you have any ideas for an approach that would be easier to understand,
more useful, or both.
Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkmsFQ4ACgkQ2YZpQepbvXEIAACffKwhPLRK4hIbJ7Hs2Cfsitjk
xr8An1RqTVblud9OipgfanywU3Wr8kWV
=E7Nw
-----END PGP SIGNATURE-----
[View Less]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
With David's permission, I quote his message
On Mar 2, 2009, at 1:50 PM, David Champion wrote:
> This is a crazy idea I haven't really thought through, and completely
> tangent to what you're asking, but what about implementing a Milter
> interface (the MTA component, not the filter component) in Mailman
> and adopting its semantics?
>
> Then Mailman could take advantage of an existing framework with many
> instances in the …
[View More]field already, while limiting the use of those
> filters
> to Mailman (not the whole MTA) and being completely independent of
> whichever MTA you're indeed using.
>
> The pymilter project makes writing Milter filters in Python rather
> easy,
> so that Mailman-specific milters can be contributed and distributed
> with
> Mailman. http://www.bmsi.com/python/milter.html
This occurred to me too, so let's explore it.
MM3 has a lot of plugin points, and content filtering could definitely
be one as well. For example, I could imagine a filter such as "leave
nothing but the first text/plain", "strip out all word documents",
etc. implemented as Python modules. Some would come with stock MM3,
others could be added by the site administrator. In fact, I think the
current mime_delete.py handler could be implemented as a plugin
(though I'm not sure you'd want to ;).
The advantage of a plugin architecture here is that I think it is
simpler to implement, understand, explain, and skin. The disadvantage
is that the individual plugins would be less flexible, and you'd need
a site administrator to add third party plugins.
I'm not sure that the milter API is quite appropriate for Mailman,
which has a much different architecture than an MTA. For example, it
doesn't make sense for Mailman to expose SMTP callbacks since that
will have happened long before Mailman gets its paws on the message.
But something /like/ this could make a lot of sense.
Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkmsRCIACgkQ2YZpQepbvXG2ZwCeLhv5WOiuS2iwrxznGqOmZsYj
Al8An3GjQVGTBDN2sIJhjwOKuBZslw5b
=0tfj
-----END PGP SIGNATURE-----
[View Less]