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 never outsource 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.

Comments (5)

  1. Norman Diamond says:

    > I think a good bulk emailer does the following

    > things:

    > It honours opt-out requests by providing a link to

    > click on, rather than replying with REMOVE in the

    > subject line.

    I can see why that could be good for customers who have always-on connections.  But a lot of the world still doesn’t have always-on connections, and it’s far better to accept REMOVE e-mail messages than to force customers to spend slow expensive dial-up time to visit a web site for it.

    Also consider these:  (1) People who have a bit of sense about security never click on a link in an e-mail message.  (2) People who get trained to click on links in e-mail messages don’t develop that bit of sense about security, making it easier to add them to your zombie pool.

    > It doesn’t ask you to whitelist them when you

    > receive their messages.

    Why not?  I seem to remember a few years ago that a big university accepted too many applicants and sent e-mail to too many of them, so some big knowledgeable ISPs routed the acceptance letters into the users’ spam bins.  What makes it good to hide the fact that unfortunately whitelisting is sometimes necessary?

    > one of my colleagues said that financial

    > instutitions should never outsource their bulk

    > email service

    That criticism cuts both ways.  Haven’t you ever received spam from a compromised bank?  Suppose the bulk e-mail service has some competent administrators so they get compromised less often than the banks themselves?

    On the other hand, I’ve received postal mail where financial institutions chose bulk mail services which were even more incompetent than genuine government-owned postal operations.

  2. tzink says:

    > it’s far better to accept REMOVE e-mail messages than

    > to force customers to spend slow expensive dial-up

    > time to visit a web site for it.

    What’s the difference between using bandwidth to send an email vs clicking a link?

    > People who have a bit of sense about security never click on a link in an e-mail message.

    Depends on the link, I suppose.  For example, replying to mail indicates that the email address is active, whereas clicking a link I see as a "passive" removal request.

    > What makes it good to hide the fact that unfortunately whitelisting is sometimes necessary?

    From a spam processing point of view, I’ve never felt comfortable with whitelisting.  The way I see it, a spam filter should be good enough to detect that the message is not spam and the newsletter should not be including spammy content such that it gets filtered as spam.

    > That criticism cuts both ways.

    Indeed it does.  Personally, I come down on the side of outsourcing the email to a third party, but I admit that it could make bank security folks uncomfortable.

  3. Norman Diamond says:

    > What’s the difference between using bandwidth to

    > send an email vs clicking a link?

    If you’re sending e-mail, then you tell Outlook Express to dial your ISP’s connection server, log in automatically, send the entire contents of your outbox, log out automatically, and hang up.  Sending the REMOVE message probably added a fraction of a second to this operation.

    If you have to open a web site, then you tell Internet Explorer to dial your ISP’s connection server, log in automatically, download and render a web page, remain connected while you type in whatever you have to type in, submit and render the next web page, and then wait for you to disconnect.  Probably about two minutes.

    >> People who have a bit of sense about security

    >> never click on a link in an e-mail message.

    >

    > Depends on the link, I suppose.

    Yes, you and I know how to right-click a link, copy shortcut, and examine the shortcut before browing to it.  But do you really think you’re going to teach that to an average user?  I would rather teach an average user to have a bit of sense about security by never clicking on a link in an e-mail message.

    > From a spam processing point of view, I’ve never

    > felt comfortable with whitelisting.  The way I see

    > it, a spam filter should be good enough

    OK, we agree, a spam filter *should* be good enough.  So what?

    This time you’re sounding very Microsofty.  Windows *should* be good enough, therefore don’t accept bug reports (except if users pay to submit them), don’t allow customers to download fixes, etc.  Do you know that this policy causes trouble for Windows users?  Now, spam filter users have the same needs.  We can accept the fact that real spam filter’s aren’t as good as perfect spam filters, *if* we get tools to work around the bugs.

  4. Andy says:

    As far as newsletters are concerned, I believe the envelope sender is usually being set to the domain of the mailer in order to enable tracking bounces. In other words, elabs3.com gets the bounce records for the campaign sent on behalf of nwa.com and processes them cleans up the list etc. etc. Whereas the promotions@nwa.com is left for real feedback from the recipients. It seems that SPF handles this, but isn’t this an issue with SenderID?

  5. Maarten O. says:

    Andy is right. In many cases the email service provider (ESP) is handling the bounces and has set up SPF records for it’s servers. The difficulty is with Sender ID, since the client want’s his own domain in the From: header. This requires the client to set up an SPF record with the mail servers of the ESP.    

    Often the ESP is more experienced with sender authentication than it’s clients. To make it easy for the client to implement Sender ID, they often use a subdomain or a new domain for all mailings sent by the ESP. By delegating the domain or using the redirect or include directive the ESP can manage the SPF records for it’s clients.

Skip to main content