On Thursday 30 January 97, at 23 h 35, the keyboard of Eliot
Sabath-Levitt <eslevitt(_at_)mindspring(_dot_)com> wrote:
/usr/sbin/sendmail -q
/usr/bin/popclient -3 -s -u user1 -p password1 -c pop.mindspring.com |
formail -s procmail -d user1
One day, I swear, I'll write a FAQ about that matter. This comes on the
procmail list every week...
(1) Have I, in principle, done something horribly wrong with this master
cron scheme? Like, God forbid, blasting a huge hole in my security? (I'm
There is a huge hole in popclient. It never tests the results of the
system calls or library routines before deleting mail on the POP server.
If your disk is full, you lose mail without warning. Drop that s..t and
use a good POP client (fetchmail seems the most widely used):
gwpop : <ftp://ftp.pasteur.fr/pub/Network/gwpop> or
<ftp://ftp.std.com/pub/mal/gwpop>
popc : <ftp://ftp.imag.fr/pub/Linux/net>
popmail : <ftp://ftp.cic.net/pub/Software/unix/mail>
fetchpop : <SUNSITE>/system/Mail/pop
getmail : <SUNSITE>/system/Mail/pop
pimp : <SUNSITE>/system/Mail/pop
pop-perl5 : <SUNSITE>/system/Mail/pop
fetchmail : ftp://ftp.ccil.org/pub/esr/
aware of the inherent security problem of putting passwords on command
lines as above, as anyone logged on to my system could run a "ps" and see
everything. I don't know how to fix that particular problem, though.)
Some POP clients can find the password from a file (I believe fetchmail
can do that). Still unsecure, but not so. Some POP clients erase the
command line (gwpop does it). It doesn't work on some Unix (Solaris) and
it leaves a small vulnerability window, but it's better than nothing.
(4) Is this more or less how procmail is supposed to work, or is there
anything about this that will die horribly under a high message load...?
fetchmail or gwpop (or others) can call procmail by theirselves.