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