On 4/2/20 8:23 PM, Grant Edwards wrote:
It's very powerful but the configuration file format is almost
impossible to understand, so people developed an m4 application that
accepted a _slightly_ less cryptic language and generated the
sendmail configuration file.
The configuration file is far from impossible to understand.
Calling it a configuration file is sort of a misnomer in that it's more
of a programing language than a configuration file. Some have even said
that it's Turning complete.
It does have some things going against it though.
1) It is highly dependent on the tab character (one or more) being used
to separate two parts of specific lines. This is easily visually lost
as well as frequently lost with bad copy & paste. But it's trivial to
know about and correct. (Compare that to Python that has lost all of
it's leading white space.)
2) The "config" file is really multiple sub-routine that are called in
specific instances and do very specific things. You must know which one
you need to use when.
3) Sendmail's logic is different than what most people are used to.
It's not quite RPN. But it's different enough that many people have
problems with it. I think it's more like relay logic. Each line in a
rule-set has an opportunity to apply to the current working space. Each
line can modify the working space, possibly directly or indirectly by
calling other things. If you aren't careful, the working set can be
inadvertently matched by multiple lines (rules). As such, the working
set is specifically modified so that other lines don't match if they
should not. There is a lot of pattern manipulation to keep track of and
it takes practice.
I'm sure that there are others. But those are the big ones that come to
mind at the moment.
At it's peak back in the early 90's there were approximately five
people in the world who actually understood sendmail, and none of
them ever worked where you did.
I don't know about the '90s, but I do know that in the '00s and '10s,
your statement is exaggeration to the point of being hyperbole.
I have witnessed an active Sendmail support community for about 15 of
the last 20 years. Most of that support was via the comp.mail.sendmail
newsgroup.
The rest of us stumbled in the dark using the finely honed
cargo-cult practices cutting and pasting random snippets out of
example configurations to see what happened.
Your lack of use of resources doesn't mean that said resources wasn't
available.
Usually what happed is that mail was lost or flew around in a loop
multiplying to the point where a disk parition filled up.
Yep.
That said, sendmail has features that no other MTA has. For
example, it can transfer mail using all sorts of different protocols
that nobody uses these days.
It's not just (on the wire) protocols that sendmail supports. Many of
which are effectively obsolete save for specific microcosms. Sendmail
also supports interfacing with other programs in a very flexible manner.
It is fairly easy to have Sendmail support Mailman (et al.) in such a
way as that you don't need to change anything on the email server when
adding or removing mailing lists. No, I'm not talking about automated
alias generation. There is no need for alias generation when Sendmail
and Mailman are connected properly.
Sendmail quite happily supports LMTP into local mail stores / programs.
This is quite handy when you want something like a recipient's sive
filter to be able to reject a message.
Back in the 90's a number of replacement MTAs were developed such as
qmail, postfix, exim, etc. When you installed one of these, (instead
of the classic sendmail), they would usually provide an executable
file named "sendmail" that accepted the same command line arguments
and input format that the original did. That allowed applications who
wanted to send email to remain ignorant about exactly what MTA was
installed.
Yep. The "sendmail" command has become a de facto industry standard
that most MTAs emulate.
--
Grant. . . .
unix || die
