RFC2822 windows attachment

Martin Konold martin.konold at erfrakon.de
Tue Jan 11 00:59:39 CET 2005


Am Montag, 10. Januar 2005 09:10 schrieb Joon Radley:

Hi Joon,


> While working on the RFC2822 translation we ran into a problem where we

I fail to understand your problem. To my knowledge OL is able to handle normal 
RFC2822 messages via IMAP for a long time.

Are you absolutly sure that you need that winmail.dat tnef?

> 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.

Are you sure that this is critical data?

> <* 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.)

Hmm,.. if other clients can simply strip this attachment then I am wondering 
what is lost if different clients access the same folder simultaneously.

> 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.

How did other people solve the problem? E.g. what is the strategy of Bynari or 
Konsec?

> 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.

Having proprietary opaque data structures in our standard are not nice and 
should be avoided whenever possible.

Regards,
-- martin

-- 
"I am committed to helping Ohio deliver its electoral votes to the
President next year."  -- 2004, Wally O'Dell - CEO of Diebold, Inc. 
e r f r a k o n - Stuttgart, Germany
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker




More information about the format mailing list