a few short notes

[As the traffic for this list is significant and there are lots of 
things I want to respond to, I'm responding to several points in a 
single message.]

XML for headers: this is a *very* bad idea. I guess it is sometimes 
appropriate to use something as heavy as XML for the content, which is 
generated once and decoded once, but using this encoding that is 
expensive to manipulate and hard to implement efficiently at 
intermediate hops makes no sense.

I'm not convinced that using non-ASCII characters in headers is a good 
idea either. Headers must be simple and unambiguous. Having text in 
them that your computer can't even display and if it can, 99% of the 
world population can't spell, isn't a good idea.

Maybe it makes sense to have different types of headers: ones that are 
relevant to the sender and recipient only, so they can be in any 
format, and others that must be more general so they must be in ASCII.

Mandatory authentication is also a bad idea IMO. Obviously 
authentication is very important and must be supported so that people 
who only want to receive mail from verifyable sources get to implement 
this policy, but that doesn't mean that we should force *everyone* to 
use such a policy.

Chris Bonatti had something to say about multicast. Obviously this is 
something that applies to mailinglist rather than one-to-one messages. 
See http://www.muada.com/projects/usenet.txt for something like this 
but different that I think would work over a reliable multicast 
transport protocol.

Important point: as long as email is a store and forward mechanism, 
encrypting the transport makes little sense: encryption should be 
end-to-end.

Someone made the point that it is hard / impossible to negotiate 
parameters across multiple hops. I see no reason why this should be the 
case if we create a new kind of message: the control message. If we 
accept that the delivery of one message containing actual content may 
require several control messages to flow back and forth between the 
source and the destination, then this is no problem at all. Obviously 
this is more expensive in terms of transaction overhead and bandwidth 
(and it takes longer) but if this leads to less spam, worms and bounces 
for messages I never sent in the first place, I can certainly live with 
that.