[Mailman-Developers] Logging automatic rejects of incoming posts.

[Barry Warsaw]

On Oct 19, 2012, at 05:26 PM, Mark Sapiro wrote:

>When a handler raises Errors.RejectMessage to reject an incoming post,
>nothing is logged. I have filed
><https://bugs.launchpad.net/mailman/+bug/1068837> in preparation for
>addressing this.
>
>My question is what to log.

I'm not sure MM3 is any beacon of clarity here.  For all intents and purposes,
it just logs the Message-Id (if available) into the mailman.vette logger.

        bounce_message(mlist, msg)
        log.info('REJECT: %s', msg.get('message-id', 'n/a'))
        notify(RejectEvent(mlist, msg, msgdata, self))

One thing MM3 does also though is to send a RejectEvent with the mailing
lisst, message, and metadata so listeners could use that to do more logging or
whatever.

>Currently, IncomingRunner logs automatic discards with the message 'Message
>discarded, msgid: %s'. This is a bit cryptic. I think it would be good to
>have the list name in this message, but I have never changed it as that could
>be disruptive. It would also be possible to log which handler raised the
>exception, but again, that could be disruptive.
>
>With a new message for rejects, disruption is not much of an issue as
>existing log analyzers would presumably not recognize the message and skip
>it, which is no different from no message, or report the raw message.

Putting the mailing list in there is a great idea.  (If you do this, maybe
you'd like to work up a similar patch for MM3? :).

>The question is whether it is a good thing to log the error message
>that accompanies the exception. This can be quite verbose as the error
>message can be the list's member_moderation_notice or
>nonmember_rejection_notice, but if only the handler name is logged, it
>doesn't distinguish between a non-member reject and a moderated member
>reject.

Logging the reason for the rejection is probably a good idea.  I'd like to do
the same in MM3, but currently that information doesn't make it through to the
reject chain.  The way to do that is probably add some additional metadata
containing the reason, and plumb that through to the actual bounce code, and
the logger.

Cheers,
-Barry