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