In an ideal world, you’d create and format your emails, send them off, and the recipient would see just what you meant them to see. Sadly, it’s not an ideal world. For simple messages, obviously, everything works fine, but for more sophisticated emails, it can be less straightforward.
For Mac users, in particular, it’s worth remembering that your recipients may well be using Microsoft Outlook or Outlook Express and so won’t be able to see some of the nice features that Mac users take for granted. A couple of examples:
Attachments in the middle of the email
If you know you’re sending to a Mac user, you can be reasonably sure that their email app will support the standards that allow you to insert and refer to images, documents and other attachments inline as part of the text. Microsoft users, on the other hand, will probably just see these bunched together at the top or bottom of the message. More importantly, if you put any text after them in your message, it may become a text attachment in Outlook. I have seen conversations get very confused when Mac users didn’t realise that PC users had only seen the first half of an email.
Inline PDFs
Since Macs are native speakers of PDF, some graphics apps will naturally output that format and use it, for example, when copying and pasting to other apps. Remember that a PDF, unless it has multiple pages, will embed in an email like any other image on a Mac. On Windows, even if the mail program can display inline images, PDFs will probably appear as attachments, so it’s best not to use them for putting your logo in your signature, for example.
I’m not purely criticising Outlook here; Gmail has some of the same limitations, for example, but Outlook does seem to cause more than its fair share of problems. (See the TNEF issues, for example). Nor am I saying that Apple Mail is perfect – I wish, amongst other things, that it allowed more manipulation of HTML styling. But the Apple Mail/MS Outlook differences are the ones that most people are likely to see most often, so that’s why I’m highlighting them here.
Anyway, Apple users who know they are sending to PC users should therefore probably take advantage of the options under Mail’s ‘Edit > Attachments’ menu, which let you send attachments in a more Windows-friendly way, and force them to be at the end of the message.
If, on the other hand, you’re using a Mac and you know your recipient is also likely to be using a Mac, then you can take advantage of some of these features and, for example, put explanatory paragraphs around your attachments:
But how, other than through your estimate of the recipient’s, or their organisation’s, general level of street cred, can you guess what kind of a mail program they’re using?
There are one or two things that will give you a clue immediately. If they have mysterious ‘J’ characters in their messages, for example, it’s because Outlook uses a somewhat strange, or at least very dated, method of encoding smileys, which seldom displays correctly elsewhere. For ‘J’, read :-).
But you can almost always get a definite answer by asking your mail app to show you the full headers, or perhaps the raw text, of the email message. (On Apple Mail, go to View > Message > Long Headers.)
Most email programs will insert a header named X-Mailer which will identify the source as being, for example, ‘Microsoft Outlook 14.0’, or ‘Apple Mail (2.1081)’.
If a message doesn’t have that header, then it probably didn’t come from a desktop app, and you may get a clue from other headers that it came from Hotmail, GMail, or a mailing list. The iPad Mail app doesn’t add X-Mailer, but it does identify itself in the Mime-Version, so take a look at the other headers too.
In addition to helping you plan complex email messages, I’ve used this in the past to guess whether somebody is using a Mac, Windows or Linux machine before recommending a piece of software that might not work on their platform.
On Godaddy, this defaults to one hour – really rather a short period, and since they’re the largest DNS registrar, this probably causes a lot of unnecessary traffic on the net as a whole. If you’re confident that your server is going to stay on the same IP address for a good long time, you should set your TTLs to something more substantial – perhaps a day, or even a week. This will help to distribute the load on the network, reduce the likelihood of failed connections, and, on average, speed up interactions with your server. The reason people don’t regularly set their TTL to something long is that, when you do need to change the mapping, perhaps because your server has died and you’ve had to move to a new machine, the old values may hang around in everybody’s caches for quite a while, and that can be a nuisance.
RSS feed
Recent Comments