On Sat, 19 Dec 1998, Peter Gervai wrote:
Barry,
On Sat, Dec 19, 1998 at 12:21:34AM -0500, Barry A. Warsaw wrote:
> "PG" == Peter Gervai <grin@tolna.net> writes:
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 PG> what happens. There is some logfiles, but apart from the error PG> log (which doesn't help always so well :)) there is no useful PG> logfile. Is there a log for all processed messages for PG> example? Especially the subscribe and confirmation messages? PG> The bounces mailman processes, and other non-fatal errors?Lots of stuff should be getting logged, but I can't remember what's in 1.0b6 (Ken?). You should see every post getting logged, subscribes/unsubscribes, digests, and of course errors.
No, definitely I completely miss the logfile showing the posts. Subscribes/unsubs get logged as well as errors, though error log a bit hard to use because it doesn't show the variables failed.
Logging of posts is in the "frontier" (CVS repository) version, soon to be released as 1.0b7. (It was added by scott cotton, not too long after 1.0b6 was released.)
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"), 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!)
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 actually is something that is improving in Python (due to some recent work by barry!), and in general i expect the situation to progressively improve. (I've added to the todo list that error messages should say more about failed file, maillist, etc identities.)
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 PG> because security reasons the CC's were maxed at 15, so PG> delivery failed with 5xx error somewhere in the middle and PG> mail got silently lost. Is there any settings to set how many PG> CC's mailman will use at most? At least it should later be PG> documented somewhere that mailman requires such limitations PG> lifted.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.
That said, once again the frontier version has a fix for your particular problem (once again, from scott cotton). It's in the form of a new parameter, SMTP_MAX_RCPTS, which constrains the size of the groups into which destinations are batched for delivery. You should be able to set that to 10, or whatever, and prevent your MTA from getting passed batches larger than 10. This will probably reduce the speed of the delivery process, but that sounds like a tradeoff that your site has elected for, in general.
BTW, if this is really why the messages are not being delivered, they probably aren't just lost. They get held for administrative approval for a period of time. Check the pending messages for the list.
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...
Ken Manheimer klm@python.org 703 620-8990 x268 (orporation for National Research |nitiatives
# If you appreciate Python, consider joining the PSA! #
# <http://www.python.org/psa/>. #