Forum Discussion
BCC Foldering Agent
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"?
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
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.
mderooij
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.
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"
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-mailbox-using-mfcmapi/
