Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!rutgers!ucsd!ucbvax!TWG.COM!dcrocker
From: dcrocker@TWG.COM (Dave Crocker)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Email server alternative
Message-ID: <8811211348.AA20322@ucbvax.Berkeley.EDU>
Date: 14 Nov 88 19:37:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 34

Perhaps my previous note was a bit too brief.  Its intent was to inform
the community of a mail transport system, for Unix, which was built with
considerable attention to issues of management (scaling and analysis) and
security.  I don't know enough details about sendmail to engage in a
comparison, so the comments are only about MMDF.  (For that matter, I
have not dealt with the MMDF code in detail since I left UDel in '82, so
there may be features added that I have not heard of.)

The system operates off of a single queue, with a "view" of sub-sets, using
sub-directories, for different destination networks/channels.  This gives
very good scaling as the queue grows.

Mail is added to the queue through a submission process which interacts with
the user's interactive agent.  The user agent runs under the user's id.  The
submission process runs under MMDF's separate id.  Most other MMDF processes
run under this un-privilged id.  The local delivery channel starts as
superuser, of course, but it does a setuid to the receiver as soon as it
can.  In particular, any receiver-controlled programs, such as one which
does automatic replies when you are away from the office, run under the
id of that recipient, rather than of MMDF.

During submission, messages are inspected for conformance to various rules,
such as having an authentic From or Sender field.  This can be overridden,
by "relay" accounts, in which case the mail is assumed to be coming from
another machine and to have gone through authentication, already, or else
the message is considered to be anonymous and a header message is attached,
indicating that From/Sender are not authenticated.

(On another list, there was a question about the legality of inspecting
headers -- i.e., reaching inside the envelope -- and there was fear that
this violated an RFC.  It does not, and it is done as part of the enforcement
policy that MMDF was designed to support.)

Dave