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

At 03:56 31/01/2004, Chuq Von Rospach wrote:
>>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 "^\.")

If that deceives a mail system, then the mail system is broken and needs 
fixing.... XML encapsulation won't be compatible with mbox format anyway 
(AIUI) so you can't say 'you can't fix mbox format mail systems because 
they have to use mbox format for other reasons' as an excuse to change to XML.

However, thinking about it a bit more, I can see reasons for XML -
<header>
<to><name>fred bloggs</name><address>[email protected]</address></to>
<to><address>[email protected]</address><name>Jim 
Smith</name><comment>Director</comment></to>
...
</header>
would be more useful than the many ways to encode a To: field at the 
moment, but that's about the only reason that I can come up with. The added 
complexity of XML parsing & generation, and the data overhead may or may 
not be worth it, IMHO, there are almost definitely non-XML ways of doing this.

>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?

Because this assumes you have access to libraries which work on your system 
which support parsing/creating XML. Let's assume you're writing a mailing 
system for a hardware device with a limited amount of RAM & ROM, and you 
only have assembler and C (if you're lucky) to use, would you still want XML?

>>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...

Exactly, that's my point. It's a certificate, it's useless. If you said, 
'take a blood sample, ring the 'DNA registry' number you can find in the 
phone directory and check I'm who I say I am', then I'd be more sure of 
what's going on.

No, I still wouldn't know you were an axe murderer, but I'd know I could 
identify you accurately to the police if you turned out to be one - hence 
you're less likely to be an axe murderer (if you were, you wouldn't have 
identified yourself to me so reliably)

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

Yes, but I think authentication is relatively possible, central 
authorization isn't, without a big registry, local authorization is quite 
straightforward once you have reliable authentication.

>>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.

How. If you give me a certificate, I have to go off and validate it. This 
is almost certainly going to be at least as 'expensive' as a DNS lookup... 
The sending mail server doesn't get any more data throughput, just the 
receiver. If it cuts out spam, then there'll be lots of spare capacity to 
do that..


Paul				VPOP3 - Internet Email Server/Gateway
[email protected]			http://www.pscs.co.uk/