Sender authentication part 18: More hazards

The other hazard I'd like to look at with regards to SPF and SenderID is the issue of newsletters, or more specifically, bulk emailers.

Bulk emailers have a long and checkered history of using questionable email practises.  They put in lots of advertising in their messages that spammers often mimic (refinance your mortgage, reduced price software, free <insert word here>), they have opt-out requests unselected in sign-up pages (often in grey text with font size = 1), they sell your email address to other bulk emailers (jerks) and usually insert a lot of HTML in their message, a lot like how spammers used to do it a couple of years ago.

Still, even though there are a lot of grey-hat mailers, there are some legitimate ones as well.  Bulk email really is a necessity to business.  Businesses have to keep in contact with their customers and those that have signed up to receive email from the business want to hear from them.  If a customer wants to hear about the latest sale at Home Depot, or United Airlines wants to tell its preferred customers about its latest vacation travel package, or Starwood Hotels keeps bugging me about its latest savings plan even though I only stayed with them one time and regret turning over my email address, the reality is that email marketing is something that business must do.

I think a good bulk emailer does the following things:

  1. It honours opt-out requests by providing a link to click on, rather than replying with REMOVE in the subject line.
  2. It doesn't sell your email address to anyone.
  3. It makes you opt-in by default - that means that the checkbox is unclicked when you go to the page to sign up for something.  This is more the responsibility of the merchant, but still...
  4. It doesn't ask you to whitelist them when you receive their messages.
  5. It publishes SPF and SenderID records.

Aside from that, bulk mail has the issue of how it identifies itself.  Suppose that website goodmailers.com has SPF record v=spf1 ip4:1.2.3.4.  It then does a mailing campaign for Northwest Airlines.  What does it put in the message headers?  Let's deal with SPF first.

In the message From: address, it could put promtions @ nwa.com.  It could put a different Reply-To to get replies, but what does it put in the Envelope Sender?

Suppose the SPF record for nwa.com is v=spf1 ip4:139.72.159.240 ip4:139.72.159.241 mx ~all.  That means that goodmailers.com, if they don't want to get mail rejected by email servers that use SPF, must put mail @ goodmailers.com as the envelope sender.  Wouldn't that look a little odd?  It is supposedly coming from nwa.com but the Return-Path says goodmailers.com?  I don't know that much about marketing and branding, but I bet somebody at nwa.com does and wouldn't like a bulk sender putting their stamp on their customer marketing messages.

But, if goodmailers puts promotions @ nwa.com as the envelope sender, then from the above we can see that if the mail is coming from 1.2.3.4 (the IP authorized to send mail from goodmailers.com), this will fail the SPF check from nwa.com's SPF record.  So, on the one hand we have a marketing problem and the other we have a security problem.

In reality, nwa.com gets around this by having a different SPF record than what I put above.  It's actually the following:

v=spf1 ip4:139.72.159.240 ip4:139.72.159.241 mx include:elabs3.com ~all

Northwest Airlines actually outsources their bulk mail to EmailLabs and specifically authorizes them to send email for them.  This means that elabs3.com can send bulk mail for Northwest Airlines and put nwa.com as the envelope sender.

A SenderID implementation will take a look at this SPF record, and because elabs3.com is authorized to send mail, it will (probably) extract the PRA, most likely the From: or Sender: address, and this, too, will pass an SPF check.

This raises the question of whether or not Northwest Airlines really wants to add elabs3.com to their SPF records.  They don't own EmailLabs so that means there needs to be a lot of trust between them and NWA.  This may not be so bad for an airline, but what about a financial institution?

In a discussion last week, one of my colleagues said that financial instutitions should neveroutsource their bulk email service.  It's too much of a risk.  If the bulk mailer was ever compromised (or ever turned gray or black) they could do an incredible amount of damage to their customers in a short amount of time.  The emails would get through SPF and SenderID checks and customers might be tempted to enter in their information.  On the other hand, there would be an incredible lawsuit in that case and the email provider would be out of business in short order - both from the lawsuit and from the loss of business.

It's still debateable whether or not financial institutions and even other businesses want to add bulk mailers to their SPF record.  If you don't control the domain in your SPF record, you may want to think twice before adding it.  On the other hand, as a business you probably want to outsource your mass emailing.  I guess the CFO and chief security officer need to evaluate the risk/reward ratio.