In addition to the IANA reserved list, don't forget ICANN controversially reserved .corp, .home and .mail.
https://www.theregister.com/2018/02/12/icann_corp_home_mail_... https://www.icann.org/en/system/files/files/sac-062-en.pdf
foo@bar.com
191–200 of 301 posts
Re: foo@bar.com
#192Earlier quoted context omitted.
One of the problems we had at my last company were invalid emails. We had so many users enter gnail.com or hptmail.com
I use this library for web pages that ask for an email: https://github.com/mailcheck/mailcheck It's a bit old and requires jquery, but it's fairly easy to gut the library and just use the email logic. It even uses your example of "gnail.com" in the README.
Sweet! I'm no longer working on that project but if I ever need user email input, I'll remember this (someone must have ported it to react I'm sure)
Re: foo@bar.com
#193Earlier quoted context omitted.
A lot of people learned this the hard way when Google bought and later enabled permanent HSTS for the .dev domain (prior to actually publicly releasing it) in Chrome, breaking everybody's non https local .dev environments. As mentioned above, it should have been .test
Can't wait for .internal to be registered so that my internal DNS breaks.
Once upon a time plenty of people thought it'd be cool to give their "internal" stuff names like wwwtest.int and database.int and so on.
Now, there has actually been an int TLD for a long time, but you probably don't visit sites in that TLD very often because it is for international organisations like the UN.
So if your configuration blocks all those actual sites well, too bad right?
However, back that long ago the trusted Public CAs were not actually forbidden from issuing certificates for names that don't belong to anybody on the public Internet. This was a bad idea, but it was not yet (at that time) forbidden. So you could pay Thawte a pile of money and get a certificate for "exchange2" your backup MS Exchange server or maybe "linux.build" your Linux build server.
And since people were using this for internal names, you'd get people asking their CA for certificates like "exchange2.int" - for the internal backups MS Exchange server right?
Obviously there can't be any effective way to demonstrate control over internal names, since you do not in fact have control over them, you've just hijacked them.
And so the end result is that there were actual publicly trusted CAs issuing certificates for names in a real public TLD without checks, because they assumed it was internal when it was actually not.
These days the CAs are required to issue only for names in the actual Internet DNS hierarchy (plus TOR) and only after seeing one of the accepted proofs of control nicknamed the Ten Blessed Methods.
Meanwhile: There is only one namespace, do not try to hijack little pieces for yourself that don't belong to you. If you want to reserve some names so that your DNS doesn't "break" then you can buy names like anybody else.
Re: foo@bar.com
#194daftar judi bola
https://judimedan.com/daftar-judi-bola-terpercaya-online24ja...
Re: foo@bar.com
#195Earlier quoted context omitted.
Note that `foo@bar.com` is frequently used to get around the email address requirement, so it is not really for testing. I wouldn't be surprised if prominent websites block any address from example.com or so.
I usually use president@whitehouse.gov and the like...
I would steer well clear of .gov and .mil when providing fake anything.
Impersonating federal agents is shockingly illegal and the authorities who enforce this have absolutely no sense of humor.
The risk is low but why take it?
Re: foo@bar.com
#196This guy is really committed to the joke, seeing as how he could easily sell bar.com for millions of dollars. Note also that there is a .bar gTLD, and there is a foo.bar domain as of 2014 (though it doesn't seem to be hosting any content). I run the .foo gTLD, and bar.foo is a real domain (though admittedly not as good as foo.bar). There is no .baz; next round maybe?
The domain is for sale for the right price: https://www.haven2.com/index.php/domains Seems the asking price is at least 1m USD
In fact, he quite recently sold corp.com for a healthy sum: https://krebsonsecurity.com/2020/04/microsoft-buys-corp-com-...
Re: foo@bar.com
#197Earlier quoted context omitted.
I use this library for web pages that ask for an email: https://github.com/mailcheck/mailcheck It's a bit old and requires jquery, but it's fairly easy to gut the library and just use the email logic. It even uses your example of "gnail.com" in the README.
Sweet! I'm no longer working on that project but if I ever need user email input, I'll remember this (someone must have ported it to react I'm sure)
Of course, you're right: https://github.com/eligolding/react-mailcheck#readme
Re: foo@bar.com
#198Earlier quoted context omitted.
contoso.com does have MX records. $ dig +short -t mx contoso.com 10 contoso-com.mail.protection.outlook.com.
You don't need MX records, email will go to the A record if no MX is defined. Presuming its listening for email of course.
It's actually interesting how we didn't go there for the web, although it is likely that we will in the next decade or so.
By the time Tim built his toy hypermedia system ("the World Wide Web"), DNS had a sensible mechanism which could have been used to deploy it cleanly. But that wasn't done. So, first HTTP means "just look up the A record for the name and connect on TCP port 80" and then HTTPS meant "look up the A record, connect TCP 443". Today you also need to check AAAA (for IPv6) and you need to use ALPN to say what kind of HTTPS you speak, but otherwise things remain much the same.
However we have a pile of things we want to do in the near future that don't fit this model very well. HTTP/3 support (ie HTTP over QUIC) would ideally be discovered as early as possible for best performance, and Encrypted Client Hello (technology to a void revealing the names of sites you're visiting to an eavesdropper) really wants to fetch from DNS quite a lot of information too.
So there will likely be a new DNS record for basically "I want to connect over HTTPS to this DNS name" the same way the MX record means "I want to send email to this DNS name".
Ordinarily this would be a huge deployment nightmare, because we know crap DNS implementations can't do new DNS features. The specification for DNS is clear that if somebody asks "What's the WONKABAR for some.name you control?" and you've got no idea what a WONKABAR is you say there isn't one. But lots of bad software has been written that will break out, and either crash, silently drop the question or reply by reporting that there was a server error, none of which is correct.
However, fortunately the DNS privacy protocols give us a chance to reset expectations. Comcast's deal to get their DoH servers used in Chrome (for Comcast customers obviously) requires that they implement DNS properly, not half-arse it. So that's millions of customers brought on board by contractual obligation just for one example.
Re: foo@bar.com
#199I own a curse word (Swedish) domain and I get quite a lot of similar emails. Nowhere close to thousands per day though. Still the level where I can answer the emails with a bad joke.
Re: foo@bar.com
#200Earlier quoted context omitted.
This is the real answer here. It's widely believed that domains working the opposite way of filesystem hierarchies and even URL paths was a huge design mistake. Think of how many billions of dollars have been lost over the years from account compromises resulting from people not correctly distinguishing yourbank.com/account/foobar from yourbank.com-account.info/foobar.
1. The reason for the change is generally thought to be email: you read least specific to most specific from left to right, like non-American dates, e.g firstname.lastname@group.department.university.edu 2. also I think ! was used rather than . for some networks at some times. Certainly I’ve heard this anecdote from some early users of the internet (or maybe other computer networks) 3. Traditionally the dot is the ze…
Interesting, and makes sense, seeing as how the Web didn't yet exist when domain names were first invented, but email did. It does make sense that they were thus represented in a manner catering to that use case. In hindsight I guess we'd prefer if emails were backwards too, e.g. com.gmail@cydeweys