The FCC recently published a notice of proposed rulemaking that will have an impact on how we fight abuse on the internet. M3AAWG has submitted a comment on the proposal (pdf link). All submissions can be found on the FCC website.
Judge Koh published her ruling on Google’s motion to dismiss today.
It’s a 43 page ruling, which I’m still digesting. But the short answer is that Google’s motion was denied almost in total. Google’s motion was granted for two of the claims: that email is confidential as defined by the California Invasion of Privacy Act (CIPA, section 632) and dismissal of a claim under Pennsylvania law.
Update: As of mid-morning pacific time on 10/7 yahoo.com has been removed from the FCC list.
As part of CAN SPAM the FCC maintains a list of wireless domains that require proof of permission to send mail to. Recently, various email folks noticed that yahoo.com was added to this list.
According to the law, senders have 30 days to meet the permission standards for any recipients at domains on the FCC list. In practical terms what this means is that the FCC and Yahoo have 30 days to fix this error and get yahoo.com off the list. Based on conversations with people who’ve talked to Yahoo and the FCC this is in the process of happening.
This isn’t the first time a non-wireless domain has been added to the FCC list.
As a sender what should you do with your yahoo.com subscribers?
Right now, nothing. There is a 30 day grace period between when a domain goes on the FCC list and when senders need to comply. I have every expectation that this will be removed in less than 30 days.
But what if it’s not?
In that case you will need to segregate out yahoo.com subscribers in 30 days and not mail them until the domain is removed from the FCC list. While I can’t actively suggest ignoring the law, it’s unlikely that the FCC is going to start coming after senders for mailing yahoo.com addresses once the 30 days are up.
More information: Al Iverson’s Spam Resource.
When you’re developing code to handle data it’s almost essential to have a decent sized set of test data, so you can build a test harness to check on functionality and performance as you go.
A common way of doing that is to take a snapshot of your production database and pull out an appropriate subset from there. That works pretty well in most cases, but it’s a really bad idea if the data you’re working with is personally identifiable information, such as email addresses, phone numbers, credit cards and so on.
Test data gets spread everywhere. It’s checked in to source control systems, copied to developers laptops, included in publicly visible bug reports, shared with mailing lists when asking questions and sent to that dodgy overseas outsourcing company your CTO is evaluating. And if the code you’re developing sends email or SMS messages then sooner or later you’re going to misconfigure your test platform and send test messages to the contacts in your test data. (I’ve only done that once, and it was a memorable experience.)
But test data needs to be similar to real data, and look plausible, or it’s hard for manual testers to identify problems using it.
Enter randomuser.me – a simple API for generating random user data – name, email address, birthdate, phone numbers, postal address, social security number, even photos.
Need something more configurable, that lets you create a fake API to test your code against? Try RandomAPI for a web API returning JSON, SQL, CSV or YAML.
Just need some test JSON files you can generate and paste in to your test suite? Try JSON Generator.
Need bulk data, to load into your test database? Look at Mockaroo, DummyData or GenerateData.
Just don’t use your production PII, even if you plan on anonymizing it before use. Really.