diff options
| author | glass <glass@NetBSD.org> | 1993-10-30 00:32:27 +0000 |
|---|---|---|
| committer | glass <glass@NetBSD.org> | 1993-10-30 00:32:27 +0000 |
| commit | 386f59b9d545ee266d61cd1fca5d8b50dc140bfe (patch) | |
| tree | f2eb4ef9cdc0322577411942f786c7dc7cb3e4ad /usr.sbin/sendmail/FAQ | |
| parent | c33a954998f371797bc14f9585dcc435d9d42b75 (diff) | |
updated from 8.3 to 8.6.3.
known problems: sendmail/cf/cf required 'obj' directory
Diffstat (limited to 'usr.sbin/sendmail/FAQ')
| -rw-r--r-- | usr.sbin/sendmail/FAQ | 213 |
1 files changed, 213 insertions, 0 deletions
diff --git a/usr.sbin/sendmail/FAQ b/usr.sbin/sendmail/FAQ new file mode 100644 index 00000000000..8419a30cf65 --- /dev/null +++ b/usr.sbin/sendmail/FAQ @@ -0,0 +1,213 @@ + Sendmail Version 8 + Frequently Asked Questions + VERY EARLY DRAFT + Last Update: October 18, 1993 + + +This FAQ is specific to Version 8 of sendmail. + +---------------------------------------------------------------------- + * What are the differences between Version 8 and other versions? + + See CHANGES-R5-R8 in the anonymous FTP directory. +---------------------------------------------------------------------- + * What happened to sendmail 6.x and 7.x? + + When I released a new version of sendmail, I changed it to + Release 6. Development continued in that tree until 4.4BSD + was released, when everything on the 4.4 tape was set to be + version 8.1. Version 7.x never existed. +---------------------------------------------------------------------- + * Where can I get Version 8? + + Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail. +---------------------------------------------------------------------- + * Version 8 requires a new version of "make". Where can I get this? + + Actually, Version 8 does not require a new version of "make". + It includes a collection of Makefiles for different architectures, + only one or two of which require the new "make". If you are + porting to a new architecture, start with Makefile.dist. + + If you really do want the new make, it is available on any of + the BSD Net2 distribution sites. These include: + + ftp.uu.net /systems/unix/bsd-sources + gatekeeper.dec.com /.0/BSD/net2 + ucquais.cba.uc.edu /pub/net2 + ftp.luth.se /pub/unix/4.3bsd/net2 +---------------------------------------------------------------------- + * What macro package do I use to format the V8 man pages? + + The BSD group switched over the the ``mandoc'' macros for + the 4.4 release. These include more hooks designed for + hypertext handling. However, new man pages won't format + under the old man macros. Fortunately, old man pages will + format under the new mandoc macros. + + Get the new macros with the BSD Net2 release. +---------------------------------------------------------------------- + * What books are available describing sendmail? + + There are currently no books available devoted to sendmail. + However, there are several books that have sendmail chapters. + + Nemeth, Snyder, and Seebass, _Unix System Administration + Handbook_. Prentice-Hall. + Carl-Mitchell and Quarterman, _Practical Internetworking with + TCP/IP and UNIX_. Addison-Wesley. + Hunt, _TCP/IP Network Administration_. O'Reilly & Associates. + +| At least two books are due out "soon": + + Costales, Allman, and Rickert, _Sendmail_. O'Reilly & +| Associates (to appear 11/93). + Avolio & Vixie, _Sendmail Theory and Practice_. Digital +| Press (release date unknown). +---------------------------------------------------------------------- + * How do I make all my addresses appear to be from a single host? + + Using the V8 configuration macros, use: + + MASQUERADE_AS(my.dom.ain) + + This will cause all addresses to be sent out as being from + the indicated domain. +---------------------------------------------------------------------- + * How do I rewrite my From: lines to read ``First_Last@My.Domain''? + + There are a couple of ways of doing this. This describes using + the "user database" code. This is still experimental, and was + intended for a different purpose -- however, it does work + with a bit of care. It does require that you have the Berkeley + "db" package installed (it won't work with DBM). + + First, create your input file. This should have lines like: + + loginname:mailname First_Last + First_Last:maildrop loginname + + Install it in (say) /etc/userdb. Create the database: + + makemap btree /etc/userdb.db < /etc/userdb + + You can then create a config file that uses this. You will + have to include the following in your .mc file: + + define(confUSERDB_SPEC, /etc/userdb.db) + FEATURE(notsticky) +---------------------------------------------------------------------- + * So what was the user database feature intended for? + + The intent was to have all information for a given user (where + the user is the unique login name, not an inherently non-unique + full name) in one place. This would include phone numbers, + addresses, and so forth. The "maildrop" feature is because + Berkeley does not use a centralized mail server (there are a + number of reasons for this that are mostly historic), and so + we need to know where each user gets his or her mail delivered -- + i.e., the mail drop. + + We are in the process of setting up our environment so that + mail sent to an unqualified "name" goes to that person's + preferred maildrop; mail sent to "name@host" goes to that + host. The purpose of "FEATURE(notsticky)" is to cause + "name@host" to be looked up in the user database for delivery + to the maildrop. +---------------------------------------------------------------------- + * Why are you so hostile to using full names for e-mail addresses? + + Because full names are not unique. For example, the computer + community has two Andy Tannenbaums and two Peter Deutsches. + At one time, Bell Labs had two Stephen R. Bournes with offices + a few doors apart. You can create alternative addresses + (e.g., Stephen_R_Bourne_2), but that's even worse -- which + one of them has to have their name desecrated in this way? + And you can bet that they will get most of the other person's + email. + + So called "full names" are just longer versions of unique + names. Rather that lulling people into a sense of security, + I'd rather that it be clear that these handles are arbitrary. + People should use good user agents that have alias mappings + so that they can attach arbitrary names for their personal + use to those with whom they correspond. + + Even worse is fuzzy matching in e-mail -- this can make good + addresses turn bad. For example, I'm currently (to the best + of my knowledge) the only ``Allman'' at Berkeley, so mail + sent to "Allman@Berkeley.EDU" should get to me. But if + another Allman ever appears, this address could suddenly + become ambiguous. I've been the only Allman at Berkeley for + over fifteen years -- to suddenly have this "good address" + bounce mail because it is ambiguous would be a heinous wrong. + + Finger services should be as fuzzy as possible. Mail services + should be unique. +---------------------------------------------------------------------- + * When I use sendmail V8 with a Sun config file I get lines like: + + /etc/sendmail.cf: line 273: replacement $3 out of bounds + + the line in question reads: + + R$*<@$%y>$* $1<@$2.LOCAL>$3 user@ether + + what does this mean? How do I fix it? + + V8 doesn't recognize the Sun "$%y" syntax, so as far as it + is concerned, there is only a $1 and a $2 (but no $3) in this + line. Read Rick McCarty's paper on "Converting Standard Sun + Config Files to Sendmail Version 8", in the contrib directory + (file "converting.sun.configs") on the sendmail distribution + for a full discussion of how to do this. +---------------------------------------------------------------------- + * Should I use a wildcard MX for my domain? + + If at all possible, no. + + Wildcard MX records have lots of semantic "gotcha"s. For + example, they will match a host "unknown.your.domain" -- if + you don't explicitly test for unknown hosts in your domain, + you will get "config error: mail loops back to myself" + errors. +---------------------------------------------------------------------- + * I'm connected to the network via a SLIP link. Sometimes my sendmail + process hangs (although it looks like part of the message has been + transfered). Everything else works. What's wrong? + + Most likely, the problem isn't sendmail at all, but the low + level network connection. It's important that the MTU (Maximum + Transfer Unit) for the SLIP connection be set properly at both + ends. If they disagree, large packets will be trashed and + the connection will hang. +---------------------------------------------------------------------- ++ * How can I get sendmail to deliver local mail to $HOME/.mail ++ instead of into /usr/spool/mail (or /usr/mail)? ++ ++ This is a local mailer issue, not a sendmail issue. Either ++ modify your local mailer (source code will be required) or ++ change the program called in the "local" mailer configuration ++ description to be a new program that does this local delivery. ++ I understand that "procmail" works well, although I haven't ++ used it myself. +---------------------------------------------------------------------- ++ * Under V8, the "From " header gets mysteriously munged when I send ++ to an alias. ++ ++ ``It's not a bug, it's a feature.'' This happens when you have ++ a "owner-list" alias and you send to "list". V8 propogates the ++ owner information into the envelope sender field (which appears ++ as the "From " header on UNIX mail or as the Return-Path: header) ++ so that downstream errors are properly returned to the mailing ++ list owner instead of to the sender. In order to make this ++ appear as sensible as possible to end users, I recommend making ++ the owner point to a "request" address -- for example: ++ ++ list: :include:/path/name/list.list ++ owner-list: list-request ++ list-request: eric ++ ++ This will make message sent to "list" come out as being ++ "From list-request" instead of "From eric". +---------------------------------------------------------------------- |
