371–380 of 405 posts
TL;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.
And when they do, it's usually mine.
TL;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…
There are an amazing number of C. R. Conrad's in the world -- mostly the USA -- who seem to think they own that address.
Earlier quoted context omitted.
That one fails " "@example.com and test@example, both of which are legal. Also, since it relies on looking up MX records and then making an SMTP connection to check if the user exists, why not just send the confirmation email? You've already done all of the expensive stuff at that point.
You haven't had to bother the user yet. Also, shouldn't example.com fail?
Earlier quoted context omitted.
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.
"callable via text"? What does that even mean? The command line is an API, isn't it? If people don't manage to pass an ampersand to another program via the command line, that's really no different than people failing to pass an ampersand as a URI parameter to an HTTP resource: Failure to encode properly. There is absolutely nothing that prevents you from passing an ampersand (or any other characters) to a program via…
It means you have to execute commands through a shell. A real API would be something you could include in your program, execute a method against and get a list of objects back. Instead all these basic command are replicated in every framework.
As far as encoding properly, you're preaching to the choir, but out in the real world there is still injection attacks everywhere.
Earlier quoted context omitted.
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.
But even PHP has a way to escape shell arguments safely
Earlier quoted context omitted.
> > ...@(valid)example.org(honest) > Are those parens really permitted in the host name? I'm looking at RFC 3696. RFC5322 states that an addr-spec consists of a local-part, followed by @, followed by a domain. It states that a domain may be a domain-literal; a domain-literal may begin and end with commented folding whitespace (CFWS). It's all in https://tools.ietf.org/html/rfc5322#section-3.4.1 It's only the dtext po…
Thank you for that; this has been eyeopening. The possibility of having a valid email address where the second-level domain component can't actually be registered as a domain, to the best of my understanding, eg "bar!.com", is interesting.
It is! Conceivably, it could be used to implement a new kind of domain-less mail system, e.g. foo@$megamail or something.
Earlier quoted context omitted.
> If it doesn't, remind me to patch it to not accept that. You'd be wrong to do so. The whole point of RFCs and Standards is to take things out of the realm of personal preference. Also, I suspect that a validator which allowed reasonable addresses like jim(somesite)@foo.invalid (which is both a good use of comments and what the + hack emulates) or "Ted Smith"@bar.invalid or "work@home"@jobs.invalid or "William \"Bil…
There are already things that are technically allowed by RFCs for various types of input but should be disallowed because they cause problems. So something being in an RFC doesn't create any kind of binding requirement, and very often the things that get dropped are things that, on contact with the real world, turned out to be bad ideas. Many of the more arcane things that can technically be done in an email address…
That may be true, but it's something else entirely for someone to drop them because the problems they cause … were enabled by him. An email address using characters you don't like is perfectly valid, and perfectly deliverable, right up until you refuse to deliver it. It doesn't cause any problems until you decide to make it cause a problem.
> Many of the more arcane things that can technically be done in an email address seem to me to be in the "turned out to be bad ideas" bin, and I have no problem making them be de facto deprecated even if no RFC has yet caught up to that.
> Also, no halting-problem issues at all; my preferred approach would be to disallow certain class
I really don't see why you think it's a bad idea to disallow more than alphanumeric (and plus? and ampersand?) characters in the local-part. Cui malo?
Earlier quoted context omitted.
1. There are no "obviously invalid email address[es]". 2. Getting billed for sending emails? WTF?
With respect to (1), the cases I had in mind as "obviously invalid" is something that doesn't contain all of the required components of an email address. For example, if the user submits their email as "foo" or "foo@bar" or "foo@bar." I should have provided examples as the way I wrote it was definitely ambiguous.
That said, "foot@bar." may be valid, but ICANN says it should not be functional. They prohibit dotless domain names (that is, top-level domain names may not have A, AAA, or MX records).
Earlier quoted context omitted.
It is true that regular expressions in the CS sense can't parse context-free grammars. However, PCRE, which is what most programmers are talking about when they say "regex", can do so. So you're both kinda right, I guess. But you're being a bit pedantic.
> PCRE, which is what most programmers are talking about I wish that were the case. http://www.regular-expressions.info/refunicode.html (They used to have a much more useful and concise comparison table but I can't for the life of me find it.)
I guess what I really meant is that programmers are talking about PCRE in terms of power, not in terms of exact syntax. In particular, they have recursive patterns, which are sufficient to pull them up to context-free grammars.
Earlier quoted context omitted.
> Sure, the complete regex is complex, but it is defined and is hardly unconquerable. If it is a regular expression, then it is not able to match all valid email addresses, because the grammar of email addresses is context-free, and regular expressions can only match regular grammars. It doesn't matter if it is defined or not: if it's a true regular expression, then it simply cannot validate email addresses. (it may,…
It is true that regular expressions in the CS sense can't parse context-free grammars. However, PCRE, which is what most programmers are talking about when they say "regex", can do so. So you're both kinda right, I guess. But you're being a bit pedantic.