Date: Fri, 3 Jan 2003 13:46:48 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Terry Lambert <tlambert2@mindspring.com> Cc: Dave Hayes <dave@jetcafe.org>, dever@getaclue.net, freebsd-chat@FreeBSD.ORG Subject: Re: Bystander shot by a spam filter. Message-ID: <20030103214648.GE10237@HAL9000.homeunix.com> In-Reply-To: <3E15E208.18128D71@mindspring.com> References: <200212302207.gBUM74175262@hokkshideh2.jetcafe.org> <20021230235954.GB2072@HAL9000.homeunix.com> <3E10FD38.87438C83@mindspring.com> <20030103095508.GA10237@HAL9000.homeunix.com> <3E15E208.18128D71@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Terry Lambert <tlambert2@mindspring.com>: > David Schultz wrote: > > > Actually, you want to have authorization, not authentication. You > > > could probably care less about authentication, and it seems to me > > > that authentication is the part that Dave objects to, anyway. > > > > > > The point of authorization is to change the cost model, anyway, so > > > in the limit, you are talking about economics in both your approaches. > > > > Authentication is a prerequisite to being able to enforce policies > > for authorization. > > No, it's not. > > Consider: > [...] > > Basically: there is no authetication, only authorization, since a > certificate does not provide me with identity, unless we modify the > domain name registration system to require proof of identity. A DNS-based solution doesn't save you from IP spoofing and other routing-based attacks. Also, in your system the people running the network write the policy, not the people receiving the mail. Will the ISPs in Taiwan implement a policy that I can agree with, or do I have to blackhole all of Taiwan? > > I intentionally avoided trying to specify some > > sort of culture or policy for email because that's a highly > > debatable issue. I'm just pointing out that in order to enforce > > any policy in a way that can't be abused, you need an > > infrastructure that allows you to bind a key to every sender, or > > at least to each service provider. > > Yes. But having a key in hand does not provide sufficient data > to discern the sender's identity. The ability to send anonymous > email is not lost... in fact, given the way today's blacklists > operate, it is regained. You still need an authority in the system, perhaps to sign personal keys. But that's true of any system that allows you to receive mail from a select group of people you don't know, your proposal included. In your system, the authority always returns a `yes' or `no' answer to the question of whether a particular principal is authorized to send mail. I claim that the authority ought to return some information about the principal that would permit the implementation of more expressive policies. That information doesn't need to include a name and SSN, but it might have a `SPAM history' of some sort and SPAM statistics for the originating ISP. Then I could say, ``I don't want to receive mail from anyone who has sent confirmed SPAM,'' or ``I don't want to hear from people who use anonymous remailers''. Of course, there are ways to abuse the policies I just stated, so further refinement is needed. Ideally, we would have an inclusion set. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030103214648.GE10237>