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

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

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


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

    Sometimes I post some useful tips on my blog, see blog.pijnappels.eu/category/sophos/ for Sophos related posts.

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

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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? 

  • BAlfson said:

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


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

    Sometimes I post some useful tips on my blog, see blog.pijnappels.eu/category/sophos/ for Sophos related posts.

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

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


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

    Sometimes I post some useful tips on my blog, see blog.pijnappels.eu/category/sophos/ for Sophos related posts.

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

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

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