Skip to main content

Exchange Edge server Filter Agent "precedence"

You might find the attachments are being stripped from some email entering your organization despite recipient and sender domain have been added to the "whitelist" in Sender ID Agent.

Agents on Exchange Edge server are as follows:


Each of the agents has its own priority, meaning which of the agent will be first, second, third,... in line to filter. Filters take precedence over another just in case spam is found.

For example: If Connection Filtering Agent finds spam (connection verification fails) it discards the message and none is processed any further. If the message passes Connection Filtering Agent it then goes to Address Rewriting Inbound Agent, which is next on priority list etc.

So, if we put a recipient to BypassedRecipients list in Sender ID Agent, it will be bypassed only for Sender ID Agent filter and not for example Attachment Filtering Agent.

As per Microsoft. "The BypassedRecipients parameter specifies one or more SMTP email addresses. Messages bound for the email addresses listed in this parameter are excluded from processing by the Sender ID agent. You can specify multiple values separated by commas. You can enter a maximum of 100 email addresses."

Therefore, precedence, as we might want it to be, does not exist on Exchange Edge server. It is not as Exchange policies which take precedence when the result (filtered) is found and no more policies are processed.

The biggest problem is with Attachment Filtering Agent, which does not offer any white-listing. The only possibility to bypass attachment filtering without disabling it is by using separate receive connector and then add it to ExceptionConnectors parameter.

As per Microsoft: "The ExceptionConnectors parameter specifies a list of connectors that should be excluded from attachment filtering. Attachment filters aren't applied to email messages received through these connectors. You must use the connector GUID to specify the ExceptionConnectors parameter value."
Labels:

Comments

Post a Comment

Popular posts from this blog

Netscaler vs Exchange 2019 "time out during ssl handshake stage

If you are using Citrix Netscaler as load balancer in front of Exchange 2019 server you must know this: Microsoft Exchange 2019 is secured by default and allows only TLS 1.2. Therefore default schannel settings are as follows (using IISCrypto tool from Nartac Software): While Citrix Netscaler offers following Cipher Suites: TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA Now, you will fi
1 comment
Read more

Exchange Admin Center language

Depending on your computer language settings, Exchange Admin Center can take those and open in a language you actually don't want to use. You'll Google that this can be changed if administrator/ admin user has mailbox by openening OWA settings and changing Regional parameters. But usually Admin user does not have mailbox or you don't want her/him to have it. You will search again and find that you can add mkt=en-US (as an example) to the URL of the Exchange Admin Center (https://yourexchangehostname/ecp?ExchClientVer=15&mkt=en-US) Third option you have is opening Internet Explorer settings (I am using Windows 2016) Click languages Click Set Language Preferences Add language you want to use by clicking Add language Use Move up or Move Down options to put desired language on top Close Internet Explorer Open it again and login again to Exchange Admin Center
Post a Comment
Read more

Free/Busy missing - Cloud to On-Premises

We had a problem where M365 users could not retreive Free/Busy information from on-premise Exchange server. Hybrid setup was run and everything was working fine except this. After research I found out that TargetSharingEpr is the way to look at. There are many sites out there that are pointing to the same setting but only Set-OrganizationRelationship is used to change the value. The problem is, this value is available for two commands: Set-IntraOrganizationConnector Set-OrganizationRelationship While we changed the value in  Set-OrganizationRelationship it didn't work until we changed the value in  Set-IntraOrganizationConnector too. By default it should work with just  TargetAutodiscoverEpr but for us it didn't. Finally we ran this command on Intra Organization Connector which is used from Cloud to On-prem:  Set-IntraOrganizationConnector -TargetSharingEpr   https://mail.domain.com/ews/exchange.asmx And it worked.
Post a Comment
Read more