[Mailman-Users] confidentiality features
Barry A. Warsaw
bwarsaw at cnri.reston.va.us
Wed Mar 22 18:48:15 CET 2000
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
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
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
More information about the Mailman-Users