[Mailman-Developers] Security standards?

[emf]

So as I understand it, mm 2.2 is dropping email reminders of passwords. 
This has made me think that we'd like more support for 'passwordless' 
manipulation of the UI.

I've come up with a few approaches for this, and I'd like to get 
feedback as to what would be acceptable. Please keep in mind I'll allow 
administrators to require more authentication than I outline below.

* Use case A: an email is a member of a mailing list but has never 
logged into the interface.

I was thinking it would be ok in this context to allow a user-agent to 
approach the interface and provide only the email address to be 
"provisionally authenticated"; they would be allowed to manipulate the 
member's settings. Once they were done doing so, an email would be sent 
to the address that required clicking on a confirmation link to make the 
changes active.

* Use case B: a user-agent presents an email that has used the interface 
previously. If the user-agent presents a visitation cookie that was 
active during the previous manipulation, the user is provisionally 
authenticated again, and gets a similar confirmation email.

If they did *not* have a matching visitation cookie, or present another 
this-is-really-me token, they would not be allowed to manipulate the 
interface until they click a email-verification link.

* Use case C: Some other code (an upstream process, OpenId server, etc) 
provides a username for a user. In this case we accept the user as 
authenticated, and either use our map of username-> email addresses for 
purposes of determining membership or accept an email_addresses list 
from the WSGI environment or from the remote server/other process.

If only the username is provided, the user is given the opportunity to 
indicate which email addressess should be associated with that username; 
once they have done so, verification emails are sent to said addresses, 
and post reply/link activation mailman considers those emails to be 
associated with that username.

Does this stuff sound reasonable?

~ethan fremen