Re: What I see as problems to solve ... and a strawman solution

On Jan 30, 2004, at 4:47 AM, Paul Smith wrote:

> No. I don't like XML when it's not needed.
> I would see this as overcomplicating. Personally I don't have much of 
> a problem with header formats, envelopes, and header/body separation 
> at the moment.

functional, well-formed, and unambiguous.

> The header: data structure in the header and the blank line separating 
> header and message content is pretty straight forward to parse and is 
> unambiguous.

no, it's not, really. Because you can embed a header in the message 
part of a footer, in a way that many mail systems (mbox format stuff) 
will be deceived. That's why "^From" is modified to "^>From", which is 
one of the big issues of transparency in current SMTP implementations 
(the other biggie being "^\.")

And anyway, why build a custom format that needs custom code to decode, 
when you can use an existing system that allows for existing tools to 
do the packing and unpacking?

> No, don't have certificates. They either need to be signed by a few 
> agencies or they can be easily forged. They also add complexity.

If I hand you my driver's license, does that prove I'm not an axe 
murderer? No, it only means you know who the name of your killer was, 
assuming it's not a fake. and you won't be talking...

(authentication is not authorization. authentication without 
authorization is useless. please repeat my mantra with me...)

> Simply have some sort of callback. Eg I get a connection from someone 
> claiming to be 'mail.aol.com'. I do a DNS lookup and see that 
> 'mail.aol.com' really does resolve to the IP address of the person 
> who's talking to me. I think that's enough really. It's pretty hard to 
> fake, and gives traceability.

except it's not that simple. That lookup would kill most corporate mail 
systems. instead, SPF, which has been mentioned on this list.