Re: Why are we here? What are our goals?

On Jan 30, 2004, at 1:53 AM, Hector Santos wrote:

> Lyndon,  "Provable anonymity" is an oxymoron.
>
> If its *provable*, you are not anonymous.
I'm on Lyndon's side here. You can have provable anonymity. All you 
need is a man in the middle you trust to handshake that they trust the 
originator.
And that's the rub at putting anonymity down at the transport layer. 
you open up a huge hole for the spammers to use; they'll simply start 
setting up trust engines using bogus real world data, and use that to 
relay spam in to you. And as fast as you figure out that you're 
trusting something untrustworthy, they'll move on and replace it with a 
new bogus trust handler.
Because what the server to server relationship has is authentication -- 
you know who the other guy is. But that's like me handing you my 
driver's license. Now you have my ID, but that doesn't tell you a thing 
about whether I help little old ladies across streets or if I like 
running them over.
I think any system where the "web of trust" leaves the server's 
environment is going to fail, because it'll be jobbed by those who's 
interests are in getting around it. So each server should define it's 
own web of trust with the help of its admin. If the admin wants to hand 
off part of that job to some third party, fine, let's build in support 
for that ala RBL. But let's not legislate that into this service or 
define what it is. Instead, let's define a server who's assumption is 
one of non-trust until proven otherwise, and takes appropriate steps to 
be a safe harbor for its users and minimize any damage an unknown 
entity might cause. Then each admin can choose to add information on 
trust/reject as they see fit and which works for their environment, 
because we should understand up front that there is no global, 
universally acceptable view of what "white hat" or "black hat" should 
be. any attempt to build that universal definition will fail.
So what I'm suggesting is an authentication mechanism tied to the host 
name of the machine, tied back to a DNS token (ala SPF) so that the 
owner of that domain can approve it's use as a sender, and then from 
there, it's up to the receiving machine to determine how far to trust 
the sending machine. We should then focus on ways to both limit the 
damage a greyhat machine can cause before a server defines it as a 
black, and various mechanisms to allow the machine (and its admins) to 
define the white and black lists that suit its individual environs.
As far as things a server can do to non-trusted machines, I'd like to 
be able to configure it to do things like:
(a) restrict connections to every Ns -- you can't connect more often 
than this.
(b) restrict transfers to N every connection.

(c) strip content pieces from messages that we don't want to accept 
from untrusted hosts (I almost said 'unknown hosts', but I felt back 
into my own authentication trap. I know who you are, I simply don't 
know whether I can trust you)
and etc. The server connection negotiation should clearly define these 
rules for that connection, so the sending server can adjust itself 
accordingly. Imagine how nice it would be if my mailserver, the first 
time I connected to you, was told "no more than two connections in 
parallel, no more than one connection per hour, and no more than 30 
messages per connection". my system could then adjust it's processing 
to your request and self-regulate, so that over time, systems that 
exchange mail would do so in ways that don't waste resources or 
overload the inbound server.
finally, completely lost in the discussion so far are things like out 
of bounds communications (how does the receiving system tell the sender 
that something's up and they need to talk it over?) and things like 
bounce returns. While it's way too early to over-specify these things, 
we need them in the mix and understand how other decisions are 
affecting them?
Bounces are going to be a fascinating issue in this new environment. 
What if the bounce is returned from a non-SPF authorized machine? does 
it get accepted anyway? (loophole for spammers. all spam are now 
bounces). Can a returning site simply say 'we don't care about bounces' 
and not accept them at all? Do bounces serve a useful purpose any more? 
Do they include message content, or are they considered out of band 
meta messages at the server-server level? does the sender or receiver 
site define a bounce policy? how is that policy transmitted?
anything we define needs to deal with these issues...