On Oct 26, 2017, at 17:21, Dmitry Makovey <dmakovey@stanford.edu> wrote:
we are trying to figure out what is that we're doing wrong as we can't use instructions that mailman sends with information on held messages as referenced in: https://gitlab.com/mailman/mailman/blob/master/src/mailman/chains/hold.py#L2...
In particular - replying to the message with "Approved: listpassword" we were not able to approve any message.
I’m pretty sure you’re not doing anything wrong, it just doesn’t work.
There are two use cases for Approved: header. The first is that the list admin can send a pre-approved message to the mailing list, which bypasses all rule checks except for dmarc-mitigation and no-senders. At least, that’s what happens with the default, built-in chain. But that’s not what you’re talking about here.
The second use case is where you reply to the subpart with the ‘confirm <token>’ Subject. This should go to the -confirm@ or -requests@ subaddress (both of which are processed by the command runner). As that bit of text says, the held message should be discarded if there’s no matching Approved: header (in the first non-blank line of the message body, or in a header). The held message will be accepted if it has a matching Approved: header.
The problem is that the current implementation of the ‘confirm’ command doesn’t distinguish the operation based on the “pend key” of the record matching the token. Meaning, those tokens are used to represent held messages *and* held subscriptions, and the ‘confirm’ command only routes its message to the subscription handler.
So I’d say this is a bug in the ‘confirm’ command handler.
-Barry