They all seem to be either bouncing explicitly or silently not going through now (0 open/click rate), and they had been working since they first introduced the feature. I know they aren't giving users the option to choose a proxymail.facebook.com address anymore in the newer Auth box. Thanks.
The answer is NO. Facebook no longer issues proxymail addresses.
Although there is no official reference which I can attach with this answer. But found this for reference.
Pretty sure it's still available to users, but Facebook rolls out
updates to their dialog boxes slowly, so it's possible a newer (or
even an older) one doesn't have that option.
This was one link where you had that:-
Now after the recent updates the Change button was removed.
I can answer the specific question I asked so long ago. I think Facebook must have had a bug for a while that broke the *#proxymail.facebook.com email integration, and it was during this period that I asked my original question. However, looking at our email logs, I can see that we have had people click on links in email sent to these Facebook proxy emails at the end of October, so whatever the issue was must have been resolved, and I believe if you have a Facebook proxy email, you can safely send to it.
That being said, of course the individual user may have revoked the email permission (in which case their proxy email will go to nowhere), and my impression is the same as sfussenegger that Facebook is no longer allowing users to use proxy email addresses. I haven't seen the option to anonymize my email in a FB permissions dialog in a long time...
does this answer your question?
Communicating Directly with Your Users via Email
The reason you're getting no click-rates, is because in all outgoing emails that go through the facebook proxymail servers, the remailer is rewriting the links. So stuff of the form:
<a href="http://www.domain.com/">
gets re-written as:
<a href="l.php/?u=http://www.domain.com/">
Which is a broken link, and so your open-detection or click-detection probably won't work at all. And undoubtedly, users are confused (as evidenced by my users who ran into this).
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.
This is not exactly a programming related question but it is closely related to developing so I think it is pertinent.
I´ve been charged in my work with developing an app with access to Facebook Messenger. I needed a Facebook Account and I didn´t want to use a personal one (and I don´t use Facebook anyway) so I created a new gmail account to use it to sign up in Facebook, as user and as a developer.
After a couple of days of work, having created the page, my webhook, done some tests, etc., and investing a good deal of work hours, my account appeared as disabled.
I have to admit a didn´t use much of real info on this account (I´m kind of allergic to disclosing personal information unless mandatory), and the account was new so I thought that maybe that was the reason (they don´t give you any).
So I tried again a second time with an account I had been using for years (just for logging in some sites, not much of real information there neither, as I say I don´t really use Facebook), and after a couple of days, same results, locked account.
I can´t stress enough I don´t use the API extensively, I just send some messages to another user I have added as one of the application developers so I can test (that other account is never blocked, by the way). It´s not like I am sending hundreds of messages or anything like it. And by the way, I have never been blocked while I was doing something (so I could indentify my wrongdoing). It just happened that at some point when I was going back to work (first hour in the morning, or after lunch for example) I tried to log in again and then I got the warning.
So I have tried a third time, this time I have given all my real information, reluctantly uploaded a personal picture, given all my data to Facebook (yikes!).
And after a couple of days: damn, same result. Blocked account. Work lost. They prompt you to upload a picture to check your Id, but to no avail (no answer yet, not even a notice of any kind) and they don´t give you absolutely any reason why the have blocked you.
And if I go to https://facebook.com/help/contact/260749603972907 to fill the form where they ask you to upload an ID then it says that the email doesn´t belong to a disabled account!
What is the unusual activity they have detected? What have I done wrong? Has someone experienced the same problem? Has someone got any clue of what it is that I could be doing wrong?
Because I don´t want to go through the whole process once again only to get blocked in a couple of days.
Thanks.
EDIT 1:
Ok, after checking again now it recognizes the account as a disabled one. I have gone to https://facebook.com/help/contact/260749603972907 to fill the form and I have uploaded my ID (even though I completely disagree with disclosing that kind of information).
Honestly, I don´t know what it means by "shortly". It´s been two days now and I have not received any kind of notification yet.
By the way, I haven´t received any kind of notification (mail, sms, anything) during any step of the process EVER. No one. Nothing. Not even an automatic email response. Plain absolute silence.
Honestly, if Facebook uses a security system like this, that lets hackers in while blocks legitimate users, creating false positives and making us lose many hours of work, without any reason or notification or explanation, then Facebook security is plain wrecked.
And I cannot do anything less than to strongly discourage any developer to use it if they can avoid it (what unfortunately I can´t).
EDIT 2:
After some days I regained access to my account again. Without any notification, I just tried again and now it worked (really good communication policy, Facebook, congratulations).
My App had disappeared, so I had to go through the whole process again. And after sending ONE message to the API, this again:
And once again the asked me to upload a picture of myself (I think they already have enough pictures of me to make an album).
This is just plain crazy.
good morning!
Since last week my website URL - www.musiconline.xpg.com.br - and others sites from www.xpg.com.br , is/are with the LIKE BUTTON blocked.
I need the solution for this problem Urgently, because I'm NOT a Spammer!!!
My Fan Page is with a problem too: http://www.facebook.com/musicasonline
I'm trying to talk with Facebook in Forum and Support, but I still have no answer until now.
Thanks a lot for all!
I finally got my URL back. Facebook blocked use of our URL for years, yes years. For some reason no one would include our website URL (a-fib.com) in any post, or even on our own FB page. They'd get an error message saying our site had been flagged as spammy. This had been going on for years! FB has zero customer service.
Here's what worked. After trying everything else over the course of three years, we finally resorted to writing a pleading letter on our letterhead, asking why would anyone block a non-profit trying to help heart patients? We sent it 'registered mail' to FB headquarters. (Advice I found among other ideas online from those with a similar problem.) It worked. Praise the lord!
Facebook does not care if you personally are a spammer or not – it just blocks the whole domain, in this case most likely xpg.com.br.
This is a risk you’re always taking when using a shared domain. To avoid it, the best way is to get your own domain – then it’s you and only you who’s responsible – whereas now, if one of the users on this domain does not behave, all other users of the same domain will get punished as well.
We have an application that issue search requests (FB Graph API) using an email address as the main query parameter, so basically we are searching users by email (e.g. /search?q=email#dot.com&type=user). Everything was working perfect until yesterday when suddenly we started to get 0 results from that request. We are not aware if something has changed on the way the search API works, or if without previous notice that feature is not supported anymore. Does anybody else has had the same issue, or has any info about it?
This was a bug (https://developers.facebook.com/bugs/292220680814266) and should now be resolved. Thanks.
This functionality was deprecated because of low utilization, and they have no current plans to re-enable it. Have a look
https://developers.facebook.com/x/bugs/453298034751100/
I looked thru Facebook's documentation and they don't have specified you can search by email address, only by name. https://developers.facebook.com/docs/reference/api/ (see the searching section).
Where did you find in their documentation you can search by email address? Can you send me a link?
I'm really thinking someone hacked into that feature and now Facebook considers it a security hole, and they plugged it.
Today I realized that FB Connect does not return the proxied_email field in about 4 out of 5 times. (I can reproduce this with a single users repeatedly, so this obviously does not have anything to do with privacy options or permissions)
It definitely worked fine last week ago.
I could not find any official info that this field is going to be removed or anything, so...
Does anybody else have this problem? Is there anything I am doing wrong that could be causing this behavior? Or is Facebook just having a bad day?
I did the following quick fix:
$personArray = $facebook->api_client->users_getInfo( $fb_config->user_id, "last_name, first_name, birthday, hometown_location, current_location, is_app_user, proxied_email" );
$email = $personArray[0]['proxied_email'];
if(empty($email)){
echo 'Proxied email was not retreived. Trying fql query...';
$facebookFQLResultXml = $facebook->api_client->fql_query("SELECT proxied_email FROM user WHERE uid=".$fb_config->user_id);
$email = $facebookFQLResultXml['proxied_email'];
}
I'm going to posit that it's just one of those Facebook days. There is supposed to be a big change this month that will change the way developers interact with users. Notifications will be removed, etc. Facebook is going to allow full access to a user's real email address (with the user's permission), and remove the proxied email system.
However, the official word is that the email proxy system should still be supported. According to http://wiki.developers.facebook.com/index.php/Roadmap_Email, users who have already granted proxy email permissions will continue to be available. However, it doesn't say anything about new users, so perhaps they have removed the email addresses for those that did not grant permission?
I noticed that they put the new privacy controls in place today, so it could be they made a change to the proxy at this time.
The same thing happened to me too. In the Facebook Connect JS API the proxied_email works about 80% of the time, but in the Facebook Developer Toolkit (for .NET) it barely works at all (which is strange cause I think they use the same facebook api under the hood).
This probably could have something to do with the somewhat failed privacy settings introduced the other day, as the whole proxy email functionality is related to facebook privacy (as zombat mentions above)? According to http://developers.facebook.com/live_status.php, the API seems to be under a fair amount of stress at the moment, cause it's acting a bit sluggish.
Do these things happen often? Where the facebook team either decide to just change the implementation overnight or where the service more or less nosedives?
It seems that the data returned by users_getInfo doesn't longer contains the proxied_email value
You can't circumvent the problem with FQL:
$aResult = $facebook->api_client->fql_query("SELECT proxied_email FROM user WHERE uid=$fbUid");
$sFbMail = $aResult[0]['proxied_email'];
I'm using the Facebook .NET Developer Toolkit and think it's just a bit buggy, which is why it didn't always work. In the end I also worked around the problem using FQL which worked really well (with a touch of XPath)