Date: Fri, 03 Jan 2003 11:18:32 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: Dave Hayes <dave@jetcafe.org>, dever@getaclue.net, freebsd-chat@FreeBSD.ORG Subject: Re: Bystander shot by a spam filter. Message-ID: <3E15E208.18128D71@mindspring.com> References: <200212302207.gBUM74175262@hokkshideh2.jetcafe.org> <20021230235954.GB2072@HAL9000.homeunix.com> <3E10FD38.87438C83@mindspring.com> <20030103095508.GA10237@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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: o I want it it cost a proportionally large amount of money to SPAM o I tie the ability to send email to a renewable time limited X.509 certificate o I tie the X.509 certificate to the sender's domain name o I the the domain name to an IP address through a crosscheck, which ties it to the . and .inaddr-arpa. delegation authority o If the certificate is used to send SPAM, I refuse to renew it for you. This is a contractual obligation for my certifying authority o Anyone is free to set up a certifying authority, based on any preconditions for certification they want (or none, if they want). People can subscribe to any certifying authority they want, without fee, since the public key must be well known, if it is to be used at all o The refusal is either permanent, or I tie an economic cost to a punative renewal fee, in the face of SPAM: in order to send SPAM, you must pay a "bulk postage rate" for that right, for a period equal to the duration of the validity of the certificate o It now costs you the smaller of a domain name registration or a punative certificate renewal fee, to send SPAM (this is preferrably the domain fee, but we recognize that we do not wish an economic equivalence to the "burning" of domain names, since it is a linear limited space in each TLD) o In no case does having a certificate tell me anything more than that someone has paid some money, either for a domain name registration, or for a recertification, following a violation of their covenant with the certifying authority. 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. > 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. > It needs to take more than an Internet connection to send email; > it must require some sort of consent from the community. Yes. That's self-evident. > Moreover, that permission must be granted in a secure way. No. It does not require a secure relationship, it requires a trust relationship. That's a very different thing. That can be handled by ensuring that the machine requesting the certificate to send is one of the machines known to the DNS server for the authoritative domain, by obtaining the peer IP address, performing a reverse lookup, performing a forward lookup on the canonical name, and verifying that the IP address of the forward lookup matches the peer IP address, to ensure a DNS spoof is not being utilized to make the machine appear, via a simple reverse lookup, to be in a domain it's not (i.e. I can put any thing I want in the reverse DNS entry for an IP address for which I have the .in-addr.arpa. delegation). > Clearly, basing it on IP addresses and > artificial intelligence is unreliable and complicated, as > evidenced by the existence of this thread. No. The existance of this thread is on the basis of the lack of implementation in the most common mail server software, not on the inability of such code to be implemented. Realize that in order to support TLS and some forms of SMTP AUTH and other facilities, including local delivery of S/MIME messages, the code to support this type of thing already exists in the SMTP mail servers -- it's merely not invoked for this particular use. Yet. -- Terry 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?3E15E208.18128D71>