Comments and questions on this FAQ should be directed to [email protected].
unable to write /etc/mail/sendmail.pid?
Kvirtuser line
to sendmail.cf ?
The entire contents of this document are copyright 1997 - 1998 by the Sendmail Consortium, all rights reserved.
This document may be freely distributed for non-profit purposes (including, but not limited to: posting to mailing lists, Usenet newsgroups, and world-wide-web pages; inclusion on CD-ROM or other distribution media; and insertion into text retrieval systems), so long as it is the latest version available at the time, all parts are distributed together, and it is kept completely intact without editing, changes, deletions, or additions. Non-profit redistribution in accordance with these guidelines does not require contact with or approval from the copyright holder.
Redistribution of this document for profit without express prior permission is not allowed. At the very least, expect to provide the copyright holder a free copy of the product (exactly as it would be sold to customers, all distribution media intact), or a percentage of the gross revenue from said product and sufficient proof that the integrity and completeness requirements set for non-profit distribution will be met.
In the event that the copyright holder discovers a redistributed version that is not in compliance with the above requirements, he will make a good-faith effort to get it corrected or removed, and failing that, at least note its deprecated status in a new version. Legal action will likely be taken against redistribution for profit that is not in compliance with the above requirements.
The Usenet newsgroup comp.mail.sendmail is dedicated to the discussion of the program named "sendmail" in all its various forms. It is most commonly found on computers running a flavor of the Operating System known as Unix, or derived from Unix.
This program has been ported to other OSes, but those versions have typically been ported by a particular vendor and are considered proprietary. There are many versions of sendmail, but the original author (Eric Allman) is continuing development on a particular version typically referred to as "Version Eight" or sometimes just "V8". This is considered by many to be the One True Version. This is also the version that this FAQ is centered around.
If you have a question that amounts to "How do I send mail to my friend?", then you're in the wrong newsgroup. You should first check with your System or E-Mail Administrator(s), BBS SysOp(s), etc... before you post your question publicly, since the answer will likely be very highly dependent on what software and hardware you have. You also don't want to embarrass yourself publicly, nor do you want to annoy the kinds of people who are likely to be the counterparts of your System or E-Mail Administrator(s), BBS SysOp(s), etc.... If asking them doesn't do you any good, make sure you read this FAQ and the other mail-related FAQs at the archive sites listed below.
If you have a question about another program similar to sendmail (technically referred to as an "SMTP MTA"), an SMTP Gateway package, or a LAN email package, then you should see if there is another group in the comp.mail hierarchy that more closely matches the particular program you want to ask a question about. For example, the SMTP MTA known as Smail has comp.mail.smail dedicated to it. The Mail User Agent (MUA) Eudora has two newsgroups dedicated to it (comp.mail.eudora.mac and comp.mail.eudora.ms-windows), depending on which hardware platform you use. If there isn't a more appropriate newsgroup, try comp.mail.misc. Again, make sure your question isn't already addressed in one of the mail-related FAQs or other available documentation. See the IMC website (more info below) for a good list of mail-related FAQs.
If you have a question about an older or vendor-proprietary version of sendmail, be prepared for a lot of answers that amount to "Get V8". Version 8 isn't a panacea, but it does solve many problems known to plague previous versions, as well as having many new features that make it much easier to administer large or complex sites. In many cases, it makes at least possible what was previously virtually impossible, and relatively easy the previously difficult.
There are, of course, many alternative programs that have sprung up in an attempt to answer one or another weakness or perceived fault of sendmail, but so far, none of them have had the kind of success it would require to unseat it as the de facto standard program for sending Internet mail. Obviously, this forum should not be used to discuss the merits of any of the alternative programs versus sendmail. These kinds of discussions should be taken to comp.mail.misc, or you should agitate to get a new newsgroup or newsgroup hierarchy created where that sort of thing is acceptable (or even the norm, such as a comp.mail.advocacy or news:comp.mail.mta.advocacy newsgroup).
This FAQ is strongly centered around version 8 sendmail, for many reasons. First and foremost, this is the area of most interest on the part of the maintainers of this FAQ. Secondly, version 8 is where most of the additional development is being concentrated. Version 8 sendmail is also the best documented of all SMTP MTAs, by virtue of the book by Bryan Costales (see entry sendmail-faq//book/ISBN/1-56592-222-0 in Q6.1).
Other versions of sendmail get mentioned in passing, and some interesting interactions between version 8 and various OSes is also covered.
This FAQ is aimed primarily at the experienced Unix System Administrator/Postmaster/DNS Domain Administrator. If you're looking for introductory texts, see the references in Q6.1.
We post changes as they occur to the sendmail FAQ support page at http://www.sendmail.org/faq/.
Send email to [email protected] with the command "sub comp-news.comp.mail.sendmail full-US-ordered-email-address" as the body of the message (with your correct address in place of the "full-US-ordered-email-address", and omitting the double quotes in all cases of this example).
E-mail you want posted on comp.mail.sendmail should be sent to [email protected]
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 Usenet newsgroup comp.protocols.tcp-ip.domains (DNS in general) or to the Info-BIND mailing list (if the question is specific to that program).
For comp.protocols.tcp-ip.domains, you have to be on Usenet. They don't have a news-to-mail gateway yet (I'm working on this), but they do have a FAQ.
Questions from all levels of experience can be found on this newsgroup (as well as people to answer them), so don't be shy about asking a question you think may be too simple.
Some more information from the BIND 8.1 src/README file:
| URL | Purpose |
|---|---|
| ftp.isc.org/isc/bind/src/cur | current non-test release |
| ftp.isc.org/isc/bind/src/testing | latest public test kit |
| comp.protocols.dns.bind | using BIND |
| comp.protocols.dns.ops | DNS operations in general |
| comp.protocols.dns.std | DNS standards in general |
| [email protected] | gw'd to c.p.d.bind |
| [email protected] | gw'd to c.p.d.std |
| [email protected] | code warriors only please |
| www.isc.org/bind.html | the BIND home page |
| [email protected] | bug reports |
If you're concerned at all about the security of your machines, you should make sure you're at least running a recent release of version 8 sendmail (either from your vendor or the public version detailed in 1.8).
Check the CERT Alerts and Summaries to make sure that you're running a version that is free of known security holes. Just because the sendmail program provided by your vendor isn't listed doesn't mean that you're not vulnerable, however. If your particular vendor or version isn't listed, check with your vendor and on the appropriate Internet mailing lists and Usenet newsgroups to verify.
If nothing else, the most recent public version is usually a pretty good bet, although you should check comp.mail.sendmail to see if anyone has posted recent comments that haven't yet been folded into a new release.
That said, you need to look at what the primary function is for the machine. If its primary function is to run some CAD/CAM package on the desk of an engineer, then there's probably not much sense in replacing the vendor-supplied version of sendmail (assuming it's secure, according to the CERT Alerts and Summaries). Just set the machine up to forward all outbound mail to a central mail relay, and then worry about making that central mail relay the best it can be. Also arrange to have all their inbound mail pass through a central Mail eXchanger (probably the same machine as the central Mail Relay), for the same reasons.
If the primary function for a machine is to act as that central Mail Relay/Mail eXchanger, then we *strongly* recommend the best version of sendmail you can get, and in our opinion that is the latest release of version 8. IDA sendmail is also pretty good, but virtually everything it does, version 8 does better, and version 8 has the additional advantage of having continued development as well.
If fighting spam is a concern, then by all means upgrade to 8.9.X . 8.8.X has some good anti-spam features, but 8.9.X has more features, and the anti-spam ones are far easier to configure than those in 8.8.X .
However, keep in mind that version 8 still hasn't been ported (so far as we know) to some of the older (and perhaps more esoteric) platforms, and if you're stuck using one of them, you may not have much choice.
Recently, some vendors have started shipping (or announced that they will soon ship) version 8 sendmail pre-configured for their machines. Unfortunately, in most cases this means you get a pre-compiled binary and a sendmail.cf file (that may need a bit of tweaking), but not much else of the "standard" version 8 sendmail installation kit. Silicon Graphics (SGI), Hewlett-Packard and Sun Microsystems are known to already be shipping version 8 sendmail in this fashion.
For version 8 sendmail, there are four release trees.
For those people who, for whatever reason, are unable or unwilling to upgrade to version 8.8.z, releases of version 8.6 and 8.7 sendmail are still available. As of this writing, the most recent release of version 8.6 sendmail is 8.6.13, and the most recent release of version 8.7 sendmail is 8.7.6.
For the most recent releases of 8.6 and 8.7 sendmail, there is a version number difference between the sendmail program itself and the associated configuration files. This is okay. The security-related bug fixes that were made only required changes to the sendmail program itself and not the configuration files, so only the version number of the sendmail program itself was incremented.
Version 8.9.1 was released on July 2, 1998. Version 8.9.0 was released on May 20, 1998.
On machines exposed directly to the Internet, you should either already be running sendmail 8.9.0 or plan on upgrading to it in the immediate future. 8.9.0 is considered "stable", has security fixes included that will not be found in any previous release, and therefore supercedes all previous releases.
There is no further support for previous releases of sendmail.
By anonymous FTP from ftp.sendmail.org in /pub/sendmail, or (in URL form) via ftp://ftp.sendmail.org/pub/sendmail/. If you care, there should be files in this directory that end with the extension ".sig" which you can check with PGP to make sure that corresponding archives haven't been modified. You'll need to have the PGP key of Eric Allman on your public keyring to be able to verify these archives with their associated .sig files.
There are no other known official version 8 sendmail mirrors.
Check the sendmail home page at http://www.sendmail.org/ for late-breaking updates and other useful information.
If you want to be notified regarding future updates to sendmail and other items of potential interest, you may want to subscribe to the sendmail-announce mailing list. Address your subscription requests to "[email protected]" with "subscribe sendmail-announce" as the body of the message.
See doc/changes/changes.{me,ps} in the distribution. See also RELEASE_NOTES at the top level.
Generally speaking, I adhere to the old axiom that you should choose what software you want to run first, then choose the platform (hardware and OS) that best runs this software. By this token, if sendmail is the software, then a recent version of BSD Unix would probably be best, since sendmail was developed at UC Berkeley on BSD Unix. FreeBSD and BSD/OS are two known implementations of BSD Unix for Intel-based PC's (among other hardware platforms), and this would make them the most "native" OSes for sendmail. FreeBSD is freely available by anonymous ftp or on CD-ROM, and BSD/OS is a commercial product.
However, not everyone has this kind of "luxury". If you're on a homogeneous network (i.e., completely composed of only one type of hardware and OS), then you should probably be running the same OS as the rest of the machines on the network, regardless of the axiom stated above. You may have other problems, but you should at least be able to get some local support on the OS for your machine.
Either way, if the primary function of the machine is to handle "large" quantities of mail (for whatever value you define "large" to be), I strongly recommend getting the latest stable release of version 8 sendmail.
You may be surprised to find that it is easier for you to support only one version of sendmail across all the various platforms than it is to try to support multiple versions of sendmail, each unique for their particular platform. In that case, the easy solution is to put version 8 sendmail everywhere, and not have to worry about vendor-specific problems with older versions.
For more information on BSD Unix in general, see the Usenet newsgroups under comp.unix.bsd, comp.bugs.4bsd, comp.os.386bsd. For more information on BSD/OS, see the BSD newsgroups mentioned above, or the BSD/OS Home Page at http://www.bsdi.com/. For more information on FreeBSD, see the Usenet newsgroups under news:comp.unix.bsd.freebsd, or the FreeBSD Home Page at http://www.freebsd.org/.
BIND stands for "Berkeley Internet Name Daemon", and is the Internet de-facto standard program for turning host names into IP addresses.
The BIND Home Page is at http://www.isc.org/bind.html, which provides pointers to the most recent release of BIND. In May of 1997, the first production version of BIND-8 was released. The ISC has deprecated BIND-4 other than for security related patches. No new features or portability changes will be added to BIND-4. You should be using BIND-8.
Note that there are bugs in older resolver libraries, which can cause problems getting to large sites (that list more than five IP addresses for a particular name), or represent a huge security hole as they do not check the returned data to see if it will fit in the amount of space pre-allocated for it.
If at all possible, you should get the most recent "release" version of BIND and make a serious attempt to integrate it into your configuration, since virtually all vendor-provided resolver libraries are woefully out of date.
Note that since the release of BIND version 8.1, many people building sendmail
have experienced problems compiling and linking with the new BIND include files
and libraries under /usr/local/. A section in our Compiling
Sendmail page explains this.
From ftp://info.cert.org/pub/tools/smrsh/README:
smrsh is a restricted shell utility that provides the ability to specify, through a configuration, an explicit list of executable programs. When used in conjunction with sendmail, smrsh effectively limits sendmail's scope of program execution to only those programs specified in smrsh's configuration.
smrsh has been written with portability in mind, and uses traditional Unix library utilities. As such, smrsh should compile on most Unix C compilers.
The purpose for restricting the list of programs that can be executed in this manner is to keep mail messages (either through an alias or the .forward file in a user's home directory) from being sent to arbitrary programs which are not necessarily known to be sufficiently paranoid in checking their input, and can therefore be easily subverted (this is related to, but different from, the /etc/shells feature discussed in Q3.11).
More information regarding the CERT-CC can be found at their web site, http://www.cert.org. For more information on CERT Alerts and CERT Summaries, see their advisories and summaries, respectively.
You can find smrsh in the most recent sendmail source archive, as well as ftp://info.cert.org/pub/tools/smrsh/. Other very useful programs can be found in ftp://info.cert.org/pub/tools/.
Smap (and smapd) are tools out of the Trusted Information Systems (TIS) Firewall Toolkit (fwtk). They were originally written by firewall expert Marcus Ranum under contract to TIS, and TIS is continuing what maintenance there is. The toolkit may be found at here. Support questions regarding the toolkit may be sent to [email protected], while you may join their mailing list [email protected] by sending electronic mail to [email protected].
The concept of smap and smapd is that sendmail is a huge, monolithic setuid root program that is virtually impossible to verify as being "correct" and free from bugs (historically, sendmail has been rather buggy and an easy mark for system crackers to exploit, although with the advent of version 8 sendmail, this becomes much more difficult). In contrast, smap and smapd are very small (only a few hundred lines long), and relatively easy to verify as being correct and functioning as designed (however, as you will see later, we can question their design). According to the theory, it is therefore safer and "better" to run smap and smapd as "wrappers" around sendmail, which would no longer need to be run setuid root.
Unfortunately, smap and smapd have a few problems of their own, and don't appear to have been updated since late March 1996. There have been conflicting reports of incompatibilities between smapd and sendmail 8.7.y (both cannot be run on the same machine, although if you're running sendmail 8.6.x and smap/smapd on the local machine, people on the outside can still use sendmail 8.7.y to talk to you).
For further information on smap and smapd, see the documentation that comes with the TIS Firewall Toolkit.
For more information on firewalls, see the Firewalls FAQ at http://www.v-one.com/newpages/faq.htm.
TCP-Wrappers is another security enhancement package. The theory is that you take programs being run under inetd (see /etc/inetd.conf) and before you run the program to do the real work (ftpd, telnetd, etc...), you first run the connection attempt through a package that checks to see if the IP address of the source packet is coming from a host known to be either good or bad (you may filter connection attempts by source host name, domain name, raw IP address, port they are attempting to connect to; and either allow known good connections through thus refusing unknown connections, or accept all connections except those known to be bad).
The practice of TCP-Wrappers actually follows the theory quite well. It is a very useful and important tool in the System Administrator's Bag of Things To Help You Secure Your Machine From Crackers, Spammers, Junkmailers, and Other Undesirables. However, it only works for programs that communicate via TCP packets (not UDP, such as NFS) started up out of inetd. It does not work for RPC-based services, and programs that start up a daemon outside of inetd and just leave it running obviously don't benefit beyond the initial connection that gets the daemon started (however, see the FTP URL below for other packages that can help secure RPC and portmapper-based services).
However, most sendmail installations tend to start up a daemon and leave it running at all times. If you did run sendmail out of inetd, you'd lose the benefit of the load average checking code that is executed only in daemon mode, and for systems that handle a lot of mail, this is vitally important.
You can get TCP-Wrappers from ftp://ftp.win.tue.nl/pub/security/, a site that has a whole host of other useful security tools, such as securelib, portmap, satan, cops, crack, etc... You can also find pointers to many other useful security tools at http://ciac.llnl.gov/ciac/SecurityTools.html, and the COAST Archive at http://www.cs.purdue.edu/homes/spaf/hotlists/csec.html is a veritable cornucopia of all things security related. The SANS 1996 Network Security Roadmap at http://www.sans.org/roadmap/ has much useful information and pointers to many other useful resources.
For the adventurous, you can get a source patch for version 8 sendmail (created for 8.7.6, but, with work, applicable to older releases) that will take the core TCP-Wrappers code and integrate it into the daemon, so that you get the best of both worlds. However, this isn't as smoothly integrated as it should be, is not for the faint-of-heart, and is certainly not officially supported by the original author of sendmail (Eric Allman). This functionality is integrated in a different fashion into version 8.8.5 sendmail.
You should be able to find the unsupported patch at ftp://ftp.win.tue.nl/pub/security/sendmail-tcpd.patch.
As of release 8.9.X of sendmail, db 1.85 is no longer needed, as support for db 2.X is included (starting with 2.3.16). More details are given at Q3.25. The rest of this answer only applies if you have not yet upgraded to 8.9.X .
The db 1.85 package as available from http://www.sleepycat.com/packages/db.1.85.tar.gz provides Irix support up to Irix 4.05F, but 5.{2,3} need a slightly patched version, as does HP-UX 10.20. Some vendors also provide db standard with their OS (DEC Unix 4.0, for example).
A tarball incorporating these changes for Irix 5.x is available at ftp://ftp.his.com/pub/brad/sendmail/irix5.tar.gz. This will extract into ./db.1.85/PORT/irix.5.2, with a symbolic link created from ./db.1.85/PORT/irix.5.3 to this same directory. Make sure you extract this archive into the same directory where you extracted the db 1.85 archive as available from ftp.cs.berkeley.edu. (see Q3.5 for more information on getting the db 1.85 package). An ASCII context diff of this same patch is at ftp://ftp.his.com/pub/brad/sendmail/irix4-5.diff.
A version of db 1.85 that has supposedly been patched to compile under Irix 6.2 has been made available at http://reality.sgi.com/ariel/freeware/#db, but I haven't had a chance to download and check it out yet.
The context diffs required to get db 1.85 working under HP-UX 10.20 are available at ftp://ftp.his.com/pub/brad/sendmail/hpux.10.20.diff. A tarball incorporating these changes is available at ftp://ftp.his.com/pub/brad/sendmail/hp-ux.10.20.tar.gz. This will extract into ./db.1.85/PORT/hpux.10.20, so make sure you extract this archive into the same directory where you extracted the db 1.85 archive as available from ftp.cs.berkeley.edu.
The program "makemap" is used to build the databases used by version 8 sendmail, for things like the UserDB, mailertables, etc....
It is distributed as part of the basic operating system from some vendors, but source code for it is also included at the root level of the sendmail archive (at least, it is for sendmail 8.6.12 and 8.7.5, and presumably will continue to be as newer releases come out). However, it is not considered a "supported" part of version 8 sendmail. Just like the other source provided in the archive, the Makefile will likely need some tweaking for your specific site.
It turns out that Irix 5.3 doesn't appear to have the dbm or ndbm libraries, but to compile makemap.c, you need to have -DNDBM on the "DBMDEF=" line (some necessary things are defined only in /usr/include/ndbm.h). Try just leaving off "-lndbm" from the "LIBS=" line in the Makefile for makemap.
If you plan on using makemap with db 1.85 on an SGI machine running a version of Irix later than 4.x, see Q2.16 for some additional steps to get db 1.85 compiled on your machine.
unable to write
/etc/mail/sendmail.pid on Solaris 2.x?
Kvirtuser line to sendmail.cf ?
There are a couple of ways of doing this. This describes using the "user database" code, discussed in detail at the Using UserDB to Map Full Names page. 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 DifferentName DifferentName:maildrop loginnameInstall it in (for example) /etc/userdb. Create the database:
makemap btree /etc/userdb.db < /etc/userdbYou 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)
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 email.
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 email -- 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 <[email protected]> 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.
Directory services should be as fuzzy as possible (within reason, of course). Mail services should be unique.
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.
UC Berkeley is (was) in the process of setting up their 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.
The user database code is part of the Sendmail V8 distribution. However, it depends on your installing the db library from the package at http://www.sleepycat.com/packages/db.1.85.tar.gz. If you install this library, edit the Makefile to include the right option (-DNEWDB), and then make sendmail again, you get a binary which has the database features described in the book and the documentation provided in the sendmail source archive.
If you're using SGI Irix above 4.x, see Q2.16 for the patches you will need to get db 1.85 working on your machine.
The basic incompatibility with Pine and the user database option is in how Pine writes From addresses in the header. Most MUAs write the From address as "From: user", while Pine, for reasons given in its documentation, write the From address as "From: user@FQDN" (FQDN=fully qualified domain name). Using the m4 feature macro always_add_domain has the same effect. Because of this difference, the user database does not rewrite these headers.
One solution to this problem is to make the following change in the sendmail.mc file compiled by m4 into your /etc/sendmail.cf (or wherever your sendmail.cf file is located) after you have the user database option installed and working with other MUAs:
Early in the section(s) where you are setting configuration variables, add the following:
# Define our userdb file for FQDN rewrites Kuserdb btree -o /etc/userdb.dbAnd a bit later, before the "MAILER()" entries, but after other configuration options have been set:
LOCAL_RULE_1 ######################################################## ### Local Ruleset 1, rewrite sender header & envelope ## ######################################################## #Thanks to Bjart Kvarme <[email protected]> S1 R$- $1 < @ $j . > user => user@localhost R$- < @ $=w . > $* $: $1 < @ $2 . > $3 ?? $1 user@localhost ? R$+ ?? $+ $: $1 ?? $(userdb $2 : mailname $: @ $) R$+ ?? @ $@ $1 Not found R$+ ?? $+ $>3 $2 Found, rewrite #NOTE ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ # Use Tab Characters Use Tab Characters in these regions # to make three columns (the line with "mailname" only has 2 columns).Now the user database should re-write messages sent with Pine or anything else that causes local users to have their address be fully qualified (both header and envelope sender will be properly re-written). If this still does not work for you, try adding the following to either the system-wide pine.conf, pine.conf.fixed, or your personal .pinerc:
user-domain=localhost
This has been known to help solve the problem for some people.
However, a more elegant (read: m4-based) solution for version 8 sendmail users has yet to be created.
There is nothing wrong. 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.
Note that this problem is sometimes caused by incompatible values of the MTU (Maximum Transmission Unit) size on a SLIP or PPP connection. Be sure that your MTU size is configured to be the same value as what your ISP has configured for your connection. If you are still having problems, then have your ISP configure your MTU size for 1500 (the maximum value), and you configure your MTU size similarly.
Although it seems like a problem of this sort would affect all of your connections, that is not the case. You may encounter this problem with only a small number of sites with which you exchange mail, and it may even affect only certain size messages.
I just upgraded to version 8 sendmail and now when my users try to forward their mail to a program they get an "illegal shell" or "cannot mail to programs" 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, version 8 sendmail 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.
IBM AIX does not use /etc/shells -- a list of allowable login shells is contained, along with many other login parameters, in /etc/security/login.cfg. You can copy the information in the "shells=" stanza into a /etc/shells on your system so sendmail will have something to use. Do NOT add "/usr/lib/uucp/uucico" or any other non-login shell into /etc/shells.
Also note that there are some weird things that AFS throws into the mix, and these can keep a program from running or running correctly out of .forward files or the system-wide aliases.
See also "smrsh" in Q2.13.
I just upgraded to version 8 sendmail 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 version 8 sendmail 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 (pre-8.7.y sendmail), set the IDENT timeout to zero using:
define(`confREAD_TIMEOUT',`Ident=0')dnl
in the .mc file used by m4 to generate your sendmail.cf file. Alternatively, if you don't use m4, you can put ``OrIdent=0'' in the configuration file (we recommend the m4 solution, since that makes maintenance much easier for people who don't understand sendmail re-write rules, or after you've been away from it for a while). Either way, this will completely disable all use of the IDENT protocol.
For version 8.7.y sendmail (and above), you should instead use:
define(`confTO_IDENT',`0s')dnl
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 are up to date (this file is usually called something like "/var/namedb/root.cache"; see your /etc/named.boot file to get your value). Either of these can cause long delays.
I just upgraded to version 8 sendmail 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, where "systype" is set correctly for your hardware & OS combination -- otherwise the configurations use a default that probably disagrees with your local mail system. See the configuration OSTYPE page for details.
If this is on a Sun workstation, you might also want to take a look at the local mailer flags in the Sun-supplied sendmail.cf and compare them to the local mailer flags generated for your version 8 sendmail.cf. If they differ, you might try changing the V8 flags to match the Sun flags.
Sendmail 8.7.y panics SunOS 4.1.3_U1 (at least for 1 <= y <= 3) and SunOS 4.1.3, and sendmail 8.6.x seems fine on both machines (at least for 9 <= x <= 12).
The problem is that a kernel patch is missing, specifically 100584-08 (4.1.3), 102010-05 (4.1.3_U1), or 102517 (4.1.4). This should be available from your hardware vendor through your support contract or their online support facilities (including being available on the SunSolve CD).
``It's not a bug, it's a feature.'' This happens when you have an
owner-list alias and you send to list. V8 propagates
the owner information into the SMTP envelope sender field (which appears as the
Unix From line [sometimes incorrectly referred to as the From-space "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: ericThis will make message sent to
list come out as being
"From list-request" instead of "From eric".
Believe it or not, this is intentional. The interpretation of the standards by the version 8 sendmail 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.
If you're using version 8.7.y sendmail (or later), you can use
FEATURE(masquerade_envelope)in your sendmail.mc file to change this behavior. This is discussed in greater detail at the configuration Masquerading and Relaying page.
Get the reimplementation of the mail11 protocol by Keith Moore from ftp://gatekeeper.dec.com/pub/DEC/gwtools/ (with contributions from Paul Vixie).
When I look in the queue directory I see that qf* files have been renamed to Qf*, and sendmail doesn't see these. What's wrong?
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.
This is considered to be a MUA issue rather than an MTA issue.
Quoth Eric Allman:
The primary reason is that the information necessary to do the encoding (that is, 8->7 bit) is unknown to the MTA. In specific, the character set used to encode names in headers is _NOT_ necessarily the same as used to encode the body (which is already encoded in MIME in the charset parameter of the Content-Type: header). Furthermore, it is perfectly reasonable for, say, a Swede to be living and working in Korea, or a Russian living and working in Germany, and want their name to be encoded in their native character set; it could even be that the sender was Japanese, the recipient Russian, and the body encoded in ISO 8859-1. If all I have are 8-bit characters, I can't choose the charset properly.Similarly, when doing 7->8 bit conversions, I don't want to throw away this information, as it is necessary for proper presentation to the end user.
This is usually caused by a bug in the remote host's mail server, or Mail Transport Agent (MTA). The "EHLO" command of ESMTP causes the remote server to drop the SMTP connection. There are several MTAs that have this problem, but one of the most common server implementations can be identified by the "220 All set, fire away" greeting it gives when you telnet to its SMTP port.
To work around this problem, you can configure sendmail to use a mailertable with an entry telling sendmail to use plain SMTP when talking to that host:
name.of.remote.host smtp:name.of.remote.host
Sites which must run a host with this broken SMTP implementation should do so by having a site running sendmail or some other reliable (and reasonably modern) SMTP MTA act as an MX server for the problem host.
There is also a problem wherein some TCP/IP implementations are broken, and if any connection attempt to a remote end gets a "connection refused", then *all* connections to that site will get closed. Of course, if you try to use the IDENT protocol across a firewall (at either end), this is highly likely to result in the same apparent kind of "read error".
The fix is simple -- on those machines with broken TCP/IP implementations, do not attempt to use IDENT. When compiling newer releases of version 8 sendmail, the compiler should automatically detect whether you're on a machine that is known to have this kind of TCP/IP networking problem, and make sure that sendmail does not attempt to use IDENT. If you've since patched your machine so that it no longer has this problem, you'll need to go back in and explicitly configure sendmail for support of IDENT, if you want that feature.
When creating m4 Master Config (".mc") files for version 8 sendmail, many FEATURE() macros simply change the definition of internal variables that are referenced in the MAILER() definitions.
To make sure that everything works as desired, you need to make sure that OSTYPE() macros are put at the very beginning of the file, followed by FEATURE() and HACK() macros, local definitions, and at the very bottom, the MAILER() definitions. See the configuration Introduction and Example page for more details.
In situations where you're behind a firewall, or across a dial-up line, there are times when you need to make sure that programs (such as sendmail) do not use the DNS at all.
With version 8.8, you change the service switch file to omit "DNS" and use only NIS, files, and other map types as appropriate.
With previous releases of version 8 sendmail, you need to recompile the binary and make sure that "NAMED_BIND" is turned off in src/conf.h.
Note that you'll need to forward all your outbound mail to another machine as a "relay" (one that does use DNS, and understands how to properly use MX records, etc...), otherwise you won't be able to get mail to any site(s) other than the one(s) you configure in your /etc/hosts file (or whatever).
In the contrib directory of the sendmail distribution is a
Perl script called etrn.pl. Assuming you're running sendmail
or some other SMTP MTA on some sort of a Unix host, and your ISP uses version
8.8 sendmail and they queue all mail for your domain (as opposed to stuffing
it all in one file that you need to download via POP3 or some such), the command
etrn.pl mail.myisp.com mydomain.comwill do the trick. You can learn about Perl at the Perl Language Home Page. The O'Reilly book is also very helpful.
If you don't have Perl, something like the following script should do the trick:
#!/bin/sh telnet mail.myisp.com. 25 << __EOF__ EHLO me.mydomain.com ETRN mydomain.com QUIT __EOF__Note that this is indented for readability, and the real script would have column position #1 of the file be the first printable character in each line.
Of course, you'll have to fill in the appropriate details for "mail.myisp.com", "mydomain.com", etc....
If your ISP doesn't use version 8.8 sendmail, you may have to cobble together alternative solutions. They may have a "ppplogin" script that is executed every time your machines dials them up, and if so, you may be able to have them modified this script so as to put a "sendmail -qRmydomain.com" in it (which is effectively what the "ETRN" command does, but in a safer fashion).
Alternatively, they may have a hacked finger daemon, so that you'd put "finger [email protected]" in your script. Or, they may have some other solution for you. However, only they would be able to answer what solutions they have available to them.
Obviously, the easiest and most "standard" solution is to have them upgrade their system to the most recent stable release of version 8.8 sendmail.
unable to write
/etc/mail/sendmail.pid?
sendmail checks if it has write access to the directory in which it
wants to create a file without granting special privileges to 'root'.
To have sendmail run properly, the directories /etc,
/etc/mail, and/or /var/run should be owned
by root and be writable by its owner.
sendmail 8.8 only supports Berkeley DB 1.85. It will not work with newer Berkeley DB versions, even in compatibility mode
Sendmail 8.9, however, does include support for Berkeley DB 2.X, starting with 2.3.16 .
Berkeley sendmail 8.8.8 supports most known flavors of UNIX, including:
386BSD A-UX AIX Altos BSD-OS BSD43 CLIX CSOS ConvexOS Dell DomainOS Dynix EWS-UX_V FreeBSD HP-UX IRIX ISC KSR LUNA Linux Mach386 NCR.MP-RAS NEWS-OS NeXT NetBSD NonStop-UX OSF1 OpenBSD PTX Paragon PowerUX RISCos SCO SINIX SMP_DC.OSx.NILE Solaris SVR4 SunOS Titan ULTRIX UMAX UNICOS UNIX_SV.4.x.i386 UX4800 UXPDS Utah dgux maxion uts.systemV
Also, a Windows NT version is available from MetaInfo, Inc..
You need to add the fully-qualified host name and/or IP address of each
client to class R, the set of relay-allowed domains. For version 8.8.X,
this is typically defined by the file /etc/sendmail.cR ;
for 8.9.X, it is typically /etc/mail/relay-domains . Note:
if your DNS is problematic, you may need to list the IP address in
square brackets (e.g., [1.2.3.4]) to get the
${client_name} macro to work properly; in general, however,
this should not be necessary.
Once you've updated the appropriate file, SIGHUP your sendmail
daemon and you should be OK.
Further details are available on our Allowing controlled SMTP relaying in Sendmail 8.9 page.
Kvirtuser line to sendmail.cf?
Just adding the proper Kvirtuser line to sendmail.cf is not enough
to enable the virtual user table feature, a key ingredient for virtual hosting.
You need to use the m4 technique FEATURE(virtusertable);
detailed instructions are provided at our
Virtual Hosting with Sendmail page.
Stuffing multiple user's mail into a single mail box is not a good method of distributing user mail but if you must do this, the following solution should allow a tool like fetchmail to separate the messages for individual users.
FEATURE(local_procmail) in your .mc file
so procmail (which you must install separately) will deliver mail to
the mailbox.
FEATURE(virtusertable) to create a virtual user table
entry for the domain as follows:
@domain.com domuser+%1where
domuser is the username of the mailbox you will be using.
domuser's
$HOME/.procmailrc:
DOMAIN=domain.com ENV_TO=$1 :0f * ENV_TO ?? . | formail -i "X-Envelope-To: "$ENV_TO@$DOMAIN :0fE | formail -i "X-Envelope-To: UNKNOWN"This will insert an
X-Envelope-To header with the original
envelope recipient address when the message is delivered the normal way
via the virtusertable, and UNKNOWN if for some reason it was
sent directly to domuser.
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 "MX list for hostname points back to hostname" or "config error: mail loops back to myself".
See RFCs 1535, 1536, and 1912 (updates RFC 1537) for more detail and other related (or common) problems. See also _DNS and BIND_ by Albitz and Liu.
They can also cause your system to add your domain to outgoing FQDNs in a desperate attempt to get the mail to where it's supposed to go, but because *.your.domain is valid due to the wildcard MX, delivery to not.real.domain.your.domain will get dumped on you, and you may even find yourself in a loop as the domain keeps getting tacked on time after time after time (the "config error: mail loops back to myself" problem).
Wildcard MX records are just a bad idea, plain and simple. They don't work the way you'd expect, and virtually no one gets them right. Avoid them at all costs.
This is a local mailer issue, not a sendmail issue. Depending on what you're doing, look at procmail (see Q4.9), ftpmail, or Majordomo.
The latest version of Majordomo can be found at ftp://ftp.greatcircle.com/pub/majordomo/. It is written in Perl and requires either Perl 4.036, and appears to run with only minor tweaks under 5.001a or later. Make sure to check out the web interface for Majordomo called "Mailserv" at http://iquest.com/~fitz/www/mailserv/ or "LWGate" at http://www.netspace.org/users/dwb/lwgate.html. The latest versions of Perl (both 4.x and 5.x) can be found in http://www.metronet.com/perlinfo/src/. More information about Perl can be found at http://www.metronet.com/perlinfo/perl5.html
The latest version of ftpmail can be found at ftp://src.doc.ic.ac.uk/packages/ftpmail or any comp.sources.misc archive (volume 37).
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 (see Q4.9), 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). More information is at ftp://ftp.cs.columbia.edu/pub/hlfsd/README.hlfsd, while the actual archive of the papers is at ftp://ftp.cs.columbia.edu/pub/hlfsd/hlfsd-paper.tar.gz (tar archive, gzip'ed).
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.
I'm getting these error messages:
553 MX list for domain.net points back to relay.domain.net 554 <[email protected]>... Local configuration errorHow 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: When making changes to your configuration file, be sure you kill and restart the sendmail daemon (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 with versions prior to 8.7.y!
With version 8.8.z sendmail, if the daemon was started up with a full pathname (i.e., "/usr/lib/sendmail -bd -q13m"), then you should be able to send it a HUP signal ("kill -1", or more safely, "kill -HUP") and have it reload itself (version 8.7.y sendmail cannot do this safely, and represents a security risk if it's not replaced with version 8.8.3 or later).
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.
This question is addressed on pages 445-449 of _sendmail, 2nd Ed_ (see page 319 of first edition) by Bryan Costales (see entry sendmail-faq//book/ISBN/1-56592-222-0 in Q6.1).
An updated version of this syslog-stat.pl script (so that it understands the log format used in version 8 sendmail) is at ftp://ftp.his.com/pub/brad/sendmail/syslog_stats. The updated version of ssl has been uploaded to the SMTP Resources Directory (in ftp://ftp.is.co.za/networking/mail/tools/), as well as ftp://ftp.his.com/pub/brad/sendmail/ssl. There is also another program (written by Bryan Beecher) at ftp://ftp.his.com/pub/brad/sendmail/smtpstats.
If you're interested in summarizing POP statistics, there is ftp://ftp.his.com/pub/brad/sendmail/popstats, also written by Bryan Beecher.
To see what else is available today, check the Comprehensive Perl Archive Network ftp://ftp.funet.fi/pub/languages/perl/CPAN/CPAN or ftp://ftp.cis.ufl.edu/pub/perl/CPAN/CPAN for the site nearest you. For the scripts themselves, look under CPAN/scripts/mailstuff/ at any CPAN site. For more information, see the comp.lang.perl.* FAQs at ftp://ftp.cis.ufl.edu:/pub/perl/faq/FAQ or ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/lang/perl/.
There is also the "Sendmail Statistics Project" which has a web page at http://www.josnet.se/projects/ssp/. Although they have examples online of what the output might look like, it now appears that this project is either dead or at least indefinitely on hold. Still, you may be able to talk to the authors in order to get what code from them you can.
If you're interested in using these kinds of tools to help you do some near real-time monitoring of your system, you might be interested in MEWS (Mail Early Warning System). From the README:
If you've ever written a perl script to parse sendmail log files looking for errors, MEWS might be of interest to you. If you've ever thought about writing a perl script to munge sendmail log files, cringed a little and hurriedly came up with an excuse not to do it, read on. If you don't have a Solaris 2.5 machine, you can probably stop reading here. The Mail Early Warning System (MEWS) gives postmasters immediate notification of trouble spots on your mail backbone. It only works with sendmail. To explain it in a nutshell, whenever sendmail returns a 4xx or 5xx SMTP code, with the MEWS modifications, it also sends the code over UDP to a daemon which then replays the error message to interested parties. The man pages go into a little bit more detail.If this sounds like something you might be interested in getting more details about, you can find the MEWS archive at ftp://ftp.qualcomm.com/pub/people/eamonn/mews.tar.Z.
The recommended program for this is "checksendmail" by Rob Kolstad. Old versions of this are available on various archive sites, but currently, the only way to get the most recent version (which has been updated to understand version 8.7 long option name syntax, as well as now supporting both Perl 4.x and Perl 5.x) is from Rob himself.
The latest archive will be made publicly available (most likely through the SMTPRD run by Andras Salamon; see Q6.5, entry sendmail-faq//online/index/14) as soon as it is received.
The program "procmail" is a replacement for the local mailer (variously called /bin/mail, /usr/bin/mail, mail.local, rmail, etc...). It has been ported to run on virtually every Unix-like OS you're likely to run into, and has a whole host of features. It is typically about 30% faster performing the job of the local mailer than programs such as /bin/mail or /usr/bin/mail, it has been hammered on widely to make it extremely secure (much more so than most local mailers) and very robust. Procmail is also capable of helping you put a quota on a user's mailbox through the standard Unix quota mechanism (see Q4.3).
In short, whatever you've got, you're almost guaranteed that procmail is better (if nothing else, the author has been able to focus lots of time and energy into making it the best and fastest tool available, while most system vendors just throw something together as fast as they can and move on to the whole rest of the OS).
However, this only begins to scratch the surface of what procmail is capable of. It's most important feature is the fact that it gives you a standard way to create rules (procmail calls them "recipes") to process your mail before the messages get put into your mailbox, and for that feature alone, it is one of the most important tools any administrator can have in their repertoire. By filtering out or automatically dealing with 80% of your daily cruft, it lets you spend more time on the hard 20%.
Note that recent releases of version 8 sendmail natively support using procmail as an alternate local mailer (see "FEATURE(local_procmail)" for version 8.7 and above). They also support procmail as an additional local mailer, if you're concerned about flat-out replacing your current local mailer with procmail (see "MAILER(procmail)" in version 8.7 and above).
You can also install procmail as a user and run it out of your .forward file, although this tends to be a bit slower and less efficient.
The latest version of procmail can be found at ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail/.
Procmail is also the core to a mailing list management package called "SmartList", so if you've already got procmail, adding SmartList may be a good option. Some listowners prefer Majordomo, Listserv, or one of those other programs, but SmartList has more than a few adherents as well. Your personal tastes will dictate whether you swear by SmartList or at it.
I upgraded from my vendor's sendmail to the latest version and now I'm getting these error messages when I run "newaliases":
/etc/aliases: line 13: MAILER-DAEMON... cannot alias non-local names
/etc/aliases: line 14: postmaster... cannot alias non-local names
How can I solve this problem?
Your local mailer doesn't have the "A" flag specified. Edit the Mlocal line in sendmail.cf and add "A" to the flags listed after "F=".
Better yet, if you're running a recent version of sendmail that uses m4 to generate .cf files from .mc files, regenerate your sendmail.cf and see if that fixes the problem. Remember to install the new sendmail.cf and restart the sendmail daemon.
Quoth Eric Allman:
... I can make the following assurances:Internally, sendmail represents dates in the Unix native format: seconds since January 1, 1970. This does not overflow until well after the year 2000.
Externally, sendmail always represents dates using four digit years, as required by the applicable Internet standards.
At no time does sendmail store dates using only the last two digits of the year. However, if a
Date:field is received that has a two digit year, sendmail does not attempt to repair that damage. However, neither does it attempt to interpret the date.
First, you need to get sendmail not to use DNS on your local machine so your host doesn't trying to connect to your ISP for a DNS query. See Q3.22 for more information.
You also need to designate a "smart host" or external relay to handle all mail that you can't deliver locally (this would be your ISP's mailhost).
You need to configure it so that the smtp mailer is considered
"expensive" by adding the F=e mailer flag and tell sendmail
not to connect to expensive mailers by default by setting the
HoldExpensive option to True.
You need to add mydomain.com to the sendmail.cw
file or the Cw line in the sendmail.cf. See
Q4.5.
Finally, you need to run a program periodically to check in with your ISP and get them to deliver any mail they may have queued for you. See Q3.23.
When I use sendmail V8 with a Sun config file I get lines like:
/etc/sendmail.cf: line 273: replacement $3 out of boundsthe line in question reads:
R$*<@$%y>$* $1<@$2.LOCAL>$3 user@etherwhat 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") in the latest version 8 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 version 8 sendmail 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 (make sure you're logged in as root):
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.oldAssuming, of course, that you have installed sendmail V8 in /usr/local/lib/sendmail.v8.
In moving from Solaris 2.4 to Solaris 2.5, the kernel changed its name and is now in /kernel/genunix instead of /kernel/unix, so _PATH_UNIX in conf.h is pointing to the wrong place.
If you can't upgrade to the latest release of sendmail 8.8.z, the next best thing to do is change _PATH_UNIX in conf.h (in the solaris2 part) to point to the generic interface /dev/ksyms, like so:
# define _PATH_UNIX "/dev/ksyms"
This is most likely a problem in your resolver libraries (DNS, /etc/hosts, NIS, etc...). Older Sun (and Solaris?) resolver libraries allocated enough room for only five IP addresses for each host name, and if any program ever ran across a name with more than five IP addresses for it, the program would crash.
For example, this would keep you from getting mail to CompuServe, since (at the time of this writing) they list eleven IP addresses for mx1.compuserve.com (one of the named MXes for compuserve.com).
This will affect you even if you use version 8 sendmail, since it's a problem in the resolver libraries, and not in sendmail itself.
You should either get patches to the resolver libraries from Sun, or the latest version of BIND (see Q2.12) and install their resolver library routines. Between the two, installing BIND is a bit more work, but it typically gives you much more up-to-date code to help you resist attacks to your systems, more capable programs to be used for serving the DNS (including support for IPv6 and several other features), and some very useful utility programs.
Many people have experienced compilation problems on Solaris, with
the compiler typically complaining about tm_zone or
TopFrame. The Solaris
section of our Compiling Sendmail page
explains these.
With a Vn/Berkeley config file, they're identical.
There are a few minor differences between 8.X with a
Vn/Berkeley config file and 8.X+Sun
with the same config file, but the V line changed to
Vn/Sun. But most differences are the backwards
compatibility hacks needed for 8.X+Sun to support old
V1/Sun config files.
There are three web pages which discuss these in detail: Berkeley migration (from SMI-8.6 to 8.X), Sun migration (from SMI-8.6 to 8.X+Sun), and Differences (5 sections comparing and contrasting config files and binaries).
When I use version 8 sendmail on an IBM RS/6000 running AIX, the system resource controller always reports sendmail as "inoperative", even though it's actually running. What's wrong?
When running as a daemon, sendmail detaches from its parent process, fooling the SRC into thinking that sendmail has exited. To fix this, issue the commands:
kill `head -1 /etc/sendmail.pid` chssys -s sendmail -f 9 -n 15 -S -a "-d99.100" # use "-d0.1" in sendmail 8.6.x startsrc -s sendmail -a "-bd -q30m" # your sendmail args may varyNow the SRC should report the correct status of sendmail. If you are using version 8.6.x, use "-d0.1" instead of "-d99.100" (the debug options changed somewhat in version 8.7). In 8.6.x a side-effect of the "-d0.1" option is that a few lines of debug output will be printed on the system console every time sendmail starts up.
For more information, read up on the System Resource Controller, the lssrc command and the chssys command in the online AIX documentation.
When I use IBM's sendmail on an IBM RS/6000 running AIX trying to get to certain sites, it seems that I can get to some of them and not others. What's wrong?
There are two possible problems here:
1) Your version of sendmail is not configured to recognize MX records in the DNS. Search through your sendmail.cf looking for "OK MX" or "OK ALL". Older configurations had this line commented out, and this will cause mail from you to some sites to fail (because those sites have MX records, but no A records in their DNS for the specific Fully Qualified Domain Name you're trying to mail to).
For more information, see the comp.unix.aix FAQ ftp://rtfm.mit.edu/pub/usenet/news.answers/aix-faq/.
2) There is a negative caching bug in AIX 3.2.5 with /usr/sbin/named executables that are less than 103000 bytes long. Ask your IBM representative to give you PMP 3251, or the most recent patch that fixes this problem for your particular configuration and version of the OS.
IBM, in their infinite wisdom, provided a header file that would easily mis-compile. This resulted in the struct{} for the DNS query to be mis-allocated, and MX processing would barf.
Fix 1) upgrade to 8.7.5 - this has a code fix for this problem.
Fix 2) Install the BIND 4.9.4 libraries and include files and tweak the Makefile.AIX to use them - I *think* these Get It Right (if not, at least it'll die during compile rather than failing weirdly at runtime).
Fix 3) Hack Makefile.AIX to pass a -DBIT_ZERO_ON_LEFT to cause the headers to use the right #ifdefs.
This probably isn't in strict RFC 1807 format, but I'm getting closer. Unfortunately, the format detailed in RFC 1807 was never intended to be used in this fashion, so I'm doing a bit of square-peg fitting into round holes.
Note that the publisher ids that I've assigned should not be misconstrued to imply that I have actually published all these documents, it's just that I need some sort of reasonable entry for the RFC 1807 "ID" field, and in lieu of information to the contrary indicating what the actual publishers have registered, I have assigned my own, independent, "third-party" IDs. Hopefully, the bibliographic entries below make it obvious who the real publishers of the various documents are.
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/reference/1
ENTRY:: March 23, 1996
TYPE:: Reference manual, available online in printable format
REVISION:: April 8, 1997; Updated "CONTACT" information
TITLE:: Sendmail Installation and Operation Guide
AUTHOR:: Allman, Eric
CONTACT:: Eric Allman <[email protected]>
DATE:: November 19, 1995
PAGES:: 69
RETRIEVAL:: Contents of manual is in doc/op/op.ps of sendmail source
archive
KEYWORD:: version 8.7.5 sendmail
LANGUAGE:: English
NOTES:: {g|n}roff "me" macro format version is in doc/op/op.me
See: URL:http://www.sendmail.org/
ABSTRACT::
The documentation written by Eric Allman himself, comes with the sendmail distribution. The file in doc/op/op.me (nroff "me" macro format) may have a different number of pages depending on the type of device it is printed on, etc....
Eric provides his free consulting in the form of continuing development on sendmail, and occasional posts to comp.mail.sendmail. Please don't be so rude as to ask him to provide further free consulting directly to you. If you (or your company) are willing to compensate him for his consulting time, he may be willing to listen. At the very least, you should make sure you've exhausted all other courses of action before resorting to adding another message to the thousands he gets per day.
Check the sendmail home page for late-breaking updates and other useful information.
If you want to be notified regarding future updates to sendmail and other items of potential interest, you may want to subscribe to the sendmail-announce mailing list. Address your subscription requests to "[email protected]" with "subscribe sendmail-announce" as the body of the message.
END:: sendmail-faq//online/reference/1
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/1-56592-222-0
ENTRY:: March 23, 1996
REVISION:: April 8, 1997; Updated entire entry re: 2nd Ed.
TYPE:: Reference book, hardcopy
TITLE:: sendmail
AUTHOR:: Costales, Bryan
AUTHOR:: Allman, Eric
CONTACT:: Bryan Costales <[email protected]>
O'Reilly & Associates, Inc.
103 Morris Street, Suite A
Sebastapol, CA 95472
Order by phone: 800-998-9938 (US/Canada inquiries)
800-889-8969 (US/Canada credit card orders)
707-829-0515 (local/overseas)
DATE:: January, 1997
PAGES:: 1021
COPYRIGHT:: Copyright (c) 1997 O'Reilly & Associates, Inc. All rights
reserved.
LANGUAGE:: English
NOTES:: See: URL:http://www.ora.com/catalog/sendmail2/
ABSTRACT::
The definitive reference for version 8 sendmail (specifically, version 8.8). If you can have only one book on the subject of sendmail, this one is it.
Bryan provides his consulting to the world in the form of his book, unless you're willing to compensate him for his services as well. Like Eric, you should make sure you've exhausted all other courses of action before you spend any of his valuable time.
END:: sendmail-faq//book/ISBN/1-56592-222-0
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/1-55558-127-7
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: Sep 9, 1996; fixed typo
TITLE:: Sendmail: Theory and Practice
AUTHOR:: Avolio, Frederick M.
AUTHOR:: Vixie, Paul A.
CONTACT:: Fred Avolio <[email protected]>, Paul Vixie <[email protected]>
Digital Press
225 Wildwood Avenue
Woburn, MA 01801, USA
Ordering Info: voice 1 800 366 2665
fax 1 800 446 6520
DATE:: 1994
PAGES:: 262
COPYRIGHT:: Copyright (c) by 1995 Butterworth-Heinemann
LANGUAGE:: English
NOTES:: See: URL:http://www.vix.com/vix/smtap/
ABSTRACT::
Centers more on IDA sendmail (at least partly because version 8 didn't exist when they began the book). Written more like a college Sophomore or Junior level textbook.
While you'll probably never let the Costales book out of your grubby little hands (especially if you do much work with version 8 sendmail), this is a book you'll probably read once or maybe twice, learn some very valuable things, but then likely put on a shelf and not read or reference again (unless you have to write up a bibliographic entry for it). Makes a better introduction to sendmail for management types, especially if you don't want them getting their hands on too much "dangerous" technical information. Also a *lot* smaller and less imposing.
If possible, I recommend getting both, but if you can only get one, get Costales unless you're going to be working exclusively with IDA sendmail, in which case Avolio & Vixie will probably be more useful.
Note that Paul Vixie is extremely busy working on further development of BIND, the Internet de facto standard program for serving the DNS, upon which all Internet services depend, mail being only one of them. Like Eric and Bryan, he's also very busy. Unless you're willing to compensate him for his services, please let him get real work done.
END:: sendmail-faq//book/ISBN/1-55558-127-7
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/0-13-151051-7
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: May 23, 1996; Updated abstract.
TITLE:: Unix System Administration Handbook, Second Edition
AUTHOR:: Nemeth, Evi
AUTHOR:: Snyder, Garth
AUTHOR:: Seebass, Scott
AUTHOR:: Hein, Trent R.
CONTACT:: <[email protected]>
Prentice-Hall, Inc.
Upper Saddle River, New Jersey 07458
DATE:: January, 1995
PAGES:: 780
COPYRIGHT:: Copyright (c) 1995 by Prentice Hall PTR
LANGUAGE:: English
NOTES:: See: URL:http://www.admin.com/
ABSTRACT::
Still the best hands-on Unix System Administration book around. Covers far more than just sendmail, but the sixty-four pages (pages 455-518 in the third printing) it does devote are very well written and quite useful. Also provides a version of Rob Kolstad's checksendmail script on the accompanying CD-ROM.
Note that Eric Allman and Marshall Kirk McKusick wrote the Foreword for the Second Edition. This should give you at least an inkling as to how essential this book is, even for experienced Unix administrators.
END:: sendmail-faq//book/ISBN/0-13-151051-7
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/0-201-58629=0
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: March 27, 1996; Changed ID format to include ISBN,
moved URL to NOTES field from OTHER_ACCESS field,
also updated ABSTRACT
REVISION:: March 29, 1996; Updated ID, PAGES, COPYRIGHT, and ABSTRACT
TITLE:: Practical Internetworking With TCP/IP and UNIX
AUTHOR:: Carl-Mitchell, Smoot
AUTHOR:: Quarterman, John S.
CONTACT:: <[email protected]>
Addison Wesley Publishing Company
Computer Science & Engineering Division
One Jacob Way
Reading, MA 01867
USA
Orders: voice://800-822-6339 (USA)
fax://617-942-1117
DATE:: 1993
PAGES:: 476
COPYRIGHT:: Copyright (c) 1993 by Addison-Wesley Publishing
Company, Inc.
LANGUAGE:: English
NOTES:: See URL:http://heg-school.aw.com/cseng/authors/mitchell/
practical/practical.html
ABSTRACT::
Devotes 50 pages (most of chapter 8) to discussion of sendmail. As far as TCP/IP networking books go that also happen to discuss sendmail, it seems well-written and clear (better than I recall Hunt's book being), but rather dated in the face of books devoted to the topic and all the recent development activity in the sendmail community. Forget about the references, though. The newest sendmail-related reference listed is dated 1983, ten years before the date on this book and most certainly wildly out-of-date now.
There are other books written on the subject of Internetworking with TCP/IP (most notably Comer), but this particular book seems to have a unique mix of theory (if perhaps a bit dated) and practical advice. Other books tend to have lots of one or the other, or split their theory and nitty-gritty details into separate books in a series (like Comer).
Assuming that an update will be coming out soon, it probably deserves a place on the shelf of most System or Network Administrators, right next to _Internetworking with TCP/IP_ by Comer, _Managing Internet Information Services_ by Liu, et. al., _DNS and BIND_ by Albitz and Liu, _Unix System Administration_ by Nemeth, et. al., and last, but certainly not least, _sendmail_ by Costales. However, it deserves this place more because of the non-sendmail related material, as opposed to what sendmail-related material there is.
END:: sendmail-faq//book/ISBN/0-201-58629-0
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/0-937175-82-X
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: April 8, 1997; updated URL in NOTES section
TITLE:: TCP/IP Network Administration
AUTHOR:: Hunt, Craig
CONTACT:: O'Reilly & Associates, Inc.
103 Morris Street, Suite A
Sebastapol, CA 95472
Order by phone: 800-998-9938 (US/Canada inquiries)
800-889-8969 (US/Canada credit card orders)
707-829-0515 (local/overseas)
DATE:: August, 1992
PAGES:: 502
LANGUAGE:: English
NOTES:: See: URL:http://www.ora.com/catalog/tcp/
ABSTRACT::
The book I learned sendmail from when there was no other book in print that even mentioned the name.
Here primarily for historical purposes, especially with respect to the sending of Internet mail and the DNS. Some of the other TCP/IP networking stuff is relevant, but this book is getting more and more dated as time goes by.
END:: sendmail-faq//book/ISBN/0-937175-82-X
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/1-56592-236-0
ENTRY:: March 23, 1996
TYPE:: Reference book, hardcopy
REVISION:: April 8, 1997; Updated entire entry for 2nd Ed.
TITLE:: DNS and BIND
AUTHOR:: Albitz, Paul
AUTHOR:: Liu, Cricket
CONTACT:: O'Reilly & Associates, Inc.
103 Morris Street, Suite A
Order by phone: 800-998-9938 (US/Canada inquiries)
800-889-8969 (US/Canada credit card orders)
707-829-0515 (local/overseas)
DATE:: January, 1997
PAGES:: 418
COPYRIGHT:: Copyright (c) 1997 O'Reilly & Associates, Inc. All rights
reserved.
LANGUAGE:: English
NOTES:: See: URL:http://www.ora.com/catalog/dns2/
ABSTRACT::
As definitive as Costales is on sendmail, this book is on the subject of the Domain Name System (DNS) and the most common server software for the DNS, namely BIND.
The second edition has been updated to reflect the changes in BIND up through version 4.9.4, but even the first edition still stands the test of time as the one book *every* DNS/Domain Administrator should have on their shelf. The second edition is just that much better.
Since the sending of Internet mail is so very heavily dependant on the DNS, it obviously also belongs on the shelf of any Postmaster or System Administrator whose site does Internet email. That means virtually every administrator of every site on the Internet.
END:: sendmail-faq//book/ISBN/1-56592-236-0
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//book/ISBN/1-56592-153-4
ENTRY:: April 8, 1997
TYPE:: Reference book, hardcopy
TITLE:: Using & Managing UUCP
AUTHOR:: Ravin, Ed
AUTHOR:: O'Reilly, Tim
AUTHOR:: Dougherty, Dale
AUTHOR:: Todino, Grace
CONTACT:: O'Reilly & Associates, Inc.
103 Morris Street, Suite A
Order by phone: 800-998-9938 (US/Canada inquiries)
800-889-8969 (US/Canada credit card orders)
707-829-0515 (local/overseas)
DATE:: September, 1996
PAGES:: 424
LANGUAGE:: English
NOTES:: See: URL:http://www.ora.com/catalog/umuucp/
ABSTRACT::
Replaces _Managing UUCP and Usenet_ by Todino and O'Reilly as the definitive book for using, installing, and managing UUCP.
The general assumption with version 8 sendmail is that virtually no one uses UUCP to send email anymore, but if that assumption isn't true for you, then you probably need this book.
END:: sendmail-faq//book/ISBN/1-56592-153-4
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/10
ENTRY:: March 23, 1996
TYPE:: Online sendmail index
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: comp.mail.sendmail FAQ Support Page
AUTHOR:: Knowles, Brad
CONTACT:: Brad Knowles <[email protected]>
OTHER_ACCESS:: URL:http://www.his.com/~brad/sendmail/
LANGUAGE:: English
ABSTRACT::
Support Page for this FAQ.
END:: sendmail-faq//online/index/10
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/17
ENTRY:: March 25, 1996
TYPE:: Online sendmail index
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: comp.mail.sendmail Most Frequently Asked Questions Support Page
AUTHOR:: Assman, Claus
CONTACT:: Claus Assmann <[email protected]>
OTHER_ACCESS:: URL:http://www.informatik.uni-kiel.de/~ca/email/english.html
LANGUAGE:: English
ABSTRACT::
Most Frequently Asked Questions on comp.mail.sendmail and their answers. Also has some links to a few other resources.
END:: sendmail-faq//online/index/17
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/resources/22
ENTRY:: November 24, 1996
TITLE:: IICONS Sendmail Resources
AUTHOR:: Caloca, Paul
CONTACT:: Paul Caloca <[email protected]>
COPYRIGHT:: Copyright (c) 1996 Paul Caloca. All Rights Reserved.
OTHER_ACCESS:: URL:http://www.iicons.com/sendmail/index.html
LANGUAGE:: English
ABSTRACT::
Provides information on how to compile Sendmail and the NEWDB db.1.85 for Solaris 2. Also has a section on which Sun patches update Solaris 2 to BIND 4.9.3.
Has pointers to some non-Sun/Solaris sendmail resources, especially including CERT Advisories related to sendmail.
END:: sendmail-faq//online/index/22
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/12
ENTRY:: March 23, 1996
TYPE:: Online general Internet email index
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: Internet Mail Consortium web site
CORP-AUTHOR:: Internet Mail Consortium
CONTACT:: <[email protected]>
OTHER_ACCESS:: URL:http://www.imc.org/
LANGUAGE:: English
ABSTRACT::
If it has to do with Internet email, you'll probably find it here or a link to it from here.
They have or have information on email-related Usenet FAQs, RFCs, Internet Drafts (documents that are in the process of becoming RFCs), IETF Working Groups, security standards, and are running a few email-related mailing lists.
Tends to be focussed on the standards issues.
If you care about Internet email, you should make it your duty in life to check this site frequently.
END:: sendmail-faq//online/index/12
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/13
ENTRY:: March 23, 1996
TYPE:: Online general Internet email index
REVISION:: August 20, 1996; Updated URL.
TITLE:: Email References
AUTHOR:: Wohler, Bill
CONTACT:: Bill Wohler <[email protected]>
OTHER_ACCESS:: URL:http://www.worldtalk.com/html/msg_resources/email_ref.html
LANGUAGE:: English
ABSTRACT::
The most exhaustive index site I know of for Internet email related documents outside of the Internet Mail Consortium.
Also has pointers to other organizations that relate to Internet email, such as the Electronic Messaging Association and the European Electronic Messaging Association.
Tends to be focussed on the server and standards issues.
END:: sendmail-faq//online/index/13
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/14
ENTRY:: March 23, 1996
TYPE:: Online general Internet email index
REVISION:: June 28, 1996; Added acronym for SMTPRD
TITLE:: SMTP Resources Directory (SMTPRD)
AUTHOR:: Salamon, Andras
AUTHOR:: Knowles, Brad
CONTACT:: Andras Salamon <[email protected]>
OTHER_ACCESS:: URL:http://www.dns.net/smtprd/
LANGUAGE:: English
ABSTRACT::
Another good index site, but still very much in the early phases of gestation. Based very heavily on the DNS Resources Directory, also by Andras Salamon.
A well-rounded site, for the amount of material it covers so far.
END:: sendmail-faq//online/index/14
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/index/15
ENTRY:: March 23, 1996
TYPE:: Online general Internet email index
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: E-Mail Web Resources
AUTHOR:: Wall, Matt
CONTACT:: Matt Wall <[email protected]>
OTHER_ACCESS:: URL:http://andrew2.andrew.cmu.edu/cyrus/email/email.html
LANGUAGE:: English
ABSTRACT::
Another good index site, tends to be more focussed on client side and LAN email packages. Also lists some email services, which no one else that I've seen appears to have taken the time to catalog.
Excellent side-by-side feature comparison of various MUAs and their compliance with various Internet protocols.
END:: sendmail-faq//online/index/15
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/tutorial/9
ENTRY:: March 23, 1996
TYPE:: Online sendmail tutorial
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
REVISION:: August 29, 1998; updated URL.
TITLE:: Sendmail V8: A (Smoother) Engine Powers Network Email
AUTHOR:: Reich, Richard
CONTACT:: Richard Reich <[email protected]>
DATE:: February 8, 1996
COPYRIGHT:: Copyright (c) 1995 The McGraw-Hill Companies, Inc.
All Rights Reserved.
OTHER_ACCESS:: URL:http://www.networkcomputing.com/unixworld/tutorial/
008/008.txt.html
LANGUAGE:: English
NOTES:: UnixWorld Online: Tutorial: Article No. 008
ABSTRACT::
Good technical introduction. Some useful references. Notably does not reference this FAQ as a place to get more information.
END:: sendmail-faq//online/article/9
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/tutorial/16
ENTRY:: March 23, 1996
TYPE:: Online sendmail tutorial
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: Sendmail -- Care and Feeding
AUTHOR:: Quinton, Reg
CONTACT:: Reg Quinton <[email protected]>
Computing and Communications Services
The University of Western Ontario
London, Ontario N6A 5B7
Canada
DATE:: March 24, 1992
OTHER_ACCESS:: URL:ftp://ftp.sterling.com/mail/sendmail/uwo-course/
sendmail.txt.Z
LANGUAGE:: English
NOTES:: Postscript version also available. See ftp://ftp.sterling.com/
mail/sendmail/uwo-course/sendmail.ps.Z
ABSTRACT::
Dated. Only here until I find better.
END:: sendmail-faq//online/tutorial/16
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/tutorial/21
ENTRY:: March 27, 1996
TYPE:: Online sendmail tutorial
REVISION:: August 29, 1998; updated URL.
TITLE:: Explosion in a Punctuation Factory
AUTHOR:: Bryan Costales
CONTACT:: Becca Thomas <[email protected]>
DATE:: January 1994
COPYRIGHT:: Copyright (c) 1995 The McGraw-Hill Companies, Inc.
All Rights Reserved.
OTHER_ACCESS:: URL:http://www.networkcomputing.com/unixworld/tutorial/
01/01.txt.html
LANGUAGE:: English
ABSTRACT::
Good introduction on how sendmail re-write rules work.
END:: sendmail-faq//online/article/21
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/archive/18
ENTRY:: March 25, 1996
TYPE:: Online Usenet newgroup archive
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: DejaNews
OTHER_ACCESS:: URL:http://www.dejanews.com
LANGUAGE:: English
NOTES:: Archives/indexes only Usenet news.
ABSTRACT::
The first, and still most focussed, Usenet news archive/index site. Others archive/index news as well as other things, but none that I've seen do it better.
Go to "Power Search" then "Query Filter" if you wish to restrict the newsgroups you search on to something like just comp.mail.sendmail and not all newsgroups.
END:: sendmail-faq//online/archive/18
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/archive/19
ENTRY:: March 25, 1996
TYPE:: Online Usenet newgroup archive
REVISION:: March 27, 1996; moved URL from RETRIEVAL field to
OTHER_ACCESS field.
TITLE:: AltaVista
OTHER_ACCESS:: URL:http://www.altavista.digital.com
LANGUAGE:: English
NOTES:: Archives/indexes Usenet news and World-wide web pages.
ABSTRACT::
One of the leading indexes of world-wide web pages, and their archive/index of Usenet news is obviously secondary.
END:: sendmail-faq//online/archive/19
BIB-VERSION:: CS-TR-v2.1
ID:: sendmail-faq//online/archive/20
ENTRY:: March 25, 1996
TYPE:: Online Usenet newgroup archive
REVISION:: April 8, 1997; Additional information based on experience
TITLE:: InReference
OTHER_ACCESS:: URL:http://www.reference.com
LANGUAGE:: English
ABSTRACT::
Had promise to be the best Usenet news/publicly accessible mailing list index/archive site in the world. The best minds that were working on the project have since left, and the difference is visible. You'll probably be happier with DejaNews instead.
END:: sendmail-faq//online/archive/20
Special thanks to:
| Eric Allman | The core of the material here comes from his FAQ for version 8.6.9 sendmail. I couldn't even have gotten started were it not for him. And if he hadn't written sendmail, there obviously wouldn't even be a FAQ. Heck, there might not even be an Internet. |
| Paul Southworth | Provides FAQ posting services, useful comments on various sections, and the mailclient-faq. I couldn't have kept doing this were it not for his help. |
| Ed Ravin | Virtually all the material regarding the use of sendmail on AIX is his, and most of it has been carried over verbatim. |
Thanks also to:
Neil Hoggarth, Andras Salamon, Johan Svensson, Christopher X. Candreva, Bill Wohler, Matthew Wall, Henry W. Farkas, Claus Assmann, Curt Sampson, Rebecca Lasher, Jim Davis, David Keegel, Betty Lee, Alain Durand, Walter Schweizer, Christophe Wolfhugel, Al Gilman, Valdis Kletnieks, John Gardiner Myers, Paul DuBois, Adam Bentley, Dave Sill, Dave Wreski, Paul Caloca, Eamonn Coleman, Michael Fuhr, Betty Lee, Derrell Lipman, Era Eriksson, Richard Troxel, and the readers and posters of comp.mail.sendmail.
Популярность: 1, Last-modified: Thu, 10 Sep 1998 11:47:36 GmT