Looking to setup your email on your Android phone? This tutorial will walk you through the process.
First thing, if you haven’t already, download K-9 Mail from the Google Play Store.
1) Once K-9 Mail installs, use the icon to open it up, and you should see a screen that looks like this, on which you can select “Next”.
2) On the next screen, enter your full email address and password, and select “Next”.
3) Select “IMAP”.
4) The settings on this screen should fill in automatically, but if they don’t, fill in:
Then select “Next”.
4a) If presented with this screen, select “Accept Key”.
5) The settings on this screen should fill in automatically, but if they don’t, fill in:
Then select “Next”.
5a) If presented with this screen, select “Accept Key”.
6) The settings on the following screen should all be correct, unless you tend to have a lot of email. If that’s the case, you can change the “Number of messages to display” to a higher number.
7) Finally, retype your email address in the first field, and your name in the second field. Note: The name you type in the second field will be used on emails you send.
In the world of the Internet, computers don’t really have names. They have IP addresses, like 184.108.40.206 or 2001:4860:4860::8888. The problem with that is, people have a hard time remembering numbers, but we’re really good at remembering names. The solution is the Domain Name System, or DNS. DNS takes a domain name, like 10twebdesign.com, and resolves (translates) it to an IP address, such as 220.127.116.11.
So, what really happens when you type 10twebdesign.com into your web browser and press enter?
First things first, your web browser might already know where 10twebdesign.com is located, because you may have visited it recently. If you have, your browser will cache (remember) the information for a certain period of time, so it doesn’t have to keep looking it up if you visit several different pages in a row. But the first time you visit a 10twebdesign.com page, your web browser has no idea where 10twebdesign.com is, so it starts the processes of trying to find out.
So your web browser tells your operating system, “I need to know where 10twebdesign.com is.” It’s possible that your OS already knows, and will just tell your browser, but chances are, it doesn’t know either. What it does know is the address of a preferred DNS server, which is usually owned by your Internet service provider and assigned automatically. So, your operating system heads out to your DNS server to find out where 10twebdesign.com is located.
Your DNS server handles requests from basically everyone in your area that all use the same Internet Service Provider that you do, so it’s much more likely that they might already know where 10twebdesign.com is, and can answer straightaway. Still, it’s more likely that no one has looked it up recently enough, and the DNS server needs to find out, too.
Your DNS server will now start working backwards; it needs to find out who manages the ‘.com’ domain names. Chances are, it already knows the answer to that, because someone else has recently looked up some other .com domain name, and it would have cached the information, but for the sake of this article, let’s say it doesn’t know and needs to find out.
Your DNS server now resorts to asking a root name server, of which there are only 13 in the world. These servers, named with the letters A – M, are located all over the world and are owned by many different organizations, including NASA, the University of Maryland, and the U.S. Army Research Lab, just to name a couple. Everybody knows where these 13 root servers are, so they can always fall back on them when everything else fails. Your DNS server tells one of the roots, “Hey, I need to know who manages .com addresses,” and the root server responds, “It’s Verisign.”
You DNS server now caches the information from the Verisign server, so that next time someone looks up a .com domain name, your DNS server won’t need to bother the root servers; after all, they are pretty busy, and it would make more sense to just remember and go directly there. It then heads over and asks the Verisign server, “Can you tell me who knows where 10twebdesign.com is?” The Verisign server responds with “They are registered through this domain registrar.”
So, your DNS server now heads over to the domain registrar, and says, “I need to know the name servers (NS) of 10twebdesign.com.” The registrar responds with one of two or more servers that know where 10twebdesign.com is actually located.
At last, we know who to ask. Your DNS server now makes direct contact with one of 10twebdesign.com’s NS servers, and asks, “Where is 10twebdesign.com located?” Our NS server replies, “It is located at 18.104.22.168, and it has a TTL of 14,400 seconds.” Your DNS server takes this information, and caches it so that the next time someone looks up 10twebdesign.com, it can just tell it the answer of 22.214.171.124, and save a whole bunch of work.
The only issue with this is that it’s possible that 10twebdesign.com might move at some time in the future. That’s where the TTL, or Time To Live, comes in. So, for the next 14,400 seconds, or four hours, you can find 10twebdesign.com at 126.96.36.199. After that, it might change. So, when your DNS server caches the information for 10twebdesign.com, it sets it to expire after the number of seconds specified in the TTL; once it expires in your DNS server’s cache, it will have to look up the information again.
Last, but not least, your DNS server returns the address of 10twebdesign.com to your operating system (that caches the information for the same length of time), and your OS passes the information along to your web browser (which also caches the information), so that it can look up the website hosted there.
The most amazing thing is that, if everything happens as quickly as it should, all of this happens in about a tenth of a second. Now that’s fast.