POP3GET
[/?]
[/BYIP[+|-]]
[/SRV_SUPERDOMAINS[+|-]]
[/SRV_SELF[+|-]]
[/IMPLICIT[+|-]]
[/IP6ADDR[+|-]]
[/CLIENTIP[+|-]]
[/CLIENTPORT[+|-]]
[/DIRECTORY string]
domain
username
password
The POP3GET command connects to a mailbox on a POP3 server, and downloads all messages in that mailbox, writing them to a local directory in the standard mail directory format, removing all successfully downloaded messages from the server. By default, the mail directory used is the current directory.
POP3GET locates servers from the domain string supplied in
the normal way,
using pop3 as the service name, tcp as the
transport name, and 110 as the well-known port number.
POP3GET requires the POP3 server to support the "USER", "PASS", "LIST", "RETR", "DELE", and "QUIT" commands.
In order to allow the passage of a message to be traced, POP3GET prepends
a Received: header to each message that it transfers,
describing its receipt of the article from the source server.
POP3GET issues a "DELE" command for all messages that it (successfully) retrieves, deleting the original messages from the server mailbox.
Amazingly, POP3 servers are allowed, explicitly by the protocol
specification, to delete any messages that have been retrieved, even
unsuccessfully, even if no "DELE" command has been issued, and even as
soon as immediately after the first time that they are retrieved.
(This does not match the behaviour of the Unix System V mail
program whose semantics POP is modelled after, but was a late addition to
the protocol to intentionally provide POP3 service providers the latitude
of throwing away their customers' mail. See
§8 of RFC 1939.)
POP3GET makes no attempt to determine whether a server will do this. (There is a capability flag in the protocol that can be checked.) This is for the simple reason that a successful retrieval by POP3GET implies that a local copy of the message has been transferred to a local mail directory. That is, after all, the very purpose of the tool. POP3GET is a tool for downloading messages from a POP3 server (and placing them somewhere more reliable), not for leaving them there.
For similar reasons, POP3GET will still issue a "QUIT" command even if one or more "RETR" commands have failed. By strict letter of the protocol, "RETR" cannot fail for a program that, like POP3GET does, only attempts to retrieve existing (non-deleted) messages. However, for some POP3 servers, including the POP3 dæmon in the Internet Utilities, it will fail if an IMAP server, or some other program, comes along and expunges a message from an INBOX whilst the POP3 client has that INBOX open. In such circumstances, issuing a "QUIT" command is no loss. The worst that it could do is delete the message, and in that circumstance the message has, in fact, already been deleted (by something else).
Such issues aside, there is nonetheless potential for mail loss in the POP3 protocol even without any involvement of IMAP or any other behind-the-scenes access to a mail folder. There are holes in the protocol itself into which mail can vanish. Clients cannot inform servers when they have successfully stored copies of retrieved messages, and it is possible for a server to think that a client has successfully retrieved a message when the client has in fact been unable to make a local copy. Moreover, the latitude to servers that leads to this state of affairs is explicitly blessed in the protocol specification.
All in all, it is strongly recommended to use IMAP in preference to POP3.
To download messages from the Someone@example.org mailbox on
mailhost.example.org.:
[c:\]pop3get mailhost.example.org. Someone@example.org pass
/DIRECTORY