Programming Internet Email

The Authorization State

The POP Authorization State can take many forms and still comply with the standard. In fact, any given POP client or server must only support one type of user authentication. This means, of course, that there may exist standards-compliant POP server and client implementations that cannot communicate. This situation should be avoided by supporting at least the basic username/password authentication mechanism in any new POP implementation.

There are an unlimited number of possible authentication mechanisms in POP, but only two are part of the standard protocol: username/password and the MD5-based APOP command. RFC 1734 proposed an extensible command (AUTH) to enable as many types of authentication as may be found necessary. RFC 1734 is a proposed standard.

Note

You don’t have to support the basic username/password authentication, especially if you are trying to enforce stronger authentication means. As we shall see with the APOP and AUTH commands, their effectiveness is reduced if a user’s mailbox can be accessed by user name/password authentication. In order to ensure interoperability though, we recommend that any POP server implementation allow a mailbox to be accessed by username/password authentication if no other mechanism is selected for that mailbox and that any POP client attempt username/password authentication if the preferred authentication mechanism is supported by the server.

POP clients should attempt to use the authentication mechanism that they ...