…which both excludes addresses allowed by the RFC and includes addresses disallowed by the RFC. (For example, the RFC disallows two consecutive dots in the local-part.)
I take the descriptivist approach to email validation, rather than the prescriptivist.
I know an email has to have a domain name after the @ so I know where to send it.
I also know it has to have something before the @ so the domain’s email server knows how to handle it.
But do I care if the email server is supports sub addresses, characters outside of the commonly supported range (eg quotation marks and spaces), or even characters which aren’t part of the RFC? I do not.
If the user gives me that email, I’ll trust them. Worst case they won’t receive the verification email and will need to double check it. But it’s a lot better than those websites who try to tell me my email is invalid because their regex is too picky.
The HTML email regex validation [1] is probably the best rule to use for validating an email address in most user applications. It prohibits IP address domain literals (which the emailcore people have basically said is of limited utility [2]), and quoted strings in the localpart. Its biggest fault is allowing multiple dots to appear next to each other, which is a lot of faff to put in a regex when you already have to individually spell out every special character in atext.
I generally agree, but the two consecutive dots (or leading/trailing dots) are an example that would very likely be a typo and that you wouldn’t particularly want to send. Similar for unbalanced quotes, angle brackets, and other grammar elements.
That would be bad form, IMO. The user may have typed john..kennedy@example.com by mistake instead of john.f.kennedy@example.com, and now you’ll be sending their email to john.kennedy@example.com. Similar for leading or trailing dots. You can’t just decide what a user probably meant, when they type in something invalid.
Yeah, that's about as far as I've ever been comfortable going in terms of validating email addresses too: some stuff followed by "@" followed by more stuff.
Though I guess adding a check for invalid dot patterns might be worthwhile.
Actually pretty good response if the programmer bothers to read all of it
I'd be more emphatic that you shouldn't rely on regexes to validate emails and that this should only be used as an "in the form validation" first step to warn of user input error, but the gist is there
> This regex is *practical for most applications* (??), striking a balance between complexity and adherence to the standard. It allows for basic validation but does not fully enforce the specifications of RFC 5322, which are much more intricate and challenging to implement in a single regex pattern.
^ ("challenging"? Didn't I see that emails validation requires at least a grammar and not just a regex?)
> For example, it doesn't account for quoted strings (which can include spaces) in the local part, nor does it fully validate all possible TLDs. Implementing a regex that fully complies with the RFC specifications is impractical due to their complexity and the flexibility allowed in the specifications.
> For applications requiring strict compliance, it's often recommended to use a library or built-in function for email validation provided by the programming language or framework you're using, as these are more likely to handle the nuances and edge cases correctly. Additionally, the ultimate test of an email address's validity is sending a confirmation email to it.
Support for IDN email addresses is still patchy at best. Many systems can’t send to them; many email hosts still can’t handle being configured for them.
Wow, that’s an incredibly lazy and short-sighted take from the GP then. The training set will definitely get updated at some point… or you could just ask Bing, or Bard
I've once used Selenium to run javascript in the webpage to steal a few dynamic tokens required by the sites API to reuse in my more well-trodden python-requests workflow.
The Shopping Reform and Modernization Act, or Scanner Law, requires that most items on store shelves be clearly displayed with the price; by signage, electronic reader, price sticker, or any other method that clearly and reasonably conveys the price to a consumer in the store at the place where the item is located. If an automatic checkout system (scanner) charges you more than the displayed price of an item, and:
the transaction has been completed, and
you have a receipt indicating the item purchased and the price charged for it;
Then:
You must notify the seller that you were overcharged, within 30 days of the transaction, either in person or in writing. Within two days of receiving your notice, the seller may choose to refund you the difference between the amount charged and the price displayed plus a "bonus" of ten times the difference, with a minimum of $1.00 and a maximum of $5.00. If the seller does not pay you both the refund and the bonus, you may bring a lawsuit to recover your actual damages or $250.00, whichever is greater, plus reasonable attorney fees up to $300.00. You may instead file a complaint in a small claims court without an attorney.
I think that page backs up what I thought, at least for Michigan. The law views the price displayed on the shelf as being the correct price, and if the POS system doesn't match then the law says the POS system is wrong. Also there's another interesting FAQ there which further reinforces it.
Now, if an e-ink display is changed by a hacker, that's obviously fraud and presumably the store wouldn't have to pay up, but I assume that would be tough to catch because the store wouldn't likely assume it had been hacked and even if they thought so they'd probably have to prove it somehow.
From the FAQ:
What if the wrong price is displayed for an item and the clerk catches it before I pay; am I entitled to buy the item at the displayed price?
This is a fact-specific question best answered by a court. A store may not knowingly charge or attempt to charge a price higher than the price displayed for that item. Therefore, the consumer may have a claim if the store will not sell the item at the price displayed. However, the consumer may face obstacles convincing a court that the store knowingly charged the higher price when the pricing mistake is not intentional and will result in an obvious windfall to the consumer.
1) you’re only entitled to damages if the store actually completed the sale and the item rang up higher than listed on the shelf
and
2) the store is not required to honor labeling mistakes and can’t be compelled into a sale in that situation
This is consistent with my experience. So I guess if you’re trying to cheat, you don't tell them and ask them to adjust the price, instead you complete the sale then notify them of the error afterward. My experience has mostly been with notifying the employee beforehand which causes them to correct the labeling mistake if one was made.
The legal reason isn't that they aren't allowed to, it is that it can only hurt them.
Why would a company highlight failures if they don't have to? Especially when their statements can later be used against them in civil or criminal proceedings.
I'm almost certain that FMLA, ADA, etc have provisions that require the employer to treat the information as confidential. Even things like contact tracing for covid keeps the person anonymous.
This is the company that released a video of a bunch of their rockets exploding, "How not to land an orbital rocket booster". They are usually pretty open with their failures, at least in engineering.
https://www.youtube.com/watch?v=bvim4rsNHkQ
I guess I didn't specify that "failure of an experimental rocket for a company developing new rockets" is a different category than "failure of workplace safety procedures that permanently disables a family man"
the difference is clear to be sure, just pointing out that at least in engineering, they have never been shy to publicize their failures, and use them to improve processes. I would hope that that attitude would apply equally to safety, but it seems like it does not.
