[Mailman-Users] List not archiving, not sending mail, mischief log shows 'Hostile listname: <list>"
billc_lists at greenbuilder.com
Mon May 18 07:14:43 CEST 2015
On Sun, May 17, 2015 at 6:26 PM, Mark Sapiro <mark at msapiro.net> wrote:
> On 05/17/2015 01:58 PM, Bill Christensen wrote:
> > I'm using Gmail for all our email addresses, and pulling the mail into
> > Mailman using Fetchmail. It's been working fine for years.
> > One of my more important lists recently started getting this in the
> > Fetchmail console:
> > post script, list not found: <listname>
> > fetchmail: Error writing to MDA: Broken pipe
> > and the Mailman error log says:
> > <date> gate_news(12061): IOError : [Errno 13] Permission denied:
> > '/opt/local/var/mailman/locks/gate_news.lock.<site FQDN>.12061.0'
> This is probably not related. Do you even have any lists with
> Mail<->News gateways -> gateway_to_mail = Yes?.
> Mailman's cron/gate_news runs by default every five minutes and does use
> this lock to prevent concurrent updates. I would also expect to see
> entries like 'Could not acquire gate_news lock' in the fromusenet log.
No news gateways.
> 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.
> > <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.
> > In the smtp-failure log I'm seeing
> > Message size exceeds fixed limit
> > In General Options => Maximum length in kilobytes (KB) of a message body.
> > Use 0 for no limit. I have '0'.
> These two things are unrelated. The message in smtp-failure says Mailman
> attempted to send a message which was larger than the MTA would accept.
> In Postfix for example, this is the main.cf parameter message_size_limit.
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.
> > I've run the check permissions script ( with -f), it changes nothing. It
> > appears that there are 5 messages waiting for delivery, though I don't
> > them in any of the queues.
> If Mailman is retrying the smtp-failure, the message would be in
> Mailman's 'retry' queue until Mailman eventually gives up. Or, they
> could be still in the gmail inbox since fetchmail probably wouldn't
> delete them as it couldn't deliver them.
Yes, there are still 5 messages waiting in Gmail. Fetchmail apparently
hasn't marked them as read as it can't put them anywhere.
> > This appears to have started around the time that I upgraded from Mailman
> > 2.1.17 (or so) to 2.1.20
> > That list is also not archiving properly, so it clearly has problems
> The listname problem would mess up a lot, but it looks like there would
> be nothing to archive since nothing for that list is getting posted.
> > All the other lists on the server are working fine as far as I can tell.
> > Any ideas as to what's wrong?
> First, what's the list name? Once you fix that issue, that may be all,
> or there may be shunted messages in Mailman's shunt queue to be unshunted.
As far as I can tell, the list name is correct. I checked
and ran sudo newaliases
it was lower case in a few places, so I changed those to upper case to
match, just in case.
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.
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
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.
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.
More information about the Mailman-Users