Re: Why are we here? What are our goals?

> 	-- internationalization, esp. of addresses
> 	-- enhanced tracing mechanisms
> 	-- generalized challenge/response mechanisms
> 	-- transport-level authentication
> 	-- binary transport  (phasing out C-T-E's)
> 	-- Cleaner separation of header, envelope, and body
> 	-- structured local-part syntax
> 	-- economic mechanisms (postage, attention bonds)

I agree with some (maybe most) of these.  I would add

- improving reliability
- improving transparency of the MTS (which is a broader topic than 
  binary transport)
- improving error reporting (see below)
- clean separation between submission and relaying
- reducing reliance on store-and-forward
- better support for "integration" between various messaging services
- improve configuration (for both users and admins) so it is less error-prone

on error reporting:

In my view Internet email has always had a fairly fundamental problem in
that errors (implementation errors,  configuration errors, network
failures) tend to get detected at a point where the person who learns
about the error is powerless to do anything about it,  Furthermore when
email errors occur they tend to block the very channels you'd like to
use to report those errors.  So if we were to design a new email system I
think we should pay close attention to how error reporting works.


--
He not busy being born, is busy dying.		- Bob Dylan