Assistance with Sendmail.cf
Steve Nuchia
steve at nuchat.sccsi.com
Tue Feb 12 11:29:53 AEST 1991
In <BZS.91Feb10001054 at world.std.com> bzs at world.std.com (Barry Shein) writes:
>among Unix internet gateway mailers after all these years, by far. So
>we have to assume that either it isn't that bad, or no one can think
>of a better way to do this.
Or those of us who have thought of a better way (it isn't hard!) look at
sendmail.cf like a "weeder" CS class: it keeps those who don't need to
be there from mucking about with the mail system.
:-) <------ translation for the humor impaired.
Actually what happens is that by the time you understand enough to
be making non-trivial changes to sendmail configurations you realize that
the syntax is nowhere near the hardest part. It would be really nice
to have a more expressive language, and it would be even nicer to
have an MTA with a data flow graph that can be embedded -- accurately --
in a space having less than four dimensions.
I've only had my head completely wrapped around sendmail once, and
my client at the time had a taboo against rewriting system code, so
I just made it do what I needed it to do. If somebody wants a better
MTA and doesn't like smail3 or MMDF, and is willing to pay to have
it built, drop me a line. Otherwise you'll have to wait until the
next time I want sendmail to do something it doesn't want to do.
The fact that that condition doesn't arise very often is why nobody
has bothered to write the replacement. A textbook application of
``If it ain't broke, don't fix it.''
Go ahead, call me an elitist. It makes my head swell, and I
just love that. But I would rather have sendmail.cf change
requests get routed to my desk than have to write, debug, and
support a new mailer PLUS unfuck all the configuration files that
all the users have scrambled because they are no longer intimidated
by them.
Yes, I know the vendors send out paleolithic default configuration
files and there are people out there who just need their stupid
machine to work. The vendors should hire somebody who understands
sendmail, and the users would probably be happier with a simpler MTA.
Does smail3 solve the problem for most of those users? I honestly
don't know; I don't currently have any clients in that situation.
Just so that this little exercise in catharsis hits the streets
with some redeeming social value, here are some of my rewrite ideas:
1) the rewrite rule syntax should be based on ed(1) level or
better regular expressions, enhanced with appropriate
lexical concepts and state vector access.
2) great care should be exercised in the architectural specification
to ensure that processing steps are well defined, happen in
a well-defined sequence, and are either necessarily idempotent
or happen exactly once.
3) message routing, and hence rewriting, decisions must be made as
the message is drawn from the queue, rather than when it is
inserted. Otherwise changes to topolgy or policy will cause
garbling or stranding of messages.
3a) the message must be stored in its original form in the queue,
and any auxilliary data structures (e.g. recipient lists) must
be carefully designed to allow proper control of rewriting.
4) routing policy should be expressed in a well-thought-out language
with provisions for fallback, prioritization, and other goodies.
5) the rewrite rules should be organized around the processing phases and
must clearly distinguish the various contexts (sender, recipient,
from, to, etc) in which an address string might appear.
6) all of the implicit lexical and specialized syntactic processing
hidden inside sendmail must be moved out to the configuration scripts.
7) the new program must subsume all known functions of sendmail, unless
some are determined to be inappropriate for an MTA.
Just figuring out what sendmail really does with a message is a big job.
--
Steve Nuchia South Coast Computing Services (713) 964-2462
"Innocence is a splendid thing, only it has the misfortune
not to keep very well and to be easily misled."
--- Immanuel Kant, Groundwork of the Metaphysic of Morals
More information about the Comp.unix.wizards
mailing list