Andy Matthews writes:
I've found some libraries which can parse the message property and extract the relevant bits, but I'd rather pass some sort of flag or filter to the initial Mailman 3 API call and get back less information.
Before I express my opinion, note that I am not authoritative on this, but I have a decent record on channeling the consensus. So YMMV FWIW
I'd be against putting such a thing into the core without a lot of beta testing, I think. I imagine there would be various opinions on how much less and which data should come back.
There is a plugin architecture which specifically can be used to implement REST routes: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/plugins/doc... While doing it this way undoubtedly makes it more complicated for the initial implementer, I think it would be a lot simpler (more self-contained) for people who want to implement different filters, etc.
I've looked through the documentation but I'm not finding anything of the sort.
I don't think there is for this, although there's a certain amount of code for filtering the messages that are being processed (stripping attachments of specified MIME types, converting text/html to text/plain, etc). I'm not sure if that's done in advance of holding for moderation. So maybe it would be OK to repurpose that code to your end (though I'd want it to be a proper refactoring, not cargo culting the post distribution filter into the moderation code), and somebody would need to do the same for Postorius. Not necessarily you (I infer you're talking about a separate application that talks to Mailman core for moderation), but availability to Postorius users with common administrative UI would make it a lot more attractive to us.