Re: a few short notes

On Feb 1, 2004, at 1:12 PM, Paul Smith wrote:

> I'd say that mandatory user -> server authentication is vital (I can't 
> see any reason NOT to have it, and it certainly removes/reduces the 
> need to have other authentication methods - eg IP address filtering - 
> which can cause problems)
There has to be a chain of trust from creation of message to final 
reading. If anywhere you lose that chain, you have the current state of 
e-mail, because wherever that chain is broken, the spammers will find 
it and use it to inject their own stuff in the way they want to inject 
it. That means whatever person/agent creates the mail has to be 
unambiguously known to the server that accepts that mail, and that 
server has to validate that authorization to whoever it hands the 
message to, and that authorization has to be passed on however many 
times until reception. If you ever break that, it's over.
that's why I don't want anoymous operations at the mail-ng level. It's 
fine at a higher level, because what that really means is there's a 
server somewhere that says "I know who he is, I tell you he's okay, but 
I won't tell you who he is" -- and as long as I accept the judugement 
of that server, that's okay (or I reject mail from that remailer 
because I don't trust it, my choice). If you lower that into the 
transport layer, you have grave issues of keeping that chain of trusts 
alive. And as soon as it breaks, you have a hole the spammers will 
lose.
It's also why I'm against global authorization services, because those 
become single points of failure for these chains of trust.
The reality is -- I don't have to know the person who sent the mail or 
the server they live on to accept an email. But I have to know that the 
information identifying that mail is correct so that I can use it to 
decide whether to accept it, which means each link in the chain of 
transfers has to be trusted in maintaining that information is correct.
In the current system, that's not true, and that's the root of the 
failures of SMTP.