Notification sent to requestor even when squelched

Hi all,

I manage an RT 4.2.11 deployment using Debian Wheezy, Apache 2.2, mod_fcgid

Today we had a very concerning issue regarding a notification being sent to
a requestor even when it had been explicitly unchecked in the recipients
list. At first I didn’t believe the user, but then I found this in the log:

Jun 22 11:29:08RT:[user.info<14>] [6157]
rt-4.2.11-6157-1434965348-1424.4519-59-0@rtdomain.com
requestor@address.com is blacklisted by notification checkboxes for
this transaction. Skipping

Jun 22 11:29:55RT:[user.info<14>] [6145] rt-4.2.11-6145-1434965395-786.4519-59-0@rtdomain.com #4519/69938 - Scrip 59 On Correspond from web Notify Requestor and Ccs
Jun 22 11:29:56RT:[user.info<14>] [6145] rt-4.2.11-6145-1434965395-786.4519-59-0@rtdomain.com sent To: requestor@address.com

You can see that the requestor address was unchecked, but he was notified
anyway. The notificatoin script uses a custom condition to just send the
notification when using the web interface, with the possibility of
squelching recipients manually. The default behaviour (implicit
notification to all requestors even for correspondence by mail) was
confusing for my team mates.

The only odd thing I can see in the log is that the “Blacklisted” and the
"sent to …" entries are written by two different perl processes (PID 6157
and 6145 respectively). That didn’t happen when I tried to reproduce the
issue (with no success).
Does anyone know if that’s normal in mod_fcgid? Could it be the cause of
the problem?

It’s a big problem for us if we cannot fully trust the platform to not
spread confidential information to unintended recipients.

Thank you in advance,

Marcos.

I manage an RT 4.2.11 deployment using Debian Wheezy, Apache 2.2,
mod_fcgid

Today we had a very concerning issue regarding a notification being
sent to a requestor even when it had been explicitly unchecked in the
recipients list. At first I didn’t believe the user, but then I found
this in the log:
[snip]

There’s a 47-second interval between the first and the second of
those. Can you show the full log of everything between them? My guess
is that the first one was a “dry run” to list the potential recipients,
and the second was the actual submission. This would explain the
different process IDs, as well as the different behaviors.

You can see that the requestor address was unchecked, but he was
notified anyway. The notificatoin script uses a custom condition to
just send the notification when using the web interface, with the
possibility of squelching recipients manually. The default behaviour
(implicit notification to all requestors even for correspondence by
mail) was confusing for my team mates.

Your wording is confusing. Is this jut the stock “Notify Requestor and
Ccs” action, with a custom condition?

  • Alex

It’s a big problem for us if we cannot fully trust the platform to not
spread confidential information to unintended recipients.

Along with Alex’s suggestions / questions, it sounds like this workflow
would benefit from the comment functionality. Ticket comments allow
communication via your internal team (AdminCCs) but do not notify
Requestors and Ccs.

Hi Todd,

Thank you for the suggestion. However, in this case, it was a Reply with
One-Time-CCs, so I guess a Comment is not the best option. Moreover, we
don’t have control of the mail domain, and you wouldn’t believe the
bureaucracy and delay to get a mail alias for comments.

It’s true that our use of the system is not always adapted to the platform,
my colleagues want the WebUI to be basically a mail client on steroids.
They want all external recipients to be explicit, either when sending a
mail from their client, or in the webUI message composing screen.

Even if I understand the design of RT, I think a few features would make it
come close to what users are most accustomed to in a mail client, and make
it more flexible:

  • Correspondance subject independent from the ticket title. Copied from the
    transaction that you are replying to.
  • Default recipients selected based on the sender of the transaction you
    are replying to, even if they are not the Requestors (with the full list of
    Requestors available for checking if desired).
  • One-Time-To. There is an extension for this, but I couldn’t make it work
    properly with RT 4.2.
  • Preserved To, CC in mail notifications, by setting them to a different
    value independent from the SMTP envelope.
  • Show full list of recipients for transactions in History
  • Collapsible individual transactions in History.

Anyway, I should maybe wait for Christmas… :slight_smile:

Kind regards,
Marcos.2015-06-22 19:54 GMT+02:00 Todd Wade todd@bestpractical.com:

On 6/22/15 1:10 PM, Marcos Orallo wrote:

It’s a big problem for us if we cannot fully trust the platform to not
spread confidential information to unintended recipients.

Along with Alex’s suggestions / questions, it sounds like this workflow
would benefit from the comment functionality. Ticket comments allow
communication via your internal team (AdminCCs) but do not notify
Requestors and Ccs.

Hi Alex,

Thanks for your reply. My comments inline.

I manage an RT 4.2.11 deployment using Debian Wheezy, Apache 2.2,
mod_fcgid

Today we had a very concerning issue regarding a notification being
sent to a requestor even when it had been explicitly unchecked in the
recipients list. At first I didn’t believe the user, but then I found
this in the log:
[snip]

There’s a 47-second interval between the first and the second of
those. Can you show the full log of everything between them?

That’s the full log, nothing in between (syslog, “info” level). The gap is
indeed strange…

My guess is that the first one was a “dry run” to list the potential
recipients,
and the second was the actual submission. This would explain the
different process IDs, as well as the different behaviors.

But the “blacklisting” happened just for that transaction when composing
the message, it was not a permanent squelch. So the system didn’t know it
was blacklisted in the preparation stage…

You can see that the requestor address was unchecked, but he was
notified anyway. The notificatoin script uses a custom condition to
just send the notification when using the web interface, with the
possibility of squelching recipients manually. The default behaviour
(implicit notification to all requestors even for correspondence by
mail) was confusing for my team mates.

Your wording is confusing. Is this jut the stock “Notify Requestor and
Ccs” action, with a custom condition?

Exactly. This is the custom condition, taken from RT wiki, IIRC.

my $trans = $self->TransactionObj;
return 0 unless $trans->Type eq “Correspond”;

my $msgattr = $trans->Message->First;
return 0 unless $msgattr;

return 1 unless $msgattr->GetHeader(‘Received’);
return 0;