SOLVED

BCC Foldering Agent

Steel Contributor

One of our users have reported that certain emails are delivered into various subfolders in her mailbox instead of the inbox. Message trace (see attached) refers to 'BCC Foldering Agent' (indeed this happens with emails where this user is BCC-d) and suggests that this is caused by an inbox rule, but there are no inbox rules in place (double checked both 'visually' and with the Get-InboxRule cmdlet), and also there are no add-ins enabled for that mailbox.

 

Does anyone have any idea what is happening in this case and what is this "BCC Foldering Agent"?

8 Replies

Might be some hidden rule, you can check for this via MFCMAPI as detailed here: https://blogs.msdn.microsoft.com/hkong/2015/02/27/how-to-delete-corrupted-hidden-inbox-rules-from-a-...

 

 

 

best response confirmed by Zoltan Bagyon (Steel Contributor)
Solution

Not well documented, but this looks like expected behavior:
"Engineering confirmed that the behavior is expected and by design. The design stems from users who complained that when someone replies to a message on a DL and moves the DL to the BCC line (e.g. to discourage members of the DL from sending more replies), that BCC'd reply lands in the recipients' Inboxes, instead of landing in the same folder as the rest of the messages for that DL. The BCC Transport agent provides this functionality. The BCC agent detects BCC messages, looks at the In-Reply-To header, searches for the message identified by the In-Reply-To header, and delivers the BCC message to the same folder as the replied-to message." (source)

 

Were not able to repro the folder movement; messages did have an extra header, X-MS-Exchange-Processed-By-BccFoldering

 

Thanks Michel, this indeed is the same what we have experienced and it seems to be the root cause. What I'd add to the obeservations from the forum thread you cited: it doesn't have to be a DL in the BCC field, it occurs even when simply a couple of user mailboxes are BC-ed.

We had this same issue with our systems. Our scenario might not match yours exactly, but we have an email account that is used to process important emails. It was a lights out system and our employees would include this email account on the BCC line if we needed to track it. The trouble is BCC Foldering was moving it on us before we got a chance to have it processed by some automated tools. 

Our work around was we setup a new 0365 Group email (think DL) that our Employees started using instead on the BCC line. Then we setup an mail flow Rule on Exchange to take all emails sent to this email do a Redirect to the custom email account that our tools are running against. The result is the BCC header is stripped from the email, and no BCC Foldering kicks in. 

Hope this helps. 

@Michel de Rooij 
One way to stop the automatic move I found is to create a Transport Rule with 


-SetHeaderName X-MS-Exchange-Organization-Recipient-P2-Type

-SetHeaderValue To

 

This will pre-stamp the email with an x-header before getting to BCC foldering agent. Changing the above header value from 'Bcc' to 'To' will fool the BCC foldering agent into thinking the email was not Bcc'd.

However, the only viable message filtering parameter you can use with this rule is keywords in subject and message body.  Bcc'd recipient and groups addresses are not detectable by transport rule, so they can't be used in filter.  You can't filter on the bcc related x-header, because that is stamped AFTER BCC folder agent has touched the email.

Also with this rule, even if email is not Bcc'd, triggered email will have the "X-MS-Exchange-Organization-Recipient-P2-Type", and the "X-MS-ExchangeProcessed-By-BccFoldering" headers stamped because of this transport rule.  From header, this email is going to look like it was Bcc'd to the trained eyes of Exchange admins.  Other then that, I don't see any downsides with this rule.

@J_Tsai Hey, I know that this thread is old but it is the only reliable thread I have found on this subject. About a month ago we discovered this exact same issue happening with one of our clients - User A BCCs User B on an email. User B then moves that email into a sub folder. User A then goes into their sent items and Reply All's the original email. That email then goes directly into User B's sub folder where they moved the original email. I was able to put the transport rule in place to modify the 'X-MS-Exchange-Organization-Recipient-P2-Type' message header to avoid this issue and it was working perfectly. That is until yesterday. Now the mail flow rule does not seem to be applying and changing the message header. Is anyone else seeing this behavior with a recent Exchange patch? This is happening for my client and when I test in our own environment. We are both running Exchange Version - 1713.5.

@JHaney 

I have the exact same version of Exchange (2016 CU12? With latest Exchange security patch). I just tested it and it’s still working.

 

Try raising the priority on that rule so it runs first?  On my transport rule I also added subject keywords because I only need to modify header for specific messages.

 

Here’s the read out on the rule I am running.  Hope this help!

 

ManuallyModified : False

ActivationDate :

ExpiryDate :

Description : If the message:

Includes these words in the message subject: 'Comp Committee' or

'Lateral' or 'CONFIDENTIAL' or 'Test BCC'

Take the following actions:

set message header 'X-MS-Exchange-Organization-Recipient-P2-Type'

with the value 'To'

RuleVersion : 14.0.0.0

Conditions : {SubjectContains}

Exceptions :

Actions : {SetHeader}

State : Enabled

Mode : Enforce

RuleErrorAction : Ignore

SenderAddressLocation : Header

RuleSubType : None

UseLegacyRegex : False

From :

FromMemberOf :

FromScope :

SentTo :

SentToMemberOf :

SentToScope :

BetweenMemberOf1 :

BetweenMemberOf2 :

ManagerAddresses :

ManagerForEvaluatedUser :

SenderManagementRelationship :

ADComparisonAttribute :

ADComparisonOperator :

SenderADAttributeContainsWords :

SenderADAttributeMatchesPatterns :

RecipientADAttributeContainsWords :

RecipientADAttributeMatchesPatterns :

AnyOfToHeader :

AnyOfToHeaderMemberOf :

AnyOfCcHeader :

AnyOfCcHeaderMemberOf :

AnyOfToCcHeader :

AnyOfToCcHeaderMemberOf :

HasClassification :

HasNoClassification : False

SubjectContainsWords : {Comp Committee, Lateral, CONFIDENTIAL, Test BCC}

SubjectOrBodyContainsWords :

HeaderContainsMessageHeader :

HeaderContainsWords :

FromAddressContainsWords :

SenderDomainIs :

RecipientDomainIs :

SubjectMatchesPatterns :

SubjectOrBodyMatchesPatterns :

HeaderMatchesMessageHeader :

HeaderMatchesPatterns :

FromAddressMatchesPatterns :

AttachmentNameMatchesPatterns :

AttachmentExtensionMatchesWords :

AttachmentPropertyContainsWords :

ContentCharacterSetContainsWords :

HasSenderOverride : False

MessageContainsDataClassifications :

MessageContainsAllDataClassifications :

SenderIpRanges :

SCLOver :

AttachmentSizeOver :

MessageSizeOver :

WithImportance :

MessageTypeMatches :

RecipientAddressContainsWords :

RecipientAddressMatchesPatterns :

SenderInRecipientList :

RecipientInSenderList :

AttachmentContainsWords :

AttachmentMatchesPatterns :

AttachmentIsUnsupported : False

AttachmentProcessingLimitExceeded : False

AttachmentHasExecutableContent : False

AttachmentIsPasswordProtected : False

AnyOfRecipientAddressContainsWords :

AnyOfRecipientAddressMatchesPatterns :

ExceptIfFrom :

ExceptIfFromMemberOf :

ExceptIfFromScope :

ExceptIfSentTo :

ExceptIfSentToMemberOf :

ExceptIfSentToScope :

ExceptIfBetweenMemberOf1 :

ExceptIfBetweenMemberOf2 :

ExceptIfManagerAddresses :

ExceptIfManagerForEvaluatedUser :

ExceptIfSenderManagementRelationship :

ExceptIfADComparisonAttribute :

ExceptIfADComparisonOperator :

ExceptIfSenderADAttributeContainsWords :

ExceptIfSenderADAttributeMatchesPatterns :

ExceptIfRecipientADAttributeContainsWords :

ExceptIfRecipientADAttributeMatchesPatterns :

ExceptIfAnyOfToHeader :

ExceptIfAnyOfToHeaderMemberOf :

ExceptIfAnyOfCcHeader :

ExceptIfAnyOfCcHeaderMemberOf :

ExceptIfAnyOfToCcHeader :

ExceptIfAnyOfToCcHeaderMemberOf :

ExceptIfHasClassification :

ExceptIfHasNoClassification : False

ExceptIfSubjectContainsWords :

ExceptIfSubjectOrBodyContainsWords :

ExceptIfHeaderContainsMessageHeader :

ExceptIfHeaderContainsWords :

ExceptIfFromAddressContainsWords :

ExceptIfSenderDomainIs :

ExceptIfRecipientDomainIs :

ExceptIfSubjectMatchesPatterns :

ExceptIfSubjectOrBodyMatchesPatterns :

ExceptIfHeaderMatchesMessageHeader :

ExceptIfHeaderMatchesPatterns :

ExceptIfFromAddressMatchesPatterns :

ExceptIfAttachmentNameMatchesPatterns :

ExceptIfAttachmentExtensionMatchesWords :

ExceptIfAttachmentPropertyContainsWords :

ExceptIfContentCharacterSetContainsWords :

ExceptIfSCLOver :

ExceptIfAttachmentSizeOver :

ExceptIfMessageSizeOver :

ExceptIfWithImportance :

ExceptIfMessageTypeMatches :

ExceptIfRecipientAddressContainsWords :

ExceptIfRecipientAddressMatchesPatterns :

ExceptIfSenderInRecipientList :

ExceptIfRecipientInSenderList :

ExceptIfAttachmentContainsWords :

ExceptIfAttachmentMatchesPatterns :

ExceptIfAttachmentIsUnsupported : False

ExceptIfAttachmentProcessingLimitExceeded : False

ExceptIfAttachmentHasExecutableContent : False

ExceptIfAttachmentIsPasswordProtected : False

ExceptIfAnyOfRecipientAddressContainsWords :

ExceptIfAnyOfRecipientAddressMatchesPatterns :

ExceptIfHasSenderOverride : False

ExceptIfMessageContainsDataClassifications :

ExceptIfMessageContainsAllDataClassifications :

ExceptIfSenderIpRanges :

PrependSubject :

SetAuditSeverity :

ApplyClassification :

ApplyHtmlDisclaimerLocation :

ApplyHtmlDisclaimerText :

ApplyHtmlDisclaimerFallbackAction :

ApplyRightsProtectionTemplate :

SetSCL :

SetHeaderName : X-MS-Exchange-Organization-Recipient-P2-Type

SetHeaderValue : To

RemoveHeader :

AddToRecipients :

CopyTo :

BlindCopyTo :

AddManagerAsRecipientType :

ModerateMessageByUser :

ModerateMessageByManager : False

RedirectMessageTo :

RejectMessageEnhancedStatusCode :

RejectMessageReasonText :

DeleteMessage : False

Disconnect : False

Quarantine : False

SmtpRejectMessageRejectText :

SmtpRejectMessageRejectStatusCode :

LogEventText :

StopRuleProcessing : False

SenderNotificationType :

GenerateIncidentReport :

IncidentReportContent :

RouteMessageOutboundConnector :

RouteMessageOutboundRequireTls : False

ApplyOME : False

RemoveOME : False

OMEExpiryDays : 0

GenerateNotification :

Identity : Disable BCC Foldering Agent

If anyone comes across this in the future, you can disable the BccFolderingAgent with the following settings override:

 

New-SettingOverride DisableBCCFolderingAgent -Component MailboxTransport -Section StoreDriverBccFolderingAgent -Parameters @('Enabled=false') -Reason "Custom override to disable BCCFolderingAgent"

1 best response

Accepted Solutions
best response confirmed by Zoltan Bagyon (Steel Contributor)
Solution

Not well documented, but this looks like expected behavior:
"Engineering confirmed that the behavior is expected and by design. The design stems from users who complained that when someone replies to a message on a DL and moves the DL to the BCC line (e.g. to discourage members of the DL from sending more replies), that BCC'd reply lands in the recipients' Inboxes, instead of landing in the same folder as the rest of the messages for that DL. The BCC Transport agent provides this functionality. The BCC agent detects BCC messages, looks at the In-Reply-To header, searches for the message identified by the In-Reply-To header, and delivers the BCC message to the same folder as the replied-to message." (source)

 

Were not able to repro the folder movement; messages did have an extra header, X-MS-Exchange-Processed-By-BccFoldering

 

View solution in original post