15 ms·

As a security person its hard as heck training (some of) our users to understand how basic domain formats work. We use a phishing simulation service, and outsid

As a security person its hard as heck training (some of) our users to understand how basic domain formats work. We use a phishing simulation service, and outside of certain content,putting part or all of our company name in the domain but adding other words/underscores/etc is what tricks a lot of people. I tend to explain how it works in a basic format, and often you can see the light bulb go off when I point out how a subdomain works and why an underscore or dash creates a whole new domain anybody can register while a subdomain is something our company can only create/use (mind you, I'm not going to confuse them by explaining how this can be abused, these people i talk to about this are having enough trouble grasping the basics).

capableweb 6y ago
As a human who had to describe the internet, computers and email addresses to some of our older population, I agree, stuff is really hard for newcomers. Most of them barely understand the mouse abstraction, so getting them to understand some of the finer details of the modern computing world is a exercise in humongous patience.
cmehdy 6y ago
This stuff is not really well made for normal people, to be honest. Just look at all the discussions and troubles (tickets, misunderstandings, security risks) related to email and hyperlink parsers.. It took me a while to know that FQDNs can (and sometimest must?) start at root with a period, meaning every address you've ever typed could have finished with a period (news.ycombinator.com.) and I recall some newspaper (NYT? News Yorker?) failing to test for that when people want to bypass their paywall. And this is a valid email address apparently: #!$%&’*+-/=?^_`{}|~@example.com RFCs/codified norms by tech people are just weird to normal people.
- ableal 6y ago
  Please stop downvoting this. If not an unpleasant truth, it's at least a widely held perception, which must have a reason. (And I suspect that reason is because it's true ...) > this is a valid email address apparently: #!$%&’*+-/=?^_`{}|~@example.com If so, that's actually the same as #!$%&’*@example.com (mail user 'foo+bar' is the same as 'foo'). Many webforms/DBs don't know that.
  - scubbo 6y ago
    > If so, that's actually the same as #!$%&’*@example.com (mail user 'foo+bar' is the same as 'foo'). Many webforms/DBs don't know that. Actually, no. To the best of my knowledge (and I'd be delighted to be corrected!), that's merely a convention that lots of providers (including GMail) conform to, but it's not part of the RFC or standards. Don't get me wrong - it irritates me when that very-common behaviour isn't supported (and, at the very least, `+` shouldn't be considered an illegal character). But it's also technically-not-wrong to consider `a+1@test.com` as different from `a@test.com`.
    - umanwizard 6y ago
      You are right. In fact, RFC 5321 specifically forbids you from interpreting the local part of an address in any way. > the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
      - scubbo 6y ago
        See your sibling comment for another perspective! (EDIT: which, to be clear, doesn't invalidate your point. Though it's worth considering, I guess, whether "only assigned semantics by the host specified in the domain" prevents user-tracking systems from calling "foo+bar@gmail.com" the same user as "foo@gmail.com". After all - if they're being interpreted "as" user IDs, rather than as emails, does that really breach the RFC?)
        deleted 6y ago
        [deleted]
        umanwizard 6y ago
        It's not really a different perspective. Sieve, which the sibling comment's RFC extends, is a mail-filtering script language for end-user inboxes. So it's perfectly reasonable for a user on foo.com, who knows that foo.com supports the `+` syntax, to write a Sieve script directing mail to "username+blah@foo.com" to a particular inbox. In fact, that RFC specifically calls out that interpreting the `+` on non-local addresses is likely wrong: > NOTE: Because the encoding of detailed addresses are site and/or implementation specific, using the subaddress extension on foreign addresses (such as the envelope "from" address or originator header fields) may lead to inconsistent or incorrect results. EDIT to address your second point: > After all - if they're being interpreted "as" user IDs, rather than as emails, does that really breach the RFC? Well, technically no, the RFC is about SMTP so if you're not writing an SMTP implementation, you're not breaching it. But RFCs aren't the law, so whether you're technically breaching it isn't really what's relevant. What _is_ relevant is that a system that treats foo+bar@quux.com the same as foo@quux.com is making assumptions about how email works that contradict the RFCs that define how email works. Whether that's a useful thing to do in practice is an engineering decision with tradeoffs. E.g., it's probably fine to assume it for a whitelisted set of domains where you know it to be true, like gmail.
- usmannk 6y ago
  > I recall some newspaper (NYT? News Yorker?) failing to test for that when people want to bypass their paywall. For a long time I could access Bloomberg for free because they failed open when you did this
- chaos_a 6y ago
  This root period was mentioned on reddit a while ago because the domain "youtube.com." would fail to serve ads. https://www.reddit.com/r/webdev/comments/gzr3cq/fyi_you_can_bypass_youtube_ads_by_adding_a_dot/ https://www.reddit.com/r/webdev/comments/gzr3cq/fyi_you_can_...
DavidAdams 6y ago
I registered .com domains with my kids' names when they were born, and when one of them discovered that they could get the email address gmail@hisname.com he was stoked. His friends don't understand how it's possible for that email address to work. As a practical joke, he always says "what do you mean? Doesn't gmail@yourname.com not work too?"
- tambeb 6y ago
  Somewhat similar to this... My full name is Tambe Barsbay, so I bought the domain mbebarsbay.com and have t@mbebarsbay.com as my email.

capableweb 6y ago

As a human who had to describe the internet, computers and email addresses to some of our older population, I agree, stuff is really hard for newcomers. Most of them barely understand the mouse abstraction, so getting them to understand some of the finer details of the modern computing world is a exercise in humongous patience.

cmehdy 6y ago

This stuff is not really well made for normal people, to be honest. Just look at all the discussions and troubles (tickets, misunderstandings, security risks) related to email and hyperlink parsers.. It took me a while to know that FQDNs can (and sometimest must?) start at root with a period, meaning every address you've ever typed could have finished with a period (news.ycombinator.com.) and I recall some newspaper (NYT? News Yorker?) failing to test for that when people want to bypass their paywall. And this is a valid email address apparently: #!$%&’*+-/=?^_`{}|~@example.com RFCs/codified norms by tech people are just weird to normal people.

ableal 6y ago
Please stop downvoting this. If not an unpleasant truth, it's at least a widely held perception, which must have a reason. (And I suspect that reason is because it's true ...) > this is a valid email address apparently: #!$%&’*+-/=?^_`{}|~@example.com If so, that's actually the same as #!$%&’*@example.com (mail user 'foo+bar' is the same as 'foo'). Many webforms/DBs don't know that.
- scubbo 6y ago
  > If so, that's actually the same as #!$%&’*@example.com (mail user 'foo+bar' is the same as 'foo'). Many webforms/DBs don't know that. Actually, no. To the best of my knowledge (and I'd be delighted to be corrected!), that's merely a convention that lots of providers (including GMail) conform to, but it's not part of the RFC or standards. Don't get me wrong - it irritates me when that very-common behaviour isn't supported (and, at the very least, `+` shouldn't be considered an illegal character). But it's also technically-not-wrong to consider `a+1@test.com` as different from `a@test.com`.
  - umanwizard 6y ago
    You are right. In fact, RFC 5321 specifically forbids you from interpreting the local part of an address in any way. > the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
    - scubbo 6y ago
      See your sibling comment for another perspective! (EDIT: which, to be clear, doesn't invalidate your point. Though it's worth considering, I guess, whether "only assigned semantics by the host specified in the domain" prevents user-tracking systems from calling "foo+bar@gmail.com" the same user as "foo@gmail.com". After all - if they're being interpreted "as" user IDs, rather than as emails, does that really breach the RFC?)
      - deleted 6y ago
        [deleted]
      - umanwizard 6y ago
        It's not really a different perspective. Sieve, which the sibling comment's RFC extends, is a mail-filtering script language for end-user inboxes. So it's perfectly reasonable for a user on foo.com, who knows that foo.com supports the `+` syntax, to write a Sieve script directing mail to "username+blah@foo.com" to a particular inbox. In fact, that RFC specifically calls out that interpreting the `+` on non-local addresses is likely wrong: > NOTE: Because the encoding of detailed addresses are site and/or implementation specific, using the subaddress extension on foreign addresses (such as the envelope "from" address or originator header fields) may lead to inconsistent or incorrect results. EDIT to address your second point: > After all - if they're being interpreted "as" user IDs, rather than as emails, does that really breach the RFC? Well, technically no, the RFC is about SMTP so if you're not writing an SMTP implementation, you're not breaching it. But RFCs aren't the law, so whether you're technically breaching it isn't really what's relevant. What _is_ relevant is that a system that treats foo+bar@quux.com the same as foo@quux.com is making assumptions about how email works that contradict the RFCs that define how email works. Whether that's a useful thing to do in practice is an engineering decision with tradeoffs. E.g., it's probably fine to assume it for a whitelisted set of domains where you know it to be true, like gmail.
usmannk 6y ago
> I recall some newspaper (NYT? News Yorker?) failing to test for that when people want to bypass their paywall. For a long time I could access Bloomberg for free because they failed open when you did this
chaos_a 6y ago
This root period was mentioned on reddit a while ago because the domain "youtube.com." would fail to serve ads. https://www.reddit.com/r/webdev/comments/gzr3cq/fyi_you_can_bypass_youtube_ads_by_adding_a_dot/ https://www.reddit.com/r/webdev/comments/gzr3cq/fyi_you_can_...

DavidAdams 6y ago

I registered .com domains with my kids' names when they were born, and when one of them discovered that they could get the email address gmail@hisname.com he was stoked. His friends don't understand how it's possible for that email address to work. As a practical joke, he always says "what do you mean? Doesn't gmail@yourname.com not work too?"

tambeb 6y ago
Somewhat similar to this... My full name is Tambe Barsbay, so I bought the domain mbebarsbay.com and have t@mbebarsbay.com as my email.