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: 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: * Return-Path: <> - basically it's blank * X-Auto-Response-Suppress: DR, RN, NRN,OOF, AutoReply - contains two additional settings not found in the works@B header* RN - Suppress read notifications from receiving client * 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?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Email handler discarding legitimate emails

Andrew Pratt

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: &lt;xxxxxxxxxxxxxxxxx&gt;
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:

Return-Path: <> - basically it's blank
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?

Accepted answers

Andrew Pratt

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?

All comments

Michael Knight

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.

Andrew Pratt

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.

Andrew Pratt

Hi Michael,

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.

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

Andrew Pratt

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud