X

Welcome to the Oracle Modern Marketing Blog:
The latest in marketing strategy, technology, and innovation.

Potential email marketing privacy risks with re-released Yahoo! IDs

Thomas Senne
Senior Director of Global Deliverability

Last week I published a post about how Yahoo! plans to re-release dormant IDs and make them available again. The plan is that on July 15, IDs that have had no log-ins within the past year will be deactivated and reissued a month later to new users.

At first glance, this seems like a fairly interesting chance for email marketers, and in a way it is.  Cleaning out old dormant email addresses from lists is always helpful. This is something that should be constantly performed on the sender side as customers stop responding to email. Now, this scenario also presents some new challenges. The first is a straight deliverability challenge that although somewhat scary, should be manageable. The second is around privacy implications and it's one that we are much more concerned about.

Here are my thoughts and advice:

Deliverability risks

If you are not purging inactive addresses from your list, you can expect to see an increase in bounces as once legitimate addresses are no longer valid.  This could have a short-term effect on deliverability if these numbers were to spike.

Yahoo! tells us that in the month between making the IDs available and re-issuing them, that they will be unsubscribing from any commercial email that is delivered to these addresses.  That sounds good, but I have questions about the logistics.  I am skeptical that valid unsubscribes will be sent for all commercial email.  Yahoo doesn’t support list-unsubscribe at this time.

Will this be a manual process?

How do you deal with a preference center?

Will Yahoo! just send email replies with “Unsubscribe” in the subject line?

What if you don’t receive an email in the 30-day period?

There are lots of questions, but bottom line is you should expect a significant amount of new address holders will be receiving email they didn’t sign-up to receive. An increase in complaints is the quickest way to bulking and blocking.

Privacy implications

Giving access to Personally Identifiable Information (PII) is the most dangerous aspect of this transition. If you now have access to an email address someone used as the sign-in for a website, they have all the tools needed to gain access to the old users account information. Someone could visit a site where the old address holder had an account, click the “forgot password link” and now be mailed a new password. You know the log-in is the email address, and now you have the password.  The danger here is real for sites that allow email address as a log-in and only verify ownership by possession of that email account. There is no way for Yahoo! to police this action because they have no knowledge of activity using that address outside their environment.

What’s next?

It is important to immediately evaluate your risk for this type of behavior. Do you only require an email address to verify sensitive data?  Will you send a username or password to someone if they provide only an email address?  If so, it is time to take some decisive action before August 15, when the IDs are reissued.

You should know which Yahoo! addresses are at risk. While you can’t know with certainty which addresses will be put back in the pool, you can look at your own engagement data. Flag any users at a Yahoo! address with no activity in the past 12 months. You should then strongly consider disabling those accounts.You can either require a different login, or create an entirely new account mapping.  It is critical to have separation because this will almost certainly be a brand new customer.

This is a change that depending on the method used to handle accounts could have little effect, or could be something that puts your company at risk. Either way, time is running short to find out.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.