168330SericNewsgroups: comp.mail.sendmail,comp.mail.misc,comp.mail.smail,comp.answers,news.answers 268330SericSubject: comp.mail.sendmail Frequently Asked Questions (FAQ) 368330SericFrom: brad@birch.ims.disa.mil (Brad Knowles) 468330SericFollowup-to: comp.mail.sendmail 568330SericSummary: This posting contains a list of Frequently Asked Questions 668330Seric (and their answers) about the program "sendmail", distributed 768330Seric with many versions of Unix (and available for some other 868330Seric operating systems). This FAQ is shared between 968330Seric comp.mail.sendmail and the Sendmail V8 distribution. It should 1068330Seric be read by anyone who wishes to post to comp.mail.sendmail, or 1168330Seric anyone having questions about the newsgroup itself. 1268330Seric 1368330SericArchive-name: mail/sendmail-faq 1468330SericPosting-Frequency: monthly (first Monday) 1568330Seric 1668330Seric 1768330Seric[The most recent copy of this document can be obtained via anonymous 18*68445SericFTP from rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq. 19*68445SericIf you do not have access to anonymous FTP, you can retrieve it by 2068330Sericsending email to mail-server@rtfm.mit.edu with the command "send 2168330Sericusenet/news.answers/mail/sendmail-faq" in the message.] 2268330Seric 2368330Seric 2468330Seric 2566282Seric Sendmail Version 8 2666282Seric Frequently Asked Questions 27*68445Seric Last updated 02/24/95 2866282Seric 2966282Seric 30*68445SericThis FAQ is specific to Version 8.6.10 of sendmail. Other questions, 3168330Sericparticularly regarding compilation and configuration, are answered in 3268330Sericsrc/READ_ME and cf/README (found in the V8 sendmail distribution). 3366282Seric 3468330SericThis is also the official FAQ for the Usenet newsgroup 3568330Sericcomp.mail.sendmail. 3668330Seric 3768069Seric====================================================================== 3868330SericBEFORE YOU GO ANY FURTHER 3968069Seric====================================================================== 4068069Seric 4168330Seric * What do you wish everyone would do before sending you mail or 4268330Seric posting to comp.mail.sendmail? 4367892Seric 4467892Seric Read this FAQ completely. Read src/READ_ME and cf/README 4568330Seric completely. Read the books written to help with common 4668330Seric problems such as compilation and installation, configuration, 4768330Seric security issues, etc.... Ask themselves if their question 4868330Seric hasn't already been answered. 4967892Seric---------------------------------------------------------------------- 5068330Seric * How can I be sure if this is the right place to look for answers 5168330Seric to my questions? 5268330Seric 5368330Seric 1. Do you know, for a fact, that the question is related to 5468334Seric sendmail V8? 5568330Seric 5668330Seric 2. Do you know, for a fact, that the question is related to an 5768330Seric older version of sendmail? 5868330Seric 5968330Seric 3. Is the question about a sendmail-like program (e.g., Smail, 6068330Seric Zmailer, MMDF, etc...)? 6168330Seric 62*68445Seric 4. Is the question about an SMTP Gateway product for a LAN 63*68445Seric mail package (e.g., cc:Mail, MS-Mail, WordPerfect 64*68445Seric Office/GroupWise, etc...)? 6568330Seric 6668330Seric If you answered "yes" to the question #1, then this is the 6768330Seric right place. 6868330Seric 6968330Seric If you answered "yes" to questions #2 or #3, then you should 7068330Seric seriously consider upgrading to the most recent version of 7168330Seric sendmail V8. 7268330Seric 73*68445Seric For question #2, If you're going to continue using an older 7468330Seric version of sendmail, you may not find much help and will 7568330Seric probably get some responses that amount to "Get V8". 7668330Seric Otherwise, this is probably the best place to look for 7768330Seric answers. 7868330Seric 7968330Seric If you answered "yes" to question #3 and are not going to 8068330Seric upgrade to sendmail V8, then this is probably not the right 8168330Seric place to look. 8268330Seric 8368330Seric If you answered "yes" to question #4, then this is almost 8468330Seric certainly not the right place to look. 8568330Seric 8668330Seric For questions #3 and #4, try looking around elsewhere in the 8768330Seric "comp.mail.*" hierarchy for a more appropriate newsgroup. 8868330Seric For example, you might want to try posting to comp.mail.misc 8968330Seric or comp.mail.smail. 9068330Seric 9168330Seric If you couldn't answer "yes" to any of the above questions, 92*68445Seric then you're DEFINITELY in the wrong place. For the sake of 93*68445Seric your sanity and ego, not to mention avoiding the waste of 94*68445Seric your time and ours, try asking your System or E-Mail 9568330Seric Administrator(s) before you post any questions publicly. 9668330Seric---------------------------------------------------------------------- 9768330Seric * Where can I find the latest version of this FAQ? 9868330Seric 9968330Seric It is included in the most recent Version 8 distribution of 10068330Seric sendmail (described below), as well as via anonymous FTP from 10168330Seric rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq. 10268330Seric If you do not have access to anonymous FTP, you can retrieve 10368330Seric it by sending email to mail-server@rtfm.mit.edu with the 10468330Seric command "send usenet/news.answers/mail/sendmail-faq" in the 10568330Seric message. 10668330Seric---------------------------------------------------------------------- 10768330Seric * I don't have access to Usenet news. Can I still get access to 10868330Seric comp.mail.sendmail? 10968330Seric 11068330Seric Yes. Send email to mxt@dl.ac.uk with the command "sub 11168330Seric comp-news.comp.mail.sendmail <full-US-ordered-email-address>" 11268330Seric in the message. 11368330Seric 11468330Seric E-mail you want posted on comp.mail.sendmail should be sent 11568330Seric to comp-mail-sendmail@dl.ac.uk 11668330Seric---------------------------------------------------------------------- 11768330Seric * I have sendmail-related DNS questions. Where should I ask them? 11868330Seric 11968330Seric Depending on how deeply they get into the DNS, they can be 12068330Seric asked here. However, you'll probably be told that you should 12168330Seric send them to the Info-BIND mailing list (if the question is 12268330Seric specific to that program) or to the Usenet newsgroup 12368330Seric comp.protocols.tcp-ip.domains (DNS in general). 12468330Seric---------------------------------------------------------------------- 12568330Seric * How do I subscribe to either of these? 12668330Seric 12768330Seric For comp.protocols.tcp-ip.domains, you have to be on Usenet. 12868330Seric They don't have a news-to-mail gateway yet. 12968330Seric 13068330Seric For the Info-BIND mailing list, send email to 13168330Seric bind-request@uunet.uu.net with the command "subscribe" in the 13268330Seric message. Submissions should be sent to bind@uunet.uu.net 13368330Seric 13468330Seric====================================================================== 13568330SericGENERAL QUESTIONS 13668330Seric====================================================================== 13768330Seric 13867021Seric * Where can I get Version 8? 13967021Seric 14067021Seric Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. 14167021Seric---------------------------------------------------------------------- 14266282Seric * What are the differences between Version 8 and other versions? 14366282Seric 14467021Seric See doc/changes/changes.me in the sendmail distribution. 14566282Seric---------------------------------------------------------------------- 14666282Seric * What happened to sendmail 6.x and 7.x? 14766282Seric 14868330Seric When a new (Alpha/Beta) version of sendmail was released, it 14968330Seric was changed to Release 6. Development continued in that tree 15068330Seric until 4.4BSD was released, when everything on the 4.4 tape 15168330Seric was set to be version 8.1. Version 7.x never existed. 15266282Seric---------------------------------------------------------------------- 15368069Seric * What books are available describing sendmail? 15468069Seric 15568069Seric There is one book available devoted to sendmail: 15668069Seric 15768069Seric Costales, Allman, and Rickert, _Sendmail_. O'Reilly & 15868069Seric Associates. 15968069Seric 16068069Seric Several books have sendmail chapters, for example: 16168069Seric 16268069Seric Nemeth, Snyder, and Seebass, _Unix System Administration 16368069Seric Handbook_. Prentice-Hall. 16468069Seric Carl-Mitchell and Quarterman, _Practical Internetworking with 16568069Seric TCP/IP and UNIX_. Addison-Wesley. 16668069Seric Hunt, _TCP/IP Network Administration_. O'Reilly & Associates. 16768069Seric 16868069Seric Another book about sendmail is due out "soon": 16968069Seric 17068069Seric Avolio & Vixie, _Sendmail Theory and Practice_. Digital 17168069Seric Press (release date unknown). 17268069Seric 17368330Seric For details on sendmail-related DNS issues, consult: 17468330Seric 17568330Seric Liu and Albitz, _DNS and BIND_. O'Reilly & Associates. 17668330Seric 17768330Seric For details on UUCP, see: 17868330Seric 17968330Seric O'Reilly and Todino, _Managing UUCP and Usenet_. 18068330Seric O'Reilly & Associates. 18168330Seric 18268069Seric====================================================================== 18368069SericCOMPILING AND INSTALLING SENDMAIL 8 18468069Seric====================================================================== 18568069Seric 18666282Seric * Version 8 requires a new version of "make". Where can I get this? 18766282Seric 18866282Seric Actually, Version 8 does not require a new version of "make". 18966282Seric It includes a collection of Makefiles for different architectures, 19067892Seric only one or two of which require the new "make". For a supported 19167892Seric architecture, use ``sh makesendmail''. If you are porting to a 19267892Seric new architecture, start with Makefile.dist. 19366282Seric 19466282Seric If you really do want the new make, it is available on any of 19567021Seric the BSD Net2 or 4.4-Lite distribution sites. These include: 19666282Seric 19766282Seric ftp.uu.net /systems/unix/bsd-sources 19866282Seric gatekeeper.dec.com /.0/BSD/net2 19966282Seric ucquais.cba.uc.edu /pub/net2 20066282Seric ftp.luth.se /pub/unix/4.3bsd/net2 20166282Seric 20268330Seric Diffs and instructions for building this version of make 20368330Seric under SunOS 4.1.x are available on ftp.css.itd.umich.edu in 20468330Seric /pub/systems/sun/Net2-make.sun4.diff.Z. A patchkit for 20568330Seric Ultrix is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z. 20668330Seric Patches for AIX 3.2.4 are available on ftp.uni-stuttgart.de 20768330Seric in /sw/src/patches/bsd-make-rus-patches. 20867489Seric 20967489Seric There is also a Linux version available on the main Linux 21067489Seric distribution sites as pmake; this version is included as 21167489Seric standard with the current Slackware distributions. 21266282Seric---------------------------------------------------------------------- 21366282Seric * What macro package do I use to format the V8 man pages? 21466282Seric 21568330Seric The BSD group switched over the the ``mandoc'' macros for the 21668330Seric 4.4 release. These include more hooks designed for hypertext 21768330Seric handling. However, new man pages won't format under the old 21868330Seric man macros. Fortunately, old man pages will format under the 21968330Seric new mandoc macros. 22066282Seric 22168330Seric Get the new macros with the BSD Net2 or 4.4-Lite release (see 22268330Seric above for locations; for example, on FTP.UU.NET the files 22368330Seric /system/unix/bsd-sources/share/tmac/me/strip/sed and 22468330Seric /system/unix/bsd-sources/share/tmac/* are what you need). 22566282Seric 22668330Seric This macro set is also included with newer versions of groff. 22768070Seric---------------------------------------------------------------------- 22868070Seric * What modes should be used when installing sendmail? 22966282Seric 23068070Seric The sendmail binary should be owned by root, mode 4755. 23168070Seric The queue directory should be owned by root, with a mode 23268330Seric between 700 and 755. Under no circumstances should 23368330Seric it be group or other writable! 23468070Seric The sendmail config file should be owned by root, mode 644. 23568070Seric The aliases file should generally be owned by one trusted 23668330Seric user and writable only by that user, although it is 23768330Seric not unreasonable to have it group writable by a 23868330Seric "sysadmin" group. It should not be world writable. 23968070Seric The aliases database files (aliases.db or aliases.{pag,dir} 24068070Seric depending on what database format you compile with) 24168070Seric should be owned by root, mode 644. 24268070Seric 24368069Seric====================================================================== 24468069SericCONFIGURATION QUESTIONS 24568069Seric====================================================================== 24666282Seric 24766282Seric * How do I make all my addresses appear to be from a single host? 24866282Seric 24966282Seric Using the V8 configuration macros, use: 25066282Seric 25166282Seric MASQUERADE_AS(my.dom.ain) 25266282Seric 25366282Seric This will cause all addresses to be sent out as being from 25466282Seric the indicated domain. 25566282Seric---------------------------------------------------------------------- 25666282Seric * How do I rewrite my From: lines to read ``First_Last@My.Domain''? 25766282Seric 25868330Seric There are a couple of ways of doing this. This describes 25968330Seric using the "user database" code. This is still experimental, 26068330Seric and was intended for a different purpose -- however, it does 26168330Seric work with a bit of care. It does require that you have the 26268330Seric Berkeley "db" package installed (it won't work with DBM). 26366282Seric 26466282Seric First, create your input file. This should have lines like: 26566282Seric 26666282Seric loginname:mailname First_Last 26766282Seric First_Last:maildrop loginname 26866282Seric 26966282Seric Install it in (say) /etc/userdb. Create the database: 27066282Seric 27166282Seric makemap btree /etc/userdb.db < /etc/userdb 27266282Seric 27366282Seric You can then create a config file that uses this. You will 27466282Seric have to include the following in your .mc file: 27566282Seric 27666282Seric define(confUSERDB_SPEC, /etc/userdb.db) 27766282Seric FEATURE(notsticky) 27866282Seric---------------------------------------------------------------------- 27966282Seric * So what was the user database feature intended for? 28066282Seric 28168330Seric The intent was to have all information for a given user 28268330Seric (where the user is the unique login name, not an inherently 28368330Seric non-unique full name) in one place. This would include phone 28468330Seric numbers, addresses, and so forth. The "maildrop" feature is 28568330Seric because Berkeley does not use a centralized mail server 28668330Seric (there are a number of reasons for this that are mostly 28768330Seric historic), and so we need to know where each user gets his or 28868330Seric her mail delivered -- i.e., the mail drop. 28966282Seric 29066282Seric We are in the process of setting up our environment so that 29166282Seric mail sent to an unqualified "name" goes to that person's 29266282Seric preferred maildrop; mail sent to "name@host" goes to that 29366282Seric host. The purpose of "FEATURE(notsticky)" is to cause 29466282Seric "name@host" to be looked up in the user database for delivery 29566282Seric to the maildrop. 29666282Seric---------------------------------------------------------------------- 29766282Seric * Why are you so hostile to using full names for e-mail addresses? 29866282Seric 29966282Seric Because full names are not unique. For example, the computer 30066282Seric community has two Andy Tannenbaums and two Peter Deutsches. 30168330Seric At one time, Bell Labs had two Stephen R. Bournes with 30268330Seric offices a few doors apart. You can create alternative 30368330Seric addresses (e.g., Stephen_R_Bourne_2), but that's even worse 30468330Seric -- which one of them has to have their name desecrated in 30568330Seric this way? And you can bet that one of them will get most of 30668330Seric the other person's e-mail. 30766282Seric 30867892Seric So called "full names" are just an attempt to create longer 30967892Seric versions of unique names. Rather that lulling people into a 31067892Seric sense of security, I'd rather that it be clear that these 31167892Seric handles are arbitrary. People should use good user agents 31267892Seric that have alias mappings so that they can attach arbitrary 31368330Seric names for their personal use to those with whom they 31468330Seric correspond (such as the MH alias file). 31566282Seric 31666282Seric Even worse is fuzzy matching in e-mail -- this can make good 31768330Seric addresses turn bad. For example, Eric Allman is currently 31868330Seric (to the best of our knowledge) the only ``Allman'' at 31968330Seric Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to 32068330Seric him. But if another Allman ever appears, this address could 32168330Seric suddenly become ambiguous. He's been the only Allman at 32268330Seric Berkeley for over fifteen years -- to suddenly have this 32368330Seric "good address" bounce mail because it is ambiguous would be a 32468330Seric heinous wrong. 32566282Seric 32667892Seric Finger services should be as fuzzy as possible (within 32767892Seric reason, of course). Mail services should be unique. 32866282Seric---------------------------------------------------------------------- 32968069Seric * Should I use a wildcard MX for my domain? 33068069Seric 33168069Seric If at all possible, no. 33268069Seric 33368069Seric Wildcard MX records have lots of semantic "gotcha"s. For 33468069Seric example, they will match a host "unknown.your.domain" -- if 33568069Seric you don't explicitly test for unknown hosts in your domain, 33668069Seric you will get "config error: mail loops back to myself" 33768069Seric errors. 338*68445Seric 339*68445Seric See RFCs 1535-1537 for more detail and other related (or 340*68445Seric common) problems. 34168069Seric---------------------------------------------------------------------- 34268330Seric * How can I get sendmail to process messages sent to an account and 34368330Seric send the results back to the originator? 34468330Seric 34568330Seric This is a local mailer issue, not a sendmail issue. 34668330Seric Depending on what you're doing, look at procmail (mentioned 34768330Seric again below), ftpmail, or Majordomo. 34868330Seric 34968330Seric Check your local archie server to see what machine(s) nearest 35068330Seric you have the most recent versions of these programs. 35168330Seric---------------------------------------------------------------------- 35268069Seric * How can I get sendmail to deliver local mail to $HOME/.mail 35368069Seric instead of into /usr/spool/mail (or /usr/mail)? 35468069Seric 35568330Seric Again, this is a local mailer issue, not a sendmail issue. 35668330Seric Either modify your local mailer (source code will be 35768330Seric required) or change the program called in the "local" mailer 35868330Seric configuration description to be a new program that does this 359*68445Seric local delivery. One program that is capable of doing this is 360*68445Seric "procmail", although there are probably many others as well. 36168069Seric 36268330Seric You might be interested in reading the paper ``HLFSD: 36368330Seric Delivering Email to your $HOME'' available in the Proceedings 36468330Seric of the USENIX System Administration (LISA VII) Conference 36568330Seric (November 1993). This is also available via public FTP from 36668330Seric ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}. 36768069Seric---------------------------------------------------------------------- 36868069Seric * I'm trying to to get my mail to go into queue only mode, and it 36968069Seric delivers the mail interactively anyway. (Or, I'm trying to use 37068330Seric the "don't deliver to expensive mailer" flag, and it delivers the 37168330Seric mail interactively anyway.) I can see it does it: here's the 37268330Seric output of "sendmail -v foo@somehost" (or Mail -v or equivalent). 37368069Seric 37468069Seric The -v flag to sendmail (which is implied by the -v flag to 37568069Seric Mail and other programs in that family) tells sendmail to 37668069Seric watch the transaction. Since you have explicitly asked to 37768069Seric see what's going on, it assumes that you do not want to to 37868069Seric auto-queue, and turns that feature off. Remove the -v flag 37968330Seric and use a "tail -f" of the log instead to see what's going 38068330Seric on. 38168069Seric 38268330Seric If you are trying to use the "don't deliver to expensive 38368330Seric mailer" flag (mailer flag "e"), be sure you also turn on 38468330Seric global option "c" -- otherwise it ignores the mailer flag. 38568069Seric---------------------------------------------------------------------- 38668069Seric * There are four UUCP mailers listed in the configuration files. 38768069Seric Which one should I use? 38868069Seric 38968330Seric The choice is partly a matter of local preferences and what 39068330Seric is running at the other end of your UUCP connection. Unlike 39168330Seric good protocols that define what will go over the wire, UUCP 39268330Seric uses the policy that you should do what is right for the 39368330Seric other end; if they change, you have to change. This makes it 39468330Seric hard to do the right thing, and discourages people from 39568330Seric updating their software. In general, if you can avoid UUCP, 39668330Seric please do. 39768069Seric 39868330Seric If you can't avoid it, you'll have to find the version that 39968330Seric is closest to what the other end accepts. Following is a 40068330Seric summary of the UUCP mailers available. 40168069Seric 40268069Seric uucp-old (obsolete name: "uucp") 40368330Seric This is the oldest, the worst (but the closest to UUCP) way 40468330Seric of sending messages across UUCP connections. It does 40568330Seric bangify everything and prepends $U (your UUCP name) to the 40668330Seric sender's address (which can already be a bang path 40768330Seric itself). It can only send to one address at a time, so it 40868330Seric spends a lot of time copying duplicates of messages. Avoid 40968330Seric this if at all possible. 41068069Seric 41168069Seric uucp-new (obsolete name: "suucp") 41268069Seric The same as above, except that it assumes that in one rmail 41368069Seric command you can specify several recipients. It still has a 41468069Seric lot of other problems. 41568069Seric 41668069Seric uucp-dom 41768069Seric This UUCP mailer keeps everything as domain addresses. 41868069Seric Basically, it uses the SMTP mailer rewriting rules. 41968069Seric 42068330Seric Unfortunately, a lot of UUCP mailer transport agents 42168330Seric require bangified addresses in the envelope, although you 42268330Seric can use domain-based addresses in the message header. (The 42368330Seric envelope shows up as the From_ line on UNIX mail.) So.... 42468069Seric 42568069Seric uucp-uudom 42668330Seric This is a cross between uucp-new (for the envelope 42768330Seric addresses) and uucp-dom (for the header addresses). It 42868330Seric bangifies the envelope sender (From_ line in messages) 42968330Seric without adding the local hostname, unless there is no host 43068330Seric name on the address at all (e.g., "wolf") or the host 43168330Seric component is a UUCP host name instead of a domain name 43268330Seric ("somehost!wolf" instead of "some.dom.ain!wolf"). 43368069Seric 43468069Seric Examples: 43568069Seric 43668330Seric We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). 43768330Seric The following summarizes the sender rewriting for various 43868330Seric mailers. 43968069Seric 44068069Seric Mailer sender rewriting in the envelope 44168069Seric ------ ------ ------------------------- 44268069Seric uucp-{old,new} wolf grasp!wolf 44368069Seric uucp-dom wolf wolf@grasp.insa-lyon.fr 44468069Seric uucp-uudom wolf grasp.insa-lyon.fr!wolf 44568069Seric 44668069Seric uucp-{old,new} wolf@fr.net grasp!fr.net!wolf 44768069Seric uucp-dom wolf@fr.net wolf@fr.net 44868069Seric uucp-uudom wolf@fr.net fr.net!wolf 44968069Seric 45068069Seric uucp-{old,new} somehost!wolf grasp!somehost!wolf 45168069Seric uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr 45268069Seric uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf 45368069Seric 45468069Seric====================================================================== 45568069SericRESOLVING PROBLEMS 45668069Seric====================================================================== 45768069Seric 45868069Seric * When I compile, I get "undefined symbol inet_aton" messages. 45968069Seric 46068069Seric You've probably replaced your resolver with the version from 46168330Seric BIND 4.9.3. You need to compile with -l44bsd in order to get 46268069Seric the additional routines. 46368069Seric---------------------------------------------------------------------- 46467892Seric * I'm getting "Local configuration error" messages, such as: 46567892Seric 46667892Seric 553 relay.domain.net config error: mail loops back to myself 46767892Seric 554 <user@domain.net>... Local configuration error 46867892Seric 46967892Seric How can I solve this problem? 47067892Seric 47167892Seric You have asked mail to the domain (e.g., domain.net) to be 47267892Seric forwarded to a specific host (in this case, relay.domain.net) 47368330Seric by using an MX record, but the relay machine doesn't 47468330Seric recognize itself as domain.net. Add domain.net to 47568330Seric /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or 47668330Seric add "Cw domain.net" to your configuration file. 47767898Seric 47867898Seric IMPORTANT: Be sure you kill and restart the sendmail daemon 47967898Seric after you change the configuration file (for ANY change in 48067898Seric the configuration, not just this one): 48167898Seric 48267898Seric kill `head -1 /etc/sendmail.pid` 48367898Seric sh -c "`tail -1 /etc/sendmail.pid`" 48467898Seric 48567898Seric NOTA BENE: kill -1 does not work! 48667892Seric---------------------------------------------------------------------- 48766282Seric * When I use sendmail V8 with a Sun config file I get lines like: 48866282Seric 48966282Seric /etc/sendmail.cf: line 273: replacement $3 out of bounds 49066282Seric 49166282Seric the line in question reads: 49266282Seric 49366282Seric R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether 49466282Seric 49566282Seric what does this mean? How do I fix it? 49666282Seric 49768330Seric V8 doesn't recognize the Sun "$%y" syntax, so as far as it is 49868330Seric concerned, there is only a $1 and a $2 (but no $3) in this 49966282Seric line. Read Rick McCarty's paper on "Converting Standard Sun 50066282Seric Config Files to Sendmail Version 8", in the contrib directory 50166282Seric (file "converting.sun.configs") on the sendmail distribution 50266282Seric for a full discussion of how to do this. 50366282Seric---------------------------------------------------------------------- 50468330Seric * When I use sendmail V8 on a Sun, I sometimes get lines like: 50566282Seric 50668330Seric /etc/sendmail.cf: line 445: bad ruleset 96 (50 max) 50768330Seric 50868330Seric what does this mean? How do I fix it? 50968330Seric 51068330Seric You're somehow trying to start up the old Sun sendmail (or 51168330Seric sendmail.mx) with a sendmail V8 config file, which Sun's 51268330Seric sendmail doesn't like. Check your /etc/rc.local, any 51368330Seric procedures that have been created to stop and re-start the 51468330Seric sendmail processes, etc.... Make sure that you've switched 51568330Seric everything over to using the new sendmail. To keep this 51668330Seric problem from ever happening again, try the following: 51768330Seric 51868330Seric mv /usr/lib/sendmail /usr/lib/sendmail.old 51968330Seric ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail 52068330Seric mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old 52168330Seric ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx 52268330Seric chmod 0000 /usr/lib/sendmail.old 52368330Seric chmod 0000 /usr/lib/sendmail.mx.old 52468330Seric 52568330Seric Assuming you have installed sendmail V8 in /usr/local/lib. 52668330Seric---------------------------------------------------------------------- 52768330Seric * When I use sendmail V8 on an IBM RS/6000 running AIX, the system 52868330Seric resource controller always reports sendmail as "inoperative" even 52968330Seric though it is running. What's wrong? 53068330Seric 53168330Seric IBM's system resource controller is one of their "value 53268330Seric added" features to AIX -- it's not a Unix standard. You'll 53368330Seric need to either redefine the subsystem to use signals (see 53468330Seric chssys(1)) or dump the entire subsystem and invoke sendmail 53568330Seric in /etc/rc.tcpip or some other boot script. 53668330Seric---------------------------------------------------------------------- 53768330Seric * When I use sendmail V8 on an Intel x86 machine running Linux, I 53868330Seric have some problems. Specifically, I have.... 53968330Seric 54068330Seric The current versions of Linux are generally considered to be 54168334Seric great for hobbyists and anyone else who wants to learn Unix 54268330Seric inside and out, or wants to always have something to do, or 54368334Seric wants a machine for light-duty mostly personal use and not 54468334Seric high-volume multi-user purposes. 54568330Seric 54668330Seric However, for those who want a system that will just sit in 54768330Seric the background and work without a fuss handling thousands of 54868330Seric mail messages a day for lots of different users, it's not 54968330Seric (yet) stable enough to fit the bill. 55068330Seric 55168330Seric Unfortunately, there are no known shareware/freeware 55268330Seric implementations of any operating system that provides the 55368334Seric level of stability necessary to handle that kind of load 55468334Seric (i.e., there are no free lunches). 55568334Seric 55668334Seric If you're wedded to the Intel x86 platform and want to run 55768334Seric sendmail, we suggest you look at commercial implementations 558*68445Seric of Unix such as Interactive, UnixWare, Solaris, or BSD/386 55968334Seric (just a sample of the dozens of different versions of Unix 56068334Seric for Intel x86). 56168334Seric 56268334Seric Of all known vendor supported versions of Unix for Intel x86, 56368334Seric BSDI's BSD/386 is least expensive and the only one known to 56468334Seric currently ship with sendmail V8 pre-installed. Since sendmail 56568334Seric V8 is continuing to be developed at UC Berkeley, and BSD/386 56668334Seric is a full BSD 4.4 implementation, this is obviously be the most 56768334Seric "native" sendmail V8 environment. 56868330Seric---------------------------------------------------------------------- 56968330Seric * When I use sendmail on an Intel x86 machine running OS/2, I have 57068330Seric some problems. Specifically, I have.... 57168330Seric 57268330Seric The OS/2 port of sendmail is known to have left out huge 57368330Seric chunks of the code and functionality of even much older 57468330Seric versions of sendmail, in large part because the underlying OS 57568330Seric just doesn't have the necessary hooks to make it happen. 57668330Seric This port is so broken that we make no attempt to provide any 577*68445Seric kind of support for it. Try BSDI's BSD/386 instead. 57868330Seric---------------------------------------------------------------------- 57968330Seric * I'm connected to the network via a SLIP/PPP link. Sometimes my 58068330Seric sendmail process hangs (although it looks like part of the 58168330Seric message has been transfered). Everything else works. What's 58268330Seric wrong? 58368330Seric 58466282Seric Most likely, the problem isn't sendmail at all, but the low 58568330Seric level network connection. It's important that the MTU 58668330Seric (Maximum Transfer Unit) for the SLIP connection be set 58768330Seric properly at both ends. If they disagree, large packets will 58868330Seric be trashed and the connection will hang. 58966282Seric---------------------------------------------------------------------- 59066282Seric * I just upgraded to 8.x and suddenly I'm getting messages in my 59166282Seric syslog of the form "collect: I/O error on connection". What is 59266282Seric going wrong? 59366282Seric 59468330Seric Nothing. This is just a diagnosis of a condition that had 59568330Seric not been diagnosed before. If you are getting a lot of these 59668330Seric from a single host, there is probably some incompatibility 59768330Seric between 8.x and that host. If you get a lot of them in 59868330Seric general, you may have network problems that are causing 59968330Seric connections to get reset. 60066282Seric---------------------------------------------------------------------- 60168338Seric * I just upgraded to 8.x and now when my users try to forward their 60268338Seric mail to a program they get an "illegal shell" message and their 60368338Seric mail is not delivered. What's wrong? 60468338Seric 60568338Seric In order for people to be able to run a program from their 60668338Seric .forward file, 8.x insists that their shell (that is, the 60768338Seric shell listed for that user in the passwd entry) be a "valid" 60868338Seric shell, meaning a shell listed in /etc/shells. If /etc/shells 60968338Seric does not exist, a default list is used, typically consisting 61068338Seric of /bin/sh and /bin/csh. 61168338Seric 61268338Seric This is to support environments that may have NFS-shared 61368338Seric directories mounted on machines on which users do not have 61468338Seric login permission. For example, many people make their 61568338Seric file server inaccessible for performance or security 61668338Seric reasons; although users have directories, their shell on 61768338Seric the server is /usr/local/etc/nologin or some such. If you 61868338Seric allowed them to run programs anyway you might as well let 61968338Seric them log in. 62068338Seric 62168338Seric If you are willing to let users run programs from their 62268338Seric .forward file even though they cannot telnet or rsh in (as 62368338Seric might be reasonable if you run smrsh to control the list of 62468338Seric programs they can run) then add the line 62568338Seric 62668338Seric /SENDMAIL/ANY/SHELL/ 62768338Seric 62868338Seric to /etc/shells. This must be typed exactly as indicated, 62968338Seric in caps, with the trailing slash. NOTA BENE: DO NOT 63068338Seric list /usr/local/etc/nologin in /etc/shells -- this will 63168338Seric open up other security problems. 63268338Seric---------------------------------------------------------------------- 63367892Seric * I just upgraded to 8.x and suddenly connections to the SMTP port 63467892Seric take a long time. What is going wrong? 63567892Seric 63668330Seric It's probably something weird in your TCP implementation that 63767892Seric makes the IDENT code act oddly. On most systems V8 tries to 63867892Seric do a ``callback'' to the connecting host to get a validated 63968330Seric user name (see RFC 1413 for detail). If the connecting host 64068330Seric does not support such a service it will normally fail quickly 64168330Seric with "Connection refused", but certain kinds of packet 64268330Seric filters and certain TCP implementations just time out. 64367892Seric 64467892Seric To test this, set the IDENT timeout to zero using 64567892Seric ``OrIdent=0'' in the configuration file. This will 64667892Seric completely disable all use of the IDENT protocol. 64767892Seric 64867892Seric Another possible problem is that you have your name server 64968330Seric and/or resolver configured improperly. Make sure that all 65068330Seric "nameserver" entries in /etc/resolv.conf point to functional 65168330Seric servers. If you are running your own server make certain 65268330Seric that all the servers listed in your root cache (usually 65368330Seric called something like "/var/namedb/root.cache"; see your 65467892Seric /etc/named.boot file to get your value) are up to date. 65567892Seric Either of these can cause long delays. 65667892Seric---------------------------------------------------------------------- 65768338Seric * I just upgraded to 8.x and suddenly I get errors such as ``unknown 65868338Seric mailer error 5 -- mail: options MUST PRECEDE recipients.'' What is 65968338Seric going wrong? 66067892Seric 66167892Seric You need OSTYPE(systype) in your .mc file -- otherwise the 66267892Seric configurations use a default that probably disagrees with 66367892Seric your local mail system. See cf/README for details. 66467892Seric---------------------------------------------------------------------- 66566282Seric * Under V8, the "From " header gets mysteriously munged when I send 66666282Seric to an alias. 66766282Seric 66868330Seric ``It's not a bug, it's a feature.'' This happens when you 66968330Seric have a "owner-list" alias and you send to "list". V8 67068330Seric propagates the owner information into the envelope sender 67168330Seric field (which appears as the "From " header on UNIX mail or as 67268330Seric the Return-Path: header) so that downstream errors are 67368330Seric properly returned to the mailing list owner instead of to the 67468330Seric sender. In order to make this appear as sensible as possible 67568330Seric to end users, I recommend making the owner point to a 67668330Seric "request" address -- for example: 67766282Seric 67866282Seric list: :include:/path/name/list.list 67966282Seric owner-list: list-request 68066282Seric list-request: eric 68166282Seric 68268330Seric This will make message sent to "list" come out as being "From 68368330Seric list-request" instead of "From eric". 68466282Seric---------------------------------------------------------------------- 68568330Seric * I am trying to use MASQUERADE_AS (or the user database) to 68668330Seric rewrite from addresses, and although it works in the From: header 68768330Seric line, it doesn't work in the envelope (e.g., the "From " line). 68868330Seric 68968330Seric Believe it or not, this is intentional. The interpretation 69068330Seric of the standards by the V8 development group was that this 69168330Seric was an inappropriate rewriting, and that if the rewriting 69268330Seric were incorrect at least the envelope would contain a valid 69368330Seric return address. Other people have since described scenarios 69468330Seric where the envelope cannot be correct without this rewriting, 69568330Seric so 8.7 will have an option to rewrite both header and 69668330Seric envelope. 69768330Seric---------------------------------------------------------------------- 69866285Seric * I want to run Sendmail version 8 on my DEC system, but you don't 69966285Seric have MAIL11V3 support in sendmail. How do I handle this? 70066285Seric 70168330Seric Get Paul Vixie's reimplementation of the mail11 protocol from 70268330Seric gatekeeper.dec.com in /pub/DEC/gwtools. 70368330Seric 70468330Seric Rumour has it that he will be fully integrating into sendmail 70568330Seric V8 what little is left of IDA sendmail that is not handled 70668330Seric (or handled as well) by V8. No additional information on 70768330Seric this project is currently available. 70866285Seric---------------------------------------------------------------------- 70968069Seric * Messages seem to disappear from my queue unsent. When I look in 71068330Seric the queue directory I see that they have been renamed from qf* to 71168330Seric Qf*, and sendmail doesn't see these. 71268069Seric 71368069Seric If you look closely you should find that the Qf files are 71468069Seric owned by users other than root. Since sendmail runs as root 71568069Seric it refuses to believe information in non-root-owned qf files, 71668330Seric and it renames them to Qf to get them out of the way and make 71768330Seric it easy for you to find. The usual cause of this is 71868069Seric twofold: first, you have the queue directory world writable 71968069Seric (which is probably a mistake -- this opens up other security 72068069Seric problems) and someone is calling sendmail with an "unsafe" 72168069Seric flag, usually a -o flag that sets an option that could 72268069Seric compromise security. When sendmail sees this it gives up 72368069Seric setuid root permissions. 72468069Seric 72568330Seric The usual solution is to not use the problematic flags. If 72668330Seric you must use them, you have to write a special queue 72768069Seric directory and have them processed by the same uid that 72868069Seric submitted the job in the first place. 72968069Seric---------------------------------------------------------------------- 730*68445Seric@(#)FAQ 8.15 (Berkeley) 02/24/95 73168330SericSend updates to sendmail@CS.Berkeley.EDU. 732