No email confirmation when subscribing via the REST API

I think that it is important for this to be controlled an administrative list policy setting.
When someone logs in using BrowserID, for example, and then subscribes to a new mailing list, the subscription can be marked as "email confirmed". But if they simply enter an email address on a form, the website need to be able to trigger the issuance of a "request subscription confirmation" email.

Richard

On May 30, 2012, at 6:21 AM, Robert Niederreiter wrote:

> Public bug reported:
>
> Currently it is not possible to subscribe as anonymous user.
>
> ** Affects: postorius
> Importance: Undecided
> Status: New

> ** Tags: anonymous confirmation subscription ui

would it make sence to add a flag for each list enable/disable this behavior? (somewhat like "allow anonymous subscription")?

Robert.

On May 30, 2012, at 12:28 PM, Richard Wackerbarth wrote:

>I think that it is important for this to be controlled an administrative list
>policy setting. When someone logs in using BrowserID, for example, and then
>subscribes to a new mailing list, the subscription can be marked as "email
>confirmed". But if they simply enter an email address on a form, the website
>need to be able to trigger the issuance of a "request subscription
>confirmation" email.

What does "subscribe as an anonymous user" actually mean?

Do you mean, without a user account on Postorius? It makes no sense to me in
the context of the core, because subscribing is the very act of providing an
email address, which de-anonymizes you.

Now, it may make sense to support a subscribe-without-email-confirmation step,
but I think that should not be an exposed workflow for end users. To much
potential for spam.

A valid use case for non-confirmation subscriptions might be: Alice manages a
team at work and wants to run a mailing list for all of her team members. Bob
joins the team, so Alice wants to subscribe him; since he's a direct report,
she doesn't need nor want him to confirm his email.

This can be handled in a number of ways, using the general roster API. mm3
currently supports setting a message's recipients via flat file, so that might
be one way.

actually, in postorius you need to be authenticated in order to subscribe to a list

"anonymous" refers to the authentication in postorius in this case

it would be nice to just have subscription form available to the public, sending a "subscription confirmation" to the entered mail address with a confirmation link, finally do the list subscription if confirmation link gets clicked.

Robert

Pasted from IRC/#mailman:

florianf
barry: just to make sure: if you subscribe a new address to a mailing list via the rest API this new member will not get a confirmation mail, correct?

barry
florianf: that's right. however, unless the email address has already been validated, no delivery will occur (i.e. unvalidated emails are filtered out of recipient lists). i suppose we need to think about how to trigger an email confirmation for rest subscribed emails

...

florianf
barry: that's what robert's bug report is about: a rest-based subscription w/o postorius account should trigger an email opt-in mail…

barry
florianf: one possibility is to add a flag to the POST variables for /members. the semantics would be that *if* the email address is brand new, it should get a confirmation msg. that would have to be plumbed through, but i think that's fine.

rnix
barry: well then request parameters as control flags would be appropriate.. ?

barry
rnix: that's what i think too

On May 30, 2012, at 11:06 AM, Robert Niederreiter wrote:

> actually, in postorius you need to be authenticated in order to
> subscribe to a list
>
> "anonymous" refers to the authentication in postorius in this case
>
> it would be nice to just have subscription form available to the public,
> sending a "subscription confirmation" to the entered mail address with a
> confirmation link, finally do the list subscription if confirmation link
> gets clicked.
>
> Robert

+2 :)

there's one question left from my POV

should there be configuration flags for each list?

one defining if a confirmation mail gets sent, one defining if the list can be subscribed unauthenticated ttw.

Robert

> one possibility is to add a flag to the POST variables for
> /members. the semantics would be that *if* the email
> address is brand new, it should get a confirmation msg.
> that would have to be plumbed through, but i think that's
> fine.

would it be more appropriate to provide IRegistrar.register through the REST api instead of adding a flag to subscribe and implement register in mailman.client as well?

This bug has been moved to the new gitlab repo here: https://gitlab.com/mailman/mailman/issues/44

This bug has been moved to the new gitlab repo here: https://gitlab.com/mailman/postorius/issues/7