[Mailman-Developers] Mailman Suite beta: what's left?

[Barry Warsaw]

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 at 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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20131104/176e52f1/attachment.sig>