1Newsgroups: comp.mail.sendmail,comp.mail.misc,comp.mail.smail,comp.answers,news.answers 2Subject: comp.mail.sendmail Frequently Asked Questions (FAQ) 3From: brad@birch.ims.disa.mil (Brad Knowles) 4Followup-to: comp.mail.sendmail 5Summary: This posting contains a list of Frequently Asked Questions 6 (and their answers) about the program "sendmail", distributed 7 with many versions of Unix (and available for some other 8 operating systems). This FAQ is shared between 9 comp.mail.sendmail and the Sendmail V8 distribution. It should 10 be read by anyone who wishes to post to comp.mail.sendmail, or 11 anyone having questions about the newsgroup itself. 12 13Archive-name: mail/sendmail-faq 14Posting-Frequency: monthly (first Monday) 15 16 17[The most recent copy of this document can be obtained via anonymous 18FTP as rtfm.mit.edu:/pub/usenet/news.answers/mail/sendmail-faq. If 19you do not have access to anonymous FTP, you can retrieve it by 20sending email to mail-server@rtfm.mit.edu with the command "send 21usenet/news.answers/mail/sendmail-faq" in the message.] 22 23 24 25 Sendmail Version 8 26 Frequently Asked Questions 27 Last updated 02/16/95 28 29 30This FAQ is specific to Version 8.6.9 of sendmail. Other questions, 31particularly regarding compilation and configuration, are answered in 32src/READ_ME and cf/README (found in the V8 sendmail distribution). 33 34This is also the official FAQ for the Usenet newsgroup 35comp.mail.sendmail. 36 37====================================================================== 38BEFORE YOU GO ANY FURTHER 39====================================================================== 40 41 * What do you wish everyone would do before sending you mail or 42 posting to comp.mail.sendmail? 43 44 Read this FAQ completely. Read src/READ_ME and cf/README 45 completely. Read the books written to help with common 46 problems such as compilation and installation, configuration, 47 security issues, etc.... Ask themselves if their question 48 hasn't already been answered. 49---------------------------------------------------------------------- 50 * How can I be sure if this is the right place to look for answers 51 to my questions? 52 53 1. Do you know, for a fact, that the question is related to 54 sendmail V8? 55 56 2. Do you know, for a fact, that the question is related to an 57 older version of sendmail? 58 59 3. Is the question about a sendmail-like program (e.g., Smail, 60 Zmailer, MMDF, etc...)? 61 62 4. Is the question about an SMTP Gateway product for a LAN mail 63 package (e.g., cc:Mail, MS-Mail WordPerfect Office/GroupWise, 64 etc...)? 65 66 If you answered "yes" to the question #1, then this is the 67 right place. 68 69 If you answered "yes" to questions #2 or #3, then you should 70 seriously consider upgrading to the most recent version of 71 sendmail V8. 72 73 For question #2, If you're going to contiue using an older 74 version of sendmail, you may not find much help and will 75 probably get some responses that amount to "Get V8". 76 Otherwise, this is probably the best place to look for 77 answers. 78 79 If you answered "yes" to question #3 and are not going to 80 upgrade to sendmail V8, then this is probably not the right 81 place to look. 82 83 If you answered "yes" to question #4, then this is almost 84 certainly not the right place to look. 85 86 For questions #3 and #4, try looking around elsewhere in the 87 "comp.mail.*" hierarchy for a more appropriate newsgroup. 88 For example, you might want to try posting to comp.mail.misc 89 or comp.mail.smail. 90 91 If you couldn't answer "yes" to any of the above questions, 92 then you're DEFINITELY asking in the wrong place. For the 93 sake of your sanity and ego, not to mention avoiding the 94 waste of your time and ours, try asking your System or E-Mail 95 Administrator(s) before you post any questions publicly. 96---------------------------------------------------------------------- 97 * Where can I find the latest version of this FAQ? 98 99 It is included in the most recent Version 8 distribution of 100 sendmail (described below), as well as via anonymous FTP from 101 rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq. 102 If you do not have access to anonymous FTP, you can retrieve 103 it by sending email to mail-server@rtfm.mit.edu with the 104 command "send usenet/news.answers/mail/sendmail-faq" in the 105 message. 106---------------------------------------------------------------------- 107 * I don't have access to Usenet news. Can I still get access to 108 comp.mail.sendmail? 109 110 Yes. Send email to mxt@dl.ac.uk with the command "sub 111 comp-news.comp.mail.sendmail <full-US-ordered-email-address>" 112 in the message. 113 114 E-mail you want posted on comp.mail.sendmail should be sent 115 to comp-mail-sendmail@dl.ac.uk 116---------------------------------------------------------------------- 117 * I have sendmail-related DNS questions. Where should I ask them? 118 119 Depending on how deeply they get into the DNS, they can be 120 asked here. However, you'll probably be told that you should 121 send them to the Info-BIND mailing list (if the question is 122 specific to that program) or to the Usenet newsgroup 123 comp.protocols.tcp-ip.domains (DNS in general). 124---------------------------------------------------------------------- 125 * How do I subscribe to either of these? 126 127 For comp.protocols.tcp-ip.domains, you have to be on Usenet. 128 They don't have a news-to-mail gateway yet. 129 130 For the Info-BIND mailing list, send email to 131 bind-request@uunet.uu.net with the command "subscribe" in the 132 message. Submissions should be sent to bind@uunet.uu.net 133 134====================================================================== 135GENERAL QUESTIONS 136====================================================================== 137 138 * Where can I get Version 8? 139 140 Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. 141---------------------------------------------------------------------- 142 * What are the differences between Version 8 and other versions? 143 144 See doc/changes/changes.me in the sendmail distribution. 145---------------------------------------------------------------------- 146 * What happened to sendmail 6.x and 7.x? 147 148 When a new (Alpha/Beta) version of sendmail was released, it 149 was changed to Release 6. Development continued in that tree 150 until 4.4BSD was released, when everything on the 4.4 tape 151 was set to be version 8.1. Version 7.x never existed. 152---------------------------------------------------------------------- 153 * What books are available describing sendmail? 154 155 There is one book available devoted to sendmail: 156 157 Costales, Allman, and Rickert, _Sendmail_. O'Reilly & 158 Associates. 159 160 Several books have sendmail chapters, for example: 161 162 Nemeth, Snyder, and Seebass, _Unix System Administration 163 Handbook_. Prentice-Hall. 164 Carl-Mitchell and Quarterman, _Practical Internetworking with 165 TCP/IP and UNIX_. Addison-Wesley. 166 Hunt, _TCP/IP Network Administration_. O'Reilly & Associates. 167 168 Another book about sendmail is due out "soon": 169 170 Avolio & Vixie, _Sendmail Theory and Practice_. Digital 171 Press (release date unknown). 172 173 For details on sendmail-related DNS issues, consult: 174 175 Liu and Albitz, _DNS and BIND_. O'Reilly & Associates. 176 177 For details on UUCP, see: 178 179 O'Reilly and Todino, _Managing UUCP and Usenet_. 180 O'Reilly & Associates. 181 182====================================================================== 183COMPILING AND INSTALLING SENDMAIL 8 184====================================================================== 185 186 * Version 8 requires a new version of "make". Where can I get this? 187 188 Actually, Version 8 does not require a new version of "make". 189 It includes a collection of Makefiles for different architectures, 190 only one or two of which require the new "make". For a supported 191 architecture, use ``sh makesendmail''. If you are porting to a 192 new architecture, start with Makefile.dist. 193 194 If you really do want the new make, it is available on any of 195 the BSD Net2 or 4.4-Lite distribution sites. These include: 196 197 ftp.uu.net /systems/unix/bsd-sources 198 gatekeeper.dec.com /.0/BSD/net2 199 ucquais.cba.uc.edu /pub/net2 200 ftp.luth.se /pub/unix/4.3bsd/net2 201 202 Diffs and instructions for building this version of make 203 under SunOS 4.1.x are available on ftp.css.itd.umich.edu in 204 /pub/systems/sun/Net2-make.sun4.diff.Z. A patchkit for 205 Ultrix is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z. 206 Patches for AIX 3.2.4 are available on ftp.uni-stuttgart.de 207 in /sw/src/patches/bsd-make-rus-patches. 208 209 There is also a Linux version available on the main Linux 210 distribution sites as pmake; this version is included as 211 standard with the current Slackware distributions. 212---------------------------------------------------------------------- 213 * What macro package do I use to format the V8 man pages? 214 215 The BSD group switched over the the ``mandoc'' macros for the 216 4.4 release. These include more hooks designed for hypertext 217 handling. However, new man pages won't format under the old 218 man macros. Fortunately, old man pages will format under the 219 new mandoc macros. 220 221 Get the new macros with the BSD Net2 or 4.4-Lite release (see 222 above for locations; for example, on FTP.UU.NET the files 223 /system/unix/bsd-sources/share/tmac/me/strip/sed and 224 /system/unix/bsd-sources/share/tmac/* are what you need). 225 226 This macro set is also included with newer versions of groff. 227---------------------------------------------------------------------- 228 * What modes should be used when installing sendmail? 229 230 The sendmail binary should be owned by root, mode 4755. 231 The queue directory should be owned by root, with a mode 232 between 700 and 755. Under no circumstances should 233 it be group or other writable! 234 The sendmail config file should be owned by root, mode 644. 235 The aliases file should generally be owned by one trusted 236 user and writable only by that user, although it is 237 not unreasonable to have it group writable by a 238 "sysadmin" group. It should not be world writable. 239 The aliases database files (aliases.db or aliases.{pag,dir} 240 depending on what database format you compile with) 241 should be owned by root, mode 644. 242 243====================================================================== 244CONFIGURATION QUESTIONS 245====================================================================== 246 247 * How do I make all my addresses appear to be from a single host? 248 249 Using the V8 configuration macros, use: 250 251 MASQUERADE_AS(my.dom.ain) 252 253 This will cause all addresses to be sent out as being from 254 the indicated domain. 255---------------------------------------------------------------------- 256 * How do I rewrite my From: lines to read ``First_Last@My.Domain''? 257 258 There are a couple of ways of doing this. This describes 259 using the "user database" code. This is still experimental, 260 and was intended for a different purpose -- however, it does 261 work with a bit of care. It does require that you have the 262 Berkeley "db" package installed (it won't work with DBM). 263 264 First, create your input file. This should have lines like: 265 266 loginname:mailname First_Last 267 First_Last:maildrop loginname 268 269 Install it in (say) /etc/userdb. Create the database: 270 271 makemap btree /etc/userdb.db < /etc/userdb 272 273 You can then create a config file that uses this. You will 274 have to include the following in your .mc file: 275 276 define(confUSERDB_SPEC, /etc/userdb.db) 277 FEATURE(notsticky) 278---------------------------------------------------------------------- 279 * So what was the user database feature intended for? 280 281 The intent was to have all information for a given user 282 (where the user is the unique login name, not an inherently 283 non-unique full name) in one place. This would include phone 284 numbers, addresses, and so forth. The "maildrop" feature is 285 because Berkeley does not use a centralized mail server 286 (there are a number of reasons for this that are mostly 287 historic), and so we need to know where each user gets his or 288 her mail delivered -- i.e., the mail drop. 289 290 We are in the process of setting up our environment so that 291 mail sent to an unqualified "name" goes to that person's 292 preferred maildrop; mail sent to "name@host" goes to that 293 host. The purpose of "FEATURE(notsticky)" is to cause 294 "name@host" to be looked up in the user database for delivery 295 to the maildrop. 296---------------------------------------------------------------------- 297 * Why are you so hostile to using full names for e-mail addresses? 298 299 Because full names are not unique. For example, the computer 300 community has two Andy Tannenbaums and two Peter Deutsches. 301 At one time, Bell Labs had two Stephen R. Bournes with 302 offices a few doors apart. You can create alternative 303 addresses (e.g., Stephen_R_Bourne_2), but that's even worse 304 -- which one of them has to have their name desecrated in 305 this way? And you can bet that one of them will get most of 306 the other person's e-mail. 307 308 So called "full names" are just an attempt to create longer 309 versions of unique names. Rather that lulling people into a 310 sense of security, I'd rather that it be clear that these 311 handles are arbitrary. People should use good user agents 312 that have alias mappings so that they can attach arbitrary 313 names for their personal use to those with whom they 314 correspond (such as the MH alias file). 315 316 Even worse is fuzzy matching in e-mail -- this can make good 317 addresses turn bad. For example, Eric Allman is currently 318 (to the best of our knowledge) the only ``Allman'' at 319 Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to 320 him. But if another Allman ever appears, this address could 321 suddenly become ambiguous. He's been the only Allman at 322 Berkeley for over fifteen years -- to suddenly have this 323 "good address" bounce mail because it is ambiguous would be a 324 heinous wrong. 325 326 Finger services should be as fuzzy as possible (within 327 reason, of course). Mail services should be unique. 328---------------------------------------------------------------------- 329 * Should I use a wildcard MX for my domain? 330 331 If at all possible, no. 332 333 Wildcard MX records have lots of semantic "gotcha"s. For 334 example, they will match a host "unknown.your.domain" -- if 335 you don't explicitly test for unknown hosts in your domain, 336 you will get "config error: mail loops back to myself" 337 errors. 338---------------------------------------------------------------------- 339 * How can I get sendmail to process messages sent to an account and 340 send the results back to the originator? 341 342 This is a local mailer issue, not a sendmail issue. 343 Depending on what you're doing, look at procmail (mentioned 344 again below), ftpmail, or Majordomo. 345 346 Check your local archie server to see what machine(s) nearest 347 you have the most recent versions of these programs. 348---------------------------------------------------------------------- 349 * How can I get sendmail to deliver local mail to $HOME/.mail 350 instead of into /usr/spool/mail (or /usr/mail)? 351 352 Again, this is a local mailer issue, not a sendmail issue. 353 Either modify your local mailer (source code will be 354 required) or change the program called in the "local" mailer 355 configuration description to be a new program that does this 356 local delivery. I understand that "procmail" works well, 357 although I haven't used it myself. 358 359 You might be interested in reading the paper ``HLFSD: 360 Delivering Email to your $HOME'' available in the Proceedings 361 of the USENIX System Administration (LISA VII) Conference 362 (November 1993). This is also available via public FTP from 363 ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}. 364---------------------------------------------------------------------- 365 * I'm trying to to get my mail to go into queue only mode, and it 366 delivers the mail interactively anyway. (Or, I'm trying to use 367 the "don't deliver to expensive mailer" flag, and it delivers the 368 mail interactively anyway.) I can see it does it: here's the 369 output of "sendmail -v foo@somehost" (or Mail -v or equivalent). 370 371 The -v flag to sendmail (which is implied by the -v flag to 372 Mail and other programs in that family) tells sendmail to 373 watch the transaction. Since you have explicitly asked to 374 see what's going on, it assumes that you do not want to to 375 auto-queue, and turns that feature off. Remove the -v flag 376 and use a "tail -f" of the log instead to see what's going 377 on. 378 379 If you are trying to use the "don't deliver to expensive 380 mailer" flag (mailer flag "e"), be sure you also turn on 381 global option "c" -- otherwise it ignores the mailer flag. 382---------------------------------------------------------------------- 383 * There are four UUCP mailers listed in the configuration files. 384 Which one should I use? 385 386 The choice is partly a matter of local preferences and what 387 is running at the other end of your UUCP connection. Unlike 388 good protocols that define what will go over the wire, UUCP 389 uses the policy that you should do what is right for the 390 other end; if they change, you have to change. This makes it 391 hard to do the right thing, and discourages people from 392 updating their software. In general, if you can avoid UUCP, 393 please do. 394 395 If you can't avoid it, you'll have to find the version that 396 is closest to what the other end accepts. Following is a 397 summary of the UUCP mailers available. 398 399 uucp-old (obsolete name: "uucp") 400 This is the oldest, the worst (but the closest to UUCP) way 401 of sending messages across UUCP connections. It does 402 bangify everything and prepends $U (your UUCP name) to the 403 sender's address (which can already be a bang path 404 itself). It can only send to one address at a time, so it 405 spends a lot of time copying duplicates of messages. Avoid 406 this if at all possible. 407 408 uucp-new (obsolete name: "suucp") 409 The same as above, except that it assumes that in one rmail 410 command you can specify several recipients. It still has a 411 lot of other problems. 412 413 uucp-dom 414 This UUCP mailer keeps everything as domain addresses. 415 Basically, it uses the SMTP mailer rewriting rules. 416 417 Unfortunately, a lot of UUCP mailer transport agents 418 require bangified addresses in the envelope, although you 419 can use domain-based addresses in the message header. (The 420 envelope shows up as the From_ line on UNIX mail.) So.... 421 422 uucp-uudom 423 This is a cross between uucp-new (for the envelope 424 addresses) and uucp-dom (for the header addresses). It 425 bangifies the envelope sender (From_ line in messages) 426 without adding the local hostname, unless there is no host 427 name on the address at all (e.g., "wolf") or the host 428 component is a UUCP host name instead of a domain name 429 ("somehost!wolf" instead of "some.dom.ain!wolf"). 430 431 Examples: 432 433 We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). 434 The following summarizes the sender rewriting for various 435 mailers. 436 437 Mailer sender rewriting in the envelope 438 ------ ------ ------------------------- 439 uucp-{old,new} wolf grasp!wolf 440 uucp-dom wolf wolf@grasp.insa-lyon.fr 441 uucp-uudom wolf grasp.insa-lyon.fr!wolf 442 443 uucp-{old,new} wolf@fr.net grasp!fr.net!wolf 444 uucp-dom wolf@fr.net wolf@fr.net 445 uucp-uudom wolf@fr.net fr.net!wolf 446 447 uucp-{old,new} somehost!wolf grasp!somehost!wolf 448 uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr 449 uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf 450 451====================================================================== 452RESOLVING PROBLEMS 453====================================================================== 454 455 * When I compile, I get "undefined symbol inet_aton" messages. 456 457 You've probably replaced your resolver with the version from 458 BIND 4.9.3. You need to compile with -l44bsd in order to get 459 the additional routines. 460---------------------------------------------------------------------- 461 * I'm getting "Local configuration error" messages, such as: 462 463 553 relay.domain.net config error: mail loops back to myself 464 554 <user@domain.net>... Local configuration error 465 466 How can I solve this problem? 467 468 You have asked mail to the domain (e.g., domain.net) to be 469 forwarded to a specific host (in this case, relay.domain.net) 470 by using an MX record, but the relay machine doesn't 471 recognize itself as domain.net. Add domain.net to 472 /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or 473 add "Cw domain.net" to your configuration file. 474 475 IMPORTANT: Be sure you kill and restart the sendmail daemon 476 after you change the configuration file (for ANY change in 477 the configuration, not just this one): 478 479 kill `head -1 /etc/sendmail.pid` 480 sh -c "`tail -1 /etc/sendmail.pid`" 481 482 NOTA BENE: kill -1 does not work! 483---------------------------------------------------------------------- 484 * When I use sendmail V8 with a Sun config file I get lines like: 485 486 /etc/sendmail.cf: line 273: replacement $3 out of bounds 487 488 the line in question reads: 489 490 R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether 491 492 what does this mean? How do I fix it? 493 494 V8 doesn't recognize the Sun "$%y" syntax, so as far as it is 495 concerned, there is only a $1 and a $2 (but no $3) in this 496 line. Read Rick McCarty's paper on "Converting Standard Sun 497 Config Files to Sendmail Version 8", in the contrib directory 498 (file "converting.sun.configs") on the sendmail distribution 499 for a full discussion of how to do this. 500---------------------------------------------------------------------- 501 * When I use sendmail V8 on a Sun, I sometimes get lines like: 502 503 /etc/sendmail.cf: line 445: bad ruleset 96 (50 max) 504 505 what does this mean? How do I fix it? 506 507 You're somehow trying to start up the old Sun sendmail (or 508 sendmail.mx) with a sendmail V8 config file, which Sun's 509 sendmail doesn't like. Check your /etc/rc.local, any 510 procedures that have been created to stop and re-start the 511 sendmail processes, etc.... Make sure that you've switched 512 everything over to using the new sendmail. To keep this 513 problem from ever happening again, try the following: 514 515 mv /usr/lib/sendmail /usr/lib/sendmail.old 516 ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail 517 mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old 518 ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx 519 chmod 0000 /usr/lib/sendmail.old 520 chmod 0000 /usr/lib/sendmail.mx.old 521 522 Assuming you have installed sendmail V8 in /usr/local/lib. 523---------------------------------------------------------------------- 524 * When I use sendmail V8 on an IBM RS/6000 running AIX, the system 525 resource controller always reports sendmail as "inoperative" even 526 though it is running. What's wrong? 527 528 IBM's system resource controller is one of their "value 529 added" features to AIX -- it's not a Unix standard. You'll 530 need to either redefine the subsystem to use signals (see 531 chssys(1)) or dump the entire subsystem and invoke sendmail 532 in /etc/rc.tcpip or some other boot script. 533---------------------------------------------------------------------- 534 * When I use sendmail V8 on an Intel x86 machine running Linux, I 535 have some problems. Specifically, I have.... 536 537 The current versions of Linux are generally considered to be 538 great for hobbyists and anyone else who wants to learn Unix 539 inside and out, or wants to always have something to do, or 540 wants a machine for light-duty mostly personal use and not 541 high-volume multi-user purposes. 542 543 However, for those who want a system that will just sit in 544 the background and work without a fuss handling thousands of 545 mail messages a day for lots of different users, it's not 546 (yet) stable enough to fit the bill. 547 548 Unfortunately, there are no known shareware/freeware 549 implementations of any operating system that provides the 550 level of stability necessary to handle that kind of load 551 (i.e., there are no free lunches). 552 553 If you're wedded to the Intel x86 platform and want to run 554 sendmail, we suggest you look at commercial implementations 555 of Unix such as Interactive, UnixWare, Solaris, or 386BSD 556 (just a sample of the dozens of different versions of Unix 557 for Intel x86). 558 559 Of all known vendor supported versions of Unix for Intel x86, 560 BSDI's BSD/386 is least expensive and the only one known to 561 currently ship with sendmail V8 pre-installed. Since sendmail 562 V8 is continuing to be developed at UC Berkeley, and BSD/386 563 is a full BSD 4.4 implementation, this is obviously be the most 564 "native" sendmail V8 environment. 565---------------------------------------------------------------------- 566 * When I use sendmail on an Intel x86 machine running OS/2, I have 567 some problems. Specifically, I have.... 568 569 The OS/2 port of sendmail is known to have left out huge 570 chunks of the code and functionality of even much older 571 versions of sendmail, in large part because the underlying OS 572 just doesn't have the necessary hooks to make it happen. 573 This port is so broken that we make no attempt to provide any 574 kind of support for it. Try BSDI's 386BSD instead. 575---------------------------------------------------------------------- 576 * I'm connected to the network via a SLIP/PPP link. Sometimes my 577 sendmail process hangs (although it looks like part of the 578 message has been transfered). Everything else works. What's 579 wrong? 580 581 Most likely, the problem isn't sendmail at all, but the low 582 level network connection. It's important that the MTU 583 (Maximum Transfer Unit) for the SLIP connection be set 584 properly at both ends. If they disagree, large packets will 585 be trashed and the connection will hang. 586---------------------------------------------------------------------- 587 * I just upgraded to 8.x and suddenly I'm getting messages in my 588 syslog of the form "collect: I/O error on connection". What is 589 going wrong? 590 591 Nothing. This is just a diagnosis of a condition that had 592 not been diagnosed before. If you are getting a lot of these 593 from a single host, there is probably some incompatibility 594 between 8.x and that host. If you get a lot of them in 595 general, you may have network problems that are causing 596 connections to get reset. 597---------------------------------------------------------------------- 598 * I just upgraded to 8.x and now when my users try to forward their 599 mail to a program they get an "illegal shell" message and their 600 mail is not delivered. What's wrong? 601 602 In order for people to be able to run a program from their 603 .forward file, 8.x insists that their shell (that is, the 604 shell listed for that user in the passwd entry) be a "valid" 605 shell, meaning a shell listed in /etc/shells. If /etc/shells 606 does not exist, a default list is used, typically consisting 607 of /bin/sh and /bin/csh. 608 609 This is to support environments that may have NFS-shared 610 directories mounted on machines on which users do not have 611 login permission. For example, many people make their 612 file server inaccessible for performance or security 613 reasons; although users have directories, their shell on 614 the server is /usr/local/etc/nologin or some such. If you 615 allowed them to run programs anyway you might as well let 616 them log in. 617 618 If you are willing to let users run programs from their 619 .forward file even though they cannot telnet or rsh in (as 620 might be reasonable if you run smrsh to control the list of 621 programs they can run) then add the line 622 623 /SENDMAIL/ANY/SHELL/ 624 625 to /etc/shells. This must be typed exactly as indicated, 626 in caps, with the trailing slash. NOTA BENE: DO NOT 627 list /usr/local/etc/nologin in /etc/shells -- this will 628 open up other security problems. 629---------------------------------------------------------------------- 630 * I just upgraded to 8.x and suddenly connections to the SMTP port 631 take a long time. What is going wrong? 632 633 It's probably something weird in your TCP implementation that 634 makes the IDENT code act oddly. On most systems V8 tries to 635 do a ``callback'' to the connecting host to get a validated 636 user name (see RFC 1413 for detail). If the connecting host 637 does not support such a service it will normally fail quickly 638 with "Connection refused", but certain kinds of packet 639 filters and certain TCP implementations just time out. 640 641 To test this, set the IDENT timeout to zero using 642 ``OrIdent=0'' in the configuration file. This will 643 completely disable all use of the IDENT protocol. 644 645 Another possible problem is that you have your name server 646 and/or resolver configured improperly. Make sure that all 647 "nameserver" entries in /etc/resolv.conf point to functional 648 servers. If you are running your own server make certain 649 that all the servers listed in your root cache (usually 650 called something like "/var/namedb/root.cache"; see your 651 /etc/named.boot file to get your value) are up to date. 652 Either of these can cause long delays. 653---------------------------------------------------------------------- 654 * I just upgraded to 8.x and suddenly I get errors such as ``unknown 655 mailer error 5 -- mail: options MUST PRECEDE recipients.'' What is 656 going wrong? 657 658 You need OSTYPE(systype) in your .mc file -- otherwise the 659 configurations use a default that probably disagrees with 660 your local mail system. See cf/README for details. 661---------------------------------------------------------------------- 662 * Under V8, the "From " header gets mysteriously munged when I send 663 to an alias. 664 665 ``It's not a bug, it's a feature.'' This happens when you 666 have a "owner-list" alias and you send to "list". V8 667 propagates the owner information into the envelope sender 668 field (which appears as the "From " header on UNIX mail or as 669 the Return-Path: header) so that downstream errors are 670 properly returned to the mailing list owner instead of to the 671 sender. In order to make this appear as sensible as possible 672 to end users, I recommend making the owner point to a 673 "request" address -- for example: 674 675 list: :include:/path/name/list.list 676 owner-list: list-request 677 list-request: eric 678 679 This will make message sent to "list" come out as being "From 680 list-request" instead of "From eric". 681---------------------------------------------------------------------- 682 * I am trying to use MASQUERADE_AS (or the user database) to 683 rewrite from addresses, and although it works in the From: header 684 line, it doesn't work in the envelope (e.g., the "From " line). 685 686 Believe it or not, this is intentional. The interpretation 687 of the standards by the V8 development group was that this 688 was an inappropriate rewriting, and that if the rewriting 689 were incorrect at least the envelope would contain a valid 690 return address. Other people have since described scenarios 691 where the envelope cannot be correct without this rewriting, 692 so 8.7 will have an option to rewrite both header and 693 envelope. 694---------------------------------------------------------------------- 695 * I want to run Sendmail version 8 on my DEC system, but you don't 696 have MAIL11V3 support in sendmail. How do I handle this? 697 698 Get Paul Vixie's reimplementation of the mail11 protocol from 699 gatekeeper.dec.com in /pub/DEC/gwtools. 700 701 Rumour has it that he will be fully integrating into sendmail 702 V8 what little is left of IDA sendmail that is not handled 703 (or handled as well) by V8. No additional information on 704 this project is currently available. 705---------------------------------------------------------------------- 706 * Messages seem to disappear from my queue unsent. When I look in 707 the queue directory I see that they have been renamed from qf* to 708 Qf*, and sendmail doesn't see these. 709 710 If you look closely you should find that the Qf files are 711 owned by users other than root. Since sendmail runs as root 712 it refuses to believe information in non-root-owned qf files, 713 and it renames them to Qf to get them out of the way and make 714 it easy for you to find. The usual cause of this is 715 twofold: first, you have the queue directory world writable 716 (which is probably a mistake -- this opens up other security 717 problems) and someone is calling sendmail with an "unsafe" 718 flag, usually a -o flag that sets an option that could 719 compromise security. When sendmail sees this it gives up 720 setuid root permissions. 721 722 The usual solution is to not use the problematic flags. If 723 you must use them, you have to write a special queue 724 directory and have them processed by the same uid that 725 submitted the job in the first place. 726---------------------------------------------------------------------- 727@(#)FAQ 8.14 (Berkeley) 02/16/95 728Send updates to sendmail@CS.Berkeley.EDU. 729