IMAP Fetch


This message flow simulates an IMAP session that retrieves a message from a server, and is intended to generate simple IMAP traffic between the MN and the Network Host node.

When control plane protocols are used, the TCP connection is established after Data Start Delay timer expires. The MN initiates the TCP connection, using the Client Port and Server Port defined in the message flow.

  1. The server begins the message sequence by sending the server greeting, indicating that it is ready to receive requests.

  2. The client logs in by sending a user name and password.

  3. The client selects a mailbox, and the server responds with the number of messages in the mailbox (2).

  4. The server continues the response with the message number of the one, in this case, unread message (1).

  5. The server completes the inventory portion of the response with the total number of unread messages (1).

  6. The server continues the response with the mailbox flags.

  7. The server completes the response with the user's mailbox permissions.

  8. The client issues a UID FETCH request for message number 1, and the server responds with the message. The message includes To, From, and Subject headers, and a message body of Zs.

  9. The server completes the FETCH response.

  10. The client issues a LOGOUT, and the server acknowledges the command.

  11. The server terminates the IMAP session.

In the default configuration, the message flow will repeat once per second while the MN session is active. This assumes that the entire flow can be completed in one second. The flow must complete before the next iteration can begin, even if this results in a slower transaction rate.

Modifying the Message Flow

Since IMAP is a text-based protocol, you can easily modify the simulated email message, or import a file to use as the message. If you do modify the message, keep the following rules in mind:

Pipelining can be achieved with IMAP by creating a transaction loop of FETCH requests and responses with the Wait for Response checkbox cleared on the client side. The requests will be successively sent without waiting for server responses.

You can specify that random port numbers, in the IANA specified dynamic range of 49152 — 65535, be used by the client by entering a 0 for the Client Port.