Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Subscribers 6 subscribers
  • Views 15606 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Recipient verification failing

apijnappels

We've had several problems receiving mails from different domains lately (all delivered to our UTM (primary MX-record) and all to be routed to another host (mostly Office365)).

Today I went for a more thorough search and found out that whenever I have Recipient verification (with callout) selected, which has always been selected in the past, it fails with a lot of addresses (all valid) hence the mail is simply rejected.

Here's what is shown in the logfile (masked real mailaddresses):

2018:07:12-23:18:48 utm-2 exim-in[26983]: 2018-07-12 23:18:48 [209.85.161.171] F=<***@gmail.com> R=<***@p***.**> Verifying recipient address with callout
2018:07:12-23:18:48 utm-2 exim-in[26983]: 2018-07-12 23:18:48 TLS error on connection from mail-yw0-f171.google.com [209.85.161.171]:34565 (renegotiation not allowed): error:00000000:lib(0):func(0):reason(0)

 

When I set to No verification, mails are allowed and routed to the external mailbox correctly.

The fail is also seen when using https://www.checktls.com/TestReceiver for sending to a mailaddress. Once no verificiation is setup this site also gets a "OK".

Is there some reason verification is failing? 



This thread was automatically locked due to age.
Parents
  • 0

    Noticed this today too, was wondering about lack of incoming emails. I use SMTP callout on a Exchange 2016 on premise. Worked. Until I installed 9.510 obviously. If callout is active I also got the message logged: (renegotiation not allowed): error:00000000:lib(0):func(0):reason(0). Disabling smtp callout recipient verification it works again.

  • 0 in reply to Thorsten Langer

    So the problem applies to more than just Office365, and is specific to 9.510?

  • 0 in reply to DouglasFoster

    I am not sure about this. I have to admit I didn't look regularly in the smtp proxy log the last two or three updates. But this error message is new for me in 9.510 and I have no O365 stuff. I also didn't look any further but I think there is a problem with TLS and SMTP communication from my UTM to my Ex2016 on premise.

  • 0 in reply to DouglasFoster

    DouglasFoster said:

    So the problem applies to more than just Office365, and is specific to 9.510?

     

     

    No Douglas, not specific to 9.510 since I'm still on 9.509.

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0 in reply to apijnappels

    Hi,

     

    this error seems to come with 9.510 and server callout.

    The error seems to be only for incoming TLS1.2 connections and callout to Exchange with TLS1.0/1.1. (Exchange 2010 and Server 2008/2008R2)

    Seems there is a config enabled not allowing to downgrade TLS during such sessions.

    Maybe helps: https://www.msxfaq.de/signcrypt/tls.1.2.htm, switch Exchange 2010 and Server 2008 to have TLS1.2 as Standard and 1.0/1.1 as fallback only.

     

    Switch to only TLS1.2 will not work, because Exchange behind might not be able to do TLS1.2. 

    There are even bugs in Exchange 2010, even TLS1.2 is configured, it is not used as standard.

    To be checked viceversa, incoming TLS1.0/1.1 and Exchange only TLS1.2.

     

    I have raised a case to check this.

    May

    Astaro user since 2001 - Astaro/Sophos Partner since 2008

Reply
  • 0 in reply to apijnappels

    Hi,

     

    this error seems to come with 9.510 and server callout.

    The error seems to be only for incoming TLS1.2 connections and callout to Exchange with TLS1.0/1.1. (Exchange 2010 and Server 2008/2008R2)

    Seems there is a config enabled not allowing to downgrade TLS during such sessions.

    Maybe helps: https://www.msxfaq.de/signcrypt/tls.1.2.htm, switch Exchange 2010 and Server 2008 to have TLS1.2 as Standard and 1.0/1.1 as fallback only.

     

    Switch to only TLS1.2 will not work, because Exchange behind might not be able to do TLS1.2. 

    There are even bugs in Exchange 2010, even TLS1.2 is configured, it is not used as standard.

    To be checked viceversa, incoming TLS1.0/1.1 and Exchange only TLS1.2.

     

    I have raised a case to check this.

    May

    Astaro user since 2001 - Astaro/Sophos Partner since 2008

Children
No Data
Unfiltered HTML