-- On Tuesday, April 15, 2008 11:36 PM +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> 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(_at_)xyzzy add a new address jhjhjggjhmgc(_at_)gmail", it also
doesn't let me say "now please consider hmhmdnbdngnf(_at_)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
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf