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

[Ken Manheimer]

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/>. #