Error: 602 Attempted to send the message to the following IPs:

Question asked by YS Tech - 1/4/2024 at 8:56 AM

Unanswered

I seem to be getting a few errors sending emails to addresses that I know are ok (I've sent ok from other addresses to it).

Is anyone else getting this since the latest updates v8762?

43 Replies

Reply to Thread

YS Tech Replied

1/4/2024 at 9:29 AM

This also includes when I try to send a test to ping@tools.mxtoolbox.com:

Error: 602 Attempted to send the message to the following IPs: 44.210.42.52, 34.233.112.144

I can send from a different domain on my server (same IP) to ping@tools.mxtoolbox.com fine!

Any idea what the issue is?

Brian Bjerring-Jensen Replied

1/4/2024 at 9:38 AM

We are seeing the same. Lots of 602 errors at the moment.

YS Tech Replied

1/4/2024 at 10:56 AM

What's confusing me is that I can send to the email address using 1 domain on my server but not another. Both using the same IP, so it must be something to do with the domain that I'm sending from?

Any idea what it could be as all my setup looks ok according to mxtoolbox (server setup wise anyway as I obviously can't test the failing domain).

Kyle Kerst Replied

1/4/2024 at 10:58 AM

Employee Post

The 602 error is unfortunately a generic error and doesn't tell us much about why it failed. Can you do a search in your Delivery logs for the offending to address and include related when you search? Any exceptions/timeouts/other complaints jump out at you there? Please be sure to obfuscate any logs before you post them!

Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com

YS Tech Replied

1/4/2024 at 11:28 AM

Hi Kyle, it looks like the local binding IP is not correct (it's one of my old IP's that hasn't been used for months).

[2024.01.04] 00:30:38.667 [26911768] Sending remote mail from sending@domain.com

[2024.01.04] 00:30:38.693 [26911768] MXRecord count: '1' for domain 'to.co.uk'

[2024.01.04] 00:30:38.693 [26911768] Attempting MXRecord Host Name: 'to.co.uk', preference '10', Ip Count: '1'

[2024.01.04] 00:30:38.693 [26911768] Attempting to send to MXRecord 'to.co.uk' ip: '77.68.7.68'

[2024.01.04] 00:30:38.693 [26911768] Sending remote mail to:to@to.co.uk

[2024.01.04] 00:30:38.693 [26911768] Initiating connection to xx.xx.xx.xx

[2024.01.04] 00:30:38.693 [26911768] Connecting to xx.xx.xx.xx (Id: 1)

[2024.01.04] 00:30:38.693 [26911768] Binding to local IP 217.172.129.141 (Id: 1)

[2024.01.04] 00:30:38.694 [26911768] Binding to local IP 217.172.129.141 failed.

[2024.01.04] 00:30:38.701 [26911768] Connection to xx.xx.xx.xx from mycurrentip succeeded (Id: 1)

[2024.01.04] 00:30:38.765 [26911768] RSP: 220 domains.com ESMTP Postfix (Ubuntu)

[2024.01.04] 00:30:38.769 [26911768] CMD: EHLO mymailserver

It then gets to:

[2024.01.04] 00:30:38.812 [26911768] CMD: STARTTLS

[2024.01.04] 00:30:38.843 [26911768] RSP: 220 2.0.0 Ready to start TLS

[2024.01.04] 00:30:38.867 [26911768] Certificate is expired as of 17/11/2021 12:43:09.

[2024.01.04] 00:30:38.868 [26911768] Attempt to ip, 'xx.xx.xx.xx' success: 'False'

[2024.01.04] 00:30:38.868 [26911768] Removed from RemoteDeliveryQueue (0 queued or processing)

[2024.01.04] 02:46:15.385 [26912069] Added to RemoteDeliveryQueue (1 queued; 0/50 processing)

----

Checking the valid one that did send, this also tries to bind to that IP, but it sends successfully. So that's not the issue although it shouldn't be trying to bind to that IP (any idea why?)

YS Tech Replied

1/4/2024 at 11:48 AM

I have disabled the "enable TLS if supported by the remote server" and this has cured the problem.

I'll check the certificates I have to see what's happening there.

Thanks

YS Tech Replied

1/4/2024 at 12:29 PM

Kyle, where does it reference the correct certificate in SM?

I have a few but only 1 is valid, so shouldn't it just use that one?

Settings > SSL Certificates >

I need to find out why it's referencing the old server IP address as well, as its not setup with that IP anywhere in SM any more?

Kyle Kerst Replied

1/4/2024 at 12:49 PM

Employee Post

Good find! First, the outbound IPv4 address might be defined in the domain's settings, or in Settings>Protocols>SMTP Out at the system level. To correct this long term you should be able to bypass certificate checks in Settings>Protocols>SMTP Out and then reenable TLS so your outbound mail is still going out securely. Ideally though you'll want to reach out to that third-party mail server and advise them to get their certificate updated as soon as possible.

As to which certificate is used; the one being selected as the "fall back certificate" (if there isn't a better cert available for that hostname) is defined in Settings>Bindings>Ports in your SMTP port. We'll attempt to use a certificate for the domain in question, but failing that we'll move to the fallback certificate to secure the connection.

Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com

YS Tech Replied

1/4/2024 at 1:19 PM

Now binding successfully, not sure why it was picking up an old IP that's never been installed on this server though?

The email that fails is being sent to mxtoolbox, I find it hard to believe that they may have an out of date cert?

[2024.01.04] 20:16:15.464 [26915013] RSP: 220 2.0.0 Ready to start TLS

[2024.01.04] 20:16:15.646 [26915013] Certificate is expired as of 08/04/2020 13:00:00.

[2024.01.04] 20:16:15.647 [26915013] Attempt to ip, '34.233.112.144' success: 'False'

[2024.01.04] 20:16:15.647 [26915013] Attempting to send to MXRecord 'postfix-mxping-public2-a52a3b849fba7a64.elb.us-east-1.amazonaws.com' ip: '44.210.42.52'

[2024.01.04] 20:16:15.647 [26915013] Sending remote mail to: ping@tools.mxtoolbox.com

David Fisher Replied

1/4/2024 at 1:59 PM

Looks like tools.mxtoolbox.com MX records do contain an expired SSL Certificate, as indicated by :

https://www.checktls.com/TestReceiver

YS Tech Replied

1/4/2024 at 2:49 PM

Well, there you go. Thanks David.

Jack. Replied

1/4/2024 at 2:51 PM

This error is common when sending Smartermail emails to Linux servers.

If you send many emails to Linux servers and they use the CSX firewall, the IP of your Smartermail servers will be blocked when it exceeds the number of connections configured in CSX.

I have investigated and we did some tests, when the number of connections is exceeded the firewall blocks the IP of the Smartermail server, if we add the IP as secure to the CSX firewall the problem does not occur and the emails are sent satisfactorily.

masoud mohammadi Replied

1/6/2024 at 2:19 PM

This issue will be fix by uncheck "Enable TLS if supported by the remote server" but emails will send unencrypted and it's not ok at all!

Please rollback this feature to the 8655 build. I think 8655 is the most perfect version of smartermail. Unfortunately we upgraded some of our servers to the newer versions and this issue happened. I think you changed the TLS hand shaking method and it cause the error 602 issue. Please release the new version to fix this issue ASAP.

Thanks

Brian A. Replied

1/10/2024 at 2:32 PM

Can you have SmarterMail give a more detailed rejection notice than just "602?" If the user knows why the email got rejected, then they could let their recipient know to fix their server... (I know... I'm dreaming...)

Brian Bjerring-Jensen Replied

1/11/2024 at 12:55 AM

Still getting 602's despite turning it off.

Its DNS related.

Sébastien Riccio Replied

1/11/2024 at 6:56 AM

Yes, since we updated to 8644 from 8251, we also see a lot of 602 errors. Most intriguing is that these are linked to smartermail trying to communicate with some external SMTP servers. However we have an incoming and outgoing gateway, so SM isn't supposed to talk to the remote servers directly...

Please rollback this feature to the 8655 build. I think 8655 is the most perfect version of smartermail.

Where is build 8655 available, can't find it on download page...

Sébastien Riccio System & Network Admin https://swisscenter.com

Gabriele Maoret - SERSIS Replied

1/11/2024 at 10:38 AM

I'm monitoring the servers of recipients of these "602 errors"...

Testing the domain with MX toolbo, almost everyone I have tested has an SMTP destination server that fails the MXtoolbox SMTP test because they TIMEOUT.

So I think it's a problem on the recipient side, not on my SmarterMail server.

Example:

Gabriele Maoret - Head of SysAdmins at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)

Jerry Heinz Replied

1/11/2024 at 12:25 PM

I toggled off 'Enable TLS if supported by the remote server' at the domain level and it resolved the

issue for me, I will be doing it on a per-domain level as I see the 602 error occur. Perhaps the next
update will address it. Currently I am running SmarterMail Enterprise Build 8768 (Jan 3, 2024)

Mark Johnson Replied

1/11/2024 at 9:44 PM

Same issue here, upgraded to 8768 last night and now seeing 602 errors, including this one from gmail.com saying no MX!!

Error: 602 Failed to connect to the recipient's mail server. No MX records were found for the 'gmail.com' domain. Status: 544 5.4.4 Host not found (not in DNS).

Also lots of these timout/transient DNS errors in the admin log that appeared after the upgrade

[2024.01.12] 15:03:00.981 [DNS Client] Exception: Query 24501 => gmail.com IN MX on 9.9.9.9:53 timed out or is a transient error.

have changed from google dns to quad9/cloudflare as suggested by SM with no change

thinking this version might be buggy .. ticket logged, awating response.

Brian Bjerring-Jensen Replied

1/11/2024 at 11:18 PM

In what log do you find that?? We have a lot of reported 602's but nothing in the logs.

Mark Johnson Replied

1/11/2024 at 11:35 PM

The 602 errors we see are from checking messages in the Waiting to Deliver queue .. which seem related to the DNS errors in the Admin log

Manuel Martins Replied

1/14/2024 at 4:07 PM

Hi,

Activating the option on "Protocols" menu , option "Bypass certificate validation checks" resolve the erros for us. Most of the erros were because of Expired Certificates on destination Servers.

Mark Johnson Replied

1/14/2024 at 4:12 PM

is that a security compromise though?

Mark Johnson Replied

1/14/2024 at 9:59 PM

Update ..

I changed the Smartermail DNS to use the server NIC (by setting it blank) as suggested by Tony recently and its reduced these "timeout/transient DNS errors" from 1700+ an hour to just 4 in the last 5 hours! Does that indicate a network issue with access to public DNS from our host machine perhaps?

Will continue to monitor, as these errors were not present prior to the upgrade last week.

Brian Bjerring-Jensen Replied

1/15/2024 at 10:15 AM

We use the same setup but has arror 602's.... disabling DNS Caching made the problem less occurent.

Dave Stuart Replied

1/15/2024 at 8:02 PM

I'm getting this 602 error when trying to send mail to shaw.ca domain email accounts. Is there something I can do to see what is blocking this? I know that's a general question, but all other e-mails work fine. The coincidence with this is that Shaw is also my ISP. How can I check if my IP address is doing blocked by shaw.ca?

Dave Stuart

Mark Johnson Replied

1/15/2024 at 9:22 PM

Anything in the logs? if you can see the message in the Waiting to Deliver queue, check the View Recipients option to see if there's an error there too ..

rick Replied

1/23/2024 at 5:41 AM

I'm seeing same issue here on build 8776. As soon as I disabled "Enable TLS if supported by the remote server" email was able to get delivered with no more Error 602.

Is there a known fix for this? I had to do this for another domain a week or two ago.

Mike Mulhern Replied

1/24/2024 at 2:50 PM

I have experienced the same issue.

Jack. Replied

1/24/2024 at 4:00 PM

>>>>

Activating the option on "Protocols" menu , option "Bypass certificate validation checks" resolve the erros for us. Most of the erros were because of Expired Certificates on destination Servers.

>>>>

Gabriele Maoret - SERSIS Replied

1/25/2024 at 12:33 AM

@Jack

I think you may be right, but this setting is marked in backets as DANGEROUS (see image below).

Is it safe to activate it???

Derek Curtis Replied

1/25/2024 at 4:23 PM

Employee Post

@rick -- if enabling that setting allows email to go through, chances are that means the recipient server has an expired certificate. The fix would be to get them to update their cert.

@gabriele -- "Dangerous" is a bit harsh, I suppose. After recent discussions, we have decided to change the name of the setting from 'Bypass certificate validation checks (Dangerous)' to 'Enforce strict certificate validation'. This setting will be disabled for new SmarterMail installations, which means that the default behavior going forward is to allow these outbound deliveries, even if the recipient's certificate is expired or mismatched, as we have found the risk to be minimal. (There was the potential for rogue certificates to be set up to intercept emails, but it's not likely.) If administrators want to tighten up their security, they can choose to disallow those deliveries, if desired.

Derek Curtis COO SmarterTools Inc. (877) 357-6278 www.smartertools.com

Mark Johnson Replied

1/31/2024 at 7:26 PM

Thanks Derek, so to confirm, you are suggesting we should disable the cert checks to avoid mail delivery issues with servers that have expired certs?

I'm ok with it as it saves our support team but it does let lazy email server admins off the hook a bit ..

Derek Curtis Replied

2/1/2024 at 8:26 AM

Employee Post

Mark

I just saying that there is a setting to avoid the 602 errors seen when attempting to send to a mail server with an expired cert. It's up to you whether to disable cert checks. Ideally it's a temporary issue that's resolved once the sys admin on the other end realizes they have an expired cert.

Derek Curtis COO SmarterTools Inc. (877) 357-6278 www.smartertools.com

Martin Schaible Replied

2/6/2024 at 3:03 PM

Hello

Since the last update of SmarterMail we see some 602 errors in the delivery log. The reason is always an expired certificate on the remote server:

00:55:00.813 [83801623] Certificate is expired as of 16.03.2023 07:02:27.

00:55:00.814 [83801623] Attempt to ip, '217.182.197.10' success: 'False'

00:55:00.815 [83801623] Removed from RemoteDeliveryQueue (0 queued or processing)

My point of view is this: Disabling the certificate check generates work and makes no sense. Sooner or later the administrator of the remote server will be kicked in his lacy back (Right words? :-)).

Cheers!

andrew knasinski Replied

2/24/2024 at 2:48 PM

We are seeing the 602 but not with certificate issues.

[2024.02.24] 07:15:39.805 [23511192] MXRecord count: '1' for domain 'xxx.net'

[2024.02.24] 07:15:39.953 [23511192] Attempting MXRecord Host Name: 'mailfilter.xxx.net', preference '10', Ip Count: '1'

[2024.02.24] 07:15:39.953 [23511192] Attempting to send to MXRecord 'mailfilter.xxx.net' ip: '15.204.249.50'

[2024.02.24] 07:15:39.953 [23511192] Sending remote mail to: jeannette@xxx.net

[2024.02.24] 07:15:40.010 [23511192] RSP: 220 mailfilter.xxx.net - Xeams SMTP server; Version: 9.0 - build: 6302; 2/24/24 8:15 AM

[2024.02.24] 07:15:41.022 [23511192] Delivery for cmoriarity@xxx.com to jeannette@xxx.net has bounced. Reason: Remote host said: 602 Attempted to send the message to the following IPs:

[2024.02.24] 07:15:41.026 [23511192] DSN email written to 813169252061 with status failed to jeannette@xxx.net

[2024.02.24] 07:15:41.026 [23511192] Process delivery status notification step from recipient success. Recipient: [jeannette@xxx.net], Notify: [], LastError: [602 Attempted to send the message to the following IPs:

[2024.02.24] 07:15:41.027 [23511192] Delivery for cmoriarity@xxx.com to jeannette@xxx.net has completed (Bounced)

Gerhard Queisser Replied

3/8/2024 at 6:30 AM

Yes, we get it every day and all the time. We have been trying for weeks to get rid of it somehow. But unfortunately all the changes, including those suggested in this forum, have done nothing.

SmarterMail Enterprise Edition

Version: 8825 (Feb. 29, 2024)

ActorMike Replied

3/13/2024 at 12:30 PM

We are having this same issue now. Is it from beefed-up security checks in the latest SM server to make sure the recipient has the correct SSL certificate etc?

[2024.03.13] 14:44:53.854 [63624749] Sending remote mail to: gemtronap@***.com

[2024.03.13] 14:44:54.236 [63624749] Delivery for don@***.com to gemtronap@***.com has bounced. Reason: Remote host said: 602 Attempted to send the message to the following IPs:

[2024.03.13] 14:44:54.239 [63624749] DSN email written to 1033817126286 with status failed to gemtronap@***.com

[2024.03.13] 14:44:54.240 [63624749] Process delivery status notification step from recipient success. Recipient: [gemtronap@***.com], Notify: [failure], LastError: [602 Attempted to send the message to the following IPs:

[2024.03.13] 14:44:54.240 [63624749] Delivery for don@***.com to gemtronap@***.com has completed (Bounced)

[2024.03.13] 15:26:49.938 [82282004] Sending remote mail to: gemtronap@***.com

SmP Replied

3/13/2024 at 1:56 PM

ActorMike, we had to not only disable the SMTP cert checks but also change the retry timing sequences and those two together seemed to have resolved the majority of 602 errors.

ActorMike Replied

3/13/2024 at 2:37 PM

Our retry timing is 5, 30, 90, 120, 1440, what did you change yours to?

I don't think my version of SM allows me to disable the SMTP Cert Checks. This is all I can do:

Brian Bjerring-Jensen Replied

3/13/2024 at 3:05 PM

I disabled DNS Caching and the 602 errors went away.

SmP Replied

3/13/2024 at 3:39 PM

Disable strict certificate validation and DNS caching -

That should help address most of the 602 errors

ActorMike Replied

3/13/2024 at 3:43 PM

@brian This worked! Since we've had this setting enabled for years, something that has happened in the recent updates has caused this IMHO. It didn't start until I updated SM.

Since that worked, I'm going to leave strict certificate validation enabled.

Back to Community Threads

Please leave this box unchecked