TNEF format is a Microsoft only format and GroupWise does not fully interpret it (if at all). This should be changed, as other mail software is capable of doing so and having to tell an external person to change their setting in Outlook is bad at best (even worse if it is a customer).
When GroupWise users have many interactions with Outlook/Exchanges users they for sure end up in the Outlook Contacts with the wrong settings for mail format (Rich Text). Then winmail.dat files are sent and GroupWise does not interpret them fully. Most frequenty seen for appointments...
by: Mathias F. | over a year ago | Agents
Comments
Really need it. Users didn't care what format they received and stop telling them to ask their customers to change their outlook settings
This is a major pain point in the bank -- we do business with many other people who use Outlook and when they send appointments encoded with TENF, we just don't get them as appointments. Then, we have to go through a whole rigmarole where we ask them to modify their address book for us blah blah blah you get the point. Making this "just work" with GroupWise would eliminate this rather strong pain point.
We've recently began receiving a rash of these from outlook users and has become quite frustrating for everyone involved.
Same here. Hate to tell the Outlook sender to make changes on their end.
If the same mail could be read perfectly in the GMAIL , OFFICE365 and any other major email platform, I think that there is no reason that the GW server and client could not interpret correctly.
GW engineer wrote a very long list about "What is New" in each new versions from GW5.5 to GW2014R2, but they just could not doing this very simple task! Please!
Not sure how complicated TNEF encoding of messages is, however this has been an issue for a LONG time. Can we please get some development traction on this. Other mail systems seem to have this ability. I'm sure GroupWise developers could knock this out quickly as well if product management would just bump this up on the priority list. Please. Asking Outlook senders to change because of a limitation in GW is not helping me continue selling GW to my management.
We need this!
While this problem is absolutely on the sender side i.e. poorly implemented exchange system, GroupWise users blame GW because other email systems e.g. Gmail process the proprietary TNEF format. For years I'd send email to the postmaster at the problem sender with the MS KB doc with the one-line powershell needed to fix the issue, but sometimes the receiver just needs to handle the mistake. Web browsers have done this for years with poorly formatted HTML.
Just ran into this with another client. Fortunately I know this one and she handled it well. I realize this is a Microsoft screw-up, but I doubt they really care. It would be greatly appreciated if MicroFocus would take the steps to build a solution into GroupWise for this!
Since we can't control where mail comes from, GroupWise needs to just handle this correctly. I will NOT go to my customer/vendor and ask them to change THEIR email settings so that my GroupWise email system understands their message. I'm already embarrassed that I missed meetings due to GroupWise not processing it correctly. I'm not going to bring even more attention to the matter. This needs to be corrected on the GroupWise side.
Our stakeholders run exchange. They are very very big company. They send many TNEF calendar messages to us. In case we cant read it - they can enforce us to migrate to exchange. Why Novell can't develop TNEF decoding? Novell will be LOST its customers in case of nothing do.
I keep running into this issue having to ask the Outlook user to delete and recreate their personal address book entry for me.
Receiving TNEF coded appointments is a must. The excuse that this is a Microsoft issue is refuted by the fact that GMail works fine. When you do business in a competitive environment receiving appointments just needs to work. Managers will miss meetings because the appointment does not make it on to the calendar. This will be the death of GroupWise at my company if this is not resolved.
And, this is nothing fancy or extra, just something which has grown from a proprietary thing to a necessity for doing business in a business world dominated by Outlook.
So, Product Management Team, please move this to planned asap?
Totally approved ! Do it quickly as an add-on or update...
Do it as an patch update ASAP! Do not waste current customers.
This needs to be done. Even if the cause is Outlook in that case you have to adapt. Please move this as soon as possible to planned.
Well, it happened. We just migrated to Office365, and this was a major reason.
Please implement this as soon as possible. It will be used here a s an excuse to move to Office 365. You cannot continue to hemorrhage customers because they cannot communicate effectively with those who do (even when they have mis-configured their systems).
Yes, do it ASAP. Can we have a official statement from MF about that enhancement request? As ex. from PM / Mike Bills?
TNEF is a proprietary Microsoft protocol that they do not publish. As such we can not offer official support for the protocol. Microsoft documentation also states TNEF is meant for exchanging mails from exchange to exchange and to disable TNEF when communicating with non exchange email systems. While we do not and can not offer full support for TNEF we do maintain a TNEF parser. We have worked with some customers recently and made improvements and most appointments are getting correclty parsed. This code is in both the 18.x and 14.x versions. It will be officially available in 18.0.1 which is scheduled for the end of Q1 of 2018. If you do not want to wait you can contact support and get and FTF for both 14R2 and 18.x
Thanks Mike! This is good news!
Great news, Mike, thanks!!!
Thanks, we will implement them in near future.