summaryrefslogtreecommitdiff
path: root/usr.sbin/sendmail/FAQ
diff options
context:
space:
mode:
authorglass <glass@NetBSD.org>1993-10-30 00:32:27 +0000
committerglass <glass@NetBSD.org>1993-10-30 00:32:27 +0000
commit386f59b9d545ee266d61cd1fca5d8b50dc140bfe (patch)
treef2eb4ef9cdc0322577411942f786c7dc7cb3e4ad /usr.sbin/sendmail/FAQ
parentc33a954998f371797bc14f9585dcc435d9d42b75 (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/FAQ213
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".
+----------------------------------------------------------------------