Winmail.dat - what is the best fix (at the sending server level?) so senders don't have to be bothered and receivers know they will get the PDF attachment?
When users send emails with attachments like PDFs from SBS 2011 standard server (they are using different versions of outlook on their desktops), it shows up sometimes on iphones as a winmail.dat file.
I've heard that's a common issue with outlook at one end and iphones at the receiving end. The receiving person with the iphone can look on their desktop and got the mail with the correct pdf or similar attachment.
But I got a bit confused while troubleshooting.
I had 1 user send me an email with PDF attachment to a gmail account and looked at it on my iphone (with latest ios version) using the native iphone mail app.. It came in as a PDF file.
I had the same user send me the same PDF to a POP mail account and looked at it on that same iphone and it came in under that account as a winmail.dat attachment.
I am thinking why they came in differently, but then thought - have to check how the contact is in the address book - to turn off / on rich text?
So the issue is at the sending end? Is there a way to force a fix on the SBS 2011 server? So senders don't have to tweak all their contacts for people with iphones. and receivers don't have to deal with winmail.dat 3rd party apps (at least from mail this client sends).
And if you don't have rich text, you lose bolding / fancy signatures?
I've heard that's a common issue with outlook at one end and iphones at the receiving end. The receiving person with the iphone can look on their desktop and got the mail with the correct pdf or similar attachment.
But I got a bit confused while troubleshooting.
I had 1 user send me an email with PDF attachment to a gmail account and looked at it on my iphone (with latest ios version) using the native iphone mail app.. It came in as a PDF file.
I had the same user send me the same PDF to a POP mail account and looked at it on that same iphone and it came in under that account as a winmail.dat attachment.
I am thinking why they came in differently, but then thought - have to check how the contact is in the address book - to turn off / on rich text?
So the issue is at the sending end? Is there a way to force a fix on the SBS 2011 server? So senders don't have to tweak all their contacts for people with iphones. and receivers don't have to deal with winmail.dat 3rd party apps (at least from mail this client sends).
And if you don't have rich text, you lose bolding / fancy signatures?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
There should be no differences in the cmdlets, simply connect to the EMS and run them.
Sorry looking at that page closer now a couple questions
It talks about including the email address of the receiver in method one. I’d like it to be global? I don’t know who is going to have an iPhone. And they may type in someone new freeform on the to line. Will this solve the problem for those situations? It talks of working for contacts in exchange.
And it talks about external recipients. What about people in the company who have iPhones? Internal recipients on iPhones will still get winmail.dat attachments?
And by sending in text mode, any fancy signatures that they may have or pictures in their signatures get lost,right?
Is there a way to force it into HTML to keep nice colors / formatting? Rich text is the problem, right? HTML is fine?
It talks about including the email address of the receiver in method one. I’d like it to be global? I don’t know who is going to have an iPhone. And they may type in someone new freeform on the to line. Will this solve the problem for those situations? It talks of working for contacts in exchange.
And it talks about external recipients. What about people in the company who have iPhones? Internal recipients on iPhones will still get winmail.dat attachments?
And by sending in text mode, any fancy signatures that they may have or pictures in their signatures get lost,right?
Is there a way to force it into HTML to keep nice colors / formatting? Rich text is the problem, right? HTML is fine?
To answer the second part of your question - you CANNOT keep your colours, formatting and embedded images in signatures and guarantee that emails will be received in all clients in the same format they were sent.
Unfortunately (or Fortunately depending on your perspective) the safest common denominator for emails is PLAIN TEXT and that eliminates all styling and font customisation and all files are attached and nothing is in-line.
I've dealt with companies over the years who have spent lots of time/money and effort creating colourful, custom HTML signatures only to find they don't work on certain email clients or devices and degrade badly.
In terms of who is to blame .. you can spread it between Apple and Microsoft. Apple have opted for 2 email standards for sending mainly RTF and Plain Text and although their Mail clients can read HTML it doesn't allow you to explicitly create HTML emails.
https://support.apple.com/en-ie/guide/mail/use-plain-or-rich-text-in-messages-mlhlp1009/mac
Furthermore, Apple have "decided" that the HTML and RTF formats that Microsoft use when sending emails via their Exchange-Server emails are not following a specific standard and if it cannot parse the attachment clearly it bundles it into a winmail.dat and displays it as the annoying attachment.
If you use Outlook on OSX you'll notice that it manages to properly parse the email so it is clearly a "decision" by Apple to willingly not understand the email format.
GMail and SOME other mail clients can manage to successfully parse the HTML formatted emails sent via Exchange server so you can see that it is possible if the will is there. It is also fair to say that Apple Mail client is not the only software that can have issues parsing Exchange-server emails so even if Apple Mail was better you'd still have others with the attachment winmail.dat issue.
However as the SENDER in this case is Microsoft Exchange and the sending mail server is the only element in the equation you can control.
Unfortunately if your emails are being sent outside your Intranet and could be received on ANY device you really have to opt for the safest lowest common denominator which is PLAIN TEXT.
Unfortunately (or Fortunately depending on your perspective) the safest common denominator for emails is PLAIN TEXT and that eliminates all styling and font customisation and all files are attached and nothing is in-line.
I've dealt with companies over the years who have spent lots of time/money and effort creating colourful, custom HTML signatures only to find they don't work on certain email clients or devices and degrade badly.
In terms of who is to blame .. you can spread it between Apple and Microsoft. Apple have opted for 2 email standards for sending mainly RTF and Plain Text and although their Mail clients can read HTML it doesn't allow you to explicitly create HTML emails.
https://support.apple.com/en-ie/guide/mail/use-plain-or-rich-text-in-messages-mlhlp1009/mac
Furthermore, Apple have "decided" that the HTML and RTF formats that Microsoft use when sending emails via their Exchange-Server emails are not following a specific standard and if it cannot parse the attachment clearly it bundles it into a winmail.dat and displays it as the annoying attachment.
If you use Outlook on OSX you'll notice that it manages to properly parse the email so it is clearly a "decision" by Apple to willingly not understand the email format.
GMail and SOME other mail clients can manage to successfully parse the HTML formatted emails sent via Exchange server so you can see that it is possible if the will is there. It is also fair to say that Apple Mail client is not the only software that can have issues parsing Exchange-server emails so even if Apple Mail was better you'd still have others with the attachment winmail.dat issue.
However as the SENDER in this case is Microsoft Exchange and the sending mail server is the only element in the equation you can control.
Unfortunately if your emails are being sent outside your Intranet and could be received on ANY device you really have to opt for the safest lowest common denominator which is PLAIN TEXT.
Hello,
As an aside to the above, I too have had this issue in the past and it turned out to be the autocomplete on the e-mail address that was causing the problem. This is the site that I found:
http://galaxycow.com/2008/01/12/winmaildat-hides-in-your-autocomplete/
As an aside to the above, I too have had this issue in the past and it turned out to be the autocomplete on the e-mail address that was causing the problem. This is the site that I found:
http://galaxycow.com/2008/01/12/winmaildat-hides-in-your-autocomplete/
you can't choose assisted answers anymore?! sorry!
ASKER