Newsgroups: comp.mail.sendmail,comp.mail.misc,comp.mail.smail,comp.answers,news.answers
Subject: comp.mail.sendmail Frequently Asked Questions (FAQ)
From: brad@birch.ims.disa.mil (Brad Knowles)
Followup-to: comp.mail.sendmail
Summary: This posting contains a list of Frequently Asked Questions
(and their answers) about the program "sendmail", distributed
with many versions of Unix (and available for some other
operating systems). This FAQ is shared between
comp.mail.sendmail and the Sendmail V8 distribution. It should
be read by anyone who wishes to post to comp.mail.sendmail, or
anyone having questions about the newsgroup itself.
Archive-name: mail/sendmail-faq
Posting-Frequency: monthly (first Monday)
[The most recent copy of this document can be obtained via anonymous
FTP from rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
If you do not have access to anonymous FTP, you can retrieve it by
sending email to mail-server@rtfm.mit.edu with the command "send
usenet/news.answers/mail/sendmail-faq" in the message.]
Sendmail Version 8
Frequently Asked Questions
Last updated 2/24/95
This FAQ is specific to Version 8.6.10 of sendmail. Other questions,
particularly regarding compilation and configuration, are answered in
src/READ_ME and cf/README (found in the V8 sendmail distribution).
This is also the official FAQ for the Usenet newsgroup
comp.mail.sendmail.
======================================================================
BEFORE YOU GO ANY FURTHER
======================================================================
* What do you wish everyone would do before sending you mail or
posting to comp.mail.sendmail?
Read this FAQ completely. Read src/READ_ME and cf/README
completely. Read the books written to help with common
problems such as compilation and installation, configuration,
security issues, etc.... Ask themselves if their question
hasn't already been answered.
----------------------------------------------------------------------
* How can I be sure if this is the right place to look for answers
to my questions?
1. Do you know, for a fact, that the question is related to
sendmail V8?
2. Do you know, for a fact, that the question is related to an
older version of sendmail?
3. Is the question about a sendmail-like program (e.g., Smail,
Zmailer, MMDF, etc...)?
4. Is the question about an SMTP Gateway product for a LAN
mail package (e.g., cc:Mail, MS-Mail, WordPerfect
Office/GroupWise, etc...)?
If you answered "yes" to the question #1, then this is the
right place.
If you answered "yes" to questions #2 or #3, then you should
seriously consider upgrading to the most recent version of
sendmail V8.
For question #2, If you're going to continue using an older
version of sendmail, you may not find much help and will
probably get some responses that amount to "Get V8".
Otherwise, this is probably the best place to look for
answers.
If you answered "yes" to question #3 and are not going to
upgrade to sendmail V8, then this is probably not the right
place to look.
If you answered "yes" to question #4, then this is almost
certainly not the right place to look.
For questions #3 and #4, try looking around elsewhere in the
"comp.mail.*" hierarchy for a more appropriate newsgroup.
For example, you might want to try posting to comp.mail.misc
or comp.mail.smail.
If you couldn't answer "yes" to any of the above questions,
then you're DEFINITELY in the wrong place. For the sake of
your sanity and ego, not to mention avoiding the waste of
your time and ours, try asking your System or E-Mail
Administrator(s) before you post any questions publicly.
----------------------------------------------------------------------
* Where can I find the latest version of this FAQ?
It is included in the most recent Version 8 distribution of
sendmail (described below), as well as via anonymous FTP from
rtfm.mit.edu in /pub/usenet/news.answers/mail/sendmail-faq.
If you do not have access to anonymous FTP, you can retrieve
it by sending email to mail-server@rtfm.mit.edu with the
command "send usenet/news.answers/mail/sendmail-faq" in the
message.
----------------------------------------------------------------------
* I don't have access to Usenet news. Can I still get access to
comp.mail.sendmail?
Yes. Send email to mxt@dl.ac.uk with the command "sub
comp-news.comp.mail.sendmail "
in the message.
E-mail you want posted on comp.mail.sendmail should be sent
to comp-mail-sendmail@dl.ac.uk
----------------------------------------------------------------------
* I have sendmail-related DNS questions. Where should I ask them?
Depending on how deeply they get into the DNS, they can be
asked here. However, you'll probably be told that you should
send them to the Info-BIND mailing list (if the question is
specific to that program) or to the Usenet newsgroup
comp.protocols.tcp-ip.domains (DNS in general).
----------------------------------------------------------------------
* How do I subscribe to either of these?
For comp.protocols.tcp-ip.domains, you have to be on Usenet.
They don't have a news-to-mail gateway yet.
For the Info-BIND mailing list, send email to
bind-request@uunet.uu.net with the command "subscribe" in the
message. Submissions should be sent to bind@uunet.uu.net
======================================================================
GENERAL QUESTIONS
======================================================================
* Where can I get Version 8?
Via anonymous FTP from FTP.CS.Berkeley.EDU in /ucb/sendmail.
----------------------------------------------------------------------
* What are the differences between Version 8 and other versions?
See doc/changes/changes.me in the sendmail distribution.
----------------------------------------------------------------------
* What happened to sendmail 6.x and 7.x?
When a new (Alpha/Beta) version of sendmail was released, it
was changed 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.
----------------------------------------------------------------------
* What books are available describing sendmail?
There is one book available devoted to sendmail:
Costales, Allman, and Rickert, _Sendmail_. O'Reilly &
Associates.
Several books have sendmail chapters, for example:
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.
Another book about sendmail is due out "soon":
Avolio & Vixie, _Sendmail Theory and Practice_. Digital
Press (release date unknown).
For details on sendmail-related DNS issues, consult:
Liu and Albitz, _DNS and BIND_. O'Reilly & Associates.
For details on UUCP, see:
O'Reilly and Todino, _Managing UUCP and Usenet_.
O'Reilly & Associates.
======================================================================
COMPILING AND INSTALLING SENDMAIL 8
======================================================================
* 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". For a supported
architecture, use ``sh makesendmail''. 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 or 4.4-Lite 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
Diffs and instructions for building this version of make
under SunOS 4.1.x are available on ftp.css.itd.umich.edu in
/pub/systems/sun/Net2-make.sun4.diff.Z. A patchkit for
Ultrix is on ftp.vix.com in /pub/patches/pmake-for-ultrix.Z.
Patches for AIX 3.2.4 are available on ftp.uni-stuttgart.de
in /sw/src/patches/bsd-make-rus-patches.
There is also a Linux version available on the main Linux
distribution sites as pmake; this version is included as
standard with the current Slackware distributions.
----------------------------------------------------------------------
* 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 or 4.4-Lite release (see
above for locations; for example, on FTP.UU.NET the files
/system/unix/bsd-sources/share/tmac/me/strip/sed and
/system/unix/bsd-sources/share/tmac/* are what you need).
This macro set is also included with newer versions of groff.
----------------------------------------------------------------------
* What modes should be used when installing sendmail?
The sendmail binary should be owned by root, mode 4755.
The queue directory should be owned by root, with a mode
between 700 and 755. Under no circumstances should
it be group or other writable!
The sendmail config file should be owned by root, mode 644.
The aliases file should generally be owned by one trusted
user and writable only by that user, although it is
not unreasonable to have it group writable by a
"sysadmin" group. It should not be world writable.
The aliases database files (aliases.db or aliases.{pag,dir}
depending on what database format you compile with)
should be owned by root, mode 644.
======================================================================
CONFIGURATION QUESTIONS
======================================================================
* 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 one of them will get most of
the other person's e-mail.
So called "full names" are just an attempt to create 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 (such as the MH alias file).
Even worse is fuzzy matching in e-mail -- this can make good
addresses turn bad. For example, Eric Allman is currently
(to the best of our knowledge) the only ``Allman'' at
Berkeley, so mail sent to "Allman@Berkeley.EDU" should get to
him. But if another Allman ever appears, this address could
suddenly become ambiguous. He's 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 (within
reason, of course). Mail services should be unique.
----------------------------------------------------------------------
* 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.
----------------------------------------------------------------------
* I'm getting "Local configuration error" messages, such as:
553 relay.domain.net config error: mail loops back to myself
554 ... Local configuration error
How can I solve this problem?
You have asked mail to the domain (e.g., domain.net) to be
forwarded to a specific host (in this case, relay.domain.net)
by using an MX record, but the relay machine doesn't
recognize itself as domain.net. Add domain.net to
/etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or
add "Cw domain.net" to your configuration file.
IMPORTANT: Be sure you kill and restart the sendmail daemon
after you change the configuration file (for ANY change in
the configuration, not just this one):
kill `head -1 /etc/sendmail.pid`
sh -c "`tail -1 /etc/sendmail.pid`"
NOTA BENE: kill -1 does not work!
----------------------------------------------------------------------
* 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.
----------------------------------------------------------------------
* When I use sendmail V8 on a Sun, I sometimes get lines like:
/etc/sendmail.cf: line 445: bad ruleset 96 (50 max)
what does this mean? How do I fix it?
You're somehow trying to start up the old Sun sendmail (or
sendmail.mx) with a sendmail V8 config file, which Sun's
sendmail doesn't like. Check your /etc/rc.local, any
procedures that have been created to stop and re-start the
sendmail processes, etc.... Make sure that you've switched
everything over to using the new sendmail. To keep this
problem from ever happening again, try the following:
mv /usr/lib/sendmail /usr/lib/sendmail.old
ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail
mv /usr/lib/sendmail.mx /usr/lib/sendmail.mx.old
ln -s /usr/local/lib/sendmail.v8 /usr/lib/sendmail.mx
chmod 0000 /usr/lib/sendmail.old
chmod 0000 /usr/lib/sendmail.mx.old
Assuming you have installed sendmail V8 in /usr/local/lib.
----------------------------------------------------------------------
* When I use sendmail V8 on an IBM RS/6000 running AIX, the system
resource controller always reports sendmail as "inoperative" even
though it is running. What's wrong?
IBM's system resource controller is one of their "value
added" features to AIX -- it's not a Unix standard. You'll
need to either redefine the subsystem to use signals (see
chssys(1)) or dump the entire subsystem and invoke sendmail
in /etc/rc.tcpip or some other boot script.
----------------------------------------------------------------------
* When I use sendmail V8 on an Intel x86 machine running Linux, I
have some problems. Specifically, I have....
The current versions of Linux are generally considered to be
great for hobbyists and anyone else who wants to learn Unix
inside and out, or wants to always have something to do, or
wants a machine for light-duty mostly personal use and not
high-volume multi-user purposes.
However, for those who want a system that will just sit in
the background and work without a fuss handling thousands of
mail messages a day for lots of different users, it's not
(yet) stable enough to fit the bill.
Unfortunately, there are no known shareware/freeware
implementations of any operating system that provides the
level of stability necessary to handle that kind of load
(i.e., there are no free lunches).
If you're wedded to the Intel x86 platform and want to run
sendmail, we suggest you look at commercial implementations
of Unix such as Interactive, UnixWare, Solaris, or BSD/386
(just a sample of the dozens of different versions of Unix
for Intel x86).
Of all known vendor supported versions of Unix for Intel x86,
BSDI's BSD/386 is least expensive and the only one known to
currently ship with sendmail V8 pre-installed. Since sendmail
V8 is continuing to be developed at UC Berkeley, and BSD/386
is a full BSD 4.4 implementation, this is obviously be the most
"native" sendmail V8 environment.
----------------------------------------------------------------------
* When I use sendmail on an Intel x86 machine running OS/2, I have
some problems. Specifically, I have....
The OS/2 port of sendmail is known to have left out huge
chunks of the code and functionality of even much older
versions of sendmail, in large part because the underlying OS
just doesn't have the necessary hooks to make it happen.
This port is so broken that we make no attempt to provide any
kind of support for it. Try BSDI's BSD/386 instead.
----------------------------------------------------------------------
* I'm connected to the network via a SLIP/PPP 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.
----------------------------------------------------------------------
* I just upgraded to 8.x and suddenly I'm getting messages in my
syslog of the form "collect: I/O error on connection". What is
going wrong?
Nothing. This is just a diagnosis of a condition that had
not been diagnosed before. If you are getting a lot of these
from a single host, there is probably some incompatibility
between 8.x and that host. If you get a lot of them in
general, you may have network problems that are causing
connections to get reset.
----------------------------------------------------------------------
* I just upgraded to 8.x and now when my users try to forward their
mail to a program they get an "illegal shell" message and their
mail is not delivered. What's wrong?
In order for people to be able to run a program from their
.forward file, 8.x insists that their shell (that is, the
shell listed for that user in the passwd entry) be a "valid"
shell, meaning a shell listed in /etc/shells. If /etc/shells
does not exist, a default list is used, typically consisting
of /bin/sh and /bin/csh.
This is to support environments that may have NFS-shared
directories mounted on machines on which users do not have
login permission. For example, many people make their
file server inaccessible for performance or security
reasons; although users have directories, their shell on
the server is /usr/local/etc/nologin or some such. If you
allowed them to run programs anyway you might as well let
them log in.
If you are willing to let users run programs from their
.forward file even though they cannot telnet or rsh in (as
might be reasonable if you run smrsh to control the list of
programs they can run) then add the line
/SENDMAIL/ANY/SHELL/
to /etc/shells. This must be typed exactly as indicated,
in caps, with the trailing slash. NOTA BENE: DO NOT
list /usr/local/etc/nologin in /etc/shells -- this will
open up other security problems.
----------------------------------------------------------------------
* I just upgraded to 8.x and suddenly connections to the SMTP port
take a long time. What is going wrong?
It's probably something weird in your TCP implementation that
makes the IDENT code act oddly. On most systems V8 tries to
do a ``callback'' to the connecting host to get a validated
user name (see RFC 1413 for detail). If the connecting host
does not support such a service it will normally fail quickly
with "Connection refused", but certain kinds of packet
filters and certain TCP implementations just time out.
To test this, set the IDENT timeout to zero using
``OrIdent=0'' in the configuration file. This will
completely disable all use of the IDENT protocol.
Another possible problem is that you have your name server
and/or resolver configured improperly. Make sure that all
"nameserver" entries in /etc/resolv.conf point to functional
servers. If you are running your own server make certain
that all the servers listed in your root cache (usually
called something like "/var/namedb/root.cache"; see your
/etc/named.boot file to get your value) are up to date.
Either of these can cause long delays.
----------------------------------------------------------------------
* I just upgraded to 8.x and suddenly I get errors such as ``unknown
mailer error 5 -- mail: options MUST PRECEDE recipients.'' What is
going wrong?
You need OSTYPE(systype) in your .mc file -- otherwise the
configurations use a default that probably disagrees with
your local mail system. See cf/README for details.
----------------------------------------------------------------------
* 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
propagates 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".
----------------------------------------------------------------------
* I am trying to use MASQUERADE_AS (or the user database) to
rewrite from addresses, and although it works in the From: header
line, it doesn't work in the envelope (e.g., the "From " line).
Believe it or not, this is intentional. The interpretation
of the standards by the V8 development group was that this
was an inappropriate rewriting, and that if the rewriting
were incorrect at least the envelope would contain a valid
return address. Other people have since described scenarios
where the envelope cannot be correct without this rewriting,
so 8.7 will have an option to rewrite both header and
envelope.
----------------------------------------------------------------------
* I want to run Sendmail version 8 on my DEC system, but you don't
have MAIL11V3 support in sendmail. How do I handle this?
Get Paul Vixie's reimplementation of the mail11 protocol from
gatekeeper.dec.com in /pub/DEC/gwtools.
Rumour has it that he will be fully integrating into sendmail
V8 what little is left of IDA sendmail that is not handled
(or handled as well) by V8. No additional information on
this project is currently available.
----------------------------------------------------------------------
* Messages seem to disappear from my queue unsent. When I look in
the queue directory I see that they have been renamed from qf* to
Qf*, and sendmail doesn't see these.
If you look closely you should find that the Qf files are
owned by users other than root. Since sendmail runs as root
it refuses to believe information in non-root-owned qf files,
and it renames them to Qf to get them out of the way and make
it easy for you to find. The usual cause of this is
twofold: first, you have the queue directory world writable
(which is probably a mistake -- this opens up other security
problems) and someone is calling sendmail with an "unsafe"
flag, usually a -o flag that sets an option that could
compromise security. When sendmail sees this it gives up
setuid root permissions.
The usual solution is to not use the problematic flags. If
you must use them, you have to write a special queue
directory and have them processed by the same uid that
submitted the job in the first place.
----------------------------------------------------------------------
@(#)FAQ 8.15 (Berkeley) 2/24/95
Send updates to sendmail@CS.Berkeley.EDU.