Quoting spiralofhope (spiralofhope@???):

> Thank you for the lesson. It all, and I think the above in particular,
> is just the thing I needed to learn to approach the admins of the list
> I've had such problems with.

It may also be helpful to know that Mailman listadmins in _many_ (most?
wouldn't know for sure) cases have been granted and know how to
effectively use the Mailman admin WebUI for their supervision of the
mailing list but lack access to the server shell, hence their (typical)
inability to read/research Mailman's and the MTA's log entries.

Also, as a personal observation about my administration of both my own
(linuxmafia.com) host + mailing lists and those of several LUGs,
although (to date) I've always been willing to spend time investigating
subscribers' claims that the mailing list server is losing/refusing
their mail, it's inevitably a significant time sink -- and the
diagnostic information provided by the user tends to be vague and
unreliable.

Which, in turn, is in part because a high percentage of those users lack
diagnostic information, e.g., I'll ask such a user what the user's
outbound MTA logs show about the delivery attempts, and the user has no
idea whatsoever, because the user has no access to that data. So,
instead, the user _claims_ there were outbound delivery attempts, but is
actually just guessing and really knows only that he/she composed mail
and handed it off to outbound system software at timestamp X.

I can't tell you how many times such a user swore up and down that there
was an outbound MTA delivery attempt, I report finding no evidence in my
receiving MTA logs, and then days later the user admits that 'Well,
actually, I was merely assuming outbound delivery attempts.'

So, what I'm saying is: If you're going to chew up the time and effort
of a volunteer listadmin, be aware of the limits of your knowledge
(especially if you are neither root on your outbound MTA box nor even
have shell on it), and provide the most-exact information you have,