This issue has been bugging me for a while and I finally figured out the cause.

There's a bug in Microsoft Exchange Server 2000 which causes message parts with a Content Disposition of "inline" to still be sent as attachments. So, the message body becomes an attachment.

I've successfully worked around the issue. I used to use the Path attribute for the attachment, but now I do this...

my $mailfile_data; if ( ! open(MAILFILE, "$mailfile") ) { Log( "Unable to open $mailfile for email report." ); return FAILURE; } { local $/; undef $/; $mailfile_data = <MAILFILE>; } close MAILFILE; $email->attach( Type => "text/html", Data => $mailfile_data, Disposition => "inline", );
    Microsoft Knowledge Base Article - 323482
    http://www.ietf.org/rfc/rfc1806.txt
    http://www.ietf.org/rfc/rfc2183.txt

Microsoft's Knowledge Base claims that "This behavior is in compliance with the Request For Comments (RFC) 2803 and 1806.", however using their own links to the RFC standards mentioned, I found that it is not...

The presence of the filename parameter does not force an implementation to write the entity to a separate file. It is perfectly acceptable for implementations to leave the entity as part of the normal mail stream unless the user requests otherwise. As a consequence, the parameter may be used on any MIME entity, even `inline' ones. These will not normally be written to files, but the parameter could be used to provide a filename if the receiving user should choose to write the part to a file.
--
-- GhodMode

Replies are listed 'Best First'.
Re: MIME::Lite & MS Exchange 2000
by hossman (Prior) on Jul 08, 2004 at 06:32 UTC
    • You don't have to slurp the whole file in, you can use the "FH" option to attachment and let it read the filehandle as it writes out the message...
      my $fh; if (open($fh, "$mailfile") ) { $email->attach(Type => "text/html", Disposition => "inline", FH => $fh, ); } else { die "can't open file to attach"; }
    • While it makes sense that MIME::Lite would automaticly put the filename info on if you use the "Path" option, I was dissapointed to discover that saying "Filename => undef" didn't supress that. Given the situation you describe, it seems like it might be a worthy feature request.