Recipient Verification with Exchange 2013

Using callout doesn't work anymore. As mentioned here

exchange 2013 recipient filtering

the recipient filter works different as in Ex2010:

I have also noticed that Recipientfiltering doesn't work exactly the same way as in EX07/EX10.
When enabled, you should get an 550 5.1.1 User unknown after the ending period (see below)


mail from:
250 2.1.0 Sender OK
rcpt to:
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
Write some Text Here
.
550 5.1.1 User unknown


Is this a known issue for development?
  • Toltol, does recipient verification work with Active Directory?

    Cheers - Bob
  • Try Bob suggestion 
    Exchange2013 is more secure than older versions, I think you should google how to trust UTM as Smarthost
    Exchange sends the emails through the NIC gateway (UTM IP), but this is not the way this is the easy way
  • In reply to BAlfson:

    Toltol, does recipient verification work with Active Directory?

    Cheers - Bob


    Yes, verification with AD works fine.
  • Although verification with AD indeed works fine with Exchange 2013, is possible to get callout working also. It involves tweking Exchange 2013 RecipientFIlterConfig. I'll lay down what I just did to get this working.

    First of all, make sure you have Anti-Spam Functionality enabled on your Mailbox Server. To do so, check with Exchange Management Shell:

    Get-TransportAgent


    This show provide you with all Transport Agents avaliable on you system. Make sure you have this displayed:

    Recipient Filter Agent                             True


    If Recipient Filter Agent is not listed, then Anti-Spam Functionality was not enabled during setup. You can enable it by running this on the shell:

    & $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1


    After enabling Anti-Spam Functionality, run Get-TransportAgent again and make sure Recipient Filter Agent is available and enabled. If it's available but disabled, run this to enable it:

    Enable-TransportAgent “Recipient Filter Agent”


    Restart Exchange Transport service after making any modification mentioned above.

    Now let's make sure your accepted domains are using AddressBook for cheching valid recipients. By default, this should be enabled when you set Exchange as an authoritative Mailbox Server for your domain. To chek it, run this on the shell:

    Get-AcceptedDomain | Format-List Name,AddressBookEnabled

    It should provide you with a list oif all accepted domains and if AdressBook is enable or not. If ny any chance Exchange is Authoritative and AddressBook is disabled for some reason, enable it with:

    Set-AcceptedDomain  -AddressBookEnabled $true


    Or, to enable for all domains (caution, make sure you are not relaying any domains before runing this)

    Get-AcceptedDomain | Set-AcceptedDomain -AddressBookEnabled $true


    Just to be safe, restart Exchange Transport service again after making any of the changes mentioned above.

    Now you should have Recipient Filter enabled on you Mailbox Server and AddressBook enabled on you domain. But, if you test this now, it probably still won't work. That's because Validation is still disabled. There's one more step to take to get this working. To make sure it's disabled, run

    Get-RecipientFilterConfig | FL Enabled,RecipientValidationEnabled


    It should return that Recipient Filter is enable, but validation is not:

    Enabled                    : True
    RecipientValidationEnabled : False


    To enable it, run:

    Set-RecipientFilterConfig -RecipientValidationEnabled $true

    And now you shoud get Recipient Validation enabled:

    Get-RecipientFilterConfig | FL Enabled,RecipientValidationEnabled

    Enabled                    : True
    RecipientValidationEnabled : True


    Restart Exchange Transport service and test it. Callout should work now, at least id did for me (domains are removed for obvious reasons):

    220 utm... ESMTP ready.
    EHLO main...250-utm... Hello ... [192.168.1.121]
    250-SIZE 52428800
    250-PIPELINING
    250-STARTTLS
    250 HELP
    MAIL FROM:250 OK
    RCPT TO:250 Accepted
    RCPT TO:550 Address unknown
    quit221 utm....com.br closing connection


    As you can see, it accepted the valid address and denied the invalid one. To make sure callout was used:

    2013:10:03-09:27:25 utm-1 exim-in[17340]: 2013-10-03 09:27:25 [192.168.1.121] F= R= Verifying recipient address with callout
    2013:10:03-09:27:25 utm-1 exim-in[17340]: 2013-10-03 09:27:25 id="1003" severity="info" sys="SecureMail" sub="smtp" name="email rejected" srcip="192.168.1.121" from="giovani@....com.br" to="ti49@....com.br" size="-1" reason="address_verification" extra="Address unknown"


    And that's it for Recipient Verification with Exchange 2013. Just to tune things up, disable any AntiSpam feature on Exchange that could hurt UTM-Exchange communication. Here's what I did:

    Set-SenderFilterConfig -Enabled $false
    Disable-TransportAgent "Sender Filter Agent"
    Set-SenderIDConfig -Enabled $false
    Disable-TransportAgent "Sender ID Agent"
    Set-ContentFilterConfig -Enabled $false
    Disable-TransportAgent "Content Filter Agent"
    Set-SenderReputationConfig -Enabled $false
    Disable-TransportAgent "Protocol Analysis Agent"


    You should endup with only Recipient Filter enabled on the Transport Agent:

    Get-TransportAgent

    Identity                                           Enabled         Priority
    --------                                           -------         --------
    Transport Rule Agent                               True            1
    Malware Agent                                      False           2
    Text Messaging Routing Agent                       True            3
    Text Messaging Delivery Agent                      True            4
    Content Filter Agent                               False           5
    Sender Id Agent                                    False           6
    Sender Filter Agent                                False           7
    Recipient Filter Agent                             True            8
    Protocol Analysis Agent                            False           9


    Since UTM should handle all AntiSpam checks, it makes sense to disable them at Exchange.

    Hope this helps!
  • Here is the reason for this behaviour:

    exchange 2013 recipient filtering

    (...) this is expected in Exchange 2013. Recipient Filtering is only present on Mailbox server role. Client Access Role will proxy SMTP session to Mailbox server but CAS will not effectively manage the Recipient filtering part.

    In fact, CAS needs the RCPT TO information in order to determine the best Mailbox Server to which it can proxy connection to. Connection from CAS to MBX will be established only after DATA being received by CAS from external SMTP server. CAS will pass to Mailbox server SMTP commands it received from external SMTP server. That is why you observe that "User unknown" only at the very end of the session.


    and the workaround:

    The workaround is to create a new receive connector of type HubTransport scoped for the IP addresses of your front-end MTA's.  Limiting the scope will cause them to be used.  HubTransport receive connectors do recipient validation correctly just like previous version of Exchange.  


    Testing it with the default HubTransport connector listening on 2525 (have to enable anonymous access on this connector):

    sophos:/root # telnet ex2013.company.de 2525
    
    Trying 192.168.***.***...
    Connected to ex2013.company.de.
    Escape character is '^]'.
    220 ex2013.company.de Microsoft ESMTP MAIL Service ready at Tue, 18 Mar 2014 20:39:41 +0100
    ehlo local
    250-ex2013.company.de Hello [192.168.***.***]
    250-SIZE
    250-PIPELINING
    250-DSN
    250-ENHANCEDSTATUSCODES
    250-STARTTLS
    250-X-ANONYMOUSTLS
    250-AUTH NTLM
    250-X-EXPS GSSAPI NTLM
    250-8BITMIME
    250-BINARYMIME
    250-CHUNKING
    250-XEXCH50
    250-XRDST
    250 XSHADOWREQUEST
    mail from:toltol@external.com
    250 2.1.0 Sender OK
    rcpt to:sadfasdf@company.de
    550 5.1.1 User unknown
    ....



    So you can add another HubTransport connector on port 25 just for your UTM (configured in the RemoteIPRanges) and use callout as with EX2010. 
    Of course you have to setup recipient filtering as described above too.

    Tobias
  • After some further research I would recommend to use "In Active Directory" for verification. Setup another HubTransport connector isn't as simple as expected because the "Frontend Transport Service" will always be in front of any "Transport Service" connector. Perhaps you can get it done with an additional IP at the EX server. Here is an interesting picture for the mail flow:

    Exchange 2013 Mail Flow Demystified

    Tobias
  • In reply to toltol:

    giomoda what you have written is very nice guide which helped us with exchange 2010 and the callout feature not working.

    I configured our exchange 2010 as per your guide and callout is now working for our exchange. I believe previously we had set an external relay as one of the domains which caused exchange 2010 to allow any user even after we set it back to authoritative and rebooted the server.

    Thank you very much.
  • In reply to toltol:

    unfortunately AD checking is iffy at best. i just enabled it in one of the utms i manage and it started bouncing everything with "Address not present in directory",

    the AD server was setup correctly and tests ok.

    i can't set any DN as the recipients are scattered all over different OUs

    i had to go back to callout(non functional)

  • In reply to Mast_01:

    Mast, what does Support say about this - do they acknowledge a bug not documented in the KIL?  I assume you and the others checked ID24065 and followed those workarounds.

    Cheers - Bob

  • In reply to BAlfson:

    Strange, my AD is working fine. It only bounces the correct recipients ie the ones not in AD and my base is DC=mydomain; DC=com

  • In reply to Louis-M:

    Louis, are your users in multiple OUs?

    Cheers - Bob

  • In reply to BAlfson:

    Yes they are and that caught me out in the beginning too.

    I was told that everybody was in the same OU and configured the base OU as such. Everybody got email but certain groups (outside of the base OU) got rejected.

    I then set the base OU as DC=mydomain; DC=com and everything works.

    The majority of the time, the spam filter kicks it out for RBL's etc as expected. But if the mail does get past, everybody gets the mail they should and the odd attempt says "recipient not in directory" which is 100% correct in my case. So it's definitely working on my SG 310's on 9.4