Users, members, accounts and subscribers
Oh my!
In an attempt to introduce a friend to MailMan3, I had her subscribe to a couple of lists that I set up and we exchanged a few messages via the email interface.
Then I introduced her to the web interface and we were both confused when she could not log-in/sign-in and was told that her email address was not recognized.
It was only later that I realized that while she was a subscriber, she hadn’t yet signed up for an account.
What is the point of “accounts"? Why can someone become a subscriber, but not have an account?
I find the user/member/subscriber explanation at http://mailman.readthedocs.io/en/latest/src/mailman/docs/architecture.html to be very confusing.
Cameron Smith
On Sun, 20 Aug 2017 12:22:02 -0700 Cameron Smith <ccsmith@cetsi.com> wrote:
Oh my!
In an attempt to introduce a friend to MailMan3, I had her subscribe to a couple of lists that I set up and we exchanged a few messages via the email interface.
Then I introduced her to the web interface and we were both confused when she could not log-in/sign-in and was told that her email address was not recognized.
It was only later that I realized that while she was a subscriber, she hadn’t yet signed up for an account.
What is the point of “accounts"? Why can someone become a subscriber, but not have an account?
The frontend is purely optional when using Mailman 3. They (frontend and Core) are actually two separate systems which maintain their own user list.
If someone doesn't want to use the web interface, there is no account automatically generated for them there. You can interact with Mailman Core (the part that handles the emails) to subscribe/post to mailing lists.
You have to sign-up for a new account on the web interface if you want to manage your subscriptions through it.
I find the user/member/subscriber explanation at http://mailman.readthedocs.io/en/latest/src/mailman/docs/architecture.html to be very confusing.
That documentation is about the internal architecture of Mailman Core and would probably not be much useful to you as a user.
I can explain that to you if are still interested though, trying to avoid a whole lot of (maybe) unnecessary typing ;)
-- thanks, Abhilash Raj
Cameron Smith writes:
In an attempt to introduce a friend to MailMan3, I had her subscribe to a couple of lists that I set up and we exchanged a few messages via the email interface.
Then I introduced her to the web interface and we were both confused when she could not log-in/sign-in and was told that her email address was not recognized.
In theory we could recognize addresses, and tell the user that the address is not associated with an account. This might not be a bad idea, but in theory it could be used by spammers to confirm that accounts are good ones.
What we can do right away is to add a generic statement to the sign in screen that "addresses that are not linked to accounts and presented along with a valid password will be not be recognized".
It was only later that I realized that while she was a subscriber, she hadn’t yet signed up for an account.
Yes, that will happen in some cases, depending on how the subscription was created.
The solution is simple: create an account via the web interface, and link the address (and therefore subscriptions using that address) to the account.
What is the point of “accounts"?
A "user" or "account" manages the entire relationship that a person has with a Mailman installation, including subscriptions, personal profile, administrative roles, and credentials (currently just passwords). An account may have several addresses associated with it and several subscriptions. Sometimes several addresses may be subscribed to the same list, because subscription is often required by the posting priviliege.
In Mailman 2, where a person is identified by an address, a person with several addresses would have to manage the credentials and preferences for each address separately. Mailman 3's concept of "user" allows a person have one account with a single password, set typical preferences, and still have exceptional configurations for particular subscriptions. It's more complex, but experience shows users are happy to accept this much extra complexity for the power and convenience.
A "subscription" links a particular address and the associated user, if there is one, to a mailing list. An address is its own credential: if you can reply to a mail sent to an address, it is assumed you own that address and are allowed to subscribe it to lists, post from it, etc. (Not just by Mailman: this is an extremely common setup on the Internet.) However, this model becomes inconvenient rather quickly if you need to manage relationships among several addresses.
Why can someone become a subscriber, but not have an account?
There are subscriptions, such as other lists or archiving services, that don't serve a single human person. It also is a reasonable approach to situations where it's a bad idea, or even impossible, to access personal data and credentials, such as a subscription by an admin on behalf of a person.
Excellent = explanation. Thank you Stephen.
On = 2017.08.20, at 19:41 , Stephen J. Turnbull =
<turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Cameron Smith = writes:
In an attempt to introduce a = friend to MailMan3, I had her
subscribe to a couple of lists that I = set up and we exchanged a
few
messages via the email = interface.
Then I introduced her to the web interface and we were = both
confused when she could not log-in/sign-in and was told that = her
email address was not recognized.
In theory = we could recognize addresses, and tell the user that the
address is = not associated with an account. This might not be a
bad
idea, = but in theory it could be used by spammers to confirm that
accounts = are good ones.
What we can do right away is to add a generic = statement to the
sign in
screen that "addresses that are not linked = to accounts and
presented
along with a valid password will be not be = recognized".
It was only later that I = realized that while she was a subscriber,
she hadn=E2=80=99t yet = signed up for an account.
Yes, that will happen in = some cases, depending on how the
subscription
was created.
The = solution is simple: create an account via the web interface,
and
link = the address (and therefore subscriptions using that address)
to
the = account.
What is the point of = =E2=80=9Caccounts"?
A "user" or "account" manages = the entire relationship that a
person
has with a Mailman = installation, including subscriptions, personal
profile, = administrative roles, and credentials (currently just
passwords). = An account may have several addresses associated with
it
and = several subscriptions. Sometimes several addresses may = be
subscribed to the same list, because subscription is often =
required by
the posting priviliege.
In Mailman 2, where a = person is identified by an address, a person
with several addresses = would have to manage the credentials and
preferences for each address = separately. Mailman 3's concept of
"user" allows a person have = one account with a single password,
set
typical preferences, and = still have exceptional configurations for
particular subscriptions. = It's more complex, but experience shows
users are happy to = accept this much extra complexity for the power
= and
convenience.
A "subscription" links a particular address = and the associated
user,
if there is one, to a mailing list. An = address is its own
credential:
if you can reply to a mail sent to an = address, it is assumed you
own
that address and are allowed to = subscribe it to lists, post from
it,
etc. (Not just by Mailman: = this is an extremely common setup on
the
Internet.) However, = this model becomes inconvenient rather
quickly if
you need to manage = relationships among several addresses.
Why can someone become a subscriber, but not have an = account?
There are subscriptions, such as other = lists or archiving
services,
that don't serve a single human person. = It also is a reasonable
approach to situations where it's a bad = idea, or even impossible,
to
access personal data and credentials, = such as a subscription by an
admin on behalf of a = person.
_______________________________________________
Mailman-user= s mailing = list
mailman-users@mailman3.org
https://lists.mailman3.org/mailman3/=
lists/mailman-users.mailman3.org/Cameron = Smith
=
participants (3)
-
Abhilash Raj -
Cameron Smith -
Stephen J. Turnbull