jordan@ucbarpa.Berkeley.EDU.UUCP (01/16/87)
Well, I think it's time once again to quell these nasties flying around
about what sendmail is and isn't; what it can do and what it can't.
Frankly, I'm kind of sick of seeing mis- or ill- informed people
passing on incorrect information and perpetuating a lack of
understanding. To wit,
Terry Poot <tp@ndmce.UUCP> writes:
If I had one that properly handled standard syntax, it'd still
mess up, because some sendmail site somewhere scribbled on the
From: line.
Notice the attack on "sendmail" rather than "novice sendmail
maintainer" ...? Just because sendmail is "hard" to understand and use
correctly doesn't mean that the program is responsible for some
haphazard site running a config file that is destroying headers beyond
usability. While it's certainly clear that sendmail has sufficient
power to destroy any header, make a note of the fact that there are
many sucessful configurations around doing really good things for
mail. A few of the better ones have been well documented and made
available. There's no reason if you have a reasonable network
situation that you can't find a cf file to suit your needs.
The reason I haven't installed sendmail is that I hear that the
munging of From: lines is unfixable without changing the
program (NOT the sendmail.cf).
"I hear" ... hmmm ... the From: line is directly managed with the
configuration file ... you "heard" wrong. The major problems people
run into with sendmail deal with their undertstanding of which rulesets
get called where, and what to do about being a gateway site.
I understand why people with LAN's use sendmail, but why does
anyone else use it?
Sendmail has been popular with sites who fall into one of two
categories:
1) As you say, have a LAN and want to use SMTP to deliver
the mail
2) Those with anything other than a straight network
connection. Certainly a UUCP-only site with 4 dialup
connections doesn't have a need for sendmail. If you're on
the Internet and UUCP or CSNET or BITNET or even have a
"UUCP gateway" machine to your local LAN, sendmail may be
for you.
smail has made my life much easier. It would be easier still
if nobody ran sendmail (the headers wouldn't be destroyed).
There are plenty of people out there who simply cannot (and due to
their network connections, shouldn't) stop running a complicated
mailer. When you speak of some of the major mail-handeling sites on
the net, you'll usually find them running sendmail, or at least MMDF
... try running a place like ucbvax which is a major UUCP hub, has a
local link to BITNET (via ucbjade), is on the ARPANet, has an extensive
dynamic local network (some of it registered with the NIC for the sake
of the MILNET foot-draggers, some of it not, thus requiring different
header syntaxes for different sites), is on CSNET, acts as a mailing
list gateway to USENET, etc. to run reasonably without lots of external
information.
Last I checked, ucbvax would be lost without sendmail. Also, one of
the sites I run, ames.arpa (aka !ames), would also be very much in the
dark without the features of sendmail.
[ a small comment here -- this is not meant to "sell" sendmail to you
all, just to point out that there are everyday real problems at
sites you all depend on for speedy service that require tools
that you haven't taken the time to understand (and, admitedly,
need not understand -- smail suits you just fine, and that's
terrific) ... please don't cry and whine about things you simply
don't have any experience with. ]
If sendmail can't be made to follow the standards, why doesn't
someone fix it, or write something better.
This is really classic stuff. Sendmail has the ability to follow more
standards (and has been made to do so) than anything I've ever seen.
Sendmail is still being worked on faithfully, and was written with the
expressed purpose of addressing (no pun intended) the needs of an
ever-changing standards-crazy Internetwork world. One need that it
really overlooked was that of a small UUCP-only site. This need has, I
think, been addressed (or at least are begining to be addressed) by
smail. As with all large software projects, there ae objections all
around, but it certainly can "do what you want it to do" in the same
way sendmail can do what I want it to.
/jordandiamant@hpfclp.HP.COM (John Diamant) (01/19/87)
> / jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) / 12:12 pm Jan 16, 1987 / > Well, I think it's time once again to quell these nasties flying around > about what sendmail is and isn't; what it can do and what it can't. > Frankly, I'm kind of sick of seeing mis- or ill- informed people > passing on incorrect information and perpetuating a lack of > understanding. To wit, > > Terry Poot <tp@ndmce.UUCP> writes: > > If I had one that properly handled standard syntax, it'd still > mess up, because some sendmail site somewhere scribbled on the > From: line. > > Notice the attack on "sendmail" rather than "novice sendmail > maintainer" ...? Just because sendmail is "hard" to understand and use > correctly doesn't mean that the program is responsible for some > haphazard site running a config file that is destroying headers beyond > usability. ... > > The reason I haven't installed sendmail is that I hear that the > munging of From: lines is unfixable without changing the > program (NOT the sendmail.cf). > > "I hear" ... hmmm ... the From: line is directly managed with the > configuration file ... you "heard" wrong. The major problems people > run into with sendmail deal with their undertstanding of which rulesets > get called where, and what to do about being a gateway site. Jordan, this is wrong. While it is true that you can make the From: line say anything you want, in the version of sendmail in 4.2BSD (the one our version is based on), the From_ line for UUCP and the From: line are derived from the same ruleset. Thus, if you are a UUCP and SMTP site, you have NO CHOICE but to munge one or the other header unless you use something like smail to fix what sendmail broke in the header. It is a mistaken assumption on sendmail's part that a From_ line is equivalent to a From: line (see RFC 976 for details). RFC 976 should be implementable with just sendmail, but it is not because of this problem. If you gateway mail from SMTP into UUCP, you MUST put your sitename on the From_ line, and you must NOT put it in the From: line. In fact, if you don't put your site (followed by "!") at the beginning of the address, sendmail will complain, because it cannot construct the >From (in particular, the "remote from" part). So you see, if you gateway from SMTP into UUCP using sendmail (without smail), you don't have any choice! The correct solution is a change to the sendmail source code -- namely the a separate ruleset must be made available for "ugly" From_ lines. > > If sendmail can't be made to follow the standards, why doesn't > someone fix it, or write something better. > > This is really classic stuff. Sendmail has the ability to follow more > standards (and has been made to do so) than anything I've ever seen. > Sendmail is still being worked on faithfully, and was written with the > expressed purpose of addressing (no pun intended) the needs of an > ever-changing standards-crazy Internetwork world. One need that it > really overlooked was that of a small UUCP-only site. This need has, I > think, been addressed (or at least are begining to be addressed) by > smail. As with all large software projects, there ae objections all > around, but it certainly can "do what you want it to do" in the same > way sendmail can do what I want it to. > > /jordan Don't get me wrong -- I think sendmail is a tremendous improvement over what can be done without it, but that doesn't make it above reproach. In fact, there were many good decisions made in the design of sendmail, and some bad ones. A couple bad ones that come to mind are: 1) That sendmail.cf was designed to be easy to parse by a computer, rather than by a person. With current parsing technology, it is almost trivial to make a readable format that would not have added much complexity to the sendmail code (using lex and yacc, for intance -- like Ease). 2) That ruleset bindings to headers should be configurable, or at least extensible without recompiling sendmail from source (since many people don't have source). John Diamant Systems Software Operation UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO
rpk@lmi-angel.UUCP (Bob Krajewski) (01/19/87)
I think that sendmail is a good thing, but...
* I'd like to see it be easier to share information with MX records and
pathalias data. There is usually a chunk of the local ``know-it-all''
sendmail.cf which dispatches on mailers based on what UUCP or Internet
routes offer for certain domains. This can be done either by extending
sendmail's matching techniques or having filters that generate crucial (yet
tedious) sections of ruleset zero from various files of routing information,
which are then #included in ruleset 0 or wherever appropriate.
* It would be nice if pseudo-domains were never used for routing, even
internally.
* The configuration files supplied in the distribution should NEVER think
they are at Berkeley. (At least that's the way is was in 4.2.)
--
Robert P. Krajewski
Internet/MIT: RPK@MC.LCS.MIT.EDU
UUCP: ...{cca,harvard,mit-eddie}!lmi-angel!rpktp@ndmce.uucp (Terry Poot) (01/20/87)
In article <16890@ucbvax.BERKELEY.EDU> jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) writes: > > [ Jordan's comment on my remark about sendmail messing up from lines] > >Notice the attack on "sendmail" rather than "novice sendmail >maintainer" ...? Just because sendmail is "hard" to understand and use >correctly doesn't mean that the program is responsible for some >haphazard site running a config file that is destroying headers beyond >usability. While it's certainly clear that sendmail has sufficient >power to destroy any header, make a note of the fact that there are >many sucessful configurations around doing really good things for >mail. A few of the better ones have been well documented and made >available. There's no reason if you have a reasonable network >situation that you can't find a cf file to suit your needs. I have seen 2 configuration packages posted to the net. I assume these are the ones you refer to. Why would a novice sendmail maintainer even dream of tackling a job like customizing something that involved, which he doesn't understand in the first place? Several of my neighboring sites run sendmail and muck up From: lines. Very little mail that I get has a useable From: line. Are most sendmail maintainers novices? Is there a decent configuration package (such as you mention) shipped with sendmail from Berkeley (which I assume is where 99% of them come from)? Why isn't it used. A quick scan of some mail in my mailbox shows from lines with the proper address prefixed by seismo!, sdcrdcf!, ihnp4! and uiucdcs!. I am not sure about the problem (whether it occured there or downstream), but does this mean that the configurations at these sites are poor? I hardly think the maintainers of these sites are novices. >This is really classic stuff. Sendmail has the ability to follow more >standards (and has been made to do so) than anything I've ever seen. Could you tell me where to get a sendmail.cf that properly handles From: lines. I'd like to look at it for my own edification. If it works with smail, I might even use it. I'd really like something to do header processing (to the degree it should be done). I also like other features of sendmail. I was really interested in bringing it up until I started hearing really bad things about it. It was not my attempt to spread any mis-information, and I'm sorry if I have done so. I just noticed that many of the smail gripes seemed to actually be sendmail problems. For instance, a major gripe was that the From: line could not be used for replies. This is because sendmail sites have been tacking sitename! to the front of the address in the From: line. This is incorrect by RFC822, and smail attempts to do it right, by bypassing sendmail whenever possible. Thus people have actually been complaining that smail does not exhibit a bug found in sendmail, or rather (thank you Jordan) in most sendmail configurations. It still seems to me that improper sendmail configurations (rather than sendmail itself, as I incorrectly stated) are at the root of these kinds of problems. If nobody prepended anything to the From: address, then the address would be perfectly acceptable to smail and useable for replies. This conflicts with existing practice by sites running sendmail, but it does follow the standards. Note that the current practice by sendmail sites does not apply to non-sendmail sites, so it is not possible to standardize on existing behaviour. Since we can't go that route, even if we wanted to, we should move forward as quickly as possible to making uucp mail conform to RFC822. I hope someone will post one of these high quality configuration packages that Jordan refers to, or publicize the whereabouts and usage of same if it is already easily available, so that 'novice sendmail maintainers' will be able to easily correct the header processing done by their system. I hope I have spread no more mis-information. I am sure someone will correct me if I said something wrong :-) -- Terry Poot, Nathan D. Maier Consulting Engineers, (214)739-4741 8800 N. Central Expressway, Suite 300, Dallas, Tx 75231, USA UUCP: { seismo | cbosgd | ihnp4 | sun!convex | allegra!convex }!ndmce!tp ARPA: ndmce!tp@seismo.css.gov CSNET: ndmce!tp@smu
rick@seismo.CSS.GOV (Rick Adams) (01/20/87)
Seismo "incorrectly" prepends seismo! to the From: line of outgoing uucp mail. This is technically wrong. However, the reason that we do it is simple. If we didn't, the vast majority of sites could not respond to the From: line. So, we do what works (welcome to the real world). If I had control over everyones mailer (e.g like the DDN NIC has over the arpanet mailers) I'd send correct From: lines. However, life isn't that simple. We do not prepend seismo! to arpanet and direct connection smail sites that we know can handle "real" 822 addresses. ---rick (Life is a continuing series of kludges)
woods@hao.UUCP (01/24/87)
In article <16890@ucbvax.BERKELEY.EDU> jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) writes: >Well, I think it's time once again to quell these nasties flying around >about what sendmail is and isn't; what it can do and what it can't. Good idea. It certainly does have advantages and disadvantages, and there are certain sites, like ours, that could not deliver all the mail we are expected to handle without it. However, there are some problems with it. <double-quoted article from Terry Poot, criticizing sendmail, deleted> >Notice the attack on "sendmail" rather than "novice sendmail >maintainer" ...? I must take issue with this and agree with Terry. Sendmail is next to IMPOSSIBLE to understand other than by using brute force trial and error if you have anything other than a trivial LAN setup. This MAKES 99% of the site admins using it into "novice sendmail maintainers". It takes MONTHS of playing with it to understand how the cf file really works. After nearly a year, I have FINALLY gotten it to deliver all the mail without creating infinite bouncing loops when a user types an address incorrectly. >There's no reason if you have a reasonable network >situation that you can't find a cf file to suit your needs. Bull. No one *I* know about has a "reasonable network situation" by this definition. Oh, sure, I have found most of the rewriting rules I need in various sendmail.cf files that ARE available, but NOWHERE is there any documentation on how to merge them into ONE file that I can use on each of my particular machines, NONE of which has exactly identical network connections. Even trying to use "ease", a cf file compiler, I have never been able to generate a sendmail.cf file that really works without ANY manual mods on my part. I gave up on it, because dealing with "ease" PLUS the manual mods needed after that was as much of a pain as making all the mods myself. And "ease" is not even an official part of sendmail. To be fair, the authors do mention in the sendmail writeup that the cf file was designed for easy parsing and not for easy reading and that there really ought to be a cf-file compiler, which means they are aware of some of the problems, but right now there ISN'T a cf compiler, and it is VERY difficult to generate a cf file that does what you need it to if you have anything beyond a single fully-connected LAN with one uucp host. >"I hear" ... hmmm ... the From: line is directly managed with the >configuration file ... you "heard" wrong. The major problems people >run into with sendmail deal with their undertstanding of which rulesets >get called where, and what to do about being a gateway site. On this one I have to agree with Jordan. Seldom is there any need to change the header definitions, and those sites which have chosen to do so are fully responsible for the consequences. Even in the messy setup (4 distinct LAN's and a uucp host) that we have here, I have never found a reason to mess with the header definitions. Of course, all machines on all our LAN's are the same domain, and so it looks like one big LAN to the outside world (which is exactly what I want). >There are plenty of people out there who simply cannot (and due to >their network connections, shouldn't) stop running a complicated >mailer. Agreed. We are one of them. Despite my complaints, I certainly wouldn't want to give up sendmail, because there just isn't anything else that works. We also run smail, for routing uucp messages and eliminating the need for our users to type the long paths, but that is merely a convenience; sendmail is a necessity. --Greg -- UUCP: {hplabs, seismo, nbires, noao}!hao!woods CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA INTERNET: woods@hao.ucar.edu