DOD breaks links in .mil clients

DataSecurity_IllustrationThe Department of Defense is breaking HTML links in mail to .mil domains. This is part of the DoD’s attempt to curtail phishing.

a great majority of intrusions into Pentagon networks are the result of the kind of human error that is exploited in phishing attacks, in which seemingly trustworthy e-mail links are used as attack vectors to hijack user computers, install malware or steal credentials.

Instead of being able to click on links, .mil recipients will have to cut and paste links into a browser in order to visit the website. This will also affect open tracking and break images in emails.
If you’re sending to .mil domains, plain text is going to be best. The DoD has had a policy of not rendering HTML, but some mail clients still did. Now the DoD is taking extra steps to break links.
My suggestions for senders who need to send mail to .mil domains:

  1. Use plain text.
  2. Make links as short as possible so that they’re easier to cut and paste.
  3. Call to actions are even more important as you’re asking for an extra step.
  4. For those of you who can, try and get an address that’s not .mil

For mailers who might sometimes get .mil addresses on your lists, think about whether or not you really want to allow them. Try to get a different address for them. Deliverability will be easier and your pretty HTML can be displayed.
 

Related Posts

4 things spammers do legitimate marketers don't

I’ve never met a spammer that claims to be a spammer. Most that I’ve met claim to be legitimate marketers (or high volume email deployers). But there are things spammers do that I never expect to see a legitimate marketer doing.
I’ve written about these things throughout the blog (tag: TWSD), but it’s probably time to actually pull them together into a single post.

Read More

What to do when an important email bounces

Some emails are more important than others. I know, I know, all emails are important, but really, some are more important than others.
I’ve recently been decluttering by the simple expedient of enrolling in paperless statements for some of our accounts. We have a 1TB NAS, I’m not going to run out of storage space and I will have so much less paper to deal with. Plus, electronic searches are easier than digging through a file I’ve just shoved statements in for the whole year.
Some companies just let you sign up for statements online and don’t take any extra steps to verify your email address or tell you what happens if your email breaks. But at least one company has gone the extra mile to establish how they handle email bounces.
consentforpaperlessdocs
First, to sign up for paperless notifications I have to give my consent to receive docs. Even better, when I look at the important information it expressly details what happens if my email address bounces.

Read More

Do system administrators have too much power?

Yesterday, Laura brought a thread from last week to my attention, and the old-school ISP admin and mail geek in me felt the need to jump up and say something in response to Paul’s comment. My text here is all my own, and is based upon personal experience as well as those of my friends. That said, I’m not speaking on their behalf, either. 🙂
I found Paul’s use of the word ‘SysAdmin’ to be a mighty wide (and — in my experience — probably incorrect) brush to be painting with, particularly when referring to operations at ISPs with any significant number of mailboxes. My fundamental opposition to use of the term comes down to this: It’s no longer 1998.
The sort of rogue (or perhaps ‘maverick’) behavior to which you refer absolutely used to be a thing, back when a clean 56k dial-up connection was the stuff of dreams and any ISP that had gone through the trouble to figure out how to get past the 64k user limit in the UNIX password file was considered both large and technically competent. Outside of a few edge cases, I don’t know many system administrators these days who are able to (whether by policy or by access controls) — much less want to — make such unilateral deliverability decisions.
While specialization may be for insects, it’s also inevitable whenever a system grows past a certain point. When I started in the field, there were entire ISPs that were one-man shows (at least on the technical side). This simply doesn’t scale. Eventually, you start breaking things up into departments, then into services, then teams assigned to services, then parts of services assigned to teams, and back up the other side of the mountain, until you end up with a whole department whose job it is to run one component of one service.
For instance, let’s take inbound (just inbound) email. It’s not uncommon for a large ISP to have several technical teams responsible for the processing of mail being sent to their users:

Read More