I am sorry, if I sound harsh, but I think this chain of mails is becoming more
concerning than the amount of spam one receives. Could we put an end to it?
James M Galvin wrote:
> Keith,
>
> Your NAT analogy is weak, very weak, at best. It's opening premise is
> flawed, as is this entire discussion of mail list filtering, because it
> confuses policy with implementation.
>
> The IETF has a policy of "openness" for all its mailing lists. The
> problem is most of the argument against filtering defines openness as
> "all messages shall be distributed." This is false.
>
> Every IETF mailing list has a charter, a known purpose for its use. It
> is entirely reasonable and legitimate to reject all submissions that are
> outside the scope of the charter. If we can not agree on that point
> this whole discussion is pointless.
>
> Implementation is wholly separate from policy, and a primary concern for
> the list maintainer. A list maintainer needs to figure out how to
> identify messages that are within scope and ideally would like to
> automate that process. I would assert they can do this without anyone's
> approval or guidance. The only issue anyone in the IETF can have with
> that is if the list maintainer has a skewed sense of "within scope" or
> if whatever process they use generates false positives. But you can not
> know this until after the fact. We do so many things in this
> "organization" on the basis of "subjective judgement with after decision
> peer review," (less so now than even just 5 years ago but still) why
> should this be any different?
>
> Mail filtering is not in and of itself a bad thing. It is a tool, a
> legitimate tool, that when used as part of a larger solution to the
> problem of maintaining the integrity of a mailing list is extremely
> valuable.
>
> Restricting the posting of messages to subscribers is not bad, it is an
> excellent choice for the first line defense against off-topic messages.
> The issue is whether it is the only solution employed.
>
> Messages from non-subscribers need to be reviewed to determine if they
> are within scope. In a worst case this review is done manually but it
> doesn't need to be. There are a few (I mean less than 5) additional
> technological criteria that can be applied that will correctly review
> 95% or more of the non-subscriber messages. This minimizes the manual
> work.
>
> I know this because I do this and have been doing it for years. I have
> a 100% success rate at keeping spam off mailing lists and no complaints.
> The total volume of email I deal with far exceeds the needs of all the
> IETF lists combined. This is not rocket science.
>
> Furthermore, I don't see how the occasional 24-48 hour delay in getting
> an occasional message distributed is bad. So many people have this
> idealistic view of email immediacy. Have you ever really looked at the
> Received: lines for messages distributed to the main IETF list?
> Messages to me typically take about 6 hours to get delivered but I've
> seen delays as long as 18 hours. And the delay is *not* at my end.
>
> Jim
>
> On Mon, 21 May 2001, Keith Moore wrote:
>
> Date: Mon, 21 May 2001 18:00:02 -0400
> From: Keith Moore <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: filtering of mailing lists and NATs
>
> it occurs to me that most of the methods that have been proposed
> for filtering spam from mailing lists have a lot in common with NATs.
>
> in both cases, the proponents say (in effect) "if it works for me and
> for my small set of test cases, it must be okay to impose this on
> everyone. if some legitimate traffic is excluded by my filters, they is
> of no consequence - they should be willing to jump through whatever hoops
> that I believe are appropriate. and if people have to abandon practices
> that they find useful in order to to get around my filters, that is of
> no consequence either, because they do not need to be doing those things
> anyway"
>
> Keith
>
>
--
************************************************
The only way to solve a problem is to look at it in the face.
************************************************
