none
S/TNEF signature RRS feed

  • Question

  • We are using Exchange 2003 to send internal email within our company. Some users receive a plain/text email with various attachments, while others receive winmail.dat attachments with no plain text. The problem we are having is the TNEF signature in these files are not the signature stated in the MS-OXTNEF. The signature we are getting is %78 3F 3E 22 versus what we expect %78 9F 3E 22. Also all our attribute IDs are off. Where we would be looking for 9006 we find 3F06. Is this something different between TNEF and S/TNEF? And is there a document which describes the new attribute IDs? The MAPIProps IDs are still the same for us as what we expect.

    The emails which are getting these non standard winmail.dat files seem to all contain Mail.Note and rtf compressed data. What exactly can a Mail.Note contain? Can it contain the text of a standard email or is just calendar/appointment type items?

    Wednesday, November 17, 2010 10:57 PM

Answers

  • cc1375,
     
    I am going to archive this issue until a future time in which you would like to further investigate.
    Once you have some sample data we could analyze to reproduce the issue you are observing, send it to dochelp [at] microsoft.com.
    Thank you.
     
    Dominic Salemno
    Escalation Engineer
    Open Specifications
    • Marked as answer by King Salemno Monday, November 29, 2010 3:33 PM
    Monday, November 29, 2010 3:33 PM

All replies

  • Hi cc1375, thank you for your question. A member of the protocol documentation team will be in touch with you soon.
    Josh Curry (jcurry) | Escalation Engineer | US-CSS DSC Protocols Team
    Thursday, November 18, 2010 3:44 PM
    Moderator
  • Greetings cc1375,

    I am the engineer who has taken ownership of your questions. I am currently investigating these and will update you as things progress.

    Dominic Salemno
    Escalation Engineer
    Open Specifications

    Thursday, November 18, 2010 3:57 PM
  • cc1375,

    Could you please send me some samples of these attachments and winmail.dat files to dochelp [at] microsoft.com ?

    Dominic Salemno
    Escalation Engineer
    Open Specifications

     

    Thursday, November 18, 2010 5:00 PM
  • I can't send any of the other attachments which are coming through. These are interoffice emails we are having issues with so they contain sensitive information. Across the same exchange servers (coming from the same and to the same different ones) we have both emails which do not get any winmail.dat treatment and then some that do. I assume this is based off of how the recipients are marked in our global address book. Our main issue is not how to stop the winmail.dat from appearing but why we are getting a different encoding. 

    These are the common bytes at the beginning of each of the winmails that are coming through.

     

    7834 3e22 1c0c 0106 3f08 0004 0000 0000
    0001 0001 0001 073f 0600 0800 0000 3404
    0000 0000 0000 3f00 010a 3f04 0002 0000
    0002 0002 0001 053f 0300 0e00 0000 3f07
    0b00 0900 1100 0c00 3a00 0200 4e01 0120
    3f03 000e 0000 003f 070b 0009 0011 0011
    001b 0002 0034 0101 093f 0100 2100 0000

    Then we have what I assume is a recipient table which has an incorrect length and/or mapiprop count since the data gets cut off during extraction. Then we get this, which I'm assuming is another mapiprop table, but I can't figure out what the header id starts. This may include null attributes for the recipient table, but the length of the recipient table cut off the data at this point. The byte previous to this was the last letter of an email address.

    0000 0000 0300 713a
    0000 0000 03003f5f 0000 0000 0300 3f5f
    0000 00000300 3f5f 0000 0000 32770103
    3f06 003f 0c00 0043 0000000b 0002 0001
    0000001f001a 0001 0000 0012 0000 0049
    0050 004d 002e 004e 006f 0074 0065 0000 0000

    Friday, November 19, 2010 4:15 AM
  • cc1375,
     
    My ability to assist you on this issue is limited without the full range of sample data to reproduce the behavior you are observing. Could you please contact me at dochelp [at] microsoft.com so that we may discuss your concerns regarding your company’s sensitive information?
     
    Dominic Salemno
    Escalation Engineer
    Open Specifications
    Saturday, November 20, 2010 12:43 AM
  • cc1375,
     
    I am going to archive this issue until a future time in which you would like to further investigate.
    Once you have some sample data we could analyze to reproduce the issue you are observing, send it to dochelp [at] microsoft.com.
    Thank you.
     
    Dominic Salemno
    Escalation Engineer
    Open Specifications
    • Marked as answer by King Salemno Monday, November 29, 2010 3:33 PM
    Monday, November 29, 2010 3:33 PM