[Mailman-Developers] debug logging, long CC (Deliverer.py)

[Peter Gervai]

Ken,

> > >     PG> This reminds me to the feeling when I first met mailman, when
> > >     PG> I thought: uhh, this program cannot log anything. I don't see
[...]
> I should add that i was surprised to see you say "this program cannot
> log anything".  We don't pretend Mailman is perfect, but it's
> discouraging to hear such low judgements ("no useful logfile"),

Oh, sorry if I sounded like that, it wasn't intentional! I wanted to tell
about when I was young and ingorant to the great aspects of mailman, and
when I first saw it (and the next 397 times when I tried to get it started
in my brainwashed environment) I felt the miss of the detailed logfiles
about what happens.

But of course since I managed it to work fine I don't feel the miss. I
just think others might need them in the startup phase, at least until
the program gets rid of that 'b' from the version number. :-)

I think I state the obvious when mentioning that even I avoid Python
I've fallen in love with mailman as it not only manages lists, but do
it with a royal superiority. :) The UI is very useful, pretty; the bounce
detection is wise, and the admin UI is easy to use. 

Bugreports and (uncalled) complaints always sound a bit disappointing,
maybe I'll try to put some "you know that we love mailman and that's why we
make such bugreports" :) to make you feel it's not because I think it's BAD
but because I want it to be BETTER. Better than best, you see. :)

> particularly about things we're working on improving (and about which
> you seem to be mistaken - we've had logs for both subscribe and bounce
> activity for a while!)

Apologies for not mentioning those logs, but at least I never mentioned
they doesn't exist. :) 

> I agree that it would be nice to be able to glean more about the
> specific coding errors from the error log - but we're mostly dealing
> with the limits of the resolution of Python tracebacks, here.  This

I don't know Python that deep enough, I just suspected that being an
interpreted language it could evaluate the line in question so find
variables in the line in question and tell their values... Maybe this
only shows my lack of Pythonness. :)

> > >     PG> The other question is the reason why it didnt: it was because
> > >     PG> mailman wanted to send a mail with a very long CC list, and
[...]
> > > Look in the Privacy Options.  There's an option that says "Ceiling on
> > > acceptable number of recipients for a posting".  This defaults to 10.
> > 
> > It's been 10 by default. Doesn't seem to matter at all.
> 
> There is a serious architectural obstacle for delivery failures that
> occur for destinations on the local system - because the MTA doesn't
> generate any bounce messages in that case.  This is something that
> should be corrected in our smtplib (i'm not sure whether the interface
> in the standard python smtplib addresses the problem, either), but at
> least the smtp-failures log file should register the problem.

Unfortunately that was quite hard to spot... If I weren't in the batch
disappearing I'd never see there was a problem at all.

> > Of course I regularly check the waiting messages as I'm the owner as well
> > but there were none waiting, obviosuly. The message got delivered to the
> > small batch (outside users, 3 cc) and lost for the big one (local
> > users, 20-50 cc)...
> 
> I'm really suspecting you're not talking about addresses in the CC
> headers, but rather groups into which deliveries for the list were
> batched.  Sorry if i'm mistaken - if i am, we'll need more info to
> determine why the size-of-cc-option is failing for you...

I can't really tell you whether it's CC or multiple RCPT TO: fields
since I don't have the logfile :-)) But I'm confident that the error
was caused by having a limit on the number of recipients a single
mail can contain, no matter the method. (Posted mail did not contain
any cc at all, if that was your question.)

To mailman limited numbers of CC could mean a tradeoff (more batches) but
efficiently stops ignorant users from creating mass-mailings. In these 
times we live in this do matter.

bye,
grin