Re: PS -- Re: Restricting the list
Ned Freed <NED@innosoft.com> Wed, 07 February 1996 20:56 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19707;
7 Feb 96 15:56 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa19702;
7 Feb 96 15:56 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa13022;
7 Feb 96 15:56 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net
(8.6.12/8.6.12) with SMTP id PAA18059; Wed, 7 Feb 1996 15:56:12 -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 PAA18021;
Wed, 7 Feb 1996 15:55:53 -0500
Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.0-6 #2001)
id <01I0XJ5VPCHS9N3WDF@INNOSOFT.COM>; Wed, 07 Feb 1996 12:54:38 -0800 (PST)
Message-Id: <01I0XKYNCNLW9N3WDF@INNOSOFT.COM>
Date: Wed, 07 Feb 1996 12:33:15 -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: Dave Crocker <dcrocker@brandenburg.com>
Cc: Ned Freed <NED@innosoft.com>, ietf-smtp@list.cren.net,
ietf-822@list.cren.net
Subject: Re: PS -- Re: Restricting the list
In-Reply-To: "Your message dated Wed, 07 Feb 1996 07:40:22 -0800"
<v03004a06ad3e76a1dc8c@[205.214.160.51]>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Listprocessor-Version: 8.0(beta) -- ListProcessor by CREN
> At 8:58 AM 2/6/96, Ned Freed wrote: > >1. I've already pointed out that filtering on specific origin addresses is > > totally ineffective. > Ned, > What about the following set of mechanisms, each of which I believe > I've seen in operation. In combination, they would seem to create a rather > powerful filter and control mechanism, I would think. > 1. To subscribe to a list, the user sends a request. The list server > sends back a verification request. The subscriber returns a confirmation. > This provides reasonable assurance that the registered email address is > valid. I've already described this mechanism and commented on it in some detail on the IETF list. Simply put, the problem is that list subscribers hate it and therefore most list managers cannot reasonably use it. As such, it's a nonstarter more often than not. It also has nothing to do with spamming; it's a mechanism intended to defeat personal "subscribe him to every list in the world" attacks like the one directed at Mark Crispin recently. > 2. Those who are registered can send messages freely. Those who are not > have their messages channeled to the list moderate who decides whether to > forward the message or not. One could elaborate this, further, by having > non-registered email ALSO get a verification request from the server before > sending it on to the moderator. This would filter deprivation of service > attacks, I suppose. I have also described this particular mechanism in an earlier message on this list. The sender verification step suffers from the problems #1 has only more so -- people posting to lists *really* hate it and simply won't post if it is used. (I personally can tolerate #1 but won't accept this variant of it.) As for having a moderator review messages received from people not subscribed to the list, this depends on having a moderator willing to perform the task. Such moderator resources are in scarce supply. Also keep in mind that the burden placed on the moderator is FAR greater than anticipated, as postings from legitimate list members from addresses other than the address registered on the list are incredibly common. (For example, I probably send out around 100 messages out every day, and at least half of them have this property.) I also heard it suggested that lists maintain a separate set of "addresses that can post to the list". This is a nice idea in theory, and some list managers, including the one in our PMDF product, allow for it, but the problem is that the information needed to maintain such tables is rarely available. Finally, please note that the attack I previously described blows past all this with ease, since it builds a list of addresses that are known to be subscribed to the list in an automated way. I dealt with a use of this attack this morning -- it is the first case I have seen. This will never be as common as more simpleminded techniques, but it will not remain unknown for much longer. In conclusion, my bottom line remains the same: In the lucky event that you can find a moderator willing to look at every message, that is what you should do and the more power to you. And if you can find a moderator willing to look at exceptions defined by list-specific heuristics, then this is also reasonable. But there are always going to be lists where these resources don't exist, and the only viable approach then is to just delete the offending spams and get on with life. Ned
- Re: PS -- Re: Restricting the list Dave Crocker
- Re: PS -- Re: Restricting the list Tim Kehres
- Re: PS -- Re: Restricting the list Ned Freed
- Re: PS -- Re: Restricting the list John W. Noerenberg
- Re: PS -- Re: Restricting the list Dave Crocker
- Re: PS -- Re: Restricting the list John W. Noerenberg
- Re: PS -- Re: Restricting the list Robert Moskowitz
- Re: PS -- Re: Restricting the list Robert Moskowitz
- Re: PS -- Re: Restricting the list Dave Crocker
- Re: PS -- Re: Restricting the list Ned Freed