comp.lang.ml and sml-list problems

The infrastructure for dealing with moderation of comp.lang.ml and
sml-list finally broke down for good sometime earlier this year due to
changes in the supported software at Carnegie Mellon, which hosts the
key moderation addresses. I have recovered some posts from the past
few months, but it is likely that some posts, particularly those posted
via comp.lang.ml, may have either been rejected or silently dropped. I
believe that I now have a working interim solution, and assuming that
this works correctly I will forward on all posts that I have recovered.
My apologies for any that have been lost.

My interim solution is based on the Mailman mailing list software. It
is possible that there will be some glitches associated with this - I
have had some problems with Mailman's netnews gatewaying in the past.
Please let me know if your posts do not show up in a reasonable amount
of time (e.g. 1-2 weekdays), or if you run into other problems.

I am looking at several alternatives for a long term solution, which
hopefully will result in a more efficient and reliable moderation
process all around.

Thanks,
Leaf Petersen, Moderator comp.lang.ml and sml-list

It is certainly possible to go this route - it would certainly be the
easiest for me. The major potential issue that I see is that
comp.lang.ml and sml-list are tied together, and the volume of spam may
be problematic for the readers of sml-list without the moderation filter
in place.

Sml-list receives a considerable volume of spam, as does comp.lang.ml.
It's not clear to me how much of the comp.lang.ml spam comes from the
newsgroup, and how much from the submission address (which would go away
if the newsgroup became unmoderated). I suspect that this would be more
of an issue for sml-list readers, but I'm not sure.

If the newsgroup were to switch to unmoderated status, the options that
I see are:

1) Automatically gateway sml-list and comp.lang.ml together (both
unmoderated)
2) Abandon sml-list entirely (there still seems to be traffic from this
end though)
3) Separate the two entirely (presumably leaving sml-list moderated)
4) Leave sml-list moderated, but comp.lang.ml unmoderated. I'm not
positive that this is feasible, but I believe it can be done.

All four of these would likely have the benefit of reducing the
administrative overhead, except possibly option 4.

I would be interested to hear opinions from folks: for, against, or
ambivalent.

cheers,
-leaf


David B. Benson wrote:
>> Leaf Petersen, Moderator comp.lang.ml and sml-list
>>
>
> I (and others) would prefer comp.lang.ml to be UNmoderated. This
> works acceptably well for comp.lang.functional.
>
>
>
>

In article <mailman.1.1206744417.5464.sml-redistribution@mailman.srv.cs.cmu.edu>,
Leaf Petersen <sml-list@cs.cmu.edu> wrote:
>It is certainly possible to go this route - it would certainly be the
>easiest for me. The major potential issue that I see is that
>comp.lang.ml and sml-list are tied together, and the volume of spam may
>be problematic for the readers of sml-list without the moderation filter
>in place.

Another option is to employ robo-moderation software that would
allow known posters through fairly easily, but put some barriers
in place of spam. This might also allow the work of moderation
to be shared more easily.

I would suggest STUMP:

http://www.algebra.com/~ichudov/stump/


Incidentally, it's probably impossible to get the moderation
status changed on every server worldwide, so in practice we would
need some "auto approving" software regardless to deal with posts
from servers that had not been updated. So we may as well employ
somewhat more intelligent software to get extra benefits...


--
Jeffrey M. Vinocur, M.D.
jmv16@cornell.edu

> 3) Separate the two entirely (presumably leaving sml-list moderated)

I suggest trying this and seeing how it goes.

Disclaimer: I never read sml-list.

This is somewhat orthogonal, but yes: my default plan is to move to
STUMP or something like it. This would allow for several moderators to
share the job, as well as white-listing regular posters. However, the
STUMP requirements are more than the general purpose linux account at
CMU that comp.lang.ml is currently hosted out of provides. So this is
gated by me resolving the hosting situation.

Cheers,
Leaf

Jeffrey M. Vinocur wrote:
> In article <mailman.1.1206744417.5464.sml-redistribution@mailman.srv.cs.cmu.edu>,
> Leaf Petersen <sml-list@cs.cmu.edu> wrote:
>
>> It is certainly possible to go this route - it would certainly be the
>> easiest for me. The major potential issue that I see is that
>> comp.lang.ml and sml-list are tied together, and the volume of spam may
>> be problematic for the readers of sml-list without the moderation filter
>> in place.
>>
>
> Another option is to employ robo-moderation software that would
> allow known posters through fairly easily, but put some barriers
> in place of spam. This might also allow the work of moderation
> to be shared more easily.
>
> I would suggest STUMP:
>
> http://www.algebra.com/~ichudov/stump/
>
>
> Incidentally, it's probably impossible to get the moderation
> status changed on every server worldwide, so in practice we would
> need some "auto approving" software regardless to deal with posts
> from servers that had not been updated. So we may as well employ
> somewhat more intelligent software to get extra benefits...
>
>
>

In article <mailman.1.1207112547.9373.sml-redistribution@mailman.srv.cs.cmu.edu> you write:
>This is somewhat orthogonal,

Well, yes and no, since having a reliable way to do fairly quick
moderation would resolve the issue without having to decouple the
mailing list (which personally I'd rather avoid, since the
community is not so large to start with).


>STUMP requirements are more than the general purpose linux account at
>CMU that comp.lang.ml is currently hosted out of provides. So this is
>gated by me resolving the hosting situation.

I'd have to check with my co-sysadmin type but if you think it
would be an improvement over the current situation, we could
potentially host for you.

(It's a "personal" server, no guarantees about reliability, but
it's rackmounted hardware in a commercial colocation facility,
and we run a lot of services we care about off of it so it does
get a decent amount of attention -- current uptime is 204 days.)


--
Jeffrey M. Vinocur, M.D.
jmv16@cornell.edu