Ben over at MailChimp writes about spamfilters that are following links in emails resulting in people being unsubscribed from lists without their knowledge. I strongly suggest clients use a 2 step unsubscribe system, that does not require any passwords or information. The recipient clicks on a link in the email and confirms that they do want to be unsubscribed once they get to the unsubscribe webpage.
Even more concerning for me is the idea that people could be subscribed to emails without their knowledge. For some subset of lists, using confirmed (double) opt-in is the best way to make sure that the sender really has permission from the recipient. Now we have a spam filter that is rendering “click here to opt-in” completely useless. I am sure there are ways to compensate for the stupidity of filters. As usual, though, the spammers are doing things which push more work off onto the end user and the legitimate mailers.
Spamfilters are stupid
S
RSS - Posts
[…] link. I filed this under “mildly concerning” and forgot about it until Laura pointed out that they might equally click on the links in those emails asking folk to confirm their email […]
I had a couple of questions about this. Do you have any information on which filters are clicking on links? What ramifications does this have on spam traps? If they are showing activity and possibly confirming, it could be difficult to know that you are sending email only to subscribers that want it.
So long as the filters are only using GET requests to pull down links, there’s nothing fundamentally wrong with them. It’s a basic (though oft-ignored) tenet of web development that GET requests should be idempotent; that is, they shouldn’t somehow change anything important on the server. That’s what POST is for.
A lot of people ignore this for convenience’s sake, but this is just one way that you can get bitten. Anyone remember the Google Web Accelerator that came out a while ago, then promptly disappeared? It’d pre-fetch links on a page to speed up things if you clicked them later on. And if one of those links happened to delete something from a blog, or log you out… well, then you begin to see why GET shouldn’t change things.
So yes, the perfect solution to this is a 2-step unsubscribe link: the first step takes to you a page with a form on it, and that form then POSTs something back that finalizes the unsubscribe request.
Tracking links, unfortunately, would need some other solution…
Idempotent just means that following a link twice has exactly the same effect on persistent state as clicking it once. It does not mean that following the link must not change state, just that after following it once, following it again must not change state further.
There are good reasons to avoid GET requests for changing state, but that’s not what idempotent means.
Two step unsubscribe, where the link in the email goes to a webpage with a prominent “click here to unsubscribe” button is often a good thing for unsubscription. It also gives people an option to not unsubscribe, when they click on the wrong link, or hit “return” with the wrong link focused, in a mail inadvertently, which isn’t that unusual in link-laden emails.
As for closed-loop opt-in… if someone is mailed a magic cookie that must be returned in order to subscribe them to a mailing list, and they give permission to others to use that cookie by posting the cookie somewhere public I have very little sympathy when those people they’ve delegated responsibility to use the cookie to add them to a mailing list. Installing software that automatically clicks on links in their inbound email isn’t quite the same, but I still won’t have any sympathy for the recipient (I’ll reserve that sympathy for the mailer who’ll later have to put up with frivolous spam complaints from the recipient).