running procmail on the contents of /var/mail/$USER

[Tim Writer]

"Peter L. Peres" <plp-ysDPMY98cNQDDBjDh4tngg at public.gmane.org> writes:

> > Anyway, I don't see anything wrong with William's syntax.  There's no
> > requirement to specify an rc file with procmail, if you don't it will just
> > use your ~/.procmailrc.  In other words, William's syntax was equivalent to:
> >
> >    formail -ds procmail ~/.procmailrc < /var/mail/$USER
> 
> You CAN'T run that command, ever.

Did you try it?  I did:

    tim at newsol% grep '^From ' /var/mail/$USER
    From XXX  Thu Jul 29 14:46:15 2004
    tim at newsol% cp /var/mail/$USER mbox.bak
    tim at newsol% formail -ds procmail ~/.procmailrc < /var/mail/$USER
    tim at newsol% tail -3 ~/.procmail/log
    From XXX  Thu Jul 29 14:46:15 2004
     Subject: XXX
      Folder: /var/spool/mail/tim
    tim at newsol% grep '^From ' /var/mail/$USER
    From XXX  Thu Jul 29 14:46:15 2004
    From XXX  Thu Jul 29 14:46:15 2004

So, I had a single mail in my mail spool.  I ran formail which ran procmail
which happily delivered that mail back to my spool (cuz it wasn't filtered
into another mailbox).  As a result, I now have two copies of that mail in my
spool.

> procmail detects that someone else (bash
> through <) reads /var/mail/$USER and refuses to run as it should, waiting for
> bash to give up, i.e. forever.

I'm not sure how procmail would detect that.  Linux has no general mechanism
for one process to determine if another process has a file open.  That's why
tools like lsof have to grovel through /proc, /dev/kmem, etc.  I doubt
procmail does that.

I'll concede that the command I gave is unsafe as procmail's default rule
will deliver mail back to your mail spool, resulting in duplicated mail, and
conceivable putting formail and procmail into an infinite loop (until all the
space in /var/mail is consumed).  This won't happen (duplicated e-mail or the
infinite loop) if you have a catchall rule in your .procmailrc so that
procmail always delivers to a folder and never back to your spool.

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
905.771.0017 ext. 225                           thornhill, ontario, canada
http://www.starnix.com              professional linux services & products
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml