Reporting Spam on Mobile Devices
Return Path’s new study “Email on the Move: The Future of Mobile Messaging” reveals that the massive increase in email readership on mobile devices corresponds with a decrease in use of webmail, particularly on weekends. If your focus is either spam detection or list management, that’s bad news.
Unlike webmail interfaces, very few mobile email clients give users the ability to report spam effectively. There’s no “report spam” button, and no way to forward a message with the full original headers & body required to accurately track down the source.
In legitimate messages, the unsubscribe link is often in tiny text at the bottom of the message; on a mobile device, scrolling all the way down can take a long time. Worse, accessing the web site requires browser handoff functionality that not all devices offer. Even when the site can be accessed, subscription preference centers are rarely optimized for mobile devices.
When there’s not an easy and obvious way to unsubscribe, users of webmail systems can report the message as spam, and it’ll usually find its way back to the sender via a complaint feedback loop. Without a spam button, a mobile recipient’s only choices are to leave the message in their inbox and deal with it when they get home, or just hit delete. Deleting it without sending any report or complaint means they’ll receive similar messages again and again, and they’ll be that much more upset with the sender — less likely to ever make a purchase.
This problem isn’t unique to mobile devices. Most desktop email clients also don’t have a spam button that interfaces with the mailbox provider’s complaint feedback system. Last year the Anti-Spam Research Group (part of the Internet Research Task Force, an open research group operating alongside the IETF) discussed and documented some possible options for adding a “junk” or “spam” button to email clients, but there hasn’t been much interest from email client developers.
Similarly, the Open Mobile Alliance has for some time been working with the MAAWG Wireless SIG and the IETF Mail Abuse Reporting Format working group to develop a reporting standard based on ARF, with a mobile messaging focus (both email and SMS text messaging.) This work is still in progress.
So, what can we do in the meantime? Unfortunately, not much.
If you’re sending legitimate email with complex HTML, it’s important to remember that your lovingly designed message will look absolutely hideous on many mobile devices. Return Path’s Campaign Preview (pdf) lets you see what each message will look like on dozens of different displays, including mobile. You can also try sending the message to your own device and friends’ devices. When you do, make sure it’s possible to unsubscribe — you can always subscribe again afterwards, and test that part too.
When you’re working with spam complaints, you’re already used to the low reporting numbers — enough for a valid statistical sample, but not enough to guarantee complete coverage. Even users who have access to a spam reporting button don’t always use it, or use it inconsistently. So you’ll have to continue tweaking the algorithms, tracking which users are valuable reporters, which are trying to game the system, and which are just inexplicably random. Unfortunately, users who (like myself) read email on four different devices throughout the day will probably fall into that third category.
And if you’re a software developer who’d like to implement an effective spam reporting feature into your mail client, email me and I’ll gladly introduce you to the people who’ve been working on the reporting standards described above.