Re: PS -- Re: Restricting the list
Ned Freed <NED@innosoft.com> Tue, 06 February 1996 18:12 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16737;
6 Feb 96 13:12 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16733;
6 Feb 96 13:12 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa10798;
6 Feb 96 13:12 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net
(8.6.12/8.6.12) with SMTP id NAA26906; Tue, 6 Feb 1996 13:11:15 -0500
Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by
list.cren.net (8.6.12/8.6.12) with ESMTP id NAA26860;
Tue, 6 Feb 1996 13:10:07 -0500
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-6 #2001)
id <01I0VYAXOIG096W68X@INNOSOFT.COM>; Tue, 06 Feb 1996 10:02:45 -0800 (PST)
Message-Id: <01I0W0O4VCHA96W68X@INNOSOFT.COM>
Date: Tue, 06 Feb 1996 08:58:51 -0800 (PST)
X-Orig-Sender: owner-ietf-smtp@list.cren.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Ned Freed <NED@innosoft.com>
To: Nathaniel Borenstein <nsb@nsb.fv.com>
Cc: conklin@info.cren.net, ietf-smtp@list.cren.net, ietf-822@list.cren.net,
"John W. Noerenberg" <jwn2@qualcomm.com>
Subject: Re: PS -- Re: Restricting the list
In-Reply-To: "Your message dated Tue, 06 Feb 1996 06:56:14 -0500 (EST)"
<gl5o7SqMc50e0NGWwg@nsb.fv.com>
References: <v03004a00ad3c858b7d47@[129.46.54.71]>
<v03004a00ad3c858b7d47@[129.46.54.71]>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
X-Listprocessor-Version: 8.0(beta) -- ListProcessor by CREN
> To pre-empt an obvious objection: My guess is that very few people are > both technologically sophisticated enough to know how to change their > Email address and culturally unsophisticated enough to use that > knowledge to inappropriately spam mailing lists. But there will > undoubtedly be a few. -- NB As a long-time subscriber to the FV list, I'm very familiar with the problems there that Nathaniel has set out to address. And I agree that in this limited case a bozo list can be an effective tool. Unfortunately this approach is completely worthless when it comes to the sort of spamming that started this discussion. Nathaniel may be correct in his assessment that most people lack either the sophisitication or attitude necessary to change email addresses. Nevertheless, "most people" is known not to apply to the typical originator of this sort of spam. We have ample evidence that this is the case. Usually origin addresses are bogus and are chosen to make a point. The nude videoconferencing spam that started this discussion was an example of this. The ongoing magazine subscription spam that keeps coming back is also an example, and so is the learn-while-you-sleep spam. Some of these things are sufficiently sophisticated that they use different addresses on each list they post to. There is actually a book that describes how to spam and I'm told it specifically recommends using different addresses each time a spam is sent out. I must also point out that the state of the art in spam prevention is already far past this point. It is worthwhile to review the various methods that are available: 0. Use news and not mail. News has a key feature email lacks: Messages can be recalled after being sent. Unfortunately settting up newsgroups is much more involved than setting up mailing lists, so much so that it is impractical to talk about converting most mailing lists to news. 1. I've already pointed out that filtering on specific origin addresses is totally ineffective. 2. Filtering duplicate postings to multiple, unrelated lists is somewhat successful now, but there are clear indications that spammers have already figured this out and are taking steps to post different variants to each list. Building software to generate such variants is technology that is well understood -- I recall a program on a system I used back in 1978 that wrote random dirty poetry, and it was old when I first encountered it -- and it's only a matter of time before use of this technology becomes routine. Furthermore, the filters used to implement this sort of thing often misfire and block legitimate postings: I've had more than one posting that quoted from previous postings rejected by some LISTSERV variant, and I generally don't bother to repost such things, which I'm conceited enough to think is not to the advantage of the list. 3. Restricting lists to postings from list members is very effective at the present time, but it is also hugely inconvenient to list participants. I've already stated my firm policy in this area: I absolutely refuse to cater to such software. And if this approach becomes widespread it can easily be overcome by spammers: All they have to do is set up a robot that subscribes to lists and captures one or more addresses of people who do manage to post. I figure I could write the software to do this in an afternoon, and it is silly to suppose that the spammers would be unable do something similar. Heck, if such restriction become widespread someone probably could write the software to do this and sell the results it generates to the spammers! 4. Scanning postings for inappropriate material is an approach that looks attractive but is very difficult to implement in practice. You may be able to catch offsensive text, but I'll bet there wasn't anything in the magazine subscription spam that you could easily latch onto. And what are you going to do about someone who, now that MIME-capable readers are getting to be pretty common, posts a GIF image? Scan the image? The technology in this area isn't up to the challenge, I'm afraid. And an approach of blocking all GIFs or whatever won't work since people are starting to use them as signature files and so on. 5. Inserting a delay in the list that offers a shot at manual intervention and deletion of inappropriate material is somewhat effective. But spammers tend to come out at night, when people able to scan such messages are in short supply, and inserting delays long enough to insure that reviewers are available can be very inconvenient. 6. Hybrid approaches employing one or more of these ideas, coupled with partial moderation (where instead of rejecting suspect messages outright they are sent to a moderator for review) is about the best mechanism we have at this time. But anyone implementing this should take note of a key point: The specific automatic review mechanism they decide on should not be revealed publicly. The minute you publish the details of the specific approach you use you have provided the enemy with the means to get around your restrictions. The problem with this approach, of course, is that list managers have to acquire the sophistication to set up such things. This last point in the killer when it comes to commercial software. A single, standardized list filter simply won't cut it. As such, the approach we've taken in our PMDF product is to provide the tools necessary implement a wide variety of list filters. Sites can then build the filters they want from the available tools. I don't know (and don't want to know) the specific mechanisms people have implemented using the tools we provide. This requires both substantial management skills and competent technical support from the vendor, but it is the best we've been able to come up with. The long-term prognosis, however, is gloomy: There is no single universally effective long-term solution to these problems other than full moderation of all lists at all times. And the more half-assed measures we employ the more we inconvenience list participants while not managing to inconvenience the spammers significantly. Ned
- Restricting the list Jim Conklin
- Re: Restricting the list Ned Freed
- Re: Restricting the list Donald E. Eastlake 3rd
- Re: Restricting the list Roger Fajman
- Re: Restricting the list John W. Noerenberg
- PS -- Re: Restricting the list Nathaniel Borenstein
- Re: Restricting the list Nathaniel Borenstein
- Re: Restricting the list Jay
- Re: Restricting the list Ben Nowlin
- Re: PS -- Re: Restricting the list Ned Freed
- Re: Restricting the list Ned Freed
- Re: Restricting the list John W. Noerenberg
- Re: Restricting the list RANDY
- Re: Restricting the list Robert Moskowitz
- Re: Restricting the list keld
- Re: Restricting the list Lindsay
- Re: Restricting the list Einar Stefferud
- Re: Restricting the list Jim Conklin
- Re: Restricting the list Tim Kehres