[Mailman-Developers] Even more on that log weirdie...

[Barry A. Warsaw]

>>>>> "CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:

    CVR> why is mailman sending the unsub to -request here? and
    CVR> throwing it out?

Oh this is twisted!  Note that this only happens when you have
admin_notify_mchanges enabled.

So, when you remove the address, the user gets a notification, which
is all well and good.  Also, the list-owner gets a notification
because of admin_notify_mchanges.  But note that this particular
message is sent to "listname-owner@dom.ain" -- so it gets to the
owners indirectly, not by using the owners explicitly as the
recipients of the message.

So, Mailman happily sends out the list-owner message, which your mta
dutifully returns to Mailman's incoming queue.  Now this message
correctly has a Precendence: bulk header on it, and Mailman now goes
through the normal processing for an -owner addressed message.  At
this point it has no idea it generated the message internally and fed
it back to itself via a loop through the MTA.

Now the logs/vette message is coming from Replybot.py and it's
actually both lying and misleading <wink>.  It's lying about the
"ignored by" address -- it just says the -request address no matter
where the message came from.  It's also misleading because although
the log message ways "Precedence: bulk message ignored by:" the only
thing that really happens is that the replybot won't auto-reply to the
message.  All the other normal processing of the message occurs, so
eventually it ends in the outgoing queue and sent on to the list
owners.

Fneh.  Two fixes are in order i believe.  1) admin_notify_mchanges
should use the owners addresses explicitly in the recipients list so
you don't need a roundtrip through the mta to get this message
delivered, and 2) the logs/vette message needs to be improved.

Thanks for the reproducible recipe Chuq.  I'll work out a fix and
check it in before I head to sleep.

-Barry