[…] rt got the mail, responded to the clown’s address, mail was picked
by the clown’s bot, responded to rt, rt got it, responded again - the
cycle was so vicious I has to shutdown that queue.I’m wondering if there is a way to protect rt against such a situation.
RT here goes through procmail first. Suspicious mail goes to
an passive mailbox, otherwise direct to RT. When a problem is
noticed, an ppropriate expression is inserted in procmailrc to
make such mails suspicious. Not very multi-user, but sufficient
in my case.
The passive mailbox is read once in a while (could have some
kind of “biff” program) by admin using mutt. A macro in mutt
sends it straight through to RT if admin so decides.
Another solution would be to have suspicious mail sent to a
queue in RT that does not have the autoresponder set, but
that has disadvantages like 1) suspicious e-mails that are
admin-authorized wouldn’t get auto-ack 2) mailbombing still
enters RT (been mailbombed several times, don’t like it).
Procmail also lets me change the From header on the fly, which
means that I can deal with some automatic tools that send
trouble tickets but should not get any replies, auto-ack,
whatever.
If I had the time/inclination, there are procmail scripts that
can eliminate duplicates, and you can probably do some kind of
rate-limiting too.
#include <std_disclaim.h> Lorens Kockum