Re: [Evolution-hackers] winmail.dat/TNEF streams

On Wed, 2003-09-03 at 13:57, Larry Ewing wrote:
On Wed, 2003-09-03 at 11:45 -0500, Not Zed wrote:
> On Tue, 2003-09-02 at 15:29, Randall Hand wrote:
> > I'm the maintainer of ytnef (  I
> > released the ytnef C Library a few days ago, after alot of work and
> > testing.  
> > 
> > I was wondering if there's any plan to directly support TNEF streams
> > inside Evolution?  Right now we have to use procmail and filters and 
> Larry Ewing had a bonobo component he was playing with at some point,
> but i'm not sure how far it got.

It worked fine for attachments but didn't parse any of the more
interesting bits like contact information or meeting requests etc.  One
of the issues is that because it was based on GPL'd code not owned by
Ximian we couldn't link it into the mailer (since the connector is
proprietary) and bonobo oop component activation is too slow for inline
display in most cases.
The ytnef C Library is GPL, but you should be able to dynamically link to it with no problems.

> > such to do it, and that mangles signatures and such.  It would be nice
> > if evolution could directly do this.  I'm happy to work with the 
> I'm not sure if you'd still be able to maintain signatures, depends I
> guess on how it would have to work.
> > Evolution developers to implement this functionality, although I have
> > no experience with gtk/bonobo or any of this gnome programming stuff. 
> > Is this a plan for a later 1.4? Or 1.6/2.0?
> It wouldn't go into 1.4.
> As to how it would be done ... It depends on how it can be made to
> work.  If it possible to just take a tnef and form a valid MIME
> structure (it needn't be a mime stream, just the parsed in-memory
> representaiton) from it, then you dont even need to deal with gtk or
> bonobo.  If on the other hand, it needs its own display system too, then
> it would probably be best being a bonobo component, and Larry's stuff
> might be a starting point, and it can be done completely independently
> of our work.

It should be possible to fake a mime structure for the parts that ytnef
actually decodes, but the license issue is still out there.  Also in the
past it didn't look like there was a simple way to replace an attachment
with a multipart blob in mail display code, is that any simpler now? 
Finally, TNEF attachments are rare enough these days that I doubt we
have any resources to spare on improving support for them, but if
someone is interested in working on this I can point them in the right
The ytnef application actually regenerates the MIME Portions.  Everything internal to the email can be expressed as basic attachments (files, contact cards, meeting requests, etc).  There's alot of other information in there too, but most of it's redundant stuff like correlation keys and sender addresses and stuff.  The library actually just fills a giant structure with all the information, and exports a few functions to easily find the desired MAPI attributes.  It's up to the calling app to decide what to do with the information.

As for it being rare, I still see hundreds of these.  It seems like everyone using Outlook, Outlook Express, or an exchange server sends these things out.  Every time someone sends me an attachment with an inline buddy icon or smily face, welcome winmail.dat.  Granted most of them are absolutely useless, they're still there.  And you never know if they're useless until you download it and run it through something like tnef or ytnef.  I've heard the argument that they can send ICS attachments, but outlook doesn't properly support them.  Try sending an ICAL meeting request from Outlook 2k to Outlook 98, it's fun to watch.  Also, outlook's ICS attachment features only seem to work for Calendar's, not for Contact cards or tasks.  It seems that right now (until something like OpenGroupware becomes a little more common), TNEF is here to stay.

Randall E. Hand
Senior Software Engineer
Z-KAT, Inc.
2901 Simms Street
Hollywood, FL 33020
Office 954.927.2044 x125
fax 954.927.0446
"the digital surgery companytm"

Digital signature stored at
ID: 0x1D1D765C
Fingerprint: 963A 28B5 A59B F63E 18A0 6731 38DB 462E 1D1D 765C

Attention: The information contained in this e-mail message is privileged and confidential information intended only for the use of the individual(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copy of this communication is strictly prohibited. If you have received this communication in error, please contact the sender by reply E-mail and destroy all copies of the original message.

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]