|
|
The Answer Guy 37: 'procmail' to Get Mail via POP-3? No. 'fetchmail'
"The Linux Gazette...making Linux just a little more fun!"
'procmail' to Get Mail via POP-3? No. 'fetchmail'
From ehalm on Mon, 28 Dec 1998
Hi,
Looking for ways to get my mail from my POP3 account on my
ISP and deliver it locally.
Thanks,
Ebow Halm
In your subject you list 'procmail' --- that is probably not
the right tool for this job.
The normal way to get your mail from your ISP (or any POP
server) to your system is to use a mail user agent such as
Netscape Communicator that directly uses this protocol.
However, there's another way that's useful if you use 'elm'
or 'pine' (or MH as I do). You can use any of several
programs that fetch the mail from a remote POP or IMAP
server and store it in your "inbox" (usually something like
/var/spool/mail/$USERNAME). Currently Eric S. Raymond's
'fetchmail' is the most popular utility for this purpose.
There are others with names like 'getpop' and 'popmail'
--- some are simple PERL scripts.
One minor complaint I have about 'fetchmail' is
that it really wants to relay the mail it fetches
through the local mail daemon (usually 'sendmail')
--- so that it can apply any local aliasing and filtering
rules to it.
Since I like to centralize my mail on one server --- and
prevent mail daemons from running on the client workstations
and other servers on my LANs --- I need to bypass this.
The easiest way is to invoke 'fetchmail' with some extra
parameters to force it to pipe the messages through
my preferred delivery agent (procmail). So I use a
command like:
fetchmail -m "/usr/bin/procmail -f - "
... note: this is only appropriate for fetching mail
for a single user. Some ISP's will spool mail for an
entire client domain into a single "mbox" file (this is
one method of "virtual hosting" mail). They expect the
client to split the mail back into the users within that
domain to whom it is addressed.
ISP's that want to do this correctly will add an additional
header to each incoming message --- usually called
"X-Envelope-To:" One way to do this is documented at:
http://www.sendmail.org/faq/section3.html#3.29
... in the ' sendmail 'FAQ (it uses procmail).
I've seen references to another method that just uses
a line like:
H?P?X-Envelope-To: $u
... or
H?P?X-Envelope-To: $g
... to your sendmail.cf file (near the top) --- or to
your .mc file where it will be passed into your .cf file
by m4.
There's a whole section on these "multidrop mailboxes"
in the 'fetchmail' man pages.
Insteat of using the fetchmail -m (MDA) option I've
also occasionally resorted to a different technique
--- where I define a line in my /etc/inetd.conf like:
smtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sendmail -bs
... and lines in /etc/hosts.allow and /etc/hosts.deny like:
# hosts.allow
smtp: 127.0.0.1
... and:
# hosts.deny
ALL: ALL
... or at least:
# hosts.deny
smtp: ALL
This allows me to configure sendmail (or another SMTP
daemon) to be dynamically loaded --- but only for
connections by the "localhost" (throught the loopback
interface). The main reason I use this is that some
of the MUA's (mail user agents) seem to wont to deliver
mail to the local SMTP daemon as well. In particular
the mail sending utility in MH seems to demand it.
Granted, most people are somewhat sloppier about their
system configuration. They let 'sendmail' (or 'qmail'
or some other SMTP daemon) just run on all of their
Unix systems --- including workstations that only ever
have a single user logged into them. I think it's a bad
idea --- unnecessary and possibly a security risk.
('sendmail' has improved immensely over the last couple
of years --- but that doesn't mean we should for get that
it was a favorite target of crackers for over twenty years
--- and that we should assume that some new package like
'qmail' or Wietse Venema's new PostFix doesn't have some,
as yet undiscovered bug).
Incidentally --- another, more hackish, way of getting
your mail would be to have some script that ftp'd or
otherwise copied your remote "mbox" (inbox) file to your
system (performing the necessary locking!) and then
fed it through the 'procmail -f' command to process
it accoding to your filters (and feed the resulting
messages into your local mbox/inbox or other folders).
One advantage of 'fetchmail' is that is supports
a wide variety of advanced authentication options. For
more info on 'fetchmail' go to ESR's web page for it:
http://www.ccil.org/~esr/fetchmail
Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 37 February 1999
|