Microsoft

Deferrals at Microsoft

If you’re seeing a lot of “451 4.7.500 Server busy. Please try again later” from Office365 this morning you’re not alone.

It looks like Microsoft are getting pickier about email address syntax, rejecting mail that uses illegal address formats. That might be what’s causing that “550 5.6.0 CAT.InvalidContent.Exception: DataSourceOperationException, proxyAddress: prefix not supported – ; cannot handle content of message” rejection.

Authentication at Office365

This is a followup from a post a few weeks ago about authentication changes at Office365. We have some more clarity on what is going on there. This is all best information we have right now.

Microsoft and SPF

Many deliverability folks stopped recommending publishing SPF records for the 5322.from address to get delivery to Microsoft. I even remember Microsoft saying they were stopping doing SenderID style checking. A discussion on the emailgeeks slack channel has me rethinking that.

SenderID is dead

A question came up on the email geeks slack channel (Join Here) about SenderID. They recently had a customer ask for SenderID authentication.

How accurate are reports?

One of the big topics of discussion in various deliverability circles is the problems many places are seeing with delivery to Microsoft properties. One of the challenges is that Microsoft seems to be happy with how their filters are working, while senders are seeing vastly different data. I started thinking about reporting, how we generate reports and how do we know the reports are correct.

Microsoft using Spamhaus Lists

An on the ball reader sent me a note today showing a bounce message indicating microsoft was rejecting mail due to a Spamhaus Blocklist Listing.
5.7.1 Client host [10.10.10.10] blocked using Spamhaus. To request removal from this list see http://www.spamhaus.org/lookup.lasso (S3130). [VE1EUR03FT043.eop-EUR03.prod.protection.outlook.com]
The IP in question is listed on the CSS, which means at a minimum Microsoft is using the SBL. I expect they’re actually using the ZEN list. ZEN provides a single lookup for 3 different lists: the SBL, XBL and PBL. The XBL is a list of virus infected machines and the PBL is a list of IPs that the IP owners state shouldn’t be sending email. Both of these lists are generally safe to use. If MS is using the SBL, it’s very likely they’re using the other two as well.

What's up with microsoft?

A c/p from an email I sent to a mailing list.
I think we’re seeing a new normal, or are still on the pathway to a new normal. Here’s my theory.
1) Hotmail made a lot of underlying code changes, learning from 2 decades of spam filtering. They had a chance to write a new codebase and they took it.
2) The changes had some interesting effects that they couldn’t test for and didn’t expect. They spent a month or two shaking out the effects and learning how to really use the new code.
3) They spent a month or two monitoring. Just watching. How are their users reacting? How are senders reacting? How are the systems handling everything?
3a) They also snagged test data along the way and started learning how their new code base worked and what it can do.
4) As they learned more about the code base they realized they can do different and much more sophisticated filtering.
5) The differences mean that some mail that was previously OK and making it to the inbox isn’t any longer.
5a) From Microsoft’s perspective, this is a feature not a bug. Some mail that was making it to the inbox previously isn’t mail MS thinks users want in their inbox. So they’re filtering it to bulk. I’ll also step out on a limb and say that most of the recipients aren’t noticing or caring about the missing mail, so MS sees no reason to make changes to the filters.
6) Expect at least another few rounds of tweak and monitor before things settle into something that changes more gradually.
Overall, I think delivery at Microsoft really is more difficult and given some of the statements coming out of MS (and some of the pointed silence) I don’t think they’re unhappy with this.

OATH and Microsoft updates

I’ve seen multiple people asking questions about what’s going to happen with the Yahoo and AOL FBLs after the transition to the new Oath infrastructure. The most current information we have says that the AOL FBL (IP based) is going away. This FBL is handled by the AOL infrastructure. As AOL users are moved to the new infrastructure any complaints based on their actions will come through the Yahoo complaint feedback loop (CFL). The Yahoo CFL is domain based. Anyone who has not signed up for the Yahoo CFL should do so.
When registering you will need each domain and the selectors you’re planning on using. Yahoo will send an email with a confirmation link that needs to be clicked on within a short period of time in order to activate the FBL.
Microsoft’s SNDS program had an outage at the end of last week. That’s been fixed, but the missing data will not be back populated into the system. This has happened a couple times in the past. It seems the system gets a live feed of data. If, for some reason, the data is interrupted, then it’s gone and doesn’t get populated.

Is purging always effective?

SNDS issues and new Gmail

A bunch of folks reported problems with Microsoft’s SNDS page earlier today. This afternoon, our friendly Microsoft rep told the mailop mailing list that it should be fixed. If you see problems again, you can report it to mailop or your ESP and the message will get shared to the folks who can fix it.
The other big thing that happened today was Gmail rolled out their new inbox layout.
It’s… nice. I’ll be honest, I am not a big gmail user and have never been a huge fan. I got my first account way-back-during-the-beta. I used it to handle some of my mailing list mail. I could never work out how to get it to stop breaking threads by deciding to put some mail into the junk folder. I just gave up and went back to my shell with procmail (now sieve) scripts. I still have a couple lists routed to my gmail account, and the filtering is much improved – I can at least tell it to never bulk folder certain email.
The feature I’m really interested in is the confidential, expiring email. I’m interested in how that’s going to work with non-Gmail accounts. Within Gmail makes perfect sense, but I don’t think Gmail can control mail once it’s off their system.

My best guess is that Gmail will end up sending some type of secure link to recipients using non-Gmail mail servers. The message itself will stay inside Google and recipients will only be able to view mail through the web. That’s how the vast majority of secure mail systems work.
If anyone has the secure message already, feel free to send me a secure message. I’ll report back as to how it works.

What kind of mail do filters target?

All to often we think of filters as a linear scale. There’s blocking on one end, and there’s an inbox on the other. Every email falls somewhere on that line.
Makes sense, right? Bad mail is blocked, good mail goes to the inbox. The bulk folder exists for mail that’s not bad enough to block, but isn’t good enough to go to the inbox.
Once we get to that model, we can think of filters as just different tolerances for what is bad and good. Using the same model, we can see aggressive filters block more mail and send more mail to bulk, while letting less into the inbox. There are also permissive filters that block very little mail and send most mail to the inbox.
That’s a somewhat useful model, but it doesn’t really capture the full complexity of filters. There isn’t just good mail and bad mail. Mail isn’t simply solicited or unsolicited. Filters take into account any number of factors before deciding what to do with mail.

Widespread Microsoft phishing warnings today

People throughout the industry are reporting phishing notices in a lot of mail going through Microsoft properties this morning. I even got one in an email from one of my clients earlier today

Multiple people have talked to employees inside Microsoft, and I suspect their customers have been blowing up support about this. I know they’re aware, I suspect they’re frantically working on a fix.
Update 11 am PDT: It appears this filter is firing when mail has the word “hotmail” in it. This includes if non displaying text (like CSS) has the word in it. It feels like they were attempting to mitigate something and wrote a rule that wasn’t quite right. Still no word on a fix, but don’t panic.
Update 12:30 PDT: Reports are that the warning is gone. No word from Microsoft, but as long as things get fixed we don’t need it.

Change is coming…

A lot of email providers are rolling out changes to their systems. Some of these changes are so they will comply with GDPR. But, in other cases, the changes appear coincidental with GDPR coming into effect.
It seems, finally, some attention is being paid to the mail client. Over the last few years the webmail providers have tried to upgrade their interface. Many of the upgrades are about managing high volumes of email in a more efficient manner. Google uses tabs while Microsoft has sweep and focused inbox.
It’s about time the mail client got an overhaul. My Apple mail client doesn’t look all that different from the desktop client I was using back in the late 90s on OS/2 Warp back in the late 90s. In some ways the OS/2 client was actually more functional. And, well, I do miss a lot of the flexibility of mutt in the shell.
Today, Google announced to Google Suite administrators that they would be rolling out a major client overhaul. G Suite admins who want to can join the early adopter program in the coming week. Techcrunch has a sketch of what the new mailbox layout looks like, done by someone who says they saw a Google engineer working on a train.
What’s interesting about the sketch is it seems tabs are going away. Given how many senders hate tabs I’m sure this is a welcome relief. We’ll see, though, if there’s not more inbox management built into the new client or not. The nifty new features are “snooze” – hide this email for some period of time and bring it back at some point in the future. The other big thing is calendar access right from the mail client.
I expect, too, that as OATH: brings the Yahoo and AOL mailboxes under one banner, there will also be some changes there. All of this amounts to more uncertainty in the email delivery space. But we’ll get through, we always do.

List-Unsub header

Benjamin asked in the comments where in the interface the “unsubscribe” or “block” popup appeared. This is the dialog box Microsoft uses when the add the “unsubscribe here” link at the top of a message. Screenshots taken today from my Hotmail account:
At this point we have 3 of the major webmail providers (Yahoo, Microsoft, Gmail) using List-Unsubscribe headers and at least one mobile client (Apple Mail). 20 years on it seems List-Unsubscribe is finally gaining traction.
Notice, too, that ISPs hold their own mail to the same standards as outside mail. This really is Microsoft offering to let me block everything from MSN News.

Still with the Microsoft problems

We took a quick trip to Dublin last week. I had every intention of blogging while on the trip, but… oops. I did get to meet with some clients, and had a great dinner while discussing email and delivery.

Coming back, I see a lot of folks still reporting delivery problems to Microsoft properties. I’ve been operating under the assumption this was temporary as kinks were worked out after the migration. I’m still pretty convinced not all of the problems are intentional. Even the best tested code can have issues that only show up under real load with real users. Reading between-some-lines tells me that the tech team is hard at work identifying and fixing issues. There will be changes and things will continue to improve.
With all that being said, I think it’s important to realize that delivering to the new system is not the same as delivering to the old system. This is a major overhaul of their email handling code, representing multiple years worth of planning and development inside Microsoft. It’s very likely that not all of the current delivery problems are the result of deployment. Some of the problems are likely a result of new standards and thresholds for reaching the inbox. What worked a year ago to get into the inbox just doesn’t any more.

Filters evolving

I started writing this blog post while sitting on a conference call with a bunch of senders discussing some industry wide problems folks are having with delivery. Of course the issue of Microsoft comes up. A lot of senders are struggling with reaching the inbox there and no one has any real, clear guidance on how to resolve it. And the MS employees who regularly answer questions and help folks have been quiet during this time.

In some ways the current situation with Microsoft reminds me of what most deliverability was like a decade ago. Receivers were consistently making changes and they weren’t interacting with senders. There weren’t FBLs really. There weren’t postmaster pages. The reason knowing someone at an ISP was so important was because there was no other way to get information about blocking.
These days, we have a lot more institutional knowledge in the industry. The ISPs realized it was better to invest in infrastructure so senders could resolve issues without having to know the right person. Thus we ended up with postmaster pages and a proliferation of FBLs and best practices and collaboration between senders and receivers and the whole industry benefited.
It is challenging to attempt to troubleshoot deliverability without the benefit of having a contact inside ISPs. But it is absolutely possible. Many ISP folks have moved on over the years; in many cases due to layoffs or having their positions eliminated. The result is ISPs where there often isn’t anyone to talk to about filters.
The lack of contacts doesn’t mean there’s no one there and working. For instance, in the conference call one person asked if we thought Microsoft was going to fix their systems or if this is the new normal. I think both things are actually true. I think Microsoft is discovering all sorts of interesting things about their mail system code now that it’s under full load. I think they’re addressing issues as they come up and as fast as they can. I also think this is some level of a new normal. These are modern filters that implement the lessons learned over the past 20 years of spam filtering without the corresponding cruft.
Overall, I do think we’re in a period of accelerating filter evolution. Address filtering problems has always been a moving target, but we’ve usually been building on known information. Now, we’re kinda starting over. I don’t have a crystal ball and I don’t know exactly what the future will bring. But I think the world of deliverability is going to get challenging again.

Oh, Microsoft

Things have been a little unsettled at Microsoft webmail properties over the last few months. A number of ESPs reported significantly increased deferrals from Microsoft properties starting sometime late in November. Others saw reduced open rates across their customer base starting in late October. More recently, people are noticing higher complaint rates as well as an increase in mail being dropped on the floor. Additionally, Return Path announced certification changes at the end of November lowering the Microsoft overall complaint rate to 0.2%, half of what is was previously.

Overall, sending mail to Microsoft is a challenge lately. This is all correlated with visible changes which may seem unrelated to deliverability, but actually are. What are the changes we know about?

Happy 2018

This is the time of year when everyone starts posting their predictions for the coming year. Despite over a decade of blogging and close to 2500 blog posts, I have’t consistently written prediction articles here. Many years I don’t see big changes on the horizon, so there’s not a lot to comment on. Incremental changes are status quo, nothing earth shattering there. But I’ve been thinking about what might be on the horizon in 2018 and how that will affect email marketing.

Microsoft MXs changed over

Today on MailOp it was announced that the migration of Microsoft freemail domains to the office 365 backend. Over the next week the mx*.hotmail.com mail servers will stop working. Check your settings, folks, and make sure you’re correctly querying DNS before sending.

Microsoft changes

There’s been quite a bit of breakage and delivery failure to various Microsoft domains this month. It started with them changing the MX for hotmail.co.uk, then the MX for hotmail.fr… and both these things seem to have broken mail. I also saw a report this morning that some of the new MXs have TLS certificates that don’t match the hostnames.

The cycle goes on

Monday I published a blog post about the ongoing B2B spam and how annoying it is. I get so many of these they’re becoming an actual problem. 3, 4, 5 a day. And then there’s the ongoing “drip” messages at 4, 6, 8, 12 days. It is getting out of control. It’s spam. It’s annoying. And most of it’s breaking the law.
But, I can also use it as blog (and twitter!) fodder.

Microsoft deprecating SmartScreen filters

At the beginning of the month Microsoft announced that they were deprecating the SmartScreen filters used by the desktop Microsoft mail clients. These are the filters used in Exchange and various version of Outlook mail. This is yet further consolidation of spam filtering between the Microsoft free webmail domains, Office365 hosted domains and self hosted Exchange servers. The online services (hotmail.com, outlook.com, Office365, live.com, etc) have been using these filters for a while. The big change now is that they’re being pushed down to Exchange and Outlook users not hosted on the Microsoft site.
EOP was developed for Outlook.com (and friends) as well as Office365 users. From Microsoft’s description, it sounds like the type of machine learning engine that many providers are moving to.
Microsoft has published quite a bit of information about these filters and how they work on their website. One of the best places to start is the Anti-spam Protection FAQ. Something senders should pay attention to is the final question on that page: “What are a set of best outbound mailing practices that will ensure that my mail is delivered?” Those are all things deliverability folks recommend for good inbox delivery.
Poking around looking at the links and descriptions, there is a host of great information about spam filtering at Microsoft and how it works.
A page of note is their Exchange Online Protection Overview. This describes the EOP process and how the filters work.

Improving Outlook Email Display

Today Litmus announced they had partnered with Microsoft to fix many of the rendering issues with Outlook. Congrats, Litmus! This is awesome. I know a lot of folks have tried to get MS to the table to fix some of the problems with Outlook. Take a bow for getting this off the ground.
According to Litmus, the partnership has two parts.

Ask Laura: Is the SmartScreen Filter Really Smart?

July 2015: The Month in Email

Once again, we reviewed some of the ways brands are trying (or might try) to improve engagement with customers. LinkedIn, who frequently top lists of unwanted-but-legitimate email, announced that they’ll be sending less mail. Josh wrote about giving subscribers options for both the type and frequency of messages, and about setting expectations for new subscribers. In each case, it’s about respecting that customers really want to engage with brands in the email channel, but don’t want the permission they’ve granted to be abused. I also wrote a brief post following up on our June discussion on purchased lists, and as you’d predict, I continue to discourage companies from mailing to these recipients.

Microsoft Send

Microsoft Send is a new mail client by Microsoft for iPhones and soon Windows Phone and Android phones. Send is designed to send quick, short messages to contacts. Instead of building a chat application build on a proprietary protocol, Send sends and receives its messages over email and uses your existing mailbox to handle the messages. What makes Send neat is that I can start a conversation within the app and when I get back to my computer, I can log into Outlook Web Access and continue the conversation.
MicrosoftSend

Messages to and from the Send app do not utilize subjects lines.

Sending a message from my personal account with Office365 to my Word to the Wise account and the email looks like any other email I received except with the #Send on the subject line.
Inbox

The message goes through the same outbound mail servers as if I sent it from Outlook or OWA, so emails pass SPF.

SPF

If you are signing with DKIM, the emails will be signed and authenticated.

(Office365 will sign emails with DKIM soon, it’s on the Office RoadMap.)
For an email to show up within the Send app, the subject contains #Send.
Microsoft has taken a unique approach to building a messaging app that utilizes existing SMTP infrastructure. If you’re sending to a tech savvy list, take a look at your logs to see how many recipients are using Microsoft Send and consider reaching out to them specifically using #Send.

Office365 checking DMARC on the inbound

According to a recent blog post, Office365 is starting to evaluate incoming messages for DMARC. I talked a little bit about DMARC in April when Yahoo started publishing a p=reject message.

Outlook 365 having a bad day

I’ve seen scattered reports today that some mail to the Outlook 365 servers is failing. This has been confirmed by ZDNet. Only folks with a Office 365 account can log in and see the status messages, but there are some folks on the mailop list posting updates from the website.
Attempts to mail to affected domains results in this response:

Ignoring opt-outs

One of the marketing solutions to the spam problem is just to have recipients opt out.

SNDS News

A number of people have mentioned over the last week or so that they’re seeing a lot of outages, failures and general ickiness with SNDS. I contacted Microsoft and asked about it. SNDS has been undergoing some upgrades and improvements and the outages were not intended to be end user visible. They’re going to keep a closer eye on things, while they finish the upgrades.
The good news in all of this is that SNDS is being upgraded and maintained. SNDS is still a functioning part of the Microsoft infrastructure, and this is good news for anyone who uses it as a data source.

4 things the new outlook ads tell us about email

Microsoft has a new TV ad showing how trivial it is to remove unwanted email from the inbox. Various busy people use the “sweep” and “delete” functions to clean up mail. The commercial even have a segment counting up the hundreds of emails deleted.
This tells me a few things.

DNS, SERVFAIL, firewalls and Microsoft

When you look up a host name, a mailserver or anything else there are three types of reply you can get. The way they’re described varies from tool to tool, but they’re most commonly referred to using the messages dig returns – NXDOMAIN, NOERROR and SERVFAIL.
NXDOMAIN is the simplest – it means that there’s no DNS record that matches your query (or any other query for the same host name).
NOERROR is usually what you’re hoping for – it means that there is a DNS record with the host name you asked about. There might be an exact match for your query, or there might not, you’ll need to look at the answer section of the response to see. For example, if you do “dig www.google.com MX” you’ll get a NOERROR response – because there is an A record for that hostname, but no answers because there’s no MX record for it.
SERVFAIL is the all purpose “something went wrong” response. By far the most common cause for it is that there’s something broken or misconfigured with the authoritative DNS for the domain you’re querying so that your local DNS server sends out questions and never gets any answers back. After a few seconds of no responses it’ll give up and return this error.
Microsoft
Over the past few weeks we’ve heard from a few people about significant amounts of delivery failures to domains hosted by Microsoft’s live.com / outlook.com, due to SERVFAIL DNS errors. But other people saw no issues – and even the senders whose mail was bouncing could resolve the domains when they queried Microsofts nameservers directly rather than via their local DNS resolvers. What’s going on?
A common cause for DNS failures is inconsistent data in the DNS resolution tree for the target domain. There are tools that can mechanically check for that, though, and they showed no issues with the problematic domains. So it’s not that.
Source ports and destination ports
If you’re even slightly familiar with the Internet you’ve heard of ports – they’re the numbered slots that servers listen on to provide services. Webservers listen on port 80, mailservers on port 25, DNS servers on port 53 and so on. But those are just the destination ports – each connection comes from a source port too (it’s the combination of source port and destination port that lets two communicating computers keep track of what data should go where).
Source ports are usually assigned to each connection pretty much randomly, and you don’t need to worry about them. But DNS has a history of the source port being relevant (it used to always use source port 53, but most servers have switched to using random source ports for security reasons). And there’s been an increasing amount of publicity about using DNS servers as packet amplifiers recently, with people being encouraged to lock them down. Did somebody tweak a firewall and break something?
Both source and destination ports range between 1 and 65535. There’s no technical distinction between them, just a common understanding that certain ports are expected to be used for particular services. Historically they’ve been divided into three ranges – 1 to 1023 are the “low ports” or “well known ports”, 1024-49151 are “registered ports” and 49152 and up are “ephemeral ports”. On some operating systems normal users are prevented from using ports less than 1024, so they’re sometimes treated differently by firewall configurations.
While source ports are usually generated randomly, some tools let you assign them by hand, including dig. Adding the flag -b "0.0.0.0#1337" to dig will make it send queries from source port 1337. For ports below 1024 you need to run dig as root, but that’s easy enough to do.
A (slightly) broken firewall
“sudo dig -b "0.0.0.0#1024" live.com @ns2.msft.net” queries one of Microsofts nameservers for their live.com domain, and returns a good answer.
“sudo dig -b "0.0.0.0#1023" live.com @ns2.msft.net” times out. Trying other ports above and below 1024 at random gives similar results. So there’s a firewall or other packet filter somewhere that’s discarding either the queries coming from low ports or the replies going back to those low ports.
Older DNS servers always use port 53 as their source port – blocking that would have caused a lot of complaints.
But “sudo dig -b "0.0.0.0#53" live.com @ns2.msft.net” works perfectly. So the firewall, wherever it is, seems to block DNS queries from all low ports, except port 53. It’s definitely a DNS aware configuration.
DNS packets go through a lot of servers and routers and firewalls between me and Microsoft, though, so it’s possible it could be some sort of problem with my packet filters or firewall. Better to check.
“sudo dig -b "0.0.0.0#1000" google.com @ns1.google.com” works perfectly.
So does “sudo dig -b "0.0.0.0#1000" amazon.com @pdns1.ultradns.net“.
And “sudo dig -b "0.0.0.0#1000" yahoo.com @ns1.yahoo.com“.
The problem isn’t at my end of the connection, it’s near Microsoft.
Is this a firewall misconfiguration at Microsoft? Or should DNS queries not be coming from low ports (other than 53)? My take on it is that it’s the former – DNS servers are well within spec to use randomly assigned source ports, including ports below 1024, and discarding those queries is broken behaviour.
But using low source ports (other than 53) isn’t something most DNS servers will tend to do, as they’re hosted on unix and using those low ports on unix requires jumping through many more programming hoops and involves more security concerns than just limiting yourself to ports above 1023. There’s no real standard for DNS source port randomization, which is something that was added to many servers in a bit of a hurry in response to a vulnerability that was heavily publicized in 2008. Bind running on Windows seems to use low ports in some configurations. And even unix hosted nameservers behind a NAT might have their queries rewritten to use low source ports. So discarding DNS queries from low ports is one of the more annoying sorts of network bugs – one that won’t affect most people at all, but those it does affect will see it much of the time.
If you’re seeing DNS issues resolving Microsoft hosted domains, or you’re seeing patterns of unexpected SERVFAILs from other nameservers, check to see if they’re blocking queries from low ports. If they are, take a look and see what ranges of source ports your recursive DNS resolvers are configured to use.
(There’s been some discussion of this recently on the [mailop] mailing list.)

Outlook.com

The big news in email today is Microsoft’s announcement of the next version of Hotmail: Outlook.com. This does appear to be an attempt to compete with a host of Google’s offerings. Not only does Outlook.com include Skype and access to social media accounts, but it also includes web app versions of Word, Excel and Powerpoint with 7GB of storage space.
I’m not sure how actively people will be grabbing Outlook.com addresses, as you can use hotmail.com addresses with the Outlook.com interface. Only time will tell, though, how this affects email marketing and spam filtering.

Robust protection under the CDA

Venkat also commented on the Holomaxx v. MS/Y! ruling.

As with blocking or filtering decisions targeted at malware or spyware, complaining that the ISP was improperly filtering bulk email (spam) is likely to fall on unsympathetic ears. It would take a lot for a court to allow a bulk emailer to conduct discovery on the filtering processes and metrics employed by an ISP. (Hence the rulings on a 12b motion, rather than on summary judgment.) Here the court reiterates the “good faith” standard for 230(c)(2) is measured subjectively, not objectively. That puts a heavy burden on plaintiffs to show subjective bad faith.
Read More

Amendment was futile

Judge Fogel published his ruling in the two Holomaxx cases today.

Holomaxx v. Yahoo and MS: The hearing

I visited Judge Fogel’s courtroom this morning to listen to the oral motions in the Holomaxx cases. This is a general impression, based on my notes. Nothing here is to be taken as direct quotes from any participant. Any errors are solely my own. With that disclaimer in mind, let’s go.
The judge is treating these two cases as basically a single case. When it came time for arguments, the cases were called together and both Yahoo and Microsoft’s lawyers were at the defendant’s table.
Oral arguments centered on the question of CDA immunity and to a lesser extent if there is an objective industry standard for blocking and dealing with blocks. Nothing at all was mentioned about the wiretapping arguments.
The judge opened the hearing with a quick summary of the case so far and what he wanted to hear from the lawyers.
Judge Fogel pointed out that current case law suggests that the CDA provides a robust immunity to ISPs to block mail. The plaintiff can’t just say that the blocks were done in bad faith, there has to be actual evidence to show bad faith. The law does permit subjective decisions by the ISPs. Also, that it is currently hard to see any proof of bad faith by the defendants.
The judge asked the plaintiff’s attorney for his “absolute best argument” as to the bad faith exhibited by the defendants.
The plaintiff responded that they are a competitor who is being stonewalled by the defendants. That their email is not spam (as it is CAN SPAM compliant) and it is wanted email. The defendants are not following the “objective industry standard” as defined by MAAWG.
The judge responded clarifying that the plaintiff really claimed he didn’t need to present any evidence. “Yes.” Judge Fogel mentioned the Towmbly standard which says that a plaintiff must have enough facts to make their allegations plausible, not just possible.
Yahoo!’s lawyer pointed out that both case law and the statutes require a robust showing to invalidate claims under the CDA. And that the purpose of the CDA is to protect ISPs from second guessing. She started to bring up the absolute numbers of emails, but was interrupted and told the numbers weren’t relevant. My notes don’t say if that was the judge or Holomaxx’s lawyer that interrupted, and the numbers discussion did come up again.
Yahoo continued that the CAN SPAM compliance is not a litmus test for what is spam. The decision for what is and is not spam is left to the subjective judgement of the ISP. She also pointed out that the numbers are important. She defined the amount of spam as a tax on the network and a tax on users.
She also addressed the anti-competitive claim. Even if Holomaxx is right, and neither defendant was conceding the point, and it is doubtful that the anti-competitive point can be proven, competition alone cannot establish bad faith. What evidence is there that either defendant exhibited bad faith? In Yahoo’s case there is zero advertiser overlap and in the Microsoft case Holomaxx showed one shared customer.
She then pointed out that the MAAWG document was a stitched collection of experiences from desks. That the document itself says it is not a set of best practices. She also pointed out that there was nothing in the document about how to make spam blocking decisions. That it was solely a recommendation on how to handle people who complain.
According to Yahoo!’s lawyer the plaintiffs brought this suit because they disagreed with the ISPs’ standards for blocking and they were upset about how they were treated. That the worst Holomaxx can say is the MS and Y! had bad customer service.
At this point there was some discussion between the judge and lawyers about how they were currently in a “grey area” between Rule 9(b) and Rule 12(b)6. I am not totally sure what this was about (one of my lawyer readers can help me out?) but there was also mention of using these rules in the context of the ISPs’ robust immunity under the CDA.
Finally, the judge asked Microsoft’s lawyer if he had anything more to add. He reiterated that the MAAWG document was not a standard, it was a collection of options. He also brought up the volume issue again, asserting that even if it is a true standard that the volume of unwanted mail sent by Holomaxx does not mean ISPs need to follow it.
Judge Fogle asked him if he meant there was no legal obligation for the ISPs to be warm and fuzzy.
The judge and defendant lawyers talked around a few general ideas about the MAAWG document. First that there was no obligation to tell senders enough information so that senders could reverse engineer spam filters. Microsoft also brought up the volume issue again, saying that the volume of unwanted 3rd party mail that the plaintiff was sending was, in itself, proof that the mail was bad.
Holomaxx interrupted claiming that the volume is a red herring. Judge Fogel countered with “but the gross number of unwanted emails is a huge number of emails.” Holomaxx’s lawyer argued that both Yahoo and Microsoft had large, robust networks, and the volume is irrelevant. I thought this was funny, given how often both of them have outages due to volume. However, the Holomaxx lawyer did have a point. Facebook sends billions of emails a day and both Yahoo and Hotmail can cope with that volume of mail and that volume dwarfs what Holomaxx sends.
The judge asked if he should look at the percentage of complaints about the mail rather than the gross number. Holomaxx replied that both were just a drop in the bucket and neither number was relevant.
Holomaxx then claimed again that MAAWG was a standard. The judge pointed out it was a standard for customer service, not a standard for blocking. Holomaxx disagreed and said that the MAAWG document was a standard for both how to block and how to deal with blocks afterwards.
The judge asked Holomaxx if there was any actual evidence of their claims. He talked about a case he heard a few years ago. Some company was suing Google because their search results were not on the front page of Google results. That company didn’t prevail because they never offered any actual evidence that Google was deliberately singling them out. He asked Holomaxx how they were being singled out.
Holomaxx replied there was no industry standard to measure against.
The judge wrapped up the hearing by pointing out that he was being asked to show where the exceptions to the CDA were and that he had to consider the implications of his ruling. He agreed that bad faith was clearly an exception to CDA protection, but what was the burden of proof required to identify actual bad faith. He seemed to think this was the most important point and one that would take some deliberation.
Overall, the hearing took about 15 minutes, which seemed in line with the case immediately before this one.
My impression was that the judge was looking for Holomaxx to argue something, anything with facts rather than assertion. But, I am scientist enough to see that may be my own biases at work. But the judge gave Holomaxx the opportunity to show their absolute best evidence, and Holomaxx provided exactly zero, instead falling back to it’s true because we said it’s true.
The judge will issue a written ruling, I’ll keep an eye out for it and post it when it’s out.

Still futile

As I mentioned last Thursday, both Yahoo and Microsoft filed oppositions to Holomaxx’s opposition to dismissal. Let me ‘splain… no, there is too much, let me sum up.
Holomaxx sued both Microsoft and Yahoo to force MS and Yahoo to stop blocking mail from Holomaxx.
The judge dismissed the initial complaint with leave to amend.
Holomaxx filed a first amended complaint.
Microsoft and Yahoo both argued that the first amendment complaint should be dismissed because it wasn’t fixed.
Holomaxx filed a motion in opposition to the motion to dismiss. Their arguments were reasonably simple.

Holomaxx doubles down

Holomaxx has, as expected, filed a motion in opposition to the motion to dismiss filed by both Yahoo (opposition to Yahoo motion and Hotmail (opposition to Microsoft motion). To my mind they still don’t have much of an argument, but seem to believe that they can continue with this.
They are continuing to claim that Microsoft is scanning email before the email gets to Microsoft (or Yahoo) owned hardware.

Further amendment would be futile

Both Microsoft and Yahoo filed their motions to dismiss the Holomaxx first amended complaint (FAC). Each company filed the same set of documents.

News about the Rustock takedown

Spam levels plummeted 2 weeks ago as the Rustock botnet was beheaded. Reports have been trickling out in the press about the takedown, about the botnet and about the team responsible.
Rustock Takedown Analysis at The Register
Brian Krebs’ intitial report of the takedown
Taking down botnets from a Microsoft attorney
Spam Network Shut Down at the Wall Street Journal
Global Spam Levels Graph from Symantec

Holomaxx v. MSFT and Yahoo

I mentioned way back in January that Yahoo had filed a motion to dismiss the case against Holomaxx. Microsoft filed a motion to dismiss around that time, although I didn’t mention it here.
And, of course, Holomaxx filed a motion in opposition in both the Microsoft case and the Yahoo case. Nothing terribly interesting here, about what you’d expect to read.
On March 11 the judge ruled on both motions to dismiss and in both cases ruled that the case was dismissed. He did, however, give leave for the complaints to be amended in the future.
As I expected the Judge agreed that MSFT and Yahoo have protection under the CDA. First, the court made it clear that providers are allowed wide leeway in determining what is objectionable to their customers.

Email and law in the news

A couple things related to the intersection of email and law happened recently.
The 6th circuit court ruled that the government must have a search warrant before accessing email. The published opinion is interesting reading, not just because of the courts ruling on the law but also because of the defendant. Berkeley Premium Nutraceuticals toyed with spamming to advertise their product as a brief search of public reporting sites shows. The extent and effort they went to in order to stay below the thresholds for losing their merchant accounts is reminiscent of the effort some mailers go through to get mail through ISP filters.
The other bit of interesting reading is the Microsoft motion to dismiss the case brought against them by Holomaxx. It is a relatively short brief (33 pages) and 3 of those pages are simply a listing of the relevant cases demonstrating ISPs are allowed to filter mail as they see fit. 2 more pages are dedicated to listing the relevant Federal and State statutes. I strongly encourage anyone considering suing any large ISP to to read this pleading. These lawyers understand email law inside and out and they are not going to mess around. They also have both statute and case law on their side. They point this out before the end of page 1:

Spam lawsuits: new and old

There’s been a bit of court activity related to spam that others have written about and I feel need a mention. I’ve not yet read the papers fully, but hope to get a chance to fully digest them over the weekend.
First is e360 v. Spamhaus. This is the case that actually prompted me to start this blog and my first blog post analyzed the 7th circuit court ruling sending the case back the lower court to determine actual damages. The lower court ruled this week, lowering the judgment to $27,002 against Spamhaus. The judge ruled that there was actual tortuous interference on the part of Spamhaus. In my naive reading of the law, this strikes me as not only an incorrect ruling, but one that ignores previous court decisions affirming that blocklists are protected under Section 230. Venkat seems to agree with me.

Microsoft delivery partnerships

Last week John Scarrow from Microsoft made a public statement on Deliverability.com about Microsoft’s approach to using available products in the email industry.