25.02.2013 Views

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

15.5.3 IMAP4 comm<strong>and</strong>s <strong>and</strong> response interaction<br />

IMAP4 clients establish a <strong>TCP</strong> connection to the server using well-known port<br />

143. When the connection is established, the server sends a greeting message,<br />

after which the client <strong>and</strong> the server exchange data interactively. Whenever the<br />

client sends a comm<strong>and</strong>, the server sends a completion result response to this<br />

comm<strong>and</strong>. The server can also send data for any other reason. All comm<strong>and</strong>s<br />

<strong>and</strong> responses are in the form of lines ending with the sequence.<br />

Although the server must respond to all client comm<strong>and</strong>s, it might not respond to<br />

them in the order in which they were received. In order to correlate the responses<br />

with the comm<strong>and</strong>s, the client comm<strong>and</strong>s begin with an identifier called a tag.<br />

For example, assume a client sends two comm<strong>and</strong>s to the server. The first has<br />

the tag ABC005, <strong>and</strong> the second with the tag ABC006. If it takes less time to<br />

process the second comm<strong>and</strong>, the server will respond to this comm<strong>and</strong> first,<br />

even though it was received second. In order to let the client know the response<br />

is for the second comm<strong>and</strong>, the response will include the ABC006 tag.<br />

Client comm<strong>and</strong>s<br />

Most of the IMAP4 comm<strong>and</strong>s must be used in the correct corresponding state<br />

(we define the states in 15.5.2, “IMAP4 states” on page 592), though some of<br />

them can be used in more than one state. The following list shows the<br />

comm<strong>and</strong>s <strong>and</strong> the states in which they are used:<br />

► In any state:<br />

– CAPABILITY: Request a list of functions supported by the server.<br />

– NOOP: Do nothing. This is typically to reset an inactivity autologout timer<br />

on the server.<br />

– LOGOUT: Disconnect from the server.<br />

► In the non-authenticated state:<br />

– AUTHENTICATE mechanism: This comm<strong>and</strong> requests a special<br />

authentication mechanism with an argument from the server. If the server<br />

does not support that mechanism, the server sends an error message.<br />

Valid mechanisms, defined in RFC 1731, include:<br />

KERBEROS_V4<br />

GSSAPI<br />

SKEY<br />

– LOGIN user pass: This comm<strong>and</strong> sends the user name <strong>and</strong> password (in<br />

plain text).<br />

– STARTTLS: Begin TLS negotiation. Note that using TLS with IMAP4 is<br />

defined in RFC 2595.<br />

594 <strong>TCP</strong>/<strong>IP</strong> <strong>Tutorial</strong> <strong>and</strong> <strong>Technical</strong> <strong>Overview</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!