Commit | Line | Data |
---|---|---|
924e1e40 EA |
1 | Newsgroups: comp.mail.sendmail,comp.mail.misc,comp.mail.smail,comp.answers,news.answers |
2 | Subject: comp.mail.sendmail Frequently Asked Questions (FAQ) | |
3 | From: brad@birch.ims.disa.mil (Brad Knowles) | |
4 | Followup-to: comp.mail.sendmail | |
5 | Summary: 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 | ||
13 | Archive-name: mail/sendmail-faq | |
14 | Posting-Frequency: monthly (first Monday) | |
924e1e40 EA |
15 | |
16 | ||
17 | [The most recent copy of this document can be obtained via anonymous | |
31e11046 EA |
18 | FTP from rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq. |
19 | If you do not have access to anonymous FTP, you can retrieve it by | |
924e1e40 EA |
20 | sending email to mail-server@rtfm.mit.edu with the command "send |
21 | usenet/news.answers/mail/sendmail-faq" in the message.] | |
22 | ||
23 | ||
24 | ||
3055c3a0 EA |
25 | Sendmail Version 8 |
26 | Frequently Asked Questions | |
924e1e40 EA |
27 | Last updated %G% |
28 | ||
3055c3a0 | 29 | |
31e11046 | 30 | This FAQ is specific to Version 8.6.10 of sendmail. Other questions, |
924e1e40 EA |
31 | particularly regarding compilation and configuration, are answered in |
32 | src/READ_ME and cf/README (found in the V8 sendmail distribution). | |
3055c3a0 | 33 | |
924e1e40 EA |
34 | This is also the official FAQ for the Usenet newsgroup |
35 | comp.mail.sendmail. | |
3055c3a0 | 36 | |
9ffbc9da | 37 | ====================================================================== |
924e1e40 | 38 | BEFORE YOU GO ANY FURTHER |
9ffbc9da EA |
39 | ====================================================================== |
40 | ||
924e1e40 EA |
41 | * What do you wish everyone would do before sending you mail or |
42 | posting to comp.mail.sendmail? | |
c0ac82a2 EA |
43 | |
44 | Read this FAQ completely. Read src/READ_ME and cf/README | |
924e1e40 EA |
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 | |
b2f10127 | 54 | sendmail V8? |
924e1e40 EA |
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 | ||
31e11046 EA |
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...)? | |
924e1e40 EA |
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 | ||
31e11046 | 73 | For question #2, If you're going to continue using an older |
924e1e40 EA |
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, | |
31e11046 EA |
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 | |
924e1e40 EA |
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). | |
21446efc | 124 | ---------------------------------------------------------------------- |
924e1e40 EA |
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 | ====================================================================== | |
135 | GENERAL QUESTIONS | |
136 | ====================================================================== | |
137 | ||
21446efc EA |
138 | * Where can I get Version 8? |
139 | ||
140 | Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. | |
3055c3a0 EA |
141 | ---------------------------------------------------------------------- |
142 | * What are the differences between Version 8 and other versions? | |
143 | ||
21446efc | 144 | See doc/changes/changes.me in the sendmail distribution. |
3055c3a0 EA |
145 | ---------------------------------------------------------------------- |
146 | * What happened to sendmail 6.x and 7.x? | |
147 | ||
924e1e40 EA |
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. | |
3055c3a0 | 152 | ---------------------------------------------------------------------- |
9ffbc9da EA |
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 | ||
924e1e40 EA |
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 | ||
9ffbc9da EA |
182 | ====================================================================== |
183 | COMPILING AND INSTALLING SENDMAIL 8 | |
184 | ====================================================================== | |
185 | ||
3055c3a0 EA |
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, | |
c0ac82a2 EA |
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. | |
3055c3a0 EA |
193 | |
194 | If you really do want the new make, it is available on any of | |
21446efc | 195 | the BSD Net2 or 4.4-Lite distribution sites. These include: |
3055c3a0 EA |
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 | ||
924e1e40 EA |
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. | |
7de17422 EA |
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. | |
3055c3a0 EA |
212 | ---------------------------------------------------------------------- |
213 | * What macro package do I use to format the V8 man pages? | |
214 | ||
924e1e40 EA |
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. | |
3055c3a0 | 220 | |
924e1e40 EA |
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). | |
3055c3a0 | 225 | |
924e1e40 | 226 | This macro set is also included with newer versions of groff. |
516636f7 EA |
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 | |
924e1e40 EA |
232 | between 700 and 755. Under no circumstances should |
233 | it be group or other writable! | |
516636f7 EA |
234 | The sendmail config file should be owned by root, mode 644. |
235 | The aliases file should generally be owned by one trusted | |
924e1e40 EA |
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. | |
516636f7 EA |
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. | |
3055c3a0 | 242 | |
9ffbc9da EA |
243 | ====================================================================== |
244 | CONFIGURATION QUESTIONS | |
245 | ====================================================================== | |
21446efc | 246 | |
3055c3a0 EA |
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 | ||
924e1e40 EA |
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). | |
3055c3a0 EA |
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 | ||
924e1e40 EA |
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. | |
3055c3a0 EA |
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. | |
924e1e40 EA |
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. | |
3055c3a0 | 307 | |
c0ac82a2 EA |
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 | |
924e1e40 EA |
313 | names for their personal use to those with whom they |
314 | correspond (such as the MH alias file). | |
3055c3a0 EA |
315 | |
316 | Even worse is fuzzy matching in e-mail -- this can make good | |
924e1e40 EA |
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. | |
3055c3a0 | 325 | |
c0ac82a2 EA |
326 | Finger services should be as fuzzy as possible (within |
327 | reason, of course). Mail services should be unique. | |
9ffbc9da EA |
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. | |
31e11046 EA |
338 | |
339 | See RFCs 1535-1537 for more detail and other related (or | |
340 | common) problems. | |
924e1e40 EA |
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. | |
9ffbc9da EA |
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 | ||
924e1e40 EA |
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 | |
31e11046 EA |
359 | local delivery. One program that is capable of doing this is |
360 | "procmail", although there are probably many others as well. | |
924e1e40 EA |
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}. | |
9ffbc9da EA |
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 | |
924e1e40 EA |
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). | |
9ffbc9da EA |
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 | |
924e1e40 EA |
379 | and use a "tail -f" of the log instead to see what's going |
380 | on. | |
9ffbc9da | 381 | |
924e1e40 EA |
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. | |
9ffbc9da EA |
385 | ---------------------------------------------------------------------- |
386 | * There are four UUCP mailers listed in the configuration files. | |
387 | Which one should I use? | |
388 | ||
924e1e40 EA |
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. | |
9ffbc9da | 397 | |
924e1e40 EA |
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. | |
9ffbc9da EA |
401 | |
402 | uucp-old (obsolete name: "uucp") | |
924e1e40 EA |
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. | |
9ffbc9da EA |
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 | ||
924e1e40 EA |
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.... | |
9ffbc9da EA |
424 | |
425 | uucp-uudom | |
924e1e40 EA |
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"). | |
9ffbc9da EA |
433 | |
434 | Examples: | |
435 | ||
924e1e40 EA |
436 | We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). |
437 | The following summarizes the sender rewriting for various | |
438 | mailers. | |
9ffbc9da EA |
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 | ====================================================================== | |
455 | RESOLVING 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 | |
924e1e40 | 461 | BIND 4.9.3. You need to compile with -l44bsd in order to get |
9ffbc9da | 462 | the additional routines. |
c0ac82a2 EA |
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) | |
924e1e40 EA |
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. | |
a70f1d02 EA |
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! | |
3055c3a0 EA |
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 | ||
924e1e40 EA |
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 | |
3055c3a0 EA |
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. | |
3055c3a0 | 503 | ---------------------------------------------------------------------- |
924e1e40 EA |
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 | |
b2f10127 | 541 | great for hobbyists and anyone else who wants to learn Unix |
924e1e40 | 542 | inside and out, or wants to always have something to do, or |
b2f10127 EA |
543 | wants a machine for light-duty mostly personal use and not |
544 | high-volume multi-user purposes. | |
924e1e40 EA |
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 | |
b2f10127 EA |
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 | |
31e11046 | 558 | of Unix such as Interactive, UnixWare, Solaris, or BSD/386 |
b2f10127 EA |
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. | |
924e1e40 EA |
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 | |
31e11046 | 577 | kind of support for it. Try BSDI's BSD/386 instead. |
924e1e40 EA |
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? | |
3055c3a0 EA |
583 | |
584 | Most likely, the problem isn't sendmail at all, but the low | |
924e1e40 EA |
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. | |
3055c3a0 EA |
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 | ||
924e1e40 EA |
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. | |
c94a0629 EA |
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. | |
c0ac82a2 EA |
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 | ||
924e1e40 | 636 | It's probably something weird in your TCP implementation that |
c0ac82a2 EA |
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 | |
924e1e40 EA |
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. | |
c0ac82a2 EA |
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 | |
924e1e40 EA |
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 | |
c0ac82a2 EA |
654 | /etc/named.boot file to get your value) are up to date. |
655 | Either of these can cause long delays. | |
656 | ---------------------------------------------------------------------- | |
c94a0629 EA |
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? | |
c0ac82a2 EA |
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. | |
3055c3a0 EA |
664 | ---------------------------------------------------------------------- |
665 | * Under V8, the "From " header gets mysteriously munged when I send | |
666 | to an alias. | |
667 | ||
924e1e40 EA |
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: | |
3055c3a0 EA |
677 | |
678 | list: :include:/path/name/list.list | |
679 | owner-list: list-request | |
680 | list-request: eric | |
681 | ||
924e1e40 EA |
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. | |
881deae6 EA |
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 | ||
924e1e40 EA |
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. | |
9ffbc9da EA |
708 | ---------------------------------------------------------------------- |
709 | * Messages seem to disappear from my queue unsent. When I look in | |
924e1e40 EA |
710 | the queue directory I see that they have been renamed from qf* to |
711 | Qf*, and sendmail doesn't see these. | |
9ffbc9da EA |
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, | |
924e1e40 EA |
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 | |
9ffbc9da EA |
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 | ||
924e1e40 EA |
725 | The usual solution is to not use the problematic flags. If |
726 | you must use them, you have to write a special queue | |
9ffbc9da EA |
727 | directory and have them processed by the same uid that |
728 | submitted the job in the first place. | |
3055c3a0 | 729 | ---------------------------------------------------------------------- |
31e11046 | 730 | @(#)FAQ 8.15 (Berkeley) %G% |
924e1e40 | 731 | Send updates to sendmail@CS.Berkeley.EDU. |