The following principles apply to spam control on IETF mailing lists:
* IETF mailing lists MUST provide spam control.
* Such spam control SHOULD track accepted practices used on the Internet.
These two bullets are well-intentioned, but have no clear meaning. Simply
put,
there is no way of knowing whether conformance has been achieved.
IMO this criticism is legitimate (unlike the previous criticisms I responded
to, which IMO are not). That said, I tried to come up with a way say what's
needed here and I'm afraid I could come up with nothing better for the first
point. LIke it or not, spam is a major problem and controls are necessary. But
the minute you dive into what control means you're basically stuck into a
definitional funk.
For example, there are many different sets of "accepted practice" for
anti-abuse
email mechanisms, and what is particularly vexing is that what is deemed
desirable by one constituency often is deemed as deplorable by another.
Exactly. I think the right thing to do is simply remove this item entirely. I'm
not entirely happy about this resolution but I can think of nothing better.
* IETF mailing lists MUST provide a mechanism for legitimate technical
participants to bypass moderation, challenge-response, or other techniques
that would interfere with a prompt technical debate on the mailing list
without requiring such participants to receive list traffic.
Here, again, is something that is not a technical specification and had no
clear
criterion to permit telling when it is satisfied.
In fact, I'm not sure this bullet even has an appropriate goal. (On
reflection,
I'm not entirely sure what the precise goal is.)
The goal is simple: Whitelisting. There are many reasons such a facility is
needed, but one I see all the time is where someone is subscribed using a
subaddress of some sort but doesn't post using that address.
We call this a "nomail" subscription in our implementation, after the LISTSERV
command that was used to set this up.
If the intent is to say that mailing lists shall not operate in a moderated
mode, whereby all postings are subject to prior approval by the list
administrator, then that's probably what you need to say. But the language,
here, seems to say that if such controls are in place, any participant can
bypass them. In which case, why have the control?
Wow, I just don't get it. Nothing in the text says or even implies that
any participant can bypass the controls on a whim. Why is everyone reading
into the text something that just isn't there?
I guess it is necessary to modify the text to make it clear that such
arrangements are customarily made through some sort of additional configuration
involving some kind of validity check. I have to say I'm nothing short of
astounded that this is necessary.
* IETF mailing lists MUST provide a mechanism for legitimate technical
participants to determine if an attempt to post was dropped as apparent
spam.
This is actually contrary to the way most list software seems to work. When
dropping is done, it is done silently, in order to eliminate that considerable
overhead that comes with large-volume spamming.
The approach I prefer (and which I hope most list software is able to support)
is to bounce such messages at the SMTP level. This eliminates sufficient
blowback to be an effective approach. (And yes, I'm well aware that it doesn't
eliminate all of it. Let's please not dive down this rathole yet again.)
However, if for some reason this isn't possible, or leads to too much blowback
via relays, or whatever, there are alternatives. The obvious one is to record
the message-ids of messages rejected as spam for some reasonable period of time
so the handling of a given message can be determined.
Nothing in the requirement says that the disposition of the message has to be
communicated through an email notification.
If the IESG has something specific in mind, then it should document how to
achieve it for a number of the major mailing list packages.
I would not object to documenting some of the possible approaches, but is this
right place for it? As for requiringing a specific approach, I strongly object
to that.
* The Internet draft editor, RFC editor, IESG secretary, IETF chair and
IANA MUST be able to post to IETF mailing lists. The relevant identity
information for these roles will be added to any white-list mechanism used
by an IETF mailing list.
Oops. This is quite a good idea and I am quite sure that only one or two of
the
ones that need whitelisting are entered in the lists I administer.
But that really leads to the question of where the list of addresses to enter
is
maintained? Given a standard list, then yes, it makes sense to have list
admins
pre-load them.
Um, Dave, you do realize the implications of providing a list on a policy page
of addresses whitelisted for all IETF lists? I think it is very sensible indeed
to omit this.
So here is the process question:
You know, I think I'm going to pass on the process question here. I'm having
more than enough fun with the technical side.
Ned
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf