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