This is technically no longer a "procmail" question, since the answer I
received on my last question pointed me to using "fetchmail"... However,
it is related (since I have the feeling that a procmail command may be the
solution to the sendmail queueing problem I will describe below--a
solution I tried for 2 hours to implement properly but was unable to)...
I may be making progress on this, but with this new system mail is not
going where it is supposed to go when it is supposed to go there.
If I have this in my /root/.fetchmailrc file:
poll pop.mindspring.com proto pop3
user user1 there with pass pass1 is user1 here
user user2 there with pass pass2 is user2 here
(...etc..)
I have a problem with the mail queueing, because sendmail is set to
automatically queue all messages. Normally this does not affect
locally-addressed messages, but I guess these messages in particular are
not considered "local" because they came from somewhere else. So they sit
in the queue after they are fetched.
Now my ip-up entry is now:
sendmail -q
fetchmail
Unless I add another sendmail -q to the bottom (to send to local users the
messages that were just retrieved) it could be up to 6 hours before local
users can view their mail (up to 3 hours from the time they send it to
when I receive it, then 3 more hours until sendmail is run again).
That is obviously the "quick fix" solution of choice. Does anyone know of
a more elegant way for sendmail to handle this, though? I'd much
rather have an "mda" line in my .fetmailrc file to use procmail and
avoid sendmail as the mail delivery agent... but every variation I
try fails with some sort of parsing error when I try to force each
user's mail to be processed through his/her own .procmailrc.
Thank you!
Eliot
On Fri, 31 Jan 1997, Stephane Bortzmeyer wrote:
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.