I've noticed that there are a lot of users that misspell their email addresses when registering. For example, if the email is example#gmail.com, the user may write example#gmail.con. In a registering process, this may lead to the user registering wrong without him/her being aware of.
Is it a good idea to implement a function that changes .con for .com? This would be a problem if .con email addresses exist because they wouldn't be able to register. Do .con email addresses exist?
.con emails cannot exist (right now) because there is not a top-level domain (TLD) named .con
If you go to the Wikipedia page or tld-list.com, you'll see that there isn't a .con
.computer
.condos
.construction
.consulting
.contact
.contractors
.cooking
No .con to be found.
You should probably popup a warning instead of automatically fixing it, though, so that clients are conscious that they made a mistake.
As of today, there is no .con top-level domain (according to https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains#C ).
Is it a good idea? That's more of a Product question than a technical question :) Maybe just prevent the user from entering such an address using client-side validation instead of replacing it for them automatically?
Related
I have an app where a few administrators will need write access in the data. To authorize them I was thinking about having their email address in a list in the database, since they don't have a uid until they have logged in for the first time.
Will this be safe enough, or will I have to figure out another way?
Thank you in advance!
If you are concerned with any security risks, the approach you are describing would actually be safe as it would minimize the chance that there is a bot or some other entity which may corrupt your data.
Additionally, you can always test your Firestore rules as mentioned over here so that you are happy with the security you are enforcing.
Hope you find this useful!
I think that is no big point if the email could be verified, means to make sure that it come from the actual email owner.
And will be better if it been encoded with appropriate encryption before saved into the database.
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).
I'm using rails 2 for this app, with ActionMailer, but this is a general question about emails.
When we send out emails, i save a record corresponding to the email in a database table. I'd like to keep track of whether people have read the emails, and am wondering the best way to do it. On initial googling, it seems like i've stumbled into an ongoing battle between spammers and email clients!
My first thought was to use the "read receipt" header, but i know that this isn't supported by a lot of clients and is therefore unreliable. After that, i read of the tactic of including an image in the mail, and of detecting that image being loaded. I was thinking that i could put a parameter with the email record's id in the image url, so that when i get a request for that image i can see if it has a (for example) email_id param and if so, mark the corresponding email as having been read.
But, then i remembered that many clients are wise to this tactic and specifically ask the viewer of the mail if they want to display images. Obviously they might say no.
Am i right in thinking that i can't pull in other resources, such as stylesheets, in my mail? Because if i can pull them in, i could do that same trick but with the stylesheet rather than an image.
Grateful for any advice, max
Externally-hosted stylesheets are generally treated the same way as images. The client will not download them without prompting the user, if that works at all with HTML-formatted emails.
One thing to consider- you're looking to determine whether the email was read, not necessarily just received, right? Format your email so that it can't be easily read without viewing the images, and include a "view in browser" link at the top. Track image and page-format views and I think you'll have a fairly reliable way to measure actual reads.
Bit late on this, but we've got a similar problem.
We're tracking the links to our site that are included within the email. We're doing this by, like you, having a DB record per email sent out. We've generated a unique hash key per email and are including that as a parameter on all the links included in the email.
We simply then have a before_filter that looks for the parameter and records the fact against the correct email record by using the unique hash to identify the correct one.
We use a unique hash key (rather than the DB's primary key) just so it is a little bit more secure / reliable.
Obviously this method only helps us track the clicks our emails have generated (and not if they've been read) but it is still useful as we can see which of ours users has clicked on which links.
We are having major problems with this as well.
We have task wek portal, where users create tasks (like paint my house) and then we invite painters to give the task creator an price on painting his house.
For that we had a very advanced email system, that sends an invitation and if they accept the invitation we send them the contact info of the task creator.
We need to be able to track if the email was opened, and then once it's opened, we know that the company got the contact info, and we can now send another email to the task creator, telling them that they can expect to be contacted by that company.
The problem is that tracking if the email was opened is not reliable at all. There are different systems for this like msgtag (which does not support a wide range of mail clients like yahoo and other major clients) and our email API client (elastic email) even offer some API call back functions to tell us if each email was opened or bounced or whatever. But again, it's not reliable. To track if it's open, elastic email just includes a 1x1 px image and track if it's opened. So if people don't click "show images in this email" it's not tracked as opened.
So basically we are down to two options.
Have vital portions of the content printed on images, that they have to view to get the info we want to track if they got (in this case contact info)
Just have a link in the email "click here to get the contact info" and then track if that is clicked.
So in conclusion, the "track if opened" is totally useless and unreliable, unless you can fully control which email clients your recipients are using and how they are using them (like if they are all your employees or something).
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm creating a web app that requires registration/authentication, and I'm considering using an email address as the sole user id. Here are what I see as the pros and cons (updated with responses):
PROS
One less field to fill out during registration (it would just be email address, password, and verify password). I'm a big fan of minimalistic registration.
An email address is easier to remember. (thanks Mitch, Jeremy)
You don't have to worry about your favorite username being taken already - you're the only one who uses your email address. (thanks TStamper)
CONS
User has more to type every time they log in.
What if a user wants multiple accounts? They'll need another email address. (Do I even want a user to be able to create multiple accounts?)
Easy for a potential attacker to guess (if they know the target's email address, they know the login id). (thanks Vasil)
Users may be tempted to use the same password they use for their email account, which is bad security. (thanks Thomas)
If you change email addresses frequently, it may be difficult to remember which address you used to sign up for a site after a long hiatus. (thanks Software Monkey)
A hacker could spam the registration form and use "email already taken" responses to generate a list of valid emails. (thanks David)
Not everyone has an email address. (thanks Nicholas)
If I went with email as id, I would provide a mechanism to allow it to be changed in the event a user changes address. In this case users would not be posting content to a public site, so a separate username won't be necessary to protect the email addresses (but it is something to consider for other sites).
Another option is to implement OpenID (which is a whole other debate).
This seems to work for Google, but their services are tightly integrated. What have I missed in my analysis? Do you have any recommendations? Does anyone have experiences to share?
FINAL EDIT
Thank you all for your responses. I have decided to use email as an id, but then allow the creation of a username for login purposes after registration. This allows a little flexibility while keeping registration as short as possible. It also prevents problems when a user changes email addresses (they can just log in with their username and update it). I will also be implementing methods to prevent brute-forcing of email addresses out of the registration and login systems (mainly a cool-down period after repeated attempts).
Personally, I prefer just using my email address as a username. It's one less thing to remember, and I never have to worry about my preferred name being already taken.
Just my 2 cents!
I think you missed a PRO:
Users are likely to remember their email address; and as email addresses are unique, they never have to worry about their preferred username being taken already.
As a user of websites, I can tell you that I hate memorizing unnecessary usernames. I don't use a unique handle or anything so I can never remember which variation of my name I used that wasn't already taken. I'd much rather type my email address.
Also, I like OpenID.
CONS
When the same password is used for the e-mail account, compromising the one automatically means compromising the other.
CON: Not everyone has an e-mail address. Consider if your database is ever accessed by an internal application. If you are running a store, people will call up and place an order by phone and refuse to provide an e-mail address. So while having an e-mail address as the default user ID is cool, be sure to allow alternates to get into the system. (Of course, this depends on the context.)
Learned this one the hard way.
I tend to not prefer pro/con lists, and instead try to think of benefits and challenges.
Challenge:
Some users will be tempted to use their email address from their ISP. Linking to an email alone, may be difficult for the users who forget to update their email in all the web sites they have signed up for before they change ISPs.
Instead:
You should consider allowing a user to provide multiple addresses, as well user-selected id and then let the user decide what they want they wish to do. Perhaps also consider allowing the user to provide an OpenID account.
CON: If I change my email address, suddenly all my account names are invalid. My name doesn't change, but my email often does. I have occasionally revisited a site after a number of years, and been stuck... what was my email address two years ago???
One setup you may want to consider: Have both a username and an email. The email is used to login and is always kept private, the username is used to identify the user in any public interaction, such as posting a comment. It winds up being slightly more secure as both halves of the user login credentials are kept private, whereas if you use a username for both login and public identification, half of the login is already known.
I definitely agree with you about having minimal registration for most cases, but depending on what you're doing you may want to balance that against added security for your users. Four fields isn't outrageous for registration, (username, email, password, confirm password), and if you're feeling particularly adventurous, you could cut it down to three by dropping the confirm password field, or two by emailing them a password that they can change later.
PRO
People hate having to create a unique name that fits their id and that has not already been taken to register for a site..So this is why the user id as EMAIL ADDRESS is so embraced.
ex:TStamper1930, who actually wants to remember 1930 at the end of my name that I really wanted
CON: If a hacker can try registering random email addresses en masse, he or she will be able to figure out which of those addresses are valid based on which registrations fail. This is a tactic that can be used to put together lists of known valid email addresses, which are a hot commodity on the spam black market.
Although now that I think about it, that's a problem that affects any website which asks for an email address as part of the registration process, regardless of whether or not there's a separate username. But it's still something to think about.
Stick to email addresses they are used everywhere, actually most of the major websites use them, they are unique so they save the user from struggling to find a name that's not used by others, also users won't forget their email addresses (in most cases at least :)), which is unlike usernames that they will keep on forgetting if they don't visit your site very often.
You shouldn't be worried about them being too long as all the major browsers (IE, FF .. etc) offer autocomplete to forms which is enabled by default, so you type the first letters in your email and you get a drop down list (ie. autocomplete list) where you just click to enter the whole email, personally I almost never type the email address in full, I always type the first letters then select the email from the autocomplete drop down list. Besides, if you allow users to be remembered (using a Remember Me checkbox and persistent cookies), it will be another reason to not worry about it.
I don't know about your app but usually users having multiple accounts is not desirable in most apps.
One con might be that if it's an email address the login can be guessed by people and brute force attacks attempted. Which is not really a big issue, since on most sites today the logins are publicly displayed.
The biggest pro is that logins are easier to remember this way.
A good setup is to require username and email. Allowing the user to login with either email address or username is very user friendly. An added benefit is the user can change their email address. It would also allow multiple accounts for one email.
To solve your con item of the email being too long to type in every time. I have implemented the StringScan Ruby library.
require 'strscan'
def signup!(user, &block)
self.email = user[:email] unless user[:email].blank?
str = StringScanner.new(self.email)
str.scan_until(/#/)
str.pre_match
self.login = str.pre_match
etc..
Then just change login method to allow either email or login to match password.
This works just like google or mobileme. A user can choose to just type in their email username (ie. username instead of username#gmail.com.)
I'm fighting with removing this right now. Here's a newer CON from the current era.
An email address is considered Personal Identifiable Information (PII) by many governments. Hence extra care needs to be taken any time you display it on a page, or even return it from an end-point.
Consider that many sites allow interactions between different users. This often means the site will provide a list of users to choose from (e.g. a drop-down list, or search results). This ca actually enable the leaking of PII by the site.
Usernames, on the other hand, can be completely anonymous. Given the prevalence today of password managers, users really don't need to actually remember their username and password.
If you don't care about forcing your users to login to your application with Facebook or some other social network (most people don't seem to care), then you can just use their social network email as their 'user id' when referencing other tables/documents (MySQL, Mongo, etc).
I've noticed the bonus to using social media logins is that all the security has been taken care of by said social network, including not allowing 2 users to have the same email or username in their database thus saving you the hassle of having to code for all of that. This is just my personal preference.