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 from rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq. 19If you 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/24/95 28 29 30This FAQ is specific to Version 8.6.10 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 63 mail package (e.g., cc:Mail, MS-Mail, WordPerfect 64 Office/GroupWise, 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 continue 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 in the wrong place. For the sake of 93 your sanity and ego, not to mention avoiding the waste of 94 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 See RFCs 1535-1537 for more detail and other related (or 340 common) problems. 341---------------------------------------------------------------------- 342 * How can I get sendmail to process messages sent to an account and 343 send the results back to the originator? 344 345 This is a local mailer issue, not a sendmail issue. 346 Depending on what you're doing, look at procmail (mentioned 347 again below), ftpmail, or Majordomo. 348 349 Check your local archie server to see what machine(s) nearest 350 you have the most recent versions of these programs. 351---------------------------------------------------------------------- 352 * How can I get sendmail to deliver local mail to $HOME/.mail 353 instead of into /usr/spool/mail (or /usr/mail)? 354 355 Again, this is a local mailer issue, not a sendmail issue. 356 Either modify your local mailer (source code will be 357 required) or change the program called in the "local" mailer 358 configuration description to be a new program that does this 359 local delivery. One program that is capable of doing this is 360 "procmail", although there are probably many others as well. 361 362 You might be interested in reading the paper ``HLFSD: 363 Delivering Email to your $HOME'' available in the Proceedings 364 of the USENIX System Administration (LISA VII) Conference 365 (November 1993). This is also available via public FTP from 366 ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}. 367---------------------------------------------------------------------- 368 * I'm trying to to get my mail to go into queue only mode, and it 369 delivers the mail interactively anyway. (Or, I'm trying to use 370 the "don't deliver to expensive mailer" flag, and it delivers the 371 mail interactively anyway.) I can see it does it: here's the 372 output of "sendmail -v foo@somehost" (or Mail -v or equivalent). 373 374 The -v flag to sendmail (which is implied by the -v flag to 375 Mail and other programs in that family) tells sendmail to 376 watch the transaction. Since you have explicitly asked to 377 see what's going on, it assumes that you do not want to to 378 auto-queue, and turns that feature off. Remove the -v flag 379 and use a "tail -f" of the log instead to see what's going 380 on. 381 382 If you are trying to use the "don't deliver to expensive 383 mailer" flag (mailer flag "e"), be sure you also turn on 384 global option "c" -- otherwise it ignores the mailer flag. 385---------------------------------------------------------------------- 386 * There are four UUCP mailers listed in the configuration files. 387 Which one should I use? 388 389 The choice is partly a matter of local preferences and what 390 is running at the other end of your UUCP connection. Unlike 391 good protocols that define what will go over the wire, UUCP 392 uses the policy that you should do what is right for the 393 other end; if they change, you have to change. This makes it 394 hard to do the right thing, and discourages people from 395 updating their software. In general, if you can avoid UUCP, 396 please do. 397 398 If you can't avoid it, you'll have to find the version that 399 is closest to what the other end accepts. Following is a 400 summary of the UUCP mailers available. 401 402 uucp-old (obsolete name: "uucp") 403 This is the oldest, the worst (but the closest to UUCP) way 404 of sending messages across UUCP connections. It does 405 bangify everything and prepends $U (your UUCP name) to the 406 sender's address (which can already be a bang path 407 itself). It can only send to one address at a time, so it 408 spends a lot of time copying duplicates of messages. Avoid 409 this if at all possible. 410 411 uucp-new (obsolete name: "suucp") 412 The same as above, except that it assumes that in one rmail 413 command you can specify several recipients. It still has a 414 lot of other problems. 415 416 uucp-dom 417 This UUCP mailer keeps everything as domain addresses. 418 Basically, it uses the SMTP mailer rewriting rules. 419 420 Unfortunately, a lot of UUCP mailer transport agents 421 require bangified addresses in the envelope, although you 422 can use domain-based addresses in the message header. (The 423 envelope shows up as the From_ line on UNIX mail.) So.... 424 425 uucp-uudom 426 This is a cross between uucp-new (for the envelope 427 addresses) and uucp-dom (for the header addresses). It 428 bangifies the envelope sender (From_ line in messages) 429 without adding the local hostname, unless there is no host 430 name on the address at all (e.g., "wolf") or the host 431 component is a UUCP host name instead of a domain name 432 ("somehost!wolf" instead of "some.dom.ain!wolf"). 433 434 Examples: 435 436 We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). 437 The following summarizes the sender rewriting for various 438 mailers. 439 440 Mailer sender rewriting in the envelope 441 ------ ------ ------------------------- 442 uucp-{old,new} wolf grasp!wolf 443 uucp-dom wolf wolf@grasp.insa-lyon.fr 444 uucp-uudom wolf grasp.insa-lyon.fr!wolf 445 446 uucp-{old,new} wolf@fr.net grasp!fr.net!wolf 447 uucp-dom wolf@fr.net wolf@fr.net 448 uucp-uudom wolf@fr.net fr.net!wolf 449 450 uucp-{old,new} somehost!wolf grasp!somehost!wolf 451 uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr 452 uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf 453 454====================================================================== 455RESOLVING PROBLEMS 456====================================================================== 457 458 * When I compile, I get "undefined symbol inet_aton" messages. 459 460 You've probably replaced your resolver with the version from 461 BIND 4.9.3. You need to compile with -l44bsd in order to get 462 the additional routines. 463---------------------------------------------------------------------- 464 * I'm getting "Local configuration error" messages, such as: 465 466 553 relay.domain.net config error: mail loops back to myself 467 554 <user@domain.net>... Local configuration error 468 469 How can I solve this problem? 470 471 You have asked mail to the domain (e.g., domain.net) to be 472 forwarded to a specific host (in this case, relay.domain.net) 473 by using an MX record, but the relay machine doesn't 474 recognize itself as domain.net. Add domain.net to 475 /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or 476 add "Cw domain.net" to your configuration file. 477 478 IMPORTANT: Be sure you kill and restart the sendmail daemon 479 after you change the configuration file (for ANY change in 480 the configuration, not just this one): 481 482 kill `head -1 /etc/sendmail.pid` 483 sh -c "`tail -1 /etc/sendmail.pid`" 484 485 NOTA BENE: kill -1 does not work! 486---------------------------------------------------------------------- 487 * When I use sendmail V8 with a Sun config file I get lines like: 488 489 /etc/sendmail.cf: line 273: replacement $3 out of bounds 490 491 the line in question reads: 492 493 R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether 494 495 what does this mean? How do I fix it? 496 497 V8 doesn't recognize the Sun "$%y" syntax, so as far as it is 498 concerned, there is only a $1 and a $2 (but no $3) in this 499 line. Read Rick McCarty's paper on "Converting Standard Sun 500 Config Files to Sendmail Version 8", in the contrib directory 501 (file "converting.sun.configs") on the sendmail distribution 502 for a full discussion of how to do this. 503---------------------------------------------------------------------- 504 * When I use sendmail V8 on a Sun, I sometimes get lines like: 505 506 /etc/sendmail.cf: line 445: bad ruleset 96 (50 max) 507 508 what does this mean? How do I fix it? 509 510 You're somehow trying to start up the old Sun sendmail (or 511 sendmail.mx) with a sendmail V8 config file, which Sun's 512 sendmail doesn't like. Check your /etc/rc.local, any 513 procedures that have been created to stop and re-start the 514 sendmail processes, etc.... Make sure that you've switched 515 everything over to using the new sendmail. To keep this 516 problem from ever happening again, try the following: 517 518 mv /usr/lib/sendmail /usr/lib/sendmail.old 519 ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail 520 mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old 521 ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx 522 chmod 0000 /usr/lib/sendmail.old 523 chmod 0000 /usr/lib/sendmail.mx.old 524 525 Assuming you have installed sendmail V8 in /usr/local/lib. 526---------------------------------------------------------------------- 527 * When I use sendmail V8 on an IBM RS/6000 running AIX, the system 528 resource controller always reports sendmail as "inoperative" even 529 though it is running. What's wrong? 530 531 IBM's system resource controller is one of their "value 532 added" features to AIX -- it's not a Unix standard. You'll 533 need to either redefine the subsystem to use signals (see 534 chssys(1)) or dump the entire subsystem and invoke sendmail 535 in /etc/rc.tcpip or some other boot script. 536---------------------------------------------------------------------- 537 * When I use sendmail V8 on an Intel x86 machine running Linux, I 538 have some problems. Specifically, I have.... 539 540 The current versions of Linux are generally considered to be 541 great for hobbyists and anyone else who wants to learn Unix 542 inside and out, or wants to always have something to do, or 543 wants a machine for light-duty mostly personal use and not 544 high-volume multi-user purposes. 545 546 However, for those who want a system that will just sit in 547 the background and work without a fuss handling thousands of 548 mail messages a day for lots of different users, it's not 549 (yet) stable enough to fit the bill. 550 551 Unfortunately, there are no known shareware/freeware 552 implementations of any operating system that provides the 553 level of stability necessary to handle that kind of load 554 (i.e., there are no free lunches). 555 556 If you're wedded to the Intel x86 platform and want to run 557 sendmail, we suggest you look at commercial implementations 558 of Unix such as Interactive, UnixWare, Solaris, or BSD/386 559 (just a sample of the dozens of different versions of Unix 560 for Intel x86). 561 562 Of all known vendor supported versions of Unix for Intel x86, 563 BSDI's BSD/386 is least expensive and the only one known to 564 currently ship with sendmail V8 pre-installed. Since sendmail 565 V8 is continuing to be developed at UC Berkeley, and BSD/386 566 is a full BSD 4.4 implementation, this is obviously be the most 567 "native" sendmail V8 environment. 568---------------------------------------------------------------------- 569 * When I use sendmail on an Intel x86 machine running OS/2, I have 570 some problems. Specifically, I have.... 571 572 The OS/2 port of sendmail is known to have left out huge 573 chunks of the code and functionality of even much older 574 versions of sendmail, in large part because the underlying OS 575 just doesn't have the necessary hooks to make it happen. 576 This port is so broken that we make no attempt to provide any 577 kind of support for it. Try BSDI's BSD/386 instead. 578---------------------------------------------------------------------- 579 * I'm connected to the network via a SLIP/PPP link. Sometimes my 580 sendmail process hangs (although it looks like part of the 581 message has been transfered). Everything else works. What's 582 wrong? 583 584 Most likely, the problem isn't sendmail at all, but the low 585 level network connection. It's important that the MTU 586 (Maximum Transfer Unit) for the SLIP connection be set 587 properly at both ends. If they disagree, large packets will 588 be trashed and the connection will hang. 589---------------------------------------------------------------------- 590 * I just upgraded to 8.x and suddenly I'm getting messages in my 591 syslog of the form "collect: I/O error on connection". What is 592 going wrong? 593 594 Nothing. This is just a diagnosis of a condition that had 595 not been diagnosed before. If you are getting a lot of these 596 from a single host, there is probably some incompatibility 597 between 8.x and that host. If you get a lot of them in 598 general, you may have network problems that are causing 599 connections to get reset. 600---------------------------------------------------------------------- 601 * I just upgraded to 8.x and now when my users try to forward their 602 mail to a program they get an "illegal shell" message and their 603 mail is not delivered. What's wrong? 604 605 In order for people to be able to run a program from their 606 .forward file, 8.x insists that their shell (that is, the 607 shell listed for that user in the passwd entry) be a "valid" 608 shell, meaning a shell listed in /etc/shells. If /etc/shells 609 does not exist, a default list is used, typically consisting 610 of /bin/sh and /bin/csh. 611 612 This is to support environments that may have NFS-shared 613 directories mounted on machines on which users do not have 614 login permission. For example, many people make their 615 file server inaccessible for performance or security 616 reasons; although users have directories, their shell on 617 the server is /usr/local/etc/nologin or some such. If you 618 allowed them to run programs anyway you might as well let 619 them log in. 620 621 If you are willing to let users run programs from their 622 .forward file even though they cannot telnet or rsh in (as 623 might be reasonable if you run smrsh to control the list of 624 programs they can run) then add the line 625 626 /SENDMAIL/ANY/SHELL/ 627 628 to /etc/shells. This must be typed exactly as indicated, 629 in caps, with the trailing slash. NOTA BENE: DO NOT 630 list /usr/local/etc/nologin in /etc/shells -- this will 631 open up other security problems. 632---------------------------------------------------------------------- 633 * I just upgraded to 8.x and suddenly connections to the SMTP port 634 take a long time. What is going wrong? 635 636 It's probably something weird in your TCP implementation that 637 makes the IDENT code act oddly. On most systems V8 tries to 638 do a ``callback'' to the connecting host to get a validated 639 user name (see RFC 1413 for detail). If the connecting host 640 does not support such a service it will normally fail quickly 641 with "Connection refused", but certain kinds of packet 642 filters and certain TCP implementations just time out. 643 644 To test this, set the IDENT timeout to zero using 645 ``OrIdent=0'' in the configuration file. This will 646 completely disable all use of the IDENT protocol. 647 648 Another possible problem is that you have your name server 649 and/or resolver configured improperly. Make sure that all 650 "nameserver" entries in /etc/resolv.conf point to functional 651 servers. If you are running your own server make certain 652 that all the servers listed in your root cache (usually 653 called something like "/var/namedb/root.cache"; see your 654 /etc/named.boot file to get your value) are up to date. 655 Either of these can cause long delays. 656---------------------------------------------------------------------- 657 * I just upgraded to 8.x and suddenly I get errors such as ``unknown 658 mailer error 5 -- mail: options MUST PRECEDE recipients.'' What is 659 going wrong? 660 661 You need OSTYPE(systype) in your .mc file -- otherwise the 662 configurations use a default that probably disagrees with 663 your local mail system. See cf/README for details. 664---------------------------------------------------------------------- 665 * Under V8, the "From " header gets mysteriously munged when I send 666 to an alias. 667 668 ``It's not a bug, it's a feature.'' This happens when you 669 have a "owner-list" alias and you send to "list". V8 670 propagates the owner information into the envelope sender 671 field (which appears as the "From " header on UNIX mail or as 672 the Return-Path: header) so that downstream errors are 673 properly returned to the mailing list owner instead of to the 674 sender. In order to make this appear as sensible as possible 675 to end users, I recommend making the owner point to a 676 "request" address -- for example: 677 678 list: :include:/path/name/list.list 679 owner-list: list-request 680 list-request: eric 681 682 This will make message sent to "list" come out as being "From 683 list-request" instead of "From eric". 684---------------------------------------------------------------------- 685 * I am trying to use MASQUERADE_AS (or the user database) to 686 rewrite from addresses, and although it works in the From: header 687 line, it doesn't work in the envelope (e.g., the "From " line). 688 689 Believe it or not, this is intentional. The interpretation 690 of the standards by the V8 development group was that this 691 was an inappropriate rewriting, and that if the rewriting 692 were incorrect at least the envelope would contain a valid 693 return address. Other people have since described scenarios 694 where the envelope cannot be correct without this rewriting, 695 so 8.7 will have an option to rewrite both header and 696 envelope. 697---------------------------------------------------------------------- 698 * I want to run Sendmail version 8 on my DEC system, but you don't 699 have MAIL11V3 support in sendmail. How do I handle this? 700 701 Get Paul Vixie's reimplementation of the mail11 protocol from 702 gatekeeper.dec.com in /pub/DEC/gwtools. 703 704 Rumour has it that he will be fully integrating into sendmail 705 V8 what little is left of IDA sendmail that is not handled 706 (or handled as well) by V8. No additional information on 707 this project is currently available. 708---------------------------------------------------------------------- 709 * Messages seem to disappear from my queue unsent. When I look in 710 the queue directory I see that they have been renamed from qf* to 711 Qf*, and sendmail doesn't see these. 712 713 If you look closely you should find that the Qf files are 714 owned by users other than root. Since sendmail runs as root 715 it refuses to believe information in non-root-owned qf files, 716 and it renames them to Qf to get them out of the way and make 717 it easy for you to find. The usual cause of this is 718 twofold: first, you have the queue directory world writable 719 (which is probably a mistake -- this opens up other security 720 problems) and someone is calling sendmail with an "unsafe" 721 flag, usually a -o flag that sets an option that could 722 compromise security. When sendmail sees this it gives up 723 setuid root permissions. 724 725 The usual solution is to not use the problematic flags. If 726 you must use them, you have to write a special queue 727 directory and have them processed by the same uid that 728 submitted the job in the first place. 729---------------------------------------------------------------------- 730@(#)FAQ 8.15 (Berkeley) 02/24/95 731Send updates to sendmail@CS.Berkeley.EDU. 732