166282Seric Sendmail Version 8 266282Seric Frequently Asked Questions 3*67892Seric Version 8.7 of 11/08/94 466282Seric 566282Seric 667021SericThis FAQ is specific to Version 8 of sendmail. Other questions, 767021Sericparticularly regarding compilation and configuration, are answered 8*67892Sericin src/READ_ME and cf/README (found in the V8 sendmail distribution). 966282Seric 1066282Seric---------------------------------------------------------------------- 11*67892Seric * What do you wish everyone would do before sending you mail? 12*67892Seric 13*67892Seric Read this FAQ completely. Read src/READ_ME and cf/README 14*67892Seric completely. Ask themselves if their question hasn't already 15*67892Seric been answered. 16*67892Seric---------------------------------------------------------------------- 1767021Seric * Where can I get Version 8? 1867021Seric 1967021Seric Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. 2067021Seric---------------------------------------------------------------------- 2166282Seric * What are the differences between Version 8 and other versions? 2266282Seric 2367021Seric See doc/changes/changes.me in the sendmail distribution. 2466282Seric---------------------------------------------------------------------- 2566282Seric * What happened to sendmail 6.x and 7.x? 2666282Seric 27*67892Seric When I released a new (Alpha/Beta) version of sendmail, I changed 28*67892Seric it to Release 6. Development continued in that tree until 4.4BSD 2966282Seric was released, when everything on the 4.4 tape was set to be 3066282Seric version 8.1. Version 7.x never existed. 3166282Seric---------------------------------------------------------------------- 3266282Seric * Version 8 requires a new version of "make". Where can I get this? 3366282Seric 3466282Seric Actually, Version 8 does not require a new version of "make". 3566282Seric It includes a collection of Makefiles for different architectures, 36*67892Seric only one or two of which require the new "make". For a supported 37*67892Seric architecture, use ``sh makesendmail''. If you are porting to a 38*67892Seric new architecture, start with Makefile.dist. 3966282Seric 4066282Seric If you really do want the new make, it is available on any of 4167021Seric the BSD Net2 or 4.4-Lite distribution sites. These include: 4266282Seric 4366282Seric ftp.uu.net /systems/unix/bsd-sources 4466282Seric gatekeeper.dec.com /.0/BSD/net2 4566282Seric ucquais.cba.uc.edu /pub/net2 4666282Seric ftp.luth.se /pub/unix/4.3bsd/net2 4766282Seric 4866282Seric Diffs and instructions for building this version of make under 4966282Seric SunOS 4.1.x are available on ftp.css.itd.umich.edu in 5067556Seric /pub/systems/sun/Net2-make.sun4.diff.Z. A patchkit for Ultrix 5167556Seric is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z. Patches 5267556Seric for AIX 3.2.4 are available on ftp.uni-stuttgart.de in 5367556Seric /sw/src/patches/bsd-make-rus-patches. 5467489Seric 5567489Seric There is also a Linux version available on the main Linux 5667489Seric distribution sites as pmake; this version is included as 5767489Seric standard with the current Slackware distributions. 5866282Seric---------------------------------------------------------------------- 5966282Seric * What macro package do I use to format the V8 man pages? 6066282Seric 6166282Seric The BSD group switched over the the ``mandoc'' macros for 6266282Seric the 4.4 release. These include more hooks designed for 6366282Seric hypertext handling. However, new man pages won't format 6466282Seric under the old man macros. Fortunately, old man pages will 6566282Seric format under the new mandoc macros. 6666282Seric 67*67892Seric Get the new macros with the BSD Net2 or 4.4-Lite release 68*67892Seric (see above). 6966282Seric 7066282Seric This macro set is also available with newer versions of groff. 7166282Seric---------------------------------------------------------------------- 7266282Seric * What books are available describing sendmail? 7366282Seric 7467021Seric There is one book available devoted to sendmail: 7566282Seric 7667021Seric Costales, Allman, and Rickert, _Sendmail_. O'Reilly & 7767021Seric Associates. 7867021Seric 7967021Seric Several books have sendmail chapters, for example: 8067021Seric 8167021Seric Nemeth, Snyder, and Seebass, _Unix System Administration 8266282Seric Handbook_. Prentice-Hall. 8367021Seric Carl-Mitchell and Quarterman, _Practical Internetworking with 8466282Seric TCP/IP and UNIX_. Addison-Wesley. 8567021Seric Hunt, _TCP/IP Network Administration_. O'Reilly & Associates. 8666282Seric 8767021Seric Another book about sendmail is due out "soon": 8866282Seric 8967021Seric Avolio & Vixie, _Sendmail Theory and Practice_. Digital 9066282Seric Press (release date unknown). 9166282Seric---------------------------------------------------------------------- 9266282Seric * How do I make all my addresses appear to be from a single host? 9366282Seric 9466282Seric Using the V8 configuration macros, use: 9566282Seric 9666282Seric MASQUERADE_AS(my.dom.ain) 9766282Seric 9866282Seric This will cause all addresses to be sent out as being from 9966282Seric the indicated domain. 10066282Seric---------------------------------------------------------------------- 10166282Seric * How do I rewrite my From: lines to read ``First_Last@My.Domain''? 10266282Seric 10366282Seric There are a couple of ways of doing this. This describes using 10466282Seric the "user database" code. This is still experimental, and was 10566282Seric intended for a different purpose -- however, it does work 10666282Seric with a bit of care. It does require that you have the Berkeley 10766282Seric "db" package installed (it won't work with DBM). 10866282Seric 10966282Seric First, create your input file. This should have lines like: 11066282Seric 11166282Seric loginname:mailname First_Last 11266282Seric First_Last:maildrop loginname 11366282Seric 11466282Seric Install it in (say) /etc/userdb. Create the database: 11566282Seric 11666282Seric makemap btree /etc/userdb.db < /etc/userdb 11766282Seric 11866282Seric You can then create a config file that uses this. You will 11966282Seric have to include the following in your .mc file: 12066282Seric 12166282Seric define(confUSERDB_SPEC, /etc/userdb.db) 12266282Seric FEATURE(notsticky) 12366282Seric---------------------------------------------------------------------- 12466282Seric * So what was the user database feature intended for? 12566282Seric 12666282Seric The intent was to have all information for a given user (where 12766282Seric the user is the unique login name, not an inherently non-unique 12866282Seric full name) in one place. This would include phone numbers, 12966282Seric addresses, and so forth. The "maildrop" feature is because 13066282Seric Berkeley does not use a centralized mail server (there are a 13166282Seric number of reasons for this that are mostly historic), and so 13266282Seric we need to know where each user gets his or her mail delivered -- 13366282Seric i.e., the mail drop. 13466282Seric 13566282Seric We are in the process of setting up our environment so that 13666282Seric mail sent to an unqualified "name" goes to that person's 13766282Seric preferred maildrop; mail sent to "name@host" goes to that 13866282Seric host. The purpose of "FEATURE(notsticky)" is to cause 13966282Seric "name@host" to be looked up in the user database for delivery 14066282Seric to the maildrop. 14166282Seric---------------------------------------------------------------------- 14266282Seric * Why are you so hostile to using full names for e-mail addresses? 14366282Seric 14466282Seric Because full names are not unique. For example, the computer 14566282Seric community has two Andy Tannenbaums and two Peter Deutsches. 14666282Seric At one time, Bell Labs had two Stephen R. Bournes with offices 14766282Seric a few doors apart. You can create alternative addresses 14866282Seric (e.g., Stephen_R_Bourne_2), but that's even worse -- which 14966282Seric one of them has to have their name desecrated in this way? 150*67892Seric And you can bet that one of them will get most of the other 151*67892Seric person's e-mail. 15266282Seric 153*67892Seric So called "full names" are just an attempt to create longer 154*67892Seric versions of unique names. Rather that lulling people into a 155*67892Seric sense of security, I'd rather that it be clear that these 156*67892Seric handles are arbitrary. People should use good user agents 157*67892Seric that have alias mappings so that they can attach arbitrary 158*67892Seric names for their personal use to those with whom they correspond 159*67892Seric (such as the MH alias file). 16066282Seric 16166282Seric Even worse is fuzzy matching in e-mail -- this can make good 16266282Seric addresses turn bad. For example, I'm currently (to the best 16366282Seric of my knowledge) the only ``Allman'' at Berkeley, so mail 16466282Seric sent to "Allman@Berkeley.EDU" should get to me. But if 16566282Seric another Allman ever appears, this address could suddenly 16666282Seric become ambiguous. I've been the only Allman at Berkeley for 16766282Seric over fifteen years -- to suddenly have this "good address" 16866282Seric bounce mail because it is ambiguous would be a heinous wrong. 16966282Seric 170*67892Seric Finger services should be as fuzzy as possible (within 171*67892Seric reason, of course). Mail services should be unique. 17266282Seric---------------------------------------------------------------------- 173*67892Seric * I'm getting "Local configuration error" messages, such as: 174*67892Seric 175*67892Seric 553 relay.domain.net config error: mail loops back to myself 176*67892Seric 554 <user@domain.net>... Local configuration error 177*67892Seric 178*67892Seric How can I solve this problem? 179*67892Seric 180*67892Seric You have asked mail to the domain (e.g., domain.net) to be 181*67892Seric forwarded to a specific host (in this case, relay.domain.net) 182*67892Seric by using an MX record, but the relay machine doesn't recognize 183*67892Seric itself as domain.net. Add domain.net to /etc/sendmail.cw 184*67892Seric (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" 185*67892Seric to your configuration file. 186*67892Seric---------------------------------------------------------------------- 18766282Seric * When I use sendmail V8 with a Sun config file I get lines like: 18866282Seric 18966282Seric /etc/sendmail.cf: line 273: replacement $3 out of bounds 19066282Seric 19166282Seric the line in question reads: 19266282Seric 19366282Seric R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether 19466282Seric 19566282Seric what does this mean? How do I fix it? 19666282Seric 19766282Seric V8 doesn't recognize the Sun "$%y" syntax, so as far as it 19866282Seric is concerned, there is only a $1 and a $2 (but no $3) in this 19966282Seric line. Read Rick McCarty's paper on "Converting Standard Sun 20066282Seric Config Files to Sendmail Version 8", in the contrib directory 20166282Seric (file "converting.sun.configs") on the sendmail distribution 20266282Seric for a full discussion of how to do this. 20366282Seric---------------------------------------------------------------------- 20466282Seric * Should I use a wildcard MX for my domain? 20566282Seric 20666282Seric If at all possible, no. 20766282Seric 20866282Seric Wildcard MX records have lots of semantic "gotcha"s. For 20966282Seric example, they will match a host "unknown.your.domain" -- if 21066282Seric you don't explicitly test for unknown hosts in your domain, 21166282Seric you will get "config error: mail loops back to myself" 21266282Seric errors. 21366282Seric---------------------------------------------------------------------- 21466282Seric * I'm connected to the network via a SLIP link. Sometimes my sendmail 21566282Seric process hangs (although it looks like part of the message has been 21666282Seric transfered). Everything else works. What's wrong? 21766282Seric 21866282Seric Most likely, the problem isn't sendmail at all, but the low 21966282Seric level network connection. It's important that the MTU (Maximum 22066282Seric Transfer Unit) for the SLIP connection be set properly at both 22166282Seric ends. If they disagree, large packets will be trashed and 22266282Seric the connection will hang. 22366282Seric---------------------------------------------------------------------- 22466282Seric * I just upgraded to 8.x and suddenly I'm getting messages in my 22566282Seric syslog of the form "collect: I/O error on connection". What is 22666282Seric going wrong? 22766282Seric 22866282Seric Nothing. This is just a diagnosis of a condition that had 22966282Seric not been diagnosed before. If you are getting a lot of these 23066282Seric from a single host, there is probably some incompatibility 23166282Seric between 8.x and that host. If you get a lot of them in general, 23266282Seric you may have network problems that are causing connections to 23366282Seric get reset. 23466282Seric---------------------------------------------------------------------- 235*67892Seric * I just upgraded to 8.x and suddenly connections to the SMTP port 236*67892Seric take a long time. What is going wrong? 237*67892Seric 238*67892Seric It's probably something wierd in your TCP implementation that 239*67892Seric makes the IDENT code act oddly. On most systems V8 tries to 240*67892Seric do a ``callback'' to the connecting host to get a validated 241*67892Seric user name (see RFC 1413 for details). If the connecting 242*67892Seric host does not support such a service it will normally fail 243*67892Seric quickly with "Connection refused", but certain kinds of 244*67892Seric packet filters and certain TCP implementations just time out. 245*67892Seric 246*67892Seric To test this, set the IDENT timeout to zero using 247*67892Seric ``OrIdent=0'' in the configuration file. This will 248*67892Seric completely disable all use of the IDENT protocol. 249*67892Seric 250*67892Seric Another possible problem is that you have your name server 251*67892Seric and/or resolver configured improperly. Make sure that 252*67892Seric all "nameserver" entries in /etc/resolv.conf point to functional 253*67892Seric servers. If you are running your own server make certain that 254*67892Seric all the servers listed in your root cache (usually called 255*67892Seric something like "/var/namedb/root.cache"; see your 256*67892Seric /etc/named.boot file to get your value) are up to date. 257*67892Seric Either of these can cause long delays. 258*67892Seric---------------------------------------------------------------------- 259*67892Seric * I just upgraded to 8.x and suddenly I get errors such as ``mail: 260*67892Seric options must follow recipients.'' What is going wrong? 261*67892Seric 262*67892Seric You need OSTYPE(systype) in your .mc file -- otherwise the 263*67892Seric configurations use a default that probably disagrees with 264*67892Seric your local mail system. See cf/README for details. 265*67892Seric---------------------------------------------------------------------- 26666282Seric * How can I get sendmail to deliver local mail to $HOME/.mail 26766282Seric instead of into /usr/spool/mail (or /usr/mail)? 26866282Seric 26966282Seric This is a local mailer issue, not a sendmail issue. Either 27066282Seric modify your local mailer (source code will be required) or 27166282Seric change the program called in the "local" mailer configuration 27266282Seric description to be a new program that does this local delivery. 27366282Seric I understand that "procmail" works well, although I haven't 27466282Seric used it myself. 27566786Seric 27666786Seric You might be interested in reading the paper ``HLFSD: Delivering 27766786Seric Email to your $HOME'' available in the Proceedings of the 27866786Seric USENIX System Administration (LISA VII) Conference (November 27966786Seric 1993). This is also available via public FTP from 28066786Seric ftp.cs.columbia.edu:/pub/hlfsd/{README.hlfsd,hlfsd.ps}. 28166282Seric---------------------------------------------------------------------- 28266282Seric * Under V8, the "From " header gets mysteriously munged when I send 28366282Seric to an alias. 28466282Seric 28566282Seric ``It's not a bug, it's a feature.'' This happens when you have 28666282Seric a "owner-list" alias and you send to "list". V8 propogates the 28766282Seric owner information into the envelope sender field (which appears 28866282Seric as the "From " header on UNIX mail or as the Return-Path: header) 28966282Seric so that downstream errors are properly returned to the mailing 29066282Seric list owner instead of to the sender. In order to make this 29166282Seric appear as sensible as possible to end users, I recommend making 29266282Seric the owner point to a "request" address -- for example: 29366282Seric 29466282Seric list: :include:/path/name/list.list 29566282Seric owner-list: list-request 29666282Seric list-request: eric 29766282Seric 29866282Seric This will make message sent to "list" come out as being 29966282Seric "From list-request" instead of "From eric". 30066282Seric---------------------------------------------------------------------- 30166282Seric * There are four UUCP mailers listed in the configuration files. 30266282Seric Which one should I use? 30366282Seric 30466282Seric The choice is partly a matter of local preferences and what is 30566282Seric running at the other end of your UUCP connection. Unlike good 30666282Seric protocols that define what will go over the wire, UUCP uses 30766282Seric the policy that you should do what is right for the other end; 30866282Seric if they change, you have to change. This makes it hard to 30966282Seric do the right thing, and discourages people from updating their 31066282Seric software. In general, if you can avoid UUCP, please do. 31166282Seric 31266282Seric If you can't avoid it, you'll have to find the version that is 31366282Seric closest to what the other end accepts. Following is a summary 31466282Seric of the UUCP mailers available. 31566282Seric 31666282Seric uucp-old (obsolete name: "uucp") 31766282Seric This is the oldest, the worst (but the closest to UUCP) way of 31866282Seric sending messages accros UUCP connections. It does bangify 31966282Seric everything and prepends $U (your UUCP name) to the sender's 32066282Seric address (which can already be a bang path itself). It can 32166282Seric only send to one address at a time, so it spends a lot of 32266282Seric time copying duplicates of messages. Avoid this if at all 32366282Seric possible. 32466282Seric 32566282Seric uucp-new (obsolete name: "suucp") 32666282Seric The same as above, except that it assumes that in one rmail 32766282Seric command you can specify several recipients. It still has a 32866282Seric lot of other problems. 32966282Seric 33066282Seric uucp-dom 33166282Seric This UUCP mailer keeps everything as domain addresses. 33266282Seric Basically, it uses the SMTP mailer rewriting rules. 33366282Seric 33466282Seric Unfortunately, a lot of UUCP mailer transport agents require 33566282Seric bangified addresses in the envelope, although you can use 33666282Seric domain-based addresses in the message header. (The envelope 33766282Seric shows up as the From_ line on UNIX mail.) So.... 33866282Seric 33966282Seric uucp-uudom 34066282Seric This is a cross between uucp-new (for the envelope addresses) 34166282Seric and uucp-dom (for the header addresses). It bangifies the 34266282Seric envelope sender (From_ line in messages) without adding the 34366282Seric local hostname, unless there is no host name on the address 34466282Seric at all (e.g., "wolf") or the host component is a UUCP host name 34566282Seric instead of a domain name ("somehost!wolf" instead of 34666282Seric "some.dom.ain!wolf"). 34766282Seric 34866282Seric Examples: 34966282Seric 35066282Seric We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). The 35166282Seric following summarizes the sender rewriting for various mailers. 35266282Seric 35366282Seric Mailer sender rewriting in the envelope 35466282Seric ------ ------ ------------------------- 35566282Seric uucp-{old,new} wolf grasp!wolf 35666282Seric uucp-dom wolf wolf@grasp.insa-lyon.fr 35766282Seric uucp-uudom wolf grasp.insa-lyon.fr!wolf 35866282Seric 35966282Seric uucp-{old,new} wolf@fr.net grasp!fr.net!wolf 36066282Seric uucp-dom wolf@fr.net wolf@fr.net 36166282Seric uucp-uudom wolf@fr.net fr.net!wolf 36266282Seric 36366282Seric uucp-{old,new} somehost!wolf grasp!somehost!wolf 36466282Seric uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr 36566282Seric uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf 36666282Seric---------------------------------------------------------------------- 36766282Seric * I'm trying to to get my mail to go into queue only mode, and it 36866282Seric delivers the mail interactively anyway. (Or, I'm trying to use 36966282Seric the "don't deliver to expensive mailer" flag, and it doesn't 37066282Seric delivers the mail interactively anyway.) I can see it does it: 37166282Seric here's the output of "sendmail -v foo@somehost" (or Mail -v or 37266282Seric equivalent). 37366282Seric 37466282Seric The -v flag to sendmail (which is implied by the -v flag to 37566282Seric Mail and other programs in that family) tells sendmail to 37666282Seric watch the transaction. Since you have explicitly asked to 37766282Seric see what's going on, it assumes that you do not want to to 37866282Seric auto-queue, and turns that feature off. Remove the -v flag 37966282Seric and use a "tail -f" of the log instead to see what's going on. 38066282Seric 38166282Seric If you are trying to use the "don't deliver to expensive mailer" 38266282Seric flag (mailer flag "e"), be sure you also turn on global option 38366282Seric "c" -- otherwise it ignores the mailer flag. 38466282Seric---------------------------------------------------------------------- 38566285Seric * I want to run Sendmail version 8 on my DEC system, but you don't 38666285Seric have MAIL11V3 support in sendmail. How do I handle this? 38766285Seric 38866285Seric Get Paul Vixie's reimplementation of the mail11 protocol 38966285Seric from gatekeeper.dec.com in /pub/DEC/gwtools. 39066285Seric---------------------------------------------------------------------- 391