BLOG

Industry News & Analysis

Protocol-relative URLs in email

When you link to an external resource – an image, a javascript file, some css style – from a web page you do so with a URL, usually something like “https://example.com/blahblah.css” or “http://example.com/blahblah.css”.

The world is beginning to go all https, all the time, but until recently good practice was to make a web page available via both http and https.

The problem is that if you try and load a resource from an http URL from a page that was loaded via https it’ll complain about it, and not load the resource.

And if your users web browser is loading the http version of your page because it’s Internet Explorer 6 and doesn’t speak modern SSL then it’ll be unable to load anything over https, including any of your resources.

So whether you choose https or http protocol for loading your page resources it’s going to break for someone.

One common trick to avoid the problem is to use a protocol-relative URL. That looks like “//example.com/blahblah.css”, and it’ll load the resource over the same protocol that the page was loaded over.

While we can safely use “https://…” everywhere now, “//…” URLs are still a common idiom for things like loading things like CSS libraries from public content-distribution networks as well as your own resources.

I was reading long-but-excellent writeup about Stack Overflow’s migration to TLS (hey, I read this sort of stuff for fun) and they point out something I hadn’t considered – mail clients don’t really have any sensible way to use protocol-relative URLs. The mail client loaded the “page” from a mailbox and so has no base document protocol to work from (even if there’s a <base> element in the content it’s not likely to affect a mail client). If the user is reading it via webmail or a mail client that’s using an embedded web browser to render HTML it might work, sometimes, but it’s not going to reliably load that resource in general.

So, if you’re copy-pasting content from your web collateral to reuse in an email, make sure you’re not loading anything external – including images – via a “//…” style URL. Rewrite them to use “https://…”.

 

1 Comment

ARC: Authenticated Received Chain

On Friday I talked a little about DMARC being a negative assertion rather than an authentication method, and also about how and when it could be deployed without causing problems. Today, how DMARC went wrong and a partial fix for it that is coming down the standards pipeline.

What breaks?

DMARC (with p=reject) risks causing problems any time mail with the protected domain in the From: field is either sent from a mailserver that is not under the control of the protected domain, or forwarded by a mailserver not under the control of the protected domain (and modified, however trivially, as it’s forwarded). “Problems” meaning the email is silently discarded.

This table summarizes some of the mail forwarding situations and what they break – but only from the original sender’s perspective. (If forwarding mail from a users mailbox on provider A to their mailbox on provider-Y breaks because of a DMARC policy on provider-A that’s the user’s problem, or maybe provider-A or provider-Y, but not the original sender’s.)

Use case SPF DKIM DMARC
alias forwarding
procmail forwarding ?* ?
discussion mailing list
recipient vanity domain forwarding
recipient forwarding service (e.g. alumni domains)
recipient forwarding e.g. yahoo to gmail ✔*
recipient mailbox forwarding via POP
consumer email addresses using other mailbox providers
consumer email addresses sending from ESPs
consumer email addresses using, e.g. zendesk

(* some situations may modify the body or headers of the message, breaking the DKIM signature and causing DMARC failures)

(If you’re diagnosing – or trying to avoid – DMARC issues it’s worth remembering that DKIM signatures can break, apparently randomly, due to issues with how the original email was constructed. If the mail wasn’t forwarded the SPF will be valid and you might not notice the broader DKIM issue.)

Where does it break?

The issues that break DMARC tend only to apply to “loosely controlled” domains – domains that don’t have full control over their mail streams, or which have humans who feel they own addresses in those domains and so want to use them outside the limits DMARC places on them. AOL, Yahoo and LinkedIn are some domains who’ve done that.

There’ve been some rather hacky workarounds for some specific situations. Some discussion mailing lists put a fake email address in the From header, rather than the original author (which prevents DMARC policy triggered bounces, but causes problems for others on the mailing list). AOL added C0nstant Contact, Sailthru and Zendesk to their SPF record.

DMARC doesn’t force receiving ISPs to take any particular action – it’s just advice. Some ISPs treat it naively and discard or reject any mail with a DMARC p=reject domain in the From: header that fails authentication.

Others take a more realistic approach and acknowledge that, for example, a mailing list server with a good reputation that’s emitting unauthenticated email from users at AOL or Yahoo is far more likely to be breaking authentication for legitimate email it’s forwarding than to be an evil phisher.

What can we mitigate?

It would be really nice to be able to say “I trust the forwarder that sent this to me, and I trust them when they tell me that the mail authenticated correctly when they received it” in a more mechanical manner than “I trust this long list of mailing list servers”.

That’s the plan behind Authenticated Received Chain (ARC).

Authenticated Received Chain

In much the same way that regular Received: headers record the series of mailservers that an email passes through as it’s delivered, ARC’s ARC-Seal: headers record the series of administrative domains a company passes through.

An administrative domain is, pretty much, a single company or single email system. While an email going through Microsoft might go through give different mailservers with each mailserver adding a new Received: header the same email would have just on ARC-Seal: header recording it entering the microsoft.com email system.

Other than that, they record where an email has gone, just like a Received: header. Unlike a Received: header, though, they’re cryptographically authenticated so that the organization adding the header can take responsibility for that email at that point in the delivery. If you think that sounds similar to the DKIM concept of taking responsibility for an email as it’s sent, you’re right. An ARC-Seal: header is like a simplified, stripped-down DKIM signature that signs just the ARC-related headers of the message.

Each ARC-Seal header can also have a couple of other ARC headers associated with it.

One is ARC-Message-Signature:. It’s pretty much the same as a DKIM-Signature: header, letting each hop of the delivery add a new DKIM-esque signature of the body of the message and the headers of the message as they send it on.

The other is ARC-Authentication-Results:. It contains the same information as an Authentication-Results: header added by that hop would – did SPF validation pass? was the DKIM signature valid? (and potentially all sorts of other authentication results, from authentication methods that are obsolete or are yet to be invented).

A recipient can step through the series of ARC-Seal: headers and as long as they trust each participant they have authenticated information about the content of the message and the authentication status of that message as it was received by that participant.

This lets an ISP – if they invest in the reputation tracking needed to make the “trust” decision about each participant – identify email that would have been validly authenticated if it hadn’t been through a forwarder or a mailing list and treat that mail as though it were validly authenticated, for making decisions about rejecting it due to DMARC policies.

Who does this affect?

If you’re a user at a domain that publishes DMARC p=reject then ARC has the potential for making your use of forwarders and mailing lists much, much more reliable.

If you’re a participant in discussion mailing lists then as long as the mailing list manager deploys ARC and your ISP is ARC aware you’re less likely to see messages vanish due to DMARC issues, and your mailing list manager will (hopefully) remove some of the gross workarounds they’ve previously put into place to mitigate those problems.

If you develop mailing list management software, or anything that forwards email, you should be reading the ARC specs and following the ARC mailing list and be thinking about how you’re going to implement this.

If you use mailing list software, you should check up on whether it’s implementing ARC. If they are, deploy it when you can. If they’re not, ask them to.

If you’re a mailbox provider you should probably find out more. ARC is something you’re going to want to plug in to your existing reputation based filters.

If you’re a typical ESP and you send email on behalf of your customers who provide the content to you via a web interface or an API and who want to send “From” their consumer email address then ARC is not going to help you. This is not the fix for “individuals and small businesses with consumer email addresses want to run mailing lists” you were looking for. Sorry.

Senders of all flavours. There’s nothing you need to change. As ARC is rolled out it will make some forms of authentication breakage less common, and that may affect your decisions as to whether or when to deploy DMARC reject or quarantine policies. If you’re using DMARC p=none with reporting today you might see those changes happening over then next year or so.

Status

AOL and Gmail are showing ARC results today.

Gmail is adding ARC headers to mail they send or forward.

There are interoperable implementations of the core algorithms in python, C, milter and perl. And a test suite.

Mailman and Sympa are actively adding support.

Want to know more?

ARC home page: arc-spec.org

ARC specification: draft-ietf-dmarc-arc-protocol-03

Recommended usage: draft-ietf-dmarc-arc-usage-01

Mailing list: subscribe or read the archives

 

 

No Comments

The philosophy of DMARC

We know that legitimate email sent with valid SPF and a DKIM signature often breaks in transit.

SPF will fail any time mail is forwarded – via a mailing list, a forwarding service used by the recipient, or just ad-hoc forwarding.

DKIM will fail any time the message is modified in transit. That can be obviously visible changes, such as a mailing list tagging a subject header or adding a footer to the body. It can also be less obvious changes, such as intermediate MTAs wrapping lines that are too long, reencoding content or repackaging the message altogether – perhaps when delivering from a mailserver that is 8BITMIME compliant to one that isn’t.

(This image has absolutely nothing to do with email authentication, but searching for stock photography about email or authentication or chains or, well, pretty much anything like that leads to horribly depressing corporate imagery. So, no. Have something colourful and optimistic instead.)

As SPF and DKIM are typically used, none of this is much of a problem. A message being authenticated provides a little extra information to the receiving mailserver, and the domain attached to the authentication can be used to look up a senders reputation, giving a potential boost to the chances of the mail being sent to the inbox. If the authentication is broken, though, the mail will still be judged on it’s merits – is it coming from an IP address that’s a source of good mail, does the content look legitimate, and all the other things a spam filter looks at.

That authentication is a (potentially big) positive signal, but lack of authentication isn’t really any signal at all is why SPF and DKIM being fragile wasn’t an issue. SPF and DKIM are positive assertions – “IF this mail IS authenticated THEN IT IS from me”.

That changed when DMARC became popular, though.

DMARC allows the owner of a domain to say “We send no mail that is not authenticated, and we promise that none of that authentication will be broken in transit”. DMARC is a negative assertion – “IF this mail IS NOT authenticated THEN it IS NOT from me”. It converts the absence of a positive assertion into a negative assertion.

This isn’t the first attempt to layer a “we authenticate everything” negative assertion on top of fragile email authentication. SPF did it, with the -all flag (which is universally ignored, leaving SPF purely as a positive assertion). DomainKeys did it, with DomainKeys policy records (which you occasionally still see published, but were never really used to reject mail). DKIM did it with ADSP – which didn’t see much use either.

The reason none of them were used much is because even when senders were telling the truth about “we send no email that is not authenticated” they were always lying, to varying degrees, about “none of the authentication will be broken in transit”.

If your domain that is solely used for bulk email. If it’s never for used mail sent by human beings, not even customer support employees. If it’s a newly created domain with no legacy usage that only sends email from a very tightly controlled infrastructure. If you only send email that’s been created via a well implemented message composition pipeline that ensures the content of the is not just RFC compliant but also “well formed”, with short lines, simple widely implemented encoding, vanilla mime structure and so on. And it’s sent out via conservatively configured smarthosts that deliver directly to the end recipients MX. And if you know that the demographics of your recipients are such that the minority that are forwarding that mail elsewhere (e.g. from their Yahoo account to their Google account or via an alumni mail alias) is a small enough group that you don’t care about them…

If all of those things are true, then your domain is going to be able to deploy DMARC pretty easily and safely. If not, though, how can you tell?

That’s the place where DMARC improves over it’s predecessors. It allows you not only to publish a DMARC policy record in test mode, so it’s not actually used to filter your mail (well, mostly, but that’s a longer story) but also to ask recipients to notify you of mail that seems to be from you but which isn’t authenticated.

You can publish a “p=none” DMARC record with notification addresses in it and wait and see what happens. You’ll get notification of mail that has your domain in the From: field but which isn’t authenticated.

As a first round of action that lets you see where you’re sending email from that you didn’t know about. Sysadmin notification email. That marketing splinter group in Sasketchwan. The outsourced survey company.

Once you’ve cleaned all that up, and made sure everyone is authenticating their mail then you can look at what’s left. The next step is likely to be mistakes you’re making in authentication or message composition that’s causing some of your mail – typically depending on content, and source and recipient domain – to become unauthenticated. Clean that up, make sure all your message composition is squeaky clean, make sure employees aren’t sending mail using that domain in ways you don’t authorize (interacting with mailing list, for example).

By that point you’ll have reduced the torrent of reports you’re getting to two types. One is mail that you send that has it’s authentication broken in transit through some process you have no control over. The other type is mail that has your domain in the “From” field but which you didn’t send. Some of that may be legitimate use of your domain by your employees, such as forward-to-a-friend services, signing up for document delivery via email, third-party notification services. By deploying DMARC you are declaring all that sort of usage to be illegitimate, and you’ll need to get all your employees to stop doing it (or, at least, know that it’s going to stop working). The rest of it is likely a mix of spam and phishing mail. The spam, that’s just using your domain in random from addresses, you probably don’t care about. The phishing you do.

You’ve finally cleaned up your mail infrastructure and policies enough to gather the data you need. How much of my legitimate email will have it’s authentication broken (and hence be silently thrown away by DMARC)? And how much hostile phishing mail is targeting my users (and using the exact domain you are)?

Then you have the information you need to make an informed decision as to how badly deploying DMARC will break your legitimate use of email (after you’ve done everything you can to minimize that) and some idea of whether it will provide you any benefit, at least in the shorter term.

That testing phase, where senders can use other peoples mail infrastructure to investigate their sending practices, gradually fix any problems and finally gather some metrics is what made gave the developers of the DMARC spec confidence that it wouldn’t break things, and made it much more deployable than previous approaches to negative assertion.

On Monday, how all that optimistic reasoning went to hell, what it broke and how we’re trying to fix it.

No Comments

You’re kidding me

All the authentication and DMARC in the world can’t save you from stupid.

I just got a survey request from my bank. Or, at least, it claimed to be from my bank.

From: Barclays International Banking Survey <internationalbanking@barclayssurveys.com>

The mail passed SPF (though the SPF record suggests this is being mailed from all over the place) and was validly DKIM signed for barclayssurveys.com. And that domain has a DMARC policy

But there’s nothing in any of that that tells me – or mail filters – that this has anything to do with Barclays Bank.

“barclayssurveys.com” is what’s know as a cousin domain in the phishing world. It’s a domain that has absolutely nothing to connect it to the legitimate domain of the phishing target, but which looks plausible to a recipient.

This one didn’t actually look that plausible, though. The website is hosted on a RackSpace VPS with no reverse DNS configured. The domain is registered by “chime.plc.uk” – whose website is just an Outlook Web Access instance:

The survey it links to – the survey that is asking the recipient about their interaction with a financial institution – doesn’t use SSL. (The webserver it’s running on does speak SSL, so the issue is that they didn’t have a certificate for barclayssurveys.com). The URL it uses and the javascript it’s running suggests it was originally taken from Wix, the free website hosting platform. And it has references to several survey providers in the source that are hidden by CSS.

All of which would be suspicious enough if it came from my local dive bar, but this is coming from an international bank that’s big enough, rich enough and technically savvy enough that they own their own top level domain.

No institution can claim to care about phishing or account takeover as an issue when the legitimate email they send is less plausible than a typical phishing mail. This is just setting up their customers to fall for phishing mail.

And, yes, it’s from a legitimate survey firm. One that’s quite widely used in the United Kingdom and Éire. How do I know it’s widely used? Because the mail they send out leaks information about their customers:

X-Confirmit-FixedSenderDomain: factssurvey.co.uk, feedback-waveutilities.co.uk, feedback-anglianwaterbusiness.co.uk, npowersurveys.com, o2surveys.co.uk, gustosurveys.co.uk, customersatisfaction.rbs.co.uk, customersatisfaction.natwest.com, mail.customersatisfaction.rbs.co.uk, mail.customersatisfaction.natwest.com, panel.uk.com, virgintrainseastcoastsurveys.com, barclayssurveys.com, sunnyloanssurveys.com, sagafeedback.co.uk, boxcleversurveys.co.uk, surveys.ulsterbank.ie, sagafeedback.co.uk, barclays.com, titanfeedback.co.uk, barclaycardsurveys.com, aegonfeedback.co.uk, directionsurveys.co.uk

Just from the names I recognize that’s five major high street banks, a payday loan outfit, several utility companies, travel companies and a major cellphone company that are sending survey email that’s this badly done. And that’s probably just the ones that are being sent from this particular mailserver.

That moment when you type "WTF?" into Google image search

I went back and checked where my bank usually sent email from, and how their authentication was normally set up. The previous mail I got from them was a timely warning about “Phishing” and “Smishing” and “Vishing” warning me to be very careful about clicking on links in mail claiming to be from my bank, for fear of being phished.

It was addressed to “%first name%”.

2 Comments

Phishing increasingly sophisticated

Phishing is an online threat that’s been around for more than 20 years. I initially heard of it in relation to spammers taking over an AOL account to send out spam. These days phis is more dangerous and more sophisticated. Phishing is not just used to send spam. It’s used to take over elections; it’s used to steal millions of dollars. Experts estimate that globally phishing costs companies over 9 billion dollars a year.

Even in the last two weeks we’ve seen 2 major phishing incidents. One targeted Google Docs, one targeted Docusign. Reading the news reports these are different than many of the more common phishing attacks and, to me, represent an evolution in standard phishing techniques.

The Google attack in early May was an evolution in getting access to a Google account. Instead of directing users to a fake Gmail login page, the phish asked users to allow “Google Docs” (actually an app controlled by the phisher) to access to their Google account.

I’m sure all of you have used an app or website that lets you login with Facebook or Gmail or Twitter. This is all done with a protocol called OAuth. OAuth is also how you give access to mailbox management tools like I discussed a few weeks ago.  Basically, OAuth lets users grant access and permission to a site or application using a second site without revealing their username and password. (It’s more complicated than I want to discuss, but if you’re looking for some information check out some of the sites I’ve found: wikipedia, Varonis blog, Digital Ocean knowledge base, or just search google for oauth.)

The switch from asking for a password to asking for access is, to my mind, a significant change. Now we have to be aware of what we’re authorizing and make sure that app isn’t malicious.

The Docusign phish is another evolution.  As I was looking at the phish I received yesterday I realized that it was sent to a tagged address. A tagged address only Docusign had. None of my other, heavily phished, addresses received the phish. None of Steve’s addresses received the phish. This wasn’t a widespread spray and pray phishing attack. The phishers targeted Docusign users. Yesterday afternoon, Docusign confirmed that someone stole user addresses.

This is a switch from just randomly looking for victims to targeting users of a specific service.

Phishing attacks look for the weakest links to gain access to computers, information, and money. The weakest links are always humans. Phishers have adapted to security measures for the last 20 years. There is zero reason that they won’t continue to adapt.

 

 

 

No Comments

Shibboleet

Using unique addresses for signups gives me the ability to track how well companies are protecting customer data. If only one company ever had an address, and it’s now getting spam or phishing mail, then that company has had a data breach. The challenge then becomes getting the evidence and details to the right people inside the company.

In one case it was easy. I knew a number of people inside the company and knew they would take it seriously and pass it on to the folks in the best place to deal with it. I did. They did. They got their systems secured and notified customers and it was all taken care of.

Other cases aren’t as easy.

Many years ago I got mail from my credit card company to a unique address. This was long before SPF or DKIM and the mail contained links different from the company’s main domain. I called them up to see if this was real or not. They told me it wasn’t, because tier 1 support are trained to tell users everything is suspicious. Eventually, though, it became clear this wasn’t a phish, it was just bad marketing by the company.

A few years ago I reported a possible breach to representatives of a company while at a meeting. Coincidentally, the address only their company had started getting phishing and spam during the conference. I brought it up to them and followed their directions for reporting. They asserted the leak wasn’t on their end, but to this day I get multiple spams a day to that address. They claimed that the spammer was someone I was friends with on their website, but they could never quite demonstrate that to my satisfaction. I treat that site as only marginally secure and take care with the information I share.

After Target was breached they emailed me, out of the blue, to the address I use at Amazon. There was some level of partnership between Amazon and Target and it appears Amazon shared at least part of their database with Target. I talked with security folks at Amazon but they told me they had no comment.

Of course, on the flip side, I know how challenging it is to sort through reports and identify the ones that are valid and ones that aren’t. When I handled abuse@ we had a customer that provided a music sharing program. If a connection was interrupted the software would attempt to reconnect. Sometimes the connection was interrupted because the modem dropped and a new person would get the IP address while the software was trying to reconnect. This would cause a flood of requests to the new person’s computer. These requests would set off personal firewalls and they’d contact abuse to tell us of hacking. There wasn’t any hacking, of course, but they’d still argue with us. One of my co-workers had a nickname for these folks that was somewhat impolite.

We had to implement some barriers to complaints to sort out the home users with personal firewalls from the real security experts with real firewalls that were reporting actual security issues. So I get that you don’t always want or need to listen to J. Random Reporter about a security issue.

Sometimes, though, J. Random Reporter knows what they’re talking about.

Yeah, I spent the morning trying to get support at a company to connect me to security or pass a message along. Too bad there isn’t a security shibboleet.

No Comments

April 2017: The Month in Email

April was a big travel month for us. I went to Las Vegas for meetings around the Email Innovations Summit and to New Orleans, where Steve spoke on the closing keynote panel for the EEC conference.

I wrote several posts this month about privacy and tracking, both in email and in other online contexts. It’s increasingly a fact of life that our behaviors are tracked, and I wrote about the need for transparency between companies and those they are tracking. More specifically, I talked about the tradeoffs between convenience and security, and how people may not be aware that they are making these tradeoffs when they use popular mailbox tools like unroll.me. The folks over at ReturnPath added a comment on that post about how they handle privacy issues with their mailbox tools.

Steve contributed several posts this month. First up, a due diligence story about how service providers might look more closely at potential customers for their messaging platforms to help curtail spam and other fraudulent activity. He also looked at the history of “/8” IP blocks, and what is happening to them as the internet moves to IPv6. Steve also added a note about his new DMARC Validation tool, which rounds out a suite of free tools we’ve made available on our site. And finally, he showcased a particularly great email subscription experience from Tor.com — have a look!

I highlighted another post about companies doing things right, this one by Len Shneyder over at Marketingland. In other best practices news, I talked about bounce handling again (I mentioned it last month too), and how complicated it can be. Other things that are complicated: responding to abuse complaints. Do you respond? Why or why not?

Our friends at Sendgrid wrote a great post on defining what spammers and other malicious actors do via email, which I think is a must-read for email marketers looking to steer clear of such activity. Speaking of malicious actors, I wrote two posts on the arrest of one of the world’s top email criminals, Peter Levashov, and speculation that he was involved in the Russian hacking activity around the US elections. We’re looking forward to learning more about that story as it unfolds.

No Comments

ESPC meeting

Yesterday I had the pleasure of attending my first ESPC semi-annual meeting. I was scheduled to talk on a panel  about list hygiene with a couple vendors. Because some folks didn’t make it, I also sat on the panel talking about blocklists.

It was a fun day. I got to meet and talk with some colleagues I haven’t seen in an age. And I met some new faces and had interesting interactions.

One bonus from the day is I really got the chance to talk with some of the list hygiene vendors that were on the panel with me. Afterwards, we spent a good hour just discussing the space and the players in it. I learned a lot from that conversation. Previously, I’d kept the list hygiene vendors at arms length. My experiences with them and with their products weren’t very positive. My experience has primarily been with clients who have used these services and not gotten what they thought they were paying for. I have also seen some internet-abusive behavior from a few. Many years ago a few of the companies approached me for deliverability advice as they were running into consistent blocking.

All of these things led me to the conclusion that it was a part of the email space I didn’t want much to do with.

Yesterday, though, I learned that there were vendors in the space that focused very much on being a net benefit to the overall network. Both Webbula and Kickbox, who were on the panel with me, have policies and processes designed to make it unattractive for spammers to sign up for their services. We did agree there were problems with some of the vendors in the space, but I realized that some is not all.

It was a good meeting, I’m glad I went.

No Comments

Text to Image ratios in email

One of the questions I get from folks about delivery is what the optimal text to image ratio there should be in an email. I’ll be honest, I hate this question. Why? Because the question is actually irrelevant. I’ve seen companies with a single image and no text get to the inbox. I’ve seen companies with no images get to the inbox. The text to image ratio is not going to make or break delivery.

Sending mail that the user expects and wants is the crucial part of delivery. If the user wants a single image? That’s the right ratio. If the user wants a readable message with images turned off? That’s the right ratio. Fretting about 20/80 or 18.5/81.5 or 43.256666/56.743334 is getting buried in details and missing the bigger picture.

Emails should be readable. These days, being readable on mobile is critical. This is the single best argument I can think of against one-image emails. And there are still folks who read email with images off by default. Being one of them, I think it gives me insight other delivery folks lack. If I am engaged with a brand, how do I show it outside of loading images? What kinds of things let the brand know I’m still a happy recipient?

If anyone tells you that your delivery problems are the result of a bad text to image ratio, run away. There is zero chance that’s actually true. Filters aren’t going to just look at the ratio and block ratios that fall into a certain range.

What filters are going to do is take the text to image ratio as part of the fingerprint of an email stream. They’re going to recognize certain factors about emails that users like, and factors about emails that users don’t like. Some of these factors will be things like the text to image ratio. But the “wrong” ratio isn’t why mail is being filtered. Mail is being filtered because the recipients aren’t interacting with it enough and the ratio is just one part of the way the ISP identifies it.

Stop fretting over your exact text to image ratios. The right, or wrong, ratio isn’t a true factor in delivery. Instead, focus on creating an email stream that users want, expect, and engage with. This starts with address collection, but collecting accurate addresses isn’t enough. You also need to provide value to them.

Sending mail users want is the key to reach the inbox. Doing that takes time and investment by the sender.

No Comments

… and bad acquisition practices

I talked last week about how incentivizing people to sign up for your mailing list could be effective when it’s done well.

This week I’m staying at a Large International Hotel Chain and I’ve got a great example of what happens when it’s done poorly.

The “free” wifi requires you to join the hotel’s loyalty programme. I’ve done that in the past, so I login with my email address and password. Nope, the email address isn’t what you log in with, it’s an obscure nine digit number (but I only discover this after assuming I’d forgotten my password and attempting the password recovery dance, which doesn’t work).

OK, new loyalty programme account time. I create a new throwaway^W tagged email address and cough up some contact information. I get a welcome email. It has a Reply-To: address of, literally, “REPLYTOADDR”.

The newly created account also doesn’t actually get me in to the hotel wifi. I’m probably not going to be a terribly receptive recipient when they start emailing me at that address about what a great hotel they are. I’ll just unsubscribe. Any reasonable recipient not in the email industry will probably hammer the “this is spam” button until the mail goes to their spam folder and doesn’t come back.

On a somewhat related note, I have line-of-sight to a nearby discount mall. They have free public wifi and “me@privacy.net” already has an account on it in the name of “Eric”. I wonder how much email they send Eric?

3 Comments
  • OTA joins the ISOC

    The Online Trust Alliance (OTA) announced today they were joining forces with the Internet Society (ISOC). Starting in May, they will operate as an initiative under the ISOC umbrella. “The Internet Society and OTA share the belief that trust is the key issue in defining the future value of the Internet,” said Internet Society President and CEO, Kathryn Brown. “Now is the right time for these two organizations to come together to help build user trust in the Internet. At a time when cyber-attacks and identity theft are on the rise, this partnership will help improve security and data privacy for users,” added Brown.No Comments


  • Friday blogging... or lack of it

    It seems the last few Friday's I've been lax on posting. Some of that is just by Friday I'm frantically trying to complete all my client deliverables before the weekend. The rest of it is by Friday I'm just tired. Today had the added complication of watching the Trumpcare debate and following how (and how soon) it would affect my company if it passed. That's been a bit distracting, along with the other stuff I posted about yesterday. I wish everyone a great weekend.1 Comment


  • Indictments in Yahoo data breach

    Today the US government unsealed an indictment against 2 Russian agents and 2 hackers for breaking into Yahoo's servers and stealing personal information. The information gathered during the hack was used to target government officials, security employees and private individuals. Email is so central to our online identity. Compromise an email account and you can get access to social media, and other accounts. Email is the key to the kingdom.No Comments


Archives