- 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.