The following list of questions and answers represent some of the most common issues which have arisen on the mailhelp mailing list.
In this section we will answer questions which are specifically related to sendmail.
1.1. I'm a newbie Linux user and I'm trying to read up on sendmail. Where is the local documentation?
I thought you'd never ask... According to the Filesystem Hierarchy Standard all architecture-independent data should be located in /usr/share and the /usr/share/doc/ directory should contain miscellaneous documentation (such as the sendmail documentation you are looking for). Now, if all the vendors were FHS compliant you would surely find what you're looking for in /usr/share/doc/sendmail/. But the vendors are not compliant so in all likelihood it won't be there. So my recommendation is to have a look under /usr and see what's there because you will find it in there somewhere. Red Hat users will find the docs here:
Example 3-1. Red Hat sendmail `doc' locations
/usr/doc/sendmail/README.cf (NEW SENDMAIL CONFIGURATION FILES) /usr/doc/sendmail/doc/changes/changes.ps (Changes in Sendmail Version 8) /usr/doc/sendmail/doc/intro/intro.ps (An Internetwork Mail Router) /usr/doc/sendmail/doc/op/op.ps (Sendmail Installation and Operation Guide) /usr/doc/sendmail/doc/usenix/usenix.ps (Mail Systems and Addressing) |
You will notice that some of these files have the `.ps' file extension. This means that they are postscript files. In all likelihood you have a postscript viewer already installed on your system. It's called Ghostview (gv) so to view these files you would need to be in X and then in an xterm you would type:
Example 3-2. Viewing the Documentation
gv /usr/doc/sendmail/doc/changes.ps & |
Just adjust your path accordingly to read the rest of the files. You could also print them out so as to have them available for reference. The file /usr/doc/sendmail/README.cf is a plain text file so you could view it by typing less /usr/doc/sendmail/README.cf.
If you are using an RPM based system and you do not have these documents you are missing an RPM (sendmail-doc). Get it and install it to get your documentation!
1.2. My sendmail install works fine locally but mail I send to internet addresses is being rejected by some places. Why?
This question has been asked and answered so many, many times on the mailhelp list that I believe we are now one of the net's premier resources for information about how to do it and why it should be done. The first HOWTO we ever wrote for mailhelp dealt with this issue and it continues to be the biggest problem we see. Once you overcome it you will know a lot more about sendmail and how to configure it than you ever did before!
In order to fix the problem you will have to configure your sendmail installation to masquerade the envelope and set it to relay through your ISP's mail host. That's the simple answer but doing it is a bit more complicated so read on.
Lets set the stage with a scenario:
"I have just installed Linux for the first time and after fighting through the problems I had getting the dialer to connect to my ISP I've started to send mail using sendmail. The trouble is that I keep messages that bounce back from many of the places I'm sending mail to with an error message which says something about `relaying denied'. Why is this happening to me and what can I do to fix it?"
In many ways electronic mail is similiar to postal mail. When you address a letter you write down your name and address and also the name and address of the intended recipient. Because you do it this way if the letter can't be delivered it can be safely returned to you. So after you put the letter in the mailbox the postal service picks it up and attempts to deliver it based on the information you wrote on the envelope. Now if you wrote down the wrong recipient address the delivery would fail and if you wrote down the wrong return address (or a false one) returning the message would be impossible also. But in both these instances the postoffice is handling the mail, not you. When you write down the addresses it's done locally but the postoffice handles it after the letter leaves your possession. But what if the postoffice was asked to deliver the mail *to* an entity which was not offically empowered to deliver the mail? What if the postoffice was asked to accept mail inbound from an agency which was not legally empowered to deliver the mail? With email this will not work. But why?
In the case of the postoffice we've been discussing lets now relate the analogy to Mail Transfer Agents (MTA's or sendmail in this case).
When you send mail with an MTA it creates the envelope address by concatenating the hostname with the domain name. So you end up with:
host "+" domain "+" toplevel
Then it adds the username prepended with the "@" symbol for the envelope sender. But it's important to understand that this has nothing to do with what you put in the From: or the Reply-To: in your mail client. Lets consider the headers from a message being read with pine (an MUA or Mail User Agent see Pine Information Center):
Example 3-3. The Envelope Is In The Headers
Return-Path: <owner-mailhelp-outgoing@moongroup.com>
Delivered-To: chuck@[10.0.0.50]
Received: from ns.moongroup.org (ns.moongroup.org [10.0.0.6])
by boss.moongroup.org (Postfix) with ESMTP id 03302BD6C
for <chuck@[10.0.0.50]>; Fri, 10 Dec 1999 08:48:20 -0500 (EST)
Received: by ns.moongroup.org (Postfix)
id 414DE191C; Fri, 10 Dec 1999 08:57:17 -0500 (EST)
Delivered-To: chuck@[12.4.13.46]
Received: from server.moongroup.com (server.moongroup.com [216.228.98.22])
by ns.moongroup.org (Postfix) with ESMTP id 72EFC191D
for <chuck@[12.4.13.46]>; Fri, 10 Dec 1999 08:57:16 -0500 (EST)
Received: by server.moongroup.com (Postfix)
id 24FEE1A803; Fri, 10 Dec 1999 08:48:16 -0500 (EST)
Delivered-To: chuck@moongroup.com
Received: by server.moongroup.com (Postfix, from userid 91)
id E778B1A804; Fri, 10 Dec 1999 08:48:15 -0500 (EST)
Delivered-To: mailhelp@moongroup.com
Date: Fri, 10 Dec 1999 08:48:13 -0500 (EST)
From: Charles <chas@somwhere.com>
X-Sender: chas@pooh.ltab.com
To: mailhelp@moongroup.com
Subject: Re: colour in pine
In-Reply-To: <Pine.LNX.4.21.9912092125370.7245-100000@pooh.ltab.com>
Message-ID: <Pine.LNX.4.21.9912100845220.19664-100000@pooh.ltab.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-mailhelp@moongroup.com
Precedence: bulk
Reply-To: mailhelp@moongroup.com
X-envelope-from: Charles <chas@somwhere.com> |
This message was resent by the listserv at MoonGroup (majordomo actually) and it's a good example because it demonstrates how envelopes work and the fact that there is a potential difference between "senders" and "envelope senders". Because of the nature of mailing lists this message is actually resent but if you look at it you see that the X-Sender: is "chas@pooh.ltab.com" but the X-envelope-from: address is "Charles <chas@somwhere.com>". These adresses are important. The X-Sender identifies the user account and host from which the original message was sent and the X-envelope-from: identifies the the envelope address of the sender. In short, the X-envelope-from: address would work as a Reply-To: address and the X-Sender: would not. This implies that the original sender is masquerading to get a valid envelope setup for their outgoing traffic. If they didn't do this then the envelope would contain the X-Sender as the envelope address. This is not so good in most cases as the host used by the X-Sender is likely to be behind a firewall or on a dynamic dial-up somewhere so that mail returned to it probably won't route. But why?
It won't route because the envelope was never adjusted to reflect the correct reply-to address so it points at a host which cannot be found via reverse DNS or hostname resolution.
What's happened is that as spam has become more and more prevalent the people who develop Mail Transfer Agents (e.g. sendmail, postfix, exim, qmail) have begun to write code with more stringent requirements. These improved MTA's now check that the sender's envelope address is valid everytime they receive inbound mail regardless of whether it's a local delivery, or a relay. This means, in part, that the concatenation of the users name, the "@" symbol, and the domain or host and domain must be used as the envelope sender address and everything on the right hand side of the "@" symbol must exist and be verifiable via reverse DNS. But it's really more stringent than that because the receiving MTA is actually looking at the transmitting host and verifying it as well! If the transmitting host does not resolve in reverse (in other words it must be a legitimate host with a DNS record) then the mail will bounce.
This is a good thing but it's causing problems for lots of people, particularly those who use an MTA rather than client software to send mail. In other words, a Linux user with an internet connection that uses a dynamic IP address is likely to get a bunch of bounced mail unless their MTA is configured to properly masquerade the envelope.
It's not enough to set the from and reply-to addresses in a piece of email client software because much like a regular letter all this does is tell the person who receives the message who it's from (maybe!). The newer versions of sendmail (particularly 8.9.x) are more concerned with which mail server it was sent from than they are with which user sent the message so they read the message envelope. They're not looking for the person that sent it by checking the senders From: or Reply-To: email address, they're checking to see if the "post office" or mail server it came from is valid! Which is equivalent to checking the zip code of origin on a letter. Once this information is excerpted from the message it's verified via reverse DNS to see if the sending post office exists in DNS (in other words would the sending MTA receive a bounce if the intended recipient didn't exist) and if that post office (the sending MTA) doesn't exist in DNS the receiving MTA will reject the message with prejudice! So we fix this by telling our MTA to masquerade the envelope and relay through our providers SMTP host.
Tip: For this section we're assuming a complete install of sendmail (this works with versions from 8.8.7 through 8.9.3). If you're using an RPM based system make sure you've installed the sendmail RPM and the sendmail-cf RPM at a minimum. All commands must be issued as the root user.
Example 3-4. Where is sendmail's config stuff?
cd /usr/lib/sendmail-cf/cf/
|
Tip: if you don't have this directory and it doesn't show up in an alternate path after you've searched for it then our assumptions about a full install are incorrect and you have to get everything installed prior to proceeding! Everything in this case would mean the sendmail-cf RPM for your version.
Example 3-5. Creating and Editing a macro configuration file
cp myconfig.mc /usr/lib/sendmail-cf/cf/myconfig.mc.bakup vi myconfig.mc |
and insert the following text:
Example 3-6. sendmail.cf
divert(-1)dnl include(`../m4/cf.m4')dnl define(`confDEF_USER_ID',``8:12'')dnl define(`SMART_HOST', `your.isps.mta')dnl dnl In the line above be sure and reset your.isps.mta to the dnl correct name for your ISP's outgoing (SMTP) mailhost. OSTYPE(`linux')dnl undefine(`UUCP_RELAY')dnl undefine(`BITNET_RELAY')dnl FEATURE(redirect)dnl FEATURE(always_add_domain)dnl FEATURE(use_cw_file)dnl FEATURE(local_procmail)dnl FEATURE(nouucp)dnl MAILER(procmail)dnl MAILER(smtp)dnl MASQUERADE_AS(yourdomain.dom)dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl |
If you're using Red Hat all of this is in the original /usr/lib/sendmail-cf/cf/redhat.mc or the /etc/sendmail.mc with a couple of lines added for folks in your situation.
The next step in this process is that we have to have a legitimate relay host to make this work so be sure and use your ISP's MTA as a "smart" relay host. This would be inserted in place of "your.isps.mta" in the line which begins: define(`SMART_HOST'... so if your ISP's SMTP host was called "mail.yourisp.net" then your line would like this:
Example 3-7. The SMART_HOST Entry
define(`SMART_HOST', `mail.yourisp.net')dnl |
Now that we've created our myconfig.mc file we've got to create a new sendmail.cf ... but how do we do that?
First we need to save the old config file...
Example 3-8. Backing up the old config
mv /etc/sendmail.cf /etc/sendmail.cf.bakup |
(we're still in the same directory with our new .mc file)
Example 3-9. Running m4
m4 ../m4/cf.m4 myconfig.mc > nuconfig.cf |
if there are any error messages here it usually means that you're missing the sendmail-cf package or RPM.
Example 3-10. placing the new config
cp nuconfig.cf /etc/sendmail.cf |
Next we want to issue the command:
Example 3-11. Restart sendmail
/etc/rc.d/init.d/sendmail restart |
and that's it... we're done!
1.3. I am running sendmail which was installed with my Linux Distribution. I am getting an error when I send mail which says something about "mail loops back to me. MX error?". How do I fix this?
This is a very common error. Essentially what's happening is that sendmail is having an identity crisis because it doesn't know who it is but it can tell by looking at the DNS records that it should be receiving mail for your domain. All you have to do is add your domain name, your hostname, and all aliases or virtual domains you want to receive mail for into the file /etc/sendmail.cw or add them to class w in your sendmail.cf file.
Do not add any domains or hosts for which you are the secondary MX host into sendmail.cw or class w!
There are 3 RPMs required for a complete install. They are:
Example 3-12. Red Hat sendmail RPM list
sendmail sendmail-cf sendmail-doc |
In the first instance you've probably built sendmail from source and specified the option `NEWDB' at compile time. Then when you started building your configuration file you specified a db class of hash instead of dbm. Change all of the `hash' statements to dbm and you'll be fine.
In the second instance its likely that you use Linux and the version of sendmail you have is set up to use hash. Change all of the dbm statements to say hash and you should be fine.
Red Hat Linux users in particular run into this when using www.sendmail.org as a reference.
1.6. I'm trying to use majordomo to set up some mailing lists with sendmail but I keep having a problem and I'm getting an error message which says something about security and something else called smrsh. I'm using Red Hat Linux 6.x. How do I fix this?
Beginning with Red Hat 6.0 Red Hat's sendmail RPMs come preconfigured to use the sendmail restricted shell (smrsh). Quite simply what you will need to do is create a symlink in /etc/smrsh to the majordomo wrapper. The following command should handle the problem:
Example 3-13. Creating the Symbolic Link for the Wrapper
ln -s /usr/local/etc/majordomo-1.94.4/wrapper /etc/smrsh |
1.7. I am trying to setup a ~/.forward file for use with sendmail on Red Hat 6.x. I am getting an error that says "sh: procmail not available for sendmail programs". This used to work! What do I need to do to fix it?
The problem here is identical to that of the previous question. You need to create a symlink to the procmail binary in /etc/smrsh.
Example 3-14. Creating the Symbolic Link for procmail
ln -s /usr/bin/procmail /etc/smrsh |
In this section we will answer questions which are specifically related to postfix.
Postfix is an MTA. It is the creation of Wietse Venema (this is the same man who created tcp_wrappers). From experience I will tell you two things about it. It is easy to configure it. It is very, very fast. In fact, it will run very tight, concentric circles around sendmail and it won't even be breathing hard <grin>!! Trust me... the difference is extreme!
2.2. I want to replace my working sendmail installation with postfix as I've heard that postfix is a lot faster. Are there any pre-install issues I should be aware of?
Yes. Postfix and sendmail cannot coexist on the same system so prior to installing postfix you must uninstall sendmail. This is a problem for those using sendmail installed via RPM because when sendmail is uninstalled it can remove things that you need. Essentially, if you have modified any of the tables in /etc/mail or the /etc/aliases file you need to preserve these first. The post-uninstall portion of sendmail can wipe these files out and if you're using them they will work fine with postfix... so hang on to 'em! Back them up somewhere and then run rpm -e sendmail sendmail-cf sendmail-doc to wipe out your sendmail install.
One more thing... if you'd have a look at Postfix Configuration - Basics you could conceivably build your entire postfix config file prior to doing your install. If you're upgrading an in service machine this can save you a lot of time.
2.3. I'm running majordomo with sendmail. Are there any issues with running postfix and majordomo that I should be aware of prior to installing postfix?
Yes. There are two.
First, postfix does not like moderated lists. If it sees a message ID for the second time it thinks there is a routing loop with that message and it bounces it. You have to edit the majordomo perl code to fix it. Here's a URL which explains the issue: Postfix breaks the majordomo "approve" command.
Second, postfix is faster than the bulk_mailer script which comes with majordomo so you should change your majordomo aliases from this:
Example 3-15. Original Majordomo Aliases
mylist-outgoing: "|/usr/sbin/bulk_mailer mylist-owner@yourdomain.com //var/lib/majordomo/lists/mylist", mylist-archive |
to simple includes. Like this:
Example 3-16. Modified Majordomo Aliases
mylist-outgoing: ":include://var/lib/majordomo/lists/mylist", mylist-archive |
2.4. Because of SEC/FDIC regulations, my company is looking for a method to make a copy of every outgoing message from every user to a public folder. Can anyone give me some idea?
Using postfix it's easy. Add this entry to your /etc/postfix/main.cf:
Example 3-17. Making Copies of Oubound Mail
always_bcc = address@somewhere.dom |
Now you can do anything you want to with the mail.
2.5. I've installed postfix but I'm having trouble with it and I can't find any documentation. Where is it?
I thought you'd never ask... According to the Filesystem Hierarchy Standard Architecture-independent data should be located in /usr/share and the /usr/share/doc/ directory should contain Miscellaneous Documentation (such as the postfix documentation you are looking for). Now, if all the vendors were FHS compliant you would surely find what you're looking for in /usr/share/doc/postfix/. But the vendors are not compliant so in all likelihood it won't be there. So my recommendation is to have a look under /usr and see what's there because you will find it in there somewhere. Red Hat users will find the docs here:
Example 3-18. Red Hat Postfix Doc's
[chuck@boss postfix-19991126]$ pwd /usr/doc/postfix-19991126 [chuck@boss postfix-19991126]$ ls 0README LICENSE ULTRIX_README master.cf sample-ldap.cf sample-rewrite.cf BEWARE MYSQL_README UUCP_README postfix-script sample-local.cf sample-smtp.cf COMPATIBILITY PCRE_README access postfix-script-nosgid sample-misc.cf sample-smtpd.cf DEBUG_README PORTING aliases postfix-script-sgid sample-pcre.cf sample-transport.cf HISTORY README_maildrop_security.txt canonical relocated sample-rate.cf sample-virtual.cf INSTALL README_rpm.txt html sample-aliases.cf sample-regexp.cf transport INSTALL.sh RELEASE_NOTES main.cf sample-canonical.cf sample-relocated.cf virtual LDAP_README TODO main.cf.default sample-debug.cf sample-resource.cf |
The previous question and answer just above would be helpful for local documentation but if you have internet access you could look here: Wietse's Postfix Project (Unofficial Mirror) or here: Wietse's Postfix Project (Merit Mirror) for that information. Wietse's documentation is generally very good and he keeps it up to date as well.
This is covered pretty well in the postfix FAQ at: Postfix Frequently Asked Questions but we'll take a moment and deal with it here.
It's really a combination of references which will get you where you want to go. Here are the relevant entries from the postfix FAQ and web site:
Example 3-19. Running Postfix on a dialup machine
Route all outgoing mail to your provider.
If your machine is disconnected most of the time, there isn't a
lot of opportunity for Postfix to deliver mail to hard-to-reach
corners of the Internet. It's better to drop the mail to a
machine that is connected all the time.
/etc/postfix/main.cf:
relayhost = smtprelay.someprovider.com
Disable spontaneous SMTP mail delivery (on-demand dialup IP only).
Normally, Postfix attempts to deliver outbound mail at its
convenience. If your machine uses on-demand dialup IP, this
causes your system to place a telephone call whenever you submit
new mail, and whenever Postfix retries to deliver delayed
mail. To prevent such telephone calls from being placed, disable
spontaneous SMTP mail deliveries.
/etc/postfix/main.cf:
defer_transports = smtp (Only for systems that use on-demand dialup IP)
Disable SMTP client DNS lookups (dialup LAN only).
Some people use Postfix to deliver mail across a LAN that is
disconnected most of the time. Under such conditions, mail
delivery can suffer from delays while the Postfix SMTP client
performs sender and recipient domain DNS lookups in order to be
standards-compliant. To prevent these delays, disable all SMTP
client DNS lookups.
/etc/postfix/main.cf:
disable_dns_lookups = yes (Only for
delivery across LANs that are disconnected most of the
time)
When you disable DNS lookups, you must specify the relayhost as
either a numeric IP address, or as a hostname that resolves to
one or more IP addresses (with DNS lookup disabled, Postfix does
no MX lookup).
Flush the mail queue whenever the Internet link is established.
Put the following command into your PPP or SLIP dialup scripts:
/usr/sbin/sendmail -q (whenever the Internet link is up)
The exact location of the sendmail command is
system-specific. With some UNIX versions, use /usr/lib/sendmail.
In order to find out if the mail queue is flushed, use something like:
#!/bin/sh
# Start deliveries.
/usr/sbin/sendmail -q
# Allow deliveries to start.
sleep 10
# Loop until all messages have been tried at least once.
while mailq | grep '^[^ ]*\*' >/dev/null
do
sleep 10
done
If you have disabled spontaneous SMTP mail delivery, you also
need to run the above command every now and then while the dialup
link is up, so that newly-posted mail is flushed from the
queue. |
Example 3-20. Address masquerading
Address masquerading is a method to hide all hosts below a domain
behind their mail gateway, and to make it appear as if the mail comes
from the gateway itself, instead of from individual machines.
Address masquerading is disabled by default. To enable, edit the
masquerade_domains parameter in the main.cf file and specify one or
more domain names separated by whitespace or commas. For example:
masquerade_domains = $mydomain
In this example, addresses of the form user@host.$mydomain would be
rewritten to user@$mydomain.
The masquerade_exceptions configuration parameter specifies what user
names should not be subjected to address masquerading. Specify one or
more user names separated by whitespace or commas. For example,
masquerade_exceptions = root
By default, Postfix makes no exceptions.
Subtle point: address masquerading is applied only to message headers
and envelope sender addresses, not to envelope recipients. |
This next section may, or may not be essential. In my case it's required as I have a very "sticky" hostname that insists on appearing in the address. The trouble with that is that this host name will not route so I have to get rid of it for outbound mail.
Example 3-21. Canonical address mapping
Before the cleanup daemon stores inbound mail into the incoming queue,
it uses the canonical table to rewrite all addresses in message
envelopes and in message headers, local or remote. The mapping is
useful to replace login names by Firstname.Lastname style addresses,
or to clean up invalid domains in mail addresses produced by legacy
mail systems.
Canonical mapping is disabled by default. To enable, edit the
canonical_maps parameter in the main.cf file and specify one or more
lookup tables, separated by whitespace or commas. For example:
canonical_maps = hash:/etc/postfix/canonical
In addition to the canonical maps which are applied to both sender and
recipient addresses, you can specify canonical maps that are applied
only to sender addresses or to recipient addresses. For example:
sender_canonical_maps = hash:/etc/postfix/sender_canonical
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
The sender and recipient canonical maps are applied before the common
canonical maps.
Sender-specific rewriting is useful when you want to rewrite ugly
sender addresses to pretty ones, and still want to be able to send
mail to the those ugly address without creating a mailer loop. |
If you have a LAN where you need to deliver some mail locally and some needs to route to the world this next session will also help:
Example 3-22. Delivering some users locally while sending mail as user@domain
In order to send mail as user@domain, edit /etc/postfix/main.cf and
specify what domain is to be appended to addresses that do not have a
domain:
myorigin = domain
In order to receive some users locally, such as root or postmaster,
edit /etc/postfix/main.cf and specify a virtual lookup table:
virtual_maps = hash:/etc/postfix/virtual
edit /etc/postfix/virtual and specify non-default destinations:
root root@localhost
postmaster postmaster@localhost
Execute the command postmap /etc/postfix/virtual to update the
table, and postfix reload to make the changes effective. |
2.8. I installed postfix on my dial-up box and it works fine. As mentioned in the FAQ I usually do a sendmail -q in my ppp script to flush the queue, but when I'm on-line for four hours I have to manually flush the queue. Is there a way to automate this?
Yes there is. Try the following:
Example 3-23. Additions for the ppp connect script
With newer Postfix snapshots, use the following:
link up:
postconf -e defer_transports=
postfix reload
sleep 1
sendmail -q
link down:
postconf -e defer_transports=smtp
postfix reload |
In this section we will cover questions about information which is not specifically related to sendmail or postfix.
If you're using procmail as your MDA you have the documentation on your system. Do man procmailex and then search for autoreply (type: /autoreply). You will see:
Example 3-24. man procmailex
A simple autoreply recipe. It makes sure that neither mail
from any daemon (like bouncing mail or mail from mailing-
lists), nor autoreplies coming from yourself will be
autoreplied to. If this precaution would not be taken,
disaster could result (`ringing' mail). In order for this
recipe to autoreply to all the incoming mail, you should of
course insert it before all other recipes in your rcfile.
However, it is advisable to put it after any recipes that
process the mails from subscribed mailinglists; it generally is
not a good idea to generate autoreplies to mailinglists (yes,
the !^FROM_DAEMON regexp should already catch those, but if the
mailinglist doesn't follow accepted conventions, this might not
be enough).
:0 h c
* !^FROM_DAEMON
* !^X-Loop: your@own.mail.address
| (formail -r -I"Precedence: junk" \
-A"X-Loop: your@own.mail.address" ; \
echo "Mail received.") | $SENDMAIL -t
A more complicated autoreply recipe that implements the
functional equivalent of the well known vacation(1) program.
This recipe is based on the same principles as the last one
(prevent `ringing' mail). In addition to that however, it
maintains a vacation database by extracting the name of the
sender and inserting it in the vacation.cache file if the name
was new (the vacation.cache file is maintained by formail which
will make sure that it always contains the most recent names,
the size of the file is limited to a maximum of aproximately
8192 bytes). If the name was new, an autoreply will be sent.
As you can see, the following recipe has comments between the
conditions. This is allowed. Do not put comments on the same
line as a condition though.
SHELL=/bin/sh # for other shells, this might need adjustment
:0 Whc: vacation.lock
# Perform a quick check to see if the mail was addressed to us
* $^To:.*\<$\LOGNAME\>
# Don't reply to daemons and mailinglists
* !^FROM_DAEMON
# Mail loops are evil
* !^X-Loop: your@own.mail.address
| formail -rD 8192 vacation.cache
:0 ehc # if the name was not in the cache
| (formail -rI"Precedence: junk" \
-A"X-Loop: your@own.mail.address" ; \
echo "I received your mail,"; \
echo "but I won't be back until Monday."; \
echo "-- "; cat $HOME/.signature \
) | $SENDMAIL -oi -t |
If you're going to do this without using a mail client, fetchmail is for you! Fetchmail is a mail-retrieval and forwarding utility; it fetches mail from remote mailservers and forwards it to your local (client) machine's delivery system. You can then handle the retrieved mail using normal mail user agents such as elm(1) or Mail(1). The fetchmail utility can be run in a daemon mode to repeatedly poll one or more systems at a specified interval.
The fetchmail program can gather mail from servers supporting any of the common mail-retrieval protocols: POP2, POP3, IMAP2bis, and IMAP4. It can also use the ESMTP ETRN extension.
While fetchmail is primarily intended to be used over on-demand TCP/IP links (such as SLIP or PPP connections), it may also be useful as a message transfer agent for sites which refuse for security reasons to permit (sender-initiated) SMTP transactions with sendmail.
As each message is retrieved fetchmail normally delivers it via SMTP to port 25 on the machine it is running on (localhost), just as though it were being passed in over a normal TCP/IP link. The mail will then be delivered locally via your system's MDA (Mail Delivery Agent, usually sendmail(8) but your system may use a different one such as smail, mmdf, or qmail). All the delivery-control mechanisms (such as ~/.forward files) normally available through your system MDA and local delivery agents will therefore work.
The behavior of fetchmail is controlled by command-line options and a run control file, ~/.fetchmailrc, the syntax of which we describe below. Command-line options override ~/.fetchmailrc declarations.
Each server name that you specify following the options on the command line will be queried. If you don't specify any servers on the command line, each server in your ~/.fetchmailrc file will be queried.
Example 3-25. ~/.fetchmailrc samples
poll your.mailserver.com proto pop3 user someone is you here password $password poll mail.worldnet.att.net proto pop3 user randy.smith is randy here password DRhcuTn |
This same type of rc file can be used for multiple users and run in daemon mode as root or from root's crontab. The key is the part where it says "user so-and-so is otheruser here". This tells fetchmail who gets the mail and it, in turn, notifies your MTA!
Fetchmail can be run from the command line by simply typing fetchmail as a user (Note: this assumes you've created a valid ~/.fetchmailrc file).
Fetchmail can also be run in daemon mode:
Example 3-26. fetchmail daemon mode syntax
fetchmail -d xxx (where xxx= the number of seconds between polls) |
I personally run it as a cronjob:
Example 3-27. fetchmail cron command
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,54,57 0-23 * * * fetchmail -f /home/chuck/.fetchmailrc > /dev/null 2>&1 |
3.3. I have a valid domain name but I don't have a dedicated connection. How can I force queued mail to download from my provider's mailserver to mine?
There are a couple of alternative solutions for this but both require the use of ETRN and a static IP address.
Sendmail comes with a perl script called etrn.pl. If you're a Red Hat Linux user the sendmail RPMs included do not contain the ETRN script. If you built sendmail from source code it is included but in any case you can get it from the link above.
ETRN can also be accomplished successfully using fetchmail. The fetchmail man page describes the process but it's not very clear so here's a simple set of instructions:
Example 3-28. ETRN with fetchmail
poll your.providers-mail-server.net proto ETRN |
This text can be inserted into a ~/.fetchmailrc file. Be sure and set the ~/.fetchmailrc file's permissions to 0710 (chmod 0710 ~/.fetchmailrc) before you run it but if you forget to it will let you know about it.
After you've created the file you may run it like this:
Example 3-29. Sample ETRN Run
[chuck@boss chuck]$ fetchmail -v fetchmail: 5.1.0 querying server.moongroup.com (protocol ETRN) at Sun, 12 Dec 1999 00:21:26 -0500 (EST) fetchmail: SMTP< 220 server.moongroup.com ESMTP Postfix (Postfix-19990906-pl07) fetchmail: SMTP> EHLO boss.moongroup.org fetchmail: SMTP< 250-server.moongroup.com fetchmail: SMTP< 250-PIPELINING fetchmail: SMTP< 250-SIZE 10240000 fetchmail: SMTP< 250-ETRN fetchmail: SMTP< 250 8BITMIME fetchmail: ETRN> ETRN boss.moongroup.org fetchmail: ETRN< 250 Queuing started fetchmail: Queuing for boss.moongroup.org started fetchmail: Polling server.moongroup.com fetchmail: ETRN> QUIT fetchmail: SMTP< 221 Bye fetchmail: normal termination, status 0 [chuck@boss chuck]$ |
As you can see by the second line the MoonGroup mail server is running postfix (an excellent ESMTP capable MTA). ETRN works just fine with it.
3.4. I have sendmail up and working just fine on a Red Hat 6.x server but my users can't get their mail. POP3 does not appear to be working but the line in /etc/inetd.conf appears to be correct and the service is correctly referenced in /etc/services. What do I need to do?
You probably did a default install of some type and the IMAP RPM was not installed. Do not be thrown by the name. The IMAP RPM contains both imapd and ipop3d. Here's what to do:
Example 3-30. Installing the missing imap rpm
Insert your distribution CDROM. mount /mnt/cdrom rpm -Uvh /mnt/cdrom/RedHat/RPMS/imap-4.5-4.i386.rpm /etc/rc.d/init.d/inet restart |
If your inetd.conf is correct as you say then the problem is now fixed.
3.5. I am getting an error with my pop daemon. My users are having trouble retrieving their mail via POP3. The users see a "connection denied" message, and the messages log on the mailserver has entries like this:
inetd[404]: pop-3/tcp server failing (looping), service terminated
What can I do to fix it?
This is fairly common. Your pop daemon is running under tcp_wrappers which is configured using /etc/inetd.conf. There are two possible fixes for the problem.
First you can increase the connections per minute allowed to the pop daemon by editing /etc/inetd.conf. Here's the line you should be looking at:
Example 3-31. Sample inetd.conf
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d |
Change it to look like this:
Example 3-32. Edited inetd.conf
pop-3 stream tcp nowait.100 root /usr/sbin/tcpd ipop3d |
If the error continues then increase the value appended to the nowait statement. When this setting is omitted the maximum value by default is 40. The number refers to the maximum number of server instances that may be spawned from inetd within an interval of 60 seconds. See man inetd.conf for more information.
The same issue sometimes arises with the ident daemon and unless it runs as a stand alone it can be fixed in the same way.
The second way to fix this is to change the pop3 daemon itself. Red Hat Linux versions through release 6.1 all use the UW IMAP and ipop3d daemons installed via a single RPM. There is a better alternative for high volume sites called gnu-pop3d. It is written by Jakob 'sparky' Kaivo <jkaivo@nodomainname.net>. There is a src.rpm for gnu-pop3d available at ftp://ftp.moongroup.com/pub/gnu-pop/ or you can get it from its home site at http://www.nodomainname.net/software/gnu-pop3d/.
3.6. "Look... I've just installed Linux and I've subscribed to at least a half dozen mailing lists and I'm thinking this will help me learn it a little faster... the only trouble is having all that mail in my Inbox all mashed up together is killing me trying to sort it all out... what can I do about it?"
This is a perfect job for procmail! A complete treatment of procmail would take a month of classes and one of those 500 page O'Reilly books... but what we can do is give you a good example and point you at the Procmail FAQ.