1*68330SericNewsgroups: comp.mail.sendmail,comp.mail.misc,comp.mail.smail,comp.answers,news.answers 2*68330SericSubject: comp.mail.sendmail Frequently Asked Questions (FAQ) 3*68330SericFrom: brad@birch.ims.disa.mil (Brad Knowles) 4*68330SericFollowup-to: comp.mail.sendmail 5*68330SericSummary: This posting contains a list of Frequently Asked Questions 6*68330Seric (and their answers) about the program "sendmail", distributed 7*68330Seric with many versions of Unix (and available for some other 8*68330Seric operating systems). This FAQ is shared between 9*68330Seric comp.mail.sendmail and the Sendmail V8 distribution. It should 10*68330Seric be read by anyone who wishes to post to comp.mail.sendmail, or 11*68330Seric anyone having questions about the newsgroup itself. 12*68330Seric 13*68330SericArchive-name: mail/sendmail-faq 14*68330SericPosting-Frequency: monthly (first Monday) 15*68330SericLast-modified: Sat Feb 11 03:26:18 EST 1995 16*68330Seric 17*68330Seric 18*68330Seric[The most recent copy of this document can be obtained via anonymous 19*68330SericFTP as rtfm.mit.edu:/pub/usenet/news.answers/mail/sendmail-faq. If 20*68330Sericyou do not have access to anonymous FTP, you can retrieve it by 21*68330Sericsending email to mail-server@rtfm.mit.edu with the command "send 22*68330Sericusenet/news.answers/mail/sendmail-faq" in the message.] 23*68330Seric 24*68330Seric 25*68330Seric 2666282Seric Sendmail Version 8 2766282Seric Frequently Asked Questions 28*68330Seric Last updated 02/14/95 2966282Seric 3066282Seric 31*68330SericThis FAQ is specific to Version 8.6.9 of sendmail. Other questions, 32*68330Sericparticularly regarding compilation and configuration, are answered in 33*68330Sericsrc/READ_ME and cf/README (found in the V8 sendmail distribution). 3466282Seric 35*68330SericThis is also the official FAQ for the Usenet newsgroup 36*68330Sericcomp.mail.sendmail. 37*68330Seric 3868069Seric====================================================================== 39*68330SericBEFORE YOU GO ANY FURTHER 4068069Seric====================================================================== 4168069Seric 42*68330Seric * What do you wish everyone would do before sending you mail or 43*68330Seric posting to comp.mail.sendmail? 4467892Seric 4567892Seric Read this FAQ completely. Read src/READ_ME and cf/README 46*68330Seric completely. Read the books written to help with common 47*68330Seric problems such as compilation and installation, configuration, 48*68330Seric security issues, etc.... Ask themselves if their question 49*68330Seric hasn't already been answered. 5067892Seric---------------------------------------------------------------------- 51*68330Seric * How can I be sure if this is the right place to look for answers 52*68330Seric to my questions? 53*68330Seric 54*68330Seric 1. Do you know, for a fact, that the question is related to 55*68330Seric sendmail V8 or IDA sendmail? 56*68330Seric 57*68330Seric 2. Do you know, for a fact, that the question is related to an 58*68330Seric older version of sendmail? 59*68330Seric 60*68330Seric 3. Is the question about a sendmail-like program (e.g., Smail, 61*68330Seric Zmailer, MMDF, etc...)? 62*68330Seric 63*68330Seric 4. Is the question about an SMTP Gateway product for a LAN mail 64*68330Seric package (e.g., cc:Mail, MS-Mail WordPerfect Office/GroupWise, 65*68330Seric etc...)? 66*68330Seric 67*68330Seric If you answered "yes" to the question #1, then this is the 68*68330Seric right place. 69*68330Seric 70*68330Seric If you answered "yes" to questions #2 or #3, then you should 71*68330Seric seriously consider upgrading to the most recent version of 72*68330Seric sendmail V8. 73*68330Seric 74*68330Seric For question #2, If you're going to contiue using an older 75*68330Seric version of sendmail, you may not find much help and will 76*68330Seric probably get some responses that amount to "Get V8". 77*68330Seric Otherwise, this is probably the best place to look for 78*68330Seric answers. 79*68330Seric 80*68330Seric If you answered "yes" to question #3 and are not going to 81*68330Seric upgrade to sendmail V8, then this is probably not the right 82*68330Seric place to look. 83*68330Seric 84*68330Seric If you answered "yes" to question #4, then this is almost 85*68330Seric certainly not the right place to look. 86*68330Seric 87*68330Seric For questions #3 and #4, try looking around elsewhere in the 88*68330Seric "comp.mail.*" hierarchy for a more appropriate newsgroup. 89*68330Seric For example, you might want to try posting to comp.mail.misc 90*68330Seric or comp.mail.smail. 91*68330Seric 92*68330Seric If you couldn't answer "yes" to any of the above questions, 93*68330Seric then you're DEFINITELY asking in the wrong place. For the 94*68330Seric sake of your sanity and ego, not to mention avoiding the 95*68330Seric waste of your time and ours, try asking your System or E-Mail 96*68330Seric Administrator(s) before you post any questions publicly. 97*68330Seric---------------------------------------------------------------------- 98*68330Seric * Where can I find the latest version of this FAQ? 99*68330Seric 100*68330Seric It is included in the most recent Version 8 distribution of 101*68330Seric sendmail (described below), as well as via anonymous FTP from 102*68330Seric rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq. 103*68330Seric If you do not have access to anonymous FTP, you can retrieve 104*68330Seric it by sending email to mail-server@rtfm.mit.edu with the 105*68330Seric command "send usenet/news.answers/mail/sendmail-faq" in the 106*68330Seric message. 107*68330Seric---------------------------------------------------------------------- 108*68330Seric * I don't have access to Usenet news. Can I still get access to 109*68330Seric comp.mail.sendmail? 110*68330Seric 111*68330Seric Yes. Send email to mxt@dl.ac.uk with the command "sub 112*68330Seric comp-news.comp.mail.sendmail <full-US-ordered-email-address>" 113*68330Seric in the message. 114*68330Seric 115*68330Seric E-mail you want posted on comp.mail.sendmail should be sent 116*68330Seric to comp-mail-sendmail@dl.ac.uk 117*68330Seric---------------------------------------------------------------------- 118*68330Seric * I have sendmail-related DNS questions. Where should I ask them? 119*68330Seric 120*68330Seric Depending on how deeply they get into the DNS, they can be 121*68330Seric asked here. However, you'll probably be told that you should 122*68330Seric send them to the Info-BIND mailing list (if the question is 123*68330Seric specific to that program) or to the Usenet newsgroup 124*68330Seric comp.protocols.tcp-ip.domains (DNS in general). 125*68330Seric---------------------------------------------------------------------- 126*68330Seric * How do I subscribe to either of these? 127*68330Seric 128*68330Seric For comp.protocols.tcp-ip.domains, you have to be on Usenet. 129*68330Seric They don't have a news-to-mail gateway yet. 130*68330Seric 131*68330Seric For the Info-BIND mailing list, send email to 132*68330Seric bind-request@uunet.uu.net with the command "subscribe" in the 133*68330Seric message. Submissions should be sent to bind@uunet.uu.net 134*68330Seric 135*68330Seric====================================================================== 136*68330SericGENERAL QUESTIONS 137*68330Seric====================================================================== 138*68330Seric 13967021Seric * Where can I get Version 8? 14067021Seric 14167021Seric Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. 14267021Seric---------------------------------------------------------------------- 14366282Seric * What are the differences between Version 8 and other versions? 14466282Seric 14567021Seric See doc/changes/changes.me in the sendmail distribution. 14666282Seric---------------------------------------------------------------------- 14766282Seric * What happened to sendmail 6.x and 7.x? 14866282Seric 149*68330Seric When a new (Alpha/Beta) version of sendmail was released, it 150*68330Seric was changed to Release 6. Development continued in that tree 151*68330Seric until 4.4BSD was released, when everything on the 4.4 tape 152*68330Seric was set to be version 8.1. Version 7.x never existed. 15366282Seric---------------------------------------------------------------------- 15468069Seric * What books are available describing sendmail? 15568069Seric 15668069Seric There is one book available devoted to sendmail: 15768069Seric 15868069Seric Costales, Allman, and Rickert, _Sendmail_. O'Reilly & 15968069Seric Associates. 16068069Seric 16168069Seric Several books have sendmail chapters, for example: 16268069Seric 16368069Seric Nemeth, Snyder, and Seebass, _Unix System Administration 16468069Seric Handbook_. Prentice-Hall. 16568069Seric Carl-Mitchell and Quarterman, _Practical Internetworking with 16668069Seric TCP/IP and UNIX_. Addison-Wesley. 16768069Seric Hunt, _TCP/IP Network Administration_. O'Reilly & Associates. 16868069Seric 16968069Seric Another book about sendmail is due out "soon": 17068069Seric 17168069Seric Avolio & Vixie, _Sendmail Theory and Practice_. Digital 17268069Seric Press (release date unknown). 17368069Seric 174*68330Seric For details on sendmail-related DNS issues, consult: 175*68330Seric 176*68330Seric Liu and Albitz, _DNS and BIND_. O'Reilly & Associates. 177*68330Seric 178*68330Seric For details on UUCP, see: 179*68330Seric 180*68330Seric O'Reilly and Todino, _Managing UUCP and Usenet_. 181*68330Seric O'Reilly & Associates. 182*68330Seric 18368069Seric====================================================================== 18468069SericCOMPILING AND INSTALLING SENDMAIL 8 18568069Seric====================================================================== 18668069Seric 18766282Seric * Version 8 requires a new version of "make". Where can I get this? 18866282Seric 18966282Seric Actually, Version 8 does not require a new version of "make". 19066282Seric It includes a collection of Makefiles for different architectures, 19167892Seric only one or two of which require the new "make". For a supported 19267892Seric architecture, use ``sh makesendmail''. If you are porting to a 19367892Seric new architecture, start with Makefile.dist. 19466282Seric 19566282Seric If you really do want the new make, it is available on any of 19667021Seric the BSD Net2 or 4.4-Lite distribution sites. These include: 19766282Seric 19866282Seric ftp.uu.net /systems/unix/bsd-sources 19966282Seric gatekeeper.dec.com /.0/BSD/net2 20066282Seric ucquais.cba.uc.edu /pub/net2 20166282Seric ftp.luth.se /pub/unix/4.3bsd/net2 20266282Seric 203*68330Seric Diffs and instructions for building this version of make 204*68330Seric under SunOS 4.1.x are available on ftp.css.itd.umich.edu in 205*68330Seric /pub/systems/sun/Net2-make.sun4.diff.Z. A patchkit for 206*68330Seric Ultrix is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z. 207*68330Seric Patches for AIX 3.2.4 are available on ftp.uni-stuttgart.de 208*68330Seric in /sw/src/patches/bsd-make-rus-patches. 20967489Seric 21067489Seric There is also a Linux version available on the main Linux 21167489Seric distribution sites as pmake; this version is included as 21267489Seric standard with the current Slackware distributions. 21366282Seric---------------------------------------------------------------------- 21466282Seric * What macro package do I use to format the V8 man pages? 21566282Seric 216*68330Seric The BSD group switched over the the ``mandoc'' macros for the 217*68330Seric 4.4 release. These include more hooks designed for hypertext 218*68330Seric handling. However, new man pages won't format under the old 219*68330Seric man macros. Fortunately, old man pages will format under the 220*68330Seric new mandoc macros. 22166282Seric 222*68330Seric Get the new macros with the BSD Net2 or 4.4-Lite release (see 223*68330Seric above for locations; for example, on FTP.UU.NET the files 224*68330Seric /system/unix/bsd-sources/share/tmac/me/strip/sed and 225*68330Seric /system/unix/bsd-sources/share/tmac/* are what you need). 22666282Seric 227*68330Seric This macro set is also included with newer versions of groff. 22868070Seric---------------------------------------------------------------------- 22968070Seric * What modes should be used when installing sendmail? 23066282Seric 23168070Seric The sendmail binary should be owned by root, mode 4755. 23268070Seric The queue directory should be owned by root, with a mode 233*68330Seric between 700 and 755. Under no circumstances should 234*68330Seric it be group or other writable! 23568070Seric The sendmail config file should be owned by root, mode 644. 23668070Seric The aliases file should generally be owned by one trusted 237*68330Seric user and writable only by that user, although it is 238*68330Seric not unreasonable to have it group writable by a 239*68330Seric "sysadmin" group. It should not be world writable. 24068070Seric The aliases database files (aliases.db or aliases.{pag,dir} 24168070Seric depending on what database format you compile with) 24268070Seric should be owned by root, mode 644. 24368070Seric 24468069Seric====================================================================== 24568069SericCONFIGURATION QUESTIONS 24668069Seric====================================================================== 24766282Seric 24866282Seric * How do I make all my addresses appear to be from a single host? 24966282Seric 25066282Seric Using the V8 configuration macros, use: 25166282Seric 25266282Seric MASQUERADE_AS(my.dom.ain) 25366282Seric 25466282Seric This will cause all addresses to be sent out as being from 25566282Seric the indicated domain. 25666282Seric---------------------------------------------------------------------- 25766282Seric * How do I rewrite my From: lines to read ``First_Last@My.Domain''? 25866282Seric 259*68330Seric There are a couple of ways of doing this. This describes 260*68330Seric using the "user database" code. This is still experimental, 261*68330Seric and was intended for a different purpose -- however, it does 262*68330Seric work with a bit of care. It does require that you have the 263*68330Seric Berkeley "db" package installed (it won't work with DBM). 26466282Seric 26566282Seric First, create your input file. This should have lines like: 26666282Seric 26766282Seric loginname:mailname First_Last 26866282Seric First_Last:maildrop loginname 26966282Seric 27066282Seric Install it in (say) /etc/userdb. Create the database: 27166282Seric 27266282Seric makemap btree /etc/userdb.db < /etc/userdb 27366282Seric 27466282Seric You can then create a config file that uses this. You will 27566282Seric have to include the following in your .mc file: 27666282Seric 27766282Seric define(confUSERDB_SPEC, /etc/userdb.db) 27866282Seric FEATURE(notsticky) 27966282Seric---------------------------------------------------------------------- 28066282Seric * So what was the user database feature intended for? 28166282Seric 282*68330Seric The intent was to have all information for a given user 283*68330Seric (where the user is the unique login name, not an inherently 284*68330Seric non-unique full name) in one place. This would include phone 285*68330Seric numbers, addresses, and so forth. The "maildrop" feature is 286*68330Seric because Berkeley does not use a centralized mail server 287*68330Seric (there are a number of reasons for this that are mostly 288*68330Seric historic), and so we need to know where each user gets his or 289*68330Seric her mail delivered -- i.e., the mail drop. 29066282Seric 29166282Seric We are in the process of setting up our environment so that 29266282Seric mail sent to an unqualified "name" goes to that person's 29366282Seric preferred maildrop; mail sent to "name@host" goes to that 29466282Seric host. The purpose of "FEATURE(notsticky)" is to cause 29566282Seric "name@host" to be looked up in the user database for delivery 29666282Seric to the maildrop. 29766282Seric---------------------------------------------------------------------- 29866282Seric * Why are you so hostile to using full names for e-mail addresses? 29966282Seric 30066282Seric Because full names are not unique. For example, the computer 30166282Seric community has two Andy Tannenbaums and two Peter Deutsches. 302*68330Seric At one time, Bell Labs had two Stephen R. Bournes with 303*68330Seric offices a few doors apart. You can create alternative 304*68330Seric addresses (e.g., Stephen_R_Bourne_2), but that's even worse 305*68330Seric -- which one of them has to have their name desecrated in 306*68330Seric this way? And you can bet that one of them will get most of 307*68330Seric the other person's e-mail. 30866282Seric 30967892Seric So called "full names" are just an attempt to create longer 31067892Seric versions of unique names. Rather that lulling people into a 31167892Seric sense of security, I'd rather that it be clear that these 31267892Seric handles are arbitrary. People should use good user agents 31367892Seric that have alias mappings so that they can attach arbitrary 314*68330Seric names for their personal use to those with whom they 315*68330Seric correspond (such as the MH alias file). 31666282Seric 31766282Seric Even worse is fuzzy matching in e-mail -- this can make good 318*68330Seric addresses turn bad. For example, Eric Allman is currently 319*68330Seric (to the best of our knowledge) the only ``Allman'' at 320*68330Seric Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to 321*68330Seric him. But if another Allman ever appears, this address could 322*68330Seric suddenly become ambiguous. He's been the only Allman at 323*68330Seric Berkeley for over fifteen years -- to suddenly have this 324*68330Seric "good address" bounce mail because it is ambiguous would be a 325*68330Seric heinous wrong. 32666282Seric 32767892Seric Finger services should be as fuzzy as possible (within 32867892Seric reason, of course). Mail services should be unique. 32966282Seric---------------------------------------------------------------------- 33068069Seric * Should I use a wildcard MX for my domain? 33168069Seric 33268069Seric If at all possible, no. 33368069Seric 33468069Seric Wildcard MX records have lots of semantic "gotcha"s. For 33568069Seric example, they will match a host "unknown.your.domain" -- if 33668069Seric you don't explicitly test for unknown hosts in your domain, 33768069Seric you will get "config error: mail loops back to myself" 33868069Seric errors. 33968069Seric---------------------------------------------------------------------- 340*68330Seric * How can I get sendmail to process messages sent to an account and 341*68330Seric send the results back to the originator? 342*68330Seric 343*68330Seric This is a local mailer issue, not a sendmail issue. 344*68330Seric Depending on what you're doing, look at procmail (mentioned 345*68330Seric again below), ftpmail, or Majordomo. 346*68330Seric 347*68330Seric Check your local archie server to see what machine(s) nearest 348*68330Seric you have the most recent versions of these programs. 349*68330Seric---------------------------------------------------------------------- 35068069Seric * How can I get sendmail to deliver local mail to $HOME/.mail 35168069Seric instead of into /usr/spool/mail (or /usr/mail)? 35268069Seric 353*68330Seric Again, this is a local mailer issue, not a sendmail issue. 354*68330Seric Either modify your local mailer (source code will be 355*68330Seric required) or change the program called in the "local" mailer 356*68330Seric configuration description to be a new program that does this 357*68330Seric local delivery. I understand that "procmail" works well, 358*68330Seric although I haven't used it myself. 35968069Seric 360*68330Seric You might be interested in reading the paper ``HLFSD: 361*68330Seric Delivering Email to your $HOME'' available in the Proceedings 362*68330Seric of the USENIX System Administration (LISA VII) Conference 363*68330Seric (November 1993). This is also available via public FTP from 364*68330Seric ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}. 36568069Seric---------------------------------------------------------------------- 36668069Seric * I'm trying to to get my mail to go into queue only mode, and it 36768069Seric delivers the mail interactively anyway. (Or, I'm trying to use 368*68330Seric the "don't deliver to expensive mailer" flag, and it delivers the 369*68330Seric mail interactively anyway.) I can see it does it: here's the 370*68330Seric output of "sendmail -v foo@somehost" (or Mail -v or equivalent). 37168069Seric 37268069Seric The -v flag to sendmail (which is implied by the -v flag to 37368069Seric Mail and other programs in that family) tells sendmail to 37468069Seric watch the transaction. Since you have explicitly asked to 37568069Seric see what's going on, it assumes that you do not want to to 37668069Seric auto-queue, and turns that feature off. Remove the -v flag 377*68330Seric and use a "tail -f" of the log instead to see what's going 378*68330Seric on. 37968069Seric 380*68330Seric If you are trying to use the "don't deliver to expensive 381*68330Seric mailer" flag (mailer flag "e"), be sure you also turn on 382*68330Seric global option "c" -- otherwise it ignores the mailer flag. 38368069Seric---------------------------------------------------------------------- 38468069Seric * There are four UUCP mailers listed in the configuration files. 38568069Seric Which one should I use? 38668069Seric 387*68330Seric The choice is partly a matter of local preferences and what 388*68330Seric is running at the other end of your UUCP connection. Unlike 389*68330Seric good protocols that define what will go over the wire, UUCP 390*68330Seric uses the policy that you should do what is right for the 391*68330Seric other end; if they change, you have to change. This makes it 392*68330Seric hard to do the right thing, and discourages people from 393*68330Seric updating their software. In general, if you can avoid UUCP, 394*68330Seric please do. 39568069Seric 396*68330Seric If you can't avoid it, you'll have to find the version that 397*68330Seric is closest to what the other end accepts. Following is a 398*68330Seric summary of the UUCP mailers available. 39968069Seric 40068069Seric uucp-old (obsolete name: "uucp") 401*68330Seric This is the oldest, the worst (but the closest to UUCP) way 402*68330Seric of sending messages across UUCP connections. It does 403*68330Seric bangify everything and prepends $U (your UUCP name) to the 404*68330Seric sender's address (which can already be a bang path 405*68330Seric itself). It can only send to one address at a time, so it 406*68330Seric spends a lot of time copying duplicates of messages. Avoid 407*68330Seric this if at all possible. 40868069Seric 40968069Seric uucp-new (obsolete name: "suucp") 41068069Seric The same as above, except that it assumes that in one rmail 41168069Seric command you can specify several recipients. It still has a 41268069Seric lot of other problems. 41368069Seric 41468069Seric uucp-dom 41568069Seric This UUCP mailer keeps everything as domain addresses. 41668069Seric Basically, it uses the SMTP mailer rewriting rules. 41768069Seric 418*68330Seric Unfortunately, a lot of UUCP mailer transport agents 419*68330Seric require bangified addresses in the envelope, although you 420*68330Seric can use domain-based addresses in the message header. (The 421*68330Seric envelope shows up as the From_ line on UNIX mail.) So.... 42268069Seric 42368069Seric uucp-uudom 424*68330Seric This is a cross between uucp-new (for the envelope 425*68330Seric addresses) and uucp-dom (for the header addresses). It 426*68330Seric bangifies the envelope sender (From_ line in messages) 427*68330Seric without adding the local hostname, unless there is no host 428*68330Seric name on the address at all (e.g., "wolf") or the host 429*68330Seric component is a UUCP host name instead of a domain name 430*68330Seric ("somehost!wolf" instead of "some.dom.ain!wolf"). 43168069Seric 43268069Seric Examples: 43368069Seric 434*68330Seric We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). 435*68330Seric The following summarizes the sender rewriting for various 436*68330Seric mailers. 43768069Seric 43868069Seric Mailer sender rewriting in the envelope 43968069Seric ------ ------ ------------------------- 44068069Seric uucp-{old,new} wolf grasp!wolf 44168069Seric uucp-dom wolf wolf@grasp.insa-lyon.fr 44268069Seric uucp-uudom wolf grasp.insa-lyon.fr!wolf 44368069Seric 44468069Seric uucp-{old,new} wolf@fr.net grasp!fr.net!wolf 44568069Seric uucp-dom wolf@fr.net wolf@fr.net 44668069Seric uucp-uudom wolf@fr.net fr.net!wolf 44768069Seric 44868069Seric uucp-{old,new} somehost!wolf grasp!somehost!wolf 44968069Seric uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr 45068069Seric uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf 45168069Seric 45268069Seric====================================================================== 45368069SericRESOLVING PROBLEMS 45468069Seric====================================================================== 45568069Seric 45668069Seric * When I compile, I get "undefined symbol inet_aton" messages. 45768069Seric 45868069Seric You've probably replaced your resolver with the version from 459*68330Seric BIND 4.9.3. You need to compile with -l44bsd in order to get 46068069Seric the additional routines. 46168069Seric---------------------------------------------------------------------- 46267892Seric * I'm getting "Local configuration error" messages, such as: 46367892Seric 46467892Seric 553 relay.domain.net config error: mail loops back to myself 46567892Seric 554 <user@domain.net>... Local configuration error 46667892Seric 46767892Seric How can I solve this problem? 46867892Seric 46967892Seric You have asked mail to the domain (e.g., domain.net) to be 47067892Seric forwarded to a specific host (in this case, relay.domain.net) 471*68330Seric by using an MX record, but the relay machine doesn't 472*68330Seric recognize itself as domain.net. Add domain.net to 473*68330Seric /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or 474*68330Seric add "Cw domain.net" to your configuration file. 47567898Seric 47667898Seric IMPORTANT: Be sure you kill and restart the sendmail daemon 47767898Seric after you change the configuration file (for ANY change in 47867898Seric the configuration, not just this one): 47967898Seric 48067898Seric kill `head -1 /etc/sendmail.pid` 48167898Seric sh -c "`tail -1 /etc/sendmail.pid`" 48267898Seric 48367898Seric NOTA BENE: kill -1 does not work! 48467892Seric---------------------------------------------------------------------- 48566282Seric * When I use sendmail V8 with a Sun config file I get lines like: 48666282Seric 48766282Seric /etc/sendmail.cf: line 273: replacement $3 out of bounds 48866282Seric 48966282Seric the line in question reads: 49066282Seric 49166282Seric R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether 49266282Seric 49366282Seric what does this mean? How do I fix it? 49466282Seric 495*68330Seric V8 doesn't recognize the Sun "$%y" syntax, so as far as it is 496*68330Seric concerned, there is only a $1 and a $2 (but no $3) in this 49766282Seric line. Read Rick McCarty's paper on "Converting Standard Sun 49866282Seric Config Files to Sendmail Version 8", in the contrib directory 49966282Seric (file "converting.sun.configs") on the sendmail distribution 50066282Seric for a full discussion of how to do this. 50166282Seric---------------------------------------------------------------------- 502*68330Seric * When I use sendmail V8 on a Sun, I sometimes get lines like: 50366282Seric 504*68330Seric /etc/sendmail.cf: line 445: bad ruleset 96 (50 max) 505*68330Seric 506*68330Seric what does this mean? How do I fix it? 507*68330Seric 508*68330Seric You're somehow trying to start up the old Sun sendmail (or 509*68330Seric sendmail.mx) with a sendmail V8 config file, which Sun's 510*68330Seric sendmail doesn't like. Check your /etc/rc.local, any 511*68330Seric procedures that have been created to stop and re-start the 512*68330Seric sendmail processes, etc.... Make sure that you've switched 513*68330Seric everything over to using the new sendmail. To keep this 514*68330Seric problem from ever happening again, try the following: 515*68330Seric 516*68330Seric mv /usr/lib/sendmail /usr/lib/sendmail.old 517*68330Seric ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail 518*68330Seric mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old 519*68330Seric ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx 520*68330Seric chmod 0000 /usr/lib/sendmail.old 521*68330Seric chmod 0000 /usr/lib/sendmail.mx.old 522*68330Seric 523*68330Seric Assuming you have installed sendmail V8 in /usr/local/lib. 524*68330Seric---------------------------------------------------------------------- 525*68330Seric * When I use sendmail V8 on an IBM RS/6000 running AIX, the system 526*68330Seric resource controller always reports sendmail as "inoperative" even 527*68330Seric though it is running. What's wrong? 528*68330Seric 529*68330Seric IBM's system resource controller is one of their "value 530*68330Seric added" features to AIX -- it's not a Unix standard. You'll 531*68330Seric need to either redefine the subsystem to use signals (see 532*68330Seric chssys(1)) or dump the entire subsystem and invoke sendmail 533*68330Seric in /etc/rc.tcpip or some other boot script. 534*68330Seric---------------------------------------------------------------------- 535*68330Seric * When I use sendmail V8 on an Intel x86 machine running Linux, I 536*68330Seric have some problems. Specifically, I have.... 537*68330Seric 538*68330Seric The current versions of Linux are generally considered to be 539*68330Seric great for hobbiests and anyone else who wants to learn Unix 540*68330Seric inside and out, or wants to always have something to do, or 541*68330Seric just wants a machine for themselves and not a whole bunch of 542*68330Seric other users. 543*68330Seric 544*68330Seric However, for those who want a system that will just sit in 545*68330Seric the background and work without a fuss handling thousands of 546*68330Seric mail messages a day for lots of different users, it's not 547*68330Seric (yet) stable enough to fit the bill. 548*68330Seric 549*68330Seric Unfortunately, there are no known shareware/freeware 550*68330Seric implementations of any operating system that provides the 551*68330Seric level of stability necessary to handle that kind of load. If 552*68330Seric you're wedded to the Intel x86 platform, you need to look at 553*68330Seric commercial implementations of Unix such as Interactive, 554*68330Seric UnixWare, Solaris, or BSDI's 386BSD. Of the commercial 555*68330Seric implementations, BSDI's 386BSD is the only one known to 556*68330Seric currently ship with sendmail V8 and a recent version of BIND 557*68330Seric pre-installed. It is also the least expensive. 558*68330Seric---------------------------------------------------------------------- 559*68330Seric * When I use sendmail on an Intel x86 machine running OS/2, I have 560*68330Seric some problems. Specifically, I have.... 561*68330Seric 562*68330Seric The OS/2 port of sendmail is known to have left out huge 563*68330Seric chunks of the code and functionality of even much older 564*68330Seric versions of sendmail, in large part because the underlying OS 565*68330Seric just doesn't have the necessary hooks to make it happen. 566*68330Seric This port is so broken that we make no attempt to provide any 567*68330Seric kind of support for it. Try BSDI's 386BSD instead. 568*68330Seric---------------------------------------------------------------------- 569*68330Seric * I'm connected to the network via a SLIP/PPP link. Sometimes my 570*68330Seric sendmail process hangs (although it looks like part of the 571*68330Seric message has been transfered). Everything else works. What's 572*68330Seric wrong? 573*68330Seric 57466282Seric Most likely, the problem isn't sendmail at all, but the low 575*68330Seric level network connection. It's important that the MTU 576*68330Seric (Maximum Transfer Unit) for the SLIP connection be set 577*68330Seric properly at both ends. If they disagree, large packets will 578*68330Seric be trashed and the connection will hang. 57966282Seric---------------------------------------------------------------------- 58066282Seric * I just upgraded to 8.x and suddenly I'm getting messages in my 58166282Seric syslog of the form "collect: I/O error on connection". What is 58266282Seric going wrong? 58366282Seric 584*68330Seric Nothing. This is just a diagnosis of a condition that had 585*68330Seric not been diagnosed before. If you are getting a lot of these 586*68330Seric from a single host, there is probably some incompatibility 587*68330Seric between 8.x and that host. If you get a lot of them in 588*68330Seric general, you may have network problems that are causing 589*68330Seric connections to get reset. 59066282Seric---------------------------------------------------------------------- 59167892Seric * I just upgraded to 8.x and suddenly connections to the SMTP port 59267892Seric take a long time. What is going wrong? 59367892Seric 594*68330Seric It's probably something weird in your TCP implementation that 59567892Seric makes the IDENT code act oddly. On most systems V8 tries to 59667892Seric do a ``callback'' to the connecting host to get a validated 597*68330Seric user name (see RFC 1413 for detail). If the connecting host 598*68330Seric does not support such a service it will normally fail quickly 599*68330Seric with "Connection refused", but certain kinds of packet 600*68330Seric filters and certain TCP implementations just time out. 60167892Seric 60267892Seric To test this, set the IDENT timeout to zero using 60367892Seric ``OrIdent=0'' in the configuration file. This will 60467892Seric completely disable all use of the IDENT protocol. 60567892Seric 60667892Seric Another possible problem is that you have your name server 607*68330Seric and/or resolver configured improperly. Make sure that all 608*68330Seric "nameserver" entries in /etc/resolv.conf point to functional 609*68330Seric servers. If you are running your own server make certain 610*68330Seric that all the servers listed in your root cache (usually 611*68330Seric called something like "/var/namedb/root.cache"; see your 61267892Seric /etc/named.boot file to get your value) are up to date. 61367892Seric Either of these can cause long delays. 61467892Seric---------------------------------------------------------------------- 61567892Seric * I just upgraded to 8.x and suddenly I get errors such as ``mail: 61667892Seric options must follow recipients.'' What is going wrong? 61767892Seric 61867892Seric You need OSTYPE(systype) in your .mc file -- otherwise the 61967892Seric configurations use a default that probably disagrees with 62067892Seric your local mail system. See cf/README for details. 62167892Seric---------------------------------------------------------------------- 62266282Seric * Under V8, the "From " header gets mysteriously munged when I send 62366282Seric to an alias. 62466282Seric 625*68330Seric ``It's not a bug, it's a feature.'' This happens when you 626*68330Seric have a "owner-list" alias and you send to "list". V8 627*68330Seric propagates the owner information into the envelope sender 628*68330Seric field (which appears as the "From " header on UNIX mail or as 629*68330Seric the Return-Path: header) so that downstream errors are 630*68330Seric properly returned to the mailing list owner instead of to the 631*68330Seric sender. In order to make this appear as sensible as possible 632*68330Seric to end users, I recommend making the owner point to a 633*68330Seric "request" address -- for example: 63466282Seric 63566282Seric list: :include:/path/name/list.list 63666282Seric owner-list: list-request 63766282Seric list-request: eric 63866282Seric 639*68330Seric This will make message sent to "list" come out as being "From 640*68330Seric list-request" instead of "From eric". 64166282Seric---------------------------------------------------------------------- 642*68330Seric * I am trying to use MASQUERADE_AS (or the user database) to 643*68330Seric rewrite from addresses, and although it works in the From: header 644*68330Seric line, it doesn't work in the envelope (e.g., the "From " line). 645*68330Seric 646*68330Seric Believe it or not, this is intentional. The interpretation 647*68330Seric of the standards by the V8 development group was that this 648*68330Seric was an inappropriate rewriting, and that if the rewriting 649*68330Seric were incorrect at least the envelope would contain a valid 650*68330Seric return address. Other people have since described scenarios 651*68330Seric where the envelope cannot be correct without this rewriting, 652*68330Seric so 8.7 will have an option to rewrite both header and 653*68330Seric envelope. 654*68330Seric---------------------------------------------------------------------- 65566285Seric * I want to run Sendmail version 8 on my DEC system, but you don't 65666285Seric have MAIL11V3 support in sendmail. How do I handle this? 65766285Seric 658*68330Seric Get Paul Vixie's reimplementation of the mail11 protocol from 659*68330Seric gatekeeper.dec.com in /pub/DEC/gwtools. 660*68330Seric 661*68330Seric Rumour has it that he will be fully integrating into sendmail 662*68330Seric V8 what little is left of IDA sendmail that is not handled 663*68330Seric (or handled as well) by V8. No additional information on 664*68330Seric this project is currently available. 66566285Seric---------------------------------------------------------------------- 66668069Seric * Messages seem to disappear from my queue unsent. When I look in 667*68330Seric the queue directory I see that they have been renamed from qf* to 668*68330Seric Qf*, and sendmail doesn't see these. 66968069Seric 67068069Seric If you look closely you should find that the Qf files are 67168069Seric owned by users other than root. Since sendmail runs as root 67268069Seric it refuses to believe information in non-root-owned qf files, 673*68330Seric and it renames them to Qf to get them out of the way and make 674*68330Seric it easy for you to find. The usual cause of this is 67568069Seric twofold: first, you have the queue directory world writable 67668069Seric (which is probably a mistake -- this opens up other security 67768069Seric problems) and someone is calling sendmail with an "unsafe" 67868069Seric flag, usually a -o flag that sets an option that could 67968069Seric compromise security. When sendmail sees this it gives up 68068069Seric setuid root permissions. 68168069Seric 682*68330Seric The usual solution is to not use the problematic flags. If 683*68330Seric you must use them, you have to write a special queue 68468069Seric directory and have them processed by the same uid that 68568069Seric submitted the job in the first place. 68668069Seric---------------------------------------------------------------------- 687*68330Seric@(#)FAQ 8.11 (Berkeley) 02/14/95 688*68330SericSend updates to sendmail@CS.Berkeley.EDU. 689