Two items that I noticed in Deliverer.py:
- it writes to stderr, rather than logging
- the writes do not have a final newline
Cheers, -g
-- Greg Stein, http://www.lyra.org/
"GS" == Greg Stein gstein@lyra.org writes:
GS> Two items that I noticed in Deliverer.py:
| 1) it writes to stderr, rather than logging
| 2) the writes do not have a final newline
Thanks Greg. Both of these are easily fixed by calling self.LogMsg() instead of sys.stderr.write().
-Barry
On Thu, Dec 17, 1998 at 03:31:14PM -0800, Greg Stein wrote:
Two items that I noticed in Deliverer.py:
- it writes to stderr, rather than logging
This reminds me to the feeling when I first met mailman, when I thought: uhh, this program cannot log anything. I don't see what happens. There is some logfiles, but apart from the error log (which doesn't help always so well :)) there is no useful logfile. Is there a log for all processed messages for example? Especially the subscribe and confirmation messages? The bounces mailman processes, and other non-fatal errors?
Maybe there is a possibility to have debug log but I didn't find it. It was especially sad when I put a larger list to mailman and found out that LOTS of mail did not get delivered, and there were NO sign anywhere in the logs that
- delivery did not happen
- why it did not happen.
The other question is the reason why it didnt: it was because mailman wanted to send a mail with a very long CC list, and because security reasons the CC's were maxed at 15, so delivery failed with 5xx error somewhere in the middle and mail got silently lost. Is there any settings to set how many CC's mailman will use at most? At least it should later be documented somewhere that mailman requires such limitations lifted.
best regards, grin
"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. The error logging ought to be very helpful if you're trying to track down a Mailman bug (but there are none any of *those* right?! :-). I'm sure there's more we could log though.
PG> Maybe there is a possibility to have debug log but I didn't
PG> find it. It was especially sad when I put a larger list to
PG> mailman and found out that LOTS of mail did not get delivered,
PG> and there were NO sign anywhere in the logs that 1) delivery
PG> did not happen 2) why it did not happen.
You don't say what version of Mailman you're using. There are a couple of places that bugs can happen to prevent message delivery. If it happens in the mail wrapper binary (e.g. you got your mail-gid wrong), you'll need to enable syslog to catch those, since they don't make it to Python yet. If the error happens within the Python part of Mailman, you should see those in the error log. Same with CGI.
The error logs (for CGI) should be quite complete; they should contain the Python traceback pointing you right to the source line that crapped out, along with a dump of the environment variables the CGI script saw.
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. 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.
Hope that helps, -Barry
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.
The error logging ought to be very helpful if you're trying to track down a Mailman bug (but there are none any of *those* right?! :-).
Hehe, don't tell me, I'm that guy with the exim and the questions about permissions nobody was able to answer, as well as error messages being unfamiliar to anyone. :-)
PG> Maybe there is a possibility to have debug log but I didn't PG> find it. It was especially sad when I put a larger list to PG> mailman and found out that LOTS of mail did not get delivered, PG> and there were NO sign anywhere in the logs that 1) delivery PG> did not happen 2) why it did not happen.You don't say what version of Mailman you're using. There are a
Sorry, trying to be at the lastest released, this time 1.0b6.
I realized that I had a new logfile, namely smtp-failures. :-) It shows at least the error message caused the delivery to fail. Nice.
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.
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)...
thank you, grin
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/>. #
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
participants (4)
-
Barry A. Warsaw -
Greg Stein -
Ken Manheimer -
Peter Gervai