Embedded attachment in Winmail.dat

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm developing an Outlook add-in in VB using VS 2005 and VSTO 2005 SE. For
some reason, I have formating information with the message, and I understand
that Outlook will attach a Winmail.dat file. I also understand, that the
Winmail.dat file will show up as an attachment for the recipient, if he/she
doesn't use Outlook as an e-mail client.

My problem is if the sender attaches a file to the message, Outlook will
embed it in the Winmail.dat file.

My question is, whether it is possible and how to force Outlook from my
add-in not to embed the original attachment in Winmail.dat, but keep it as a
separate attachment besides Winmail.dat. (Other words, I want the recipient
to receive two attachments, the first is the original file that the sender
attached and the second is Winmail.dat with the formating information, but
not the embedded original attachment.)

Thank you.

Istvan
 
Tell us more about how your add-in creates the outgoing message. It doesn't use a custom form or add custom fields to the outgoing item, does it? If you're not doing that and the message is in plain text or HTML format, Winmail.dat should not be a problem.
 
Hi Sue,

I was trying to be very specific in the question, because I had researched
this problem a lot.

The add-in does use a custom form and it does add custom fields to the
message, and therefore I had come to the conclusion, that if I wanted to keep
the custom form and the custom fields, then I'd have to live with Winmail.dat.

The only thing that I cannot live with, is that all the attachments are
embedded in Winmail.dat, and e-mail clients, other than Outlook, will not
extract them automatically.

If you want to know more about the technical implementation of the add-in,
I'll be happy to go into details. However, I felt that any further detail in
the original posting would have taken the focus off the target.

Thank you,

Istvan
 
if I wanted to keep the custom form and the custom fields, then I'd have to live with Winmail.dat.

Yes, that's correct, unless the mail server strips it, which some Exchange servers will.

The question I'd have to ask is whether a custom form and custom fields are really appropriate for your application scenario. In other words, is the benefit you get from them worth the price of the winmail.dat file that non-Outlook recipients will have to deal with?
 
Sue said:
Yes, that's correct, unless the mail server strips it, which some Exchange servers will.

The question I'd have to ask is whether a custom form and custom fields are really appropriate for your application scenario. In other words, is the benefit you get from them worth the price of the winmail.dat file that non-Outlook recipients will have to deal with?
Click to expand...

Not completely on/off topic, but have a look at http://www.eolsoft.com/freeware/winmail_opener.
 
Your question is very valid, and I will have to consider alternative ways to
implement the features we have in this add-in. Not being able to send
attachments (at least not to everybody) is a very high price for a custom
application, and I don't think my company can live with it.

Thanks again for your comments, I appreciate it,

Istvan
 
Hi Notan,

And thanks for your comment. I'm aware that there are utilities that can
read the Winmail.dat file, however, my add-in is on the sender side, and the
recipient can be anybody in the world. Therefore it is hard to require that
the recipient has a utility to open Winmail.dat.

Thank you,

Istvan
 
Once thing to keep in mind, if you're adding custom fields for internal tracking purposes, is that using a lower-level API, such as Extended MAPI, Redemption, or CDO 1.21, to add hidden properties -- rather than Outlook fields that a user can see in a folder view -- does not trigger the transmission of Winmail.dat.
 
Thank you Sue.

All our custom fields are derived fields, therefore they can be recalculated
on the fly. We store certain formated recipients (like "John Doe
<[email protected]>") in our custom fields, but they can be reproduced
from the MailItem.Recipients collection. Of course, the trade off is
processing time.

Storing them at Extended MAPI, CDO or Redemption level might also be a good
way to go. Thank you for your advise.

Istvan
 
Back
Top