[Mailman-Users] AOL redacts user addresses even with VERP and full personalization enabled

David dave at fiteyes.com
Mon Jun 18 20:59:03 CEST 2012

On Mon, Jun 18, 2012 at 2:44 PM, Lindsay Haisley <fmouse-mailman at fmp.com>wrote:

> On Mon, 2012-06-18 at 13:04 -0400, Tanstaafl wrote:
> > On 2012-06-18 12:22 PM, Lindsay Haisley <fmouse-mailman at fmp.com> wrote:
> > > Doing this as a custom hack helps.  If this were implemented as a
> > > Mailman standard option then word might indeed get back to them about
> > > it.  Using Resent-Message-ID as a header name is a clever idea.
> >
> > I'd also argue that since this is not AOL specific but is a generic way
> > for a mail system admin to control his own server, and AOL cannot
> > dictate what you add to your own headers on your own messages, why not
> > make it part of mailman official, with appropriate warnings about some
> > brain-dead (probably unenforcable and possibly even illegal) limitations
> > by certain clueless providers?
> I agree.  Stephen Turnbull points out that using reversible encryption
> with a secret key would be more secure from the point of view of
> restricting 3rd party knowledge of the unencrypted/unhashed data.  A
> secret key could be kept per-list or per-site.  The ability to securely
> track recipient information (or any information) across a list
> distribution, or across a non-delivery bounce might be very useful.
> It might be very convenient to have what one might call EVERP, where the
> recipient address is encrypted into the envelope sender address, as an
> alternative choice to Mailman's VERP implementation.

This whole thread is a good and interesting discussion. Anything along
these lines sounds like a great suggestion  to me.

In terms of privacy, as list admins we already have the member's
information. All we are doing in this case is helping that member stop
receiving messages they obviously no longer wish to receive. This is
clearly not an invasion of privacy (especially with a properly encrypted
implementation). It is a service to the individual (and to the entire list
membership and even the Internet as a whole, I think).

Originally, this seemed appropriate as a personal project. But the more I
think about this, the more clear it seems that a feature that allows a list
admin to stop sending emails to members who no longer want that email is a
very good feature to include in Mailman. It can help ensure that Mailman is
used in a way that causes the least amount of grief for everyone across the
Internet, right?

More information about the Mailman-Users mailing list