+----------------------------------------------------------------------
+ * 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.
+
+ See RFCs 1535-1537 for more detail and other related (or
+ common) problems.
+----------------------------------------------------------------------
+ * How can I get sendmail to process messages sent to an account and
+ send the results back to the originator?
+
+ This is a local mailer issue, not a sendmail issue.
+ Depending on what you're doing, look at procmail (mentioned
+ again below), ftpmail, or Majordomo.
+
+ Check your local archie server to see what machine(s) nearest
+ you have the most recent versions of these programs.
+----------------------------------------------------------------------
+ * How can I get sendmail to deliver local mail to $HOME/.mail
+ instead of into /usr/spool/mail (or /usr/mail)?
+
+ Again, 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. One program that is capable of doing this is
+ "procmail", although there are probably many others as well.
+
+ You might be interested in reading the paper ``HLFSD:
+ Delivering Email to your $HOME'' available in the Proceedings
+ of the USENIX System Administration (LISA VII) Conference
+ (November 1993). This is also available via public FTP from
+ ftp.cs.columbia.edu in /pub/hlfsd/{README.hlfsd,hlfsd.ps}.
+----------------------------------------------------------------------
+ * I'm trying to to get my mail to go into queue only mode, and it
+ delivers the mail interactively anyway. (Or, I'm trying to use
+ the "don't deliver to expensive mailer" flag, and it delivers the
+ mail interactively anyway.) I can see it does it: here's the
+ output of "sendmail -v foo@somehost" (or Mail -v or equivalent).
+
+ The -v flag to sendmail (which is implied by the -v flag to
+ Mail and other programs in that family) tells sendmail to
+ watch the transaction. Since you have explicitly asked to
+ see what's going on, it assumes that you do not want to to
+ auto-queue, and turns that feature off. Remove the -v flag
+ and use a "tail -f" of the log instead to see what's going
+ on.
+
+ If you are trying to use the "don't deliver to expensive
+ mailer" flag (mailer flag "e"), be sure you also turn on
+ global option "c" -- otherwise it ignores the mailer flag.
+----------------------------------------------------------------------
+ * There are four UUCP mailers listed in the configuration files.
+ Which one should I use?
+
+ The choice is partly a matter of local preferences and what
+ is running at the other end of your UUCP connection. Unlike
+ good protocols that define what will go over the wire, UUCP
+ uses the policy that you should do what is right for the
+ other end; if they change, you have to change. This makes it
+ hard to do the right thing, and discourages people from
+ updating their software. In general, if you can avoid UUCP,
+ please do.
+
+ If you can't avoid it, you'll have to find the version that
+ is closest to what the other end accepts. Following is a
+ summary of the UUCP mailers available.
+
+ uucp-old (obsolete name: "uucp")
+ This is the oldest, the worst (but the closest to UUCP) way
+ of sending messages across UUCP connections. It does
+ bangify everything and prepends $U (your UUCP name) to the
+ sender's address (which can already be a bang path
+ itself). It can only send to one address at a time, so it
+ spends a lot of time copying duplicates of messages. Avoid
+ this if at all possible.
+
+ uucp-new (obsolete name: "suucp")
+ The same as above, except that it assumes that in one rmail
+ command you can specify several recipients. It still has a
+ lot of other problems.
+
+ uucp-dom
+ This UUCP mailer keeps everything as domain addresses.
+ Basically, it uses the SMTP mailer rewriting rules.
+
+ Unfortunately, a lot of UUCP mailer transport agents
+ require bangified addresses in the envelope, although you
+ can use domain-based addresses in the message header. (The
+ envelope shows up as the From_ line on UNIX mail.) So....
+
+ uucp-uudom
+ This is a cross between uucp-new (for the envelope
+ addresses) and uucp-dom (for the header addresses). It
+ bangifies the envelope sender (From_ line in messages)
+ without adding the local hostname, unless there is no host
+ name on the address at all (e.g., "wolf") or the host
+ component is a UUCP host name instead of a domain name
+ ("somehost!wolf" instead of "some.dom.ain!wolf").
+
+ Examples:
+
+ We are on host grasp.insa-lyon.fr (UUCP host name "grasp").
+ The following summarizes the sender rewriting for various
+ mailers.
+
+ Mailer sender rewriting in the envelope
+ ------ ------ -------------------------
+ uucp-{old,new} wolf grasp!wolf
+ uucp-dom wolf wolf@grasp.insa-lyon.fr
+ uucp-uudom wolf grasp.insa-lyon.fr!wolf
+
+ uucp-{old,new} wolf@fr.net grasp!fr.net!wolf
+ uucp-dom wolf@fr.net wolf@fr.net
+ uucp-uudom wolf@fr.net fr.net!wolf
+
+ uucp-{old,new} somehost!wolf grasp!somehost!wolf
+ uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr
+ uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf
+
+======================================================================
+RESOLVING PROBLEMS
+======================================================================
+
+ * When I compile, I get "undefined symbol inet_aton" messages.
+
+ You've probably replaced your resolver with the version from
+ BIND 4.9.3. You need to compile with -l44bsd in order to get
+ the additional routines.