So, we ran into an autoresponder loop recently, and had to turn
it off. Then I started digging into the 1.0.3 code, and could
not find a way to add more safety features to /just/ the auto-
responder – am I missing something?
I could easily write up some safety stuff in procmail (which is
called before stripmime and rt anyway, in our configuration),
but there doesn't seem to be a way to have RT spit the ticket
number back out to procmail. Is it possible to create a ticket
submission address that doesn't respond, and still have one
that does, in case of suspected loops?
Also -- Jesse, Tobias, you guys need some good logic for the
RT2 autoresponder code?
J.D. Falk "Laughter is the sound
Product Manager that knowledge makes when it’s born."
Mail Abuse Prevention System LLC – The Cluetrain Manifesto
I could easily write up some safety stuff in procmail (which is
called before stripmime and rt anyway, in our configuration),
but there doesn’t seem to be a way to have RT spit the ticket
number back out to procmail. Is it possible to create a ticket
submission address that doesn’t respond, and still have one
that does, in case of suspected loops?
Also – Jesse, Tobias, you guys need some good logic for the
RT2 autoresponder code?
IMO best idea is to do like vacation is doing - limit the system so it
only sends one autorespond of a given template to a given email at a given
week. This would both stop loops and stop annoying the people who
frequently submit tickets. I’ve made #TODO-hooks in the code for
this. Jesse thinks this should wait until post-2.0, but I don’t think it
is a much complicated thing to do.
The traditional idea is to prevent autoreply at mails with a header line
matching /^Precedence: (junk|bulk)$/i - that’s already implemented both in
RT1 and RT2, but the implementation is a bit better in RT2.
Spell checkers are for wimps
(please send feedback on all typos)
If a regular user submits two, ten or five hundred tickets in a week,
they should get two, ten or five hundred receipts. I agree that we
need better bounce control, but vacation-style squelching wouldn’t work.On Fri, Jul 14, 2000 at 12:39:46PM +0200, Tobias Brox wrote:
I could easily write up some safety stuff in procmail (which is
called before stripmime and rt anyway, in our configuration),
but there doesn't seem to be a way to have RT spit the ticket
number back out to procmail. Is it possible to create a ticket
submission address that doesn't respond, and still have one
that does, in case of suspected loops?
Also -- Jesse, Tobias, you guys need some good logic for the
RT2 autoresponder code?
IMO best idea is to do like vacation is doing - limit the system so it
only sends one autorespond of a given template to a given email at a given
week. This would both stop loops and stop annoying the people who
frequently submit tickets. I’ve made #TODO-hooks in the code for
this. Jesse thinks this should wait until post-2.0, but I don’t think it
is a much complicated thing to do.
The traditional idea is to prevent autoreply at mails with a header line
matching /^Precedence: (junk|bulk)$/i - that’s already implemented both in
RT1 and RT2, but the implementation is a bit better in RT2.
–
Spell checkers are for wimps
(please send feedback on all typos)
jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
And I’m told we do share some common rituals. Our “flame war” is apparently
held in person in their land and called “project meeting”.
-Alan Cox [on “Suits”]
If a regular user submits two, ten or five hundred tickets in a week,
they should get two, ten or five hundred receipts. I agree that we
need better bounce control, but vacation-style squelching wouldn’t work.
I think our viewpoints at the autoreplies are a bit different - for us,
the autoreply is just a bit of “early information” about the request
handling. If we’re backlogged so it might take more than a week getting
back to the user, he should get an autoreply stating that it might take
some time and eventually a list of other resources it’s possible to find
help. In this context, one autoreply a week is sufficient, regardless how
many tickets the requestor issues.
The other usage is like a notification or receipt that the ticket is
actually received, with the ticket id (and eventually login information
for new requestors). Then it is important that one autoreply is
sent out for every Ticket; but still I disagree that the one who issues
500 requests in i.e. one hour should get 500 autoreplies; by putting a
limit somewhere, uncontrolled loops are efficiently stopped - such extreme
amounts of requests can only be generated through loops or scripts, and if
a script really needs to get those receipts … well, there are
workarounds.
My conclution is that there should be some limit, but that the limit must
be configurable. For our usage, one autoreply pr week makes sense for
most queues - for your usage, twenty replies in three minutes might make
more sense.
Spell checkers are for wimps
(please send feedback on all typos)
nod I can buy that.On Fri, Jul 14, 2000 at 05:21:41PM +0200, Tobias Brox wrote:
If a regular user submits two, ten or five hundred tickets in a week,
they should get two, ten or five hundred receipts. I agree that we
need better bounce control, but vacation-style squelching wouldn’t work.
I think our viewpoints at the autoreplies are a bit different - for us,
the autoreply is just a bit of “early information” about the request
handling. If we’re backlogged so it might take more than a week getting
back to the user, he should get an autoreply stating that it might take
some time and eventually a list of other resources it’s possible to find
help. In this context, one autoreply a week is sufficient, regardless how
many tickets the requestor issues.
The other usage is like a notification or receipt that the ticket is
actually received, with the ticket id (and eventually login information
for new requestors). Then it is important that one autoreply is
sent out for every Ticket; but still I disagree that the one who issues
500 requests in i.e. one hour should get 500 autoreplies; by putting a
limit somewhere, uncontrolled loops are efficiently stopped - such extreme
amounts of requests can only be generated through loops or scripts, and if
a script really needs to get those receipts … well, there are
workarounds.
My conclution is that there should be some limit, but that the limit must
be configurable. For our usage, one autoreply pr week makes sense for
most queues - for your usage, twenty replies in three minutes might make
more sense.
–
Spell checkers are for wimps
(please send feedback on all typos)
jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
And I’m told we do share some common rituals. Our “flame war” is apparently
held in person in their land and called “project meeting”.
-Alan Cox [on “Suits”]