Sendmail Version 8 Frequently Asked Questions Version 8.3 of 4/14/94 This FAQ is specific to Version 8 of sendmail. ---------------------------------------------------------------------- * What are the differences between Version 8 and other versions? See CHANGES-R5-R8 in the anonymous FTP directory. ---------------------------------------------------------------------- * What happened to sendmail 6.x and 7.x? When I released a new version of sendmail, I changed it to Release 6. Development continued in that tree until 4.4BSD was released, when everything on the 4.4 tape was set to be version 8.1. Version 7.x never existed. ---------------------------------------------------------------------- * Where can I get Version 8? Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. ---------------------------------------------------------------------- * Version 8 requires a new version of "make". Where can I get this? Actually, Version 8 does not require a new version of "make". It includes a collection of Makefiles for different architectures, only one or two of which require the new "make". If you are porting to a new architecture, start with Makefile.dist. If you really do want the new make, it is available on any of the BSD Net2 distribution sites. These include: ftp.uu.net /systems/unix/bsd-sources gatekeeper.dec.com /.0/BSD/net2 ucquais.cba.uc.edu /pub/net2 ftp.luth.se /pub/unix/4.3bsd/net2 Diffs and instructions for building this version of make under SunOS 4.1.x are available on ftp.css.itd.umich.edu in /pub/systems/sun/Net2-make.sun4.diff.Z. ---------------------------------------------------------------------- * What macro package do I use to format the V8 man pages? The BSD group switched over the the ``mandoc'' macros for the 4.4 release. These include more hooks designed for hypertext handling. However, new man pages won't format under the old man macros. Fortunately, old man pages will format under the new mandoc macros. Get the new macros with the BSD Net2 release. This macro set is also available with newer versions of groff. ---------------------------------------------------------------------- * What books are available describing sendmail? There is one book available devoted to sendmail, and several books that have sendmail chapters. Nemeth, Snyder, and Seebass, _Unix System Administration Handbook_. Prentice-Hall. Carl-Mitchell and Quarterman, _Practical Internetworking with TCP/IP and UNIX_. Addison-Wesley. Hunt, _TCP/IP Network Administration_. O'Reilly & Associates. Costales, Allman, and Rickert, _Sendmail_. O'Reilly & Associates. Another book is due out "soon": Avolio & Vixie, _Sendmail Theory and Practice_. Digital Press (release date unknown). ---------------------------------------------------------------------- * How do I make all my addresses appear to be from a single host? Using the V8 configuration macros, use: MASQUERADE_AS(my.dom.ain) This will cause all addresses to be sent out as being from the indicated domain. ---------------------------------------------------------------------- * How do I rewrite my From: lines to read ``First_Last@My.Domain''? There are a couple of ways of doing this. This describes using the "user database" code. This is still experimental, and was intended for a different purpose -- however, it does work with a bit of care. It does require that you have the Berkeley "db" package installed (it won't work with DBM). First, create your input file. This should have lines like: loginname:mailname First_Last First_Last:maildrop loginname Install it in (say) /etc/userdb. Create the database: makemap btree /etc/userdb.db < /etc/userdb You can then create a config file that uses this. You will have to include the following in your .mc file: define(confUSERDB_SPEC, /etc/userdb.db) FEATURE(notsticky) ---------------------------------------------------------------------- * So what was the user database feature intended for? The intent was to have all information for a given user (where the user is the unique login name, not an inherently non-unique full name) in one place. This would include phone numbers, addresses, and so forth. The "maildrop" feature is because Berkeley does not use a centralized mail server (there are a number of reasons for this that are mostly historic), and so we need to know where each user gets his or her mail delivered -- i.e., the mail drop. We are in the process of setting up our environment so that mail sent to an unqualified "name" goes to that person's preferred maildrop; mail sent to "name@host" goes to that host. The purpose of "FEATURE(notsticky)" is to cause "name@host" to be looked up in the user database for delivery to the maildrop. ---------------------------------------------------------------------- * Why are you so hostile to using full names for e-mail addresses? Because full names are not unique. For example, the computer community has two Andy Tannenbaums and two Peter Deutsches. At one time, Bell Labs had two Stephen R. Bournes with offices a few doors apart. You can create alternative addresses (e.g., Stephen_R_Bourne_2), but that's even worse -- which one of them has to have their name desecrated in this way? And you can bet that they will get most of the other person's email. So called "full names" are just longer versions of unique names. Rather that lulling people into a sense of security, I'd rather that it be clear that these handles are arbitrary. People should use good user agents that have alias mappings so that they can attach arbitrary names for their personal use to those with whom they correspond. Even worse is fuzzy matching in e-mail -- this can make good addresses turn bad. For example, I'm currently (to the best of my knowledge) the only ``Allman'' at Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to me. But if another Allman ever appears, this address could suddenly become ambiguous. I've been the only Allman at Berkeley for over fifteen years -- to suddenly have this "good address" bounce mail because it is ambiguous would be a heinous wrong. Finger services should be as fuzzy as possible. Mail services should be unique. ---------------------------------------------------------------------- * When I use sendmail V8 with a Sun config file I get lines like: /etc/sendmail.cf: line 273: replacement $3 out of bounds the line in question reads: R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether what does this mean? How do I fix it? V8 doesn't recognize the Sun "$%y" syntax, so as far as it is concerned, there is only a $1 and a $2 (but no $3) in this line. Read Rick McCarty's paper on "Converting Standard Sun Config Files to Sendmail Version 8", in the contrib directory (file "converting.sun.configs") on the sendmail distribution for a full discussion of how to do this. ---------------------------------------------------------------------- * Should I use a wildcard MX for my domain? If at all possible, no. Wildcard MX records have lots of semantic "gotcha"s. For example, they will match a host "unknown.your.domain" -- if you don't explicitly test for unknown hosts in your domain, you will get "config error: mail loops back to myself" errors. ---------------------------------------------------------------------- * I'm connected to the network via a SLIP link. Sometimes my sendmail process hangs (although it looks like part of the message has been transfered). Everything else works. What's wrong? Most likely, the problem isn't sendmail at all, but the low level network connection. It's important that the MTU (Maximum Transfer Unit) for the SLIP connection be set properly at both ends. If they disagree, large packets will be trashed and the connection will hang. ---------------------------------------------------------------------- * I just upgraded to 8.x and suddenly I'm getting messages in my syslog of the form "collect: I/O error on connection". What is going wrong? Nothing. This is just a diagnosis of a condition that had not been diagnosed before. If you are getting a lot of these from a single host, there is probably some incompatibility between 8.x and that host. If you get a lot of them in general, you may have network problems that are causing connections to get reset. ---------------------------------------------------------------------- * How can I get sendmail to deliver local mail to $HOME/.mail instead of into /usr/spool/mail (or /usr/mail)? This is a local mailer issue, not a sendmail issue. Either modify your local mailer (source code will be required) or change the program called in the "local" mailer configuration description to be a new program that does this local delivery. I understand that "procmail" works well, although I haven't used it myself. You might be interested in reading the paper ``HLFSD: Delivering Email to your $HOME'' available in the Proceedings of the USENIX System Administration (LISA VII) Conference (November 1993). This is also available via public FTP from ftp.cs.columbia.edu:/pub/hlfsd/{README.hlfsd,hlfsd.ps}. ---------------------------------------------------------------------- * Under V8, the "From " header gets mysteriously munged when I send to an alias. ``It's not a bug, it's a feature.'' This happens when you have a "owner-list" alias and you send to "list". V8 propogates the owner information into the envelope sender field (which appears as the "From " header on UNIX mail or as the Return-Path: header) so that downstream errors are properly returned to the mailing list owner instead of to the sender. In order to make this appear as sensible as possible to end users, I recommend making the owner point to a "request" address -- for example: list: :include:/path/name/list.list owner-list: list-request list-request: eric This will make message sent to "list" come out as being "From list-request" instead of "From eric". ---------------------------------------------------------------------- * There are four UUCP mailers listed in the configuration files. Which one should I use? The choice is partly a matter of local preferences and what is running at the other end of your UUCP connection. Unlike good protocols that define what will go over the wire, UUCP uses the policy that you should do what is right for the other end; if they change, you have to change. This makes it hard to do the right thing, and discourages people from updating their software. In general, if you can avoid UUCP, please do. If you can't avoid it, you'll have to find the version that is closest to what the other end accepts. Following is a summary of the UUCP mailers available. uucp-old (obsolete name: "uucp") This is the oldest, the worst (but the closest to UUCP) way of sending messages accros UUCP connections. It does bangify everything and prepends $U (your UUCP name) to the sender's address (which can already be a bang path itself). It can only send to one address at a time, so it spends a lot of time copying duplicates of messages. Avoid this if at all possible. uucp-new (obsolete name: "suucp") The same as above, except that it assumes that in one rmail command you can specify several recipients. It still has a lot of other problems. uucp-dom This UUCP mailer keeps everything as domain addresses. Basically, it uses the SMTP mailer rewriting rules. Unfortunately, a lot of UUCP mailer transport agents require bangified addresses in the envelope, although you can use domain-based addresses in the message header. (The envelope shows up as the From_ line on UNIX mail.) So.... uucp-uudom This is a cross between uucp-new (for the envelope addresses) and uucp-dom (for the header addresses). It bangifies the envelope sender (From_ line in messages) without adding the local hostname, unless there is no host name on the address at all (e.g., "wolf") or the host component is a UUCP host name instead of a domain name ("somehost!wolf" instead of "some.dom.ain!wolf"). Examples: We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). The following summarizes the sender rewriting for various mailers. Mailer sender rewriting in the envelope ------ ------ ------------------------- uucp-{old,new} wolf grasp!wolf uucp-dom wolf wolf@grasp.insa-lyon.fr uucp-uudom wolf grasp.insa-lyon.fr!wolf uucp-{old,new} wolf@fr.net grasp!fr.net!wolf uucp-dom wolf@fr.net wolf@fr.net uucp-uudom wolf@fr.net fr.net!wolf uucp-{old,new} somehost!wolf grasp!somehost!wolf uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf ---------------------------------------------------------------------- * I'm trying to to get my mail to go into queue only mode, and it delivers the mail interactively anyway. (Or, I'm trying to use the "don't deliver to expensive mailer" flag, and it doesn't delivers the mail interactively anyway.) I can see it does it: here's the output of "sendmail -v foo@somehost" (or Mail -v or equivalent). The -v flag to sendmail (which is implied by the -v flag to Mail and other programs in that family) tells sendmail to watch the transaction. Since you have explicitly asked to see what's going on, it assumes that you do not want to to auto-queue, and turns that feature off. Remove the -v flag and use a "tail -f" of the log instead to see what's going on. If you are trying to use the "don't deliver to expensive mailer" flag (mailer flag "e"), be sure you also turn on global option "c" -- otherwise it ignores the mailer flag. ---------------------------------------------------------------------- * I'm getting "Local configuration error" messages, such as: 553 relay.domain.net config error: mail loops back to myself 554 ... Local configuration error How can I solve this problem? You have asked mail to the domain (e.g., domain.net) to be forwarded to a specific host (in this case, relay.domain.net) by using an MX record, but the relay machine doesn't recognize itself as domain.net. Add domain.net to /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" to your configuration file. ---------------------------------------------------------------------- * I want to run Sendmail version 8 on my DEC system, but you don't have MAIL11V3 support in sendmail. How do I handle this? Get Paul Vixie's reimplementation of the mail11 protocol from gatekeeper.dec.com in /pub/DEC/gwtools. ----------------------------------------------------------------------