Commit | Line | Data |
---|---|---|
3055c3a0 EA |
1 | Sendmail Version 8 |
2 | Frequently Asked Questions | |
a70f1d02 | 3 | Version 8.8 of %G% |
3055c3a0 EA |
4 | |
5 | ||
21446efc EA |
6 | This FAQ is specific to Version 8 of sendmail. Other questions, |
7 | particularly regarding compilation and configuration, are answered | |
c0ac82a2 | 8 | in src/READ_ME and cf/README (found in the V8 sendmail distribution). |
3055c3a0 | 9 | |
c0ac82a2 EA |
10 | ---------------------------------------------------------------------- |
11 | * What do you wish everyone would do before sending you mail? | |
12 | ||
13 | Read this FAQ completely. Read src/READ_ME and cf/README | |
14 | completely. Ask themselves if their question hasn't already | |
15 | been answered. | |
21446efc EA |
16 | ---------------------------------------------------------------------- |
17 | * Where can I get Version 8? | |
18 | ||
19 | Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. | |
3055c3a0 EA |
20 | ---------------------------------------------------------------------- |
21 | * What are the differences between Version 8 and other versions? | |
22 | ||
21446efc | 23 | See doc/changes/changes.me in the sendmail distribution. |
3055c3a0 EA |
24 | ---------------------------------------------------------------------- |
25 | * What happened to sendmail 6.x and 7.x? | |
26 | ||
c0ac82a2 EA |
27 | When I released a new (Alpha/Beta) version of sendmail, I changed |
28 | it to Release 6. Development continued in that tree until 4.4BSD | |
3055c3a0 EA |
29 | was released, when everything on the 4.4 tape was set to be |
30 | version 8.1. Version 7.x never existed. | |
3055c3a0 EA |
31 | ---------------------------------------------------------------------- |
32 | * Version 8 requires a new version of "make". Where can I get this? | |
33 | ||
34 | Actually, Version 8 does not require a new version of "make". | |
35 | It includes a collection of Makefiles for different architectures, | |
c0ac82a2 EA |
36 | only one or two of which require the new "make". For a supported |
37 | architecture, use ``sh makesendmail''. If you are porting to a | |
38 | new architecture, start with Makefile.dist. | |
3055c3a0 EA |
39 | |
40 | If you really do want the new make, it is available on any of | |
21446efc | 41 | the BSD Net2 or 4.4-Lite distribution sites. These include: |
3055c3a0 EA |
42 | |
43 | ftp.uu.net /systems/unix/bsd-sources | |
44 | gatekeeper.dec.com /.0/BSD/net2 | |
45 | ucquais.cba.uc.edu /pub/net2 | |
46 | ftp.luth.se /pub/unix/4.3bsd/net2 | |
47 | ||
48 | Diffs and instructions for building this version of make under | |
49 | SunOS 4.1.x are available on ftp.css.itd.umich.edu in | |
dc1be093 EA |
50 | /pub/systems/sun/Net2-make.sun4.diff.Z. A patchkit for Ultrix |
51 | is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z. Patches | |
52 | for AIX 3.2.4 are available on ftp.uni-stuttgart.de in | |
53 | /sw/src/patches/bsd-make-rus-patches. | |
7de17422 EA |
54 | |
55 | There is also a Linux version available on the main Linux | |
56 | distribution sites as pmake; this version is included as | |
57 | standard with the current Slackware distributions. | |
3055c3a0 EA |
58 | ---------------------------------------------------------------------- |
59 | * What macro package do I use to format the V8 man pages? | |
60 | ||
61 | The BSD group switched over the the ``mandoc'' macros for | |
62 | the 4.4 release. These include more hooks designed for | |
63 | hypertext handling. However, new man pages won't format | |
64 | under the old man macros. Fortunately, old man pages will | |
65 | format under the new mandoc macros. | |
66 | ||
c0ac82a2 EA |
67 | Get the new macros with the BSD Net2 or 4.4-Lite release |
68 | (see above). | |
3055c3a0 EA |
69 | |
70 | This macro set is also available with newer versions of groff. | |
71 | ---------------------------------------------------------------------- | |
72 | * What books are available describing sendmail? | |
73 | ||
21446efc EA |
74 | There is one book available devoted to sendmail: |
75 | ||
76 | Costales, Allman, and Rickert, _Sendmail_. O'Reilly & | |
77 | Associates. | |
78 | ||
79 | Several books have sendmail chapters, for example: | |
3055c3a0 | 80 | |
21446efc | 81 | Nemeth, Snyder, and Seebass, _Unix System Administration |
3055c3a0 | 82 | Handbook_. Prentice-Hall. |
21446efc | 83 | Carl-Mitchell and Quarterman, _Practical Internetworking with |
3055c3a0 | 84 | TCP/IP and UNIX_. Addison-Wesley. |
21446efc | 85 | Hunt, _TCP/IP Network Administration_. O'Reilly & Associates. |
3055c3a0 | 86 | |
21446efc | 87 | Another book about sendmail is due out "soon": |
3055c3a0 | 88 | |
21446efc | 89 | Avolio & Vixie, _Sendmail Theory and Practice_. Digital |
3055c3a0 EA |
90 | Press (release date unknown). |
91 | ---------------------------------------------------------------------- | |
92 | * How do I make all my addresses appear to be from a single host? | |
93 | ||
94 | Using the V8 configuration macros, use: | |
95 | ||
96 | MASQUERADE_AS(my.dom.ain) | |
97 | ||
98 | This will cause all addresses to be sent out as being from | |
99 | the indicated domain. | |
100 | ---------------------------------------------------------------------- | |
101 | * How do I rewrite my From: lines to read ``First_Last@My.Domain''? | |
102 | ||
103 | There are a couple of ways of doing this. This describes using | |
104 | the "user database" code. This is still experimental, and was | |
105 | intended for a different purpose -- however, it does work | |
106 | with a bit of care. It does require that you have the Berkeley | |
107 | "db" package installed (it won't work with DBM). | |
108 | ||
109 | First, create your input file. This should have lines like: | |
110 | ||
111 | loginname:mailname First_Last | |
112 | First_Last:maildrop loginname | |
113 | ||
114 | Install it in (say) /etc/userdb. Create the database: | |
115 | ||
116 | makemap btree /etc/userdb.db < /etc/userdb | |
117 | ||
118 | You can then create a config file that uses this. You will | |
119 | have to include the following in your .mc file: | |
120 | ||
121 | define(confUSERDB_SPEC, /etc/userdb.db) | |
122 | FEATURE(notsticky) | |
123 | ---------------------------------------------------------------------- | |
124 | * So what was the user database feature intended for? | |
125 | ||
126 | The intent was to have all information for a given user (where | |
127 | the user is the unique login name, not an inherently non-unique | |
128 | full name) in one place. This would include phone numbers, | |
129 | addresses, and so forth. The "maildrop" feature is because | |
130 | Berkeley does not use a centralized mail server (there are a | |
131 | number of reasons for this that are mostly historic), and so | |
132 | we need to know where each user gets his or her mail delivered -- | |
133 | i.e., the mail drop. | |
134 | ||
135 | We are in the process of setting up our environment so that | |
136 | mail sent to an unqualified "name" goes to that person's | |
137 | preferred maildrop; mail sent to "name@host" goes to that | |
138 | host. The purpose of "FEATURE(notsticky)" is to cause | |
139 | "name@host" to be looked up in the user database for delivery | |
140 | to the maildrop. | |
141 | ---------------------------------------------------------------------- | |
142 | * Why are you so hostile to using full names for e-mail addresses? | |
143 | ||
144 | Because full names are not unique. For example, the computer | |
145 | community has two Andy Tannenbaums and two Peter Deutsches. | |
146 | At one time, Bell Labs had two Stephen R. Bournes with offices | |
147 | a few doors apart. You can create alternative addresses | |
148 | (e.g., Stephen_R_Bourne_2), but that's even worse -- which | |
149 | one of them has to have their name desecrated in this way? | |
c0ac82a2 EA |
150 | And you can bet that one of them will get most of the other |
151 | person's e-mail. | |
3055c3a0 | 152 | |
c0ac82a2 EA |
153 | So called "full names" are just an attempt to create longer |
154 | versions of unique names. Rather that lulling people into a | |
155 | sense of security, I'd rather that it be clear that these | |
156 | handles are arbitrary. People should use good user agents | |
157 | that have alias mappings so that they can attach arbitrary | |
158 | names for their personal use to those with whom they correspond | |
159 | (such as the MH alias file). | |
3055c3a0 EA |
160 | |
161 | Even worse is fuzzy matching in e-mail -- this can make good | |
162 | addresses turn bad. For example, I'm currently (to the best | |
163 | of my knowledge) the only ``Allman'' at Berkeley, so mail | |
164 | sent to "Allman@Berkeley.EDU" should get to me. But if | |
165 | another Allman ever appears, this address could suddenly | |
166 | become ambiguous. I've been the only Allman at Berkeley for | |
167 | over fifteen years -- to suddenly have this "good address" | |
168 | bounce mail because it is ambiguous would be a heinous wrong. | |
169 | ||
c0ac82a2 EA |
170 | Finger services should be as fuzzy as possible (within |
171 | reason, of course). Mail services should be unique. | |
172 | ---------------------------------------------------------------------- | |
173 | * I'm getting "Local configuration error" messages, such as: | |
174 | ||
175 | 553 relay.domain.net config error: mail loops back to myself | |
176 | 554 <user@domain.net>... Local configuration error | |
177 | ||
178 | How can I solve this problem? | |
179 | ||
180 | You have asked mail to the domain (e.g., domain.net) to be | |
181 | forwarded to a specific host (in this case, relay.domain.net) | |
182 | by using an MX record, but the relay machine doesn't recognize | |
183 | itself as domain.net. Add domain.net to /etc/sendmail.cw | |
184 | (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" | |
185 | to your configuration file. | |
a70f1d02 EA |
186 | |
187 | IMPORTANT: Be sure you kill and restart the sendmail daemon | |
188 | after you change the configuration file (for ANY change in | |
189 | the configuration, not just this one): | |
190 | ||
191 | kill `head -1 /etc/sendmail.pid` | |
192 | sh -c "`tail -1 /etc/sendmail.pid`" | |
193 | ||
194 | NOTA BENE: kill -1 does not work! | |
195 | ---------------------------------------------------------------------- | |
196 | * OK, I did that, and the problem still occurs. | |
197 | ||
198 | You probably forgot to to resta | |
3055c3a0 EA |
199 | ---------------------------------------------------------------------- |
200 | * When I use sendmail V8 with a Sun config file I get lines like: | |
201 | ||
202 | /etc/sendmail.cf: line 273: replacement $3 out of bounds | |
203 | ||
204 | the line in question reads: | |
205 | ||
206 | R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether | |
207 | ||
208 | what does this mean? How do I fix it? | |
209 | ||
210 | V8 doesn't recognize the Sun "$%y" syntax, so as far as it | |
211 | is concerned, there is only a $1 and a $2 (but no $3) in this | |
212 | line. Read Rick McCarty's paper on "Converting Standard Sun | |
213 | Config Files to Sendmail Version 8", in the contrib directory | |
214 | (file "converting.sun.configs") on the sendmail distribution | |
215 | for a full discussion of how to do this. | |
216 | ---------------------------------------------------------------------- | |
217 | * Should I use a wildcard MX for my domain? | |
218 | ||
219 | If at all possible, no. | |
220 | ||
221 | Wildcard MX records have lots of semantic "gotcha"s. For | |
222 | example, they will match a host "unknown.your.domain" -- if | |
223 | you don't explicitly test for unknown hosts in your domain, | |
224 | you will get "config error: mail loops back to myself" | |
225 | errors. | |
226 | ---------------------------------------------------------------------- | |
227 | * I'm connected to the network via a SLIP link. Sometimes my sendmail | |
228 | process hangs (although it looks like part of the message has been | |
229 | transfered). Everything else works. What's wrong? | |
230 | ||
231 | Most likely, the problem isn't sendmail at all, but the low | |
232 | level network connection. It's important that the MTU (Maximum | |
233 | Transfer Unit) for the SLIP connection be set properly at both | |
234 | ends. If they disagree, large packets will be trashed and | |
235 | the connection will hang. | |
236 | ---------------------------------------------------------------------- | |
237 | * I just upgraded to 8.x and suddenly I'm getting messages in my | |
238 | syslog of the form "collect: I/O error on connection". What is | |
239 | going wrong? | |
240 | ||
241 | Nothing. This is just a diagnosis of a condition that had | |
242 | not been diagnosed before. If you are getting a lot of these | |
243 | from a single host, there is probably some incompatibility | |
244 | between 8.x and that host. If you get a lot of them in general, | |
245 | you may have network problems that are causing connections to | |
246 | get reset. | |
c0ac82a2 EA |
247 | ---------------------------------------------------------------------- |
248 | * I just upgraded to 8.x and suddenly connections to the SMTP port | |
249 | take a long time. What is going wrong? | |
250 | ||
251 | It's probably something wierd in your TCP implementation that | |
252 | makes the IDENT code act oddly. On most systems V8 tries to | |
253 | do a ``callback'' to the connecting host to get a validated | |
254 | user name (see RFC 1413 for details). If the connecting | |
255 | host does not support such a service it will normally fail | |
256 | quickly with "Connection refused", but certain kinds of | |
257 | packet filters and certain TCP implementations just time out. | |
258 | ||
259 | To test this, set the IDENT timeout to zero using | |
260 | ``OrIdent=0'' in the configuration file. This will | |
261 | completely disable all use of the IDENT protocol. | |
262 | ||
263 | Another possible problem is that you have your name server | |
264 | and/or resolver configured improperly. Make sure that | |
265 | all "nameserver" entries in /etc/resolv.conf point to functional | |
266 | servers. If you are running your own server make certain that | |
267 | all the servers listed in your root cache (usually called | |
268 | something like "/var/namedb/root.cache"; see your | |
269 | /etc/named.boot file to get your value) are up to date. | |
270 | Either of these can cause long delays. | |
271 | ---------------------------------------------------------------------- | |
272 | * I just upgraded to 8.x and suddenly I get errors such as ``mail: | |
273 | options must follow recipients.'' What is going wrong? | |
274 | ||
275 | You need OSTYPE(systype) in your .mc file -- otherwise the | |
276 | configurations use a default that probably disagrees with | |
277 | your local mail system. See cf/README for details. | |
3055c3a0 EA |
278 | ---------------------------------------------------------------------- |
279 | * How can I get sendmail to deliver local mail to $HOME/.mail | |
280 | instead of into /usr/spool/mail (or /usr/mail)? | |
281 | ||
282 | This is a local mailer issue, not a sendmail issue. Either | |
283 | modify your local mailer (source code will be required) or | |
284 | change the program called in the "local" mailer configuration | |
285 | description to be a new program that does this local delivery. | |
286 | I understand that "procmail" works well, although I haven't | |
287 | used it myself. | |
34ccf6c6 EA |
288 | |
289 | You might be interested in reading the paper ``HLFSD: Delivering | |
290 | Email to your $HOME'' available in the Proceedings of the | |
291 | USENIX System Administration (LISA VII) Conference (November | |
292 | 1993). This is also available via public FTP from | |
293 | ftp.cs.columbia.edu:/pub/hlfsd/{README.hlfsd,hlfsd.ps}. | |
3055c3a0 EA |
294 | ---------------------------------------------------------------------- |
295 | * Under V8, the "From " header gets mysteriously munged when I send | |
296 | to an alias. | |
297 | ||
298 | ``It's not a bug, it's a feature.'' This happens when you have | |
299 | a "owner-list" alias and you send to "list". V8 propogates the | |
300 | owner information into the envelope sender field (which appears | |
301 | as the "From " header on UNIX mail or as the Return-Path: header) | |
302 | so that downstream errors are properly returned to the mailing | |
303 | list owner instead of to the sender. In order to make this | |
304 | appear as sensible as possible to end users, I recommend making | |
305 | the owner point to a "request" address -- for example: | |
306 | ||
307 | list: :include:/path/name/list.list | |
308 | owner-list: list-request | |
309 | list-request: eric | |
310 | ||
311 | This will make message sent to "list" come out as being | |
312 | "From list-request" instead of "From eric". | |
313 | ---------------------------------------------------------------------- | |
314 | * There are four UUCP mailers listed in the configuration files. | |
315 | Which one should I use? | |
316 | ||
317 | The choice is partly a matter of local preferences and what is | |
318 | running at the other end of your UUCP connection. Unlike good | |
319 | protocols that define what will go over the wire, UUCP uses | |
320 | the policy that you should do what is right for the other end; | |
321 | if they change, you have to change. This makes it hard to | |
322 | do the right thing, and discourages people from updating their | |
323 | software. In general, if you can avoid UUCP, please do. | |
324 | ||
325 | If you can't avoid it, you'll have to find the version that is | |
326 | closest to what the other end accepts. Following is a summary | |
327 | of the UUCP mailers available. | |
328 | ||
329 | uucp-old (obsolete name: "uucp") | |
330 | This is the oldest, the worst (but the closest to UUCP) way of | |
331 | sending messages accros UUCP connections. It does bangify | |
332 | everything and prepends $U (your UUCP name) to the sender's | |
333 | address (which can already be a bang path itself). It can | |
334 | only send to one address at a time, so it spends a lot of | |
335 | time copying duplicates of messages. Avoid this if at all | |
336 | possible. | |
337 | ||
338 | uucp-new (obsolete name: "suucp") | |
339 | The same as above, except that it assumes that in one rmail | |
340 | command you can specify several recipients. It still has a | |
341 | lot of other problems. | |
342 | ||
343 | uucp-dom | |
344 | This UUCP mailer keeps everything as domain addresses. | |
345 | Basically, it uses the SMTP mailer rewriting rules. | |
346 | ||
347 | Unfortunately, a lot of UUCP mailer transport agents require | |
348 | bangified addresses in the envelope, although you can use | |
349 | domain-based addresses in the message header. (The envelope | |
350 | shows up as the From_ line on UNIX mail.) So.... | |
351 | ||
352 | uucp-uudom | |
353 | This is a cross between uucp-new (for the envelope addresses) | |
354 | and uucp-dom (for the header addresses). It bangifies the | |
355 | envelope sender (From_ line in messages) without adding the | |
356 | local hostname, unless there is no host name on the address | |
357 | at all (e.g., "wolf") or the host component is a UUCP host name | |
358 | instead of a domain name ("somehost!wolf" instead of | |
359 | "some.dom.ain!wolf"). | |
360 | ||
361 | Examples: | |
362 | ||
363 | We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). The | |
364 | following summarizes the sender rewriting for various mailers. | |
365 | ||
366 | Mailer sender rewriting in the envelope | |
367 | ------ ------ ------------------------- | |
368 | uucp-{old,new} wolf grasp!wolf | |
369 | uucp-dom wolf wolf@grasp.insa-lyon.fr | |
370 | uucp-uudom wolf grasp.insa-lyon.fr!wolf | |
371 | ||
372 | uucp-{old,new} wolf@fr.net grasp!fr.net!wolf | |
373 | uucp-dom wolf@fr.net wolf@fr.net | |
374 | uucp-uudom wolf@fr.net fr.net!wolf | |
375 | ||
376 | uucp-{old,new} somehost!wolf grasp!somehost!wolf | |
377 | uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr | |
378 | uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf | |
379 | ---------------------------------------------------------------------- | |
380 | * I'm trying to to get my mail to go into queue only mode, and it | |
381 | delivers the mail interactively anyway. (Or, I'm trying to use | |
382 | the "don't deliver to expensive mailer" flag, and it doesn't | |
383 | delivers the mail interactively anyway.) I can see it does it: | |
384 | here's the output of "sendmail -v foo@somehost" (or Mail -v or | |
385 | equivalent). | |
386 | ||
387 | The -v flag to sendmail (which is implied by the -v flag to | |
388 | Mail and other programs in that family) tells sendmail to | |
389 | watch the transaction. Since you have explicitly asked to | |
390 | see what's going on, it assumes that you do not want to to | |
391 | auto-queue, and turns that feature off. Remove the -v flag | |
392 | and use a "tail -f" of the log instead to see what's going on. | |
393 | ||
394 | If you are trying to use the "don't deliver to expensive mailer" | |
395 | flag (mailer flag "e"), be sure you also turn on global option | |
396 | "c" -- otherwise it ignores the mailer flag. | |
881deae6 EA |
397 | ---------------------------------------------------------------------- |
398 | * I want to run Sendmail version 8 on my DEC system, but you don't | |
399 | have MAIL11V3 support in sendmail. How do I handle this? | |
400 | ||
401 | Get Paul Vixie's reimplementation of the mail11 protocol | |
402 | from gatekeeper.dec.com in /pub/DEC/gwtools. | |
3055c3a0 | 403 | ---------------------------------------------------------------------- |