Some Observations on Implementations of the Post Office Protocol (POP3)
Implementation observations about POP3 server and client behavior.
Nelson, R., "Some Observations on Implementations of the Post Office Protocol (POP3)", RFC 1957, DOI 10.17487/RFC1957, June 1996, <https://www.rfc-editor.org/info/rfc1957>.
@misc{rfc1957,
series = {Request for Comments},
number = 1957,
howpublished = {RFC 1957},
publisher = {RFC Editor},
doi = {10.17487/RFC1957},
url = {https://www.rfc-editor.org/info/rfc1957},
author = {R. Nelson},
title = {{Some Observations on Implementations of the Post Office Protocol (POP3)}},
pagetotal = 2,
year = 1996,
month = jun,
} RFC text
Contents
Network Working Group R. Nelson
Request for Comments: 1957 Crynwr Software
Updates: 1939 June 1996
Category: Informational
Some Observations on Implementations
of the Post Office Protocol (POP3)
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Observations
Sometimes an implementation is mistaken for a standard. POP3 servers
and clients are no exception. The widely-used UCB POP3 server,
popper, which has been further developed by Qualcomm, always has
additional information following the status indicator. So, the
status indicator always has a space following it. Two POP3 clients
have been observed to expect that space, and fail when it has not
been found. The RFC does not require the space, hence this memo.
These clients are the freely copyable Unix "popclient" and the
proprietary "netApp Systems Internet Series". The authors of both of
these have been contacted, and new releases will not expect the
space, but old versions should be supported.
In addition, two popular clients require optional parts of the RFC.
Netscape requires UIDL, and Eudora requires TOP.
The optional APOP authentication command has not achieved wide
penetration yet. Newer versions of the Qualcomm POP server implement
it. Known client implementations of APOP include GNU Emacs VM client
and Eudora Lite and Eudora Pro.
Security Considerations
Security issues are not discussed in this memo.
References
[1] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996.
Author's Address
Russell Nelson
Crynwr Software
521 Pleasant Valley Rd.
Potsdam, NY 13676
Phone: +1.315.268.1925
FAX: +1.315.268.9201
EMail: nelson@crynwr.com
ISO Plain Language
On this page
§1Implementation Differences
RFC 1957 warns that a widely used implementation can be mistaken for the standard. It reports cases where POP3 clients expected particular server behavior that RFC 1939 did not require.
The memo documents these observations for people implementing or maintaining POP3 software. It does not specify an Internet standard.
Software can develop habits that the written rules never required. This memo describes several such habits in POP3.
§2Space After the Status Indicator
The UCB POP3 server called popper always placed a space after its status indicator. Two clients were observed to expect that space and fail when it was absent, although RFC 1939 did not require it.
The client authors were contacted, and new releases would not expect the space. The memo says old versions should still be supported.
Some clients failed unless a server included an extra space. The protocol rules did not require the space, but older clients still needed support.
§3Optional Commands and APOP
The memo reports that Netscape required the optional UIDL command and Eudora required the optional TOP command. This illustrates how a feature marked optional in a specification may still matter for compatibility with a particular client.
It also says APOP had not achieved wide penetration at the time. The memo lists some server and client implementations that supported APOP.
Some clients depended on commands labeled optional. The memo also notes that APOP support existed but was not widespread at the time.