Recipient verification failing

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? 

  • Seems that your mail server is handled by google servers. The verification process is UTM-Google.  

    Try to search here in forum or Google to make "google smtp less secure" or even trust your UTM IP by Google

  • In reply to oldeda:

    No, this was a gmail account sending mail to my mailaddress behind UTM (which is from the UTM again forwarded to Office365).

    In the past there was no problem in recpient verification, but it seems right now there is a problem. Strange thing is this problem doesn't occur from every source, gmail is just one of the sources that doesn't work, but there are others also not working. When it fails it always seems to fail on recipient lookup and then when no positive lookup occurs, no mail is accepted and the sending party gets a message that delivery is postponed (however in case of gmail, this message appears hours after the mail was sent).

    For now I have just disabled recipient lookup and everything seems fine, but there is of course a reason that this is not recommended.....

  • In reply to apijnappels:

    Just curious - what is the benefit of using the SMTP Proxy with Office 365?

    Cheers - Bob

  • In reply to apijnappels:

    Taking a guess:

    It seems to me that callout verification might be used for directory harvesting -- using a sufficient number of iterations of the question, "Is this a valid user?"

    Consequently, I suspect that Microsoft has decided to periodically stop answering the question because they suspect your device of directory harvesting, and the problem has appeared recently because they recently adjusted their defenses without telling you.

    I suggest checking with Office365 support to see if they have configured there environment to trust your UTM.

    Also suggest using Active Directory mode instead of Callout Mode, if possible.   AD mode would be an authenticated query, while callout mode is (I believe) is an unauthenticated query.

    P.S. --- Does anyone know if "Active Directory" mode also supports LDAP Authentication Servers? 

  • In reply to BAlfson:

    BAlfson

    Just curious - what is the benefit of using the SMTP Proxy with Office 365?

    Cheers - Bob

     

    Whenever UTM is the MX record for the domain, I get all checks (spam, malware, sandstorm) before sending it to O365. Also users get a daily quarantine mail from UTM and they can easily click in this mail for releasing mails from quanrantine. In O365 is this a lot harder (for the end user).

  • In reply to DouglasFoster:

    Just saw your post under 9.510 indicating that AD verification works and that disabling TLS negotiation is an alternative (albeit unacceptable) workaround.

    So, is the problem unique to a specific version of UTM?

  • In reply to DouglasFoster:

    I do suspect such a thing indeed; for now I don't do any checking at all an just forward the mails to O365 and will have them check for validity of mailaddress. I can live with this.

  • 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.

  • In reply to Thorsten Langer:

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

  • 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.

  • In reply to DouglasFoster:

    DouglasFoster

    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.

  • 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