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