[quote user="Brian Fluet"]

The VIEWER.PM files make up the list displayed in the Content Viewer.  I say "files" because there can be two.  One is system-wide (valuable for you).  It resides in the PMail executables directory.  The other one is user specific and resides in the users mailbox directory.  In Content Viewer, the black entries are from the user file and the blue are from the system file.[/quote]

But system-wide VIEWER.PM is only available when we're talking about a Pmail network installation, where all local users start it's Pmail session from the same server shared executables. In case you prefer a single installation on each computer, you could not use this advantage.

The post topic says it all.  Occurrences of winmail.dat attachments are increasing and my sense is that it is proportional to the increase in the use of Office 365.  My recent research leads me to believe that it is much harder for senders to fix than when it could be fixed at Exchange.  I know of utilities that will decode winmail.dat but there is a serious need to keep these attachments readily available from the email. 

I envision capturing these messages before they arrive in user mailboxes, decoding winmail.dat, and then forwarding the message to the appropriate user with the decoded files attached.  Unfortunately it's only a vision.  I don't know how it could be implemented.  I would appreciate your comments on how you are handling this.

TIA

[quote user="Brian Fluet"]...  Unfortunately it's only a vision.[/quote]

I'm afraid, it will keep a vision [:D]. Regularly we've got also this annoying problem with Outlook's winmail.dat. And we've surrendered informing the sender about it, in hope he adjust his Outlook properly.

Finally we are also using little software tools for extracting the original files from that winmail.dat. But of cource, first the winmal.dat attachment has to be saved ...

I wonder what other guys answer in this regard

The problem is old and a really annoying. To inform the sender - in hope he adjusted his Outlook - is not enough according to https://support.microsoft.com/en-us/help/290809/how-e-mail-message-formats-affect-internet-e-mail-messages-in-outlook, because the exchange server has to be adjusted too...

[quote user="Sellerie"]because the exchange server has to be adjusted too...[/quote]

...and then there is Office365...and then there is the fact that an attachment sent in a reply can work but not when sent to the same recipient from their contact list if that contact record is not configured correctly.  It's a mess. 

On top of that, it's common for a sender to claim that it's my problem because I'm the only one experiencing it.

[quote user="Brian Fluet"]

On top of that, it's common for a sender to claim that it's my problem because I'm the only one experiencing it.

[/quote] YES, i know *hitting-head-on-desk* Some people really think, there is only M$ and nothing more.

I just 'fix' this with a Content viewers entry in Pegasus:

'Attachment type' information - TNEF

Run this program - folder\to\wmopener.exe 

Temporary file handling - .tnf

A double-click on the attachment in Pegasus opens the winmail.dat file in wmopener.exe, and from there the contents can be accessed.

wmopener = Winmail Opener found at https://www.eolsoft.com/freeware/winmail_opener/ 

stuzz78,

Do you have any entries for TNEF in FILETYPE.PM and/or MIME-MAP.PM?

Edit: Never mind.  I just figured out that MIME-MAP.PM needs the entry 'application/ms-tnef = tnef '.

Hi guys,

This is really a practical hint [Y]. But adding "application/ms-tnef = tnef" to the MIME-MAP.PM (Pmail at the Server) doesn't work for me. Only setting the file extension type to ".dat" is automatically starting wmopener.exe (which could also be started from the server) when double-clicking the attachment.

I have it working here.

Entry in VIEWER.PM:  2;tnef;.tnf;{\\serverpath}\wmopener.exe

Entry in MIME-MAP.PM:  application/ms-tnef = tnef

I have copied the files from my locally installed Winmail Opener to a shared location on the server so didn't actually "install" Winmail Opener on the server.  Whether this will create a conflict when simultaneously accessed is unknown.

stuzz78,

THANK YOU!   This has resolved a long-standing problem.  I hope you can feel the energy being generated from the grateful users here.

[quote user="Brian Fluet"]

I have it working here.

Entry in VIEWER.PM:  2;tnef;.tnf;{\\serverpath}\wmopener.exe

Entry in MIME-MAP.PM:  application/ms-tnef = tnef

I have copied the files from my locally installed Winmail Opener to a shared location on the server so didn't actually "install" Winmail Opener on the server.  Whether this will create a conflict when simultaneously accessed is unknown.

[/quote]

Although I've got the same entries in MIME-MAP.PM (central in Pmail\Programs) and user's VIEWER.PM, the attached winmal.dat is not recognized and wmopener is not being started by double-clicking the attachment. I'm also confused about following: Although "application/ms-tnef = tnef" entry has been added, this entry is not shown in the drop-down list of possible file viewers in Pmail settings. But there are a lot of other (global) entries which are not stated in MIME-MAP.PM.

Edit1:

Ok, now I've copied it also to the central VIEWER.PM not to the user's VIEWER.PM - this drives me crazy with the different VIEWERS.PM. Nevertheless it doesn't work. Where is the connection between "tnef" and .dat extension? Don't know how Pmail should recognize which program should be used for .dat extensions?

Edit2:

I've added the entry: "1;.dat;-;\\{server path}\wmopener.exe" to our central VIEWER.PM file at \\{server}\Pmail\Programs\ and not to the single user's VIEWER.PM. Also the a.m. entry in MIME-MAP.PM has been removed again. This caused that all user's Pmail sessions have the ".dat" entry in their viewer settings and are able to start the assigned tool wmopener.exe which resides at a server share as well.

It's not looking at the .dat extension which is a good thing because there could be .dat file attachments that are not winmail.dat files. 

The entry in the MIME-MAP.PM file has Pegasus Mail detecting the content type of "application/ms-tnef" and associating it with "tnef".

The entry in VIEWER.PM then tells Pmail that applications of type "tnef" should be opened with wmopener.exe.

FWIW, I first tested by adding an entry in Content Viewers which modified my user VIEWER.PM file.  I also added a MIME-MAP.PM file to my mailbox directory that contained the entry "application/ms-tnef = tnef".  This worked so I undid it and then added the entries to the global VIEWER.PM and MIME-MAP.PM files. 

I have Winmail Opener on the server in a location mapped as drive H: so my actual VIEWER.PM entry is:

2;tnef;.tnf;H:\Apps\Winmail Opener\wmopener.exe

HTH

[quote user="Brian Fluet"]... The entry in the MIME-MAP.PM file has Pegasus Mail detecting the content type of "application/ms-tnef" and associating it with "tnef"....[/quote]

Does a winmail.dat should always contain a header identifying itself as application/ms.tnef? My winmail.dat, which I use for testing purposes (received from a customer weeks ago) doesn't have such a header. This could be the reason why it doesn't work with me with the tnef entries. But on the other hand winmailopener is recognizing it and could extract embedded files without problem. But this caused to the question, is it ensured that winmail.dat could always be recognized as tnef?

5:00 pm - end of office hours. Wish you a stressless rest of your working day. [:)]

[quote user="Joerg"]Does a winmail.dat should always contain a header identifying itself as application/ms.tnef? My winmail.dat, which I use for testing purposes (received from a customer weeks ago) doesn't have such a header. This could be the reason why it doesn't work with me with the tnef entries. But on the other hand winmailopener is recognizing it and could extract embedded files without problem. But this caused to the question, is it ensured that winmail.dat could always be recognized as tnef?[/quote]

If you are testing with just the file then I suspect it is failing because the attachment headers are needed from the original email.  The messages I'm testing contain this:

Content-Disposition: attachment; filename="winmail.dat"
Content-Transfer-Encoding: base64
Content-Type: application/ms-tnef; name="winmail.dat"

[quote user="Joerg"]5:00 pm - end of office hours. Wish you a stressless rest of your working day. [:)][/quote]

Thanks for the stressless wish,  Unfortunately, I rarely have a stressless work day, just varying amounts of stress each day.  I suspect the same goes for you.

[quote user="Brian Fluet"]If you are testing with just the file then I suspect it is failing because the attachment headers are needed from the original email. [/quote]

This could be the reason. I've taken an existing winmail.dat which I just found on our server stock and sent it to me by e-mail. The raw mail data is showing:

Content-type: Application/Octet-stream; name="winmail.dat"; type=Unbekannt
Content-disposition: attachment; filename="winmail.dat"
Content-transfer-encoding: BASE64

Seems I have to wait for another new mail from an Otlook client containing a new winmail.dat. - Now it's time that we are even waiting for winmail.dat [<:o)]

[quote user="Brian Fluet"]

stuzz78,

THANK YOU!   This has resolved a long-standing problem.  I hope you can feel the energy being generated from the grateful users here.

[/quote]

You're welcome.  If I'd known it wasn't a solved problem, I would have shared sooner.  Meanwhile, this is the first I've heard of VIEWER.PM and MIME-MAP.PM.  I set up the Content Viewer entry for each user that frequently received winmail.dat attachments - maybe 10 or so.  Are the two .PM files effectively a system-wide Content Viewer?

Edit:  My MIME-MAP.PM file is dated February 6, 2009 and contains the line: application/ms-tnef = TNEF  I guess I added that myself?  I have no memory of it, but it was 11 years ago :)  I've nothing in the VIEWER.PM file that mentions TNEF.

[quote user="stuzz78"]Meanwhile, this is the first I've heard of VIEWER.PM and MIME-MAP.PM.  I set up the Content Viewer entry for each user that frequently received winmail.dat attachments - maybe 10 or so.  Are the two .PM files effectively a system-wide Content Viewer?

Edit:  My MIME-MAP.PM file is dated February 6, 2009 and contains the line: application/ms-tnef = TNEF  I guess I added that myself?  I have no memory of it, but it was 11 years ago :)  I've nothing in the VIEWER.PM file that mentions TNEF.[/quote]

The VIEWER.PM files make up the list displayed in the Content Viewer.  I say "files" because there can be two.  One is system-wide (valuable for you).  It resides in the PMail executables directory.  The other one is user specific and resides in the users mailbox directory.  In Content Viewer, the black entries are from the user file and the blue are from the system file.

As for MIME-MAP.PM, its entries tell Pegasus Mail what program to invoke when an attachment is opened.  The TNEF entry is not a default entry.