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

[Tim Writer]

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

> On Thu, 29 Jul 2004, Tim Writer wrote:
> 
> > Did you try it?  I did:
> >
> >    tim at newsol% grep '^From ' /var/mail/$USER
> >
> > 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.
> 
> Yes, but if all things are unfavorable you can end up with a mail loop that
> will run until the disk is full. I *know* this ;-(

Agreed.

> >> 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.
> 
> It depends on how the formail (if it is allowed to read the mailbox itself)
> and procmail are compiled. Mailbox locks come in about three flavors:
> lockfiles, kernel advisory locks and the stat count. this latter one should
> always be used as a last resort (I am quoting old books from memory -
> beware). Basically the writer process opens the file with flags A+ (append)
> and then stats the file. If the link count is not 1 (for itself), then the
> process either waits for the count to become 1 or aborts. If all write
> processes do this then the file should be safe.

Yep, but bash not formail opened the mail spool via I/O redirection.  Formail
is just reading from stdin.  Procmail may do some locking when it writes to
the spool but I don't think formail does and I'm sure bash doesn't.

All fine except that, in this case, it's bash (or $SHELL) that has opened the
spool file for reading via I/O redirection.  Formail is simply reading from
stdin and so, as far as I am aware, cannot lock it in a way that procmail
would be aware of the lock.

> > 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.
> 
> Unless there is a pipe command in the recipe that causes remailing, possibly
> to another alias address, which then is also aliased and the mail comes right
> back ...

Good point.  The bottom line is it's safest to move (not copy) the contents
of the your mail spool before processing it with formail/procmail.

-- 
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