Programming Internet Email

The Nonauthenticated State

All ACAP sessions begin in the Nonauthenticated State. The client cannot issue most commands until properly authenticating to the server. This is done by the client issuing the AUTHENTICATE command.

Like IMAP’s AUTHENTICATE command and POP’s AUTH command, ACAP’s AUTHENTICATE command can be extended as necessary by implementing new authentication mechanisms. ACAP servers, as we have seen, advertise the mechanisms that they support. It is up to the client to choose a valid mechanism from the list.^[19]

ACAP authentication is generally done with the Challenge-Response Authentication Mechanism (CRAM) described in RFC 2195. Since this mechanism uses MD5 digesting, this is commonly called CRAM-MD5. This mechanism is also used by some IMAP and POP servers. It provides a better authentication capability than plain text username/password schemes since no unencrypted passwords need to be stored on a server or transmitted in the clear via the Internet.

There is generally no simple authentication mechanism in ACAP, although a server and client could implement one. This is due to the supposition that ACAP servers are to be used to store personal information in an Internet environment, so stronger authentication is preferred. All ACAP implementations are required by the proposed standard to implement at least CRAM-MD5 authentication.

A complete discussion of the CRAM-MD5 algorithms is beyond the scope of a book on email. However, take note that CRAM-MD5 requires that the ...