D. Hugh Redelmeier via Talk wrote on 2026-02-24 12:12:
This message had to be manually approved. MailMan blocked it because "Message contains administrivia". Odd.
I don't see anything in that message that should trigger such a thing. I even sent a good portion of it to the test list and it wasn't rejected. "Odd" indeed. Oh, a second test with full message to test *did* trigger Administrivia warning. After a dozen+ test messages against test@lists.gtalug.org, I've narrowed it down! It's from this block as *only* these lines fail delivery: set smtp_url = "smtp://myname@example.com@submit.mailserver.com:587/" set smtp_pass="password" set smtp_authenticators = "login" set ssl_force_tls = yes Sending just this line *does* get delivered: set smtp_pass="password" It is *this* line that offends the Almighty Filter: set smtp_url = "smtp://myname@example.com@submit.mailserver.com:587/" Sending that alone triggers the filter. Administrivia <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs/administrivia.html#administrivia> The administrivia rule matches when the message contains some common email commands in the |Subject:| header or first few lines of the payload. This is used to catch messages posted to the list which should have been sent to the |-request| robot address. It's too bad the Mailman3 documentation on testing Administrivia does not work as indicated: docs.mailman3.org Administrivia — GNU Mailman 3.3.11b1 documentation <#> 🔗 https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs/... <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs/administrivia.html> Haven't verified versions, but the Python code exploded when I attempted it.