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

[Peter L. Peres]

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

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

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

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