Path: utzoo!attcan!uunet!seismo!lll-tis!ati.tis.llnl.gov!bae
From: bae@ati.tis.llnl.gov (Hwa Jin Bae)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SendMail
Message-ID: <22208@tis.llnl.gov>
Date: 20 May 88 02:06:35 GMT
References: <8805180903.aa03398@CAD.USNA.MIL>
Sender: news@tis.llnl.gov
Reply-To: bae@ati.tis.llnl.gov (Hwa Jin Bae)
Organization: Lawrence Livermore National Laboratory, Livermore CA
Lines: 25

In article <8805180903.aa03398@CAD.USNA.MIL> tsmith@USNA.MIL ("Tim G. Smith", Mechanical) writes:
>We currently use MMDF as our mail handler but are in the process of
>switching to sendmail as sendmail seems to be emerging as the
>"standard" mail handler.
No offense.  But in my view MMDF has far better design than sendmail.  
I don't see why you would go from MMDF to sendmail.  The other way around
makes much more sense.  I guess I've actually lived long enough to 
hear someone say "I LIKE SENDMAIL!".  sendmail is a very sickening 
piece of software - overblown, unnecessarily complicated, 
huge Mo.Fo.  I don't know how you are using MMDF but it's
concept is closer to modern mail system models like X.400 where several
delivery mechanism can be handled transparently.  MMDF allows you to
have separate processes for mail delivery channels which can be totally
different.  One of the channels may be sendmail since it does implement
SMTP.  I would prefer to use simpler SMTP mailer though.  It's truely
incredible to see how a Simple Mail Tranfer Protocol can be implemented
in such Complex ways (as in sendmail), which tries to do too much.
I think I've work on sendmail code enough to know that it is the ultimate
example of the BSD mentality - 10 times more flexible but 100 bigger
and more complex.
-----
Hwa Jin Bae          | The Devil made me do it...yeah, that's right!
Control Data Corp.   | (415) 463 - 6865
4234 Hacienda Drive  | bae@tis.llnl.gov			   (Internet)
Pleasanton, CA 94566 | {ames,ihnp4,lll-crg}!lll-tis!bae    (UUCP)