[Mailman-Users] confidentiality features

[Barry A. Warsaw]

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

>>>>> "mjinks" ==   <mjinks at 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