[Mailman-Developers] Trying to install mm 3.0.0b1

[Barry Warsaw]

On Jun 21, 2012, at 10:32 AM, Lindsay Haisley wrote:

>Barry, I don't know if you followed the discussion on the Users list
>regarding placing an encrypted (AES) header into personalized, VERPed
>list posts which would contain the subscriber recipient's address and
>possibly also the list address.  This would satisfy AOL's TOS (others,
>too) and not be redacted in their Email Feedback Reports.

I've been skimming it, so I think I get the gist.

>I have some patches and files to this end, Which I've applied
>successfully to Mailman 2.1.15 and the suggestion was made on the Users
>list that I submit them for possible application to mm 3, which would
>probably be a more appropriate place for this feature.

Agreed.  I think *something* like this would be useful for mm3.  I'm not sure
about the best way to do it, i.e. whether it should be a generally available
feature enabled by some config, or whether it should be implemented as a
plugin.  We could certainly discuss all that here.

>To do this I need to set up a test installation of mm 3 which actually
>works, and delivers mail to a test list.  I don't need to deploy it for
>general use.

Cool.  The previous virtualenv instructions should still be relevant.  You'd
of course need to hook it up to an MTA, but mm3 has a nice "development" mode
you can enable, which will ensure that the SMTP RCPT TO header will be forced
to a specific address.  What this means is that with devmode enabled, you can
forge all the RFC 5322 headers you want to make it look like real email, and
it'll never escape your local test environment.  E.g. if you put the following
in your mailman.cfg file:

[devmode]
enabled: yes
recipient: me at example.com

*All* of the email sent through your mm3 deployment will actually get
delivered to me at example.com.  There are other ways to do similar things
e.g. using Postfix transports, but you may not need them.

To make something like this a supported feature does require more work,
e.g. probably a schema change, plumbing through REST, documentation and a test
suite.  A Launchpad bug and merge proposal will be ideal.  But don't let that
discourage you.  If you can come up with a nice proof-of-concept once of us
can help shepherd you through the rest of the process.

Cheers,
-Barry