Browse Prior Art Database

Post Office Protocol - Version 3 (RFC1725)

IP.com Disclosure Number: IPCOM000003973D
Original Publication Date: 1994-Nov-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 15 page(s) / 32K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Myers: AUTHOR [+2]

Abstract

On certain types of smaller nodes in the Internet it is often impractical to maintain a message transport system (MTS). For example, a workstation may not have sufficient resources (cycles, disk space) in order to permit a SMTP server [RFC821] and associated local mail delivery system to be kept resident and continuously running. Similarly, it may be expensive (or impossible) to keep a personal computer interconnected to an IP-style network for long amounts of time (the node is lacking the resource known as "connectivity").

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 9% of the total text.

Network Working Group J. Myers

Request for Comments: 1725 Carnegie Mellon

Obsoletes: 1460 M. Rose

Category: Standards Track Dover Beach Consulting, Inc.

November 1994

Post Office Protocol - Version 3

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Overview

This memo is a revision to RFC 1460, a Draft Standard. It makes the

following changes from that document:

- removed text regarding "split-UA model", which didn't add

anything to the understanding of POP

- clarified syntax of commands, keywords, and arguments

- clarified behavior on broken connection

- explicitly permitted an inactivity autologout timer

- clarified the requirements of the "exclusive-access lock"

- removed implementation-specific wording regarding the parsing of

the maildrop

- allowed servers to close the connection after a failed

authentication command

- removed the LAST command

- fixed typo in example of TOP command

- clarified that the second argument to the TOP command is non-

negative

- added the optional UIDL command

- added warning regarding length of shared secrets with APOP

- added additional warnings to the security considerations section

1. Introduction

On certain types of smaller nodes in the Internet it is often

impractical to maintain a message transport system (MTS). For

example, a workstation may not have sufficient resources (cycles,

disk space) in order to permit a SMTP server [RFC821] and associated

local mail delivery system to be kept resident and continuously

running. Similarly, it may be expensive (or impossible) to keep a

personal computer interconnected to an IP-style network for long

amounts of time (the node is lacking the resource known as

"connectivity").

Despite this, it is often very useful to be able to manage mail on

these smaller nodes, and they often support a user agent (UA) to aid

the tasks of mail handling. To solve this problem, a node which can

support an MTS entity offers a maildrop service to these less endowed

nodes. The Post Office Protocol - Version 3 (POP3) is intended to

permit a workstation to dynamically access a maildrop on a server

host in a useful fashion. Usually, this means that the POP3 is used

to allow a workstation to retrieve mail that the server is holding

for it.

For the remainder of this memo, the term "client host" refers to a

host making use of the POP3 serv...