same on my site need this feature soon

Hi Guido,

There was some feature which let you enter safe domains, but it was not working for emails coming from some external Jira instances. These e-mail kept on being blocked and marked as "Bulk e-mail". This was due to the presence of some headers in the email...

I think it was fixed around August 2019

https://jira.atlassian.com/browse/JSDCLOUD-1924

By that time I had decided to give up, but now I accidentally found out it was fixed and it is actually working fine.

Thomas

Thanks. I think this feature has been there since at least a year. I have entered our company domain there in May 2019 so it must have been there back then already.

Hi Jason.

Sorry for late feedback (vacation times...)

We thought the purpose of white listing was that users whould not have to be registrered one by one as customers on an project, but that incoming mail from all addresses with this domain would be accepted?

At least that is what we need and was hoping for....

BR

Catrine

Hi catrine.lundstrom,

It's great to see that you're trying out the permitted list!

The list allows all mails to pass the filters for users who are on your site. In this case, it appears that the user sending the email is not registered on your site and your settings do not allow an issue to be created. I'd request that you send an email corresponding to a user that already exists on your site to test if the feature works and check your Jira Service Desk global and project settings.

If that still does not work, I'd encourage you to create a support ticket so you can share details of your instance with the team. If you do end up creating a support ticket, feel free to share the ticket number with me so I can ensure that this gets resolved quickly.

Thanks,
Jason

Thanks for the update in Jira on this issue.

However – I added a domain name in the permitted list.

But when testing, mail is not imported to Jira and the log says: "Signup is not currently avilable".

 What does that mean?

katja.huss, thanks for your question. The current plan is to allow users to whitelist trusted domains which will bypass the email filters. We do not plan to provide an option to disable filters at this stage. 

@Jason D Cruz: Will be the mentioned alternative "provide an option to disable any of the above mentioned mail filters from the Service Desk Email settings section" implemented, too?

Hi everyone, Posting a follow up to my earlier comment.

We're currently in development and are doing some early testing. We'll send out release notes and provide an update here when the feature goes live.

Thanks for your patience as this has been a long requested piece of functionality.

Hi everyone - I'm a Product Manager on the JSD Cloud team.

Just wanted to confirm that I've reviewed this feature suggestion, and can understand the value that it would provide.

This is under active investigation and has been added to our roadmap.  I will provide another update in a week or two.

Support was able to remove the "auto reply header" filter from our cloud instance.  This allowed us to receive automated emails into Jira.  I had to open a ticket with them, prove that workarounds were not effective, and show that it had an impact to our business.  They said this isn't a setting they typically modify for cloud users.  Hope that helps!

Thanks! Interestingly, I'm not seeing any failures, but we know for a fact that replies sent via our OOO responses are not getting through to create comments on SD tickets.

@Esther Storm:

Jira Settings -> Products -> Email Requests, then under Email Addresses click "View Log" under the Actions column for your incoming email address, then click "Processing Log" tab.

@esther, you have to go to "Email Requests" in the admin page, I just use the search and you'll be able to find it. It's not very detailed but it's probably what you're looking for. I can see all the attempts and all the times associated with them.

@Paul Bruno - how are you reviewing rejected emails? I know when we were on Server I could look at the incoming mail logs, but as a recent emigrant to Cloud, I haven't figured out how to see that info yet, or even if it's possible. 

I agree Paul - the inability of a Helpdesk platform to accept mails from other Helpdesk platforms, because someone decided it is a good idea to block mails, based on the header, without the option to turn this behaviour off is completely incomprehensible!

I would not be able to recommend JIRA in its current form to anybody in good faith.

I was just reviewing all the e-mails rejected by Jira Service Desk this morning and was reminded of this ticket.  The lack of progress surrounding this ticket is a very good reason to not continue using Jira Service Desk in the future.

This major bug is now entering it's 5 year. How can such a glaring omission be allowed to carry on for such a period of time?

Just consider a very common scenario:

• a multi-level Service Desk
• each level is managed by different companies
• they all use Jira for everything, manage issues, send automated emails in case of escalation to another level

This implies that an email exchange between different Jira instances must be put in place. But as of now this is not possible.

Am I wrong?

This is a very serious issue for our company, we are not able to receive tickets from one of our biggest clients becuase they autoforward all of their email. I'm hoping this can get moved up on your priority list.

Anybody using a Jira SD Cloud  instance that receives email requests from another Jira istance managed to find a workaround for the issue?
Is there any way to strip the header "Precedence: bulk" from the e-mails ?

Any suggestion appreciated

A workaround for auto-replied emails originating from Exchange/Office 365 is to add a "Modify" transport rule to remove the "Auto-Submitted" header from the email that is going to the JSD email address.

IMO this should not be a suggestion but a bug. A help desk ticketing system should allow the administrator to accept any incoming email from their organization domain or not, regardless if such email is automated or not, and regarding of what header is set.

As long as an email address is added as a valid user, the system should not stop a message coming from that email address and that is specially true if the MX records for the originating domain are correctly configured with SPF, DKIM, and DMARC records and if the email complies with the imposed security rules.

To allow configuration to stop certain emails based on any other rules is a nice to have and in fact that functionality could be an enhancement.  This feature is simply upside down. It is a design flaw.

We would appreciate if this is changed to bug and addressed ASAP. In our case this issue together with the lack of audit logs is making us consider alternatives in the market.

I second the comments above. We are receiving legitimate issues from customers, sent in via email from other ticketing systems, which are blocked, because they include a Precedence header set to bulk. The workaround is not something we can tell external customers to use, whitelisting would go a long way here.

@Joshua - no, mail comes from predefined reporter. In order to get spam, person would have to know your internal or external email address AND fake-mail that address with FROM: address that matches exactly what you set-up to allow as Reporter. You can do further processing once issue is created in Automation, like look for specific text on subject line to classify the issue, auto-close it, update, etc.

Even if we cannot disable this function, are we able to see specifically the content of the emails that are being flagged as auto-reply?

We can see the subject of the email by looking at the processing log but that's all. It would be good to see specifically the emails themselves to find out why they are being flagged and make changes on our end to try and compensate.

Hi Nicholas, doesn't that mean that email that was sent could also let in the "jira@framestore.atlassian.net" generic email? This would cause it to generate even more spam too.

Hello. For me, temporary work-around has been to set-up new Mail Handler under Incoming Mail.  [yourcloudinstance].atlassian.net/secure/admin/IncomingMailServers.jspa and configure it to Accept the email for processing under Bulk. This allowed "auto-submitted" incidents to flow into ServiceDesk from 3rd party monitoring tools. JIRA Support advised us to contact vendor to change their mail generation which is not going to happen - I mean why would/should they? They followed IETF guidelines. Atlassian needs to enable same feature within ServiceDesk, not just regular inbound mail handler. There is extra $ cost associated with this since now we need to pay for every Reporter account to preserve origin of the alert/issue. Yes, it's possible to just set default Reporter account in mail handler but then our Automation and transition of incoming alerts is not going to work as well. 
Basically, Atlassian needs to fix this, add white-listing of from: accounts or their network origin (for firewall), and also allow more than TWO inbound email accounts per ServiceDesk project. 

Please correct this issue.  I see it as a major bug.

We also have the same issue with service-now emails. There should be the ability to whitelist domains, why is this so hard.

We have same issue with gmail - clients help desk mails are considered bulk.

Any ideas?

Anybody having an idea about similar settings for IBM lotus notes server settings similar to the settings posted by @Josh on 06July2017. Request you to share the settings screenshot

Regards

We have subscribed to Atlassian Cloud.

Our servicedesk operation is impacted seriously due to lack of this white-listing feature, as the mails forwarded to the email channel via our corporate mail provider is being blocked by atlassian.

Please note that not all mails are spams. The white-listing will certainly help many customers.

Pleas suggest a solution available for IBM Lotus Notes, till the time white-listing feature is available to us.

Regards

I can appreciate workarounds exist with various mail exchange configurations but the fact remains that when purchasing a cloud support ticket system that comes with an incoming mail handler that you would be able to manage what emails are received or rejected. It should be the users decision to whitelist a domain and ensure that the domain is never blocked. Please prioritize this.

@Eugene, the settings are in the Office365 Exchange Admin Center.  Then Mail Flow -> Rules.  You will need admin rights to your O365 tenant.

@Josh, thank you for your reply! 

Could you please specify where exactly you've been able to set the rule above? 

I go to O365 -> settings -> Mail -> Automatic processing -> Inbox and sweep rules ... 

The only option in email  rules I see are the following ones: 

http://www.qopy.me/NosnudqhTq6Rl3ME3sahXA 

Thank you for your help!

@Eugene, I was able to find a solution for this out of O365.  You can setup a mail rule that catches any mail sent from your forwarding inbox and remove the "Auto-Submitted" header from the email on the way out.  This is what Atlassian is using to catch emails that are auto-forwarded.  Attached is a screenshot of the rule.  This also allowed us to prepend some text to the subject line and have JSD run some automation on that text string when it arrived at JSD.  

We use more than 1 support email address to interact with our customers. We have configured forwarding as per Atlassian recommendation for exactly such cases: https://confluence.atlassian.com/servicedeskcloud/receiving-requests-by-email-747602718.html (at the bottom). However it did not work.
ALL email that we are trying to forward/redirect are being stopped by the filter (AutoReplyMailFilter). How's forwarding supposed to be working as per Atlassian documentation ? Which email services were tested for this feature and/or recommended for using?

Whilst forwarding is not a problem with Gmail - (cos it sends a confirmation email when you setup forwarding and then, if confirmed, does NOT add 'auto-submitted' flag into forwarded email) - it IS a problem for Office365. Office365 it is more like a solution for business, so it is very surprising that this hasn't been taken into account by atlassian...
Email forwarding feature is essential for our operations and, without any doubts, for JSD product itself. This is a showstopper for companies with multiple customers and JSD projects.
—
Looks like the only solution is to use JSD API, which is NOT an option in some cases as stated by @Josh Youngblood above.
If anyone managed to overcome this problem - please share your experience here.

thank you

I can echo the same issues as the other users.  We are trying to forward alerts and other IT admin emails generated from our systems to JIRA but they are blocked by this filter.  A simple whitelist feature to always allow those emails from certain emails where we know we are sending from would be a perfect solution.  The workaround mentioned in this issue does not work for us because we can't call the JSD API from an Office365 mailbox, which is where the forwarded messages come from.

@tom how are you managing this in your organization? We are having the same issue. It's very frustrating to not be ale to workaround this in anyway.

While the workaround mentioned in the description would work as an alternative for the creation of tickets through the use of the API, it doesn't stop there when you want to integrate further than just having a one-shot automated alarm system entering a ticket: replies from Servicedesk should be procesable by the originator and follow-up-mails from there should also get added to the ticket in Jira. So we're looking at the other side possibly having to implement a full flow of triggers/hooks and API calls to keep the issues in sync.

Simply allowing emails to pass through the filter (by whitelisting) would enable the default creation of tickets AND the linking of follow-up emails to the these tickets. Letting each side handle its own flow based on emails – typically available out of the box.

Which, by the way, was already available in older versions of Cloud servicedesk by just letting us disable the AutoReplyMailFilter.

Being able to edit these filters is a crucial part of the ticket flow and email requests. 

We have the same problem in JIRA Service Desk, when a customer replies the emails are seen as Auto Reply mails by the "SD Auto Reply Fliter" handler, and we are not able to disable the sdAutoReplyFilter even as Admins.

We have the same problem in JIRA Service Desk, forwarded mails will be seen as Auto Reply mails by the "SD Auto Reply Fliter" handler, and we are not able to disable the sdAutoReplyFilter even as Admins.

This causes a problem for us, we want to use a central email adress with a forwarding rule to forward mails to JIRA in order to create issues through email requests.

no, i cannot disable the SD bulk filter. 

I can request it to be disabled by support - however, with any new version of JIRA cloud, the filter is enabled again.....

Pieter you can disable the email filter module, though it's not ideal.

https://answers.atlassian.com/questions/12911940/sd-bulk-filter

I just want to disable the SD bulk filter at this point - as it only gives us issues, while it does not add any benefits we not already have from our email provider......

Being troubled by this issue as well. I hope that Atlassian can build in some sort of function to allow an administrator to modify or improve the filter query/datapoints. Or at the very least, a whitelist as this issue recommends.

upvote.

thanks @tom.tabruyn - i've contacted support.

@Pieter, the menu is still there, but relocated:

• Administration -> Add-Ons
• Manage add-ons
• Application Components (in the 2nd dropdown box)
• Jira Service Desk: expand
• 228 modules enabled:: expand
• SD Bulk filter / auto reply filter / SD sent from jia filter: disablen

Note that I disabled my auto reply filter there a couple of weeks / months ago, but at this very moment it says for all 3: "Module cannot be modified". You might still want to contact support directly...

With the new and improved service desk feature - this is no longer an add-on that is managed through the add ons.

Therefore, I cannot disable the SD bulk mail handler...causing important mails to be not processed by jira.

Any workarounds?