+ 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.
projects / unix-history / blobdiff