Policy

Evolution of policy

Last week, I talked about policy, using some different blocklist policies as examples. In that post I talked about how important it is that policy evolve. One example of that is how we’ve been evolving policy related to companies that get listed on Purchased Lists and ESPs. Who is listed has evolved over time, and we’re actually looking at some policy changes right now.

Thoughts on policy

A particular blocklist, once again, listed a major ESP this week. Their justification is “this is our policy.” Which is true, it is their policy to list under these circumstances. That doesn’t make it a good policy, or even an effective policy. It’s simply a policy.

Online communities and abuse

A few weekends ago we met a friend for coffee in Palo Alto. As the discussion wandered we ended up talking about some of the projects we’re involved in. Friend mentioned she was working with a group building a platform for community building. We started talking about how hard it is these days to run online groups and communities. One of the things I started discussing was what needed to be built into communities like this to prevent abuse and damage.

Policy is hard

We’re back at work after a trip to M³AAWG. This conference was a little different for me than previous ones. I spent a lot of time just talking with people – about email, about abuse, about the industry, about the ecosystem. Sometimes when you’re in a position like mine, you get focused way too much on the trees.

Of course, it’s the focusing on the trees that makes me good for my clients. I follow what’s going on closely, so they don’t have to. I pay attention so I can distill things into useable chunks for them to implement. Sometimes, though, I need to remember to look around and appreciate the forest. That’s what I got to do last week. I got to talk with so many great people. I got to hear what they think about email. The different perspectives are invaluable. They serve to deepen my understanding of delivery, email and where the industry is going.

One of the things that really came into focus for me is how critical protecting messaging infrastructure is. I haven’t spoken very much here about the election and the consequences and the changes and challenges we’re facing. That doesn’t mean I’m not worried about them or I don’t have some significant reservations about the new administration. It just means I don’t know how to articulate it or even if there is a solution.
The conference gave me hope. Because there are people at a lot of places who are in a place to protect users and protect privacy and protect individuals. Many of those folks were at the conference. The collaboration is still there. The concern for how we can stop or minimize bad behavior and what the implications are. Some of the most difficult conversations around policy involve the question who will this affect. In big systems, simple policies that seem like a no-brainer… aren’t. We’re seeing the effects of this with some of the realities the new administration and the Republican leaders of congress are realizing. Health care is hard, and complex. Banning an entire religion may not be a great idea. Governing is not like running a business.
Talking with smart people, especially with smart people who disagree with me, is one of the things that lets me see the forest. And I am so grateful for the time I spend with them.

Arguing against the anti-spam policy

Not long ago I was talking with a colleague who works for an ESP. She was telling me about this new client who is in the process of negotiating a contract. Normally she doesn’t get involved in negotiations, but the sales group brought her. It seems this new client is attempting to remove all mention of the anti-spam policy from the contract. As she is the deliverability and compliance person, the sales people won’t agree unless compliance does.
Her sales team needs props for bringing her in to negotiate a contract where the anti-spam clause is removed.
This isn’t that unusual situation. Many well managed ESPs will include deliverability and compliance personnel in negotiations if the customer indicates they want changes to the language of the anti spam clause.
On the face of thing it seems reasonable for customers to want to negotiate compliance terms. They want to protect themselves from unexpected outages. It seems irresponsible to allow a service provider to have the ability to made such a business affecting decision.
Many folks try to negotiate their way out of anti-spam clauses. Just asking for changes isn’t a big deal. However, some companies push the issue with sales and contract folks to an extreme. They threaten to not sign if the anti-spam clauses are removed completely.
Threatening a contract over compliance issues can poison an entire working relationship. The fact is that most people who argue about anti-spam clauses and compliance issues are people who have had problems with other ESPs in the past. For better or worse, prospects that try and remove anti-spam clauses from contracts are often problem customers.
On the compliance side, if someone is pushing hard to get the spam clause removed, they think a few different things:

Ethics in Internet Operations

In early September, I posted about a survey being done by Jan Schaumann regarding how sysadmins viewed their ethical obligations with regard to users. The results of this have now been published by Jan. He’s also shared his talk and slides on the data.
Well worth a look through the data. I took a quick run through of his talk and it looked interesting and is definitely going on my to-read list.

Do you run spam filters?

Jan Schaumann is putting together a talk on ethics in as related to folks managing internet operations. He has a survey and is looking for folks who wrangle the machines that run the internet. I’m copying his post, with permission, due to a slightly NSFW image on his announcement.

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:

Who pays for spam?

A couple weeks ago, I published a blog post about monetizing the complaint stream. The premise was that ESPs could offer lower base rates for sending if the customer agreed to pay per complaint. The idea came to me while talking with a deliverability expert at a major ESP. One of their potential customer wanted the ESP to allow them to mail purchased lists. The customer even offered to indemnify the ESP and assume all legal risk for mailing purchased lists.
While on the surface this may seem like a generous offer, there aren’t many legal liabilities associated with sending email. Follow a few basic rules that most of us learn in Kindergarten (say your name, stop poking when asked, don’t lie) and there’s no chance you’ll be legally liable for your actions.
Legal liability is not really the concern for most ESPs. The bigger issues for ESPs including overall sending reputation and cost associated with resolving a block. The idea behind monetizing the complaint stream was making the customer bear some of the risk for bad sends. ESP customers do a lot of bad things, up to and including spamming, without having any financial consequences for the behavior. By sharing in the non-legal consequences of spamming, the customer may feel some of the effect of their bad decisions.
Right now, ESPs really protect customers from consequences. The ESP pays for the compliance team. The ESP handles negotiations with ISPs and filtering companies. The cost of this is partially built into the sending pricing, but if there is a big problem, the ESP ends up shouldering the bulk of the resolution costs. In some cases, the ESP even loses revenue as they disconnect the sender.
ESPs hide the cost of bad decisions from customers and do not incentivize customers to make good decisions. Maybe if they started making customers shoulder some of the financial liability for spamming there’d be less spamming.

Clarification on monetizing complaints

There has been quite an interesting discussion in the comment stream of my earlier post about monetizing the complaint stream. I’ve found all the perspectives and comments quite interesting.
There is one thing multiple people have brought up that I don’t necessarily see as a problem. They assert that this idea will only work if all ESPs do it because customers can just say, “Well, Other ESP will let us do this and not charge us.” I don’t quite understand why this is an issue. Customers already do this. In fact, sometimes the assertion is actually true.
There are ESPs that let customers spam. There will always be ESPs that let customers spam. This is not new. Changing a pricing model isn’t going to change this.
As I was envisioning the monetization process, ESPs who wanted to do this could actually offer multiple tier pricing. The customer can choose a lower price point for their overall mail program, while assuming the cost of their recipients complaining. Or the customer can choose a higher price point and let the ESP absorb the cost of handling complaints. In either case, the customer would still have to meet the ESP’s standards for complaints and comply with their TOS.
Clearly I’m seeing the idea and industry differently than a lot of my readers. I’m interested to hear the thought process behind this so I can better understand the objection.

Monetizing the complaint stream

What if ESPs (and ISPs, for that matter) started charging users for every complaint generated? Think of it like peak pricing for electricity. In California, businesses can opt for discounted power, with the agreement that they are the first companies shut off if electrical demand exceeds supply. What if ESPs and ISPs offered discounted hosting rates to bulk senders who agreed to pay per complaint?
I see pricing scheme something like this.

Spammers react to Y! DMARC policy

It’s probably only a surprise to people who think DMARC is the silver bullet to fixing email problems, but the spammers who were so abusing yahoo.com have moved on… to ymail.com.
In the rush to deploy their DMARC policy, apparently Yahoo forgot they have hundreds of other domains. Domains that are currently not publishing a DMARC policy. Spammers are now using those domains as the 5322.from address in their emails. The mail isn’t coming through any yahoo.com domain, but came through an IP belonging to Sprint PCS.

This is just one example of how spammers have reacted to the brave new world of p=reject policies by mailbox providers. If only the rest of us could react as quickly and as transparently to the problems imposed by these policy declarations. But changing software to cope with the changes in a way that keeps email useful for end users is a challenge. What is the right way to change mailing lists to compensate for these policy declarations? How can we keep bulk email useful for small groups that aren’t necessarily associated with a “brand”?
The conversation surrounding how we minimize the damage to the ecosystem that p=reject policy imposed hasn’t really happened. I think it is a shame and a failure that people can’t even discuss the implications of this policy. Even now that people have done the firefighting to deal with the immediate problems there still doesn’t seem to be the desire to discuss the longer effect of these changes. Just saying “these are challenges” in certain spaces gets the response “just deal with it.” Well, yes, we are trying to deal with it.
I contend that in order to “just deal with it”, we have to define “IT.” We can’t solve a problem if we can’t define the problem we’re trying to solve. Sadly, it seems legitimate mailers are stuck coping with the fallout, while spammers have moved on and are totally unaffected.
How is this really a win?

How many people to enforce policy?

I’ve been head down working on a doc for a client and started wondering what the average size of an enforcement team is. This client told me during one of our calls they wanted to be as clean and well respected as another ESP, but was shocked when I told them how large an enforcement and delivery team that ESP maintained.
I know other clients of mine have 6 – 8 people for a very large customer base, and all of them take their job very seriously.
That got me to thinking: what is the average size of a policy and enforcement desk? Does it scale with userbase? Does it scale with the amount of mail you send? Is there a minimum size?
So tell me: how many people are on your policy and enforcement team?

Broken Policies

As an email policy wonk, I think a lot about how specific policy implementations can go wrong. Sure, every policy can go wrong, or not fit a common case. A lot of people only write polices that address common cases and don’t worry about the rarer cases. The problem is there are some rare cases that may cause significant harm and those cases should be addressed.
Consumerist has a case up about email policy gone wrong with a clear path to harm but no policy for handling the issue. There are a couple places I see where this policy hole can be fixed.
Chase Bank does no verification when they collect email addresses, which results in them sending email to a person who does not have an account with Chase. This is not an ideal situation for anyone. Chase is revealing private financial information to an outside party, the actual bank customer is not getting their information and someone is getting email about money that’s not theirs.
In terms of policy for institutions handling sensitive personal information, I would always recommend implementing a verification step. This is mail that people want so they should confirm it. It’s also mail that really should be not going to 3rd parties.
Chase does not implement any verification step for email. This isn’t a fatal problem, as long as there is some process in place to get feedback and then correct the issue.
Unfortunately, Chase’s policies failed here, too. Chase requires an account number to speak to a representative about any issues. In this case, the email recipient does not have an account number. All of Chase’s contact channels rely on an account number: no account number, no talking to a human.
In terms of overall policy Chase is hoping here is that, at some point, their actual customer will notice they’re not getting email and call in and attempt to troubleshoot the problem with Chase reps. I’m willing to bet, though, that their tier 1 people don’t have the training or information needed to troubleshoot this problem. I expect they’re going to read the script that says, “We sent you the mail, it must be a problem on your end. Have a nice day.”
Chase, and other bank analogues that require an account number, that do not verify email addresses should not require account numbers to talk to someone about the mail they are receiving. Why? Because although it’s reasonably rare that the mail is going to the wrong party, the potential harm to the bank’s customer is very high. This danger to customers means the bank should invest in a support pathway that allows non-customers to call, or write, to report misdirected email.
If Chase were my customer, I’d recommend adding a button to the email that says “receiving this mail in error, report here.” Make this a simple form that the recipient can fill out, two boxes one for email address and one optional one for “reason”. Once the bank has the report, they can stop the misdirected email and attempt to contact the customer through another channel. I’d also recommend that customers confirm any new address they add to the account in the future.
I know the bank thinks that by requiring an account number they are protecting their customers. Unfortunately, they’re failing to address a rare but potentially harmful case. Sadly, I expect even after this, they will still fail to implement any changes that will stop this from happening in the future.