Moderating posts via email
Hi,
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.
Since there's no place we could find in interface to change ML password I did it through the mailmanclient:
ml=client.get_list('mylists@lists.some.com') ml.settings['moderator_password']='password123' ml.settings.save()
after which we've used above password trying to approve messages following the steps outlined above.
What are we doing wrong, or where to look for further information?
-- Sr System and DevOps Engineer SoM IRT
On Thu, Oct 26, 2017, at 02:21 PM, Dmitry Makovey wrote:
Hi,
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.
Did you add it to the body/subject of the email?
AFAIK, Mailman looks for "Approed" header to approve the held messages.
Since there's no place we could find in interface to change ML password I did it through the mailmanclient:
ml=client.get_list('mylists@lists.some.com') ml.settings['moderator_password']='password123' ml.settings.save()
after which we've used above password trying to approve messages following the steps outlined above.
What are we doing wrong, or where to look for further information?
-- Sr System and DevOps Engineer SoM IRT
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Email had 1 attachment:
- signature.asc 1k (application/pgp-signature)
-- Abhilash Raj maxking@asynchronous.in
On 10/26/2017 02:46 PM, Abhilash Raj wrote:
On Thu, Oct 26, 2017, at 02:21 PM, Dmitry Makovey wrote:
Hi,
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.
Did you add it to the body/subject of the email?
We have added "Approved: listpassword" to the body of the message as a first line as advised.
AFAIK, Mailman looks for "Approed" header to approve the held messages.
We did not try to inject "Approved: listpassword" header into the message body itself though. And if that is the way it is supposed to function I'm questioning whether average user would be able to operate it.
If that function is broken - since message is hardcoded into the chains/hold.py - how can I change the message without code modification?
-- Sr System and DevOps Engineer SoM IRT
On Thu, Oct 26, 2017, at 02:52 PM, Dmitry Makovey wrote:
On 10/26/2017 02:46 PM, Abhilash Raj wrote:
On Thu, Oct 26, 2017, at 02:21 PM, Dmitry Makovey wrote:
Hi,
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.
Did you add it to the body/subject of the email?
We have added "Approved: listpassword" to the body of the message as a first line as advised.
AFAIK, Mailman looks for "Approed" header to approve the held messages.
We did not try to inject "Approved: listpassword" header into the message body itself though. And if that is the way it is supposed to function I'm questioning whether average user would be able to operate it.
I am sorry, it does indeed say that you can add it to the first line of the body.
I haven't tried doing it so I am not sure if it works, maybe someone else can comment on it.
Given how emails are not so good at being secret, I'd not advise using it despite it's current state. Although, if it is a feature, it should work regardless!
-- Abhilash Raj maxking@asynchronous.in
On 10/26/2017 02:59 PM, Abhilash Raj wrote:
Given how emails are not so good at being secret, I'd not advise using it despite it's current state. Although, if it is a feature, it should work regardless!
agreed. but how do I strip that from the message sent to user since instructions are hardcoded into chains/hold.py ?
-- Sr System and DevOps Engineer SoM IRT
On Thu, Oct 26, 2017, at 03:01 PM, Dmitry Makovey wrote:
On 10/26/2017 02:59 PM, Abhilash Raj wrote:
Given how emails are not so good at being secret, I'd not advise using it despite it's current state. Although, if it is a feature, it should work regardless!
agreed. but how do I strip that from the message sent to user since instructions are hardcoded into chains/hold.py ?
I am not sure of any easy way to do without patching the source itself. You can however modify the 'list:admin:action:post' template for the list with instructions to advise against using the "Approved" feature (regarless of what the text below/above says).
I understand that it probably is going to confuse a lot of people, but I am just throwing out ideas to add a band-aid for the bug.
Again, I am not sure this feature if broken, I haven't tested it. It might be worth opening issue in Core though.
-- Sr System and DevOps Engineer SoM IRT
Email had 1 attachment:
- signature.asc 1k (application/pgp-signature)
-- Abhilash Raj maxking@asynchronous.in
On 10/26/2017 02:21 PM, Dmitry Makovey wrote:
after which we've used above password trying to approve messages following the steps outlined above.
What are we doing wrong, or where to look for further information?
Are you replying to the outer message or to the message in the attached message/rfc822 part that contains the
If you reply to this message, keeping the Subject: header intact, ...
text?
You don't actually have to 'reply' to anything, but your message with the 'Approved: password' actual header or first body line must be sent To: the list-request address with Subject: confirm <token> (possibly preceded by 'Re: ' or similar.
If you reply to the attached message/rfc822 message, it should work. If you reply to the outer message it won't work.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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
I should also mention that I think this is a very underutilized feature. Few mail readers are able to reply to a subpart, and of course it still means you have to edit the reply to add the Approved: pseudo-header to the body. Forget that plenty of mail readers don’t let you easily add custom headers per message.
It’s still worth fixing this though because you don’t always have access to the web ui (or it may not exist). It’s just that email is a terrible command UX :)
-Barry
participants (4)
-
Abhilash Raj -
Barry Warsaw -
Dmitry Makovey -
Mark Sapiro