166282Seric Sendmail Version 8 266282Seric Frequently Asked Questions 3*67898Seric Version 8.8 of 11/10/94 466282Seric 566282Seric 667021SericThis FAQ is specific to Version 8 of sendmail. Other questions, 767021Sericparticularly regarding compilation and configuration, are answered 867892Sericin src/READ_ME and cf/README (found in the V8 sendmail distribution). 966282Seric 1066282Seric---------------------------------------------------------------------- 1167892Seric * What do you wish everyone would do before sending you mail? 1267892Seric 1367892Seric Read this FAQ completely. Read src/READ_ME and cf/README 1467892Seric completely. Ask themselves if their question hasn't already 1567892Seric been answered. 1667892Seric---------------------------------------------------------------------- 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 2767892Seric When I released a new (Alpha/Beta) version of sendmail, I changed 2867892Seric 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, 3667892Seric only one or two of which require the new "make". For a supported 3767892Seric architecture, use ``sh makesendmail''. If you are porting to a 3867892Seric 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 6767892Seric Get the new macros with the BSD Net2 or 4.4-Lite release 6867892Seric (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? 15067892Seric And you can bet that one of them will get most of the other 15167892Seric person's e-mail. 15266282Seric 15367892Seric So called "full names" are just an attempt to create longer 15467892Seric versions of unique names. Rather that lulling people into a 15567892Seric sense of security, I'd rather that it be clear that these 15667892Seric handles are arbitrary. People should use good user agents 15767892Seric that have alias mappings so that they can attach arbitrary 15867892Seric names for their personal use to those with whom they correspond 15967892Seric (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 17067892Seric Finger services should be as fuzzy as possible (within 17167892Seric reason, of course). Mail services should be unique. 17266282Seric---------------------------------------------------------------------- 17367892Seric * I'm getting "Local configuration error" messages, such as: 17467892Seric 17567892Seric 553 relay.domain.net config error: mail loops back to myself 17667892Seric 554 <user@domain.net>... Local configuration error 17767892Seric 17867892Seric How can I solve this problem? 17967892Seric 18067892Seric You have asked mail to the domain (e.g., domain.net) to be 18167892Seric forwarded to a specific host (in this case, relay.domain.net) 18267892Seric by using an MX record, but the relay machine doesn't recognize 18367892Seric itself as domain.net. Add domain.net to /etc/sendmail.cw 18467892Seric (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" 18567892Seric to your configuration file. 186*67898Seric 187*67898Seric IMPORTANT: Be sure you kill and restart the sendmail daemon 188*67898Seric after you change the configuration file (for ANY change in 189*67898Seric the configuration, not just this one): 190*67898Seric 191*67898Seric kill `head -1 /etc/sendmail.pid` 192*67898Seric sh -c "`tail -1 /etc/sendmail.pid`" 193*67898Seric 194*67898Seric NOTA BENE: kill -1 does not work! 19567892Seric---------------------------------------------------------------------- 196*67898Seric * OK, I did that, and the problem still occurs. 197*67898Seric 198*67898Seric You probably forgot to to resta 199*67898Seric---------------------------------------------------------------------- 20066282Seric * When I use sendmail V8 with a Sun config file I get lines like: 20166282Seric 20266282Seric /etc/sendmail.cf: line 273: replacement $3 out of bounds 20366282Seric 20466282Seric the line in question reads: 20566282Seric 20666282Seric R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether 20766282Seric 20866282Seric what does this mean? How do I fix it? 20966282Seric 21066282Seric V8 doesn't recognize the Sun "$%y" syntax, so as far as it 21166282Seric is concerned, there is only a $1 and a $2 (but no $3) in this 21266282Seric line. Read Rick McCarty's paper on "Converting Standard Sun 21366282Seric Config Files to Sendmail Version 8", in the contrib directory 21466282Seric (file "converting.sun.configs") on the sendmail distribution 21566282Seric for a full discussion of how to do this. 21666282Seric---------------------------------------------------------------------- 21766282Seric * Should I use a wildcard MX for my domain? 21866282Seric 21966282Seric If at all possible, no. 22066282Seric 22166282Seric Wildcard MX records have lots of semantic "gotcha"s. For 22266282Seric example, they will match a host "unknown.your.domain" -- if 22366282Seric you don't explicitly test for unknown hosts in your domain, 22466282Seric you will get "config error: mail loops back to myself" 22566282Seric errors. 22666282Seric---------------------------------------------------------------------- 22766282Seric * I'm connected to the network via a SLIP link. Sometimes my sendmail 22866282Seric process hangs (although it looks like part of the message has been 22966282Seric transfered). Everything else works. What's wrong? 23066282Seric 23166282Seric Most likely, the problem isn't sendmail at all, but the low 23266282Seric level network connection. It's important that the MTU (Maximum 23366282Seric Transfer Unit) for the SLIP connection be set properly at both 23466282Seric ends. If they disagree, large packets will be trashed and 23566282Seric the connection will hang. 23666282Seric---------------------------------------------------------------------- 23766282Seric * I just upgraded to 8.x and suddenly I'm getting messages in my 23866282Seric syslog of the form "collect: I/O error on connection". What is 23966282Seric going wrong? 24066282Seric 24166282Seric Nothing. This is just a diagnosis of a condition that had 24266282Seric not been diagnosed before. If you are getting a lot of these 24366282Seric from a single host, there is probably some incompatibility 24466282Seric between 8.x and that host. If you get a lot of them in general, 24566282Seric you may have network problems that are causing connections to 24666282Seric get reset. 24766282Seric---------------------------------------------------------------------- 24867892Seric * I just upgraded to 8.x and suddenly connections to the SMTP port 24967892Seric take a long time. What is going wrong? 25067892Seric 25167892Seric It's probably something wierd in your TCP implementation that 25267892Seric makes the IDENT code act oddly. On most systems V8 tries to 25367892Seric do a ``callback'' to the connecting host to get a validated 25467892Seric user name (see RFC 1413 for details). If the connecting 25567892Seric host does not support such a service it will normally fail 25667892Seric quickly with "Connection refused", but certain kinds of 25767892Seric packet filters and certain TCP implementations just time out. 25867892Seric 25967892Seric To test this, set the IDENT timeout to zero using 26067892Seric ``OrIdent=0'' in the configuration file. This will 26167892Seric completely disable all use of the IDENT protocol. 26267892Seric 26367892Seric Another possible problem is that you have your name server 26467892Seric and/or resolver configured improperly. Make sure that 26567892Seric all "nameserver" entries in /etc/resolv.conf point to functional 26667892Seric servers. If you are running your own server make certain that 26767892Seric all the servers listed in your root cache (usually called 26867892Seric something like "/var/namedb/root.cache"; see your 26967892Seric /etc/named.boot file to get your value) are up to date. 27067892Seric Either of these can cause long delays. 27167892Seric---------------------------------------------------------------------- 27267892Seric * I just upgraded to 8.x and suddenly I get errors such as ``mail: 27367892Seric options must follow recipients.'' What is going wrong? 27467892Seric 27567892Seric You need OSTYPE(systype) in your .mc file -- otherwise the 27667892Seric configurations use a default that probably disagrees with 27767892Seric your local mail system. See cf/README for details. 27867892Seric---------------------------------------------------------------------- 27966282Seric * How can I get sendmail to deliver local mail to $HOME/.mail 28066282Seric instead of into /usr/spool/mail (or /usr/mail)? 28166282Seric 28266282Seric This is a local mailer issue, not a sendmail issue. Either 28366282Seric modify your local mailer (source code will be required) or 28466282Seric change the program called in the "local" mailer configuration 28566282Seric description to be a new program that does this local delivery. 28666282Seric I understand that "procmail" works well, although I haven't 28766282Seric used it myself. 28866786Seric 28966786Seric You might be interested in reading the paper ``HLFSD: Delivering 29066786Seric Email to your $HOME'' available in the Proceedings of the 29166786Seric USENIX System Administration (LISA VII) Conference (November 29266786Seric 1993). This is also available via public FTP from 29366786Seric ftp.cs.columbia.edu:/pub/hlfsd/{README.hlfsd,hlfsd.ps}. 29466282Seric---------------------------------------------------------------------- 29566282Seric * Under V8, the "From " header gets mysteriously munged when I send 29666282Seric to an alias. 29766282Seric 29866282Seric ``It's not a bug, it's a feature.'' This happens when you have 29966282Seric a "owner-list" alias and you send to "list". V8 propogates the 30066282Seric owner information into the envelope sender field (which appears 30166282Seric as the "From " header on UNIX mail or as the Return-Path: header) 30266282Seric so that downstream errors are properly returned to the mailing 30366282Seric list owner instead of to the sender. In order to make this 30466282Seric appear as sensible as possible to end users, I recommend making 30566282Seric the owner point to a "request" address -- for example: 30666282Seric 30766282Seric list: :include:/path/name/list.list 30866282Seric owner-list: list-request 30966282Seric list-request: eric 31066282Seric 31166282Seric This will make message sent to "list" come out as being 31266282Seric "From list-request" instead of "From eric". 31366282Seric---------------------------------------------------------------------- 31466282Seric * There are four UUCP mailers listed in the configuration files. 31566282Seric Which one should I use? 31666282Seric 31766282Seric The choice is partly a matter of local preferences and what is 31866282Seric running at the other end of your UUCP connection. Unlike good 31966282Seric protocols that define what will go over the wire, UUCP uses 32066282Seric the policy that you should do what is right for the other end; 32166282Seric if they change, you have to change. This makes it hard to 32266282Seric do the right thing, and discourages people from updating their 32366282Seric software. In general, if you can avoid UUCP, please do. 32466282Seric 32566282Seric If you can't avoid it, you'll have to find the version that is 32666282Seric closest to what the other end accepts. Following is a summary 32766282Seric of the UUCP mailers available. 32866282Seric 32966282Seric uucp-old (obsolete name: "uucp") 33066282Seric This is the oldest, the worst (but the closest to UUCP) way of 33166282Seric sending messages accros UUCP connections. It does bangify 33266282Seric everything and prepends $U (your UUCP name) to the sender's 33366282Seric address (which can already be a bang path itself). It can 33466282Seric only send to one address at a time, so it spends a lot of 33566282Seric time copying duplicates of messages. Avoid this if at all 33666282Seric possible. 33766282Seric 33866282Seric uucp-new (obsolete name: "suucp") 33966282Seric The same as above, except that it assumes that in one rmail 34066282Seric command you can specify several recipients. It still has a 34166282Seric lot of other problems. 34266282Seric 34366282Seric uucp-dom 34466282Seric This UUCP mailer keeps everything as domain addresses. 34566282Seric Basically, it uses the SMTP mailer rewriting rules. 34666282Seric 34766282Seric Unfortunately, a lot of UUCP mailer transport agents require 34866282Seric bangified addresses in the envelope, although you can use 34966282Seric domain-based addresses in the message header. (The envelope 35066282Seric shows up as the From_ line on UNIX mail.) So.... 35166282Seric 35266282Seric uucp-uudom 35366282Seric This is a cross between uucp-new (for the envelope addresses) 35466282Seric and uucp-dom (for the header addresses). It bangifies the 35566282Seric envelope sender (From_ line in messages) without adding the 35666282Seric local hostname, unless there is no host name on the address 35766282Seric at all (e.g., "wolf") or the host component is a UUCP host name 35866282Seric instead of a domain name ("somehost!wolf" instead of 35966282Seric "some.dom.ain!wolf"). 36066282Seric 36166282Seric Examples: 36266282Seric 36366282Seric We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). The 36466282Seric following summarizes the sender rewriting for various mailers. 36566282Seric 36666282Seric Mailer sender rewriting in the envelope 36766282Seric ------ ------ ------------------------- 36866282Seric uucp-{old,new} wolf grasp!wolf 36966282Seric uucp-dom wolf wolf@grasp.insa-lyon.fr 37066282Seric uucp-uudom wolf grasp.insa-lyon.fr!wolf 37166282Seric 37266282Seric uucp-{old,new} wolf@fr.net grasp!fr.net!wolf 37366282Seric uucp-dom wolf@fr.net wolf@fr.net 37466282Seric uucp-uudom wolf@fr.net fr.net!wolf 37566282Seric 37666282Seric uucp-{old,new} somehost!wolf grasp!somehost!wolf 37766282Seric uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr 37866282Seric uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf 37966282Seric---------------------------------------------------------------------- 38066282Seric * I'm trying to to get my mail to go into queue only mode, and it 38166282Seric delivers the mail interactively anyway. (Or, I'm trying to use 38266282Seric the "don't deliver to expensive mailer" flag, and it doesn't 38366282Seric delivers the mail interactively anyway.) I can see it does it: 38466282Seric here's the output of "sendmail -v foo@somehost" (or Mail -v or 38566282Seric equivalent). 38666282Seric 38766282Seric The -v flag to sendmail (which is implied by the -v flag to 38866282Seric Mail and other programs in that family) tells sendmail to 38966282Seric watch the transaction. Since you have explicitly asked to 39066282Seric see what's going on, it assumes that you do not want to to 39166282Seric auto-queue, and turns that feature off. Remove the -v flag 39266282Seric and use a "tail -f" of the log instead to see what's going on. 39366282Seric 39466282Seric If you are trying to use the "don't deliver to expensive mailer" 39566282Seric flag (mailer flag "e"), be sure you also turn on global option 39666282Seric "c" -- otherwise it ignores the mailer flag. 39766282Seric---------------------------------------------------------------------- 39866285Seric * I want to run Sendmail version 8 on my DEC system, but you don't 39966285Seric have MAIL11V3 support in sendmail. How do I handle this? 40066285Seric 40166285Seric Get Paul Vixie's reimplementation of the mail11 protocol 40266285Seric from gatekeeper.dec.com in /pub/DEC/gwtools. 40366285Seric---------------------------------------------------------------------- 404