RFC2822 windows attachment

Bernhard Reiter bernhard at intevation.de
Thu Jan 13 17:45:15 CET 2005


On Monday 10 January 2005 17:12, Bernhard Reiter wrote:
> On Monday 10 January 2005 09:10, Joon Radley wrote:
> > 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.
>
> Wouldn't it be possible to add another tag to the kolab-xml object
> that is Toltec or OL specific.

I do understand the problem better now,
of course in real emails there is not kolab attachement where we
can put such data and all email readers do have some extra data
they save, like the read status.

Traditionally they save it in the header and this way the mail body
will look exactely the same which is good.
Headers are different between systems that got the same email anyway.

> > 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.
>
> I would consider the custom data
> and in an XML tag if possible.
> Of course the more documentation we can have for that custom data,
> the better.

I still would like to only have the custom data to save space.
Currently I would prefer having it in a X-Toltec-something header base64 
encoded header, but then again this is only my limited knowledge 
on the subject.

Joon: Does something speak against using such a header?
It might eben be easier for some tasks? Like searching for flags?




More information about the format mailing list