One place for hosting & domains


      A Quick Guide to Using LiveReload with Gulp


      Tired of having to refresh your browser every single time you make changes to your LESS/SASS/CSS files? This article will take you step-by-step to getting LiveReload integrated in your development environment so you no longer have to reload your browser to see changes. For this tutorial, we’ll be using Gulp. If you’re unfamiliar with it, check out these awesome and super easy Scotch resources about it:

      LiveReload is an amazing piece of software that can really help improve your workflow – especially when it comes to CSS. The purpose of this article is to get you started in that direction as quickly and as easily as possible. In this article, we’ll cover:

      1. A brief overview
      2. The logistics – making sure you have everything downloaded to get things running
      3. Editing a Gulp file to setup Livereload based on this Gulp and Less Starter
      4. Seeing LiveReload in action

      Imagine a “happy land” where browsers don’t need a Refresh button. Well, that’s exactly what Andrey Tarantsov set out accomplish. LiveReload monitors changes in your file system (for example, your CSS or your images). As soon as a change is detected, such as a simple “save”, the browser is refreshed automatically. In this example, we will be examining LiveReload through editing LESS files.

      We’ll be setting up LiveReload with Gulp. A lot of people immediately think that you have to purchase this software. The truth is, using LiveReload with Gulp is completely free to use. The creators of LiveReload sell a for-purchase app that makes it ridiculously easy to use.

      LiveReload can also be utilized through other task runners, such as Grunt and Yeoman. And of course, we can use LiveReload for when we change our Javascript. I talk about its implementation towards the end of the tutorial.

      Lastly, it’s you may see that LiveReload is called LiveReload 3 on it’s GitHub repo compared to LiveReload 2 in the Chrome Store. There is no need to worry about conflicting versions, the way we are implementing it will work perfectly regardless of version.

      Change directory cd into the folder where your gulpfile.js and package.json is located via the command line. Once you are there, enter in the following command:

      1. npm install --save-dev gulp-livereload

      Next, we need to download the Google Chrome extension LiveReload, go to the Chrome Store and download it here. Make sure you can view it in your tool bar and that the circle is filled in with black. This is important or else it won’t work.

      Use incognito to manage sessions? You can enable Livereload in incognito by navigating to “More Tools”, clicking “Extensions”, and then checking the box to allow it in incognito mode.

      Now go to the ‘build-css’ task and type in .pipe(plugins.livereload()); after the .pipe(gulp.dest('build')).on('error', gutil.log). The ‘build-css’ task in it’s entirety should look like this…

          gulp.task('build-css', function() {
                 return gulp.src('assets/less/*.less')
                      .on('error', function (err) {
                              browsers: [
                                  '> 1%',
                                  'last 2 versions',
                                  'firefox >= 4',
                                  'safari 7',
                                  'safari 8',
                                  'IE 8',
                                  'IE 9',
                                  'IE 10',
                                  'IE 11'
                              cascade: false
                      .pipe(gulp.dest('build')).on('error', gutil.log)

      Put plugins.livereload.listen(); at the top line of watch task. It should look like this:

    'assets/js/libs/**/*.js', ['squish-jquery']);
    'assets/js/*.js', ['build-js']);
    'assets/less/**/*.less', ['build-css']);

      Now, run Gulp in the command line and make sure everything is okay. If an error happens, most likely you had a missing or extra semicolon.

      Now go ahead and make a change to your LESS file and see as you save the command the Gulp tasks will run, but a new one will appear. It will be the directory of your project and at the end build/style.css reloaded.

      Go to your browser and you should see the browser has refreshed on save. If it hasn’t, I cannot stress enough that the black hole needs to be filled for the LiveReload Google Extension, or else it will not work.

      Want to be pro status? Add .pipe(plugins.livereload()); after the build (.pipe(gulp.dest('build’))) for your JavaScript in the build-js task so you LiveReload after you save your .js file – it’s only one extra line.

      LiveReload can be really powerful when used with Gulp. Remember, do not forget to add plugins. before your LiveReload function call, unless you are not utilizing the gulp-load-plugins plugin. Don’t listen to the other tutorials who say you need to add your port or host in the Gulp file. You do not need any parameters in your livereload.listen(), everything is set up! All in all only a couple lines of extra JavaScript so you do not have to do COMMAND+R anymore.

      Quick Guide to SMTP: The Protocol That Powers Email

      Instant messaging, Slack, and Zoom may get all the attention lately, yet email has remained the most ubiquitous communication method of the Internet for decades. One open standard makes it possible for any user, on any platform, to exchange email with anyone else: the Simple Mail Transfer Protocol (SMTP). SMTP works as a universal mail carrier, connecting users around the world regardless of the hardware and software they use.

      This guide explains what SMTP is, what it does, how it works, and what commands it uses. You also learn how SMTP works with other protocols to make end-to-end delivery possible.

      What Is SMTP?

      SMTP is a standardized set of commands and replies that mail servers use to send and receive email. As described by the Internet Engineering Task Force in RFC 5321, SMTP defines procedures for email acceptance, formatting, and forwarding. The RFC also describes how to handle error conditions and return mail if servers are down or recipients don’t exist.
      Although SMTP operates at the application layer, it is a protocol, not a software package. A mail server (usually special software running on a dedicated machine) implements SMTP to communicate with other servers. A mail server may run SMTP processes, but that’s an implementation detail and not a protocol requirement.

      What Does SMTP Do?

      Simply put, SMTP’s job is to send and receive email. While SMTP does most of the heavy lifting for email delivery, it’s only one of several components in most email systems. Before delving into SMTP and how it relates to other protocols, it’s best to begin with an overview of Internet mail architecture.

      To most, “email software” probably means an application for reading and writing messages. Software packages like Microsoft Outlook or Mozilla Thunderbird are technically called mail user agents (MUAs). MUAs don’t actually deliver mail. After composing a message with an MUA, the message is then sent to a mail server running a mail transfer agent (MTA). MTAs communicate via SMTP with one another, and it’s here that mail delivery occurs.

      Most mail servers support SMTP. Widely used open source mail servers include Sendmail, Postfix, and exim. Commercial products such as Microsoft Exchange have proprietary engines, but include SMTP connectors to speak with other mail servers. Programming languages such as Perl, Python, and Ruby also include libraries that can act as lightweight SMTP clients and servers.

      While SMTP describes ways to send and receive email, it does not retrieve messages. Instead, MUAs use a separate, dedicated protocol such as the Internet Message Access Protocol (IMAP) or Post Office Protocol (POP) to pull messages from a mail server. Most modern MUAs use IMAP instead of the older POP.

      Although SMTP can handle both MUA-MTA and MTA-MTA connections, it’s usually preferable to separate message submission from message relay. Separating these functions allows different security and policy decisions to be applied at each step. The submission protocol, defined in RFC 6409, is a widely implemented counterpart to SMTP. Most mail servers support both protocols, and use submission for getting messages from MUAs to MTAs.

      The diagram below provides a simplified overview of Internet email architecture. Although this example shows only a few servers, SMTP works the same way throughout the global Internet.

      Email delivery using SMTP

      When SMTP first appeared in the early 1980s, it lacked security functions such as authentication and encryption. As the Internet grew, it became obvious that SMTP’s lack of security features was an issue. It was trivially easy for attackers to send spam, spoof legitimate users, steal passwords, and conduct man-in-the-middle attacks.

      In response, the IETF defined methods to authenticate users and encrypt email traffic in flight. Encryption of SMTP traffic is considered a best practice. RFC 8314 describes the ways to implement encryption.

      How Does SMTP Work?

      An SMTP session contains at least five steps:

      1. Initiation
      2. Message transfer
      3. Validation
      4. Routing
      5. Termination

      SMTP conversations consist of commands and replies. An SMTP client (which may be an MTA) usually initiates commands, and replies come from the SMTP server. Replies consist of a 3-digit code, usually followed by text. For example, a server replies “250 OK” to acknowledge receipt of the body of an email.

      Session Initiation

      An SMTP session begins when a client opens a connection to a server. SMTP servers most often listen on TCP port 25 for incoming connections. After a connection opens successfully, the client sends a “hello” command identifying itself. In the command’s basic form, the client essentially says “hello, I am”. In the more modern version, the client sends an extended hello command to say “hello, I am, and I would like to know which service extensions you support”.

      SMTP service extensions support the ability to include encoded Multipurpose Internet Mail Extensions (MIME) attachments, pipeline multiple commands, request delivery service notifications, and many other options.

      Message Transfer

      Once a connection is open, a client can then send one or more messages to the server. This is a three-step process. First, the client sends a MAIL FROM: command with the sender’s email address. Second, the client sends one or more RCPT commands, each with the email address of a message recipient. Finally, the client sends a DATA command, followed by the message contents, and finished by an end-of-mail indicator.


      Next, the SMTP server evaluates whether to accept and process each message. A server may return or discard messages with malformed or unrecognized source or destination addresses. Although mail servers can be configured to silently discard email, the SMTP RFC strongly discourages this unless senders are known to be fraudulent or undesirable. For all other mail, the RFC recommends returning undeliverable mail with an error code.

      Servers may also optionally rewrite source or destination addresses. As an example of the former, if Company B buys Company A, a mail server might rewrite mail from to appear to originate instead from As an example of destination address rewriting, a mail server might expand a mailing list’s address into many recipients who subscribe to that list.


      Assuming an incoming message has passed all validation tests, the next task for an SMTP server is to route the message to its final destination. Although there are many routing options available, all MTAs perform the same four basic steps:

      1. Perform an address lookup using the Domain Name System (DNS).
      2. Identify the name and host parts of a recipient’s email address.
      3. If the host isn’t local, forward the message.
      4. If the host is local, store the message.

      If a recipient’s email address isn’t local, the mail server becomes an SMTP client. It then hands off email to another SMTP server that can deliver mail for the recipient. If the recipient is on the same server, routing is easy. The MTA simply puts email in a message store, where it remains until the recipient’s MUA retrieves it using IMAP or POP.

      DNS First

      Before routing can occur, an MTA server must first query DNS to determine which mail server(s) accept mail for a given domain. DNS has at least one resource record, called an MX record (for Mail eXchanger), for any domain that can receive email. It points to the mail server(s) for that domain.

      SMTP depends on DNS in two critical ways. First, at least one valid MX record must exist for each recipient’s domain, and a DNS client must be able to query that record. Simply put, the sender and the recipient must have DNS working for mail delivery to work at all. DNS errors are the root cause of many email delivery problems. When troubleshooting mail server problems, it’s best practice to first verify that DNS works correctly.

      Second, optionally configure DNS with multiple MX records (one per mail server) to improve the reliability and/or speed of mail delivery. MX records include a preference, with a lower number indicating a higher priority for mail delivery. For example, here are the MX records for


      An MTA trying to send email to Gmail first tries, since its preference has the lowest value. If that server is unreachable, the MTA then successively tries the other servers with higher preference values until it’s able to make a connection. Having a primary and one or more secondary MX servers makes mail delivery more reliable in case of server or network outages.

      You can also configure MX records with identical preferences to load-balance email across two or more servers. For high-volume domains, distributing the mail load across multiple servers may help speed delivery.

      Once a DNS query completes, the server opens an SMTP session with the host in the MX record, and begins forwarding messages. If a destination mail server isn’t available, SMTP keeps retrying delivery for some interval (often 5 days by default). If the destination server is still unavailable after that interval, SMTP returns the message to the sender with an undeliverable reply code.


      After handing off all messages to a server, the final step for an SMTP client is to close the connection. As with the session initiation, the client always initiates the session close with a QUIT command.

      Basic SMTP Commands

      Although email exchanges usually occur between MUA and MTA software packages, you can also run SMTP from the command line using a telnet client. This is an excellent way to see SMTP commands at work.

      In this exchange, adapted from RFC 5321, a user with the email address [email protected] attempts to send messages to users Jones, Brown, and Green, all at In this basic example, and servers connect directly. Also, Jones and Brown have valid addresses, but Green does not have an account.

      Here is a step-by-step examination of a complete SMTP session. Note the use of reply codes after each command.

      telnet 25
      220 Simple Mail Transfer Service Ready

      You can instruct a telnet client to connect to any TCP port, including port 25, the standard SMTP port. The server’s 220 reply indicates it’s ready to open a connection. At minimum, SMTP servers also return their domain name and the words “Service Ready”. greets
      250 HELP

      The client’s EHLO (extended hello) command identifies its domain and indicates it wants to know which SMTP extensions the server supports. For each response, the server issues a 250 reply code, meaning it has successfully completed each action. This particular server supports 8-bit MIME encoding of attachments, a message size declaration, delivery status notifications, and help commands.

      MAIL FROM:<[email protected]>
      250 OK

      The client wants to send email from [email protected]. Because the server considers that a valid source address, it returns a 250 OK reply.

      250 OK
      250 OK
      550 No such user here

      The client wants to send to three recipients. The server acknowledges Jones and Brown with 250 OK replies, but sends a 550 error reply to indicate that it doesn’t recognize Green.

      354 Start mail input; end with <CRLF>.<CRLF>
      Contents of email message.
      250 OK

      The client’s DATA command indicates it’s ready to start sending the message body. The server’s 354 reply indicates it’s ready to receive input. The server continues to accept input into the message body until it sees a period on a single line. The 250 OK reply indicates the server successfully received the entire message body.

      221 Service closing transmission channel

      The final step is for the client to initiate a session close with the QUIT command. If successfully received, the server responds with a 221 reply, and terminates the session.

      SMTP defines many more commands and reply codes, as discussed in Section 4 of RFC 5321, but these provide an idea of what to expect in any successful SMTP connection. Section 4.1 of the RFC lists all SMTP commands, while Section 4.2.3 lists all reply codes in numerical order.


      The great thing about SMTP is that it’s an open protocol. The client and server in this case could be any type of hardware, running any operating system, with any SMTP-compatible server software. SMTP is truly the means that makes global email communications possible.

      Quick Guide to POP and IMAP: Protocols for Accessing Email

      Universal email retrieval is all thanks to open standards. Regardless of the hardware and software used, email is accessed via one of two specifications: Post Office Protocol (POP) or Internet Message Access Protocol (IMAP).

      This guide discusses what POP and IMAP are, how they work, and what commands they use. It also explains when you might want to use one over the other.

      What Are POP and IMAP?

      POP and IMAP are both message retrieval protocols that access and present email messages. POP is the simpler and more lightweight of the two, while IMAP has many additional functions that manipulate folders and set message attributes.

      Message retrieval is just one of several functions in a complete email system. Neither POP nor IMAP send email messages. Before delving into each protocol, it’s best to review client and server architecture to see where POP and IMAP fit in.

      Mail clients such as Mozilla Thunderbird, Evolution, or Microsoft Outlook are known as message user agents (MUAs). Their function is to compose and read email (Outlook runs proprietary protocols internally, but uses connectors to communicate with standards-based servers). To send messages, MUAs connect to mail servers using either the Simple Mail Transfer Protocol (SMTP) or the message submission protocol. For more information on SMTP, read our guide Quick Guide to SMTP.

      In TCP/IP email architecture, the server is called a mail transfer agent (MTA). Once a message reaches an MTA, it uses SMTP to relay the message to one or more other servers. It’s fair to say that SMTP does the heavy lifting for mail forwarding on the Internet. Meanwhile, POP or IMAP only get involved on the receiving side.

      An MUA (client) can use IMAP to display and manipulate messages that remain on a mail server. Because messages stay on the server, any changes (e.g. marking a message as read or deleting it) are reflected across all MUAs running on all client devices. With IMAP, the message store on the server is the “one source of truth”.

      In contrast, if your MUA runs POP, it downloads messages from a mail server and, by default, deletes those messages on the server.

      A single mail server can run all these protocols (SMTP, submission, POP, and IMAP) but there is no requirement to do so. In fact, most larger ISPs have dedicated IMAP/POP servers to offload these tasks from other mail servers. This is why SMTP and POP or IMAP must be configured separately in MUAs.

      POP and IMAP require their own server packages, separate from SMTP. Popular open source examples include Dovecot and Cyrus IMAP, available for virtually all Unix-like operating systems. A single server running something like Postfix for SMTP/submission and Dovecot for IMAP/POP would work especially well for smaller networks.

      The diagram below provides a simplified overview of Internet email architecture:

      Email delivery using SMTP.

      Although this figure shows only a few servers, the same division of labor between SMTP and IMAP/POP exists regardless of network size.

      POP or IMAP?

      POP dates from the 1980s, when many clients connected over dial-up connections, few users had multiple computers, and server storage was expensive. For all those reasons, POP assumes the client’s message store to be the “one source of truth”. It also allowed message reading offline, which for many TCP/IP client machines in the 1980s, was most of the time. POP only works with one inbox on the server, and doesn’t support multiple server-side folders.

      In contrast, IMAP is a server-based protocol, and has more features than POP. These include the ability to download message headers (rather than complete messages), set message flags, and create and manage multiple folders on the server. IMAP makes the server the “one source of truth”, so the same email can be viewed from any client device connected to that server. With IMAP, all MUAs on all devices sync with the server, so email folder contents look the same everywhere.

      IMAP is much more widely used today, and more currently maintained. The last major revision to POP, version 3, was in 1996, compared with a 2021 refresh of IMAP, now at IMAP version 4 revision 2.

      In most cases, you’re better off using IMAP rather than POP for email retrieval and management. You have the same view of your email from any device. You can create and manage multiple folders on the server, not just a single inbox. You have the option of using server-side filtering to automatically move messages based on content. You can set flags for each message such as seen, answered, and flagged.

      Now, there are cases where you might still want to consider using POP. Dial-up connections still exist, especially in remote parts of the US and other countries around the world. If you’re spending significant time offline, POP may be a better choice. If you only read email on one machine and want a simple and lightweight way to get mail, POP may also be appropriate.

      It’s very common for mail servers to support both IMAP and POP. However, unless the use case requires POP, you’re almost certainly better off configuring your MUA to use IMAP, which is the default for most.

      How Does POP Work?

      POP is a simple protocol with three states (Authorization, Transaction, and Update) and a relatively small command set.

      In the Authorization stage, a POP client initiates a TCP connection on port 110. Since this connection is unencrypted, anything sent over it is subject to interception and man-in-the-middle attacks. While the POP specification does not provide encryption, a later standard defines a method to send POP traffic through encrypted Transport Layer Security (TLS) tunnels. With TLS tunneling, a mail server running POP listens on port 995 instead of, or in addition to, the service on port 110.

      Once the TCP handshake completes, the server indicates that it’s ready to receive authentication credentials from the client. After the client sends valid login credentials, the POP server then transitions to the Transaction state. Your MUA now requests a list of messages and retrieves (i.e. downloads) them. In addition, your MUA can specify whether to delete or undelete previously seen messages.

      By default, POP downloads entire messages, even those that include huge attachments. Unlike IMAP, POP does not have a message preview function. You can optionally see a user-defined number of lines in a message rather than the entire email, but that is not the default behavior.

      Once the client issues a quit command, the POP server transitions to the Update state. The server attempts to remove all messages marked for deletion and close the client connection.

      POP cannot show a message on a second client device if you’ve already downloaded and deleted it on the first device. If you wish, you can optionally configure many MUAs running POP to leave messages on the server and never mark them for deletion. However, since POP doesn’t support server-side folders, that’s a formula for inbox bloat. For more flexibility in retrieving and managing email, server-based IMAP is a better option.

      How IMAP Works

      IMAP keeps messages on the server, allowing you to see your mail and sync message and folder state across multiple devices. You need to be connected to your server while working with messages and folders, but you can optionally download and store messages locally if needed. Unlike POP, you can download message headers before deciding to retrieve entire messages containing large attachments. Furthermore, IMAP allows you to maintain multiple folders on the server.

      IMAP sessions run over TCP. Servers listen on port 143 for plaintext connections, and port 993 for connections tunneled through TLS. RFC 8314 deprecates plaintext connections given the risk of password and email interception. Always configure MUAs and IMAP servers to use TLS tunneling wherever possible.

      IMAP has four states: Not Authenticated, Authenticated, Selected, and Logout:

      • Not Authenticated: The client must present credentials such as a valid email address and password before the IMAP server can accept most other commands. All IMAP conversations begin here unless the server “pre-authenticates” trusted users.

      • Authenticated: Even after a client authenticates (or is pre-authenticated), it still cannot read or manage email until it first selects a folder. “Mailbox” is the term the IMAP RFC uses. A client enters the authenticated state after it presents valid credentials (either by logging in or using pre-authentication), after an error in selecting a folder, or after a successful CLOSE or UNSELECT command.

        Clients in the authenticated state can select a folder and also create, rename, and delete, or subscribe/unsubscribe to existing folders. Clients in this state can also list folders, seeing all folders or searching for a selected group using strings and/or wildcards.

      • Selected: Only after a client selects a folder can it act on the messages in that folder. This is where the most email manipulation happens. In this state, the client can preview messages, read entire messages, copy/move messages, delete/undelete messages, and search folder contents, among many other tasks.

      • Logout: In this final state, both client and server close the IMAP session and underlying TCP connection.

      POP and IMAP Commands

      Although email exchanges usually involve purpose-built email clients, you can also manually enter POP or IMAP commands into a Unix shell. Given that purpose-built clients use the exact same commands, the shell is an excellent place to see the protocols at work.

      For plaintext connections, a telnet or netcat client connecting to either port 110 (POP) or 143 (IMAP) does the trick. Since RFC 8314 deprecates plaintext connections, it’s better to use OpenSSL commands to set up a TLS tunnel.

      POP Commands

      In POP, the client issues commands that begin with a keyword, optionally followed by an argument (e.g. USER [email protected]). The server responds with a status code of either +OK or -ERR and one or more lines of output. RFC 1081 describes the entire POP command set.

      Here is an example POP session set up through a TLS tunnel:

      openssl s_client -connect -crlf -quiet

      Here, the client initiates a secure POP connection through a TLS tunnel using TCP port 995.

      +OK Dovecot (Debian) ready.

      Since the details of TLS tunnel establishment are unimportant to POP, they’re omitted here. The final line is the beginning of the POP session. It indicates that the server is now in the Authorization state, and ready to receive authentication commands from the client.

      PASS ThisIsATerriblePasswordDontUseIt
      +OK Logged in.

      Because the server accepts the client’s login credentials (note the +OK after each command), the server transitions to the Transaction state, and is ready to display messages.

      +OK 3 messages:
      1 28065
      2 28066
      3 28066
      +OK 28065 octets follow.
      +OK message deleted

      Here, the client requests a list of available messages and their sizes in bytes (all in a single folder, as POP doesn’t support multiple server-side folders). The second command retrieves the first listed message. The final command deletes the second listed message.

      +OK Logging out

      These commands tear down the POP session (+OK Logging out) and the TLS tunnel (closed). Before terminating the POP session, the server deletes the first two messages from the server’s message store.

      IMAP Commands

      IMAP supports many more commands than POP. RFC 9051 sections 6 and 7 respectively cover client commands and server responses. Here’s a step-by-step example of a complete IMAP session tunneled over TLS:

      openssl s_client -connect -crlf -quiet

      The OpenSSL client requests a connection on port 993, which IMAP servers reserve for TLS tunnels.


      The final line is the IMAP server’s response. It informs the client that it’s a Dovecot server that supports IMAP version 4 revision 1 on Debian Linux, and that it supports the PLAIN and LOGIN methods of authentication. The IMAP session has begun, and is now in the Not Authenticated state.

      To enter the Authenticated state using the LOGIN method, the client sends an AUTHENTICATE LOGIN command. From that point forward, both client and server use base64-encoded strings for the rest of the authentication process. This makes interception more difficult, and also requires base64 encoding and decoding at the command line.


      Decoding that server string reveals that it’s asking for a username:

      echo "VXNlcm5hbWU6" | openssl base64 -d

      The next prompt, which is Password:, is also encoded. Before proceeding, it’s easiest to pre-encode user and password strings in your terminal:

      echo -en "[email protected]" | openssl base64
      echo -en "ThisIsATerriblePasswordDontUseIt" | openssl base64

      Putting it all together looks like this:

      This is a base64-encoded representation of Username:.

      + VXNlcm5hbWU6

      This is the base64-encoded username obtained above:

      This is a base64-encoded representation of Password::

      + UGFzc3dvcmQ6

      This is the base64-encoded password obtained above:


      The final response indicates that login was successful (a001 OK) and lists all the capabilities the IMAP server supports. The server is now in the Authenticated state, and is ready for the client to select a folder or log out.


      IMAP client commands begin with an alphanumeric string called a tag, and server responses then include that tag for troubleshooting. The client may increment the tag with each command (a001, a002, etc.), but the RFC doesn’t require this.

      Here the client selects the Inbox, moving the session into the Selected state.

      * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $label2 $Forwarded $Junk $label1 $label3 $label4 $label5 $MDNSent $NotJunk NonJunk Junk Forwarded $MailFlagBit0)
      * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $label2 $Forwarded $Junk $label1 $label3 $label4 $label5 $MDNSent $NotJunk NonJunk Junk Forwarded $MailFlagBit0 \*)] Flags permitted.
      * 49 EXISTS
      * 0 RECENT
      * OK [UIDVALIDITY 1371796952] UIDs valid
      * OK [UIDNEXT 108635] Predicted next UID
      * OK [HIGHESTMODSEQ 272055] Highest
      a002 OK [READ-WRITE] Select completed (0.002 + 0.000 + 0.001 secs).

      From the server’s response, you can see right away that IMAP offers many more features than POP. Among other things, the server responds with the type of flags it can set on each message (answered, seen, etc.), the number of messages in the Inbox (49), the number of unread messages (0 recent), and sequence numbers for messages.

      Unlike POP, an IMAP client can move between multiple folders on the server:

      * OK [CLOSED] Previous mailbox closed.
      * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $MDNSent)
      (Rest of server output omitted)

      After closing the Inbox folder, the server displays similar information about a different folder. This example uses the Drafts folder, but IMAP supports the creation and management of thousands of folders (“mailboxes”), including nested hierarchies.

      a004 fetch 1 (rfc822.text)
      * 1 FETCH (RFC822.TEXT {973}
      On Jan 6, 2022, at 15:25, [email protected] wrote:
      > How do I uninstall the Debian version and then reinstall
      a004 OK Fetch completed (0.047 + 0.000 + 0.046 secs).

      Here, the client requests the body of the first message in the Drafts folder (fetch 1). FETCH retrieves one or more messages, making it one of the most widely used IMAP commands. It has many options to display, for example, only message headers, message bodies (or parts of bodies), and size.

      a341 OK Close completed (0.001 + 0.000 secs).
      * BYE Logging out
      a342 OK Logout completed (0.001 + 0.000 secs).

      To terminate an IMAP session, the client first closes the current folder. If that succeeds, the client sends a LOGOUT command, ending the IMAP session and tearing down the underlying TLS tunnel and TCP connection.


      Email is truly the “killer app” of the Internet, and IMAP and POP are the protocols that make it happen. Because both are open standards, these protocols enable the retrieval of email on virtually any hardware and software combination. Along with SMTP, IMAP and POP are the workhorse protocols that make global email retrieval possible.