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

On Fri, Jan 30, 2004 at 12:35:00PM +0200, Kai Henningsen wrote:

> 2. Define an XML format for headers and envelopes. No non-XML sub-encoding  
> - every piece of information and structure must be basic XML. There's  
> enough there so other tricks just aren't necessary. (And namespaces seem  
> of doubtful use in this context.) This also allows for defining better  
> semantics for headers, as appropriate. Oh, and inside this thing, charset  
> MUST be UTF-8 period.

Indeed. In fact, it also becomes easier to extend the protocol as well, 
encouraging growth, innovation and improved services. In effect, do to SMTP 
what Web Services did to HTTP - make it incredibly useful in a wide range of 
contexts. Plus, if we were to say, model it on something like SOAP where the 
Objects are Mail articles, we already have many of the tools already 
required to build it. In fact, we could even deploy it over the web... no, 
now I'm being silly. :-) Or am I - is what we want the ability to securely 
pass messages around, and do we care which port it goes over? What if 
everybody becomes a mail server, and is able to quickly receive e-mail from 
anywhere, destined for them?
 
> * Binary transport, of course. BDAT?

Don't know what it is, but will educate myself over the weekend. I agree 
that 7-bit restrictions are silly.

> * Use the new XML envelope instead of the old SMTP commands. Possibly  
> transmit envelope for inspection first and allow abort of mail at that  
> point.

That envelope can also have other useful data in it, like a sender-signed 
md5 hash of the mail to make sure things aren't being changed along route. 
That kind of thing - you could extend the envelope into something quite 
useful without breaking too many things.

> * every sending MTA *must* have at least one certificate, and this  
> certificate MUST be interrogated by the receiving MTA and noted into a  
> trace header. Possibly even demand TLS-only, but I'm less convinced of  
> that.

This is good, but I think it's best that a PKI approach is used.

> * those certs really should be verifyable by the receiver - possibly via  
> something in DNS; definitively not by following the browser model and  
> effectively forcing every cert to be signed by a very few agencies like  
> Verisign.

Yes, PKI, definitely. I can create and send out a certificate for my server
without having to hand cash over to the inner cabal, and you can check it
really is me. You can take a mail that has been signed, and work out which
server sent it. It does not require a central agency, but instead a
distributed key infrastructure. I'm not sure if DNS is the best method for
this, but I expect so.

> * Probably a relaying MTA really ought to sign the trace info it  
> generates.

Yes.

> * Absolute prohibition on modifying anything except the envelope, except  
> by prior explicit agreement. (That is, a business' MTA might put these  
> stupid "this email is for you only if it really is for you" things into  
> mail it sends, but a standard transit MTA does absolutely nothing to the  
> mail proper. The common desire to not expose net internals can still be  
> done as that's now in the envelope. On-the-fly content recodings are no  
> longer needed. And signatures of the *entire* non-envelope part remain  
> valid.)

Agreed. However, we could incorporate something into the envelope that gets 
rid of the "this mail is only for you..." stuff by putting in there either a 
machine-verifiable policy, or even just a URL to the policy that applies to 
the mail. Personally, I think putting something into the bottom of a mail 
telling you shouldn't have read it is... well... pointless.

> * hopefully, a much stricter definition of the trace format.

Agreed. With an XML Schema, that shouldn't be hard.

> I think that's all of the model I had thought out. Well, except for one  
> thing: it might be prudent to decide on a preferred non-plain text format,  
> and that probably should not be HTML but a format that does structure, not  
> optics. Possibly some variant of Docbook might do.

Maybe. Plain-text has it's advantages, and I'm not keen on HTML - I'm a man 
of content rather than presentation - but I can see that people like me are 
falling into the minority on the web, and anything that stops 
multipart-MIMEing of HTML has got to be a good thing.

-- 
Paul Robinson