North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Clueless service restrictions (was RE: Anti-spam System Idea)

  • From: Tony Hain
  • Date: Tue Feb 17 20:30:12 2004

Clearly I misinterpreted your comments; sorry for reading other parts of the
thread into your intent. The bottom line is the lack of a -scalable- trust
infrastructure. You are arguing here that the technically inclined could
select from a list of partial trust options and achieve 'close enough'.
While that is true, Joe-sixpack wouldn't bother even if he could figure out
how. Whatever trust infrastructure that comes into existence for the mass
market has to appear to be seamless, even if it is technically constructed
from multiple parts. 

Steve Bellovin suggested earlier that identity based approaches wouldn't
work. While I agree having the identity won't solve the problems by itself,
it does provide a key that the rest of the legal system can start to work
with. False identities are common in the real world, so their existence in
the electronic world is not really any different. I guess I am looking at
this from the opposite side the two of you appear to be, rather than
requiring authorization to send, irrefutable identity should be used to deny
receipt after proven abuse. 


> -----Original Message-----
> From: Alex Bligh [mailto:[email protected]]
> Sent: Tuesday, February 17, 2004 4:48 PM
> To: Tony Hain; 'Steven M. Bellovin'
> Cc: [email protected]; Alex Bligh
> Subject: RE: Clueless service restrictions (was RE: Anti-spam System Idea)
> --On 17 February 2004 16:19 -0800 Tony Hain <[email protected]> wrote:
> > Where they specifically form a club and agree to preclude the basement
> > multi-homed site from participating through prefix length filters. This
> > is exactly like the thread comments about preventing consumers from
> > running independent servers by forced filtering and routing through the
> > ISP server. This is not scaled trust; it is a plain and simple power
> > grab. Central censorship is what you are promoting, but you are trying
> to
> > pass it off as spam control through a provider based transitive trust
> > structure. Either you are clueless about where you are headed, or you
> > think the consumers won't care when you take their rights away. Either
> > way this path is not good news for the future Internet.
> Now there was me thinking that I was in general agreeing with you. I am
> not
> promoting any sort of censorship, central or otherwise. I believe you have
> a perfect right to open a port 25 connection to any server, and I have a
> perfect right to accept or deny it. And of course vice-versa. What I am
> saying is that I would like, in determining whether to accept or reject
> your connection, to know who you are and that you act responsibly, or
> failing that, to know someone who is prepared to vouch for you; failing
> that, may be I'll accept your email anyway, may be I won't. I do not care
> what upstream either you or I have. For the avoidance of doubt, I am not
> talking about forcing people to send mail through their upstreams, or even
> suggesting that the graph of any web of trust should follow the BGP
> topology. Indeed the entire point I made about separating the web of
> trust's topology from IP addresses etc. was rather to enable end users to
> CHOOSE how they accept/reject mail in a manner that might have nothing to
> do with network topology. Personally I would be far more happy accepting
> mail from someone who'd been vouched for by (say) someone on this list I
> knew, than vouched for by their quite possibly clueless DSL provider. Of
> course some people will want to use their "ISP", many won't. Just like Joe
> User can use their upstream's DNS service, but doesn't necessarily need
> Maybe PGP would have been a better analogy as far as the scale bit goes. I
> think you are assigning motives to the BGP basement-multihoming problems
> where in general the main motive is not getting return on cost of
> hardware;
> however, I don't think the same scale constraints need apply as it is
> unnecessary to hold a complete table in-core at once.
> Alex