Well, let's think about this ...
It's NOT true that "The user who sends an email command is provided with a
response that tells him what's wrong." The example in question is where a
valid user sends (from his registered address) the command 'who PASSWORD'
but employs the wrong password or mistypes what he thinks is the correct
password. In that case, the response is
> You are not allowed to retrieve the list membership
This not only DOESN'T tell him what's wrong (Why am I not allowed to
retrieve the list membership?), but is actually FALSE. As a registered user
sending from the correct email address, he IS allowed to retrieve the list
membership. But the message suggests that somehow he (as a registered user)
doesn't have the correct permission to execute the command. That's just
misleading, confusing, and wrong.
What would I want you to do? Well, how about a diagnostic of
> Your request for the list membership has been denied because you
submitted the incorrect password for your account.
> The password you submitted was: PUT_SUBMITTED_PASSWORD_HERE.
> This is not your password for the PUT_LIST_NAME_HERE list.
This message is both informative and potentially helpful both to a user and
to a remote administrator, as in the case at hand. Would it be a "security
risk"?
Now let's look at the claim that "If the roster is not public, we can't give
more information because if we tell you that it is the password that's
invalid or the email address, this information can be used to fish for list
membership and this is not public information." But this is specious
reasoning. Why?
An astute user (which we presume would be the case with someone who's
fishing for list membership) can discover whether the problem is with the
password or the email address. (Actually the degree of astuteness here is
not high.) The first thing he needs to do is determine whether he has a
valid email address for a member. This is simple: he just fishes on the
email address. He sends the command
password
If he somehow manages to send this from the correct email account (or in
some other more sophisticated way manages to send the command and catch the
return message), he's rewarded by the list sending him that password. Now
he can get the list membership. If he doesn't send this command from a
member's registered email address, he gets the diagnostic message:
> You are not a member of the XXXX list.
and he just keeps fishing. So not telling someone straightforwardly that
they've submitted the wrong password doesn't add any degree of security
against fishing. Anyone can quickly tell whether an email address is or is
not one for a registered user, and then can quickly tell whether he does or
does not have the correct password -- completely independent of whether you
tell him that explicitly in a diagnostic message. Or have I missed
something here? Actually, it seems to me that your response to a 'password'
command from an unregistered email address is unnecessarily informative. It
would be safer simply to respond with
> Your request for your password has failed. Please contact the
list administrator
> immediately for additional information and to ensure the
security of your account.
This at least doesn't say explicitly to the fisher that he's tried with a
bad email address. But I think it's splitting hairs since the degree of
security in any case here is fairly low.
So where are we now? It appears to be pretty clear that providing a more
informative message in this case is both potentially quite helpful (to both
the user and an administrator attempting to help him at a distance), and not
a source of an increased security risk. So why not do it?
Finally, let's consider "The problem here is we don't anticipate a third
party acting at a distance and unable to get reliable information from his
user." Why not? This seems quite a reasonable scenario to anticipate.
Users are notoriously unreliable in what they report and how they report it.
And the user can provide information that's only as reliable and accurate as
what he gets from the list in terms of diagnostics. I feel a pontificating
lecture coming on about user interaction design, but I'll refrain :-).
At this point it's quite clear that the problem with this user is that he
keeps using the wrong password. I've told him that, but I somehow have to
(nicely) rub his nose in it. Without setting up an appointment with him and
travelling about 50 miles round trip (which is going to be unlikely with
him), there's not much I can do. But the simple change I've suggested in
this one particular diagnostic response would allow me to help him remotely.
_______________
Gary H. Merrill
Chatham Design Consultants
+1 919.271.7259
> -----Original Message-----
> From: Mark Sapiro [mailto:m...@msapiro.net]
> Sent: Tuesday, January 20, 2015 11:01 PM
> To: ghmerr...@chathamdesign.com; mailman-users@python.org
> Subject: Re: [Mailman-Users] Diagnosing command failures
>
> On 01/20/2015 06:59 PM, Gary Merrill wrote:
> > I was really asking whether there is a way to diagnose command
> > failures in Mailman, and it's clear at this point that the answer is
"No."
> > This isn't entirely unexpected, but I just wanted to check in case
> > there happened to be something that I'd missed.
>
>
> It depends. The user who sends an email command is provided with a
response that
> tells him what's wrong.
>
> We try to provide diagnostic information that is helpful to the user.
> The problem here is we don't anticipate a third party acting at a distance
and unable to
> get reliable information from his user.
>
>
> > A "diagnosis" of
> >
> >> Error
> >> LISTNAME roster authentication failed.
>
>
> What more would you like to see? Presumably the user knows what he
provided for
> his email address and password and the response says one or both is
invalid. If the
> roster is not public, we can't give more information because if we tell
you that it is the
> password that's invalid or the email address, this information can be used
to fish for
> list membership and this is not public information.
>
> You could set Privacy options... -> Subscription rules -> private_roster
(aka Who can
> view subscription list?) to Anyone and that would simplify your user's
task, but you
> may not want a public roster.
>
>
> > Personal consultation and observation appears to be the only approach
> > here that will be successful.
>
>
> As I said,
>
> >> I can give you patches to log everything if that's what you want
>
> Let me know.
>
> --
> Mark Sapiro <m...@msapiro.net> The highway is for gamblers,
> San Francisco Bay Area, California better use your sense - B. Dylan
------------------------------------------------------
Mailman-Users mailing list Mailman-Users@python.org
https://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
