Recent Posts

DMARC News – Gmail p=reject and ARC

DMARC.org announced this morning that Gmail will be moving to publishing a p=reject DMARC record in June of next year, much the same as Yahoo and AOL have.
Unlike Yahoo and AOL, Gmail are giving those who will be affected plenty of time to prepare for any issues, and have waited until there are some potential ways to mitigate problems in the development pipeline.
The ARC proposal, mentioned in the announcement, is one of the more promising mitigation approaches, and the specification for it can be found here:
Authenticated Received Chain (ARC) (draft-anderson-arc-00)
Recommended Usage of the Authenticated Received Chain (ARC) (draft-jones-arc-usage-00)
And some background on the issues it intends to mitigate can be found here:
Interoperability Issues Between DMARC and Indirect Email Flows (draft-ietf-dmarc-interoperability-07)

Silly Spam

I was cleaning out my inbox over the weekend and found a spam that actually made me laugh.

Yes, it is spam advertising the “Official Greed[sic] Card Lottery.” It’s been 20 years since I’ve seen one of those!

Glitchy Google Postmaster tools

A bunch of folks today mentioned they were seeing poor reputation for formerly good reputations on Google Postmaster Tools. I’m seeing a lot of screen shots that look like this one.

It looks like something is going on over there that has nothing to do with actual reputation. Could be a reporting bug, could be a filtering problem. I’m not seeing people mention delivery problems, just that the reputation monitor is showing bad reputation.

Network Solutions email issues

According to twitter and mailop Network Solutions is having issues with inbound mail, with both TCP level disconnections and 451 deferrals.

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.

Confusing the engineers

We went camping last weekend with a bunch of friends. Had a great time relaxing on the banks of the Tuolumne River, eating way too much and visiting.
On Saturday I was wearing a somewhat geeky t-shirt. It said 554: abort mission. (Thank you MessageSystems). At some point on Saturday every engineer came up to me, read my shirt and then looked at me and said “That’s not HTTP.”
That lead to various discussions about how their junior engineers don’t actually know SMTP at all. Why? Because the SMTP libraries just work. Apparently the HTTP libraries aren’t that great, so folks have to learn more about HTTP to troubleshoot and use them.
I’m sure there’s a joke in there somewhere: A Kindle engineer, an Android engineer and a robot engineer walk into a campsite…
It did leave me thinking, though, about how it’s not that easy to run your own mail server these days. Gone are the days when running your own server was cost effective and easy. These days, there is just too much spam coming in. Crafting filters is a skilled job. It’s not that hard to run good filters. But to run good filters takes time to do well.
There are also a lot of challenges to sending mail. One of the discussions I had at the campsite was how hard it was to configure outbound mail. The engineer was helping a friend set up a website and trying to get the website to send notifications to the friend. But without setting up authentication the mail kept silently failing.
Of course, we do run our own mail server. But it’s our job and, in many ways, it keeps us honest. We don’t run many filters meaning we see what spammers are doing and can use our own experiences to better understand what commercial filters are dealing with.
For most people, though, I really think using a service is the right solution. Find one with filters that meet your needs and just pay them to deal with the headache.

Lost in the mists of time

Over on the Farsight Security blog Joe St. Sauver talks about some of the early days of online abuse, on usenet. Laura and I were on the periphery of early usenet abuse, mostly as users, but Usenet (and IRC) around then were the places we both started with email abuse.

Yahoo FBL confirmation problems

Over the last few months I’ve seen people complaining about losing the Yahoo FBL emails with verification codes. This seems to be intermittent and no one could really explain what was going on.
Dale Lopez, VP of operations for V12 group, shared that their operations group discovered that one issue with the missing verification emails has to do with the length of the From: address and a port25 default settings.
In Dale’s words:

IPv6 and authentication

I just saw a post over on the mailop mailing list where someone had been bitten by some of the IPv6 email issues I discussed a couple of months ago.
They have dual-stack smarthosts – meaning that their smarthosts have both IPv4 and IPv6 addresses, and will choose one or the other to send mail over. Some domains they send to use Office 365 and opted-in to receiving mail over IPv6, so their smarthosts decided to send that mail preferentially over IPv6.
The mail wasn’t authenticated, so it started bouncing. This is probably going to happen more and more over the next year or so as domain owners increasingly accept mail over IPv6.
If your smarthosts are dual stack, make sure that your workflow authenticates all the mail you send to avoid this sort of delivery issue.
One mistake I’ve seen several companies make is to have solid SPF authentication for all the domains they send – but not for their IPv6 address space. Check that all your SPF records include your IPv6 ranges. While you’re doing that keep in mind that having too many DNS records for SPF can cause problems, and try not too bloat the SPF records you have your customers include.

Peeple, Security and why hiding reviews doesn't matter

There’s been a lot of discussion about the Peeple app, which lets random individuals provide reviews of other people. The founders of the company seem to believe that no one is ever mean on the Internet and that all reviews are accurate. They’ve tried to assure us that no negative reviews will be published for unregistered users. They’re almost charming in their naivety, and it might be funny if this wasn’t so serious.
The app is an invitation to online abuse and harassment. And based on the public comments I’ve seen from the founders they have no idea what kind of pain their app is going to cause. They just don’t seem to have any idea of the amount of abuse that happens on the Internet. We work with and provide tools to abuse and security desks. The amount of stuff that happens as just background online is pretty bad. Even worse are the attacks that end up driving people, usually women, into hiding.
The Peeple solution to negative reviews is two fold.