RFC2822 windows attachment

[Joon Radley]

Hi All,

While working on the RFC2822 translation we ran into a problem where we
sometimes loose critical data that cannot be saved during the translation
process. The data is encapsulated in custom properties in the OL object. To
resolve the issue we intend to add a attachment like the infamous
"winmail.dat" to each email stored on the server. 

<* flame proof jacket on *>

I know this is not a nice solution, but we were unable to find a simple and
nice way of resolving this. The other clients can just simply strip this
attachment if they like. (The content type and file name will be listed in
the kolab format doc.)

What I would like to discuss is what we will put in the attachment. 

We can put a complete TNEF object like winmail.dat in the attachment. This
will allow other OL clients to use the same data, but this will also double
the space needed on the server for the email. As normal mail objects are by
far the largest disk space user on a server, the impact would be
considerable.

The other option is to put custom data into the attachment that can only be
used by our product. This will save some space, but nobody else can use it.

Comments please.

Best regards

Joon Radley
Radley Network Technologies CC
Cell: +27 (0)83 368 8557
Fax: +27 (0)12 998 4346
E-mail: joon at radleys.co.za