RT stops sending mails to ticket requestors

Hi,

we have been running RT for several years now with great results (around 60K
tickets so far). However, our RT installation recently started to display a
weird behavior:

If a new requestor (has never before opened a ticket with their mail address,
thus unknown to RT) starts a new ticket, they get the usual auto-reply and the
ticket is forwarded to the watchers.
If one of them answers via e-mail, the reply is sent to the other watchers and
shows in the web-based ticket view, but it is not sent to the requestor.
If one of the watchers answers via the web-based ticket view, the answer is
forwarded to the other watchers AND the requestor.
For each additional ticket that the (then no longer unknown) requestor opens
with our RT, they do not even receive the auto-reply that is supposed to be
sent. They also don’t receive any replies sent via e-mail.

I looked into the mail server logs and it can’t be a transport problem since the
mails aren’t even queued - RT just doesn’t send them. There are no recent
changes on either RT, the local Perl version or OS that coincide with this odd
behavior.

Any pointers?

Regards,

–ck
http://www.de-punkt.de [ chris@de-punkt.de ] http://www.stormix.de
PHP-Anwendungen sind gefï¿œhrdet! SQL-Injection, XSS, Session-Angriffe,
CSRF, Commandshells, Response Splitting,… bï¿œhmische Dï¿œrfer? Dann gleich
“PHP-Sicherheit” direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/

Christopher,

What kind of privileges have you set up both globally and by Queue for 

the role Requestor. Also, you may have some privileges for system groups
or user-defined groups that overlap the requestor so that even if the
actual user does not have a particular privilege as a requestor, they
may have it as part of the other groups. Hope this helps.

Kenn
LBNL

Christopher Kunz wrote:

Hi,

we have been running RT for several years now with great results (around 60K
tickets so far). However, our RT installation recently started to display a
weird behavior:

If a new requestor (has never before opened a ticket with their mail address,
thus unknown to RT) starts a new ticket, they get the usual auto-reply and the
ticket is forwarded to the watchers.
If one of them answers via e-mail, the reply is sent to the other watchers and
shows in the web-based ticket view, but it is not sent to the requestor.
If one of the watchers answers via the web-based ticket view, the answer is
forwarded to the other watchers AND the requestor.
For each additional ticket that the (then no longer unknown) requestor opens
with our RT, they do not even receive the auto-reply that is supposed to be
sent. They also don’t receive any replies sent via e-mail.

I looked into the mail server logs and it can’t be a transport problem since the
mails aren’t even queued - RT just doesn’t send them. There are no recent
changes on either RT, the local Perl version or OS that coincide with this odd
behavior.

Any pointers?

Regards,

–ck
http://www.de-punkt.de [ chris@de-punkt.de ] http://www.stormix.de
PHP-Anwendungen sind gefï¿œhrdet! SQL-Injection, XSS, Session-Angriffe,
CSRF, Commandshells, Response Splitting,… bï¿œhmische Dï¿œrfer? Dann gleich
“PHP-Sicherheit” direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/

Christopher,

Did you happen to modify the scrip to do a "notify" instead of an 

“autoreply”? A notify will not send an E_mail to the requestor if the
requestor is the creator of the ticket, an autoreply will.

Kenn
LBNLOn 8/24/2007 11:36 AM, Christopher Kunz wrote:

Hi,

System groups:
Everyone: CreateTicket
Unprivileged: CreateTicket, ReplyToTicket, ShowOutgoingEmail, Watch
Requestor: CreateTicket, ModifyTicket, ReplyToTicket, ShowOutgoingEmail, Watch

No user-defined groups with special privileges exist.

For the problematic queue:
Everyone: CommentOnTicket, CreateTicket, ReplyToTicket

I really can’t see any more privileges that might collide with the reply to the
ticket requestor, however the fact that only new requestors receive a reply
points into that direction I think…

Any idea on how to debug that? The debug log just says “no recipient found, not
sending” on one of the “problematic” cases, but it doesn’t say why…

Regards,

–ck

PS: And sorry for the resend.

Hi,

System groups:
Everyone: CreateTicket
Unprivileged: CreateTicket, ReplyToTicket, ShowOutgoingEmail, Watch
Requestor: CreateTicket, ModifyTicket, ReplyToTicket, ShowOutgoingEmail, Watch

No user-defined groups with special privileges exist.

For the problematic queue:
Everyone: CommentOnTicket, CreateTicket, ReplyToTicket

I really can’t see any more privileges that might collide with the reply to the
ticket requestor, however the fact that only new requestors receive a reply
points into that direction I think…

Any idea on how to debug that? The debug log just says “no recipient found, not
sending” on one of the “problematic” cases, but it doesn’t say why…

Regards,

–ck

PS: And sorry for the resend.

http://www.de-punkt.de [ chris@de-punkt.de ] http://www.stormix.de
PHP-Anwendungen sind gefï¿œhrdet! SQL-Injection, XSS, Session-Angriffe,
CSRF, Commandshells, Response Splitting,… bï¿œhmische Dï¿œrfer? Dann gleich
“PHP-Sicherheit” direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/

Kenneth Crocker schrieb:

Christopher,

Did you happen to modify the scrip to do a "notify" instead of an

“autoreply”? A notify will not send an E_mail to the requestor if the
requestor is the creator of the ticket, an autoreply will.

No - the following scrips are active for that queue:

Scrips which apply to all queues

* Open Blank
  On Correspond Open Tickets with template Blank
* OwnerChangeNotify
  On Owner Change Notify Owner with template Transaction
* CreateNotifyAdminCC
  On Create Notify AdminCcs with template Transaction
* CorrespondNotifyAdminCC
  On Correspond Notify AdminCcs with template Admin Correspondence
* CorrespondNotifyReq
  On Correspond Notify Requestors and Ccs with template Correspondence
* CorrespondNotify
  On Correspond Notify Other Recipients with template Correspondence
* CommentNotifyAdminCC
  On Comment Notify AdminCcs as Comment with template Admin Comment
* CommentNotify
  On Comment Notify Other Recipients as Comment with template Correspondence

Current Scrips

Autoreply

On Create Autoreply To Requestors with template Autoreply de-punkt

AFAICT, they are all untouched.

I’m really at a loss as to where the problem might be…

Regards,

–ck
http://www.de-punkt.de [ chris@de-punkt.de ] http://www.stormix.de
PHP-Anwendungen sind gefï¿œhrdet! SQL-Injection, XSS, Session-Angriffe,
CSRF, Commandshells, Response Splitting,… bï¿œhmische Dï¿œrfer? Dann gleich
“PHP-Sicherheit” direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/

It’s seems, that your Autoreply script isn’t a global script, but a script, that runs only in a specific queue.

Michael

No - the following scrips are active for that queue:

Scrips which apply to all queues

* Open Blank
  On Correspond Open Tickets with template Blank
* OwnerChangeNotify
  On Owner Change Notify Owner with template Transaction
* CreateNotifyAdminCC
  On Create Notify AdminCcs with template Transaction
* CorrespondNotifyAdminCC
  On Correspond Notify AdminCcs with template Admin Correspondence
* CorrespondNotifyReq
  On Correspond Notify Requestors and Ccs with template Correspondence
* CorrespondNotify
  On Correspond Notify Other Recipients with template Correspondence
* CommentNotifyAdminCC
  On Comment Notify AdminCcs as Comment with template Admin Comment
* CommentNotify
  On Comment Notify Other Recipients as Comment with template Correspondence

Current Scrips

Autoreply

On Create Autoreply To Requestors with template Autoreply de-punkt

AFAICT, they are all untouched.

I’m really at a loss as to where the problem might be…

Regards,

–ck
http://www.de-punkt.de [ chris@de-punkt.de ] http://www.stormix.de
PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe, CSRF, Commandshells, Response Splitting,… böhmische Dörfer? Dann gleich “PHP-Sicherheit” direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/ _______________________________________________
The rt-users Archives

Community help: http://wiki.bestpractical.com Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Peer Michael schrieb:

It’s seems, that your Autoreply script isn’t a global script, but a script, that runs only in a specific queue.

So? Of course it’s a local scrip, I need a different autoreply template for each
of my queues.

Regards,

–ck

http://www.de-punkt.de [ chris@de-punkt.de ] http://www.stormix.de
PHP-Anwendungen sind gefï¿œhrdet! SQL-Injection, XSS, Session-Angriffe,
CSRF, Commandshells, Response Splitting,… bï¿œhmische Dï¿œrfer? Dann gleich
“PHP-Sicherheit” direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/

Hi,

I really need a solution to this problem ASAP, our complete ticketing has ground
to a halt. How can it happen that only a completely new requestor (not known to
RT before) receives the initial autoreply and all correspondence via e-mail, but
all known requestors don’t receive anything at all?

Without RT sending responses to requestors, it has no use for our organization
at all, I really need this fixed…

Thanks,

–ck

http://www.de-punkt.de [ chris@de-punkt.de ] http://www.stormix.de
PHP-Anwendungen sind gefï¿œhrdet! SQL-Injection, XSS, Session-Angriffe,
CSRF, Commandshells, Response Splitting,… bï¿œhmische Dï¿œrfer? Dann gleich
“PHP-Sicherheit” direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/

Hi,

the rt debug log looks like this during one of the “broken” transactions:

[Fri Aug 31 14:26:21 2007] [debug]: About to commit scrips for transaction
#324709 (/usr/local/rt/lib/RT/Transaction_Overlay.pm:173)
[Fri Aug 31 14:26:21 2007] [info]:
rt-3.6.0-6968-1188570380-1094.59902-7-0@filoo.de #59902/324709 - Scrip 7
CorrespondNotify (/usr/local/rt/lib/RT/Action/SendEmail.pm:237)
[Fri Aug 31 14:26:21 2007] [info]:
rt-3.6.0-6968-1188570380-1094.59902-7-0@filoo.de No recipients found. Not
sending. (/usr/local/rt/lib/RT/Action/SendEmail.pm:249)
[Fri Aug 31 14:26:21 2007] [info]:
rt-3.6.0-6968-1188570380-1094.59902-5-0@filoo.de #59902/324709 - Scrip 5
CorrespondNotifyAdminCC (/usr/local/rt/lib/RT/Action/SendEmail.pm:237)
[Fri Aug 31 14:26:21 2007] [debug]: Converting ‘ISO-8859-1’ to ‘utf-8’ for
text/plain - Re: AW: AW: [Filoo GmbH #59902] testmail
(/usr/local/rt/lib/RT/I18N.pm:226)
[Fri Aug 31 14:26:21 2007] [debug]: About to think about scrips for transaction
#324710 (/usr/local/rt/lib/RT/Transaction_Overlay.pm:160)
[Fri Aug 31 14:26:21 2007] [info]:
rt-3.6.0-6968-1188570380-1094.59902-5-0@filoo.de sent To: “AdminCc of Filoo
GmbH Ticket #59902”:; Bcc: chris@filoo.de, jens@filoo.de, seb@filoo.de
(/usr/local/rt/lib/RT/Action/SendEmail.pm:312)
[Fri Aug 31 14:26:21 2007] [info]:
rt-3.6.0-6968-1188570380-1094.59902-6-0@filoo.de #59902/324709 - Scrip 6
CorrespondNotifyReq (/usr/local/rt/lib/RT/Action/SendEmail.pm:237)
[Fri Aug 31 14:26:21 2007] [info]:
rt-3.6.0-6968-1188570380-1094.59902-6-0@filoo.de No recipients found. Not
sending. (/usr/local/rt/lib/RT/Action/SendEmail.pm:249)
[Fri Aug 31 14:26:21 2007] [warning]: Use of uninitialized value in
concatenation (.) or string at
/usr/local/rt/share/html/REST/1.0/NoAuth/mail-gateway line 66.
(/usr/local/rt/share/html/REST/1.0/NoAuth/mail-gateway:66)

The scrip is actually executed, but no recipient is found… how could that happen?
–ck

Stick some debugging statements in your scrip and examine the log.

my $requestors =
$RT::Logger->debug(“Scrip 43 Cleanup: Requestor list is: $requestors”);

At 01:51 AM 8/31/2007, Christopher Kunz wrote:

Hi,

I really need a solution to this problem ASAP, our complete ticketing has
ground
to a halt. How can it happen that only a completely new requestor (not
known to
RT before) receives the initial autoreply and all correspondence via
e-mail, but
all known requestors don’t receive anything at all?

Without RT sending responses to requestors, it has no use for our organization
at all, I really need this fixed…

Thanks,

–ck


http://www.de-punkt.de [ chris@de-punkt.de ] http://www.stormix.de
PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe,
CSRF, Commandshells, Response Splitting,… böhmische Dörfer? Dann gleich
“PHP-Sicherheit” direkt beim Verlag vorbestellen!
http://www.php-sicherheit.de/


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Gene LeDuc, GSEC
Security Analyst
San Diego State University