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) 1568330SericLast-modified: Sat Feb 11 03:26:18 EST 1995 1668330Seric 1768330Seric 1868330Seric[The most recent copy of this document can be obtained via anonymous 1968330SericFTP as rtfm.mit.edu:/pub/usenet/news.answers/mail/sendmail-faq. If 2068330Sericyou do not have access to anonymous FTP, you can retrieve it by 2168330Sericsending email to mail-server@rtfm.mit.edu with the command "send 2268330Sericusenet/news.answers/mail/sendmail-faq" in the message.] 2368330Seric 2468330Seric 2568330Seric 2666282Seric Sendmail Version 8 2766282Seric Frequently Asked Questions 28*68338Seric Last updated 02/15/95 2966282Seric 3066282Seric 3168330SericThis FAQ is specific to Version 8.6.9 of sendmail. Other questions, 3268330Sericparticularly regarding compilation and configuration, are answered in 3368330Sericsrc/READ_ME and cf/README (found in the V8 sendmail distribution). 3466282Seric 3568330SericThis is also the official FAQ for the Usenet newsgroup 3668330Sericcomp.mail.sendmail. 3768330Seric 3868069Seric====================================================================== 3968330SericBEFORE YOU GO ANY FURTHER 4068069Seric====================================================================== 4168069Seric 4268330Seric * What do you wish everyone would do before sending you mail or 4368330Seric posting to comp.mail.sendmail? 4467892Seric 4567892Seric Read this FAQ completely. Read src/READ_ME and cf/README 4668330Seric completely. Read the books written to help with common 4768330Seric problems such as compilation and installation, configuration, 4868330Seric security issues, etc.... Ask themselves if their question 4968330Seric hasn't already been answered. 5067892Seric---------------------------------------------------------------------- 5168330Seric * How can I be sure if this is the right place to look for answers 5268330Seric to my questions? 5368330Seric 5468330Seric 1. Do you know, for a fact, that the question is related to 5568334Seric sendmail V8? 5668330Seric 5768330Seric 2. Do you know, for a fact, that the question is related to an 5868330Seric older version of sendmail? 5968330Seric 6068330Seric 3. Is the question about a sendmail-like program (e.g., Smail, 6168330Seric Zmailer, MMDF, etc...)? 6268330Seric 6368330Seric 4. Is the question about an SMTP Gateway product for a LAN mail 6468330Seric package (e.g., cc:Mail, MS-Mail WordPerfect Office/GroupWise, 6568330Seric etc...)? 6668330Seric 6768330Seric If you answered "yes" to the question #1, then this is the 6868330Seric right place. 6968330Seric 7068330Seric If you answered "yes" to questions #2 or #3, then you should 7168330Seric seriously consider upgrading to the most recent version of 7268330Seric sendmail V8. 7368330Seric 7468330Seric For question #2, If you're going to contiue using an older 7568330Seric version of sendmail, you may not find much help and will 7668330Seric probably get some responses that amount to "Get V8". 7768330Seric Otherwise, this is probably the best place to look for 7868330Seric answers. 7968330Seric 8068330Seric If you answered "yes" to question #3 and are not going to 8168330Seric upgrade to sendmail V8, then this is probably not the right 8268330Seric place to look. 8368330Seric 8468330Seric If you answered "yes" to question #4, then this is almost 8568330Seric certainly not the right place to look. 8668330Seric 8768330Seric For questions #3 and #4, try looking around elsewhere in the 8868330Seric "comp.mail.*" hierarchy for a more appropriate newsgroup. 8968330Seric For example, you might want to try posting to comp.mail.misc 9068330Seric or comp.mail.smail. 9168330Seric 9268330Seric If you couldn't answer "yes" to any of the above questions, 9368330Seric then you're DEFINITELY asking in the wrong place. For the 9468330Seric sake of your sanity and ego, not to mention avoiding the 9568330Seric waste of your time and ours, try asking your System or E-Mail 9668330Seric Administrator(s) before you post any questions publicly. 9768330Seric---------------------------------------------------------------------- 9868330Seric * Where can I find the latest version of this FAQ? 9968330Seric 10068330Seric It is included in the most recent Version 8 distribution of 10168330Seric sendmail (described below), as well as via anonymous FTP from 10268330Seric rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq. 10368330Seric If you do not have access to anonymous FTP, you can retrieve 10468330Seric it by sending email to mail-server@rtfm.mit.edu with the 10568330Seric command "send usenet/news.answers/mail/sendmail-faq" in the 10668330Seric message. 10768330Seric---------------------------------------------------------------------- 10868330Seric * I don't have access to Usenet news. Can I still get access to 10968330Seric comp.mail.sendmail? 11068330Seric 11168330Seric Yes. Send email to mxt@dl.ac.uk with the command "sub 11268330Seric comp-news.comp.mail.sendmail <full-US-ordered-email-address>" 11368330Seric in the message. 11468330Seric 11568330Seric E-mail you want posted on comp.mail.sendmail should be sent 11668330Seric to comp-mail-sendmail@dl.ac.uk 11768330Seric---------------------------------------------------------------------- 11868330Seric * I have sendmail-related DNS questions. Where should I ask them? 11968330Seric 12068330Seric Depending on how deeply they get into the DNS, they can be 12168330Seric asked here. However, you'll probably be told that you should 12268330Seric send them to the Info-BIND mailing list (if the question is 12368330Seric specific to that program) or to the Usenet newsgroup 12468330Seric comp.protocols.tcp-ip.domains (DNS in general). 12568330Seric---------------------------------------------------------------------- 12668330Seric * How do I subscribe to either of these? 12768330Seric 12868330Seric For comp.protocols.tcp-ip.domains, you have to be on Usenet. 12968330Seric They don't have a news-to-mail gateway yet. 13068330Seric 13168330Seric For the Info-BIND mailing list, send email to 13268330Seric bind-request@uunet.uu.net with the command "subscribe" in the 13368330Seric message. Submissions should be sent to bind@uunet.uu.net 13468330Seric 13568330Seric====================================================================== 13668330SericGENERAL QUESTIONS 13768330Seric====================================================================== 13868330Seric 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 14968330Seric When a new (Alpha/Beta) version of sendmail was released, it 15068330Seric was changed to Release 6. Development continued in that tree 15168330Seric until 4.4BSD was released, when everything on the 4.4 tape 15268330Seric 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 17468330Seric For details on sendmail-related DNS issues, consult: 17568330Seric 17668330Seric Liu and Albitz, _DNS and BIND_. O'Reilly & Associates. 17768330Seric 17868330Seric For details on UUCP, see: 17968330Seric 18068330Seric O'Reilly and Todino, _Managing UUCP and Usenet_. 18168330Seric O'Reilly & Associates. 18268330Seric 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 20368330Seric Diffs and instructions for building this version of make 20468330Seric under SunOS 4.1.x are available on ftp.css.itd.umich.edu in 20568330Seric /pub/systems/sun/Net2-make.sun4.diff.Z. A patchkit for 20668330Seric Ultrix is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z. 20768330Seric Patches for AIX 3.2.4 are available on ftp.uni-stuttgart.de 20868330Seric 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 21668330Seric The BSD group switched over the the ``mandoc'' macros for the 21768330Seric 4.4 release. These include more hooks designed for hypertext 21868330Seric handling. However, new man pages won't format under the old 21968330Seric man macros. Fortunately, old man pages will format under the 22068330Seric new mandoc macros. 22166282Seric 22268330Seric Get the new macros with the BSD Net2 or 4.4-Lite release (see 22368330Seric above for locations; for example, on FTP.UU.NET the files 22468330Seric /system/unix/bsd-sources/share/tmac/me/strip/sed and 22568330Seric /system/unix/bsd-sources/share/tmac/* are what you need). 22666282Seric 22768330Seric 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 23368330Seric between 700 and 755. Under no circumstances should 23468330Seric 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 23768330Seric user and writable only by that user, although it is 23868330Seric not unreasonable to have it group writable by a 23968330Seric "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 25968330Seric There are a couple of ways of doing this. This describes 26068330Seric using the "user database" code. This is still experimental, 26168330Seric and was intended for a different purpose -- however, it does 26268330Seric work with a bit of care. It does require that you have the 26368330Seric 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 28268330Seric The intent was to have all information for a given user 28368330Seric (where the user is the unique login name, not an inherently 28468330Seric non-unique full name) in one place. This would include phone 28568330Seric numbers, addresses, and so forth. The "maildrop" feature is 28668330Seric because Berkeley does not use a centralized mail server 28768330Seric (there are a number of reasons for this that are mostly 28868330Seric historic), and so we need to know where each user gets his or 28968330Seric 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. 30268330Seric At one time, Bell Labs had two Stephen R. Bournes with 30368330Seric offices a few doors apart. You can create alternative 30468330Seric addresses (e.g., Stephen_R_Bourne_2), but that's even worse 30568330Seric -- which one of them has to have their name desecrated in 30668330Seric this way? And you can bet that one of them will get most of 30768330Seric 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 31468330Seric names for their personal use to those with whom they 31568330Seric correspond (such as the MH alias file). 31666282Seric 31766282Seric Even worse is fuzzy matching in e-mail -- this can make good 31868330Seric addresses turn bad. For example, Eric Allman is currently 31968330Seric (to the best of our knowledge) the only ``Allman'' at 32068330Seric Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to 32168330Seric him. But if another Allman ever appears, this address could 32268330Seric suddenly become ambiguous. He's been the only Allman at 32368330Seric Berkeley for over fifteen years -- to suddenly have this 32468330Seric "good address" bounce mail because it is ambiguous would be a 32568330Seric 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---------------------------------------------------------------------- 34068330Seric * How can I get sendmail to process messages sent to an account and 34168330Seric send the results back to the originator? 34268330Seric 34368330Seric This is a local mailer issue, not a sendmail issue. 34468330Seric Depending on what you're doing, look at procmail (mentioned 34568330Seric again below), ftpmail, or Majordomo. 34668330Seric 34768330Seric Check your local archie server to see what machine(s) nearest 34868330Seric you have the most recent versions of these programs. 34968330Seric---------------------------------------------------------------------- 35068069Seric * How can I get sendmail to deliver local mail to $HOME/.mail 35168069Seric instead of into /usr/spool/mail (or /usr/mail)? 35268069Seric 35368330Seric Again, this is a local mailer issue, not a sendmail issue. 35468330Seric Either modify your local mailer (source code will be 35568330Seric required) or change the program called in the "local" mailer 35668330Seric configuration description to be a new program that does this 35768330Seric local delivery. I understand that "procmail" works well, 35868330Seric although I haven't used it myself. 35968069Seric 36068330Seric You might be interested in reading the paper ``HLFSD: 36168330Seric Delivering Email to your $HOME'' available in the Proceedings 36268330Seric of the USENIX System Administration (LISA VII) Conference 36368330Seric (November 1993). This is also available via public FTP from 36468330Seric 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 36868330Seric the "don't deliver to expensive mailer" flag, and it delivers the 36968330Seric mail interactively anyway.) I can see it does it: here's the 37068330Seric 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 37768330Seric and use a "tail -f" of the log instead to see what's going 37868330Seric on. 37968069Seric 38068330Seric If you are trying to use the "don't deliver to expensive 38168330Seric mailer" flag (mailer flag "e"), be sure you also turn on 38268330Seric 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 38768330Seric The choice is partly a matter of local preferences and what 38868330Seric is running at the other end of your UUCP connection. Unlike 38968330Seric good protocols that define what will go over the wire, UUCP 39068330Seric uses the policy that you should do what is right for the 39168330Seric other end; if they change, you have to change. This makes it 39268330Seric hard to do the right thing, and discourages people from 39368330Seric updating their software. In general, if you can avoid UUCP, 39468330Seric please do. 39568069Seric 39668330Seric If you can't avoid it, you'll have to find the version that 39768330Seric is closest to what the other end accepts. Following is a 39868330Seric summary of the UUCP mailers available. 39968069Seric 40068069Seric uucp-old (obsolete name: "uucp") 40168330Seric This is the oldest, the worst (but the closest to UUCP) way 40268330Seric of sending messages across UUCP connections. It does 40368330Seric bangify everything and prepends $U (your UUCP name) to the 40468330Seric sender's address (which can already be a bang path 40568330Seric itself). It can only send to one address at a time, so it 40668330Seric spends a lot of time copying duplicates of messages. Avoid 40768330Seric 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 41868330Seric Unfortunately, a lot of UUCP mailer transport agents 41968330Seric require bangified addresses in the envelope, although you 42068330Seric can use domain-based addresses in the message header. (The 42168330Seric envelope shows up as the From_ line on UNIX mail.) So.... 42268069Seric 42368069Seric uucp-uudom 42468330Seric This is a cross between uucp-new (for the envelope 42568330Seric addresses) and uucp-dom (for the header addresses). It 42668330Seric bangifies the envelope sender (From_ line in messages) 42768330Seric without adding the local hostname, unless there is no host 42868330Seric name on the address at all (e.g., "wolf") or the host 42968330Seric component is a UUCP host name instead of a domain name 43068330Seric ("somehost!wolf" instead of "some.dom.ain!wolf"). 43168069Seric 43268069Seric Examples: 43368069Seric 43468330Seric We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). 43568330Seric The following summarizes the sender rewriting for various 43668330Seric 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 45968330Seric 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) 47168330Seric by using an MX record, but the relay machine doesn't 47268330Seric recognize itself as domain.net. Add domain.net to 47368330Seric /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or 47468330Seric 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 49568330Seric V8 doesn't recognize the Sun "$%y" syntax, so as far as it is 49668330Seric 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---------------------------------------------------------------------- 50268330Seric * When I use sendmail V8 on a Sun, I sometimes get lines like: 50366282Seric 50468330Seric /etc/sendmail.cf: line 445: bad ruleset 96 (50 max) 50568330Seric 50668330Seric what does this mean? How do I fix it? 50768330Seric 50868330Seric You're somehow trying to start up the old Sun sendmail (or 50968330Seric sendmail.mx) with a sendmail V8 config file, which Sun's 51068330Seric sendmail doesn't like. Check your /etc/rc.local, any 51168330Seric procedures that have been created to stop and re-start the 51268330Seric sendmail processes, etc.... Make sure that you've switched 51368330Seric everything over to using the new sendmail. To keep this 51468330Seric problem from ever happening again, try the following: 51568330Seric 51668330Seric mv /usr/lib/sendmail /usr/lib/sendmail.old 51768330Seric ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail 51868330Seric mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old 51968330Seric ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx 52068330Seric chmod 0000 /usr/lib/sendmail.old 52168330Seric chmod 0000 /usr/lib/sendmail.mx.old 52268330Seric 52368330Seric Assuming you have installed sendmail V8 in /usr/local/lib. 52468330Seric---------------------------------------------------------------------- 52568330Seric * When I use sendmail V8 on an IBM RS/6000 running AIX, the system 52668330Seric resource controller always reports sendmail as "inoperative" even 52768330Seric though it is running. What's wrong? 52868330Seric 52968330Seric IBM's system resource controller is one of their "value 53068330Seric added" features to AIX -- it's not a Unix standard. You'll 53168330Seric need to either redefine the subsystem to use signals (see 53268330Seric chssys(1)) or dump the entire subsystem and invoke sendmail 53368330Seric in /etc/rc.tcpip or some other boot script. 53468330Seric---------------------------------------------------------------------- 53568330Seric * When I use sendmail V8 on an Intel x86 machine running Linux, I 53668330Seric have some problems. Specifically, I have.... 53768330Seric 53868330Seric The current versions of Linux are generally considered to be 53968334Seric great for hobbyists and anyone else who wants to learn Unix 54068330Seric inside and out, or wants to always have something to do, or 54168334Seric wants a machine for light-duty mostly personal use and not 54268334Seric high-volume multi-user purposes. 54368330Seric 54468330Seric However, for those who want a system that will just sit in 54568330Seric the background and work without a fuss handling thousands of 54668330Seric mail messages a day for lots of different users, it's not 54768330Seric (yet) stable enough to fit the bill. 54868330Seric 54968330Seric Unfortunately, there are no known shareware/freeware 55068330Seric implementations of any operating system that provides the 55168334Seric level of stability necessary to handle that kind of load 55268334Seric (i.e., there are no free lunches). 55368334Seric 55468334Seric If you're wedded to the Intel x86 platform and want to run 55568334Seric sendmail, we suggest you look at commercial implementations 55668334Seric of Unix such as Interactive, UnixWare, Solaris, or 386BSD 55768334Seric (just a sample of the dozens of different versions of Unix 55868334Seric for Intel x86). 55968334Seric 56068334Seric Of all known vendor supported versions of Unix for Intel x86, 56168334Seric BSDI's BSD/386 is least expensive and the only one known to 56268334Seric currently ship with sendmail V8 pre-installed. Since sendmail 56368334Seric V8 is continuing to be developed at UC Berkeley, and BSD/386 56468334Seric is a full BSD 4.4 implementation, this is obviously be the most 56568334Seric "native" sendmail V8 environment. 56668330Seric---------------------------------------------------------------------- 56768330Seric * When I use sendmail on an Intel x86 machine running OS/2, I have 56868330Seric some problems. Specifically, I have.... 56968330Seric 57068330Seric The OS/2 port of sendmail is known to have left out huge 57168330Seric chunks of the code and functionality of even much older 57268330Seric versions of sendmail, in large part because the underlying OS 57368330Seric just doesn't have the necessary hooks to make it happen. 57468330Seric This port is so broken that we make no attempt to provide any 57568330Seric kind of support for it. Try BSDI's 386BSD instead. 57668330Seric---------------------------------------------------------------------- 57768330Seric * I'm connected to the network via a SLIP/PPP link. Sometimes my 57868330Seric sendmail process hangs (although it looks like part of the 57968330Seric message has been transfered). Everything else works. What's 58068330Seric wrong? 58168330Seric 58266282Seric Most likely, the problem isn't sendmail at all, but the low 58368330Seric level network connection. It's important that the MTU 58468330Seric (Maximum Transfer Unit) for the SLIP connection be set 58568330Seric properly at both ends. If they disagree, large packets will 58668330Seric be trashed and the connection will hang. 58766282Seric---------------------------------------------------------------------- 58866282Seric * I just upgraded to 8.x and suddenly I'm getting messages in my 58966282Seric syslog of the form "collect: I/O error on connection". What is 59066282Seric going wrong? 59166282Seric 59268330Seric Nothing. This is just a diagnosis of a condition that had 59368330Seric not been diagnosed before. If you are getting a lot of these 59468330Seric from a single host, there is probably some incompatibility 59568330Seric between 8.x and that host. If you get a lot of them in 59668330Seric general, you may have network problems that are causing 59768330Seric connections to get reset. 59866282Seric---------------------------------------------------------------------- 599*68338Seric * I just upgraded to 8.x and now when my users try to forward their 600*68338Seric mail to a program they get an "illegal shell" message and their 601*68338Seric mail is not delivered. What's wrong? 602*68338Seric 603*68338Seric In order for people to be able to run a program from their 604*68338Seric .forward file, 8.x insists that their shell (that is, the 605*68338Seric shell listed for that user in the passwd entry) be a "valid" 606*68338Seric shell, meaning a shell listed in /etc/shells. If /etc/shells 607*68338Seric does not exist, a default list is used, typically consisting 608*68338Seric of /bin/sh and /bin/csh. 609*68338Seric 610*68338Seric This is to support environments that may have NFS-shared 611*68338Seric directories mounted on machines on which users do not have 612*68338Seric login permission. For example, many people make their 613*68338Seric file server inaccessible for performance or security 614*68338Seric reasons; although users have directories, their shell on 615*68338Seric the server is /usr/local/etc/nologin or some such. If you 616*68338Seric allowed them to run programs anyway you might as well let 617*68338Seric them log in. 618*68338Seric 619*68338Seric If you are willing to let users run programs from their 620*68338Seric .forward file even though they cannot telnet or rsh in (as 621*68338Seric might be reasonable if you run smrsh to control the list of 622*68338Seric programs they can run) then add the line 623*68338Seric 624*68338Seric /SENDMAIL/ANY/SHELL/ 625*68338Seric 626*68338Seric to /etc/shells. This must be typed exactly as indicated, 627*68338Seric in caps, with the trailing slash. NOTA BENE: DO NOT 628*68338Seric list /usr/local/etc/nologin in /etc/shells -- this will 629*68338Seric open up other security problems. 630*68338Seric---------------------------------------------------------------------- 63167892Seric * I just upgraded to 8.x and suddenly connections to the SMTP port 63267892Seric take a long time. What is going wrong? 63367892Seric 63468330Seric It's probably something weird in your TCP implementation that 63567892Seric makes the IDENT code act oddly. On most systems V8 tries to 63667892Seric do a ``callback'' to the connecting host to get a validated 63768330Seric user name (see RFC 1413 for detail). If the connecting host 63868330Seric does not support such a service it will normally fail quickly 63968330Seric with "Connection refused", but certain kinds of packet 64068330Seric filters and certain TCP implementations just time out. 64167892Seric 64267892Seric To test this, set the IDENT timeout to zero using 64367892Seric ``OrIdent=0'' in the configuration file. This will 64467892Seric completely disable all use of the IDENT protocol. 64567892Seric 64667892Seric Another possible problem is that you have your name server 64768330Seric and/or resolver configured improperly. Make sure that all 64868330Seric "nameserver" entries in /etc/resolv.conf point to functional 64968330Seric servers. If you are running your own server make certain 65068330Seric that all the servers listed in your root cache (usually 65168330Seric called something like "/var/namedb/root.cache"; see your 65267892Seric /etc/named.boot file to get your value) are up to date. 65367892Seric Either of these can cause long delays. 65467892Seric---------------------------------------------------------------------- 655*68338Seric * I just upgraded to 8.x and suddenly I get errors such as ``unknown 656*68338Seric mailer error 5 -- mail: options MUST PRECEDE recipients.'' What is 657*68338Seric going wrong? 65867892Seric 65967892Seric You need OSTYPE(systype) in your .mc file -- otherwise the 66067892Seric configurations use a default that probably disagrees with 66167892Seric your local mail system. See cf/README for details. 66267892Seric---------------------------------------------------------------------- 66366282Seric * Under V8, the "From " header gets mysteriously munged when I send 66466282Seric to an alias. 66566282Seric 66668330Seric ``It's not a bug, it's a feature.'' This happens when you 66768330Seric have a "owner-list" alias and you send to "list". V8 66868330Seric propagates the owner information into the envelope sender 66968330Seric field (which appears as the "From " header on UNIX mail or as 67068330Seric the Return-Path: header) so that downstream errors are 67168330Seric properly returned to the mailing list owner instead of to the 67268330Seric sender. In order to make this appear as sensible as possible 67368330Seric to end users, I recommend making the owner point to a 67468330Seric "request" address -- for example: 67566282Seric 67666282Seric list: :include:/path/name/list.list 67766282Seric owner-list: list-request 67866282Seric list-request: eric 67966282Seric 68068330Seric This will make message sent to "list" come out as being "From 68168330Seric list-request" instead of "From eric". 68266282Seric---------------------------------------------------------------------- 68368330Seric * I am trying to use MASQUERADE_AS (or the user database) to 68468330Seric rewrite from addresses, and although it works in the From: header 68568330Seric line, it doesn't work in the envelope (e.g., the "From " line). 68668330Seric 68768330Seric Believe it or not, this is intentional. The interpretation 68868330Seric of the standards by the V8 development group was that this 68968330Seric was an inappropriate rewriting, and that if the rewriting 69068330Seric were incorrect at least the envelope would contain a valid 69168330Seric return address. Other people have since described scenarios 69268330Seric where the envelope cannot be correct without this rewriting, 69368330Seric so 8.7 will have an option to rewrite both header and 69468330Seric envelope. 69568330Seric---------------------------------------------------------------------- 69666285Seric * I want to run Sendmail version 8 on my DEC system, but you don't 69766285Seric have MAIL11V3 support in sendmail. How do I handle this? 69866285Seric 69968330Seric Get Paul Vixie's reimplementation of the mail11 protocol from 70068330Seric gatekeeper.dec.com in /pub/DEC/gwtools. 70168330Seric 70268330Seric Rumour has it that he will be fully integrating into sendmail 70368330Seric V8 what little is left of IDA sendmail that is not handled 70468330Seric (or handled as well) by V8. No additional information on 70568330Seric this project is currently available. 70666285Seric---------------------------------------------------------------------- 70768069Seric * Messages seem to disappear from my queue unsent. When I look in 70868330Seric the queue directory I see that they have been renamed from qf* to 70968330Seric Qf*, and sendmail doesn't see these. 71068069Seric 71168069Seric If you look closely you should find that the Qf files are 71268069Seric owned by users other than root. Since sendmail runs as root 71368069Seric it refuses to believe information in non-root-owned qf files, 71468330Seric and it renames them to Qf to get them out of the way and make 71568330Seric it easy for you to find. The usual cause of this is 71668069Seric twofold: first, you have the queue directory world writable 71768069Seric (which is probably a mistake -- this opens up other security 71868069Seric problems) and someone is calling sendmail with an "unsafe" 71968069Seric flag, usually a -o flag that sets an option that could 72068069Seric compromise security. When sendmail sees this it gives up 72168069Seric setuid root permissions. 72268069Seric 72368330Seric The usual solution is to not use the problematic flags. If 72468330Seric you must use them, you have to write a special queue 72568069Seric directory and have them processed by the same uid that 72668069Seric submitted the job in the first place. 72768069Seric---------------------------------------------------------------------- 728*68338Seric@(#)FAQ 8.13 (Berkeley) 02/15/95 72968330SericSend updates to sendmail@CS.Berkeley.EDU. 730