mailman list - I don't fully grok why, but ... with the Debian install of mailman, it instructs one to create a list named mailman, which I dutifully did so. I'm guestimating removing such a list may be a *bad idea* - so I've no intention of doing so unless I knew quite certainly there was no specific downside on that (including even any specific ways Debian might happen to use such list). However, seems a bit odd - and potentially problematic(/annoying) to have it shown among the "advertised" lists, so, I changed the setting on that list to: Advertise this list when people ask what lists are on this machine? No That prevents it from showing in: https://temp.balug.org/cgi-bin/mailman/listinfo I also changed setting to: What steps are required for subscription? Confirm and approve Thinkin' folks really ought not be subscribed to that list, and adding approval requirement may help prevent unintended subscriptions to that list. I'm guestimating primary reason such list is created, is to have standard localpart addresses that can be used for mailman requests, e.g. user can send an email with body of: help to: mailman-request@ and get the basic help information, they could also send the command: lists and they would get a listing of - I presume - the "advertised" lists (help text says "public mailing lists" - I'm presuming synonymous descriptors). So ... I suppose folks (and admins) might expect the various mailman-{request,admin,...} email addresses to exit. As for mailman@ itself? Default behavior would be to post to the list - that might not be so useful - but might also satisfy the rule of least astonishment (even if it doesn't successfully post - e.g. sender not subscribed). Could maybe just have that be alias to go to list / (mailman) site admins, but that may be more work/annoyance for the admins than optimal, and may also violate rule of least astonishment.
blank body (with command(s) in Subject: header) This one isn't so trivial to "fix" for mailman, while leaving the appropriate bits in place for the generally desired anti-spam. I'm leaning towards deprioritizing fixing that, and just giving suitable information about putting command(s) in email body - could put that in the information going out, web page(s) as relevant, and tweak (add to) the mailman text it sends, so that's reasonably clear. As for attempting proper fix on that ... in eximconfig, there's rule that rejects empty body. It even has a part to allow if a recipient address includes (case insensitive) the string unsubscribe. I did even adjust that to match other mailman list addresses (but not list posting address) ... that "worked" - for certain definitions of worked - made it past that rule okay, but alas, then immediately failed on a similar subsequent rule that has no provisions in it for exception by recipient (it's in collection of general body reject rules). The latter rule, effectively saying, after we strip out images and the like, if our net resultant body is empty/blank, reject it (e.g. it's likely image spam). So ... sounds in general like a good rule to have and keep ... but ... to selectively allow exception, adding that, not so trivial (I do grok regular expressions ... but alas, not python yet). Actually, ideally, for list addresses that would generally take commands, if body is blank (or blank after stripping images and such), if Subject: header is also empty - still ought reject it as spam - but allow it if the Subject: header isn't empty. Anyway, I'm inclined to mostly deprioritize a more proper fix of that (hopefully come back to it later), and move along with other relevant bits (which are generally coming along quite nicely).