Please trim followups to mailman-developers@python.org...

...

...

...

...

"mjinks" == <mjinks@bsd.uchicago.edu> writes:

mjinks> First of all, in testing it appears that although the
mjinks> "From:" header is stripped, the "X-Sender:" still comes
mjinks> through, as does the sender's IP address.  We're in a
mjinks> university, so back-tracing an IP address to a nearby
mjinks> individual is not that tough, and could certainly be seen
mjinks> as a gap for confidentiality.  Could X-Sender and IP also
mjinks> be stripped?  Have I missed some detail?

Mailman doesn't know about X-Sender, so it doesn't by default strip those. You'd probably also have to grok through Received: headers and others to truly anonymize the message.

mjinks> On the other hand, this user wants to be able to peek
mjinks> behind the curtain in those cases where confidentiality
mjinks> needs to be violated -- for example if a poster to the
mjinks> list claims to be suicidal or otherwise seems dangerous.
mjinks> I showed the user that he'd see the real return address if
mjinks> we set the list to be moderated, but he didn't like that
mjinks> idea.  Any clues?  Can identifying information be made
mjinks> available, say, to the list owner only?

Here's the approach I would explore, using the 2.0 code base.

Write a message handler module (see Mailman/Handlers/* for examples), calling it Anonymize.py. Put this in the pipeline such that every message passes through it before it's delivered to the archiver, or usenet, or the list.

In this module, you'd strip or munge all the headers you want. To support lifting the curtain, you can store (securely, on the file system) whatever information gleaned out of the message is necessary to link the poster with the email message. You might even key both off of a randomly generated ID, which you'd poke into the outgoing message.

Now that I think about it, it wouldn't be too hard to extend this idea into a general framework for email anonymizing. Given an MTA that can handle highly dynamic updates to it's alias database, you're "randomly generated ID" above would be used to create a Reply-To: address pointing back to your anonymizing service. Your add-on stuff would handle delivering back to the original user based on the random address.

Oooh, what a neat idea! Let me know if you decide to play around with this. It'd be really cool to add some more anonymizing features in a future version.

-Barry