Issues with email correspondence

RTIR
1

Hello,

we’re currently using:

  • rt 3.0.11 (with rtir-1.0.5)
  • default acls/access rights (in particular, the queues in question,
    like investigations, have replytoticket for everyone)

[I’m not aware of later versions of rt(ir) fixing the issues I’m seeing, but please correct me if they do]

and we’re currently coming up against a couple of issues with users
responding to requests via email from email addresses that aren’t
listed as correspondents for the issue (typical when noc@something sends
the incident report and then a specific user replies to correspondence
sent back)

In the cases where RT knows about them (e.g they’ve corresponded on some
other issue before) everything works fine, but where they haven’t (and
where we’re having issues), RT refuses to create a new user and their
reply gets bounced.

I realise the above is probably “known” behaviour, and is probably
specifically an RT rather than an rtir issue, but was wondering
how others have solved the issues, in particular:

  • how you get around not having everyone with replytoticket access, and
    yet
  • how you deal with most correspondence not coming from the requestor
    Note that the issues are with “external users” whom we can’t all ask to
    use pgp keys, or use the “right” email address, etc.

The best idea I’ve had so far is to remove the above replytoticket
access, and recode bits of rt(ir) to send the issue to the general queue
so a human can deal with it (i.e merge the issue with the right
investigation/incident report) but it all seems like a lot of work (and
also, it looks like mailplugins can’t currently modify anything other
than the mime object[1])

Thanks

[1] does anyone know if it is this likely to change soon? It seems like
useful functionality for plugins, particularly ::Filter’s, to modify
the queue an issue is going to, etc (?)

2

In the cases where RT knows about them (e.g they’ve corresponded on some
other issue before) everything works fine, but where they haven’t (and
where we’re having issues), RT refuses to create a new user and their
reply gets bounced.

What about granting “Everyone” the right to ReplyToTicket"?

The best idea I’ve had so far is to remove the above replytoticket
access, and recode bits of rt(ir) to send the issue to the general queue
so a human can deal with it (i.e merge the issue with the right
investigation/incident report) but it all seems like a lot of work (and
also, it looks like mailplugins can’t currently modify anything other
than the mime object[1])

Thanks

[1] does anyone know if it is this likely to change soon? It seems like
useful functionality for plugins, particularly ::Filter’s, to modify
the queue an issue is going to, etc (?)

Have a look at RT 3.2.

3

In the cases where RT knows about them (e.g they’ve corresponded on some
other issue before) everything works fine, but where they haven’t (and
where we’re having issues), RT refuses to create a new user and their
reply gets bounced.

What about granting “Everyone” the right to ReplyToTicket"?
They already do (that’s the default, as far as I can tell)
; I’d like to not give them that right (so that random
users can’t add correspondence/comments to requests they have nothing to
do with) but also solve the problem of not bouncing legitimate updates
from non-correspondents

Thanks

[1] does anyone know if it is this likely to change soon? It seems like
useful functionality for plugins, particularly ::Filter’s, to modify
the queue an issue is going to, etc (?)

Have a look at RT 3.2.
I can’t see any differences (at least in lib/RT/Interface/Email.pm and
the plugins) that would allow the above (i.e if user does not have
permission, push request into “general” queue). Can you be more specific
about where I should be looking?

thanks

4

Have a look at RT 3.2.
I can’t see any differences (at least in lib/RT/Interface/Email.pm and
the plugins) that would allow the above (i.e if user does not have
permission, push request into “general” queue). Can you be more specific
about where I should be looking?

The EmailPlugins API was changed to provide more data to massage. I’d
thought that one thing we’d added was to let you munge the queue.
Perhaps I’m wrong.