This issue is very confusing for our customers. Because they think they replied directly to the sender's email, they keep waiting for answers that don't come, and they get annoyed. Rightfully too. We've tried workarounds in our notifications: texts like "don't reply to this email" etc, but new customers still keep pressing the REPLY button. That's just how it goes.

Also: when Jira Service Desk is sending mails as an user, the contacts list of the receiving party get's polluted. This resulted already in sending emails to a no-reply email address and therefore it never reaches the intended party.

Why is this issue still under investigation?

Agreed!  See above comment from Markus ^^^.  It has been 6+ years and you are still "Gathering Interest"?  Come on Atlassian, this is poor showing.

WE NEED THIS URGENTLY TO GET THE E-MAIL CHAOS PRODUCED BY Jira UNDER CONTROL!

Hi

We  are waiting for this fix too. Any update here?

It is an important issue, lots of users send emails to agents on Jira Service Desk general email, so that emails are lost. We have to check the account and redirect them one by one and ask the user to update the agent email.

A general name can be great, but adding a prefix to the agent can solve most of problems.

ping

So fortunate we are still testing and haven't actually switched to Jira. It seems that the issue has been causing many miscommunications since 5 years ago. This is a severe bug particularly unfriendly with cloud versions, which we may have to give up.

Can we get an updated status on this from Atlassian ASAP?
We have all been waiting for a long time for you to Gather Interest.
It seems obvious to all of us that there is interest, and from some comments above, Atlassian is losing business because of this problem.

Just got back from Summit - how can you be pitching ESM and a "service desk for all teams" when this behavior still hasn't been addressed. How am I supposed to deploy dozens of service desks from a single instance with this behavior? Every time I add customers to a service desk project, I increase the occurrence of the issues reported above, and email replies don't reach their intended destination. Therefore I'm f&*%ing my customers.

vwong@atlassian.com help! I think we'll take any suggestions you have on viable workarounds at this point.

Same here- really need this fixed

Same here - confusing to our users, messes up Outlook cache (shows two emails for same person, one for Jira and the other their real address). I'll probably have to use automation to send email replies instead of built in Jira communications which is very unfortunate.

>> This shouldn't be a feature request, this should be a high severity bug 

@adam, that's totally correct. It totally messes up Outlook quick selects for all users. 
I have the impression that Atlassian sometimes lacks the feeling with "real life"...
Some request are pending for YEARS and or even later marked: "won't do". Frustrating 

I've just stumbled across this after deploying Jira Service Desk - the spoofed 'from' header is making our instance completely unable to send notifications to the majority of our users.

It makes Service Desk completely incompatible with any site that has deployed DMARC.

This shouldn't be a feature request, this should be a high severity bug as it renders service desk notifications unusable for any site with customers that have a mail server compliant with current best practice.

Christoph, we know it is working for mails. 
This topic is about : "not working for notification"  which is another mechanism. 

kind regards

If you go to Administration -> General configuration -> General settings -> Email from -> Remove $fullname (Jira) or type in another name e.g. Jira Service Desk System.

Agent name should be hidden now, tested it with 2 Mails. Don't know actually if it also works with automated notifications, we only use this for communication with external mail addresses

Hi Service Desk Team,

I agree. Please make this configurable as soon as possible because it is annoying and causes extra work in several cases. 

Thank you and have a great Christmas Time.

Kind regards

Rebecca

Count me in. This is indeed a very annoying missing feature.
It is working for mails, so why not for notifications ?

i know it takes time to evaluate, implement and test.
but >4 years ???? Come on

This continues to be an issue almost every day for us.  When an agent comments on an issue, the notification has the agent's name but Jira's email address (e.g. Paul Stallworth <jira@colorado.edu>).  Now, for all of our users that use Outlook, an autocomplete entry is now created for that incorrect email address.  So when a user attempts to send me an email, they start typing my name, Outlook's autocomplete kicks in, and the email goes to jira@colorado.edu  The email never makes it to me, the user is confused and frustrated as to why I'm not responding to their emails, and I don't even know I missed the email to begin with.

For regular Jira notifications we changed the email from to be "IT Projects on behalf of ${fullname}" in an attempt to avoid any confusion about where emails were coming from. Please put something on the roadmap to at least band-aid this problem. Even if it's just adding an additional configuration to specifying the "Email from" address for JSD-specific notifications.

Hello! 

It will be very useful instead of using own mail handler with souce email setter. 

Thanks

Recommend reviewing the solution I posted here back on 13/Jan/2017

As this issue was created in 2014, may want to re-consider use of "ASAP" in comments.

My CSR team really wants this suggestion implemented. 
They do not want their full names disclosed to end users in email communication.

One of my clients has problems because the Name and Surname is visible to the customer. Namely, after customer receives an answer from the agent, the customer starts conversation directly with the Service Desk Agent. Please take this feature into consideration! I will be very grateful (and I believe it will make not only my client happy )

Best

Dastin

I am quite surprised that this "necessary change" is still tagged as "Suggestion" and there is no action or even a comment from the Atlassian team about addressing this "must-have requirement". At least, keep this as optional choice for the JSD customers.

Our key customers are constantly complaining about this issue, when the mails are getting tagged as spam, and there is a demand to move away from JSD even after spending so much money on implementing this tool. Sad.

Adding a comment to give additional support to this issue being fixed ASAP.

Our organization is in the process of moving our support ops to JSD from FogBugz and our customers rely on email communications with our support agents. We need emails going to the customer to come from a 'generic' support desk name, NOT agents' full names. It's extremely disappointing that FogBugz can handle this without any issue, but JSD can't handle it.

Until this is fixed, I would not recommend Jira Service Desk to any customer support operations that rely on email as one of their support channels.

We just moved to JSD from Zendesk, and somehow missed that this was not possible.  Email support in general is poor (only one address can be handled?  Really?)...  In any case:

It should be possible to

1. Reply as a functional name ("Acme Support")
2. Reply as a personal name ("Annie Brown")
3. Reply as a combination ("Annie Brown (Acme Support)")

as a configured choice.  Some desks need a more personal approach, some need a more 'corporate' face, some want to take the middle road.  

Atlassian, could we please get a response?

I have been evaluating Jira Service Desk for the past few days. This issue has made me look elsewhere.

This is a really big issue for us. Our emails from Jira Service Desk is constantly getting caught in our company spam filter (as spoofed senders) and if there are enough our entire domain get's blacklisted for 48h. That's 48h that no one receives any notifications from Jira, Confluence, Jenkins and GitHub Enterprise. 

I would really expect JSD to follow Jiras configured behavior. 

Please fix asap!!

Thomas L. Kjeldsen, the Automation for Jira plugin also does not support sending of file attachments - it's on the plugin's roadmap, but not yet.

BTW, if you really hate the way JIRA Service Desk sends URLs to the file and forces people to login to JIRA to download. Then please post a comment here, JSDSERVER-3371

This issue is creating problems for our customers as well, where the mail they receive appears to be sent from their internal user but with our Support Team's email ID and their mail-system considers it to be a Spoof or a Junk mail.

We should be able to customize the "From" user-name for External Notifications, just like what is available on 'Email from' setting under 'System Configuration' which is used only by the Jira Notification Schemes.

Moreover, the problem is enhanced due to the way Jira Service Desk adds new users to the system. To add a new user under an Organization, the most common way is to add this user's email address as Customer under the Organization. This way, a new user account is created with the email-address getting filled up as the "Full Name" field. So, the notification ultimately goes out with From-name as "enduser@customer.com <supportteam@ourcompany.com>" which is considered as malicious by the customer's mail-system. Please see the attached escalation from our customer.

Unfortunately, we cannot implement the solution suggested by Justin due to software-security policies in place at our Organization.

Any other solution or workaround is welcome.

Thanks.

This is a follow-up to my previous comment. It turned out that notifications using the Automation for Jira addon does not support threading, so a correspondence would show up as a number of individual emails to the customer instead of being shown as one correspondence. This is tracked by Codebarrel in CBS-6824. We settled on a work-around similar to the one described by Justin.

I agree completely with all comments above. This is not only annoying, it is a shame that Atlassian is not able to give us a configuration place to change that parameter.

We just migrated from an in-house tool to Jira Service Desk (Server) for 350 Projects counting 1000 customers and 200 Agents, and we are in a crisis because Agents and Customers are replying to the notification instead of going in the portal for Customers or JSD for Agents, so our SLA are breached...

I agree this is annoying as hell, especially when users now have double entries in Outlook for the agent who answered him. The real email, and the alias of Jira. We are using the Cloud version.

I've been asked by Atlassian support to add a comment here. Two use cases where it is a requirement not to share the identify of agents:

1. In procurement vendors must not know the identify of internal agents. This is to prevent fraud, collusion and accusation of fraud/collusion.
2. Notifications from a helpdesk (portal only) with a large number of users should not reveal the identify of internal agents since this makes it possible for users to reach out to agents directly, which burdens individual agents and complicates audit processes.

Preliminary tests indicates that setting up notifications using the Automation for Jira addon could be a workaround as it sends out email notifications without a sender name. That said, it would be much appreciated with builtin support for hiding the identity of agents to customers. Fx by being able to specify a "Sender name" per project/email-channel. This could then take effect over both Customer notifications and the emails sent out via the JSD Automation rules, or perhaps there could be a "Hide agent identity" checkbox for each notification/rule.

Thanks for a great product!

When a ticket is created, email notification gets sent to the customer showing the name of the person who created the ticket - Agent (support engineer). This should remain anonymous.

When a ticket is answered, email notification gets sent to the customer showing the name of the person who answered the ticket - Agent (support engineer). This should remain anonymous.

I have already voted on this and seen the workaround but I am waiting for a solution from Jira.

Any feedback? A wrong explanation within the knowledge base makes this issue even more troubling (see https://confluence.atlassian.com/jirakb/how-to-change-the-sender-s-name-of-the-service-desk-notifications-933708029.html).

Does not look like Atlassian gives a dime about that issue so far. And customers are struggling because of it...

Thanks @Justin for the workaround!

This is also painful not just in email replies, but because mail clients of our internal customers will pull the wrong email for our service desk agents from 'recent contacts' when searching by name, making them accidentally mail the help desk creating erroneous issues. 

is there any update on JIRA SD beside Justin's workaround.

We require the same. Certain service desks don't want individual names displayed to the person submitting the request. Just a generic "Widget Support" type of display name. Please add!

Hi,

this is a key feature for a helpdesk solution to specify such settings.

When can we expect a solution for this?

@ivar if you're desperate for a fix (as I was) then try the solution I posted.

Desperately need a fix for this!

Here's a solution we came up with which works around this limitation in JIRA Service Desk. It uses Postfix smtp_header_checks to rewrite the headers of outgoing email. Providing instructions here to help other people searching for a solution to this problem. Hope it helps someone.

To rewrite the FROM name and FROM email addresses from JIRA and/or JIRA Service Desk:
1. Install Postfix either on this server or on another trusted server you can administer.
2. Configure the Postfix server to relay email to the Internet.
3. Now configure Postfix to rewrite the outbound emails from JIRA.
4. Create the smtp_header_checks file to set up the rewrite rules.
5. A simple rule (uses regex syntax) would be like:
/^From:.*jira-support@domain.com.*/ REPLACE From: Support <support@domain.com>
If JIRA Service Desk sends an email from "Bob Agent" <jira-support@domain.com> it will be replaced with "Support" <support@domain.com>, standardising the FROM name of the email from JIRA Service Desk.
If the Customer triggers a workflow and the email has the customer name:
"Customer Name" <jira-support@domain.com> will be replaced with "Support" <support@domain.com>
You can add as many rules as required and target any part email header.
Useful if you have multiple email addresses that JIRA Service Desk sends from.
6. Edit the Postfix main.cf file, typically /etc/postfix/main.cf
7. Add the line: smtp_header_checks = pcre:/etc/postfix/smtp_header_checks
8. Restart Postfix
9. In JIRA Admin, /secure/admin/OutgoingMailServers.jspa Change the Outgoing Mail, SMTP Mail Server to use a Postfix server as the destination.
10. All email from JIRA and JIRA Service Desk will be delivered via Postfix.
11. Test and verify OK.
12. Adjust configuration as per your requirements.

This solution was based on this answer in the CentOS Stack Exchange, http://serverfault.com/questions/717719/how-can-i-strip-or-rewrite-the-senders-name-of-a-from-address-when-using-postfi#answer-724468

Please fix. Thanks

A must have! This is causing JIRA to be seen as a tool that creates confusion. I'm attaching an example on how a double entry appears in outlook and opens the door to many communication misunderstandings. Please let me know if you need any extra info on this.

All related issues are closed even this bug hasn't been solved.

Here https://jira.atlassian.com/browse/JSD-3597 I found it was cloned as https://jdog.jira-dev.com/browse/QUALITY-483 but we have not access there => we don't know the actual state of this issue.

This suggestion is the reason why we can't open the mail channel for creating issues because of people don't look in their Outlook auto complete address (mail) and read the name and send it to JIRA.

This is a very annoying problem for many teams I have rolled this product out for. Please consider prioritizing this request. I'd rather not have to push customers to make their own accounts just to vote on this issue, but I can say it's pretty universally loathed.

I assume this will be resolved as part of a larger theme to rework the email notification portion of the product.

aliciam My workaround is to change our staff "Full Names" to be "Firstname Lastname (via tech support)".

But we'd much prefer it if this was fixed and JSD would honour Jira's config for From name.

This is quite an annoying problem. Anyone know of a workaround?