166282Seric Sendmail Version 8 266282Seric Frequently Asked Questions 3*67489Seric Version 8.5 of 07/04/94 466282Seric 566282Seric 667021SericThis FAQ is specific to Version 8 of sendmail. Other questions, 767021Sericparticularly regarding compilation and configuration, are answered 867021Sericin src/READ_ME and cf/README. 966282Seric 1066282Seric---------------------------------------------------------------------- 1167021Seric * Where can I get Version 8? 1267021Seric 1367021Seric Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. 1467021Seric---------------------------------------------------------------------- 1566282Seric * What are the differences between Version 8 and other versions? 1666282Seric 1767021Seric See doc/changes/changes.me in the sendmail distribution. 1866282Seric---------------------------------------------------------------------- 1966282Seric * What happened to sendmail 6.x and 7.x? 2066282Seric 2166282Seric When I released a new version of sendmail, I changed it to 2266282Seric Release 6. Development continued in that tree until 4.4BSD 2366282Seric was released, when everything on the 4.4 tape was set to be 2466282Seric version 8.1. Version 7.x never existed. 2566282Seric---------------------------------------------------------------------- 2666282Seric * Version 8 requires a new version of "make". Where can I get this? 2766282Seric 2866282Seric Actually, Version 8 does not require a new version of "make". 2966282Seric It includes a collection of Makefiles for different architectures, 3066282Seric only one or two of which require the new "make". If you are 3166282Seric porting to a new architecture, start with Makefile.dist. 3266282Seric 3366282Seric If you really do want the new make, it is available on any of 3467021Seric the BSD Net2 or 4.4-Lite distribution sites. These include: 3566282Seric 3666282Seric ftp.uu.net /systems/unix/bsd-sources 3766282Seric gatekeeper.dec.com /.0/BSD/net2 3866282Seric ucquais.cba.uc.edu /pub/net2 3966282Seric ftp.luth.se /pub/unix/4.3bsd/net2 4066282Seric 4166282Seric Diffs and instructions for building this version of make under 4266282Seric SunOS 4.1.x are available on ftp.css.itd.umich.edu in 4366282Seric /pub/systems/sun/Net2-make.sun4.diff.Z. 44*67489Seric 45*67489Seric There is also a Linux version available on the main Linux 46*67489Seric distribution sites as pmake; this version is included as 47*67489Seric standard with the current Slackware distributions. 4866282Seric---------------------------------------------------------------------- 4966282Seric * What macro package do I use to format the V8 man pages? 5066282Seric 5166282Seric The BSD group switched over the the ``mandoc'' macros for 5266282Seric the 4.4 release. These include more hooks designed for 5366282Seric hypertext handling. However, new man pages won't format 5466282Seric under the old man macros. Fortunately, old man pages will 5566282Seric format under the new mandoc macros. 5666282Seric 5767021Seric Get the new macros with the BSD Net2 or 4.4-Lite release. 5866282Seric 5966282Seric This macro set is also available with newer versions of groff. 6066282Seric---------------------------------------------------------------------- 6166282Seric * What books are available describing sendmail? 6266282Seric 6367021Seric There is one book available devoted to sendmail: 6466282Seric 6567021Seric Costales, Allman, and Rickert, _Sendmail_. O'Reilly & 6667021Seric Associates. 6767021Seric 6867021Seric Several books have sendmail chapters, for example: 6967021Seric 7067021Seric Nemeth, Snyder, and Seebass, _Unix System Administration 7166282Seric Handbook_. Prentice-Hall. 7267021Seric Carl-Mitchell and Quarterman, _Practical Internetworking with 7366282Seric TCP/IP and UNIX_. Addison-Wesley. 7467021Seric Hunt, _TCP/IP Network Administration_. O'Reilly & Associates. 7566282Seric 7667021Seric Another book about sendmail is due out "soon": 7766282Seric 7867021Seric Avolio & Vixie, _Sendmail Theory and Practice_. Digital 7966282Seric Press (release date unknown). 8066282Seric---------------------------------------------------------------------- 8166282Seric * How do I make all my addresses appear to be from a single host? 8266282Seric 8366282Seric Using the V8 configuration macros, use: 8466282Seric 8566282Seric MASQUERADE_AS(my.dom.ain) 8666282Seric 8766282Seric This will cause all addresses to be sent out as being from 8866282Seric the indicated domain. 8966282Seric---------------------------------------------------------------------- 9066282Seric * How do I rewrite my From: lines to read ``First_Last@My.Domain''? 9166282Seric 9266282Seric There are a couple of ways of doing this. This describes using 9366282Seric the "user database" code. This is still experimental, and was 9466282Seric intended for a different purpose -- however, it does work 9566282Seric with a bit of care. It does require that you have the Berkeley 9666282Seric "db" package installed (it won't work with DBM). 9766282Seric 9866282Seric First, create your input file. This should have lines like: 9966282Seric 10066282Seric loginname:mailname First_Last 10166282Seric First_Last:maildrop loginname 10266282Seric 10366282Seric Install it in (say) /etc/userdb. Create the database: 10466282Seric 10566282Seric makemap btree /etc/userdb.db < /etc/userdb 10666282Seric 10766282Seric You can then create a config file that uses this. You will 10866282Seric have to include the following in your .mc file: 10966282Seric 11066282Seric define(confUSERDB_SPEC, /etc/userdb.db) 11166282Seric FEATURE(notsticky) 11266282Seric---------------------------------------------------------------------- 11366282Seric * So what was the user database feature intended for? 11466282Seric 11566282Seric The intent was to have all information for a given user (where 11666282Seric the user is the unique login name, not an inherently non-unique 11766282Seric full name) in one place. This would include phone numbers, 11866282Seric addresses, and so forth. The "maildrop" feature is because 11966282Seric Berkeley does not use a centralized mail server (there are a 12066282Seric number of reasons for this that are mostly historic), and so 12166282Seric we need to know where each user gets his or her mail delivered -- 12266282Seric i.e., the mail drop. 12366282Seric 12466282Seric We are in the process of setting up our environment so that 12566282Seric mail sent to an unqualified "name" goes to that person's 12666282Seric preferred maildrop; mail sent to "name@host" goes to that 12766282Seric host. The purpose of "FEATURE(notsticky)" is to cause 12866282Seric "name@host" to be looked up in the user database for delivery 12966282Seric to the maildrop. 13066282Seric---------------------------------------------------------------------- 13166282Seric * Why are you so hostile to using full names for e-mail addresses? 13266282Seric 13366282Seric Because full names are not unique. For example, the computer 13466282Seric community has two Andy Tannenbaums and two Peter Deutsches. 13566282Seric At one time, Bell Labs had two Stephen R. Bournes with offices 13666282Seric a few doors apart. You can create alternative addresses 13766282Seric (e.g., Stephen_R_Bourne_2), but that's even worse -- which 13866282Seric one of them has to have their name desecrated in this way? 13966282Seric And you can bet that they will get most of the other person's 14066282Seric email. 14166282Seric 14266282Seric So called "full names" are just longer versions of unique 14366282Seric names. Rather that lulling people into a sense of security, 14466282Seric I'd rather that it be clear that these handles are arbitrary. 14566282Seric People should use good user agents that have alias mappings 14666282Seric so that they can attach arbitrary names for their personal 14766282Seric use to those with whom they correspond. 14866282Seric 14966282Seric Even worse is fuzzy matching in e-mail -- this can make good 15066282Seric addresses turn bad. For example, I'm currently (to the best 15166282Seric of my knowledge) the only ``Allman'' at Berkeley, so mail 15266282Seric sent to "Allman@Berkeley.EDU" should get to me. But if 15366282Seric another Allman ever appears, this address could suddenly 15466282Seric become ambiguous. I've been the only Allman at Berkeley for 15566282Seric over fifteen years -- to suddenly have this "good address" 15666282Seric bounce mail because it is ambiguous would be a heinous wrong. 15766282Seric 15866282Seric Finger services should be as fuzzy as possible. Mail services 15966282Seric should be unique. 16066282Seric---------------------------------------------------------------------- 16166282Seric * When I use sendmail V8 with a Sun config file I get lines like: 16266282Seric 16366282Seric /etc/sendmail.cf: line 273: replacement $3 out of bounds 16466282Seric 16566282Seric the line in question reads: 16666282Seric 16766282Seric R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether 16866282Seric 16966282Seric what does this mean? How do I fix it? 17066282Seric 17166282Seric V8 doesn't recognize the Sun "$%y" syntax, so as far as it 17266282Seric is concerned, there is only a $1 and a $2 (but no $3) in this 17366282Seric line. Read Rick McCarty's paper on "Converting Standard Sun 17466282Seric Config Files to Sendmail Version 8", in the contrib directory 17566282Seric (file "converting.sun.configs") on the sendmail distribution 17666282Seric for a full discussion of how to do this. 17766282Seric---------------------------------------------------------------------- 17866282Seric * Should I use a wildcard MX for my domain? 17966282Seric 18066282Seric If at all possible, no. 18166282Seric 18266282Seric Wildcard MX records have lots of semantic "gotcha"s. For 18366282Seric example, they will match a host "unknown.your.domain" -- if 18466282Seric you don't explicitly test for unknown hosts in your domain, 18566282Seric you will get "config error: mail loops back to myself" 18666282Seric errors. 18766282Seric---------------------------------------------------------------------- 18866282Seric * I'm connected to the network via a SLIP link. Sometimes my sendmail 18966282Seric process hangs (although it looks like part of the message has been 19066282Seric transfered). Everything else works. What's wrong? 19166282Seric 19266282Seric Most likely, the problem isn't sendmail at all, but the low 19366282Seric level network connection. It's important that the MTU (Maximum 19466282Seric Transfer Unit) for the SLIP connection be set properly at both 19566282Seric ends. If they disagree, large packets will be trashed and 19666282Seric the connection will hang. 19766282Seric---------------------------------------------------------------------- 19866282Seric * I just upgraded to 8.x and suddenly I'm getting messages in my 19966282Seric syslog of the form "collect: I/O error on connection". What is 20066282Seric going wrong? 20166282Seric 20266282Seric Nothing. This is just a diagnosis of a condition that had 20366282Seric not been diagnosed before. If you are getting a lot of these 20466282Seric from a single host, there is probably some incompatibility 20566282Seric between 8.x and that host. If you get a lot of them in general, 20666282Seric you may have network problems that are causing connections to 20766282Seric get reset. 20866282Seric---------------------------------------------------------------------- 20966282Seric * How can I get sendmail to deliver local mail to $HOME/.mail 21066282Seric instead of into /usr/spool/mail (or /usr/mail)? 21166282Seric 21266282Seric This is a local mailer issue, not a sendmail issue. Either 21366282Seric modify your local mailer (source code will be required) or 21466282Seric change the program called in the "local" mailer configuration 21566282Seric description to be a new program that does this local delivery. 21666282Seric I understand that "procmail" works well, although I haven't 21766282Seric used it myself. 21866786Seric 21966786Seric You might be interested in reading the paper ``HLFSD: Delivering 22066786Seric Email to your $HOME'' available in the Proceedings of the 22166786Seric USENIX System Administration (LISA VII) Conference (November 22266786Seric 1993). This is also available via public FTP from 22366786Seric ftp.cs.columbia.edu:/pub/hlfsd/{README.hlfsd,hlfsd.ps}. 22466282Seric---------------------------------------------------------------------- 22566282Seric * Under V8, the "From " header gets mysteriously munged when I send 22666282Seric to an alias. 22766282Seric 22866282Seric ``It's not a bug, it's a feature.'' This happens when you have 22966282Seric a "owner-list" alias and you send to "list". V8 propogates the 23066282Seric owner information into the envelope sender field (which appears 23166282Seric as the "From " header on UNIX mail or as the Return-Path: header) 23266282Seric so that downstream errors are properly returned to the mailing 23366282Seric list owner instead of to the sender. In order to make this 23466282Seric appear as sensible as possible to end users, I recommend making 23566282Seric the owner point to a "request" address -- for example: 23666282Seric 23766282Seric list: :include:/path/name/list.list 23866282Seric owner-list: list-request 23966282Seric list-request: eric 24066282Seric 24166282Seric This will make message sent to "list" come out as being 24266282Seric "From list-request" instead of "From eric". 24366282Seric---------------------------------------------------------------------- 24466282Seric * There are four UUCP mailers listed in the configuration files. 24566282Seric Which one should I use? 24666282Seric 24766282Seric The choice is partly a matter of local preferences and what is 24866282Seric running at the other end of your UUCP connection. Unlike good 24966282Seric protocols that define what will go over the wire, UUCP uses 25066282Seric the policy that you should do what is right for the other end; 25166282Seric if they change, you have to change. This makes it hard to 25266282Seric do the right thing, and discourages people from updating their 25366282Seric software. In general, if you can avoid UUCP, please do. 25466282Seric 25566282Seric If you can't avoid it, you'll have to find the version that is 25666282Seric closest to what the other end accepts. Following is a summary 25766282Seric of the UUCP mailers available. 25866282Seric 25966282Seric uucp-old (obsolete name: "uucp") 26066282Seric This is the oldest, the worst (but the closest to UUCP) way of 26166282Seric sending messages accros UUCP connections. It does bangify 26266282Seric everything and prepends $U (your UUCP name) to the sender's 26366282Seric address (which can already be a bang path itself). It can 26466282Seric only send to one address at a time, so it spends a lot of 26566282Seric time copying duplicates of messages. Avoid this if at all 26666282Seric possible. 26766282Seric 26866282Seric uucp-new (obsolete name: "suucp") 26966282Seric The same as above, except that it assumes that in one rmail 27066282Seric command you can specify several recipients. It still has a 27166282Seric lot of other problems. 27266282Seric 27366282Seric uucp-dom 27466282Seric This UUCP mailer keeps everything as domain addresses. 27566282Seric Basically, it uses the SMTP mailer rewriting rules. 27666282Seric 27766282Seric Unfortunately, a lot of UUCP mailer transport agents require 27866282Seric bangified addresses in the envelope, although you can use 27966282Seric domain-based addresses in the message header. (The envelope 28066282Seric shows up as the From_ line on UNIX mail.) So.... 28166282Seric 28266282Seric uucp-uudom 28366282Seric This is a cross between uucp-new (for the envelope addresses) 28466282Seric and uucp-dom (for the header addresses). It bangifies the 28566282Seric envelope sender (From_ line in messages) without adding the 28666282Seric local hostname, unless there is no host name on the address 28766282Seric at all (e.g., "wolf") or the host component is a UUCP host name 28866282Seric instead of a domain name ("somehost!wolf" instead of 28966282Seric "some.dom.ain!wolf"). 29066282Seric 29166282Seric Examples: 29266282Seric 29366282Seric We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). The 29466282Seric following summarizes the sender rewriting for various mailers. 29566282Seric 29666282Seric Mailer sender rewriting in the envelope 29766282Seric ------ ------ ------------------------- 29866282Seric uucp-{old,new} wolf grasp!wolf 29966282Seric uucp-dom wolf wolf@grasp.insa-lyon.fr 30066282Seric uucp-uudom wolf grasp.insa-lyon.fr!wolf 30166282Seric 30266282Seric uucp-{old,new} wolf@fr.net grasp!fr.net!wolf 30366282Seric uucp-dom wolf@fr.net wolf@fr.net 30466282Seric uucp-uudom wolf@fr.net fr.net!wolf 30566282Seric 30666282Seric uucp-{old,new} somehost!wolf grasp!somehost!wolf 30766282Seric uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr 30866282Seric uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf 30966282Seric---------------------------------------------------------------------- 31066282Seric * I'm trying to to get my mail to go into queue only mode, and it 31166282Seric delivers the mail interactively anyway. (Or, I'm trying to use 31266282Seric the "don't deliver to expensive mailer" flag, and it doesn't 31366282Seric delivers the mail interactively anyway.) I can see it does it: 31466282Seric here's the output of "sendmail -v foo@somehost" (or Mail -v or 31566282Seric equivalent). 31666282Seric 31766282Seric The -v flag to sendmail (which is implied by the -v flag to 31866282Seric Mail and other programs in that family) tells sendmail to 31966282Seric watch the transaction. Since you have explicitly asked to 32066282Seric see what's going on, it assumes that you do not want to to 32166282Seric auto-queue, and turns that feature off. Remove the -v flag 32266282Seric and use a "tail -f" of the log instead to see what's going on. 32366282Seric 32466282Seric If you are trying to use the "don't deliver to expensive mailer" 32566282Seric flag (mailer flag "e"), be sure you also turn on global option 32666282Seric "c" -- otherwise it ignores the mailer flag. 32766282Seric---------------------------------------------------------------------- 32866285Seric * I'm getting "Local configuration error" messages, such as: 32966285Seric 33066285Seric 553 relay.domain.net config error: mail loops back to myself 33166285Seric 554 <user@domain.net>... Local configuration error 33266285Seric 33366285Seric How can I solve this problem? 33466285Seric 33566285Seric You have asked mail to the domain (e.g., domain.net) to be 33666285Seric forwarded to a specific host (in this case, relay.domain.net) 33766285Seric by using an MX record, but the relay machine doesn't recognize 33866285Seric itself as domain.net. Add domain.net to /etc/sendmail.cw 33966285Seric (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" 34066285Seric to your configuration file. 34166282Seric---------------------------------------------------------------------- 34266285Seric * I want to run Sendmail version 8 on my DEC system, but you don't 34366285Seric have MAIL11V3 support in sendmail. How do I handle this? 34466285Seric 34566285Seric Get Paul Vixie's reimplementation of the mail11 protocol 34666285Seric from gatekeeper.dec.com in /pub/DEC/gwtools. 34766285Seric---------------------------------------------------------------------- 348