myEmailHabit.com Logo

IMAP - SSL/TLS - STARTTLS - SMTP - POP3 - 2FA Webmail Login

"A different approach to organization with option, anonymity and security."
 
yourAlias@myEmailHabit.com

Choose your email: anyname@

PRIVATE - FUN - SECURE

 

"Banned? Restricted? Promo or Trial benefits? Change? Big Tech Censorship?


14-Day FREE TRIAL
Email Plans
Domain Options
Alias@DomainOption.com
Temporary Password

 

All tracks and footprints erased everyday with a secure-server maintenance rotation program, new security certificates and new I.P. routes without any interruption to you the user!!

Backend manual rotation of IP addresses, maintaining optimal routing anonymity.

Restrictive SPF, DKIM, and DMARC records to prevent email spoofing.

Instructions will be emailed after the FREE trial setup. Then $3.99/month following until you cancel.

   
SSL.com

Webmail

 

If you're relatively new to using email, or new to having your own domain and web hosting, you might have only had a Microsoft Outlook (Hotmail), Yahoo, Gmail of some other free email service previously. These accounts are easily accessible and are designed to be reached anywhere in the world by only using a web browser. Similarly, you can reach your domain's email service by using a web browser through the use of Webmail.

 

SSL, TLS, and STARTTLS

 

This is an informational page about the history of SSL, TLS, and STARTTLS and the differences between these protocols. If you are looking for information on setting up your email client, please go here.

There's often quite a bit of confusion around the different terms SSL, TLS, and STARTTLS.

SSL and TLS are the standard technology to encrypt connections between two computers. This prevents any third parties from spying on these communications.

TLS is the successor to SSL. It is supported by all modern and secure systems that handle internet traffic, including Fastmail. The terms SSL and TLS are often switched and used interchangeably.

STARTTLS is different to SSL and TLS. Before encryption was standard, many connections between an email client and the server were done insecurely. This put personal information in danger of being stolen. STARTTLS helped to reduce this risk by taking an existing insecure connection and upgrading it to a secure connection that used SSL/TLS. STARTTLS works with either SSL or TLS.

 

SSL/TLS version numbers

 

The version numbers of SSL and TLS in order from oldest to newest is:

SSL v2

SSL v3

TLS v1.0

TLS v1.1

TLS v1.2

TLS v1.3

When a connection is made to a port that has SSL or TLS, or when an insecure connection is upgraded to secure by STARTTLS, both sides of the connection will agree on a particular version depending on what is supported. This might mean that if the server supports the newest TLS v1.3, but the email client connecting to the server only supports TLS v1.1, both sides might use TLS v1.1.

While almost all online services support SSL/TLS today, not all services support the newest TLS v1.3. SSL has been officially deprecated (as of May 2018) and is no longer in use by modern online services. Current software supports TLS v1.0, TLS v1.1, and TLS v1.2, and many sites and services now strongly recommend at least TLS v1.2 for its overall improved security profile.

 

TLS vs STARTTLS naming problem

 

One cause of confusion around the names of these different technologies is that some email software incorrectly uses the term TLS when they should have used STARTTLS.

Older versions of Thunderbird in particular used "TLS" to mean that STARTTLS should be used to upgrade the connection, and the connection should fail if STARTTLS is not supported.

These versions also used the term "TLS, if available". "TLS, if available" meant that the program would try to use STARTTLS to upgrade the connection if the server supported this, but otherwise use an insecure connection.

 

A history of email authentication

 

To understand SSL/TLS and STARTTLS, it's necessary to understand the history behind these standards and how the industry has evolved to deal with existing user and client behaviors and new threats. SSL/TLS and STARTTLS had not been invented yet when IMAP, POP, and SMTP were already well established. Adding proper encryption to these without breaking existing behaviour was a significant challenge.

 

SSL/TLS vs plaintext/STARTTLS port numbers

 

Depending on the type of connection and what encryption is supported, different port numbers might be needed.

 

Since email technology like IMAP, POP, and SMTP were already around when SSL/TLS was invented, plain text connections were expected across the standard ports of 143, 110, and 25. While many services supported using STARTTLS to upgrade the connection on these ports, if a client did not also support this, there was a risk of sensitive information like passwords being transmitted in plain text. This put passwords at significant risk of being stolen if an attacker were watching the connection.

To add security, three new ports were decided upon. These ports expected SSL/TLS connections immediately, so they refused any attempt to transmit any information in plain text. This safeguarded sensitive information like passwords and email addresses - either the information would be transferred securely, or it would not be transferred at all. This is referred to as "implicit TLS", meaning it is expected that both sides of a connection will support encrypted connections.

Plain Protocol with implicit TLS

IMAP Port 143 Port 993

POP Port 110 Port 995

SMTP Port 25 Port 465

The problem with multiple port numbers

Some time after these new ports to support implicit TLS were agreed upon, it was decided that having two ports for every protocol was wasteful. In order to support only a single port, STARTTLS was created as a way for a client to connect over plain text, and then upgrade the connection to a secure one that used SSL/TLS.

This was also not a perfect solution. There were already real users who were using the new port numbers with their email clients. Email clients can be very long lived, so disabling the new ports was not a user friendly option.

There were also security concerns with using the single port and upgrading the connection. Even though mechanisms were added to each protocol to tell clients that the connection supported upgrading to a secure connection and they should not attempt logging in until the upgrade was complete, some client software ignored this and sent passwords and usernames over plain text anyway. Even if the server rejected the connection, the login details had already been sent unencrypted anyway, which left them vulnerable.

Other software ignored the server instruction to upgrade the connection, and just sent the user a login error in return. This caused a lot of confusion about what was wrong.

Since both of these issues caused significant problems for existing clients, most services continued to use plain text connections on one port number, and offer secure, implicit SSL/TLS connections on a second port number.

Today, many email services, including Fastmail, now disable plain text IMAP and POP logins entirely on ports 143 and 110, leaving encrypted connections on ports 993 and 995 as the only option. This makes sure all clients use encrypted SSL/TLS connections to protect sensitive data.

 

SMTP STARTTLS as an exception

 

There is one exception to this debate around using SSL/TLS and using STARTTLS: SMTP.

SMTP was originally designed for message transfer. Message transfer through SMTP occurs between different servers that are not designed for direct client interaction. For this reason it was not necessary in the early design to account for the problems with mail clients like transmitting user password information in cleartext.

It was only later that SMTP began to be used for message submission as well as message transfer. In the early days of email clients set up to send using SMTP, these used port 25, the same port that was used inside mail systems themselves for transfer. In larger mail transfer systems, it was possible to lock down port 25 so it could only be used by trusted IP addresses. Of course, it was not possible to do this for the many thousands of home IP addresses using SMTP on their email clients for email submission, and so port 587 was defined for message submission.

Using port 587 instead of 25 for message submission became popular at around the same time that the importance of using encryption to protect sensitive data became well known and encryption extensions were being defined for SMTP. Port 587, defined specifically for message submission, supported upgrading to a secure connection with STARTTLS.

Port 465 was also defined for SMTP submission, and unlike port 587, 465 specifically supported implicit TLS just like port 993 for IMAP and 995 for POP. At this time, however, the industry had moved on to the expectation that all connections for IMAP, POP, and SMTP would be upgraded securely using STARTTLS instead of the preferred implicit TLS today. For this reason, shortly after port 465 was defined, it was revoked. All clients were expected to move over to use STARTTLS on port 587.

Mail client software can be very long lived, and it can be challenging for most users to make changes to ports and server settings themselves. Many email clients were also designed in this time to only work with implicit SSL/TLS on port 465. This made it very difficult to remove port 465 as an option for customers, even though it was officially revoked.

Services supporting SMTP for message submission now require that clients connecting on the standard port 587 upgrade the connection using STARTTLS, and sign in with a username and password.

In 2018, the official recommendation changed again to using implicit TLS over port 465. Because of the long-lived nature of email client software, it is expected to be a very long time before port 587 can be discontinued.

Because services have now moved users away from using port 25 for email submission, they have now been able to block this port for users and use it internally only for its original intended purpose of email transmission. Port 25 had been a significant source of spam due to users' computers being infected with spam sending viruses, so this has greatly reduced the amount of spam sent through services that have blocked this port.

Currently, there is an even spread of users using implicit SSL/TLS with port 465 and users upgrading their connection with STARTTLS using port 587. Fastmail will continue to offer both options for the foreseeable future.

 

POP3 and IMAP

 

In the days before Webmail was widespread, there was POP3 and IMAP.

POP3 stands for Post Office Protocol.
IMAP stands for Internet Mail Access Protocol.

If you use an email client program such as Microsoft Outlook, Mozilla Thunderbird or Apple Mail. app, then you use POP3 or IMAP. 

 

POP3

 

When you use POP3 your email client accesses the mail server and sends your username and password. Then, it checks to see if there are new messages on the server and starts downloading them to your email client. In most cases your email client deletes the email off the server after downloading them so you don't keep old mail from taking up unnecessary space on the server. Sometimes, however, your client will leave the email on the server so you can access it from another email client on another computer or view it from Webmail.

 

IMAP

 

Using IMAP is a little different. You still use an email client, but instead of downloading the email from the server like POP3 the email client reads the email directly off the server and displays it in your client. You can then delete it or leave it there for the next time you are checking email. 

To set up your email client for POP3 or IMAP using A Small Orange's servers, configure your email client's settings to something similar to:

Mail server: mail.example.com
Username: yourname@example.com
Password: password
Protocol: POP3 or IMAP, depending on which one you want to use

 

SMTP

 

SMTP is short for Simple Mail Transfer Protocol, and is a method for sending mail from one computer to another.

 
Example
 

A little story about Bob...

You want to send an email to your friend Bob, who has an account at otherdomain.com. You already know that Bob's email address is bob@otherdomain.com, so you send him a message from your email client (or using Webmail) and address it to bob@otherdomain.com. Your computer connects to the SMTP server and tells it to send the email to bob@otherdomain.com. The SMTP server looks at the address and says, "I don't know who Bob is, but I think I can get this over to otherdomain.com."

The SMTP server then performs a series of steps to find out how to get the email to otherdomain.com. Then it connects to the other SMTP server who is responsible for all mail for otherdomain.com. When your SMTP server talks to the otherdomain.com's SMTP server they exchange a series of messages and ultimately the otherdomain.com says "Sure, I'll take the message to Bob" OR it will say "No, there's noBob here and we are going to return it back to the sender."

To set up your email client for SMTP using A Small Orange's servers, configure your email client's to something similar to:

SMTP Server: mail.example.com
SMTP Server Requires Authentication
Username: yourname@example.com
Password: password
Protocol: POP3 or IMAP, depending on which one you want to use

When you use an anonymity service.. Algorithms hone in on similarities for identification. Example: Your "username" on that service.. and you use that username for several of your services tracing back to a specific device, browser, even vpn signatures (specific keys based off of log in info). Well the algo knows in probability with the various account similarities that its the (same) or only (this) person has access to.

 

Back-end routing is one of those identifiers. So using the same "Over time, your server actions on all servers become public knowledge becomes use less in the case of account anonymity. We change servers, routing and encryption methods every 72hrs or so depending on dns crawl wait times. DNS, The IP behind the @server.com as well as the use of various CA's (Certificate Authorities) such as SSL.com's certificate will re-route to Setigo.com etc. Either way.. "you don't take the same bus to work / school with us." sometimes its not a bus ;-).

 

Downtime may total 1Hr a month which is not noticeable. There are no monthly configurations, we take care of it all. If you choose domain not in our control we will give you dns mail setting for our services. Please reach out to us if you have any comments, questions or concerns.