-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
this might be a very silly problem but today we had an exchange with a
supplier.
The supplier triggers an automatic “email creation notification” which
gets back to us, triggering a RT response, and so on.
To stop the loop, I had to deleted the ticket from database (by a manual
“delete from Tickets where id=…”).
Is there anything we can do about it? It’s happened twice in 2 years,
but I guess it’s better to prevent this from happening.
Any pointer to useful docs?
Thanks,
Giuseppe
Giuseppe Sollazzo
Senior Systems Analyst
Computing Services
Information Services
St. George’s, University Of London
Cranmer Terrace
London SW17 0RE
Email: gsollazz@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583
Twitter: http://twitter.com/sgulit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQk/wdAAoJEAqigArPBfJXK98H/j840osIAdc5W7hepPbSDa4L
u4jveNu4qMJpVCkOXxOIpq2Vikr4+NoJ4F7/xxMbfC6Ryp2xj5X+nLd/tUenO1rp
k5pQq0piPS1dwwTBh+e1CuMUiS1omdeGsrgfX7aTwfsfUOAGPKOFcsQf9y1Pf0nS
F5eivixEWfloCtVBZ7M25isp053O1tN1IxIFJ5XIVyMhW9WExOWnvr1gx4+I6/dG
38+9iqCNpFUwsPvxhjlaP0PTCeiQueC8gxEbv4YD8H1fl/Y8///6/wltV9YNySg1
S2drABQ1+HH4A/Y+brPuU/gtiksxGz8yzpeav36SGirfo/4gcUKKNvfuaoWsntw=
=I+Nc
-----END PGP SIGNATURE-----
0xCF05F257.asc (1.7 KB)
this might be a very silly problem but today we had an exchange with a
supplier.
The supplier triggers an automatic “email creation notification” which
gets back to us, triggering a RT response, and so on.
To stop the loop, I had to deleted the ticket from database (by a manual
“delete from Tickets where id=…”).
Is there anything we can do about it? It’s happened twice in 2 years,
but I guess it’s better to prevent this from happening.
Any pointer to useful docs?
You can delete the email address from the user of that system (leaving
their username set to the email address) which means RT will never
send them email. If they’re dropping all of RT’s loop prevention
headers, there isn’t much we can do to stop the loop unfortunately.
-kevin
Dnia 2012-11-06, wto o godzinie 14:02 -0500, Kevin Falcone pisze:> On Fri, Nov 02, 2012 at 05:00:13PM +0000, Giuseppe Sollazzo wrote:
this might be a very silly problem but today we had an exchange with a
supplier.
The supplier triggers an automatic “email creation notification” which
gets back to us, triggering a RT response, and so on.
To stop the loop, I had to deleted the ticket from database (by a manual
“delete from Tickets where id=…”).
Is there anything we can do about it? It’s happened twice in 2 years,
but I guess it’s better to prevent this from happening.
Any pointer to useful docs?
You can delete the email address from the user of that system (leaving
their username set to the email address) which means RT will never
send them email.
Leaving aside the original issue - why is that? Is this behavior
hardcoded or is it a question od default scrips?
Regards,
Robert Wysocki
administrator systemów linuksowych
Contium S.A., http://www.contium.pl
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leaving aside the original issue - why is that? Is this behavior
hardcoded or is it a question od default scrips?
I guess that the reason is that there are two systems, A and B.
We are A and use RT.
B is configured to send a confirmation e-mail whenever it receives
anything from A.
A sends a print-out of the e-mail it receives to B.
Specifically, it’s about the “resolve” message, but I presume the same
applies also to “correspondence” if configured to send out e-mails at
each message.
Not sure what system uses B, it might be RT as well or something similar.
I’m surprised this doesn’t affect more people.
G
Regards,
Giuseppe Sollazzo
Senior Systems Analyst
Computing Services
Information Services
St. George’s, University Of London
Cranmer Terrace
London SW17 0RE
Email: gsollazz@sgul.ac.uk
Direct Dial: +44 20 8725 5160
Fax: +44 20 8725 3583
Twitter: http://twitter.com/sgulit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQmi/tAAoJEAqigArPBfJXaPAH/RMm4F11Npim1Fvs0Lbl2yJC
kCkxrZAghKcR8pgGYEYrfdATbeZ226IGRoAql8/Y5okBkhpQMY22Cxg4cqIgBIQB
gNRzDvepUUfzMknCSgm9IdRigj6YvMzAAA+uxXB1tgcjoSocfL26XvSCXNckxnU9
kNcLk5E5CXX4XTtcbhGe00lGMYV+pQwjgv9jsBV5yOCCj92+Kqi/gKV5Mn6McFLi
I1Wc4w9xm9WKpXWfEoMKMNfj3MOA0bFmd211wtDI8o4esWVUnRnklEpsQllSznDx
Pd/4gFxIsiK2Dir8I8/mAmSV7t1jfu5RZwF+AHA7AINthcIvJLxgub4KGehiwCw=
=hJJE
-----END PGP SIGNATURE-----
0xCF05F257.asc (1.7 KB)
Dnia 2012-11-06, wto o godzinie 14:02 -0500, Kevin Falcone pisze:
You can delete the email address from the user of that system (leaving
their username set to the email address) which means RT will never
send them email.
Leaving aside the original issue - why is that? Is this behavior
hardcoded or is it a question od default scrips?
When email comes in, RT loads by the email address and looks for that
email address in the EmailAddress field and then in the Name field.
When email goes out, RT already has the user, and fetches the
EmailAddress to send them mail. Since it’s blank, it skips the user.
That’s why this particular trick works.
There are probably 5 other ways email might not go out via RT (user
preference, ticket squelching, transaction squelching, etc) but this
covers the old failthful trick I described above.
-kevin
I guess that the reason is that there are two systems, A and B.
We are A and use RT.
B is configured to send a confirmation e-mail whenever it receives
anything from A.
A sends a print-out of the e-mail it receives to B.
Specifically, it’s about the “resolve” message, but I presume the same
applies also to “correspondence” if configured to send out e-mails at
each message.
Not sure what system uses B, it might be RT as well or something similar.
I’m surprised this doesn’t affect more people.
People often make their ‘talks to remote system’ queues not use as
many autoreplies. Also, many external systems retain enough state in
the headers for RT to detect the loop (RT sets a number of bear traps
for these emails).
You could also try marking the precedence of the Resolved email lower
(RT’s emails have a configurable Precedence which defaults to bulk
from DefaultMailPrecedence). Lower precedence mail is often not
replied-to (see RT’s handling of bulk precedence email with
RedistributeAutoGeneratedMessages). Alternately, you could use the
Auto-submitted header that Autoreply uses to call out that you don’t
need a reply.
-kevin
Dnia 2012-11-07, śro o godzinie 10:12 -0500, Kevin Falcone pisze:> On Wed, Nov 07, 2012 at 10:39:21AM +0100, Robert Wysocki wrote:
Leaving aside the original issue - why is that? Is this behavior
hardcoded or is it a question od default scrips?
When email comes in, RT loads by the email address and looks for that
email address in the EmailAddress field and then in the Name field.
When email goes out, RT already has the user, and fetches the
EmailAddress to send them mail. Since it’s blank, it skips the user.
That’s why this particular trick works.
Neat 
Thanks, good to know.
Regards,
Robert Wysocki
administrator systemów linuksowych
Contium S.A., http://www.contium.pl