[rt-users] RT and email bounces

[Dominic Hargreaves]

On Mon, Jan 25, 2010 at 07:38:38AM -0600, Kenneth Marshall wrote:

> RT handles bounces by ignoring them to prevent loops as you
> suggested. It would be neat to have some error handling that would
> update the ticket with the message statuses without sending E-mail.
> You could disable bad addresses, for example, or flag a vacation
> response.
> 
> I can see a definite use for such functionality, but the devil is
> in the details. Sending an E-mail message for any of these items
> would almost certainly end very badly.

I've been dealing with this issue at our installation recently.
We have migrated from RT2, which set the return address to a form
of address ticket-bounce-nnnn which would effectively record a
comment on the affected ticket. We did have occasional mail loops set
up as a result (if the AdminCC address in question bounced) which I
assume is why the functionality was removed.

However recording and communicating bounces is an important function
for us to I have, so that we can detect that (for example) an email
address was mistyped.

As a result I have deployed a modified form of the BounceMerge
scrip action found on

http://wiki.bestpractical.com/view/BounceMerge

on our bounces queue (having previously set the envelope address in
$SendmailArguments to an address pointing to our bounces queue).

The modification is to also send out an email to owners/adminccs,
but being careful to avoid a loop by:

- sending with an empty return path
- sending with a 'from' address which doesn't point into RT (the
  RT owner address)
- not including the body of the email (to avoid content filters)

It doesn't use any of the normal RT architecture for sending out
these emails because we want to have very tight control over the format
to avoid loops and other undesirable behaviour.

In general BounceMerge works well, and ends up with the relevant
details on the original ticket where it is most useful.

It's also important that this doesn't change the status of the
ticket (to avoid other scrips sending out problematic mail) which
means that it's important that we send out a notification by email
so that issues are caught when relevant by humans. For example if
a ticket was previously resolving, it'll still be kept as resolved.
The message I send out suggests that the ticket may need to be
reopened by hand once the cause of the bounce has been analysed.

There are a few issues still to work out, but if people would be
interested I can post the details to the wiki when I'm finished.

-- 
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20100125/363ab862/attachment.sig>