procmail
[Top] [All Lists]

RE: Preventing loops when one account is down

2003-04-08 12:40:25
On Tue, Apr 08, 2003 at 07:55:41AM -0700, Derrick Bass wrote:

the mailer-daemon on the broken account sent back a response which
included the entirety of the original message; this was forwarded
back, etc, etc, etc. This N^2 process continued until, several
gigabytes later, I'd severely impaired the main mailserver for my
entire university and the sysadmin forcibly removed my procmail
filter.

Although the problems with the broken account have supposedly been
fixed, I wonder if there is a way to prevent such a fiasco in the
future.

Yes, certainly.  And now you have first-hand experience about just
how dangerous unchecked procmail processes can be.  Note that
some sysadmins have been known to close an account for such
abuse, even when it's unintended!  Or, worse, ban procmail from
the system because things can go awry when people don't prepare
themselves for such contingencies.  Not meant as a flame, here;
I just want to point out that guns, and procmail, can be dangerous.

Reading down further in the same man page you refer to, the one
from 'man procmailex', we see:

       Store everything coming from the postmaster or mailer-dae­
       mon  (like  bounced  mail)  into  the  file  postm,  using
       postm.lock as the locallockfile.

              :0:
              * ^FROM_MAILER
              postm

So that would have been one possible useful thing.  The next example,
though, contains what we're really after:

       A  simple  autoreply  recipe.   It makes sure that neither
       mail from any daemon (like  bouncing  mail  or  mail  from
       mailing-lists),  nor autoreplies coming from yourself will
       be autoreplied to.  If this precaution would not be taken,
       disaster could result (`ringing' mail).  In order for this

"Ringing mail" is what you experienced.


       recipe to autoreply to all the incoming mail,  you  should
       of  course  insert  it  before  all  other recipes in your
       rcfile.  However, it is advisable  to  put  it  after  any
       recipes  that  process  the  mails  from  subscribed mail­
       inglists; it generally is not  a  good  idea  to  generate
       autoreplies to mailinglists (yes, the !^FROM_DAEMON regexp
       should already catch those, but if the mailinglist doesn't
       follow accepted conventions, this might not be enough).
       inglists; it generally is not  a  good  idea  to  generate
       autoreplies to mailinglists (yes, the !^FROM_DAEMON regexp
       should already catch those, but if the mailinglist doesn't
       follow accepted conventions, this might not be enough).

              :0 h c
              * !^FROM_DAEMON
              * !^X-Loop: your(_at_)own(_dot_)mail(_dot_)address
              | (formail -r -I"Precedence: junk" \
                  -A"X-Loop: your(_at_)own(_dot_)mail(_dot_)address" ; \
                 echo "Mail received.") | $SENDMAIL -t



Okay, that looks fairly complicated to the untrained eye, and
is not exactly what you were after.  The point is the same, though:
whenever you have procmail send a message out, you run into the same
danger or ringing mail.  You need, and want, an X-Loop: header,
and you need, and want, to test for it up high in your own
.procmailrc.

The follow-up poster who said you should exclude your other
mail server from the recipe in question via condition is taking
the cheap way out: what we really want is to exclude any and all
bouncing mail, not just that from a specific server we happen
to be forwarding to this week, month, or year.  Hence, the
X-Loop: header.

The short lesson is, don't be so quick to put things into a
production environment when such contigencies haven't been
hashed out.

Good luck!

--  
dman




_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail


<Prev in Thread] Current Thread [Next in Thread>