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
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 -
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
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
Paul VPOP3 - Internet Email Server/Gateway