Re: IESG Statement on Spam Control on IETF Mailing Lists

[James Galvin <[e-mail]>]

-- On Tuesday, April 15, 2008 11:36 PM +0200 Frank Ellermann 
<[e-mail]> wrote regarding Re: IESG Statement on 
Spam Control on IETF Mailing Lists --

> >| As a service to the community, the IETF Secretariat
> >| operates a mailing list archive for working group
> >| mailing lists.
>
> Most lists I submitted to the "other lists" are in fact
> former WG lists.  I guess there is nothing to do for the
> submitter / AD / list owner for former IETF WG lists, the
> "official" archives are likely still subscribed.

I would suggest that there needs to be a back-office process in 
place to ensure that when a working group (or BOF or any other 
list) shuts down, the IETF should make sure it has a copy of the 
complete archive.  This does not currently exist.


> Maybe the two archive subscriptions could be added to the
> verification procedure.  As far as I can tell it the Web
> form creates a request to the chosen AD, the AD can then
> accept, reject, or ignore it.  The accept state could be
> split to arrange the archive subscriptions.  Lots of fun
> there, but there aren't many "other list", and most have
> a mailman Web interface.

Which web form are you referring to?  I think what you're talking 
about is the one for the web page that lists "other lists".  If 
that's true, I agree, there should be a back-office process that 
checks the archive subscriptions before (perhaps in parallel) with 
the list getting listed on the "other lists" web page.  Of course 
this does not address the maintenance issue of keeping the 
subscription live....

If you're talking about the mailing list request form, that's for 
getting a list hosted at ietf.org so the archives are not an issue 
in that case.

Or did you mean some other form?


> > My opinion is that the IETF should just create a mailing
> > list for every WG and then these "other lists" should
> > just subscribe the IETF list to their list.
>
> The opposition can then still pretend to send mail from the
> old list to the new list, and vice versa.  The position of
> the gateway on the IETF side (directly above the archives
> vs. before the new list) won't necessarily change the spam
> problem.

But what it facilitates is using the same mechanisms in the same 
way to control the SPAM problem.  It is an operational 
simplification that obviates a bifurcation.  Instead of a message 
coming in, getting tagged by SpamAssassin and then having to be 
directed either to an archive or Mailman, it always goes to 
Mailman.  The SPAM filtering is already part of Mailman.  If it 
goes to the archive you have to add a module or function to do the 
SPAM filtering that Mailman does.


> > Mailman provides some useful built-in features.
>
> Unfortunately it doesn't let me say "for each subscribed
> nobody@xyzzy add a new address jhjhjggjhmgc@gmail", it also
> doesn't let me say "now please consider hmhmdnbdngnf@gmail
> to have write access on all existing lists".

Well, I'm not exactly a Mailman expert but I believe these features 
are relatively straightforward to do if you are the Mailman site 
administrator and have shell access to the server.  Therefore, an 
ambitious person could setup a web interface to support them.  :-)


Jim

_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf