Autoreply to requestor not working

RT Users
1

Hi,

Our RT 3.8.8 installation does not send autoreplies to requestors if the
ticket is opened via E-Mail. If it is opened via the web interface, the
autoreply is sent. The debug log shows the following behavior:

(Only the autoreply part contained)

[Mon Aug 23 15:05:21 2010] [debug]: Converting ‘ISO-8859-15’ to ‘utf-8’
for text/plain - hfg (/usr/local/rt/bin/…/lib/RT/I18N.pm:249)
[Mon Aug 23 15:05:21 2010] [debug]: Mail from user #347309
(kunz@requestor-domain.com)
(/usr/local/rt/bin/…/lib/RT/Interface/Email/Auth/MailFrom.pm:75)
[Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for
transaction #714762 (/usr/local/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for
transaction #714763 (/usr/local/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for
transaction #714764 (/usr/local/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for
transaction #714765 (/usr/local/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Mon Aug 23 15:05:22 2010] [debug]: About to think about scrips for
transaction #714766 (/usr/local/rt/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Mon Aug 23 15:05:22 2010] [debug]: About to prepare scrips for
transaction #714766 (/usr/local/rt/bin/…/lib/RT/Transaction_Overlay.pm:167)
[Mon Aug 23 15:05:22 2010] [debug]: Found 3 scrips for TransactionCreate
stage with applicable type(s) Create
(/usr/local/rt/bin/…/lib/RT/Scrips_Overlay.pm:370)
[Mon Aug 23 15:05:24 2010] [debug]: About to commit scrips for
transaction #714766 (/usr/local/rt/bin/…/lib/RT/Transaction_Overlay.pm:187)
[Mon Aug 23 15:05:24 2010] [debug]: Committing scrip #68 on txn #714766
of ticket #99050 (/usr/local/rt/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Mon Aug 23 15:05:24 2010] [debug]: Calling SetRecipientDigests for
transaction RT::Transaction=HASH(0x911cc68), id 714766
(/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:635)
[Mon Aug 23 15:05:24 2010] [debug]: Working on mailfield To; recipients
are (/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:651)
[Mon Aug 23 15:05:24 2010] [debug]: Subject: [Filoo GmbH #99050] Ihre
Anfrage hfg
In-Reply-To: 4C728E2C.2080207@requestor-domain.com
References: RT-Ticket-99050@our-domain.com
4C728E2C.2080207@requestor-domain.com
Message-ID: rt-3.8.8-2326-1282575923-597.99050-68-0@our-domain.com
Precedence: bulk
X-RT-Loop-Prevention: Filoo GmbH
RT-Ticket: Filoo GmbH #99050
Managed-by: RT 3.8.8 (Request Tracker — Best Practical Solutions)
RT-Originator: kunz@requestor-domain.com
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=“utf-8”
X-RT-Original-Encoding: utf-8
(/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:658)
[Mon Aug 23 15:05:24 2010] [debug]: Removing deferred recipients from
[Mon Aug 23 15:05:24 2010] [debug]: Setting deferred recipients for
attribute creation (/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:690)
[Mon Aug 23 15:05:24 2010] [debug]: Working on mailfield Cc; recipients
are (/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:651)
[Mon Aug 23 15:05:24 2010] [debug]: Subject: [Filoo GmbH #99050] Ihre
Anfrage hfg
In-Reply-To: 4C728E2C.2080207@requestor-domain.com
References: RT-Ticket-99050@our-domain.com
4C728E2C.2080207@requestor-domain.com
Message-ID: rt-3.8.8-2326-1282575923-597.99050-68-0@our-domain.com
Precedence: bulk
X-RT-Loop-Prevention: Filoo GmbH
RT-Ticket: Filoo GmbH #99050
Managed-by: RT 3.8.8 (Request Tracker — Best Practical Solutions)
RT-Originator: kunz@requestor-domain.com
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=“utf-8”
X-RT-Original-Encoding: utf-8
(/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:658)
[Mon Aug 23 15:05:24 2010] [debug]: Removing deferred recipients from
[Mon Aug 23 15:05:24 2010] [debug]: Setting deferred recipients for
attribute creation (/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:690)
[Mon Aug 23 15:05:24 2010] [debug]: Working on mailfield Bcc; recipients
are (/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:651)
[Mon Aug 23 15:05:24 2010] [debug]: Subject: [Filoo GmbH #99050] Ihre
Anfrage hfg
In-Reply-To: 4C728E2C.2080207@requestor-domain.com
References: RT-Ticket-99050@our-domain.com
4C728E2C.2080207@requestor-domain.com
Message-ID: rt-3.8.8-2326-1282575923-597.99050-68-0@our-domain.com
Precedence: bulk
X-RT-Loop-Prevention: Filoo GmbH
RT-Ticket: Filoo GmbH #99050
Managed-by: RT 3.8.8 (Request Tracker — Best Practical Solutions)
RT-Originator: kunz@requestor-domain.com
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=“utf-8”
X-RT-Original-Encoding: utf-8
(/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:658)
[Mon Aug 23 15:05:24 2010] [debug]: Removing deferred recipients from
Bcc: line (/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:681)
[Mon Aug 23 15:05:24 2010] [debug]: Setting deferred recipients for
attribute creation (/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:690)
[Mon Aug 23 15:05:24 2010] [debug]: No recipients found for deferred
delivery on transaction #714766
(/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:703)
[Mon Aug 23 15:05:24 2010] [info]:
rt-3.8.8-2326-1282575923-597.99050-68-0@our-domain.com #99050/714766 -
Scrip 68 Autoreply (/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:300)
[Mon Aug 23 15:05:24 2010] [info]:
rt-3.8.8-2326-1282575923-597.99050-68-0@our-domain.com No recipients
found. Not sending. (/usr/local/rt/bin/…/lib/RT/Interface/Email.pm:352)

The last line shows the “No recipients found. Not sending” behavior that
is outlined in the FAQ - but only for AdminCC or CC fields. However,
this is a pretty standard scrip and it is being executed:

Scrip #68
Description: Autoreply
Condition: On Create
Action: Autoreply To Requestors
Template: Autoreply de-punkt
Stage: TransactionCreate

I’m baffled that although there’s a legitimate, usable mail address in
the From (and the ticket is created without any problem), the autoreply
doesn’t find any usable addresses.

Does anyone have any idea for this?

Is it possible that the settiing “Outgoing Mail” is implicitly set to 0
for all existing users, overriding the Set($NotifyActor, 1)
configuration option in my config? If so, how to remedy?

Regards,

–ck

2

Hi,

Our RT 3.8.8 installation does not send autoreplies to requestors if the
ticket is opened via E-Mail. If it is opened via the web interface, the
autoreply is sent. The debug log shows the following behavior:

[Mon Aug 23 15:05:24 2010] [debug]: Working on mailfield To; recipients
are (/usr/local/rt/bin/…/lib/RT/Action/SendEmail.pm:651)

This implies that RT isn’t seeing Requestors for that ticket.
You may want to show a sample of the email being injected into RT
and look at the user record for the user assigned as a Requestor for
the ticket. You’re also using a custom Autoreply template, and we
don’t know what you’ve changed there.

-kevin

3

This implies that RT isn’t seeing Requestors for that ticket.
You may want to show a sample of the email being injected into RT
and look at the user record for the user assigned as a Requestor for
the ticket. You’re also using a custom Autoreply template, and we
don’t know what you’ve changed there.

I solved the problem by taking up your idea of dumping the raw mails and
by remembering I had this problem before.

The mail is delivered using a forwarding (info@mydomain goes to
infomydomain@rt-host.mydomain and from there is piped into the
mailgate). It seems that when sending the ticket directly to
infomydomain@rt-host.mydomain, the autoreply is triggered. When sending
it to info@mydomain, it’s not.

So i checked the mail contents. There is a valid From: header pointing
to the requestor. The To: header points to the ticket system address. So
it looks good to me, seeing that the From: header is (as far as
rt–mailgate doc is concerned) is relevant for user authentication.
The only difference between the working and the not working mail is that
there is an empty Return-Path header in the broken one. And now it
dawned to me.
In lib/RT/Interface/Email.pm, RT checks for Return-Path =~ /<>/ to
determine a bounce. I had patched this to make our old installation work
(“return(0)”), but naturally forgot about the patch.

Now, basically everything works again, but I have 2 questions:

  1. does effectively disabling the routine CheckForBounce actually break
    something? In over 98000 tickets, I have not experienced a problem with
    double bounces or the likes.
  2. Why does qmail forward a mail with an empty Return-path? But that’s
    probably a whole other cup of tea.

Regards,

–ck

4
  1. does effectively disabling the routine CheckForBounce actually break
    something? In over 98000 tickets, I have not experienced a problem with
    double bounces or the likes.
  2. Why does qmail forward a mail with an empty Return-path? But that’s
    probably a whole other cup of tea.

My approach would be fixing qmail, rather than removing RT’s bounce
handling.

-kevin

5

My approach would be fixing qmail, rather than removing RT’s bounce
handling.

True - I analyzed the underlying problem and it turned out that our mail
server cluster was using 2 different versions of maildrop:

  • 1.5.2 did not modify the Return-Path in any way
  • 2.0.4 changed the Return-Path of filtered mails to <> / Envelope-From
    to MAILER-DAEMON

A weird behavior indeed. I’ll have to investigate this further.

Regards,

–ck