On Nov 02, 2013, at 04:06 PM, Stephen J. Turnbull wrote:
So this feature in particular, if Postorius can do all the necessary confirmations, I can much more easily provide an API that Postorius can call to associate an email address with a given user.
I'm getting that ol' sinking feeling. Either Postorius is *the* Mailman 3 user/admin UI, or it isn't. If it is, shouldn't we merge the projects sooner rather than later?
If it isn't, Mailman should be able to do this kind of thing itself.
It should be reasonably low-cost to build a simple django app (or lower-level, SimpleHTTPServera app) that handles confirmation.
Or we can do without web confirmation URLs if there's no admin UI available.
I think it definitely makes sense for there to be a REST API to explicitly add an email address to a user, or to link an existing address to a user. There's already an API for verifying (and unverifying) an email address. This API would not do any confirmations - it would trust the client to have done whatever it takes to ensure that the user owning the first (existing) address also owns the second address. If we want to combine linking and verifying in one step, then the client would be trusted to ensure that the user owns both addresses *and* that the second address is actually valid. I'm guessing this would be the most common use case.
If the client wants to leave it to the core to do the confirmations, I think that would be a separate API. What would be the protocol, given that we want to make sure that both addresses are owned by the same user *and* we want to be sure that the confirmation process can't be used to mine information such as potential addresses subscribed to the system?
Strawman:
Generate a unique token for the dual-confirmation event.
Send a confirmation message to the user's preferred address. It would say something like "Someone has requested linking foo@example.com to your Mailman account. If this was you, please reply (and/or click) to confirm this request. The request will not be completed until you complete a similar confirmation in your foo@example.com account. If you did not make this request, ignore this message."
The Reply-To address would contain the token.
(With sufficient hand-waving, the URL would contain the token.)
Send a message to the new address saying "You have requested a registration of your foo@example.com address to the Mailman server at example.net. Reply (and/or click) to confirm."
Maybe they get different tokens. In any case, nothing would happen until both requests are confirmed.
The confirmation to the new address is specifically crafted not to reveal whether the original address is registered or not. E.g. if the core had to do a new user registration, it would send a similar message, and nothing about the original account would be leaked in this second email. To a new user, it would just look like an original registration confirmation message.
The "click" part is where we get hand-wavy. I need to finish up my template branch so that these types of "core knows something about the web ui" assumptions don't have to be hard-coded. Even if Postorius is the default ui, we may not know exactly how to contact it, or whether the site has customized various texts. I'm thinking something similar to the way the welcome message is now retrieved via url.
Cheers, -Barry