Re: Mailman's Approval Duties Denied Me.

[Bob Proulx]

Hello Ralph,

> Thanks for your analysis of that list's problems, and how they apply to
> the other two nmh ones I admin too.  I'll carry out those suggestions
> tomorrow.

The standard operating procedure I recommend for new subscribers is to
have them moderated by default.  Then when they post their first valid
message I unmoderate them from the Mailman summary page.  The detail
page unfortunately lacks that control button.  But the summary page
allows approving the message and unmoderating the user in one
submissions.

Also for non-subscribers the summary page form is adaptive and changes
to allow whitelisting that non-subscribed user.  I recommend doing
that too.  As a general guideline all of the lists.gnu.org lists are
open to everyone including non-subscribers.  Becuase most started as
bug reporting mailing lists and we wouldn't want to require someone to
be subscribed to report a bug.  And the same thing to some extent when
asking for help on a help list.  Although certainly it makes sense for
everyone in a discussion to be subscribed making discussion lists a
judgement call from the list owner.

> `norm', a nice guy, is an octogenarian user of nmh, and one of its
> original authors as MH back at Rand Corp.

Cool!  I am sure Norm is a nice guy.  Hopefully nothing I said
impinged upon anyone's character.

> He gives us useful insight, but would never need to post to
> announce, or have been put on that list.

Everyone makes mistakes.  I hate to admit how many mistakes I have
made when dealing with email!  And I dare say that I know more about
how email is handled and processed than most people these days.  Yet I
still make mistakes way too often.  Its that problem of being human.

> Also, if he was on it when his email arrived then Mailman wouldn't have
> sent me this `requires approval'.

Right.  The log I posted clearly showed the message was manually
approved.  Someone approved it.  As far as I can tell from the log
message anyway.

> > Third if you suspect that someone else also has the password to the
> > mailing list admin interface then I suggest changing that password.
> 
> I changed all three to distinct passwords when I was made admin.  The
> other two main developers didn't want to get involved so I've told no
> one.  They're styled like `8nTdAEjdn2q'.

Just curious...  From 'pwgen -s 11 1'?  That is my usual go-to tool
for generating random passwords such as those.  And all of my
passwords are random passwords these days.

> That norm was added to accept_these_nonmembers suggests it's one of the
> moderator helpers that's used to keeping future workload down by
> updating those lists as they approve, discard, etc.

I must agree.  The evidence is only circumstantial but seems too
plausible to think otherwise.

> > I suggest changing the list password.
> 
> Sorry, it wasn't me, and no one else knows them.  (Ignoring the normal
> Mailman thing of storing them plain and sending reminders.)

If you have changed the password and only you know it then that leaves
the Listhelper team and the FSF admin team.  And frankly all of us are
busy doing our own things and so not likely to go looking for more to
do.

I'll send a note around to the listhelpers to make sure they are aware
of the problem.

> This thing where the three nmh lists don't have `helper moderation' any
> more, is that a mechanical device where their queue contents simply
> aren't presented to helpers,

It's that.

> or a `please remember to skip over those' where folks could be
> fallible?

It's the first.  I added those three to the file myself.  It happens
to be in RCS because, well, it works and has been that way for a long
time.  Here is the log message.

  date: 2018/01/08 01:14:53;  author: rwp;  state: Exp;  lines: +3 -0
  Add nmh-announce, nmh-commits, nmh-workers to the hands off list.

The lines are exactly this:

  address@hidden:/u/listhelper/www/moderate$ grep nmh- fsf-lists
  nmh-announce
  nmh-commits
  nmh-workers

The characters seem exactly plain.  I don't see any funky characters
that would prevent the grep from working.

  address@hidden:/u/listhelper/www/moderate$ grep nmh- fsf-lists | od -Ax -tx1z 
-v -c
  000000  6e  6d  68  2d  61  6e  6e  6f  75  6e  63  65  0a  6e  6d  68  
>nmh-announce.nmh<
           n   m   h   -   a   n   n   o   u   n   c   e  \n   n   m   h
  000010  2d  63  6f  6d  6d  69  74  73  0a  6e  6d  68  2d  77  6f  72  
>-commits.nmh-wor<
           -   c   o   m   m   I   t   s  \n   n   m   h   -   w   o   r
  000020  6b  65  72  73  0a                                              
>kers.<
           k   e   r   s  \n

  address@hidden:/u/listhelper/www/moderate$ wc -l fsf-lists 
  45 fsf-lists

And yes the file started out being the list of FSF lists that are also
hands off too.  So now we use fsf-lists as a generic hands-off
listing.  And the index.cgi script itself hasn't changed since 2014.

  date: 2014/11/23 19:18:41;  author: rwp;  state: Exp;  lines: +2 -2
  debbugs is now redirects to https so use https initially too

The script itself I could show the URL to but would prefer not to
expose it too much to the outside world.  It doesn't really need
security itself but it keeps the noise to the logs down if the world
isn't banging on it all of the time.  It produces a very simple page
that at this moment that I capture it looks like this:

  Last updated 2018-02-23 04:14:21 UTC
  bug-wget (1)
  freetype-devel (1)
  gnash-dev (2)
  qemu-devel (1)
  savannah-hackers (1)
  summer-of-code (1)
  debbugs-submit

Where each of those names are links off to Mailman's moderator page.
Here is the first one.

  https://lists.gnu.org/mailman/admindb/bug-wget

And as you know each of those needs a password to gain access.  That
is where the security resides.  And it was apparently back in 2014
when https became supported and we switched over to it.  Hopefully not
possible to sniff out passwords since then.  But in any case that is
what we routinely scan through in order to see what mailing lists have
messages held waiting for approval or discard.

Also we only discard spam and not reject.  Reject sends a rejection
and most of the time that is to a forged address.  When that is an
innocent victim of from line forgery, as most spam is these days, then
that innocent becomes a victim.  If they complain then lists.gnu.org
gets put onto a DNSBL for being a backscatter spammer.

If the message is from a human though and does need to be blocked and
rejected then I will reject it sending back a message to them.  But I
will change the "Reason" message to say something nice about why and
give help as to what they should be doing instead.  Although if it is
a group reply to an announce list I usually just discard it silently.
Because it is too much for people to keep track of otherwise.

> I'm not on a witch hunt, just trying to lessen the chances next
> time.  :-)

I know.  There is machinery working behind the curtain and you want to
know what is behind that curtan.  That's fine.  I am like that too.  I
am just telling you what I know and that is only a pitiful amount of
knowledge at this time.  Sorry.

I'll send a note around to the listhelpers to make sure they are aware
of the problem.  Other than that I don't know what to suggest.  Watch
and wait and keep an eye on things.  That is all I can really suggest.

Bob