It is possible to have a server that handles both IMAP4rev1 and SMAP1. This is done by establishing the initial SMAP1 client/server connection in a manner that's compatible with IMAP. When the server receives a connection from a client, the server sends the following reply:
      * OK [CAPABILITY capabilitylist] message
      
Servers that offer both IMAP and SMAP must terminate the initial reply with CRLF. SMAP-only servers can use the LF character alone.
“message” is
    free-form text, that identifies the server software in
    human-readable format. “capabilitylist”
    is a list of keywords that describe the server's technical
    implementation. Keywords in the list are separated by
    whitespace. Clients should separate whitespace-delimited
    “capabilitylist”
    into individual keywords. Multiple keywords may occur in any
    order, and clients must search the entire list for keywords the
    client understands.
The presence of the SMAP1
    keyword specifies that the server implements the protocol
    defined by this document. Absence of the SMAP1 keyword indicates that the server is
    probably an IMAP server. Clients that support both SMAP and
    IMAP protocol can automatically revert to IMAP, if they so
    choose.
The server's initial reply to the client may include the
    “message”
    part only, without a leading keyword capability list inside.
    This indicates that the server is only an IMAP server, and does
    not support SMAP.
“capabilitylist”
    may include additional keywords besides SMAP1. This document defines the following
    keywords. Other keywords may be added in the future. SMAP
    clients coded to this specification should ignore keywords they
    do not recognize.
This SMAP server supports an SSL/TLS connection, via the STARTTLS command.
mechanismThis SMAP server supports the “mechanism”
          authentication mechanism, as defined by RFC 3501, and its successors.
languageThis SMAP1 server can return diagnostic messages in
          the natural language “language”.
          “language”
          is a language tag defined by RFC 1766. A multilingual SMAP server
          lists multiple LANG
          keywords, one keyword for each language.
The SMAP1 server supports user-defined per-message
          KEYWORDS attributes.
The STARTTLS and AUTH keywords are also used by IMAP in the
      same way. IMAP does not define the LANG keyword (there is an optional extension
      to the base IMAP protocol specification that is functionally
      similar, but not compatible, with this definition). At this
      time, LANG does not introduce
      interoperability issues with IMAP. IMAP also does not define
      KEYWORD, a similar functionality
      is indicated by the PERMANENTFLAGS untagged reply.
In the future, there's a small chance that a new IMAP
      protocol extension or revision may not be compatible with the
      LANG or KEYWORDS capability keywords, or any other
      SMAP capability keyword. Should this occur, the next revision
      of this document will remove LANG or KEYWORD
      (or another incompatible keyword) from the initial capability
      list. The client should issue the "\SMAP1 CAPABILITY" command to retrieve an
      SMAP1-specific capability list that includes the complete
      SMAP capability keyword list.
Should IMAP introduce an interoperability issue with the
      SMAP1 keyword itself, it will be
      replaced by another keyword.
Example:
      S: * OK [CAPABILITY SMAP1 KEYWORDSAUTH=CRAM-MD5 STARTTLS
              LANG=EN LANG=EN-US IMAP4rev1] SMAP/IMAP hybrid server ready
      
The first word of IMAP commands is an arbitrary command
      identification tag. The first set of SMAP commands, that set
      up and log in to the mail account, are prefixed by the word
      "\SMAP1". The backslash
      character is not allowed in IMAP command identification tags.
      A server that implements both IMAP and SMAP reads the first
      whitespace-delimited word of the first command it receives.
      If the first word in "\SMAP1"
      the server knows that the client is using SMAP. Subsequent
      server replies will now be SMAP replies. Otherwise, the first
      word must be an IMAP command identification tag, so the
      server reverts to IMAP mode for this client connection.
The server responds to this command with a "* CAPABILITY" single line reply. The remaining words in
      the reply enumerate SMAP capabilities supported by the
      server. Example:
        C: \SMAP1 CAPABILITY
        S: * CAPABILITY SMAP1 AUTH=CRAM-MD5 STARTTLS LANG=EN LANG=EN-US IMAP4rev1
        S: +OK SMAP1 capability list complete.
        
The server should reply with the same capability list as
      the initial * OK message.
The STARTTLS capability
      indicates that the server is capable of encrypting the
      connection between the client and the server. See RFC 2595 for some additional
      comments on using TLS with mail-related protocols.
SSL/TLS negotiation begins immediately after the client receives a successfull status reply from the server. Example:
        C: \SMAP1 STARTTLS
        S: +OK Ready to accept an encrypted SMAP1 connection
        
        [ TLS negotiation occurs ]
        
This command instructs the server to send all subsequent messages in a different natural language. Example:
        C: \SMAP1 LANGUAGE FR
        S: +OK Bonjour
The specified language must be one of the languages enumerated in the capability list.
The UTF-8 character set is used for all languages.
The \SMAP1 LOGIN command
      initiates a simple userid/password login sequence. The third
      word of this command is the login userid, the fourth word is
      the login password. The server's status reply indicates whether the supplied
      credentials were accepted. Example:
        C: \SMAP1 LOGIN joneil p3r472
        S: -ERR Login invalid
        C: \SMAP1 LOGIN joneil p2r798
        S: +OK Logged in
The "\SMAP1 AUTHENTICATE"
      command initiates a generic SASL-based login mechanism. The
      third word of this command specifies the SASL authentication
      mechanism, which must be one of the AUTH mechanism listed in the server's
      capability list. The subsequent SASL conversation, if any, is
      identical to an IMAP SASL conversation: each server challenge
      is sent as a line of text that starts with the > character, whitespace filler, then the
      base64-encoded server challenge. The client replies with a
      line of text containing the base64-encoded reply.
      Example:
        C: \SMAP1 AUTHENTICATE LOGIN
        S: > VXNlciBOYW1lAA==
        C: bWl0bGlz
        S: > UGFzc3dvcmQA
        C: Zmxvc2pidw==
        S: +OK Logged in