Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
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 actually was meaning to talk to you about this matter. You'll notice http://linuxmafia.com/mailman/listinfo and http://lists.svlug.org/lists/listinfo
both have mailing list 'Mailman' set as 'Advertise this list when people ask what lists are on this machine?' = no. I don't think there's actually any functionality advantage to requiring listadmin approval, because nobody can actually do anything as a member of that list. The downside of your setting 'Confirm and approve', there, is that _if_ some numbnuts attempts to subscribe, that request will land in the admin queue, and you and I will continue to be pestered about whether to approve it or not. Unlike held _mail_, held subscribe requests never expire out of queue: There is no 'discard held subscribe requests after N days' configuration item.
So, I really do think setting 'Confirm and approve' on mailing list Mailman is an actively bad idea, and think you should revert that.
You're certainly right that any _advertised_ Mailman list will get subscriptions, no matter how nonsensical that idea is for a particular mailing list. Consider, for example http://lists.svlug.org/lists/listinfo/speakers . As it says on the listinfo page, that is an explicitly read-only archive of a _formerly_ active mailing list, so it's flat crazy to try to subscribe to it.
Some background:
There was a period around 2005 when J. Paul Reed was SVLUG President and Bill Ward was VP. They'd gotten the catastrophically bad advice that they should distrust all of the active volunteers, which is pretty much the way they conducted themselves after election. One day (March 28, 2005), I was astonished to find that the mailing lists Web-Team, Speakers, and one other whose name eludes me (I think it was lsec, a mailing list about Linux security), all of the working mailing lists of the volunteer teams, had been summarily deleted without discussion including (apparently) all back-postings archives going back five years.
In place of the three team working mailing lists, a new one, privately archived and requiring permission of Reed or Ward to join, got created called 'Volunteers'. Inquiring with them about what was going on revealed that they wanted to 'put everyone working on anything SVLUG-related together' (Reed's phrase), so they decided to blow away all of the existing forums and create the new hyper-controlled private one to take their place.
As head of the Web Team, I asked to please get a copy of the Web-team mailing list archive, as it had material I needed. It quickly became apparent that Ward had no idea how to retrieve it: He had no knowledge of Mailman, but had just blowed away the mailing list configurations using the admin WebUI's delete control. I figured out how to get the cumulative archive, on my own (and for some years hosted it publicly on linuxmafia.com's Mailman instance).
During Reed and Ward's administration, nobody but them had the right to do essentially any work on the mailing list server. Shortly after they left office, I converted Volunteers to a public mailing list open to all subscribers, and resurrected Web-team and Speakers (undoing most of the damage Ward had done). Speakers seemed unlikely to have future traffic because there was no longer a Speaker Coordinator, but some of its content seemed useful, so I edited http://lists.svlug.org/lists/listinfo/speakers so it no longer had a Web form to join the list.
(I _do_ have that vestigial mailing list with 'What steps are required for subscription?' set to 'Require approval', just in case some numbnuts tried to join it via the e-mail command interface. Nobody has tried.)
I'm guestimating primary reason such list is created, is to have standard localpart addresses that can be used for mailman requests,
http://www.gnu.org/software/mailman/mailman-install/site-list.html says:
[The site-wide mailing list, by default named 'Mailman'] is the one that password reminders will appear to come from, and it is required for proper Mailman operation.
Anyway, every GNU Mailman installation has one.
(To repeat, I concur about making it unadvertised.)
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.
If I read correctly what you say further on, it's actually some set of overly paranoid Eximconfig rules that are preventing this mail, not Mailman. I might be able to help with this later, if you like, but I suspect your detective skills on this one are at least as good as mine if not better.
Speaking of Eximconfig, here's mail I sent to the author, detailing a fix that I'm pretty sure you will also want to make:
Date: Wed, 30 Nov 2005 22:55:15 -0800
From rick@linuxmafia.com Wed Nov 30 22: 5:15 2005
From: Rick Moen rick@linuxmafia.com To: Jonathan Boggis Subject: Re: Mailing list posts, and EximConfig
Hi, Jonathan. Responding to your mail from last February:
Quoting Jonathan Boggis:
Thanks for your comments.
The problem is with SPF and forgery checks being performed on the header From: address. These help reject the forgeries generated by spammers and viruses, but have the downside of potentially blocking messages sent via mailing lists.
The easiest way to address this in the short term is simply to whitelist the mailing list's domain in accept/sender_domain (I.e: Add lists.svlug.org to this.) This will prevent the SPF and forgery checks on mail sent by this mailing list. However, it will also disable spam checks, so if spam is sent to the mailing list, it won't be trapped by SA.
In the long term, SPF and forgery checks probably need to be a little bit more configurable, i.e: So it's possible to specify whether to do SPF and forgery checks on the envelope sender, header From: and SPF on return path (Not presently done in EximConfig, but should be.)
I found that the best remedy was to disable "spf_from_acl" in /etc/exim4/eximconfig/config/spf.conf . This bit:
#spf_from_acl: # # # Check header From: # warn set acl_m8 = ${address:$h_From:} # deny !acl = spf_check # warn message = Received-SPF-From: $acl_m8 ($acl_m7) # accept
I've left the envelope-sender check, etc., intact:
spf_rcpt_acl:
# Check envelope sender warn set acl_m8 = $sender_address deny !acl = spf_check warn message = Received-SPF: $acl_m8 ($acl_m7) accept
spf_check:
warn set acl_m2 = ${readsocket{/tmp/spfd}\ {ip=$sender_host_address\n\ helo=${if def:sender_helo_name\ {$sender_helo_name}{NOHELO}}\ \nsender=$acl_m8\n\n}{20s}{\n}{socket failure}}
# Defer on socket error
defer condition = ${if eq{$acl_m2}{socket failure}{yes}{no}} message = Cannot connect to spfd
# Prepare answer and get results
warn set acl_m2 = ${sg{$acl_m2}{\N=(.*)\n\N}{="$1" }} set acl_m8 = ${extract{result}{$acl_m2}{$value}{unknown}} set acl_m7 = ${extract{header_comment}{$acl_m2}{$value}{}}
# Check for fail
deny condition = ${if eq{$acl_m8}{fail}{yes}{no}} message = ${extract{smtp_comment}{$acl_m2}{$value}{}} log_message = Not authorized by SPF
accept
Unless I'm missing something, that really _is_ the only logical solution, since SPF by its creator's definition and intent _is_ intended to validate "From " and _not_ "From:".
I really would urge that you consider disabling "spf_from_acl" in post-2.2 versions.
-- Cheers, "Due to circumstances beyond our control, we regret to Rick Moen inform you that circumstances are beyond our control." rick@linuxmafia.com --Paul Benoit