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

[Lindsay Haisley]

On Wed, 2012-06-20 at 14:39 +0900, Stephen J. Turnbull wrote:
> Lindsay Haisley writes:
> 
>  > Any chance of requesting this in Mailman 3?
> 
> As usual, the advice is to file a bug report/RFE on Launchpad, Mailman
> project, tag it Mailman 3 (or maybe that's milestone Mailman 3?)
> 
> If you want more discussion from the core people (well, Barry; Mark's
> presumably already said everything he wants to say about this subject
> :-), you could send mail to mailman-developers, but I think this idea
> is already pretty well-baked, and maybe you even have a patch you
> could attach to the issue?

I was thinking of posting to the dev list, to which I also subscribe,
and inquiring with regard to the advisability of putting this, as you
suggested, into the Resent-Message-ID header, as opposed to the VERP
address or some custom header.

My thinking, from corresponding with Dave and my own observation, is
that both the list address and the recipient address should be AES
encrypted and passed in a single header, and because this information is
pretty much guaranteed to be unique per message, given that my AES
encryption routine uses random input, using the Resent-Message-ID header
would fulfill a dual purpose and satisfy RFC 2822.  The use of this
header would depend on whether the current v3 development blueprint has
plans for this header which would preempt its use for this purpose.

I posted code and patches earlier on this list, but the patch is against
Mailman 2.1.15 rather than Mailman 3, which is the current development
focus.  I imagine it's rather different.  I'd have to take a look at the
code and figure out where the patch might go.

I'm also not up on what the execution time hit would be in generating a
short AES cipher for each outgoing message.  This might be considerable
on a large list with many thousands of subscribers.  As it is now, in my
patch, if VERP is not enabled, or there is no personalization, which I
believe excludes VERP, then no encrypted recipient cipher would be
generated.

When I get a chance I'll take a look at the v3 code.