Internal Mail format and source getting skewed

I have an odd problem. I tried searching, but honestly, I don't really know what specifically is going on so it's difficult to tack it down.

Basically, whenever someone on our domain sends an email to someone on the same domain, or another domain on the same server, the email on the recipient's side contains headers and all sorts of other garbage. I found this when I tried to create a share with a co-worker. He got an email that included headers and HTML code, but obviously that's not the goal. More critical, is because the HTML isn't being interpreted (that's really just a guess) there were no accept or decline buttons. And, you can't see this in the examples I give below, but I can see it on my screen, the reply-to address is not correct at all. The sender's address is msmith@domaina.com, but the reply-to comes across as Matt@zimbra.domainb.com, again, critical problem.

This is the task share I tried to send to my co-worker (the e-mail he received that should present him with a uniformed share notification with an accept button):

Here is an example of a test e-mail I sent from one domain on our server to another domain on our server, I did this to show that it's an 'any internal to any internal' problem (also having a reply-to address of Matt@zimbra.domainb.com):

It's worth noting that the problem only happens when email is sent through the web interface. Users sending e-mail via a client such as Outlook do not have this issue.

It's also worth noting that this a Zimbra cluster set up with split-DNS. I'm betting it has to do with the DNS because I've had big problems with this in the past, but I really don't know how to solve this one.

I will be glad to share whatever information is necessary, I just don't know what else anyone might need.

Did you ever get an answer to this problem? I see the same thing right now on a system I just migrated a pile of users to.

You could've texted me weeks ago and found a fix. I really wish you would've tried to get all the information before going crazy, but it's cool. It is what it is. I'm not going to deny the community a solution over personal BS so...

Yes, I found a fix and a number of other things in the process.

A.) If you were to create a new account, you would find that the issue still randomly comes up and that it was nothing to do with the migration process. I migrated people over from a different server, too, but just keep an eye on that.
B.) I was advised by our mutual friend to upgrade my version from 7.1.1 to 7.1.4, but that did not help. He also said that Zimbra doesn't check the forums anymore so that's a bummer, guess that bug will have to get fixed by accident.
C.) Are you doing Split-NAT? I am, wondering if there's a link there. All of my issues have always stemmed from that.
D.) Using any 3rd party SPAM filtering? Barracuda here. Don't know if it was a problem before or after the Barracuda.

My solution was to backup the account through the web interface, delete the account, re-create the account, restore the data, and setup a temporary password and notify the user. The problem is that you have no way of knowing which accounts are having the problem. You could probably do a script that just sent yourself an email from each account to see which ones are screwed up.

I've done this a dozen times and each time, the account seems to be working fine. Another thing I noticed is that accounts that use Outlook do not have this problem, so it's at least a Zimbra interface thing, possibly command line, too. I haven't checked it.

I just realized for the first time that the user's first and last name are split into two different addresses in the from field. This might be related to how I provisioned the users? LDAP has something jacked for the user information when it tries to generate the From address?

Not really sure. I just know the method I use works and it's not a terrible PITA. The fact that part of the header comes through, the newline characters show up, and the reply-to address is firstname@serverhostname.domain.com seems like possibly multiple issues as though something was corrupt when creating it. I read on G+ that you've been playing with DRBD. Is the affected server part of a DRBD cluster?

My fix is dirty, but it is a fix. I suppose the practical use of it is dependent on how many of your accounts are affected though.

So, the fix is... Clear out and type the users's First and Last name back into their account settings (I just did this through the web interface), and let the "Display Name" field repopulate automatically.

Somehow, when I scripted the account provisioning last night, a goofy character was entered when I tried to build out the "Display Name" field in the user's account.

Not doing DRBD, that was for a different project, and was horrible to deal with. :-)