[Mailman-Users] List not archiving, not sending mail, mischief log shows 'Hostile listname: <list>"

[Mark Sapiro]

On 05/17/2015 10:14 PM, Bill Christensen wrote:
> On Sun, May 17, 2015 at 6:26 PM, Mark Sapiro <mark at msapiro.net> wrote:
> 

>> If this is a one-time occurrence, It was just a glitch. Maybe someone
>> manually ran cron/gate_news as a user not in Mailman's group. If you get
>> these every 5 minutes, there is a permissions issue, probably with the
>> user running this cron not being mailman, because if the locks directory
>> were not group mailman and group writable, lots more would be broken.
>>
> 
> Yes, definitely every 5 minutes.


There is a permissions issue on the locks directory. If you do

ls -la /opt/local/var/mailman/locks/

you should see something similar to

drwxrwsr-x 2 root    mailman 4096 May 18 20:11 .
drwxrwsr-x 9 root    mailman 4096 May 10  2008 ..
-rw-rw-r-- 2 mailman mailman   62 May 19  2015 master-qrunner
-rw-rw-r-- 2 mailman mailman   62 May 19  2015 master-qrunner.host.pid

There may or may not be other files, but the two master-qrunner files
should be there and everything should be mailman's group (owner is not
important) and both . and .. should have permissions as shown.

If all this is correct, then either cron/gate_news is not running as the
Mailman user (where is its crontab and what's in it?) or there may be
some SELinux, apparmor or other security policy issue.



>>>     <date> post(12068): post script, list not found: <listname>
>>
>> The post script invoked by
>>
>>  /path/to/mailman/mail/mailman post <listname>
>>
>> in your fetchmail script says <listname> doesn't exist.
>>
>>> Mailman mischief log says:
>>>
>>>       Hostile listname: <listname>
>>
>> This is consistent with the 'post script' report and says that
>> <listname> contains one or more characters not in the
>> Defaults.py/mm_cfg.py setting ACCEPTABLE_LISTNAME_CHARACTERS. The
>> default setting only allows letters, digits, '-', '+', '_', '.' and '='.
>>
>> Does <listname> contain characters outside this set or whatever set
>> you've specified?
>>
> 
> Nope, it's four uppercase letters.  No spaces, no punctuation.


List names are always all lower-case. The list may have a real_name
attribute which is mixed case but it must differ only in case from the
list's internal name.

The name in the pipe to 'mailman/mail/mailman post <listname>' command
MUST be all lower case.


> I checked the messages waiting in Gmail.  They're all small enough, no
> worrisome attachments or anything.  I tried marking the oldest as read just
> in case it was jamming up the works, but the others are still in a logjam.


Because fetchmail can't deliver to the list until you fix the listname
you pass to the 'mailman' wrapper if that's the issue.


> Yes, there are still 5 messages waiting in Gmail. Fetchmail apparently
> hasn't marked them as read as it can't put them anywhere.


Yes.



> As far as I can tell, the list name is correct.  I checked
> 
> bin/list_lists
> 
>  /etc/aliases
>  /etc/postfix/virtual
>  /etc/fetchmailrc
> and ran sudo newaliases
> 
> it was lower case in a few places, so I changed those to upper case to
> match, just in case.


That was the reverse of what you should have done. Hopefilly, the name
of the list's directory in the /opt/local/var/mailman/lists/ directory
is all lower case.

It must also be all lower case in fetchmailrc and in the commands in
/etc/aliases.

I.e. an alias could be

LISTNAME: '|/path/to/mailman/mail/mailman post listname'
LISTNAME-admin: '|/path/to/mailman/mail/mailman admin listname'

But it should match /etc/postfix/virtual, but it's best if it's all
lower case.

But then if fetchmail is delivering directly to
/path/to/mailman/mail/mailman, none of the postfix stuff matters as it
isn't used.


> then stopped/started Mailman.  No change.
> 
> I decided to take a chance and used your clone_list script to make a copy,
> moved the original archives to a backup location, then removed the original
> list and cloned back from the copy to the original name.
> 
> Ran check_perms -f and checked them manually as well.  All looks correct.
> 
> And yet, it's still throwing the same errors.
> 
> One improvement - after correcting permissions manually on
> <listname>.mbox/<listname>.mbox I can get to the archives again.  They were
>    -rw-rw-r--  1 root  staff
> and I set them to
>    -rwxrwxr-x  1 root  staff
> to match other working lists with public archives.

It's a file. +x is not necessary on files.
archives/private/<listname>.mbox should be drwxrwsr-x (note the SETGID),
but no x of the file is needed (it's not executable). And I hope
<listname> is all lower case.

Also, it appears that Mailman's group is 'staff', not 'mailman' so
everywhere I refer to it as 'mailman', read 'staff'

> 
> Then I looked at mailman/lists/.  The list in question was owned by my
> user, not root like the rest of them (possibly a result of clone list?  the
> only two with that user were this list and the clone I had made earlier).
> Changed that to match the rest.
> 
> Ownership of the enclosed files has me confused.  All have the following
> files
> 
> config.pck
> 
> config.pck.last
> 
> pending.pck
> 
> request.pck
> 
> some lists have some files with owner = _www, other files with owner =
> _mailman and still others lists have files with owner = my user .  They're
> not consistent and I'm not really sure what they're all supposed to be, so
> I'd appreciate it if you'd enlighten me.


It doesn't matter. It is only the group that's important. The owner will
reflect the user/process that created it, but in Mailman all the
directories are SETGID and thus, things are created with the group of
the containing directory, and permissions are by group. There are a
couple of places where owner might matter. These are the owner of the
aliases.db file with mailman's aliases and the owner of the
archives/private/ directory itself if that directory is not o+x, but
everywhere else, owner doesn't matter.

But if _mailman is an owner, that says to me FreeBSD or maybe Darwin,
and I would have thought Mailman's group would also be _mailman, not staff.


> Some also have 'en' directories, and I'm similarly unsure of what the
> correct owners are for those and their enclosed files - but I'm pretty sure
> they're probably not supposed to be my user.


The en/ directories contain list specific templates, and again, the
owner doesn't matter as long as everything is in Mailman's group.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan