NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/3b1/4170

Internet Message Format | 1993-01-05 | 4.7 KB

Xref: sparky comp.sys.3b1:4170 comp.mail.misc:4246
Newsgroups: comp.sys.3b1,comp.mail.misc
Path: sparky!uunet!wupost!cs.utexas.edu!torn!utzoo!censor!becker!bdb
From: [e-mail] (Bruce Becker)
Subject: Re: Sendmail problem on AT&T unix 7300 (3b1).
Message-ID: <[e-mail]>
Organization: G. T. S., Toronto, Ontario
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Jan 1993 03:34:57 GMT
Lines: 106

In article <[e-mail]> [e-mail] (Bruce Lilly) writes:
|In article <[e-mail]>,
| posted to comp.sys.3b1,comp.mail.misc,
| [e-mail] (Elliot B Dierksen) wrote:
|>
|>I don't mean to start a religious war here, but why do you think smail is
|>inferior?
|
|Two reasons come immediately to mind:
|1)    reliability. Based on my own experience, the experiences of
|    neighboring sites, and on bounced and misdirected mail which I've
|    seen, I'd have to say that sendmail is at least an order of
|    magnitude more reliable than smail. As sendmail is the MTA of choice
|    at the vast majority of site that handle email, I suspect that I'm
|    not the only person who feels that way.


    Somehow I think you've got the order of magnitude
    the wrong way around.  The main reason sendmail
    is so pervasive is that it is the MTA that was
    always included with TCP/IP source from the
    BSD Unix distribution as the method to include
    SMTP email service.  It has a long history,
    so it's not surprising it's seen everywhere.


    Smail 3.1 was designed to be a plug-and-play
    replacement for sendmail, and with certain
    caveats it does this surprisingly well.  Those
    who install it to replace sendmail usually
    stick with it because it is so much more
    manageable


|2)    programmability. The same reason that I prefer a shell over a GUI.
|    The same feature that makes awk, sed, perl, etc. useful tools. As
|    new RFCs are released and new addressing formats are introduced,
|    sendmail can accommodate the vast majority of the changes without
|    the need to modify source code, recompile, reassemble, relink, test,
|    re-modify,... ad nauseum; a test version of sendmail.cf can be set
|    up, it's processing tested off-line from regular email processing,
|    and the new version istalled after testing without even the need for
|    access to source code, compilers, etc.


    You're clearly not very familiar with smail 3.1
    if you say all this as if smail 3.1 was somehow
    different in this regard.


    Another point is that smail 3.1 implements the
    RFC's correctly, and it's usually hard to mess
    up that part by the hapless admin trying to get
    it configures - however it's really easy to
    screw up standards-wise with sendmail, and all
    those ambiguities that are imperfectly coded
    in any given sendmail.cf produce horrible routing
    snafus for poor mail admins to tear their hair
    about


|> I have read the documentation for sendmail, consider myself fairly
|>computer literate, and sendmail.cf's still make blood run out of my ears!
|
|Why is that?  sendmail.cf is a very simple file format. There are only a few
|types of lines, distinguished by the first character. The rewriting rules
|use a fairly simple pattern matching and substitution language, not unlike
|that used by ed, awk, etc., the biggest difference being that when dealing
|with email addresses, one is interested in matching tokens, not just
|character string patterns.
|
|Granted, it is possible to design an incomprehensible sendmail.cf, and I
|have seen a few that were pretty obtuse, but it is also possible to have a
|sendmail.cf which is easily understood.
|
|Moreover, sendmail.cf was designed to be easily parsed by machine. It is not
|necessary for a casual administrator to be fluent in the details of the
|format; the recommended method of generating a sendmail.cf for a specific
|site is to use the m4 macro processor to customize a generic version for
|the site's needs. There are also programs available that convert to/from
|sendmail.cf format.


    However the need to understand the semantics
    does not go away when such tools are used.
    BOTH the syntax AND the semantics are bizarre.


    If it was so easy then all those sendmail.cf
    implementations that are sent out with so many
    Unix implementations would not be so broken,
    and in such inconsistent ways (and so painful
    to fix too).


    I suppose one could say that sendmail syntax
    is like assembler, i.e. powerful enough to
    create real problems in the hands of the
    desparate  8^)


--
  ,u,     Bruce Becker            Toronto, Ontario
a /i/     Internet: [e-mail]    Uucp: ...!web!becker!bdb
 `\o\-e  "...symbolising Excitement and Fun."
 _< /_        -- Disneyland North investment brochure