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.