New email header attempts to prevent damage of reissued email addresses

Posted by   Virus Bulletin on   Aug 27, 2013

Transactional emails not delivered if the account's owner has changed in the meantime.

When in June, Yahoo announced it would free up inactive user IDs, it received fierce criticism from the security community.

The concern was that many of these user IDs are tied to email addresses that, though dormant, may still be registered as the back-up address to other online accounts. Access to such a Yahoo! account could thus allow someone to take over the original owner's Gmail or Facebook accounts.

Yesterday, Yahoo! started to release some of the recycled user IDs. However, to mitigate the damage, it is accepting a new email header that senders can use to tell Yahoo! when the address was last confirmed.

If, for instance, Faceook sends a password reset to a Yahoo! email address, it includes a Require-Recipient-Valid-Since header, indicating when the address was last confirmed. Yahoo! will only deliver the email if the owner of the address hasn't changed since that time.

The header is the subject of a draft currently under review at the IETF.

I think this header is a really nice idea. The reissuing of email addresses was a problem before Yahoo! started doing so on a large scale: several ISPs are known to reissue addresses of former customers and in many organisations it is common practice for a new employee to receive email addressed to their predecessor.

I would certainly hope that many senders of transactional email would start using this header. At the same time, I would also hope its use would be constrained to these emails: I don't think it would be desirable if email marketers simply added this header to their emails rather than unsubscribing users whose emails bounce.

However, while I understand Yahoo!'s reasons for freeing up inactive user IDs, I'm still not convinced they've done enough to prevent possible damage. At the very least they should have waited until the draft had been accepted by the IETF and the practice of using the headers had been more widely adopted by senders of transactional email.

From a security point of view, I'd still rather have seen that Yahoo! didn't touch these old user IDs, no matter how dormant they may have been. A better alternative would have been to purchase a new domain name and use this for new customers not happy with the address Yahoo! could offer them. But, once widely implemented, this new header could make the problem a lot less serious.

Posted on 27 August 2013 by Martijn Grooten


email yahoo ietf


Latest posts:

VB2019 paper: APT cases exploiting vulnerabilities in region-specific software

At VB2019, JPCERT/CC's Shusei Tomonaga and Tomoaki Tani presented a paper on attacks that exploit vulnerabilities in software used only in Japan, using malware that is unique to Japan. Today we publish both their paper and the recording of their…

New paper: Detection of vulnerabilities in web applications by validating parameter integrity and data flow graphs

In a follow-up to a paper presented at VB2019, Prismo Systems researchers Abhishek Singh and Ramesh Mani detail algorithms that can be used to detect SQL injection in stored procedures, persistent cross-site scripting (XSS), and server‑side request…

VB2020 programme announced

VB is pleased to reveal the details of an interesting and diverse programme for VB2020, the 30th Virus Bulletin International Conference.

VB2019 paper: Cyber espionage in the Middle East: unravelling OSX.WindTail

At VB2019 in London, Jamf's Patrick Wardle analysed the WindTail macOS malware used by the WindShift APT group, active in the Middle East. Today we publish both Patrick's paper and the recording of his presentation.

VB2019 paper: 2,000 reactions to a malware attack – accidental study

At VB2019 cybercrime journalist and researcher Adam Haertlé presented an analysis of almost 2000 unsolicited responses sent by victims of a malicious email campaign. Today we publish both his paper and the recording of his presentation.

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.