RT and email bounces

RT Users
1

Hi all,

When we send email to an address that doesn’t exist, ie, that bounces,
RT doesn’t record the problem in the ticket. So we could be in a
situation where we think that everyone knows about the ticket, but the
email address was wrong in the CC list.

Likewise we may be waiting for someone to respond to an RT but they
are on vacation - maybe this is deliberate to avoid loops? we don’t
see the vacation message so unless we send them an email via outlook
we wouldn’t know they were on vacation.

Does RT manage these bounces or should I configure/hack it a particular way ?

Thanks,
L.B.

2

Hi all,

When we send email to an address that doesn’t exist, ie, that bounces,
RT doesn’t record the problem in the ticket. So we could be in a
situation where we think that everyone knows about the ticket, but the
email address was wrong in the CC list.

Likewise we may be waiting for someone to respond to an RT but they
are on vacation - maybe this is deliberate to avoid loops? we don’t
see the vacation message so unless we send them an email via outlook
we wouldn’t know they were on vacation.

Does RT manage these bounces or should I configure/hack it a particular way ?

Thanks,

L.B.

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.

Cheers,
Ken

3

I think it’s difficult for bounced emails because there is no standard
regarding this kind of emails, so it’s hard to stop loops, but it
should be easier for out of office messages. The problem is that, I
think, we need to parse the email content to get a ticket number
unless the out of office keeps the subject…

I don’t know how RT discards this type of messages, it should normally
create a new ticket with “Out of office blabla whatever the subject
is” but it doesn’t on my system…

L.B.

4

I think it’s difficult for bounced emails because there is no standard
regarding this kind of emails, so it’s hard to stop loops, but it
should be easier for out of office messages. The problem is that, I
think, we need to parse the email content to get a ticket number
unless the out of office keeps the subject…

I don’t know how RT discards this type of messages, it should normally
create a new ticket with “Out of office blabla whatever the subject
is” but it doesn’t on my system…

–
L.B.

I have not checked the code, but usually there is a header that
indicates and auto-responder message ( a message that should not
be treated normally ). Look for a line with the word bulk or junk.

Ken

5

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

signature.asc (197 Bytes)

6

See rtbouncehandler on the wiki.

It works well, although it does double the amount of notices
you receive for SPAM messages since they typically use bogus addresses
which cannot receive auto-responses.

Cambridge Energy Alliance: Save money. Save the planet.