Re: operator-visible goals?

On Sat, Feb 07, 2004 Keith Moore wrote:

> feel free to rephrase them as problem definition or (user- or operator-
> visible) goals.


OK...




> - mail system operators want the mail system to be easy to configure

This looks _very_ implementation specific (hint: compare today's 
mail system).

How to we turn this into a protocol specific goal?

We could try to design the protocol such that mail systems will 
need as little configuration as possible. We can furthermore 
try to design the system such that mail relaying, forwarding, 
routing, relaying etc. can be done through one unified mechanism. 
If we give examples or defined a standard for configuration, 
operators won't need to learn too many details for several
implementation. 

We should learn from the flaws of former protocols and avoid 
monsters like sendmail. Third edition of Allman/Costales, 
Sendmail, O'Reilly has 1180 pages. 

We should write a protocol which allows a full featured MTA 
with a manual of not more than 100 pages.





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

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.

Maybe we could try to allow something like "traceroute" on the mail 
layer. 





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

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:

- avoid duplicate transmission (IHAVE-mechanism)
- when transmitting the same message to different recipients
  at the same MTA, transmit once (like today's SMTP can do) with 
  many envelope recipients
- Try to reject rejected messages as early as possible
- support compression

and:

- Try to cope with low bandwith connections. E.g. when on the road
  with the notebook and mobile, allow to download only high priority
  messages smaller than a given size. The protocol should allow to 
  query messages with a filter, so that the sending MTA is offering
  only the wanted messages. 

- The mailers should be able to survive even under heavy CPU or
  network load. Small and important messages should be handled with
  higher priority. 

- Just an idea: What about beeing able to download the plaintext
  part only and the large attachments later when back to a 
  fast connection? We need to deal with low bandwith connections such 
  as GPRS, UMTS, Modem,...

- We should depend on other services only where needed. E.g. 
  we should try to depend as little as possible from DNS.

  








> - mail system operators want the mail system to be secure, in that they 
> can control access to it and that attempts at unauthorized use (a) fail 
> and (b) do not significantly impact operation of the mail system or 
> supporting infrastructure

What is "unauthorized" and what is "use"? 

We should try to make authentication and authorization methods
part of the protocol and try to detect attacks, unauthorized relaying 
etc. as early as possible. The decision whether to accept a message
should be made as early as possible and block further transmission. 







> - mail system operators want reliable fault detection

That's a good point. Maybe add "fault tolerance".

E.g. do not delete a message after delivery, but when the receipt 
came back from the receiver.




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

If I reconsider the problems I had as a mail admin within the last
years I'd say:

- allow one-shot-delivery of a chosen e-mail even if mail spool is
  full of undeliverable mails

- ease of control of the message queue and comfortable ways to 
  take messages out of the queue and put them back again.






> - mail system operators want effective tracing and logging to aid in 
> problem diagnosis

Veeery important. :-) 

We should take much care about this. We should also define a 
common log format for all MTA's, to make it easy to read them and to 
find the entries for a particular message in all involved MTAs. 
There should be a very simple query method/language to search for
log entries. 





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




> - network operators want a mail system that uses their networks 
> efficiently

See above.

Proposal: POP clients usually waste a lot of bandwith with 
querying for new messages. What about this: I'd propose to replace
POP with the pull version of the protocoll. When the client authorizes
to the server for the first time, it can register for mail
notifications.

When new messages come in or if messages are not fetched in time, the
server could notify the client with a single UDP packet. This could
eliminate a lot of bandwidth waste. 

SMNP = Simple Message Notification Protocol  :-)




> - network operators want a mail system that doesn't compromise the 
> security or operational integrity of their networks

Under UNIX we should give up the need for beeing root. Current
mail systems suffer from the need to be able to deliver to local
recipients. 

It should be possible to run an MTA in a closed sandbox, chrooted and 
with any userid. 

Maybe we should even allow to put the MTA on an arbitrary port by
localizing it with DNS SRV records. If you run MTA's for different 
domains or recipients, you can run several completely independent 
instances instead of a big one which handles them all. Could be
a big advantage for security and easy of configuration.

In principle, it should be no problem to run a full featured 
MTA as a java program in the java sandbox.


regards
Hadmut