Email handler discarding legitimate emails

I've got an email handler configured as "Create a new issue or add a comment to an existing issue" with the following settings:

Bulk: delete
CC Assignee: false
CC Watchers: false
Create Users: false
Default Reporter: emailreporter
Forward Email: <xxxxxxxxxxxxxxxxx>
Notify Users: false
Strip Quotes: false

Certain emails coming into our exchange server are forwarded to an imap server which is what the email handler is pointing at.

Emails from one address, call it works@B, come in and issues are created properly.

Emails from another address, call it nowork@B come in and appear to be deleted as bulk.

Examining the email headers, the differences found in the nowork@B header are:

  1. Return-Path: <> - basically it's blank
  2. X-Auto-Response-Suppress: DR, RN, NRN,OOF, AutoReply - contains two additional settings not found in the works@B header
    1. RN - Suppress read notifications from receiving client
    2. NRN - Suppress non-read notifications from receiving client

OnDemand documentation describes the Bulk setting:

This option only affects 'bulk' email messages whose header has either its Precedence: field set to bulk or its Auto-Submitted field set to no.

The email headers contain neither a Precedence: field nor an Auto-Submitted field.

Can anyone tell me why the email handler is rejecting this email as bulk?

3 answers

1 accepted

This widget could not be displayed.

Hi Michael,

Well, our IT folks changed the settings on the Exchange server to put the return path back in to the nowork@B emails and now they pass through the bulk filter when it's set to Delete. That's good. They found it also changes the X-Auto-Response-Suppress setting to match the ones found in the header of works@B.

But they weren't too happy about having to do that because they were using the empty return path to help prevent denial of service attacks on the public email address nowork@B.

Why does the OnDemand documentation not mention that the emails without a return path or with RN or NRN set in the X-Auto-Suppress-Response field will be filtered when the incoming mail handler is set to Delete? Are there any other "hidden" filters?

Are there any plans to give the user a finer grain of control on the Bulk filter? Perhaps white/black lists for email addresses?

This widget could not be displayed.

As far as I know, emails only legitimately have blank return paths when they're bounce messages. Obviously JIRA should not be processing these as replies.

If these are legitimate emails, you should investigate why they have a blank return path. It could be a problem relating to spam filtering software or some other configuration issue on your Exchange server.

Thanks Michael,

The blank return path is suspicious to me as well but my other searching indicated that the X-Auto-Response-Suppress is linked to Precedence so I wondered if OnDemand was doing something because it considered it bulk. I didn't mention it but changing the Bulk setting to Process, lets the email through from nowork@B.

I'll talk to our IT folks about the return path though and let you know if that fixes it.

This widget could not be displayed.

The two answers below sort of go together.

But I didn't get an answer as to why the Atlassian documentation doesn't mention this a one of the types of email that gets blocked.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Tuesday in Jira

What modern development practices are at the heart of how your team delivers software?

Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...

139 views 1 3
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you