quarantined email release fails

Hi Adrie,

No issue reported yet. Check in the smtp.log when you release the quarantined mail, do you see any errors? 

"Releasing has recently gone wrong on my macos Sierra machine." Did you mean that the emails are releasing perfectly through a Windows system?

Thanks

I wouldn't know, I do not have access to a windows PC. 

What I know is that, on the same macos machine, Firefox and Chrome are working.

Cheers. Adrie

The first three results on google.com and google.nl are the same, and each describes what to do.

Cheers - Bob

I have had my chances with google a couple of times before, thank you  :p

I did try the suggestions with HSTS and cache clearing etc. but none of the suggestions solved my issue.

I'm sorry that those weren't helpful, Adrie.  I don't ever remember this being an issue here though, so I have no other suggestion.  It works perfectly in Safari on my iPhone.

Cheers - Bob

For the moment I entered the ipv4 address instead of the fqdn. 

En het werkte?

That points to a problem with DNS  configuration.   How does your setup differ from DNS Best Practice?

Cheers - Bob

Hi,

Well yes, that's what I meant by when I use the ip-address the release works fine. However I am quite sure this is not a dns issue while the http(s) request always reaches the proper server instantly, there is no dns request noticable (like eg. when root-servers are queried, because of no or bad forwarders are used)

The issue here has to do with misuse of https for a http request which I am not able to pin-point (aaargh)

Thanks anyway for helping.

Regards. Adrie 

Hello, 

Has a fix been found? We're having the same issue. Whenever our Chrome users click on the Release link on the Quarantine report, it will redirect the request from http to https, which results in the page not loading and the ERR_SSL_PROTOCOL_ERROR. 

Is there a way to make the Release link use https instead of http? 

Thanks!

Did you try a Google on stop chrome from redirecting to https?

Cheers - Bob

I haven't tried it yet. The thing is this is happening to all of our users who use Chrome on their personal PCs. They are so many I can't manually apply that Chrome fix to every one of them. 

I was looking for a fix on the UTM side of things, so that way the problem will be fixed for everyone. 

This suggestion is an experiment, and I give it a 10% chance of success.  In Webserver Protection, define a Real Server on "Internal (Address)" as HTTP (not HTTPS) using the port you've configured for the Quarantine Report.  Next, define Virtual Servers on "Internal (Address)" and "External (Address)" that use HTTPS on the same port.  Please report your results.

Cheers - Bob

This suggestion is an experiment, and I give it a 10% chance of success.  In Webserver Protection, define a Real Server on "Internal (Address)" as HTTP (not HTTPS) using the port you've configured for the Quarantine Report.  Next, define Virtual Servers on "Internal (Address)" and "External (Address)" that use HTTPS on the same port.  Please report your results.

Cheers - Bob

Thanks for your suggestion! But, unfortunately, I don't have a WebServer Protection license so I can't access that feature. I only have a Network Protection and Email Protection license on my UTM.

Your reseller can get you a 30-day trial license for Full Guard so that you can test this.  Full Guard costs less than the combination of any three of the five subscriptions included.

Cheers - Bob