[Mailman-Users] Counting messages that went to postfix queue

[D G Teed]

On 5/2/07, Brad Knowles <brad at shub-internet.org> wrote:
>
> On 5/2/07, D G Teed wrote:
>
> >  I didn't trust that findsender.pl actually parses postfix logs 100% so
> >  I verified with plain grep for any mention of the user addresses in
> >  /var/log/maillog or
> >  /var/log/mailman/*    I found one reference of the 28 which
> >  findsender.pl missed.
> >  This list has 1890 members, and 27 are not showing up at all in postfix
> >  logs.
>
> Keep in mind that some of those users may have set themselves (or
> been set) to "NOMAIL" status, or they may be digest subscribers.  In
> either of those cases, they would not be found in the list of normal
> recipients.


This is a pilot server.  I subscribed all users to the list myself
with no welcome message - only minutes before the message
was delivered.  It is a one way list.

You have to look to make sure you know how many "normal" subscribers you
> have.
>
> >  Unless postfix has a bug where some emails are not being logged, there
> >  seems to be a problem with mailman.  I'm not looking for delivery -
> just
> >  any reference to the expected attempts to deliver.
>
> If you found a bug, I think it's much more likely that it exists
> within Mailman or the Python libraries or Python itself than postfix.
> Or you could have found a bug in syslog, where postfix sent the data
> to be logged, but syslog didn't actually write it to the file.


It seems like mailman is the most likely point of failure.  There was a
python error
in the error log file for mailman.  Unless we are taking about versions of
python.
I'm running 2.3.4 for that (Redhat EL 4).

>  There are no errors like it in our previous months of using mailman
> >  on other smaller departmental mailing lists.  The mailman smtp log does
> >  not show the entry for the 1800 something messages which were delivered
> OK.
>
> That's weird.  You should definitely see Mailman smtp log entries for
> the other messages which were delivered.


Unless the python bomb out happened prior to logging the smtp info.

>  My hunch, is that there is some bad data in our mailing list subscription
> >  which wasn't caught anywhere and has created this issue.  We are given
> >  data from the Alumni Affairs department to inject into the mailing
> list.
> >  It may contain odd things.  I've seen a '#' and single quote appear in
> >  the mail subscriptions.
>
> That's possible.  I think you can use dumpdb to take a look at the
> list of subscribers, to see if there's anything funky there.


dumpdb shows the email case with the single quote wrapped with
double quotes, unlike the regular ones.  I've verifyed the list
prior to import to mailman, with Mail::VRFY and only found
2 bogus format email addresses.  One had the quote, and the
other had a bad top level domain.  Not 26 problems.

However, given that you've not had problems before and are now having
> problems, tells me that either this is a result of a new addition to
> the list, or that maybe there was a problem with the way that
> particular message was formatted.
>
>
> Remind me again -- what version of Mailman are you using?


I'm on 2.1.5.  I have the patch to allow subscribers in one list
to be added to posting ability in another list by simply adding
the @listname to the allowed set.  Hopefully that still works
in 2.1.9.

  If you're
> not already on 2.1.9, you might want to consider making that upgrade,
> because I know that the more recent code has gotten more robust in
> the face of weirdness on input, and continuing to operate as close to
> normal as possible even though there may be some messages which don't
> go through.


I'll take a look.

--Donald