For the past 8 hours we have not been receiving emails because Comodo ASG is incorrectly rejecting emails sent to us with an SPF failure. This has been happening with many different domains that use Comodo for spam filtering.
Typical failure message is “554 This server requires you to send from an IP address specified by the SPF for ”
Anyone else experiencing this issue with ASG? I’m about to change our MX records to remove Comodo from the equation (again).
What is the sending domain and have you checked the senders SPF, I have had this were the sender has had the sending servers change due to isp or recover systms.
The sending domain can be anyone, it doesn’t seem to matter. The following is an example of a rejection message people are receiving when sending to us. In this example the email address recipient has been changed to XXXXX for privacy, but both domains in this example (sender and recipient) have incoming emails filtered through Comodo ASG. It has been working find in the same configuration for months and we have not changed anything recently.
This is the mail gateway at engclustn2.stage.casg.
I’m afraid I wasn’t able to deliver your message to the following addresses.
This is a permanent error; I’ve given up. Sorry it didn’t work out.
XXXXX@itregister.com.au:
<from:XXXXX@human-performance.com.au to:XXXXXX@itregister.com.au> 122.102.97.103 does not like recipient Remote host said: 554 This server requires you to send from an IP address specified by the SPF for human-performance.com.au.
Giving up on 122.102.97.103 qid: 18566-1529999769-150589.
Unless I am missing something I do not see the IP address 122.102.97.103 listed in the spf for human-performance.com.au but I do see the MX records for itregister.com.au.
Is this correct?
Correct, the email was sent from a different IP address for human-performance.com.au which is in their SPF, but for some reason Comodo appears to be thinking it is coming from the itregister.com.au IP address, who is the recipient. It appears to us that ASG is checking the receivers SPF record and trying to match that to the sender…
I seem to recall having a very simlar issue a while back and after Comodo support were informed they found a solution. Have you raised a ticket? If not I would.
Keep us informed about this error, just checked a few of my clients and all seems to be OK atthe momment.
Yes I logged a support ticket. About to remove Comodo ASG from the X records for 25 domains we manage as this is causing us huge issues.
Also forgot to add that human-performance.com.au is set to send via Comodo (i.e. smart hosting). Plus we do actually have the MX for itregister.com.au listed in their SPF record (which is 122.102.97.103) not that we’re using it currently.
From what I saw the human-performance.com.au SPF does refer to the MX records of the domain itregister.com.au but 122.102.97.103 is not an MX record for itregister.com.au maybe think about include instead of just MX
As I said human-performance is sending via Comodo anyway so that is irrelevant, plus nothing has been changed and it was working fine for many months like this.
But I suspect I found the problem:
On a test email I just sent myself from human-performance it showed the sending server was mxsrv2.spamgateway.comodo.com [144.168.192.81].
But we have the SPF record for that domain set to match it’s MX records, which are set to mxpool1.spamgateway.comodo.com (144.168.192.80) and mxpool2.spamgateway.comodo.com (144.168.192.80). Neither of those IP address match the sending server.
Did Comodo change or added a sending server in the past 24 hours that does not match the sending servers? We were told by Comodo to configure SPF this way…
Remember we use the EU settings but this is now I have my DNS setup for our clients using ASG.
MX records:
mxpool1.spamgateway.comodo.com. 10
mxpool2.spamgateway.comodo.com. 20
SPF records:
“v=spf1 ip4:AAA.AAA.AAA.AAA include:_spf.spamgateway.comodo.com include:servers.mcsv.net ~all”
AAA.AAA.AAA.AAA is edge mail server just incase we turn off smart host
mcsv.net is mailchimp for this user.
I have just noticed that
warn_msg = (2) Host ‘_spf.spamgateway.comodo.com’ not found. | Could not find a valid SPF record | 144.168.192.81
warn_msg = (2) Host ‘_spf.spamgateway.comodo.com’ not found. | Could not find a valid SPF record | 144.168.192.80[144.168.192.80]
Might be there is an issue with comodo.
Thanks, maybe I should try adding “include:_spf.spamgateway.comodo.com”? I think we used to use that but they told us to change it to mxpool1.spamgateway.comodo.com and mxpool2.spamgateway.comodo.com
Yeah I suspect someone changed something at 5PM their time and went home without testing. This has happened several times over the past 2-3 years. When they get into the office in a couple of hours time it will probably all magically start working again. Unfortunately it is now 8PM here so we’ve been dealing with this for 12 hours. Really is time we moved all our clients to Office 365 and dumped ASG.
I have just done some more testing and _spf.spamgateway.comodo.com is failing I bet they have changed something. Please ask them to reply to this thread about the correct SPF records as I think we are start to see failures.
Done. They are responding to me now which is good.
This is still not working. It is my opinion that what has happened is Comodo in the past 48 hours have added additional servers that forward emails to their customers, and those servers are no longer within the SPF range they previously advertised.
Their advice to me is to disable SPF checking on ALL inbound emails… which fine if all emails are coming from Comodo, but in some cases we have servers receiving emails from both Comodo and direct.
I give up.
For those following this thread we have tracked the problem down to emails being passed to us from Comodo via the server engclustn1.stage.casg (104.227.248.206).
We have had to temporarily whitelist this servers IP address to allow emails in
This server is not one of ours, and we can see in the email headers that it is last server in the chain when emails are passed to us from Comodo (see partial sample below). We have asked Comodo Support to confirm this is one of their servers, otherwise we may be looking at a hack of some kind…
Received: from XXXX.group.local (10.0.0.57) by XXXX.group.local
(10.0.0.57) with Microsoft SMTP Server (TLS) id 15.1.225.42; Wed, 27 Jun 2018
10:17:22 +1000
Received: from engclustn2.stage.casg (104.227.248.206) by XXXX.group.local
(10.0.0.57) with Microsoft SMTP Server (TLS) id 15.1.225.42 via Frontend
Transport; Wed, 27 Jun 2018 10:17:21 +1000
Received: (korumail 8318 invoked from network); 27 Jun 2018 00:17:16 -0000
Received: from unknown (HELO mxsrv1.spamgateway.comodo.com) (10.200.1.102)
by 0 with SMTP; 27 Jun 2018 00:17:09 -0000
Received: from mail-me1aus01on0061.outbound.protection.outlook.com ([104.47.116.61] helo=AUS01-ME1-obe.outbound.protection.outlook.com)
by mxsrv1.spamgateway.comodo.com
and the latest in this saga is we now have some customers telling us they can’t login to the spam gateway to check the quarantine queue etc. We can however login as the administrator.
The error being displayed from Comodo is as follows:
“Error 500. CASG has encountered an unexpected error. Wrong parameter: domain:domain_management:incoming_dq:retry: This error has been logged and our technicians will endeavour to correct this issue at the earliest opportunity”
I suspect all of this is related… anyone else experiencing these problems with Comodo’s EU servers??
At this time I and clients using casg EU servers have a normal service both login as admin or user works and mail not rejected.
I know it’s a bit late but I have clients with both casg and direct smtp inbound and use the firewall to route the requests inbound from ip address ranges to different ports so I can select which checks are done depending on where the email is coming from.
Comodo support have finally confirmed they did make changes on Tuesday which caused all these issues for us. They tried to initially blame this on our SPF configuration, but that is irrelevant as the primary issue is they added another set of servers and IP addresses on Tuesday without informing their customers.
As a result anyone who had firewall or other rules filtering incoming emails based on Comodo’s EU address range will be impacted until they add 104.227.248.192/28 to that range. We had previously been told by Comodo that only 144.168.192.64/27 was required for EU. They have also informed us they have since now updated their SPF record with this new range (unconfirmed by us).
The second issue we raised is we also could not access the user administration functions in the spam gateway since the above changes occurred, and none of our customers can login to check their quarantine queues etc. This issue is still on going. The following is their feedback but that does not resolve the issue for us:
After the latest changes, the users are automatically redirected from https://antispamgateway.comodo.com to https://antispamgateway2.comodo.com domain just after the login page. However, the problem could be related to the version of the browser that is being used or related to browser’s cache. Please try the steps below:
Will Comodo please update us with the correct firewall rules and SPF text ASAP. Can’t believe you make a change like this without telling us first and this is not the first time this has happened.
Day 5 and we still have numerous problems with Comodo ASG that their developers don’t seem to be able to solve which were caused by these unannounced and poorly tested changes:
1 - No end users can login to manager their quarantine, queues and Admins cannot manage Admins. Error being displayed is as follows. Only advice we have received is to clear browser cache etc etc., despite us telling them several times that this occurs on any browser with any PC, even on PC’s that have never used their website before. Sounds like they have no idea how to test in the real world:
Jun 30, 2018 12:42:43 AM CASG has encountered an unexpected error: java.lang.IllegalArgumentException: Wrong parameter: domain:domain_management:incoming_dq:retry java.lang.IllegalArgumentException: Wrong parameter: domain:domain_management:incoming_dq:retry. This error has been logged and our technicians will endeavour to correct this issue at the earliest opportunity
2 - Some emails with embedded attachments are coming through into Outlook as useless winmail.dat attachments. This usually means the encoding of the email has been ■■■■■■■ up somewhere. When we stop using Comodo ASG the problem goes away.
Needless to say we have had enough of this and have started migrating customers to MailGuard. This is the 3rd time in as many years that we have experienced significant problems such as this with Comodo’s ASG service and it has damaged our reputation.