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