Ignoring out of office emails

I have a powershell script that emails users (using the System.Net.Mail class) and the “From” address is set to our RT system, making it easier for users to get help if needed.

The problem is, people’s out-of-office responses are opening tickets.

I added the “Precendence: bulk” header after checking through the RT lists as it looks like (at least in rt 3.x) it would filter those emails out and not interact with tickets. But it’s not working.

Is this no longer the case in RT4? Or does it not apply to ticket creation? I can see the Precendence: bulk header being added in the original email.

I was hoping to not have to modify RT/procmail, but I can go that route.

Thanks,
Brent

I have a powershell script that emails users (using the System.Net.Mail class) and the “From” address is set to our RT system, making it easier for users to get help if needed.

The problem is, people’s out-of-office responses are opening tickets.

I added the “Precendence: bulk” header after checking through the RT lists as it looks like (at least in rt 3.x) it would filter those emails out and not interact with tickets. But it’s not working.

Is this no longer the case in RT4? Or does it not apply to ticket creation? I can see the Precendence: bulk header being added in the original email.

The problem, as I understand it, is Microsoft Exchange. It sends out-of-office replies as ordinary messages, and doesn’t use any of the established methods which could be used to mark such messages, such as a Return-Path header of <>, or an Auto-reply header, or a bulk precedence header. It does, however, seem to add its own header:

Out of Office AutoReply:

so you could add something in RT’s bounce detection to detect that.

Regards,

Tim

The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

I have a powershell script that emails users (using the System.Net.Mail
class) and the “From” address is set to our RT system, making it easier
for users to get help if needed.

The problem is, people’s out-of-office responses are opening tickets.

I added the “Precendence: bulk” header after checking through the RT
lists as it looks like (at least in rt 3.x) it would filter those emails
out and not interact with tickets. But it’s not working.

Is this no longer the case in RT4? Or does it not apply to ticket
creation? I can see the Precendence: bulk header being added in the
original email.

I was hoping to not have to modify RT/procmail, but I can go that route.

The Precedence: bulk header you set is on your outgoing mail, but such
headers don’t get automatically copied back into any replies. Outlook
really shouldn’t be autoresponding to mail with that Precedence header
though. There may be magic Outlook headers documented somewhere that
will prevent and autoreply, and that would be the simplest solution.
(It may also be an option in the Exchange server.)

Also, to clarify RT’s behaviour: if RT receives email with a
Precedence: bulk header, it won’t send any mail about that transaction
back to the sender, but it still proceeds with any actions like ticket
creation, etc. It doesn’t just drop the mail.

procmail would be an easy place to filter these out before they hit RT
if you can’t find the magic header to set for Outlook/Exchange (if any
exists).

Best of luck,
Thomas

I have a powershell script that emails users (using the System.Net.Mail
class) and the “From” address is set to our RT system, making it easier
for users to get help if needed.

The problem is, people’s out-of-office responses are opening tickets.

I added the “Precendence: bulk” header after checking through the RT
lists as it looks like (at least in rt 3.x) it would filter those emails
out and not interact with tickets. But it’s not working.

Or perhaps you’re just spelling the header wrong and Exchange would
otherwise respect it. It’s spelled “Precedence” not “Precendence”.
This may be the most likely case. :slight_smile: