Basic E-Mail Settings

[#embasset]:

Basic Settings Common For E-Mail

These are the pieces of information which an E-Mail provider will typically provide people so that they can know how to connect to the E-Mail server:

Common Basic Settings
  • The username to log in as
  • The password to log in as
  • The E-Mail server's name/address (often called the “Server Name” and/or the “Host Name” of the server)

Additionally, you'll typically need details for the settings described in at least one of the following sections. (Having both is commonly nice.)

E-Mail Protocol Basic Connection Settings
Typical Necessary Settings

The following information is needed:

  • Supported protocol (sometimes called a “type” of “connection”, or a type of “account”)
  • What type of encryption setting to use.
    • This basically boils down to specifying whether or not TLS/SSL will be used.
      • Note that “STARTTLS” is a different setting than “TLS”. These options are NOT the same. If you are trying to (or are told to) use “STARTTLS” then you might want to use that instead, but except for situations where a person knows that is what the person wants to try to use, this guide believes that choosing just “TLS” (or “TLS/SSL”) will be more common and preferable than trying to use “STARTTLS”.
  • Which [TCP] “port” numbers to use?
    • A number is used to specify a “port” (which networking experts may identify as being, more specifically, a TCP “port”). There is typically one “port” number used for checking incoming mail, and one port number used for sending outgoing mail. (In many cases, the “port” number is the only setting that is different between “incoming mail” settings (used with IMAP or POP) and “outgoing”/“SMTP” mail settings.)
Optional Fields (Somewhat Common)

That's the list of settings that someone commonly needs to get right in order for the E-Mail to work. There are some other settings that may be rather commonly asked for during a basic startup process. Don't fret if you don't see one or more of these settings, because not all software may ask for this during the initial phase when connection settings are being asked for.

  • Full/Display Name
    • This is the name that will be included in outgoing messages, so this name will typically show up when other people see who the message says it is from. If you misspell something, or enter an incorrect/wrong value (or even leave this blank), software will typically send the message just fine. So, an undesired value, entered for this setting, does not cause a connection to fail to work. (It just affects who the sender claims to be when an outgoing E-Mail message gets sent.) If your E-Mail address is provided through an organization (“work”/“company”, or perhaps a school), there might be some expectations that this data field should contain text that matches the name that the organization has on file. This could be a spot where people customize their name a bit, such as a man calling himself “John” instead of “Jonathan”.
  • Server/Account Description
    • This can be set to anything. This won't break a connection, and won't show up in outgoing E-Mail messages. The purpose of this field is to describe an E-Mail account and/or an E-Mail server. For instance, maybe a couple might be used for “Work” (and this could help distinguish between different E-Mail settings used with multiple employers), access to another is provided by a “School”, and yet a third might be for more “Personal” purposes. This field is simply to help a person on this computer keep things straight, and so there is no “incorrect” values that would end up actually breaking communication.
      • This is a setting for you to decide, and leaving it blank may be perfectly fine. Don't expect a support/service provider to tell you this setting, because the provider is not likley to know how you would best prefer to optinally describe things.
WebMail

Is there a “Webmail” address that can be used? If so, then, what is that address?

  • Even if that isn't the desired long-term solution, this can often be used to help test an account's credentials, so this can help narrow down some potential troubleshooting efforts. Therefore, this can be good to know.
  • This setting is NOT required for things to work. (But many providers do provide such an option, so if there is such an option available, then knowing about tht could commonly be potentially helpful.)

Typically, E-Mail can be successfully set up when all of those details are known. Otherwise, guessing might sometimes result in figuring out what the correct settings are, although obtaining success that way can also be rather infeasible (often depending on which setting is unknown). An E-Mail service provider can typically provide each of those details.

Quick Tips On Data Entry
  • Tips about the username:
    • (Commonly the username to log in as will be the same as an E-Mail address, or it is the same as an E-Mail address except without the @ or anything that came after the @.)
      • Some software has been known to automatically try a username which is like the E-Mail address, except with the @ removed as well as any text that come after the @. If the E-Mail server requires the full E-Mail address, then this automatically-guessed setting may require manual intervention.
  • Tips about TCP Port Numbers:
    • (Typically, an E-Mail service provider will provide details such as which TCP port numbers to use. If not, you could just try some of the standard options listed in the later section on “E-Mail”-Related TCP Ports.)
    • (A “TCP” port is the type of port used for each of these standard major protocols: IMAP, POP, SMTP, and Submission. Therefore, the distinction of a port being a “TCP” port is not something most users need to worry about. This guide just calls them “TCP” ports to provide a bit more clarity for people who have more experience working with different network software “port” types.)
  • Tips about Encryption/SSL/TLS:
    • In many cases, TLS/SSL may not only be just supported, but may also be required. If an E-Mail service provider knows this to be true, that may be a nice detail for an end user to know.
    • TLS and SSL are basically two different versions of what most people consider to essentially be the same thing. So a reference to “SSL/TLS” is the same thing. If you happen to see separate options, “TLS” is better than “SSL”, and if you see ony one of the options, then either one may be likely to work just fine.
    • As an example, this might be described as “Make sure that SSL support is turned on.”)
  • A quick tip: Multiple pieces of software have been seen automatically adjusting the port settings each time there is a change to the setting of what encryption method to use. If that is automatically adjusted to an incorrect/undesired value, then manually adjusting a TCP “port” number/setting (again) may be needed.
[#emltcppt]:

“E-Mail”-Related TCP Ports

...

  • The first column lists the connection style
  • The second column lists the direction that the E-Mail is (going to be) travelling
    • This informational column is provided for clarity. Any time the method shown says “IMAP” or “POP”, this will be “incoming”. Any time the method shown says “SMTP”, this will show “outgoing”.
  • The third column is what most people are likely going to be wanting to get from this chart, which is the standard TCP port number
  • For setting up E-Mail, a person is likely to only be paying attention to the first thee columns. The 4th column is some extra information for those interested in understanding what technical specifications the connection options are related to. (This 4th column is just provided as a reference for people who may be interested in such details, and can be ignored by people who aren't seeking such details.)
Method...directionTCP
Port		Why (Tech Spec)
IMAP4S (a.k.a. IMAP4 over TLS/SSL)”)incoming993RFC9051: IMAP4rev2 section 12, RFC 8314 Section 7.1 &§ 3.1
POP3S (a.k.a. POP3 over TLS/SSL)”)incoming995RFC 8314 Section 7.2 &§ 3.2
SubmissionS ([Message] Submission over TLS/SSL)”)outgoing465RFC 8314 Section 7.3 &§ 3.3
SMTPS (SMTP over TLS/SSL)”)outgoing465RFC 8314 Section 7.3 &§ 3.3
IMAP4 using STARTTLSincoming143RFC9051: IMAP4rev2 section 12, RFC 2595 section 3
IMAP4 using no encryptionincoming143RFC9051: IMAP4rev2 section 12
POP3 using STARTTLSincoming110RFC 2595 section 4
POP3 using no encryptionincoming110IETF RFC 1939 Section 3 (IETF STD 53)
SMTP on the TCP port reserved for “[Message] Submission”, using STARTTLSoutgoing587RFC 6409 section 3.1
SMTP on the TCP port reserved for “[Message] Submission”, using no encryptionoutgoing587IETF RFC 2476 section 3.1
SMTP on the original TCP port used for “SMTP”, using STARTTLSoutgoing25RFC 3207: SMTP STARTTLS
SMTP on the original TCP port used for “SMTP”, using no encryptionoutgoing25IETF STD 10, RFC 521 section 4.5.4.2
Preferences/Notes
  • Any reference to IMAP (including variations like IMAPS) can be presumed to refer to IMAP4. (For instance, IMAPS refers to IMAP4S.) This is because the latest version of IMAP has been some variation of IMAP4 since December 1994's RFC IETF 1730 (including August 2021's update, IETF RFC IMAP4rev2).
  • POP3 has been the latest version of POP since November 1988 (when RFC IETF 1081: POP3 was made as an update for February 1985's RFC 937: POP2 which updated the prior October's RFC 918: POP). For some reason, people don't abbreviated POP3 down to POP as often as IMAP4 gets abbreviated down to IMAP. Regardless, if you see a modern reference to POP (where “modern” refers to any time newer than late 1988), you can pretty safely presume that is likely referring to POP3. That includes variations: POPS refers to POP3S.
  • Which connection methods (including which “protocols”) a person can use will depend on some details, quite importantly including what the E-Mail server supports. Some E-Mail servers could potentially support all of the options listed in the above chart, but many E-Mail providers will only support certain connection methods. One very common reason to support only some methods is that some methods use communications that are more secure than when other methods are used. (Another reason is that supporting additional methods can take a bit of extra work to set up, and may seem needlessly redundant so there may not be much desire to support a lot of extra methods.)
    • If often makes sense to obtain details from an organization or person involved with the support/setup of an E-Mail server. (If you are getting E-Mail services from a company, see if that company has some documentation which specifies which methods can be used, or if an employee can provide such information.)
  • Using the specific TLS/SSL ports for encryption is preferred. IETF RFC 8314 notes the preference for “Implicit TLS”. By using reserved ports, a person can know that software implementing standard protocols will be using encryption. (The use of encryption can be implicitly assumed if standards are being followed.) STARTTLS is not less secure if restrictions are in place, but because STARTTLS uses the same port numbers as unencrypted traffic, software could potentially “fall back” from using STARTTLS and instead use unencrypted traffic. That may be harder to notice. (The STARTTLS method is considered “Explicit” because the encryption only happens when explicitly requested.)
    • A curiosity: TCP 465 may also be used for the Uniform Resource Locator (“URL”) Rendezvous Directory (“URD”) for Source Specific Multicast (“SSM”), as noted by IANA search for 465. The overlap is discussed a bit by IETF RFC 8314 section 7.3.
  • MAPI may be the nicest user experience (more than IMAP or POP), but may be more restrictive and challenging to set up, and may be less widely supported by various software implementations.
    • When MAPI is available, often IMAP and/or (probably “and”) POP will be as well.
    • MAPI may also not typically use a rather standardized and limited list of TCP ports, like what IMAP and POP and SMTP and Submission all do. This is why the above chart does not include standardized TCP port numbers for MAPI. This may also be a key reason why MAPI has often been implemented by using a VPN to bypass barriers presented by firewalls, instead of just relying on an open TCP port.
  • [#imaorpop]: IMAP is preferred over POP for all reasons but one characteristic about POP that some people may find to be nicer.
    Some POP3 characteristics
    • Software implementing POP will typically have default (uncustomized) behavior of causing POP to delete E-Mail from the server when it is downloaded.
      • This is typically a configurable option, so software using POP typically can be configured to leave messages on the server.
    IMAP Features
    • When using IMAP, the default behavior is to leave messages on the server.
    • IMAP supports the concept of an E-Mail “folder” to help organize E-Mail within a single mailbox/account. While POP3 was able to implement an organized separation to the extent that separate E-Mail addresses could have data stored in different locations and POP3 would just show data for the one E-Mail box, IMAP4 usefully expands that concept so that individual end users can store messages in multiple folders (that are stored on the E-Mail server).
    • IMAP also supports some message “status” details to be stored on the server. With such details, a message may be marked as “read”, whereas POP3 just has all messages the same (and software will typically treat such a message as “unread” if it is still on the server.
    • IMAP usage often results in lower bandwidth (and therefore can often operate faster) than POP. This is because an IMAP server can just send a message header, instead of an entire message body. This can result in an overall bandwidht reduction if the message body is not downloaded. Even if the message body does get downloaded later, it may be better to just have headers be transmitted first, so that the information from the headers can be used (to display a list of available messages) sooner than if entire message bodies were being transmitted before information was obtained from more E-Mail headers.
    A Comparing Summary
    • POP3's biggest advantage these days is that by removing E-Mail from a server, there may be lower space used on a server.
      • However, that advantage can easily be mitgated. If software can be used to automate moving or deleting E-Mail after it has been accessed (perhaps after a certain amount of time), there's typically no significant advantage for an end user to be using POP3 instead of IMAP4 (if both are implemented/supported).
      • Many people don't like the situation as much when E-Mail messages are getting removed from the server right away. If one person accesses an E-Mail box with multiple devices, any device won't see an E-Mail message if it checks for E-Mail after another device has removed that message from the server. This can easily affect a single person who might try to use a single E-Mail box with a desktop workstation, a laptop computer or tablet, and a mobile phone. Such possibilities increase if multiple people are trying to use a shared E-Mail box.
    • IMAP4 may have had a little bit less software compatibility in the 1990s, may be a bit more complex when someone is trying the more complex/advanced technique of manually interacting with a TCP stream (such as if using Telnet), and might use a bit more of some resources on a server (CPU power to prcess some data), although that may be offset by other characteristics (such as IMAP connections often using lower bandwidth, and perhaps requiring fewer “technical support” resources as people are less frustrated with an experience that feels more natural/complete these days).
  • SMTP is used for servers to receive E-Mail submissions. This includes E-Mail from MUA software and E-Mail from other E-Mail servers. So, outgoing E-Mail uses SMTP. Submission is basically a slight variation from SMTP and is often just referenced like as if it is SMTP. IMAP and POP3 can handle downloading E-Mail and deleting E-Mail from a server. IMAP can also handle moving E-Mail from one folder to another. Because people typically want E-Mail working in both directions, it is common to set up both SMTP (for outgoing) and another protocol (IMAP or POP) for incoming.
  • Submission is basically just a little variation from SMTP with two differences. The first is that it requires “SMTP Authentication” to be used, whereas SMTP did not always require such authentication. (To elaborate, SMTP typically did not require such optional SMTP authentication. In many cases, SMTP Authentication might not even be supported by the server and/or client software.) The second difference is that the unencrypted/cleartext port (also used with STARTTLS) is TCP port 587 instead of TCP port 25.
  • Microsoft Exchange ActiveSync (“EAS”) is not thoroughly documented here at this time, although some details may be at https://contactgenie.info/understanding-email-protocols-pop-imap-mapi-eas/
Details of the settings

Before trying to set up access in common “MUA” software, there are some details that will need to be known. Here is a list of details that are commonly needed during such a setup process:

User Name

Commonly, only one “user name” will work to be able to log into an E-Mail account. Most commonly, the usernames are all lowercase, and the second-most common approach (which is most common with some software designed for use with Microsoft Windows) is to be case-insensitive (meaning that case doesn't matter), so if in doubt, trying lowercase is recommended.

The user name might or might not have anything to do with what the E-Mail address looks like. However, most commonly, it does, and the username is simply whatever shows up before the @ in an E-Mail address. The second-most common standard is for the “user name” (used to log into the account) looks exactly like the E-Mail address. (Typically only one of those approaches will work.) There can be other login methods, such as relying on authentication which relies on a user database (such as details from the “Active Directory Users & Computers” standard), possibly relayed through a network protocol like RADIUS. If you are trying to use an E-Mail account supplied by an organization, and you know a “user name” to log into another main account related to that organization, you might wish to try that, and/or try that username followed by an @ and the Internet domain name of the organization's Internet site.

Because the process of enabling a “user name” to use E-Mail can, at least theoretically, involve a username that is fully customized to any standard or even no consistent/uniform standard, if a person does not know their username then they may need to try some common variations or check with whomever is supporting and/or supplying the E-Mail service.

Protocol
Main Overview Details
  • The most commonly supported protocols are a variation of IMAP4 or a variation of POP3.
    • This detail is typically necessary (although some software might try “Auto Detect”, which simply involves trying each one as needed (after any prior attempt has failed). You might even be asked about the “protocol”, sometimes referred to by another phrase like “account type”, on a screen before seeing a different (later) screen that shows other connection settings (like a server's “host name”).
    • Sometimes the protocol may be mentioned without a version number (more commonly IMAP4 just being called IMAP, whereas writing out “POP3” still seems common), and the “S” suffix (at the end of IMAP4S or POP3S) may often be left off. These are details that don't typically need to be worried about.
      • The reason for not needing to worry about the protocol's version number being frequently specified in text is because the common version number is typically safe to guess. IMAP has remained at the same major version number for decades (IMAP4 was released in the year 1994) and POP has remained at its same version number for even longer (since POP3 was specified in the year 1988).
      • Also, IMAP4S can often be thought of as IMAP4 with added security features being implemented, and similarly POP3S can be thought of as POP3 with added security features being implemented. Therefore, it is not really wrong to refer to IMAP4S as “IMAP”, because there is IMAP-compatible communication occurring (within an encrypted stream) when IMAPS is being used, and similarly POP3S is actually using POP3 communication in some fashion. So, don't worry too much if software isn't showing the “S” suffix at the end of the protocol, as long as the software is properly set to use the right encryption settings.
  • Others could include MAPI and/or Exchange ActiveSync, or possibly using an E-Mail protocol tunnelled over HTTPS (which may involve different software than what is used to connect to “web mail” over HTTPS). These other pptions may be even nicer when they work, but may be less widely supported (possibly due to a greater challenge of fulfilling more significant/stringent requirements).
Some further info/details
  • Anything involving HTTPS and which is support built into a traditional E-Mail program, rather than a web browser, may be referring to a newer mechanism designed to try to provide some of the advantages of being on a local network, without requiring a special “VPN” connection to be established ahead of time. This may be nicest for people using mobile devices which might be local sometimes, and remote other times, although less mobile computers like desktops might work just as easily without ever needing to tunnel things over HTTPS. If you can use this, and it works well, that will probably be a very good option once (if) it is ever set up quite well. For many people, this might not be an easily implementable option.
  • MAPI, sometimes described as a “Microsoft Exchange” connection method (since Microsoft Exchange was/is often a server that provided support for such MAPI connections), is often nice due to enabling a popular feature of having a server “push” E-Mail to a client, instead of waiting for a client to check with the server to determine if the server has new mail. This can often get mail delivered quicker, and might even reduce overall bandwidth. However, this may also have some additional requirements that make this option less attractive/feasible:
    • Some software simply doesn't support this.
    • There may be requirements about whether the server can see a client as being connected to a local subnet. Therefore, this might not be as feasible with mobile devices, or perhaps such devices can connect with MAPI but such a connection might only work when a VPN connection is actively connected.
  • IMAPS is preferred over POPS for the same reason(s) that IMAP is typically preferred over POP3. IMAP4S simply refers to IMAP4 secured, which is the same thing as IMAPS (unless, perhaps, maybe, possibly if some very old software is being used, but IMAP 4 came out in the year 1994, so popular, widely-used modern software is not likely to support only older versions of IMAP.
  • IMAP: IMAP can support more features than POP3, like the concept of an E-Mail “folder” within an account's E-Mail, and possibly quicker checking as IMAPcan request information about a message's header without needing to download the entire message at that moment.
Connection Encryption/Security Settings (e.g. TLS/SSL)
  • You must choose settings that are compatible with the E-Mail server. The choice to use “TLS” or “SSL” (often described as a combined choice, named either “TLS/SSL” or “SSL/TLS”) is the most common secure setting. (Most software describe “TLS” and “SSL” as a single option to use, but if you do have a choice, then “TLS” is newer, and considered to be more secure, than “SSL”.)
    • Choosing “No encryption” is NOT recommended for E-Mail correspondence over the public Internet.
      • (Since checking E_Mail is typically not functional without an E-Mail client submitting a password, and the same is frequently true for sending E-Mail as well, the main practical purpose this is possibly recommended for today would be educational purposes, demonstrating why not to do this. Some troubleshooting might also be useful, but make sure that software doesn't supply a password when using such a setting! Note that while a password is perhaps the details that are most likely, an unencrypted connection may also insecurely share other details about a message, including the contents of the main [text] “body” of a message.)
Server/Host Name

Since an E-Mail server is a “host”, the server's primary name is often called a “host name” for the server. Some E-Mail software refers to a server's “host name”, while others might refer to the same setting using a more specific phrase, “server name”.

In many, many cases, this has simply been the portion of the E-Mail address after an @. However, at least some software by Apple (including “Mail” on an iPhone) has been known to squak if the E-Mail server presents an encryption certificate which uses a name other than what the client was expecting. Therefore, such softare might only work when using the server's primary, preferred name.

  • Realistically, the easiest way to get such information is probably to look over information provided by whomever is supporting (and perhaps supplying) the E-Mail account. If such information is not found, then contacting technical support may be the option that most people will find to be reasonably feasible.
  • There is another possible approach (even though it isn't elaborated on much here). One could try to discover the preferred host name by using DNS.
    • The idea here is to try doing a regular lookup to obtain an IP address, and then trying a “Reverse DNS” lookup to see if that provides a preferred name).
    • Such a a process is probably considered to be a more advanced technique than what many people will want to do, and even doing that might not provide the preferred information in some situations where DNS might not provide such values.
    • (A fuller guide to how to do that is not here, at this time. A future version of this documentation might elaborate upon that a bit further...)
Port numbers

For a connection to work, the E-Mail software is going to need to use the correct TCP “port number”. Such a “port number” can be customized (in which case, the value being used would be something that should be provided by whomever provides support for E-Mail server's settings), but most commonly the “port” number will be correctly determined as long as other settings are correct. If an incorrect “port” number is specified, that can be manually corrected although the most common cause for that is another setting being wrong, so it may make sense to first focus on fixing the other setting(s) that typically impact a “port number”, and then software will often automatically adjust (and, thereby, correct) the “port” number.

  • The following chart's first three columns may be worth checking to determine (and verify) the typical “port number” setting.
    • (The 4th column can be ignored by people who are just seeking to make a working E-Mail connection. That column is provided to supply a reference to for people who may be interested in understanding which main, primary technical specifications are closely related to some of these common connection options.)
If you're using...... for the direction of ... ... then use TCP Port Number...Why (Technical Specification)
IMAP4 over TLS/SSLincoming993RFC9051: IMAP4rev2 section 12
POP3 over TLS/SSLincoming995
SMTP over TLS/SSLoutgoing465
IMAP4 using STARTTLSincoming143RFC9051: IMAP4rev2 section 12, RFC 2595 section 3
IMAP4 using no encryptionincoming143RFC9051: IMAP4rev2 section 12
POP3 using STARTTLSincoming110RFC 2595 section 4
POP3 using no encryptionincoming110IETF RFC 1939 Section 3 (IETF STD 53)
SMTP using STARTTLS on Message Submissionoutgoing587RFC 6409 section 3.1
SMTP using STARTTLS on original SMTP TCP portoutgoing25RFC 3207: SMTP STARTTLS