I'm writing a perl module that sends rich-text messages to Microsoft Outlook recipients from Unix. This involves generating CRCs of the plaintext and rtf versions of the mail message.
Unfortunately, when I use perl modules to generate the CRC, the values do not match those that the Outlook Client is expecting.
For example, I used the crc32 function from Digest::CRC to determine the CRC of the string ABCD. I also sent a message from an Outlook client containing only ABCD as the body text.
Digest::CRC::crc32 gives me the following for the CRC of ABCD: db 17 20 a5
But the Outlook attachment contains a CRC of ABCD as: b9 ff 53 fa
Anyone know why these wouldn't match? If not, anyone know a way to reverse engineer the CRC Algorithm Outlook uses based on an examination of computed CRCs from different message texts? I can run different texts through Outlook, snoop the attachments, and extract the CRCs to get sample data.
I've checked the Microsoft documentation to see what they say about the CRC, but it doesn't say anything about the algorithm or polynomial value used to compute the CRC. It only mentions the following for the field where it expects the CRC to be defined:
The PR_RTF_SYNC_BODY_CRC property contains the cyclical redundancy check (CRC) computed for the message text. The RTFSync function computes the CRC using only the characters that it considers to be significant to the message. For example, some white space and other ignorable characters are omitted from the CRC: http://msdn.microsoft.com/library/en-us/mapi/html/_mapi1book_pr_rtf_s...
Frank Sconzo wrote: > I'm writing a perl module that sends rich-text messages to Microsoft > Outlook recipients from Unix. This involves generating CRCs of the > plaintext and rtf versions of the mail message.
> Unfortunately, when I use perl modules to generate the CRC, the values > do not match those that the Outlook Client is expecting.
Richtext and plain text are non-binary files. Non-binary files on Windows use "\015\012" at the end of each line Non-binary files on Unix use "\012" at the end of each line. When data is transfered in ASCII mode (as opposed to BINARY) mode, the CRC will change. You need to convert one or both to canonical form before performing a CRC check. -Joe
On 2 May 2004 10:21:23 -0700, frank.sco...@dowjones.com (Frank Sconzo) wrote:
>The RTFSync function >computes the CRC using only the characters that it considers to be >significant to the message. For example, some white space and other >ignorable characters are omitted from the CRC:
You appear to have the answer right there. Assuming Outlook is using this function to do the CRC. Naturally they are not using all the characters in the message for computation of the CRC as any _normal_ CRC would. Another undocumented proprietary implementation.
Perhaps you can guess the chars they are ignoring by eliminating spaces, linefeeds and cr's from the chars you use in your CRC computation. What other chars they may consider "not significant" is anybody's guess.
Thanks for responding; you make a good point. Unfortunately, the newline/carriage return issue is not the cause of the problem. The sample text I tested contained only four characters: ABCD, no newlines (not even at the end of the single line).
> > I'm writing a perl module that sends rich-text messages to Microsoft > > Outlook recipients from Unix. This involves generating CRCs of the > > plaintext and rtf versions of the mail message.
> > Unfortunately, when I use perl modules to generate the CRC, the values > > do not match those that the Outlook Client is expecting.
> Richtext and plain text are non-binary files. > Non-binary files on Windows use "\015\012" at the end of each line > Non-binary files on Unix use "\012" at the end of each line. > When data is transfered in ASCII mode (as opposed to BINARY) mode, > the CRC will change. You need to convert one or both to canonical > form before performing a CRC check. > -Joe
> I'm writing a perl module that sends rich-text messages to Microsoft > Outlook recipients from Unix. This involves generating CRCs of the > plaintext and rtf versions of the mail message.
> Unfortunately, when I use perl modules to generate the CRC, the values > do not match those that the Outlook Client is expecting.
> For example, I used the crc32 function from Digest::CRC to determine > the CRC of the string ABCD. I also sent a message from an Outlook > client containing only ABCD as the body text.
> Digest::CRC::crc32 gives me the following for the CRC of ABCD: > db 17 20 a5
> But the Outlook attachment contains a CRC of ABCD as: > b9 ff 53 fa
> Anyone know why these wouldn't match?
I think perhaps Outlook inverted things in a different sense than is usual.
> > I'm writing a perl module that sends rich-text messages to Microsoft > > Outlook recipients from Unix. This involves generating CRCs of the > > plaintext and rtf versions of the mail message.
> > Unfortunately, when I use perl modules to generate the CRC, the values > > do not match those that the Outlook Client is expecting.
> > For example, I used the crc32 function from Digest::CRC to determine > > the CRC of the string ABCD. I also sent a message from an Outlook > > client containing only ABCD as the body text.
> > Digest::CRC::crc32 gives me the following for the CRC of ABCD: > > db 17 20 a5
> > But the Outlook attachment contains a CRC of ABCD as: > > b9 ff 53 fa
> > Anyone know why these wouldn't match?
> I think perhaps Outlook inverted things in a different sense than > is usual.
> Thanks very much for your response; I sincerely appreciate it! I've > been struggling over this for a few days, but you've solved the > puzzle.
You're most welcome. I'm glad I could help!
> How in the world did you figure this out?
I just sort of guessed. I fiddled with the parameters a bit until fa53ffb9 popped out and decided that was probably it with the bytes in the wrong order. Lacking access to Outlook, I'll leave it to you to verify it for more cases. You may still run into problems with those "ignorable characters" you mentioned.
