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

On Feb 1, 2004, at 7:10 AM, Paul Smith wrote:

> > 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....
agreed, and there are a lot of broken email systems out there. But the 
real point is showing the subtle impacts of legacy decisions from a 
time where life was a lot smaller and simpler. email-ng is a chance to 
toss all of that out and I think part of the committment here is to try 
to avoid replacing old joys like ">From" issues with new joys that 
those that come after us will remember us fondly for. We won't be able 
to do that perfectly, obviously, but anything that is avoidable should 
be.
> 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.
No, but the point is, XML is a way to distribute that information in a 
way that is unambiguous (you can't mistake a header for a body, you 
can't mistake a subject line with a from line, you don't need to worry 
about line-length issues, etc, etc, ad nauseum) and which guarantees 
well-formed-ness, which significantly simplifies managing and 
processing those headers. Plus, there are zillions of tools that can be 
used to generate, read and process XML, and unless there's a really 
good reason to re-invent teh wheel, I think it's a fine idea to take 
advantage of what others have already done and not have to write custom 
tools. That also makes it easier to convince others to adopt the 
protocols, because the toolsmithing to adopt it is easier because it's 
based on existing tools, and it's easier to actually build them because 
it requires fewer new skills to be learned for those doing the 
toolsmithing.
> Because this assumes you have access to libraries which work on your 
> system which support parsing/creating XML.
as opposed to access to custom libraries that only exist/work for 
email-ng?
> 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?
so you write a mini-XML parser specifically aimed at what you need to 
handle this task. But my answer is still yes. and I think that issue is 
really a strawman, given what mobile technology looks like today (looks 
at his P800 with embedded iMap client fondly). If they can implement 
iMap in a modern phone, this is a non-issue. and they have. and if it 
is an issue, then many of the other technologies under discussion 
(network traffic encryption, PKI infrastructures, authentication 
systems, etc) kill it as well, since those are a lot more resource 
intensive than the XML library is. It's the least of the worries here.
> > > 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.
well, no, it's not worthless -- if you call up the agency to validate 
that the ID is valid. BOTH the blood sample and the driver's license 
are equal authenticators; it's the validating agency you bring in 
that's the key. What you use to authenticate is secondary to having 
some way to authorize and validate it.
and I get tired of pricking my finger...

> 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.
Central authorization isn't reliable or particularly wanted -- but once 
you have authentication, you can start building your own repository of 
authentications, and that's the point.
Think about this analogy. if you run a business, people hand you IDs. 
Depending on the ID, you might run it past Visa or MasterCard or Amex  
for verification, but over time, you also build your own pool of 
identification. That's the model we should take here, the ability to 
build a local information pool of ID/trust (or non-trust, as in "don't 
take that person's check under any cirucmstances, he's bounced four 
already") and then reaching out to some set of services you (as admin) 
decide to trust. There should be no *requirement* of trust of any 
*specific* authorization system built into the system, but instead a 
protocol to allow interfacing to those systems based on what the 
administration feels useful.
And that also allows a site to choose no authentication, where global 
systems woudln't. Let's not make an assumption we know what everyone is 
going to want, because we won't. Instead, build in the tools to allow 
flexible systems.