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