Earlier quoted context omitted.
Even Linux tools like GNOME Archive Manager in Linux Mint 18 rejected my RAR password containing a $ as the incorrect password, even though it was the correct password for the RAR file I was trying to extract. I then used the command-line unrar utility with the exact same password, and it extracted successfully. Now, why would you preemptively (and explicitly) throw out a candidate password string based on its charac…
I'm guessing both are because the are calling command line tools. One of my pet peeves with linux is that many of these tools are only callable via text and don't expose an API for other programs.
The Correct Way to Validate Email Addresses
261–270 of 405 posts
Re: The Correct Way to Validate Email Addresses
#262The one thing I systematically do in term of email validation is catch the common typos of the main providers. So things like gmail.con, hotmai.com, gmall.com and so on. In 99% of those cases, it prevents someone from entering a wrong email. We do not do email activation by forcing people to click a link in their email to validate that they received it since that causes a drop in the funnel and reduces the amount of…
Have you considered doing email validation without forcing users to comply? It's fairly common to require valid emails after X days, or in order to unlock N features. Gets the advantages of having valid emails without the disadvantages of a drop signups.
Re: The Correct Way to Validate Email Addresses
#263Earlier quoted context omitted.
> There is nothing particularly dangerous about receiving unsolicited signup emails or about sending emails to yourself. Depends on what you do with them, in the latter case. There could be an amplification attack there. Validating domain parts to a certain extent isn't a bad idea, at least as far as non-routable domain names and RFC1918 ranges go. I've seen this done (actually implemented some of it, in fact) at a p…
> Depends on what you do with them, in the latter case. There could be an amplification attack there. Hu? How would that work? > Validating domain parts to a certain extent isn't a bad idea, at least as far as non-routable domain names and RFC1918 ranges go. What do you mean by "non-routable domain names" and what do you gain by checking for RFC1918 ranges? > I've seen this done (actually implemented some of it, in f…
You would lose the bet. The product supported IPv6 from day one.
That is a robust, if somewhat complex, solution for a relatively small volume of mail. When you're sending ten million messages a day by the end of the first month, pushing everything into a single relay of any kind is asking for a lot of trouble.
Re: The Correct Way to Validate Email Addresses
#264Earlier quoted context omitted.
These days I do this differently; I created a subdomain that forwards all email to my main account. hackernews@foo.example.com would forward to main@example.com, and I can just filter the prefixes. That way I can use the subdomain for my own unique addresses, without interfering or using up addresses on the parent domain.
I do as well. Keeps a nice track of which have been leaked (or guessed) by spammers. And easy mail filtering to relevant labels on my side. But it does get awkward quite a few times when having to interact with a human (customer services, hotel bookings, etc) via email or phone when they get a bit confused why their company name is my email alias.... Spelling a long alias over the phone letter by letter is especially…
Re: The Correct Way to Validate Email Addresses
#265TL;DR the odds that the user entered an incorrect-but-valid address are way higher than that they entered one which will not actually be able to receive mail. Send a validation email.
For flip's sake, yes please! Close the loop, fer crying out loud. I got a popular givenname.familyname@gmail.com address and I frequently get mail that's meant for other people who share my name. The vast majority of the time it's the individual themselves who sign up for a service or offering but there's rarely a validation upfront. The best emails are the ones who extend full trust to the email recipient over some…
Well what else would you have them do? Have people enter their address and send letters there to do a password reset?
A confirmation email before full trust is going to do little: a malicious person would just click that link, right?
Re: The Correct Way to Validate Email Addresses
#266Earlier quoted context omitted.
> The one thing I systematically do in term of email validation is catch the common typos of the main providers. So things like gmail.con, hotmai.com, gmall.com and so on. That can be helpful, but I assume you suggest the user that they may have made a typo and not flat out reject the input? > […] having an email with a local domain name with no TLD is valid but it'll never be valid in the context […] Well, depending…
Our email provider flat out refuses to send to those domains actually so we actually reject the input for the domains that the email provider blocks. > I would not rule out someone actually using ceo@cocacola at some point Of course, this is subject to change if the practice changes. The aim is to make sure that we balance the percentage of emails that are correct versus the number of potential rejections. If 0.00001…
Re: The Correct Way to Validate Email Addresses
#267As an aside, I received an email from a government department recently that had an '&' character as part of the email address. I didn't think that was valid, but lo and behold, when I checked the specs, it IS indeed a valid character in an email address. Just goes to show that assumptions are often wrong, and you have to crack open the spec document from time to time... [1] [1] - https://tools.ietf.org/html/rfc2822
Re: The Correct Way to Validate Email Addresses
#268Earlier quoted context omitted.
Yes. OS X keyboard drives me nuts sometimes, Karabiner can only fix some bits of the weirdness.
option-e and then a vowel will create {á é í ó ú} option-u and then a vowel will create {ä ë ï ö ü ÿ} option-n and then an 'n' will create ñ Found this out while learning Spanish since holding down keys to select their alternate was way too slow.
option-n and then 'a' will create ã
option-n and then 'o' will create õ
Re: The Correct Way to Validate Email Addresses
#269Earlier quoted context omitted.
I had a .to domain for a while, and I had an email address "firstname@firstname.to" where firstname is my first name. I wanted to use it when I needed to give out emails causally, like if someone from Church or some other group wanted my email. I gave up on it, not because of computer validation but because of stupid people! Nobody would "get" the .to domain and they'd always think there should be a .com or .gmail.co…
I'm discovering the same problem with my *.xyz domain name.