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
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ||||
11 | 12 | 14 | 15 | 16 | 17 | 18 | 19 | 21 | 22 | ||||
23 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 37 | 38 | ||||
39 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 |