chip@tct.com (Chip Salzenberg) (04/17/91)
According to barnett@crdgw1.ge.com: >In article <2801C2BB.29BD@tct.com> chip@tct.com (Chip Salzenberg) writes: >>> user@XYZ.com.user@anything.arpa >> >>I am slack-jawed with amazement that any postmaster would jump through >>hoops to fix an address so badly broken, instead of telling the people >>in charge of domain XYZ to get a life. Er, a mailer. > >First of all, we all work for the same company. My condolences. >Second [...] nor do I want to maintain a single sendmail.cf file for >every possible variation of Unix that might be out there. That actually might be a reasonable possibility, I should think -- especially if the sendmail.cf in question is a simplified one such as was recently posted by Ying-Da Lee. >Third, the expertise required to send up a properly configured mail >system is not something you can learn by reading the vendor's manuals. Of course. :-( >Fourth, some sites don't even have "system managers". I consider >myself lucky if I find someone willing to fix the problems that exist. Sounds like the real problem is one of staffing. As such, any technical solution is bound to be nothing more than a band-aid. -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>
barnett@grymoire.crd.ge.com (Bruce Barnett) (04/17/91)
In article <280B6561.7A2@tct.com> chip@tct.com (Chip Salzenberg) writes: > >Second [...] nor do I want to maintain a single sendmail.cf file for > >every possible variation of Unix that might be out there. > > That actually might be a reasonable possibility, I should think -- > especially if the sendmail.cf in question is a simplified one such as > was recently posted by Ying-Da Lee. Only if all machines use the name type of name system. (YP, DNS, Bind, /etc/hosts). Not likely. It is not possible to use the same sendmail.cf file on every machine in this building, let alone use the same one at hundreds of different sites. Supporting sendmail on a dozen different operating systems is not something I want to commit too. > >Fourth, some sites don't even have "system managers". I consider > >myself lucky if I find someone willing to fix the problems that exist. > Sounds like the real problem is one of staffing. As such, any > technical solution is bound to be nothing more than a band-aid. I agree. But if I can spend 30 seconds to fix something in a sendmail rule, and if it makes the problem go AWAY, then it makes a lot of sense to me. I can't solve other sites problems, but I can solve my own with sendmail. Yes - it's a band-aid. Better a band-aid than letting someone bleed to death all over my carpet. :-) -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
ylee@csl.dl.nec.com (Ying-Da Lee) (04/19/91)
In article <BARNETT.91Apr17102450@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: >In article <280B6561.7A2@tct.com> chip@tct.com (Chip Salzenberg) writes: >> >Second [...] nor do I want to maintain a single sendmail.cf file for >> >every possible variation of Unix that might be out there. >> >> That actually might be a reasonable possibility, I should think -- >> especially if the sendmail.cf in question is a simplified one such as >> was recently posted by Ying-Da Lee. One important clarification: I didn't include the whole sendmail.cf in my previous posting, only two sections, the macro definitions and Ruleset 3. The purpose of including those sections was to ask for comments on its adequacy or inadequacy in documentation, so please do. >Only if all machines use the name type of name system. (YP, DNS, Bind, >/etc/hosts). Not likely. Well actually, we got it running in four separate locations; on various versions of SunOS, Ultrix, BSD, Microsoft Unix Sys.V/386, and NEC's own EWS (Sys.V. variant); some of them use only /etc/hosts, some use only NIS (let's not say YP lest the British come charging at us), some use only DNS, some use both NIS and DNS, some use Sun's resolver, and some use UCB's BIND. So it does cover all the varieties you happened to mention. Some of the systems use it with mh rather than sendmail, and it works fine also -- though that's probably more a commendation of mh rather than the sendmail.cf. Before you get all excited, let me hasten to add that site-specific configuration is required with my sendmail.cf, and that it was designed with a specific e-mail environment in mind, one which I hope to make uniform throughout NEC worldwide. Disregarding the steam-powered mailers (TM) (I hope they all are fast on their way to mailer heaven) and those glad-to-be-different systems (/bin/mail doesn't do local delivery on Microsoft's, obviously everybody should use /bin/lmail for that), nothing outside of the micro definitions section should need to be touched and some automation such as m4 or sed scripts can be easily applied. I suspect most people handle situation similar to our lab alone: one mail gatway serving all mail clients; outgoing mail from our lab having user@csl.dl.nec.com in From: field no matter which machine it originates. The sendmail.cf's on our machines differ in the CI lines which identify acceptable host (domain) names for each machine, and DG line which is the gatway machine for clients and undefined for the gateway itself. That's it, everything else is identical (or would be identical if I don't also have to be mail gateway for other divisions that expect sendmail to run on a bunch of strings and Dixie cups, but they have been warned). You can replace the CI lines with a single FI, e.g., FI/etc/sendmail.me and put all names in file /etc/sendmail.me. In that case, all clients' sendmail.cf's would be identical and differ from the gatway's only in the DG line. Some people may prefer it this way, I am not too fond of it. I am going to include the macro definition section again since I kept referring to it. I'll also include rulset 0, which is the only other "complicated" ruleset besides S3. Feel free to make use of them if they fit your need. Again, your comments PLEASE. Ying-Da Lee (214)518-3490 C&C Software Development Lab NEC America (214)518-3990 (FAX) ylee@csl.dl.nec.com uunet!necbsd!ylee --------------------------------------------------------- # ============================================================== # Macros used: (defined using D) # Z Version of this sendmail.cf # B Mail gateway for BITNET # U Mail gateway for UUCP # D Local domain # F Defined if and only if file /etc/LDHOSTS exists # and contains names of all hosts in local domain. # G Next level mail gateway. See explanantion below. # If G is undefined, then this machine is a direct # mail contact point with the entire Internet. # P If not using DNS, should be undefined. If using # DNS, pick whichever works with your mailer. (In # other words, try and see.) # I My UUCP name. Defined only if we have UUCP connections. # # ============================================================== # Classes used: (defined using C or F) # A (C) For "steam-powered" test # I (C) All acceptable names for this host # S (C) Pseudo domains # U (C) My UUCP neighbors # F (F) list of hosts in local domain # (File name /etc/LDHOSTS) # # ============================================================== # Examine the line or lines immediately preceding a line of #^^^^^^^^^^^^^^^ # and modify it/them to suit the individual site. # # ============================================================== # # Things to beware of: # - Some mailers don't recognize ruleset that is numbered > 29. # - Some mailers require that the very last ruleset is ruleset 0. # - Some mailers demand that each string in a class be a single # token, e.g., abc.def will be rejected. These are refered to # as steam-powered sendmail herein. # #=============================================================== # # For ver. 1.5: # # - Added simple detection of "steam-powered" sendmail. (Class # A and ruleset 28) # - Append unqualified names in To: and Cc: fields with # @localdomain as defined by macro D. # - Change the definition and use of macro j. # - Turn off automatic rebuild of alias file. # #=============================================================== # Version number of configuration file -- Change this after each mod DZYDL1.5-910409.10 #^^^^^^^^^^^^^^^ # number before - is base version, number after is yymmdd.hh of last # modification. # All admissible names for this machine, including IP address(es) in [] # Also include the local domain name if we are its mail gatway. CIflorida CIflorida.csl.dl.nec.com CI[143.101.64.3] #^^^^^^^^^^^^^^^ # NOTE: Some steam-powered mailers, e.g., the Ultrix mailer, # demands that each string in a class be a single token, thus # rejecting things like host.domain. For these pesky ones, we # just have to spell out the nicknames one per rule in # ruleset 0 near the beginning where we are stripping off # our own name. CAsteam.powered # To see if your sendmail is of the steam-powered variety (see # note above), get into address testing mode (option -bt) of sendmail # using (option -C) this sendmail.cf, and try # 28 steam.powered # If the final answer is yes, you have a steam-powered sendmail # and the beginning section of ruleset 0 has to be expanded. # (See S0 below.) #^^^^^^^^^^^^^^^ # Local domain # Mail for machines within local domain is always sent directly. # The sender field will conntain both the host name and the domain name. # The mailer used for such mail is 'lybin'. DDcsl.dl.nec.com #^^^^^^^^^^^^^^^ # My UUCP name. Defined only if we have UUCP connections. # Must be undefined otherwise. #DItexas #^^^^^^^^^^^^^^^ # File containing unqualified hostnames in local domain. # If undefined, all unqualified hostnames will be assume to be # in local domain. # Comment out next two lines if no such file exists. #DF #FF/etc/LDHOSTS #^^^^^^^^^^^^^^^ # Next level mail gateway. # The Mailer used for such mail is 'guabin'. # For mail clients in a division, define this as the divisional mail gateway. # For divisional mail gateway that can direct SMTP to all Internet # sites, make this undefined. # For divisional mail gateway that cannot SMTP to all Internet sites, # define this as the locational mail gateway. # For locational mail gateway, which must be able to SMTP to all Internet # sites, make this undefined. DGtexas.csl.dl.nec.com #^^^^^^^^^^^^^^^ # pseudo domains CSUUCP BITNET # UUCP gateway on Internet DUUUNET.UU.NET #^^^^^^^^^^^^^^^ # Our UUCP neighbors # Defined if and only if I is defined. #CUuufake #^^^^^^^^^^^^^^^ # BITNET gateway on Internet DBCUNYVM.CUNY.EDU #^^^^^^^^^^^^^^^ # Other candidates are: #DBCORNELLC.CIT.CORNELL.EDU #DBMITVMA.MIT.EDU #DBPSUVM.PSU.EDU # P should be undefined if not using Domain Name Service. # If using DNS, you may or may not have to use this definition # depneding on the mailer you use. DP. #^^^^^^^^^^^^^^^ # my official hostname # Should be fully qualified, including local domain. Dj$w # For system that does not include domain part in macro w, # use the following instead. #Dj$w.$D #^^^^^^^^^^^^^^ ----------------------------------------------------- S29 # restart rulset 3 and then back to rulset 0 R$* $:$>3$1 R$* $@$>0$1 S0 # On entry, the address has been focused by ruleset 3. # Error R@ $#local$:$n # If next host is myself, strip that and restart R$*<@$=I>$* $@$>29$1$3 R$*<@$=I.$=S>$* $@$>29$1$4 # Steam-powered sendmail that allows only one token per item in # a class (e.g., Ultrix's) will need to have this part expanded. # Add one rule for each name this host may use: #R$*<@my.one.name>$* $@$>29$1$3 #R$*<@my.other.name>$* $@$>29$1$3 #R$*<@my.other.name.UUCP>$* $@$>29$1$3 # etc., and one rule for each of this host's IP addresses: #R$*<@[xx.xx.xx.xx]>$* $@$>29$1$3 # Divisional mail gateway should include one rule for the # divisional domain name. #^^^^^^^^^^^^^^^ # Add any special local rules here >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> # End of special local rules <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< #^^^^^^^^^^^^^^^ # <@anything.UUCP> designate UUCP mail # UUCP mail for my UUCP neighbors are sent directly R$*<@$=U.UUCP>$* $#uucp$@$2$:$2!$1$3 # Forward other UUCP mail either to our next level mail gateway # or to Internet-UUCP mail gateway R$*<@$+.UUCP>$* $#guabin$@$?G$G$|$U$.$P$:$1$3<@$2.UUCP> #R$*<@$+.UUCP>$* $#guabin$@$?G$G$|$U$.$P$:<@$?G$G$|$U$.>:$1$3@$2.UUCP # Forward BITNET mail either to our next level mail gateway # or to Internet-BITNET mail gateay. R$*<@$+.BITNET>$* $#guabin$@$?G$G$|$B$.$P$:$1<@$2.BITNET>$3 # If F is defined, check list of hosts in local domain; # if F is undefined, hosts without qualifying domain are # assumed to be in local domain. R$?F$*<@$=F>$*$|$*<@$->$*$. $:$1<@$2.$D>$3 # Call name resolver to convert nickname and IP address into canonical name R$*<@$+>$* $:$1<@$[$2.$]>$3 # If nameserver failed, get rid of the extra trailing period. R$*<@$+.>$* $:$1<@$2>$3 # for hosts in local domain R$*<@$*$D>$* $#lybin$@$2$D$P$:$1<@$2$D>$3 # or use the following instead if these hosts are too dumb to know domain #R$*<@$D>$* $#lybin$@$D$P$:$1<@$D>$2 #R$*<@$+.$D>$* $#lybin$@$2$P$:$1<@$2>$3 # Unresolved IP address in the domain-host part # If we are direct mail contact point (G undefined), # send the mail directly but drop the @[...] part in the # recipient field. This is necessary because many hosts # still don't recognize their own IP address in @[...] form. # The standard (RFC1123) makes it a requirement now so perhaps # this rule will not be needed in the near future. R$?G@$|$*<@[$+]>$*$. $#guabin$@[$2]$:$1$3 # For host outside of local domain # If mail gateway is defined in macro G, forward mail to it. # If macro G is undefined, send directly to next host. R$*<@$+>$* $#guabin$@$?G$G$|$2$.$P$:$1<@$2>$3 # everything else is a local name R$+ $#local$:$1 local names #========================================================================== # Some mailers assume that the very last ruleset is reulset S0. # So BEWARE!
ylee@csl.dl.nec.com (Ying-Da Lee) (04/19/91)
OOPS. In article <1991Apr19.022330.22141@csl.dl.nec.com> I wrote: >... >you happened to mention. Some of the systems use it with mh rather >than sendmail, and it works fine also -- though that's probably more a ^^^^^^^^ >commendation of mh rather than the sendmail.cf. Beg your pardon, that should have been "mail". Ying-Da Lee (214)518-3490 C&C Software Development Lab NEC America (214)518-3990 (FAX) ylee@csl.dl.nec.com uunet!necbsd!ylee
barnett@grymoire.crd.ge.com (Bruce Barnett) (04/19/91)
In article <1991Apr19.022330.22141@csl.dl.nec.com> ylee@csl.dl.nec.com (Ying-Da Lee) writes: >So it does cover all the varieties > you happened to mention. But you must be using the same version of sendmail on each machine. I am not going to support the sendmail binary on 100,000 different machines. Neither am I going to be responsible for each and every sendmail.cf out there. If not, I don't understand how you can use one sendmail.cf file for each of those machines. Sun, DEC, and HP have different sendmails with different features. DECNET mail, YP, name server support, etc. Here are some particulars that are different for HP/UX, Ultrix, and SunOS: HP/UX : OI - Option - for nameserver support $< - RHS - program() SunOS: OR - Option - NFS mounted spool partitions ${ - RHS - ypmap( , ) $=m - LHS - c_mydomain $=m - RHS - any_in_mydomainname $%y - LHS - any_in_etc_hosts $%? - LHS - any_in_map_? Ultrix: ${ - LHS ypalias() $" - LHS yppasswd() As you can see these variations determine how sendmail interfaces with the Name server, YP maps and /etc/hosts. The point is: the vendors have added features to their sendmail executable. The documentation tells people how to set up their machines. Using a single version of the executable and/or the configuration file means 1) "extra" features will go away unless I add them to the sendmail sources. 2) The burden of support falls on my shoulder for every machine. Maybe both of those points are acceptable to you. They are not to me. And I do mean 100,000 machines. Even the 700 machines in this site is too much, considering the two dozen different versions of Unix. -- Bruce G. Barnett barnett@crdgw1.ge.com uunet!crdgw1!barnett
ylee@csl.dl.nec.com (Ying-Da Lee) (04/20/91)
In article <BARNETT.91Apr19093301@grymoire.crd.ge.com> barnett@crdgw1.ge.com writes: >In article <1991Apr19.022330.22141@csl.dl.nec.com> ylee@csl.dl.nec.com (Ying-Da Lee) writes: > >>So it does cover all the varieties >> you happened to mention. > >But you must be using the same version of sendmail on each machine. No. Each machine runs a sendmail program that came with the box. >If not, I don't understand how you can use one sendmail.cf file for >each of those machines. Sun, DEC, and HP have different sendmails with >different features. DECNET mail, YP, name server support, etc. Oh sure, if you want to or have to use the vendor-specific features then obviously you can't. I don't find the need for them so far. >The point is: the vendors have added features to their sendmail >executable. The documentation tells people how to set up their >machines. Using a single version of the executable and/or the >configuration file means > 1) "extra" features will go away unless I add them > to the sendmail sources. Everybody has different priorities. Being able to use all the "extra" features doesn't come high on my list. It obviously is high on yours, fine. > 2) The burden of support falls on my shoulder for every machine. Ah, but it is much easier to do a better job than a typical vendor's effort at setting up and documenting ONE sendmail.cf so that our sys.admins can have a reasonable chance of understanding it and helping each other out. Besides, people using vendors's stock versions are likely to turn to "in-house experts" like you or me for their problems anyway rather than straight to the vendors. Needless to say, I prefer dealing with one version to dealing with many. >Maybe both of those points are acceptable to you. They are not to me. Obviously, and vice versa, and nothing's wrong with either. This is not one of those situations where there is a one and only right way for all occasions and everything else invariably leads to hell. Ying-Da Lee (214)518-3490 C&C Software Development Lab NEC America (214)518-3990 (FAX) ylee@csl.dl.nec.com uunet!necbsd!ylee