Exchange 2013 Realtime Block List is Kind of Working


  • Hi Everyone.

    I've been setting up a RBL in exchange 2013 using The IPBlockListProviders require that the connection filtering agent be enabled. By default when running the installantispamagents.ps1, this script will not install that connection filtering agent because it only installs on an "edge" server and since exchange 2013 did away with the "edge" role, it did not get installed. I had to modify the script so it installed that connection filtering agent with all the other anti-spam agents. (We are a one exchange server shop so the CAS and Mailbox roles are on one box.)

    I'm having a very weird response. The RBL list works and when I get a test email sent to me using the service at '', I can see the Reject message getting sent back out in the agent logs and the SMTP logs. This is the message I see in the logs. Notice that the originating IP and the RBL triggering IP are the same:

    ,,<>,,t***********e@*****.org,1,Connection Filtering Agent,OnRcptCommand,RejectCommand,550
    5.7.1 has blocked your IP address ( using the list
    ''. Please see for further
    information. This organization has no control over this RBL (Realtime Blo,BlockListProvider,,,,,Undefined

    This is a correct message and that IP address matches the Test RBL IP address spamhaus has blacklisted to check RBL filters. The IP address is added dynamically to the message with a variable in the reject message settings and should list the IP address of the SMTP server that triggered the RBL hit.

    The VERY strange thing is when I trigger the RBL with the test message, exchange rejects all incoming mail for my account from any source for several minutes and rejects with that same message. I send a test message from my google account and I can clearly see in the agent log that the SMTP connection is coming from a google IP but it still rejects and issues the message that was sent in response to my test using the nelson-''

    This is the reject message sent to my google account after I sent myself an email following the RBL test message. Notice that the originating IP is a google IP and does not match the IP the the reject message claims the message came from. The log shows the originating IP as (A google IP) but im rejecting the message because is blocked??? The message didn't come from that IP. :

    t***t@******.net,,t*******te@******.org,1,Connection Filtering Agent,OnRcptCommand,
    RejectCommand,550 5.7.1 has blocked your IP address ( using
    the list ''. Please see
    for further information. This organization has no control over this RBL
    (Realtime Blo,BlockListProvider,,,,,Undefined

    After a couple minutes, it clears up and I can get mail again. I just can not for the life of me figure out why all messages are rejected for several minutes after I have an RBL hit and the reject message is always referencing the the SMTP transaction that originally triggered the hit. Which in this case, is blocking my Gmail message thinking its coming forom the test even when the smtp logs show a completely different SMTP originating IP and Connection.

    Here is my IPBlockListProvider:

    RunspaceId        : 068b87d2-9c34-4ce9-ab05-eedef928cb27
    RejectionResponse : {1} has blocked your IP address ({0}) using the list '{2}'. Please see 
              {0} for further information. This organization has no control 
                        over this RBL (Realtime Block List).
    LookupDomain      :
    Enabled           : True
    AnyMatch          : True
    BitmaskMatch      : 
    IPAddressesMatch  : {}
    Priority          : 1
    AdminDisplayName  : 
    ExchangeVersion   : 0.1 (8.0.535.0)
    Name              :
    DistinguishedName :,CN=IPBlockListProviderConfig,CN=Message Hygiene,CN=Transport 
    Identity          :
    Guid              : 0c9b5eec-b19a-4ab5-9c6a-cb1666cf68d6
    ObjectCategory    :
    ObjectClass       : {top, msExchMessageHygieneIPBlockListProvider}
    WhenChanged       : 12/12/2012 10:02:36 PM
    WhenCreated       : 12/12/2012 10:02:36 PM
    WhenChangedUTC    : 12/13/2012 4:02:36 AM
    WhenCreatedUTC    : 12/13/2012 4:02:36 AM
    OrganizationId    : 
    OriginatingServer : Lucas.*****.net
    IsValid           : True
    ObjectState       : Unchanged

    Friday, December 14, 2012 2:38 AM

All replies

  • When you install the Antispam agents on Exchange 2013 servers you get all of them installed like you did for previous versions of Exchange server. most of them will get installed on the mailbox role but not the Connection filtering agent aka. RBL, DNS Block List etc.

    The powershell script: install-AntispamAgents.ps1 will look for which server role is installed and will not install Connection filtering if the server hold the mailbox role. This is understandable since SMTP connection should come in from the CAS server and then the original sending IP will not be show since CAS do Source-NAT. So the logic would be to install the connection filtering agent on CAS but the install script will not let you do that either. Connection Filtering will only install on Edge role.

    I can only speculate why this is, but either Microsoft want it to be like this or they have found some trouble with the Connection Filtering Agent running on CAS.

    I figured I will give this a try anyway, and here is how you get it to work.

    Start Exchange Management Shell as administrator.

    Change Directory to scripts folder.   
    cd $exscripts     
    Install the agent.    
    Install-TransportAgent -Name "Connection Filtering Agent" -TransportService FrontEnd -TransportAgentFactory "Microsoft.Exchange.Transport.Agent.ConnectionFiltering.ConnectionFilteringAgentFactory" -AssemblyPath "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\agents\Hygiene\Microsoft.Exchange.Transport.Agent.Hygiene.dll"

    If you have multiple agents running on the frontend transport you must set them in the correct order with the priority parameter

    Add a IPBlocklistprovider of your choice   
    Add-IPBlockListProvider -Name -LookupDomain -AnyMatch $true -Enabled $true

    You can add more than one provider if you like. If you Don’t provide a custom response it will be “Recipient not authorized, your IP has been found on a block list”

    Enable the agent   
    Enable-TransportAgent -TransportService FrontEnd -Identity "Connection Filtering Agent"

    Restart FrontEnd transport service   
    Restart-Service MSExchangeFrontEndTransport

    Now the agent should be live and kicking. Logging for the frontend agent is here “C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\AgentLog” instead of the directory for the backend transport “C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\AgentLog”

    Since the script don’t install the Connection filtering agent on CAS it is probably unsupported to install the agent manually, but I had it running for months without any problem so make your own judgment.

    Friday, June 14, 2013 2:34 PM
  • Binding the connection agent to the FrontEnd transport does work! The FrontEnd transport is where connections to port 25 are made to, so this transport agent should handle the connection filtering, not the Hub transport where the connection is relayed to.

    The reason that subsequent connections are also rejected is because the connection between the frontend and transport agents stays open for subsequent message deliveries so the connection agent keeps responding to the first rejected message until the connection between the frontend and transport is dropped after timeout.

    Tuesday, June 25, 2013 11:05 AM
  • Migrated to 2013 a while back and used the PowerShell to ensure the IPBlockListProvider was set-up.  Only just realised recently the reason I was getting more spam then before was because there was no Connection Filtering Agent installed so the IPBlockListProvider wasn't doing anything.  Have followed Berxane's instructions and it is now working correctly.  According to the default Default Frontend receive connector log a email was blocked by the provider and then an other email was successfully received 30 seconds later so installing it via Berxane's instructions doesn't seem to have the issue Talmen experienced.

    Thanks! :)



    Thursday, July 11, 2013 8:49 AM
  • Good morning,

    We're trying to follow Berxane's instructions and always answered that test failed.

    Could you please help ?

    Many many thanks,



    Environment : Exchange 2013 CAS & Mailbox

    Below is the capture of EMS :


    Sorry, cannot yet insert image...


    Basically the image contents these lines :

    [PS] C:\Windows\system32\Get-TransportAgent -TransportService FrontEnd
    Identiy                Enabled        Priority
    -------                -------        --------
    Connection Filtering Agent    True        1

    [PS] C:\Windows\system32\Get-IPBlockListProvider
    Name                LookupDomain    Priority
    ------                -------        -------    1

    • Edited by jb_2000 Thursday, September 19, 2013 9:28 AM
    Thursday, September 19, 2013 9:17 AM
  • I have installed the Connection Filtering Agent with these instructions. The BlockLists are working however emails take a long time to come in.  With the Agent disabled emails from external addresses will arrive in my inbox within 10 seconds normally.  With it turned on i'm looking at 1.5 to 2 minutes.  I don't recall the blocklist checks taking this long with our Exchange 2003 server prior to upgrading to 2013.

    I recieve quite a few of these messages in the Application Log:
    Event 1050, MSExchange Extensibility

    The execution time of agent 'Connection Filtering Agent' exceeded 90813.4035 milliseconds while handling event 'OnRcptCommand' for message with InternetMessageId: 'Not Available'. This is an unusual amount of time for an agent to process a single event. However, Transport will continue processing this message.

    Is anyone else who has implemented the Connection Filtering Agent in this way on Exchange 2013 been experiencing the same results? As far as I can tell all emails do eventually come in and none are "Lost" but the long delay at the transport agent concerns me.  



    Tuesday, February 25, 2014 6:21 PM
  • I do get the same thing. Single exchange server, Exchange 2013. I notice that when connection filtering is enabled, it takes a couple min for the message to get through. We have GFI MailEssentials installed too though, and that is doing connection filtering, so I think I'm just going to leave Exchange's connection filtering turned off.
    Friday, July 25, 2014 6:44 PM