I'd like to provide a single-click "Unsubscribe" links in the footer of the emails my service sends.
Obviously, many spam scanners will scan emails, and will follow any links found in the emails to scan their contents for malware. A workaround I have used so far:
If the "Unsubscribe" page is requested via HTTP GET, it renders a simple confirmation form and a bit of JS that submits the form on page load
If the "Unsubscribe" page is requested via HTTP POST then we unsubscribe the user
This way, the user will usually only need a single click on the form and they will get a "You have been unsubscribed" message. If they have JS disabled, they can still manually submit the confirmation form.
Now the problem is, some scanners like Office365's ATP will open the pages, and execute JS inside them. By executing JS they submit the form and cause user to be auto-unsubscribed.
I've considered adding checks to the auto-submit JS logic:
don't auto-submit for specific user agents
don't auto-submit for specific client IP ranges
trigger the auto-submit on mouse move event
But these all seem like brittle methods, hacks at best, that are bound to break as email scanners change their tactics.
I'm sure this problem has bit many people before me. Are there known reasonable workarounds, aside from just giving up the single-click functionality?
PS. I have added support for RFC 8058 but users are still going to click links in the footer.
This is a topic of ongoing debate at M³AAWG (The Messaging, Malware, and Mobile Anti-Abuse Working Group). It's a mess and there are no easy solutions. It sounds like you're doing everything right, but some anti-spam systems are a little too aggressive.
The big issue is that anything you can do can also be done by an abusive marketer or spammer.
The best proposal I've heard is just to put a timer on the action. Add a captcha for users that unsubscribe within 5 minutes of delivery and remove the captcha afterwards. (Do not implement this for your RFC 8058 List-Unsubscribe-Post link.)
My next favorite proposal is to add a canary link to the message. This should be invisible to human readers. If it is followed, it reverts recent click activity from that IP and bans the IP from action triggers for a time.
I like your ideas too, just make sure that if Javascript is disabled, the user can still unsubscribe after a confirmation button click.
There's a part of me (warning, I'm an anti-spam researcher) that wants these false positives. Hopefully that will teach my peers that they're doing such a bad job and that these escalations will keep coming to them. From your perspective, you get to pass the buck (though you will lose a few subscribers in the process).
Spam detection systems must be careful to avoid subscription management links (at least until the bad guys start disguising their payloads as unusbscribe links).
Related
I have read a few questions on here about e-mail clients prefetching URLs in e-mails. An answer to this seems to be to add a new confirmation page, where the user has to click a button to confirm the desired action.
But, this answer states the following:
As of Feb 2017 Outlook (https://outlook.live.com/) scans emails
arriving in your inbox and it sends all found URLs to Bing, to be
indexed by Bing crawler.
This effectively makes all one-time use links like
login/pass-reset/etc useless.
(Users of my service were complaining that one-time login links don't
work for some of them and it appeared that BingPreview/1.0b is hitting
the URL before the user even opens the inbox)
Drupal seems to be experiencing the same problem:
https://www.drupal.org/node/2828034
My major concern is with this statement:
As of Feb 2017 Outlook (https://outlook.live.com/) scans emails
arriving in your inbox and it sends all found URLs to Bing, to be
indexed by Bing crawler.
If this is the case, any URL in an e-mail meant to confirm an action, e.g. confirming a login, subscription, or unsubscription, can end up searchable in a search engine, if that's whats meant by indexed in the quote above. In this case, it's Bing. Not even a dedicated confirmation page where the user confirms the desired action truly mitigates this.
Scenario #1
If I email the user a login link with a one-time token in the URL, that URL will end up in Bing. This token will have a short lifetime, lets say 5 minutes, so I doubt anyone will manage to search on Bing and find the URL before the user clicks it or it expires.
Scenario #2
The user gets an e-mail with a link to confirm a subscription. This link is perhaps valid for 24 hours. This might(?) be long enough for someone else to stumble over the link on a search engine and accidentally (or on purpose) confirm the subscription on behalf of the user.
Scenario #2 is not uncommon, it's even best practice to use double opt-in as far as I am aware.
Scenario #3
Unsubscribe URLs in the bottom of newsletters. Maybe valid for forever? You don't want this publicly searchable in an search engine.
Assume all the one-time confirmation links land on a confirmation page where the user confirms the desired action.
Is it truly the issue that URLs in e-mails are indexed by search engines, at least Bing? And will they actually end up publicly searchable? If not, what is meant by indexed in the quote above?
I'll add for the sake of completion that I don't think I've had much of a problem with this in my own use of the web, so my gut feeling is that this is unlikely the case.
Is it truly the issue that URLs in e-mails are indexed by search engines, at least Bing?
I can't definitely say if they are being indexed or not, only Bing could answer this question, but they are surely being visited, at least with a simple GET request. I just tested this sending myself a link to a page on my website that logs the requests that are made against it, and indeed I'm seeing a GET coming from 207.46.13.181 (reverse DNS says msnbot-207-46-13-181.search.msn.com), which suggests that an automated program from search.msn.com is crawling the link. This leads me to believe that yes, they are trying to index the link's content somehow, but it's only my opinion really.
And will they actually end up publicly searchable? If not, what is meant by "indexed" in the quote above?
Well, again, impossible to say unless you work for Bing. In any case, "indexing" means exactly what you think it does: parsing the content of a page to potentially include it in search results.
The real question here is: does this somehow represent a security problem or will it compromise my website's functionality?
It surely has the potential to: if your confirmation/reset/subscription/whatever process only relies on a single GET request with the appropriate GET parameter, then you should definitely revisit the strategy, as it obviously allows anyone to perform the action (even maliciously for example enumerating possible IDs for your GET parameters).
If the link you are trying to send contains sensible information or can be used to alter important data for an user of your website, then you should at least put it behind a login page only giving access to the interested user. This way, anyone who wants to access it (including search engines) will be redirected to a login page if not already logged in.
If the link you are trying to send is just some kind of harmless confirmation link (e.g. subscribe/unsubscribe from a newsletter), then at least use a form inside the web page to do the actual confirmation through a POST request (possibly also using a CSRF token), otherwise you will unequivocally end up with false positives.
How websites like Facebook and Twitter are protected against bot during registration? I mean, there's no captcha at all on the signup form?
I want to create a signup form for a project, and I don't want bot during registration and Captchas are often ugly..
edit:
My question is really during the registration because I know Facebook uses Captchas once registred for the first time.
Facebook uses some sort of hidden spam protection, if you view source of sign-up form you will see things like:
class="hidden_elem"><div class="fsl fwb">Security Check</div>This is a standard security test that we use to prevent spammers from creating fake accounts and spamming users.
so capture becomes visible when javascript will think that you are a bot.
Where is few methods of making it harder for bots to complete registration without capture, things
like timing to fill out form, originators of mouse clicks events ect.
also random session based values in form (to privent direct submissions without downloading of the form first)
also some people use hidden form elements with common names like 'email' that is styled invisible in css but common simple bots will try to fill out all form fields and so you can block them if this hidden element have any value
twitter and fb spend lot of time on developing tecniques to block spammers i don't think they will made it public as it will be counter productive for them to fight the spammers.
But all the client side javascripts you can download from fb or twitter and study them if you want, because most of the protection will happen inside client not on server.
server could only issue some random session variable, check for valid headers in request, overall time etc. its really limited.
some sites are also use ajax exchanges between server and client during the time when user is filling out the form , mostly just to make it harder for bot developer to do simular fake exchanges of data.
Anyway, unfortunatelly where is no easy solution to do decent protection , espesially without captcha or some kind of question
also,
for submit button you can use image map instead of button,
you can dynamically create big image with a submit botton image drawn on it at random position using things like GDI in PHP and using css to display only portion of that image with the actuall button, and on server side check X and Y position of where mouse was clicked, this will be hard for bots to break.
Unless they use real browsers and just emulate keyboard and mouse. Anyway , as i said unfortunatelly where is no easy solution.
One way would be to send a verification to the user's email address or cell phone and obtain verification (so in that case, you would have to allow only one email address or cell phone per account)
Another option is to use "Negative CAPTCHA" or "Honeypot Captcha"
I don't know how Facebook and Twitter do it, but if you want to create something simple and that doesn't interfere with your site aesthetics, I know that some websites just ask the user to enter an answer to a simple math problem like "what is 2 + 3?". This is not the most secure way to do it, but it's just a thought.
Well you can always deploy hardware solutions as well to create Layer 4-7 firewall rules. You can create specific rules to look for the well known agents of bots crawling the web. However to stop newly created bots you need to know what agent they are using for the bot.
Since you don't want CAPTCHA, you can use Keypic - keypic.com - which is an invisible protection, no CAPTCHA needed. It's an efficient antispam method for any web form. Site users don't pass any tests which is good for the site as it improves the quality of the user experience and thus raises user engagement. The solution is a kind of an expert system which analyses the behaviour of the users and checks the databases, then makes a conclusion if the request comes from a legitimate user or a robot.
BTW, Twitter and Facebook still use CAPTCHA for password verification which is a very disputable method in terms of efficiency of such protection.
I had a problem with tons of bots signing up for my Nintendo site so I put a single image of Mario on the sign-up page (making sure nothing in the image data said "Mario") with the text "Who is this? Answer in one word." Haven't had a single bot sign-up since. Not sure if this is actually a good solution though, not sure how smart bots are. I'm kind of surprised that it worked.
In theory it might be keeping out a few legitimate users, but it is hard to imagine many legitimate users of a Nintendo site not knowing who Mario is...
Just signed up a third party email marketing provider, when I provide the template they give me a small tag to place which they subsitute with a user specific unsubscribe link.
My concern is that the link is single click, there is no subsequent confirmation, etc.. and whilst I am all for easy removal, I worry that any combination of malware scanners, AV engines, spam scanners will follow the link and thus unsubscribe many legitmate users.
Is this the norm to have a single HTTP GET request unsubscribe a user?
How are other developers handling this issue?
Note: The provider in question is critsend
Interesting question. It’s not the norm. But it’s common with cautious email service providers. For example, MailChimp also has a 1-click unsubscribe for his freemium users. I’m not a big fan of that, too. (I’d prefer a prefilled form field, where the user confirms his wish to unsubscribe by clicking "submit".) However, I didn’t witness any problems using 1-click-unsub until now.
FYI, here’s a discussion addressing a similar topic (false positive double opt-in confirmations). You might also want to check out this article and this discussion (forum registration required).
The norm is once clicked, it goes to a form which you click a button to confirm removal. That's strange there are even single clicks avaliable
Any side effect changing HTTP GET request is non-conforming as far as HTTP is concerned. In particular, see this from RFC 2616, section 9.1.1:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
It would be more standard to put the actual unsubscribe behind a form submission to cause a POST.
I know Campaign Monitor has built in procedures to catch non-user unsubscribes. Not sure about critsend.
I am considering making a very simple form for clients to use in a sort of web browser kiosk fashion, where they submit some of their information through the computer in the lobby at their option instead of writing something out by hand. This would be used if they come in person rather than calling or going to the web site first. I already have a form on our site for clients to use from their home computers so this would be very similar but tailored for and only used for the in-person clients.
Since the form will sort of just loop back to itself (not really "back" but just have a link to go back to a fresh form) for a fresh form after every client, how can I ensure that one can't hit back a few times to see the previous client's info? It's not really sensitive data, I just would like to provide that bit of privacy. Of course clients using our web site and the form there from their own computer are responsible for their own privacy.
Apart from having customer service walk to the computer and close and reopen the browser, or using AJAX, what should I do?
The other topics I've read related to this all have someone basically saying "you're not supposed to do that, you bad person". This seems like a valid reason to me. Any ideas?
Thanks!
Disable autocomplete by adding autocomplete="off" to the input tags or form tag.
So, 'Litmus', a web app for testing emails and webpages across browsers and email clients, has a proprietary method that they claim is able to track not just opens, clicks, browsers, etc (standard with an embedded image and pass-through link tracking.)
What's unique is they claim that they are able to track what actions the end user took, how long the end user read it for, and if they deleted or forwarded the email. They claim they do this without JavaScript, and purely using embedded images. They claim that the method works across most major email clients.
What could they be doing to track this? Obviously, if they're doing it with third party applications that they don't control, whatever they are doing should be replicable.
I'm thinking that they realized that when an email client forwards or deletes an email, it 'opens' the email in a different way then normal, creating a unique user string on the server log of some kind? I'm grasping at strings, though.
http://litmusapp.com/email-analytics
Details here http://litmusapp.com/help/analytics/how-it-works
EDIT: It also looks like they track Prints. Maybe they do this by tracking calls to the 'print' css?
It's all done with good ol' image bugs. Breaking down how they find out...
Which client was used: Check the user-agent
Whether an email was forwarded: Done by attaching image bugs to divs that are loaded only when the message is forwarded.
Whether an email was printed: bug attached to print stylesheet
How long it takes to read an email: A connection that's kept open, as pointed out by Forrest (this is also how Facebook tracks(ed?) whether or not you are online on chat).
Whether an email was deleted: Check If a message was read for a short period of time or not opened. In fact, they group "glanced" and "deleted" together.
Of course none of this will work if email clients disable images in emails.
EDIT: Here's another question on this:
The OP actually has their tracking code, and this answer here explains how it works.
One way I can think of doing that is having an embedded image that loads from a script on a server. The script would not return anything or maybe send data really slowly to keep the connection open. Once the email is deleted the connection would be closed. This way they could know how long the email was open. Maybe they just assume if it's open for less than 10 seconds it was deleted?
Another way is tracking the referrer - this would give a lot of data on what a webmail client is doing, but I doubt it would be useful with a desktop client.
They know when the email is opened (it's when the image is called from their http server).
They also know what the user do and when since they can easily replace all links with their own tracking URLs redirecting to the original link.
There is nothing exceptional here. They are just a bit more advanced than their compatitors. There is no magic.
I have only one doubt: how they track delete. Technically, there is no way to know what happened to the message after it was read.
I suspect that a "deleted" mail is a mail that is never opened.