1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
The fetchmail announcement
fetchmail is a full-featured, robust, well-documented POP2, POP3,
APOP, and IMAP batch mail retrieval/forwarding utility intended to be
used over on-demand TCP/IP links (such as SLIP or PPP connections).
It retrieves mail from remote mail servers and forwards it to your
local (client) machine's delivery system, so it can then be be read by
normal mail user agents such as elm(1) or Mail(1).
The fetchmail code was developed under Linux, but should be readily
portable to other Unix variants (it uses GNU autoconf). It has also
been ported to QNX; to build under QNX, see the header comments in the
Makefile.
The fetchmail program was originally authored (under the name
popclient) by Carl Harris <ceharris@mal.com>. I, Eric S. Raymond,
<esr@thyrsus.com> took over development in June 1996. I subsequently
renamed the program `fetchmail' to reflect the addition of IMAP
support. See the distribution files NEWS for detailed information on
recent changes and NOTES for design notes.
Before accepting responsibility for the popclient sources from Carl, I
had investigated and used and tinkered with every other UNIX
remote-mail forwarder I could find, including fetchpop1.9,
PopTart-0.9.3, get-mail, gwpop, pimp-1.0, pop-perl5-1.2, popc,
popmail-1.6 and upop. I learned from all of them, and fetchmail is a
carefully-thought-out attempt to render obsolete every other program
in its class.
Here are fetchmail's main features. Those unique to fetchmail are marked
with **.
* **POP2, POP3, **APOP, **RPOP and **IMAP support.
** Host is auto-probed for a working server if no protocol is
specified for the connection. Thus you don't need to know
what servers are running on your mail host in advance; the
verbose option will tell you which one succeeds.
** Delivery via via SMTP to the client machine's port 25. This
means the retrieved mail automatically goes to the system
default MDA as if it were normal sender-initiated SMTP mail.
** Timeout if server connection is dropped.
* Easy control via command line or free-format run control file.
* Daemon mode -- fetchmail can be run in background to poll
one or more hosts at a specified interval.
* From:, To:, Cc:, and Reply-To: headers are rewritten so that
usernames relative to the fetchmail host become fully-qualified
Internet addresses. This enables replies to work correctly.
(Would be unique to fetchmail if I hadn't added it to fetchpop.)
* Strict conformance to relevant RFCs and good debugging options.
You could use fetchmail to test and debug server implementatations.
* Carefully written, comprehensive and up-to-date man page describing
not only modes of operation but also (**) how to interpret the most
common kinds of problems and what to do about deficient servers
* Rugged, simple, and well-tested code -- the author relies on it
every day and it has never lost mail, not even in experimental
versions.
* Large user community -- fetchmail has inherited a significant
user base from Carl Harris's popclient community. This means
feedback is rapid, bugs get found and fixed rapidly.
At this point, the fetchmail code appears to be stable and bug-free.
It will probably undergo substantial change only if and when support
for a new retrieval protocol or IMAP extensions are added.
You can easily find the latest version of fetchmail from Eric's home page:
http://www.ccil.org/~esr
Just chase the link to Eric's Freeware Collection. Besides fetchmail, it
includes a tasty selection of Web authoring tools, programmer's aids,
graphics libraries, compilers for bizarre languages, games, and
miscellaneous interesting hacks. Enjoy!
-- esr
|
