Ian,
So first let me share some background on how Exchange processes BCC information, there's a good article here: http://gsexdev.blogspot.com/2011/06/processing-bccs-in-exchange-transport.html
You can also find information that alludes to how Exchange processes BCC's here: https://superuser.com/questions/476620/finding-bcc-in-internet-mail-headers
Further, I'm going to simply copy/paste this MS employee's answer since it explains it well enough: http://social.technet.microsoft.com/Forums/exchange/en-US/faa6a8f4-7192-406f-bf7c-f41b52473e37/exchange-or-outlook-rule?forum=exchangesvrsecuremessaging
The fields shown in the UI in outlook client have nothing to do with
email delivery. They are there for user convenience. When you have
outlook client send a message, it compiles an aggregate list of all
recipients specified in the (To, Cc, and Bcc) fields displayed in
its UI. Using this list of recipients, outlook then issues a RCPT-TO
command to the mail server for each recipient. Once that is done,
outlook issues one (just one) DATA command that contains your message
(headers, blank delimiter line, and body). The mail server has no clue
which recipient was specified in which field and it doesn't care. It
has been told who are the recipients by the list of RCPT-TO commands
that it received. The recipients never get to see the original list of
RCPT-TO commands that the sender issued to their sending mail server.
The headers in the message (what gets sent during the DATA command) is
whatever outlook puts there. Email clients are NOT supposed to include
the Bcc field in their header section in the message but some legacy
clients did. Outlook should only insert To and Cc headers that match
on the values specified in the To and Cc fields in UI. Since the Bcc
field was never copied to a Bcc header in the message, there is
nothing within the message's headers to indicate who were the Bcc'ed
recipients. And since recipients never get to see the list of RCPT-TO
commands issued by the sender to their mail server, there is no way
for the recipient to know who got Bcc'ed.
Even for old email clients that used to include the Bcc header in the
message based on the value of the Bcc field in their UI (as, say, an
option to do so), many receiving mail hosts will strip out that
header. It wasn't supposed to get transmitted so it gets stripped out
if present. The whole point of the Bcc field is NOT to create a header
with that list of recipients.
So let's get to the heart of the matter. Exchange processes it differently than what you are used to on your Linux mail server.
What can you do though if Insightly won't change their programming?
Here's a few ideas I can think of that might work:
1) Continue with the BCC idea but make 2 hops. What I mean by this is create resource mailboxes or similar in Exchange for the Insightly projects email addresses. Then BCC those addresses and have those mailboxes auto forward all email to the "real" Insightly project email address. At that point Insightly should see it as an actual TO address. Not sure how the FW: info would be handled by it, but worth a shot.
2) Consider simply CCing the Insightly address. I get why you want to do the BCC but maybe this is an option?
3) Same as #1 above, but put the email addresses on the Linux mail server. Then have that server trigger to BCC Insightly upon receiving a BCC from Exchange. You'd need to use a different mail domain on the Linux server and Outlook users would BCC email that domain (like Project1@insightly.internal). Then Exchange would deliver mail destined for insightly.internal domain to the Linux server. The Linux server would then trigger a BCC to Project1@realdomain.com. Frustrating and silly, but should work as well.
Hope that helps a little. It's a tricky situation to be in, and you can't exactly just nix the CRM software because of this I'm guessing.