"Sophos Firewall was unable to send the following mail..." after upgrade to (SFOS 17.0.1)

Under Email go into General Settings.

In the SMTP TLS Configuration section, untick Disable Legacy TLS protocols or add the remote mail servers that are failing to the Skip TLS Negotiation list.

Originally disabled so I have tick and untick "Disable Legacy TLS protocols" before MR2 and even after Mr2.

Under Skip TLS negotation, I am not sure how to add the recipient's MX records as per the Advisory.

Thanks.

Here it is...

:-(

Might be worth using the Advanced Shell to check that the mta.conf file as mentioned in the advisory actually has a line for disable_tls1 yes.

To add the recipient's MX records, go to Hosts and Services, create an entry (hosts and/or subnets) for the MX records of the recipient domain (use dig or nslookup to get the MX records). Once the entries are created, go back to the Skip TLS Negotiation list and add the entries.

Failing that, lodge a support request referencing the KB Article number of the advisory, or dig through /var/tslog/awarrenmta.log to see how the individual SMTP sessions are failing.

Yes. Thank you for reminding me. I have look and look for the disable_Tls1 and even copied the entire log, 

but it is nowhere to be found. I will work on adding the MX records for these 3 domains. Thank you for that info regarding Hosts and Services.

Yes. Thank you for reminding me. I have look and look for the disable_Tls1 and even copied the entire log, 

but it is nowhere to be found. I will work on adding the MX records for these 3 domains. Thank you for that info regarding Hosts and Services.

Update:

I added all the MX Records of the 3 domain names in the SKIP TLS negotiation, but same problem.

I worked with the Finance Team and ask 2 users to send it from each of their computers and both have the same bounced back error message.

Under Email>General Settings>I click on Switch to Legacy Mode and left it on for few minutes.

While Sophos is on Legacy Mode, I ask the user to send the same email and it went through.

I will continue to look where I can disable the TLS 1.0 in Advanced Mode.

I don't know that the TLS issue is causing your problem.

We've got two customers we support.  One has an XG that we sold back in the v15 days.  We've tried multiple times to bring them into MTA mode since it became available in v16, and various bugs and incompatibilities have had us toggling back to legacy mode over and over again.  With v17 we have been very close, with the legacy TLS incompatibility being the only thing we knew of as a problem.  We have updated them to v17 MR2 and disabled legacy TLS mode via the GUI.

Meanwhile, our other customer has an SG currently running 9.502-4 who had some issues with TLS, and we were given instructions to edit its exim.conf file to disable TLS v1.  That's been in place for a couple months without complaint.

Today, coincidentally the first customer tried to send to the second customer.  "550 through this server without authentication"

The SG on the recipient basically shows "temporarily rejected after DATA: Temporary local problem, please try again!"

I'm going to try updating the SG to current (it's got 4 outstanding updates) and see if that helps.  Certainly adding it as a TLS exception does NOT.  I've done that explicitly at the XG end as a test, in addition to disabling legacy TLS entirely.  Our office has an SG on 9.504-1 and we're accepting mail from both customers just fine.

I'll update if this changes anything.

This is really interesting to know Paul Gazo 

Thank you for providing your insight/experience on this issue.

When Sophos Firewall was on Legacy Mode temporarily, the email went through and the recipient was able to respond back.

I am hoping to avoid going to Legacy Mode permanently.

I will update this once Sophos called me back regarding this issue.

I have updated the recipient end's SG to 9.506-2 (current) and rebooted.  No change.  Also, this is before re-instating the manual edit to exim.conf that disables TLS 1.0 on that unit.  (In this case, the legacy TLS needs to be disabled to pass PCI compliance scanning.)

Followup...

I found greylisting was enabled on the recipient's SG.  Hence the "temporary error".  The XG is considering that a fatal error and not retrying.  That's probably your issue.

Good luck.

Thank you very much Paul.  Glad to know you have resolved your issue. My SPAM Protection in my XG210 is actually disabled. I enabled Spam Protection (without Greylisting) and disable it again but no luck. Still trying to find a resolution...

You're welcome... but I think the issue isn't with the XG having greylisting enabled.  It's the recipient end, which you have no control over.  I got lucky in that this problem was between two of my customers, so I could work at both ends.

The idea behind greylisting is:

Sending server contacts receiving server.
Receiving server hasn't seen sending server recently (keeps a table), rejects the message with a temporary error code.
Sending server considers this a temporary failures, queues the message for retry.
Time passes.
Sending server retries contacting receiving server.
Receiving server recognizing sending server, accepts the message.

Spammers usually won't retry, if they're using crappy (malware) MTAs, so this technique can help a little bit.  But if the sending server (your XG and my sending customer's XG) can't handle the retries, it turns into a permanent failure.  Nothing you can do at the sending end.

I would recommend opening a case with Sophos if you haven't already, and offer up the experience I've had today.  They should be able to stage it with an XG and an SG and determine which software isn't doing it right.

Thank you for that. I just thought to try it on my end as there are currently 3 domains that we are having an issue with MTA mode on. And you are right, I have opened a case with Sophos since two days ago and still waiting for a callback from the escalation team. In the meantime, this forum has already helped me a lot :)

Update: Sophos Team called me back, however, without the live logs in debug mode there is nothing that can be done. Unfortunately, live logs is not possible at the moment. Sending to Domain1 already worked after enabling legacy mode in Sophos Firewall. That leaves with Domain 2 and Domain3. I cannot use Domain2 as testing because this is an email communication between two directors and Domain3 is more complicated to deal with. So I TEMPORARILY disable MTA mode so that the user can resend his email after waiting for 4 days. Moving forward, I will monitor for any bounced error message in MTA mode and capture the live logs in debug mode then call Sophos Support again.

On a side note: Since my SSL VPN is broken after MR2 upgrade, I will be going back to MR1 later today. I already recreated SSL VPN (Remote Access) from scratch and it is still not working. Again, thank you for everyone who provided assistance on this matter.

Summary and Update:

#1. Due to Mail Flow issue (Sophos Firewall was unable to send the following mail error...), I upgraded to MR2, however, it did not fixed the problem and it broke my SSL VPN (Remote Access).
#2. We are able to finally get a live log in debug mode when another user received the same bounced error message from Sophos Firewall.
@Paul Gazo is right, in Domain#4, we got the error "451 Internal resource temporarily unavailable". Nslookup shows that the MX of this domain is with mimecast. The link community.mimecast.com/.../DOC-1369 explains that the error is refused due to Greylisting. The thing about this is that my end user is able to communicate with these recipients prior to version 17.0 and 17.0.1 upgrade. In fact just a day before the upgrade, my users were able to send emails to these recipients. Anyway, the workaround to sending an email to the recipients now is to enable Legacy mode in Sophos Firewall and resend the message then re-enable MTA mode. 
#3. To regain my SSL-VPN connection, I downgraded to MR1. After the downgrade to MR1, I can no longer send an email to support@sophos.com. The error message is "User profile not configured". Support Team enabled TL1.0 and the emails to Sophos support were delivered.