running procmail on the contents of /var/mail/$USER
tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org
Thu Jul 29 23:12:16 UTC 2004
"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 ;-(
> >> 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
More information about the Legacy