On May 24, 2011, at 03:11 PM, C Nulk wrote:
I don't know if this is the place to mention it but along with increased accessibility to statistics and archives, the ability to look at or review the logging information is also very important. Anywhere in the code that output's to a log file should provide enough information to follow a message coming into Mailman, through the various Mailman processes, and out of Mailman.
It is, and I agree! Well, let me say that I definitely think better logging is on the table for MM3, and I've been careful to ensure that at least the Message-ID is logged for anything that pertains to the disposition of an email message. I'm not sure how or if the logging information should be available through the web ui (and thus the REST API).
I went through Mailman v2.1.9 to add additional logging information so I can track a message. My users call on a regular basis to check if their message "went out" to a list they can post to but not read (it gets complicated). Once I had the logging information (message-id, listname, sender, etc.), I wrote a web app that parses the vette, smtp, and post logs and combines the information so I can see what happened to the message either by list or by sender. It works well for me but additional logging information for tracking messages and problems is also need.
One other thing I've been thinking about is a kind of "debug" option where a fake message could be injected into the system, with the appropriate headers, and out would come some debugging information about which rules got hit, and exactly why a message would be held, accepted, discarded, or rejected. I haven't thought more about this other than "it would be cool to have" ;).
-Barry