Hubbard, Matt R W wrote:
> Could you explain when (under what circumstances) the
> TNEF decoding is done on a winmail.dat mime part?
Before -16, in two cases:
1. The mail contains a mime part of type "application/ms-tnef".
2. The mail contains an attachment with a proposed name of "winmail.dat"
All files were fed to the TNEF decoder if one of those was true. In -16,
only the winmail.dat file is fed to the TNEF decoder.
> I'd still like to check for mime errors, but I'd rather not have a process
> die because a non-tnef file was named winmail.dat.
OK, first of all, I was never able to reproduce a crash on my RH7.x
systems. Those reporting it were using more recent distros like Fedora
Core 1. I also have a confirmed report that there is no crash on
Solaris/Sparc. Maybe this issue only occurs with gcc 3.x compiled
binaries? I have no idea.
What can you do? To be safe from child crashes, you can either reject
TNEF attachments (recommended, they are uncommon for bona fide emails,
and according to MS, they should not be used in internet email), or you
remove the TNEF checks and let them through unscanned.
For the former case, you can do this in the new MIME ACL
(*advertisement, untested*):
deny message = We do not accept TNEF encoded messages
condition = ${if eq{lc:$mime_filename}{winmail.dat}}
deny message = We do not accept TNEF encoded messages
condition = ${if eq{$mime_content_type}{application/ms-tnef}}
For the latter case, just remove this code block at the end of demime.c:
if (has_tnef) {
uschar file_name[1024];
/* at least one file could be TNEF encoded.
attempt to send all decoded files thru the TNEF decoder */
snprintf(CS file_name,1024,"%s/scan/%s",spool_directory,message_id);
mime_unpack_tnef(file_name);
};
Regards,
/tom
