Hi everyone,
This is an issue reported by @StrobeTech as well. We have open tickets: CHC-394-95623 / CS-5989 / CS-6926 and YRT-463-69963 / CS-5236
Could you please share your findings / resolution on here to communicate with Robin and get his opion, suggestions as well?
Ilker
I have my SD emails sending via office 365. Im using my own domain as the from address. I have configured my SPF records and tests I have done (hotmail) it goes to my inbox. Passes spam.
Hotmail does not use any real good spam detection
To give a little more information about this, the issue is the following: -
[C1] —Port 587 TLS Auth—> [Office 365 Incoming Server] —Incoming server does not like source—> [MS HRDP (High Risk Delivery Pool)] —Email to end user, but spam as HRDP on RBL—> [End user]
To combat this at the moment we send our ServiceDesk (SD) emails to our spam filter which then masks the source address and emails it out solving the issue.
If the issue with the source was fixed the route should look like this: -
[C1] —Port 587 TLS Auth—> [Office 365 Incoming Server] —Incoming server liked—> [MS Clean Pool] ------> [End user]
Pre spf they were going into the spam folder. Same as office 365. I’d be happy to send test email from my SD if you can provide an email to test ??
To me it would not make any difference as we have 100% of our Office 365 protection disabled and only our spam filter protecting us.
our domain is over the top protected if anything as we have SPF, DKIM, BATV etc…
our Office 365 is configured to route through our spam filter before outside world. SPF is not our issue, but you can send a msg to robin@strobe-it.co.uk and ill trace it back.
Ok, so I thought would do some more testing , now its not working !!
see post; https://c1forum.comodo.com/forum/products/service-desk/16905-ip-addresses?p=18002#post18002
looks like the sending IP has changed again !!. things just cant change without telling people, now my SD ticket emails systems is down AGAIN !!
Hi Robin,
We would like to make a remote session with you to test TLS Auth and get the logs related with the problem. But, we would like to be sure that you will not be affected on our tests. That’s why; I have asked our development team to develop a script that we will be used during our session with you. The script will enable us send your emails later if we face any problem during our tests…
We will contact with you as soon as our scripts are developed and ready.
Thank you
the problem is not with the authentication on TLS but after it hits their service as described above.
@dittoit the IP change should not make any difference to your email sending if it is configured correctly.
If configured correctly the ServiceDesk (SD) platform should be logging into your email using SMTP on port 587, so the IP is not important else you would never be able to use SMTP, OWA or RPC to access email without configuring the platform for each external IP you use.
With regards to SPF records, SD should not be listed at all as it is a client, only servers should be listed in the SPF record.
I hope this helps.
@StrobeTech I’m not using authentication, I’m sending directly to my MX record, I add the “from” IP so Office 365 allows the relay. I add the IP to my SPF as an authenticated sender.
This works perfectly until they start changing settings.
I see what you are doing; not the best way to have it setup and can cause the platform to be listed as a bad sender by MS meaning authenticated emails will be relayed out via HRDP and be caught in spam due to being on RBL lists.
Do you have this working? i have followed option 1 https://support.office.com/en-gb/article/How-to-set-up-a-multifunction-device-or-application-to-send-email-using-Office-365-69f58e99-c550-4274-ad18-c805d654b4c4 i can get the settings setup in the email section but a test send fails? i have never been able to get this working, i setup direct send and it all just works (untill the ip chnage)
im more than happy to use the AUTH route but i cant get it working.
P.S are you not having spam issues sending this way?
Cheers James.
Hi James,
the issues with Spam are down to the source (C1 platform) looking like it is a spammer which could be caused by people trying to use port 25 with it.
Because the source looks like a spammer MS sends the email to be delivered by the HRDP (MS bad outgoing email pool) instead of the safe pool. As it is the bad pool 99% of RBL lists have the IPs listed.
So the issue is not Comodo being blacklisted, but MS being blacklisted.
Comodo looks like spam so MS routes the message out via the spammy pool instead of the clean pool to make sure our normal connections on Outlook etc are not blacklisted.
Getting the Auth to work is easy, and I used to do this with the non-Comodo customised osTicket product; but at the moment we have special routing put in place for our spam filter to hide Comodo and route it differently.
Hope this explains a little more.
Nothing from Comodo???
Hi,
We are developing a code to add fall-back mechanism to not cause any problem at your side while trying our solution. Nevertheless, we focused on our major release to be deployed this weekend. After the release, we will focus on this. Thank you for your patience.