I have had a ticket in for nearly 2 weeks now, and have resorted to posting here in the hopes that it actually gets me a useful response. The ticket [#DCS-618-25286] has been escalated to the developers, but as yet, they haven’t provided me an update, despite repeated requests.
I have service desk setup to send emails through Office 365 using the Client Submission method. The diagnostics page on Service desk works without issue, as do new tickets and ticket assignments. However, responses sent from within the tickets are being blocked by spam filters at all customers due to SPF record check.
When checking the message header of the emails marked as spam, it appears that messages are attempting to be sent from the original SD email (c1notifications) using my domain name, rather than using my SMTP settings, but only for certain types of email.
Support did suggest that i add an IP address of the AWS instance to my whitelist, but this has not resolved the issue, especially given that the SPF failure is not coming from the address they gave. I am dubious of adding additional SPF IPs if i can, as the whole point of using the authenticated (Client Submission) method is that email is sent from a trusted party.
This is getting extremely frustrating, especially given that the only responses i get from Comodo are ‘its with the developers and they haven’t provided an update’. My customers are starting to get p*****d off with me for not recieving notifications to tickets that are being logged, and the workload on our end is doubled by my tech team having to send emails seperately, which are then not fully tracked.
I am the product manager of Service Desk. I totally understand your concerns.We will do our best to fix this. I will be following up with the issue and will give you updates on it as soon as possible. I also sent you a message on this issue.
Hi guys. I had this same problem, as you had little help from support. Here is what I did to fix it.
Grabbed the IP address from the message header of the blocked email.
Added that IP address to the allowed IP address connection filter under Protection in the admin center.
Continued until I found all the IP addresses they use. (I think it was only 1 or 2, if I remember right)
I already had all there domains allowed in the junk email allow list. So who knows if that did anything. Figured I better mention it just in case.
You should also download the Microsoft Office Junk add-on to outlook and make sure you unflag all those messages. This is the only way the reports make it to microsoft. I believe this to be on Microsoft’s side as they changed how they handle spam messaging but ATT was unable to confirm for me.
Hello @cascademanagement
Thank you for sharing with us your own fix to a similar dilemma. We went ahead and forwarded your own fix to the product development team in the hopes of formulating a permanent hassle-free fix.
Thanks @cascademanagement in the end, i added the IP into SPF filter and also as a SMTP Relay in our mail connectors, just to get emails working.
I have since been asked to ‘test’ to see if its working as expected by support, as if it is magically fixed, and as if i want to change and test in my production environment!
We added the 2 IP addresses listed in the Wiki article to our SPF record. The emails no longer go to Quarantine, but still go to the users’ Junk E-mail folders.
Hi @dbetlow
Since you mentioned that it is now in your users’ Junk folder, it is only a matter of setting up filters and/or marking them as Not Junk/Spam. (See also post #5 above.)
We have this working correctly now via Office 365; but this is because we do not let Microsoft route to the outside world. We route message to a Comodo KoruMail Spamfilter we host then out to the big wide world.
Doing this we have better control over the SPF, DKIM and DMARC which means we have no blocked messages.
The reason you get issues from Office 365 direct is that people configure SD wrongly which then ends up being spammy or access rights wrong. Due to this when Microsoft routes the messages from SD out they are using the High Risk Delivery Pool (HRDP) which is on nearly everyone’s block lists.
We are trying to use authenticated SMTP via Office 365 (in Comodo SD), but have not had any success. It gives a connection failed message. Perhaps Microsoft is blocking connections from Comodo? Failed to connect to smtp.office365.com:587 [SMTP: Failed to connect socket: Connection timed out (code: -1, response: )]
I apologise, just double checking and can see we have moved away from sending via Office 365 again and actually send via KoruMail directly.
As part of looking at this issue awhile ago we did find lots of users were not using authentication so would not surprise me if Microsoft are blocking access these days and would explain why we have jumped away again.
We do however use port 995 with SSL for receiving.
I am also having problems with them getting back to me with a ticket. It just sits there doing nothing. saying awaiting replay. replay from how? they never asked me anything. I keep trying to contact them to see if they need something from me, but nothing. THIS IS NOT GOOD. good thing I did put any of my customers on it yet I would be screwed. It’s too bad looks like something I could really use. I guess I will need to keep making Spiceworks work.
We appreciate your feedback and we can assure you that your reported case has been put on the highest priority possible to have the account deleted on the ticket you mentioned above.
We will notify you on the ticket (via email) when the task has been completed.
Thank you for your patience and understanding in this matter.
Yes. All information associated with your sign-up will be removed from our database. We will provide you an email confirmation once the process had been completed.