24 Aug
2017
24 Aug
'17
12:40 p.m.
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
=