As of today, I keep getting this error from Asana…
We couldn’t process your email because it was sent by jotform.com, but your email domain is wmca.org.uk.
Please contact your email admin to update your mail server’s email settings.
I have no control over the email server as it is coming from jotform with my domain address. It usually works, but as of today Asana doesn’t like the SMTP server it’s coming from.
Can this address be whitelisted or give us the option to whitelist?..or some sort of fix as this has halted my companies workflow.
Thanks.
6 Likes
I also am having the same issue with Asana and Jotform. It started today.
We are also having this exact issue with our Sendgrid mail server, we are receiving the same error and our external client can no longer create tasks. No changes have been made to this server, and the issue began in the last 24 hours. Please assist, is this a recent change made with Asana?
From: Asana
Sent: Tuesday, March 06, 2018 1:22 AM
To: MOPARKS
Subject: We couldn’t process your email.
We couldn’t process your email because it was sent by sendgrid.net, but your email domain is mo.gov.
Please contact your email admin to update your mail server’s email settings
Related case #553679. This is affecting our external client’s ability to create tasks in Asana, disrupting their workflow. Please assist in fixing as it appears to be a known issue with other customers on here, as well.
We’re also having this issue. I’ve emailed Asana support about it
Thanks folks! We appreciate you sending tickets about this. We’re aware of the issue and hope to have a solution soon.
5 Likes
Hello,
Starting earlier today we ran into issues with JotForm being able to import task into Asana. JotForm generates a email and sends the email to Asana. We now receive the following message.
We couldn’t process your email because it was sent by jotform.com, but your email domain is seiservice.com.
Please contact your email admin to update your mail server’s email settings.
We ave used this for months but just now started having the issue.
Hi Alexis,
Just wondering if there is any kind of update?
Thank you,
I’ve just had this email from Asana support:
Hi Design,
Thanks so much for your patience! As you’ve noted above we’ve recently made some changes to how we authenticate incoming mail to Asana. This is a security feature built to stop people spoofing your email address and creating tasks in your Asana Organization without your permission. This also means that Jotform is now unable to create tasks on your behalf by pretending to send messages from your email – however, there is a way to configure Jotform that will allow you to have it still create tasks in Asana for you, and by email, so you can continue to receive attachments as well!
It looks like you’ve set up the sender email in Jotform using the “verified email” option. With this option, Jotform essentially spoofs your address by sending the emails to Asana from Jotform’s servers. Instead, we recommend setting up your sender email in Jotform using the SMTP option. With this option, Jotform sends the mail through your mail server. Since it’s not spoofing your address, it’s not caught by our security filters. You can see details instructions on how to do this here on Jotform’s website – How to Set up SMTP for a Form.
My apologies for the inconvenience, but I do hope this helps! If you have any questions, or if there is anything else I can help you with, please let me know.
Thanks,
Ceri
I have gone back to them, as I am unable to get access to our SMTP servers. I’ve suggested that Asana should create a new option called “whitelist domains” or something so that the user has control on what domains can send emails in to Asana.
2 Likes
That’s the same boat we are in also.
2 Likes
This is the reply that I received from Asana support on my case last night:
Hi Jonathan,
Thanks for writing in and apologies for the trouble. We have some recent updates to strengthen the authentication of our users.
The reason you received this error is that we had trouble verifying that the email we received actually came from you. In order to protect your account from potential phishing or email spoofing, we require that your emails pass our updated authentication measures.
The mail server that sent that email is not properly configured for your domain. It must be configured so that the domain of the envelope address matches the domain of the from address.
In order to resolve this, could you please request your email admin to properly configure this mail server. They may additionally have to update the domain settings in order to give this server permission to send emails on behalf of this domain.
If you have any questions in the meantime, or if there is anything else I can help you with, please don’t hesitate to get back in touch.
Thanks,
Dave
This is unacceptable. If there was an update or change that was made to your authentication mechanism, you have to inform your users otherwise issues like this will occur. Obviously this is happening in other environments, also, and they are unable to resolve it internally per your suggestion. Our client’s workflow was severely disrupted and we spent several hours yesterday afternoon troubleshooting this issue, when the fault was with Asana the entire time, and now you are suggesting that WE have to fix this problem after no changes were made to our environment?
Please rollback to the previous version or advise on how to modify the product to make it work as it was previously before these recent authentication mechanism changes were implemented. Otherwise, we have to create a workaround internally to generate tasks that do not flow through our mail server. Regardless, you have to inform your clients if security changes are made to your product.
Thank you.
2 Likes
So here’s the latest from support…
Hi Design,
Thanks for your response! We are not specifically considering a whitelist option at the moment – but we are looking at what we can do to help mitigate these issues with services that send emails on behalf of customers without also matching SPF data. I’ve also highlighted the thread mentioned in the Asana Community to our security and product teams. We are currently looking at what options we may be able to provide for people who cannot access their SMTP settings to enter into services such as Jotform. Out number one priority is the safety and security of our customers’ data – but I will be in touch as soon as I have any further information.
My apologies again for the inconvenience. In the meantime if you have any questions, or if there is anything I can help with, please let me know.
Thanks,
Ceri
2 Likes
Our app uses SendGrid to post messages to Asana along with many other integrations. Can you folks revert to the old method of authentication and THEN consider options for better security? Asana making this change abruptly has disrupted many of our internal processes leaving us without time to find a workable solution.
2 Likes
I’m having the same issue, but not from JotForm, but from my email provider and hosting site.
Hi folks,
The members of the support team that you’ve spoken to are experts in this realm and I assure you that you can trust their counsel. I am sorry to hear that some of these updates have been frustrating to you. It’s helpful to know your thoughts here. At this time, the support team will be aware of your feedback and escalate it to the necessary folks on the product team.
Please let me or my colleagues know if there’s anything else we can help you with.
Thanks so much,
Alexis
Would adding the external accounts as an organization account bypass this new security authentication mechanism? They are currently set to guest accounts and getting rejected by the DKIM (Domain Keys Identified Mail) mechanism sent by our Sendgrid email appliance to Asana, which it does by default. I am assuming the new security features are implementing their own form of DKIM which is why the e-mails are getting rejected. The question is does the new mechanism ONLY apply to guest accounts, or organizational accounts also? Now we can disable DKIM on our Sendgrid server and whitelabel this domain, but this creates a security vulnerability in our organization for that domain, which we are trying to avoid. Please let me know if your engineers can test this and if this is an acceptable workaround unless you are able to roll back to the previous version or create a patch to fix this problem.
In the meantime, we created new e-mail accounts internally for our external customers to send requests to, then we created forwarding rules from Outlook to Asana for the corresponding task #. This fixed the issue but is obviously a less than desirable outcome for our external clients and a change to the previous ticketing process for them.
Let me know if your product team can assist further with these comments.
Thank you.
Hi folks! One recommendation we have for a workaround is auto forwarding. Have the Jotform info sent to one of your own email addresses, and then auto-forwarded from there to Asana. Guide article on auto-forwarding is here - Turning emails into Asana tasks | Product guide • Asana Product Guide.
1 Like
What about the people who aren’t using JotForm but are having the same issue. My email comes from a shared server ( I believe ) from which it is routed and shows up in the header. I was told by my host that it is impossible to eliminate from the header.
1 Like
Alexis thank you for the recommendation that is essentially what we have done to workaround this issue. However, it still needs to be resolved with a feature to disable DKIM authentication within Asana for certain hostnames (or just disable it entirely, making it optional). We cannot disable this feature on our mail server for security reasons and this would also involve a DNS change, and it looks like others here are also having this issue and facing roadblocks. So this isn’t a specific problem to JotForm but a change that was made to the authentication mechanism in how Asana receives e-mail requests. If your system now sees “On behalf of” in the authentication header regardless of source, it is dropping the request because it is trying to implement its own authentication mechanism and doesn’t recognize the sending party. This is something that absolutely should have been tested by the product team before being rolled out to live customer environments, or at least a warning e-mail should have been sent out informing Asana admins that this was a new security feature.
Looking forward to hearing back from the product team on this so our client’s workflow can be restored as it was originally before these changes were made.
Thank you.
1 Like
I’ll echo everyone that this is was both a poor product decision and a terrible roll out (or lack thereof). This silently broke our workflows with UserSnap. Right now, setting up forwarding rules isn’t an option for us either. Is there another workaround you can propose?
2 Likes