[BALUG-Admin] BALUG lists ... mailman list(?!), blank body with command in Subject: header

[Rick Moen]

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