Hi,
I've been having issue with TNEF format and thought it best to write up what I've found so far. I've been receiving e-mail from a colleague running what I suspect to be a newer Microsoft mail client. These have an "attachment" in TNEF format which (with the aid of a hex editor) turns out to be the HTML formatted (ofcourse) contents of the e-mail. tnef silently "fails" to handle these because:

*. TNEF key is 695e rather than 363
*. There is no attATTACHRENDDATA 0x9002 object, so no file is set-up and hence there is no output, debug or otherwise.
*. However the 0x9003 field is still present and contains a byte stream which is the e-mail.

I'll see if I can get you an example.

Although it may be outside of scope of tnef, would it be possible to warn in verbose or debug mode that the winmail.dat file is not empty but does not contain an attachment? Thanks.

tnef 1.4.14
tnef -f $file

==11058== Invalid write of size 1
==11058== at 0x41526B: unicode_to_utf8 (util.c:98)
==11058== by 0x40BC14: mapi_attr_read (mapi_attr.c:215)
==11058== by 0x412BD8: parse_file (tnef.c:305)
==11058== by 0x402433: main (main.c:380)

unsigned char*
unicode_to_utf8 (size_t len, unsigned char* buf)
{
int i = 0;
int j = 0;
unsigned char utf8 = malloc (3 * len/2 + 1); / won't get any longer than this */

for (i = 0; i < len - 1; i += 2)
when len is 0, (len - 1) underflow

poc.zip

I'm trying to extract attachments from winmail.dat file by using tnef, but it seems tnef is unable to parse the file for some reason. The file is expected to include calendar invitation, originating from MS Exchange 2010.

$ tnef winmail.dat
$ tnef -f winmail.dat --list
$ tnef -f winmail.dat --list -v
$ tnef -C tempdir -f winmail.dat

eg. all the above output nothing.. If I enable the "--debug" flag then I'll get lots of output, as promised by the usage/help text :)

Any tips about how to get the file contents parsed/extracted? Thanks!

I'm using tnef-1.4.18-1.el7.x86_64 rpm.

On the manpage at

              Save message body data found in the TNEF data. There can

mention if without --save-body will the message body data be saved
anyway or not.

              be up to three message bodies in the file, plain text,
              HTML encoded, and RTF encoded. Which are saved is
              specified by the --body-pref option. By default the
              message bodies are written to a file named message with
              an extension based upon the type (txt, html, rtf).

So maybe there is always an implicit --save-body message turned
on, and --save-body FILE just picks a new name instead of message.
All this needs to be clarified on the man page.

Hi,
it seems like you forgot to change the version info for the -V parameter. In two files there is still the old version:

Took me some time to figure out why the hell there is sill the old version shown after updating :)

/usr/share/doc/tnef/file-format.tex.gz is nice, alas maybe also including a .txt version would save users research in how to display TeX.

$ tnef --version
tnef 1.4.12

There are commits that have the commit message 'release 1.4.13' but there is no actual tag/release. Can you please make one?

__builtin_mul_overflow will be very fast so we should use it if it exists.

We can check for it it in the code with something like:

#ifdef __GNUC__ # if __GNUC__ >= 5 
# define HAVE_BUILTIN_OVERFLOW 
# elif defined(__has_builtin) /* clang */ 
# if __has_builtin(__builtin_mul_overflow) 
# define HAVE_BUILTIN_OVERFLOW 
# endif 
# endif 
#endif 

We have 2 companies under the same umbrella, one of them uses Outlook and Exchange, the other uses Sendmail/Dovecot and combinations of Non-Outlook clients.

The Admin Assistant always sends calendar invites from her Outlook, which stores the invites in a winmail.dat file, and sends them to our Director, who cannot open them.

we use TNEF to extract all attachments, but it is not recognising the Calendar entries embedded in the file

I have a winmail.dat file with calendar entries embedded, if you would like to have a look.

Third attachment in this winmail.dat is Ryanair Travel Itinerary, which is not same with Outlook.
What would be the reason? And how to parse it successfully?
winmail.dat.zip
Thanks.

Received in email from: Adreas Kainz on 2017-12-14

Hi,

I think you have a bug in mapi_attr.c:

line 49:
assert (len > 16);

this should be:
assert (len >= 16);

I have winmail.dat where the prior assertion triggers.

I didn't fully try to trace why you added this assert and why it
should be 16; anyway, len > 16 looked a little bit suspicious ;-)
and my winmail.dat works with the changed assert.

if winmail.dat contained attachments of named chinese charactor ,like "测试.doc" , the file name won't right and can't extract the attachment.

https://api.travis-ci.org/verdammelt/tnef.svg?branch=master

The tnef man page OTHER REFERENCES points to an old URL that no longer has content related to tnef: http://support.microsoft.com/support/kb/articles/Q136/2/04.asp

I would suggest you replace the MS support reference that is broken with the David A. Wheeler essay at: https://www.dwheeler.com/essays/microsoft-outlook-tnef.html

Hey @verdammelt ,

I am unable to parse .ics file as it return That was a not TNEF format file error while try to open this file

Sample ics.dat.zip

While this file open in Letter Opner app without any error.

Can you please provide guide that How can I open it?

Thanks

aclocal: warning: autoconf input should be named 'configure.ac', not 'configure.in'
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'

On the manpage at

       --debug
              enable debug output.

do add a warning that this will alas spew five times the
entire file's worth of bytes upon the screen.

$ ls -og winmail.dat
-rw------- 1 996334 12-05 01:27 winmail.dat
$ tnef --debug --list winmail.dat | wc
    337 1002968 5018665

So add that if the user is not prepared for five megbytes "in the face" he
should at least "pipe it to more(1)".

Since Version 1.4.13 we get assertion failures while parsing a winmail.dat containing unicode strings.

Example winmail.dat with debug output from 1.4.12 and 1.4.13: https://gist.github.com/isoftjs/e7eb450b62abbd426b055a540b3685d2

Using 1.4.12:

./tnef-1.4.12/src/tnef --list --file winmail.dat
example.dat |   example.dat

Using 1.4.13:

./tnef-1.4.13/src/tnef --list --file winmail.dat
tnef: file.c:176: file_add_mapi_attrs: Assertion `a->type == szMAPI_STRING' failed.

When adding szMAPI_UNICODE_STRING to the assertion the file can be parsed:

./tnef-1.4.13/src/tnef --list --file winmail.dat
example.dat |   example.dat

With some debug printing after the changed assertion:

./tnef-1.4.13/src/tnef --list --file winmail.dat
file_add_mapi_attrs@178: file->name=example.dat, a->type=31
example.dat |   example.dat

At first the issue was occurring with an incoming mail (which contains some sensitive information) with another assertion failure:

Using 1.4.12:

./tnef-1.4.12/src/tnef --list --file winmail.dat
Filename Jan. 2017 - Kopie.pdf  |   Filename Jan. 2017 - Kopie.pdf
Filename Dez. 2016 - Kopie.pdf  |   Filename Dez. 2016 - Kopie.pdf

Using 1.4.13:

./tnef-1.4.13/src/tnef --list --file winmail.dat
tnef: mapi_attr.c:216: mapi_attr_read: Assertion `(idx+(a->names[i].len*2)) <= len' failed.

Then the assertion failure from the gist above will occur (file.c:176: file_add_mapi_attrs: Assertion a->type == szMAPI_STRING failed.)

With some debugging:

./tnef-1.4.13/src/tnef --list --file winmail.dat
mapi_attr_read@216: idx=8968, a->names[i].len=30, len=9096
mapi_attr_read@216: idx=9048, a->names[i].len=32, len=9096
file_add_mapi_attrs@178: file->name=Filename Jan. 2017 - Kopie.pdf, a->type=31
Filename Jan. 2017 - Kopie.pdf  |   Filename Jan. 2017 - Kopie.pdf
file_add_mapi_attrs@178: file->name=Filename Dez. 2016 - Kopie.pdf, a->type=31
Filename Dez. 2016 - Kopie.pdf  |   Filename Dez. 2016 - Kopie.pdf

opening a winmail.dat from a french sender, a wrong charset is used.
for example
https://www.winmail-dat.com/online.php
opens the winmail.dat with the correct data set

On the man page at

       -t,  --list
              list attached files, do not extract.

Mention that what one is seeing is indeed one file per line.
And the first column represents ...,
and the second column represents ...,
and thus even though they look similar, careful inspection shows they
aren't.
Also add a tip: to enable the results to fit on one's screen, try
piping to perl -pwle 's/\s+/ /g;'

Also mention that adding -v now gives five or six fields, the first is
the size, the second is the date, the third and fourth are as above.
The fifth is "unknown", perhaps always, and the sixth is perhaps
blank...

Certain winmail.dat files contain MAPI fields which are 'multi-value' fields. These are inconsistently handled by tnef and case result in a termination of processing with the error message:

!!MULTI_VALUE_FLAG seen (0x1205 0x02)
Assertion failed: (!mvf), function mapi_attr_read, file mapi_attr.c, line 250.
Abort trap: 6

if attachments named in Chinese, would not get the right name,

here is the output files name when run tnef winmail.dat

C%C0%E0%CE%EF%C1%CF1.xls  
C%C0%E0%CE%EF%C1%CF2.xlsx 
D%C0%E0%CE%EF%C1%CF.xls

and here is the right name when run tnef -t winmail.dat

btw, I am using Mac OS X

I was trying to upgrade tnef from 1.4.12 to 1.4.17 on FreeBSD ports tree and got one failure on make check.

PASS: help.test
PASS: version.test
PASS: basic.test
PASS: debug.test
PASS: list.test
PASS: verbose.test
PASS: overwrite.test
PASS: directory.test
PASS: maxsize.test
PASS: body.test
PASS: mime-types.test
PASS: stdin.test
============================================================================
Testsuite summary for tnef 1.4.17
============================================================================
# TOTAL: 12
# PASS:  12
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
PASS: one-file.test
PASS: rtf.test
PASS: two-files.test
PASS: missing-filenames.test
PASS: long-filename.test
PASS: data-before-name.test
PASS: MAPI_OBJECT.test
PASS: MAPI_ATTACH_DATA_OBJ.test
PASS: triples.test
PASS: body.test
PASS: multi-name-property.test
PASS: garbage-at-end.test
FAIL: multi-value-attribute.test
PASS: unicode-mapi-attr.test
PASS: unicode-mapi-attr-name.test
============================================================================
Testsuite summary for tnef 1.4.17
============================================================================
# TOTAL: 15
# PASS:  14
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/files/test-suite.log
Please report to [email protected]
============================================================================

Here is the content of test-suite.log

=============================================
   tnef 1.4.17: tests/files/test-suite.log
=============================================

# TOTAL: 15
# PASS:  14
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: multi-value-attribute
===========================

\'diff "./multi-value-attribute.output" "./baselines/multi-value-attribute.baseline" > "./multi-value-attribute.diff"\' -- Test Failed!
FAIL multi-value-attribute.test (exit status: 1)

And here is a diff between baseline and output files:

-(MESS) Message Class <8008> [type: word <0007>] [len: 35] = 0x5049 0x2e4d 0x6f4e 0x6574 0x4d2e 0x6369 0x6f72 0x6f73 0x7466 0x562e 0x696f 0x6563 0x616d 0x6c69 0x552e 0x2e4d 0x4143 0x0000
+(MESS) Message Class <8008> [type: word <0007>] [len: 35] = 0x5049 0x2e4d 0x6f4e 0x6574 0x4d2e 0x6369 0x6f72 0x6f73 0x7466 0x562e 0x696f 0x6563 0x616d 0x6c69 0x552e 0x2e4d 0x4143 0xa500

Please let me know if you need more information

On the (Debian) man page at

REPORTING BUGS
       Report bugs to Mark Simpson <[email protected]>

do also mention https://github.com/verdammelt/tnef/issues .

@dtimms reports:

Just a note that attempting: make check is showing a test failure in:

FAIL: multi-value-attribute.test

Testsuite summary for tnef 1.4.11
============================================================================
# TOTAL: 13
# PASS:  12
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/files/test-suite.log

Given this issue relates to improvements for mult-value fields, this might be related to these patches.