Re: operator-visible goals?

> > - mail system operators want the mail system to be easy to configure
> 
> This looks _very_ implementation specific (hint: compare today's 
> mail system).

In today's mail system it might be implementation specific.  In a 
hypothetical future mail system it might be less implementation
specific. 

> > - mail system operators want a way to verify and test configurations 
> > before making them "live"
> 
> That's also an implementation detail, e.g. like sendmail -bt option.
> This is usually not a property of the protocol.

Sendmail's design is what, almost 25 years old now?  Should we really 
use what sendmail does as a scoping principle for a new protocol?
 
IMHO, it is reasonable to consider making configuration management
(including testing and verification) an inherent part of the protocol
design - at least to some extent.  Do you want mail to work reliably 
or not?
 
> I'd propose to leave this for the moment and once we begin to define
> a protocol we could also define test modes which every MTA is
> required to support.

again, I'm just collecting goals now - nobody should be insisting
that we try to satisfy all of these goals.

> > - mail system operators want the mail system to run efficiently and 
> > economically, without requiring substantial CPU resources, network 
> > bandwidth, etc. for the number of users served or messages handled
> 
> That's both an implementation question and a protocol property, but
> difficult to handle.

It does affect the protocol design.

> You certainly will not get the needed bandwith lower than the length 
> of the messages. But yes, I can remember a problem which I saw
> some time with outlook: A company had an outer office connected with 
> a leased line. They complained because sometimes it happend that the
> office is unavailable for 20 minutes. Deep analysis revealed that 
> the human resources department was sometimes sending large e-mails 
> to every employee and Outlook was sending e-mails one by one.
> The leased line took 20 minutes to transport them all.
> 
> So as a requirement we could state that the protocol should 
> come close to the absolute minimum needed to transmit the message
> itself:

It's way too early to try to nail down requirements.
 
> > - mail system operators want the ability to continue operating the mail 
> > system in the presence of various failures
> 
> Mmmh. Also looks like an implementation detail.

It does affect the protocol design.

> > - mail system operators want a uniform and effective interface for 
> > problem reporting by users
> 
> IMHO that's beyond the scope. Have a website with a form for complaints.

We need to have a scope discussion before too long.  We're going to have
to limit what we try to do if we hope to be successful.  But I think it's 
a bit premature to start discarding goals just yet.

It would be much easier to process complaints if there were  a standard
protocol for representing them.  Imagine a "press here to report abusive
mail" button on mail user agents.