aboutsummaryrefslogtreecommitdiffstats
path: root/website/index.html
blob: 95d8ade41706de3ba0a17b3e2179ddbf2080d89e (plain)
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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<link rel="stylesheet" href="sitestyle.css" type="text/css">
<meta name="description" content="The Fetchmail Project">
<meta name="keywords" content="fetchmail, pop3, imap, email, mail">
<meta name="MSSmartTagsPreventParsing" content="TRUE">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Fetchmail</title>
</head>
<body>

<div id="Header">
<table width="100%" cellpadding="0" summary="Canned page header">
<tr>
<td>Fetchmail</td>
<td align="right"><!-- update date -->2023-01-04</td>
</tr>
</table>
</div>

<div id="Menu">
	<hr>
	<a href="index.html" title="Main">Main</a><br>
	<a href="fetchmail-features.html">Features</a><br>
	<a href="fetchmail-man.html">Manual</a><br>
	<a href="fetchmail-FAQ.html" title="Fetchmail FAQ">FAQ</a><br>
	<a href="fetchmail-FAQ.pdf" title="Fetchmail FAQ as PDF">FAQ (PDF)</a><br>
	<a href="design-notes.html">Design Notes</a><br>
	<a
	    href="https://sourceforge.net/projects/fetchmail/files/branch_6.4/">Download</a><br>
	<a href="security.html">Security/Errata</a><br>
	<a href="https://gitlab.com/fetchmail/fetchmail/">Development</a><br>
	<a href="https://sourceforge.net/projects/fetchmail/">Project Page</a><br>
	<hr>
</div>

<div id="Content">

<img src="bighand.png" width="100" height="71" alt="logo: a hand presenting an envelope" align="right">

<h1>Fetchmail</h1>

<div style="background-color:#c0ffc0;color:#000000;">
    <h1>NEWS: FETCHMAIL 6.4.35 RELEASE</h1>
    <p>On 2023-01-04, <a 
    href="https://sourceforge.net/projects/fetchmail/files/branch_6.4/">fetchmail 
    6.4.35 has been released.</a> It updates translations and bumps SSL/TLS library version requirements.</p>
    <p>OpenSSL 1.1.1s and 3.0.7 and wolfSSL 5.5.1 (or newer on the respective 
    compatible branches - note that OpenSSL 1.1.1q and 3.0.6 were withdrawn) 
    remain supported.</p>
    <p>6.4.34 fixed a critical softbounce bug (courtesy of Horváth Zsolt) and updates translations.
    <p>6.4.33 updated translations.</p>
    <p>6.4.32 updated translations and finds both rst2html5 with and without .py suffix when rebuilding the distribution.</p>
    <p>6.4.31 updated the configure script for --with-ssl properly identifying the right
    OpenSSL on a system with multiple OpenSSL versions installed, and updates the
    manual page and its HTML conversion process, and adds some error checking to the .netrc parser.</p>
    <p>6.4.30 updated the Romanian translation (courtesy of Remus-Gabriel 
    Chelu).</p>
    <p>6.4.29 updated the Vietnamese translation (courtesy of Trần Ngọc Quân).</p>
    <p>6.4.28 updated the Spanish translation (courtesy of Cristian Othón Martínez 
    Vera) and added a fix to the manual page (courtesy of Jeremy Petch).</p>
    <p>6.4.26 added a wolfSSL compatibility workaround and updated the Serbian translation (courtesy of Miroslav Nikoli&#263;).</p>
    <p>6.4.25 (released 2021-12-10) updated translations and the manual page and several other documentation 
    files, adds preliminary wolfSSL 5.0 support on systems that provide a C99 
    compiler, fixed up a specific fix for a compatibility issue 
    with the end-of-life OpenSSL 1.0.2 around the expiry of the DST Root CA X3 
    certificate which impairs connectivity to Let's-Encrypt-certified sites. 
    Supported OpenSSL versions 1.1.1 and newer are unaffected.</p>
    <p>Note that you should use a supported OpenSSL version, currently 1.1.1 or 
    3.0. wolfSSL 5.0 support is currently considered experimental.</p>
        <p>Also note that OpenSSL's licensing changed between 1.1.1 and 3.0.0, the 
    latter now uses the Apache License 2.0. See the file COPYING for 
    details.</p>
    <h1>NEWS: FETCHMAIL 6.5.0.beta8 release</h1>
     <p>On 2022-10-16, <a 
    href="https://sourceforge.net/projects/fetchmail/files/branch_6.5/">fetchmail 
    6.5.0.beta8 has been released (click this link to download, or to see recent changes).</a>
     It brings the 6.5.0 betas back in line with the 6.4.28...6.4.34 developments including the critical softbounce fix,
     makes the code C99 and also valid C++, renames --auth ssh to --auth 
     implicit, refines netrc parsing and documents the format (may change 
     before 6.5.0 release!). Note that lzip as compression is discontinued, 
     fetchmail ships as .tar.xz.</p>
</div>

<div style="background-color:#ffe0c0;color:#000000;font-size:85%">
  <h1 id="security-alerts">SECURITY ALERTS</h1>
    <p>These have been moved <a href="security.html">to a separate
	page (click here for security information)</a> to unclutter the
    front page.

<p style="font-size:100%"><strong>Please <a
	href="https://sourceforge.net/projects/fetchmail/files/branch_6.4/">update
	to the newest fetchmail version</a>.</strong></p>

</div>

<h1>What fetchmail does:</h1>

<p>Fetchmail is a full-featured, robust, well-documented
remote-mail retrieval and forwarding utility intended to be used over
on-demand TCP/IP links (such as SLIP or PPP connections). It supports
every remote-mail protocol now in use on the Internet: POP2, POP3,
RPOP, APOP, KPOP, all flavors of IMAP, ETRN, and ODMR. It can even
support IPv6 and IPSEC.</p>

<p>Fetchmail retrieves mail from remote mail servers and forwards it via
SMTP, so it can then be read by normal mail user agents such as <a
href="http://www.mutt.org/">mutt</a>, elm(1) or BSD Mail.
It allows all your system MTA's filtering, forwarding, and aliasing
facilities to work just as they would on normal mail.</p>

<p>Fetchmail offers better protection against password-sniffing than any
other Unix remote-mail client.  It supports APOP, KPOP, OTP, Compuserve
RPA, Microsoft NTLM, and IMAP RFC1731 encrypted authentication methods
including CRAM-MD5 to avoid sending passwords en clair. It can be
configured to support end-to-end encryption via tunneling with <a
href="https://www.openssh.com/">ssh, the Secure Shell</a>.</p>

<p>Fetchmail can be used as a POP/IMAP-to-SMTP gateway for an entire DNS
domain, collecting mail from a single drop box on an ISP and
SMTP-forwarding it based on header addresses. (We don't really
recommend this, though, as it may lose important envelope-header
information.  ETRN or a UUCP connection is better.)</p>

<p>Fetchmail can be started automatically and silently as a system daemon
at boot time.  When running in this mode with a short poll interval,
it is pretty hard for anyone to tell that the incoming mail link is
not a full-time "push" connection.</p>

<p>Fetchmail is easy to configure.  You can edit its dotfile directly, or
use the interactive GUI configurator (fetchmailconf) supplied with the
fetchmail distribution.  It is also directly supported in linuxconf
versions 1.16r8 and later.</p>

<p>Fetchmail is <a href="https://opensource.org">open-source</a>
and <a href="https://www.gnu.org/philosophy/free-sw.html">free
software</a>.</p>

<h1>Where to find out more about fetchmail:</h1>

<p>See the <a href="fetchmail-features.html">Fetchmail Feature List</a> for more
about what fetchmail does.</p>

<p>See the on-line <a href="fetchmail-man.html">manual page</a> for
basics.</p>

<p>See the <a href="fetchmail-FAQ.html">HTML Fetchmail FAQ</a> for
troubleshooting help.</p>

<p>See the <a href="design-notes.html">Fetchmail Design Notes</a>
for discussion of some of the design choices in fetchmail.</p>

<p>See the project's <a href="todo.html">To-Do list</a> for indications
of known problems and requested features.</p>

<p>The developers use <a href="https://git-scm.com/">Git</a> for revision
control.  To browse the repository or to get the latest development version,
find the instructions at <a
				 href="https://gitlab.com/fetchmail/fetchmail">https://gitlab.com/fetchmail/fetchmail</a>. The <a href="fetchmail-FAQ.html#G2">fetchmail FAQ in section G2 lists the widely-known and active branches.</a></p>

<p>See the <a href="https://sourceforge.net/projects/fetchmail/">project
page</a> for more, including <a
href="https://sourceforge.net/projects/fetchmail/files/branch_6.4/">downloads</a>.</p>

<h1>Getting help with fetchmail:</h1>

<p>Before submitting a question anywhere, <strong>please read the <a
href="fetchmail-FAQ.html">FAQ</a></strong> (especially item <a
href="fetchmail-FAQ.html#G3">G3</a> on how to report problems).  We tend to get
the same three newbie questions over and over again.  The FAQ covers them like
a blanket.</p>

<p>There is a fetchmail-users list for help and other user discussion
of fetchmail.  It's a MailMan list, which you can sign up for at <a
href="https://sourceforge.net/projects/fetchmail/lists/fetchmail-users">
fetchmail-users@lists.sourceforge.net</a>. 
<br>There is also a
fetchmail-devel list for people who want to discuss fixes and
improvements in fetchmail and help co-develop it.  That one is at <a
href="https://sourceforge.net/projects/fetchmail/lists/fetchmail-devel">
fetchmail-devel@lists.sourceforge.net</a>.
<br>Finally, there is a low-traffic announcements-only list, <a
href="https://sourceforge.net/projects/fetchmail/lists/fetchmail-announce">
fetchmail-announce@lists.sourceforge.net</a>.</p>

<h1>Maintainer History</h1>
<p>Fetchmail originated as a program called <i>popclient</i>, written
by Carl Harris.  In 1996, <a href="http://www.catb.org/~esr/">Eric
S. Raymond</a> took over; he soon renamed the program to fetchmail after
adding IMAP support.</p>
<p>In 2004 a new team took over, led by <a
href="https://sourceforge.net/u/robfunk/profile/">Rob Funk</a>,
Graham Wilson, and <a
href="https://sourceforge.net/u/m-a/profile/">Matthias Andree</a>. Since then,
Graham Wilson has retreated, and Sunil Shetye has
contributed several important pieces of code.</p>

<h1>You can help improve fetchmail:</h1>

<p>We welcome your code contributions.  But even if you don't write code,
you can help fetchmail improve.</p>

<p><strong>If you administer a site that runs a post-office server, you may be
able help improve fetchmail by lending us a test account on your site.
Note that we do not need a shell account for this purpose, just a 
mailbox and a mail address.  Nor are we interested in collecting maildrops per
se -- what we're collecting is different <em>kinds of servers</em>.</strong></p>

<p>Before each release, we run a test harness that sends date-stamped 
test mail to each site on our regression-test list, then tries to
retrieve it.  Please take a look at the <a href="testservers.html">
list of test servers</a>.  If you can lend us an account on a kind
of server that is <em>not</em> already on this list, please do.</p>

<h1>Where you can use fetchmail:</h1>

<p>The fetchmail code was developed under Linux, but has also been
extensively tested under 4.4BSD, SunOS, Solaris, AIX, and NEXTSTEP.  It
should be readily portable to other Unix variants (it requires only
POSIX plus BSD sockets, and uses GNU autoconf).</p>

<p>Fetchmail is supported only for Unix by its official maintainers.
However, it is reported to build and run correctly under BeOS,
AmigaOS, Rhapsody, and QNX as well.  There is a CygWin port.</p>

<h1>Related works</h1>

<h2>Similar software</h2>

<p><strong>fdm:</strong> A software package that integrates basic filtering is 
<a href="https://github.com/nicm/fdm">Nicholas Marriott's fdm</a>.

<p><strong>getmail:</strong> When fetchmail's development was
stalled before the latest team took over, <a
href="http://pyropus.ca/software/getmail/">Charles Cazabon's getmail</a> came
along as an intended replacement.  It still doesn't do everything that
fetchmail does, and often suffers from Python library shortcomings, for
instance when it comes to SSL, but it's close enough to give us a bit of
competition.
<br>There is also an <a href="https://getmail6.org/">inofficial unsanctioned 
  fork called getmail6</a> with adaptations to work with Python 3.</p>

<p><strong>animail:</strong> Another contender with integrated filtering was, but is currently unmaintained, <a href="https://github.com/juanjux/animail">Juanjo &Aacute;lvarez Mart&iacute;nez's Animail</a>.</p>

<h2>Complementary and extension software</h2>

<p><a
href="https://sourceforge.net/projects/getlive/">GetLive</a>, a successor to 
the discontinued Gotmail. (Gotmail was a script to fetch mail from Hotmail, 
written by Peter Hawkins, which used to live at the now defunct 
http://linux.cudeso.be/linuxdoc/gotmail.php)</p>

<p>There's a program called
<a href="http://mailfilter.sourceforge.net/">mailfilter</a> which can be used
to do spam filtering, that works particularly well called from fetchmail's
<code>preconnect</code> directive.</p>

</div>

</body>
</html>
al gain here to pay for the large increase in complexity that adding these semaphores would entail.</p> <h1>Multidrop and alias handling</h1> <p>I decided to add the multidrop support partly because some users were clamoring for it, but mostly because I thought it would shake bugs out of the single-drop code by forcing me to deal with addressing in full generality. And so it proved.</p> <p>There are two important aspects of the features for handling multiple-drop aliases and mailing lists which future hackers should be careful to preserve.</p> <ol> <li> <p>The logic path for single-recipient mailboxes doesn't involve header parsing or DNS lookups at all. This is important -- it means the code for the most common case can be much simpler and more robust.</p> </li> <li> <p>The multidrop handing does <em>not</em> rely on doing the equivalent of passing the message to sendmail -t. Instead, it explicitly mines members of a specified set of local usernames out of the header.</p> </li> <li> <p>We do <em>not</em> attempt delivery to multidrop mailboxes in the presence of DNS errors. Before each multidrop poll we probe DNS to see if we have a nameserver handy. If not, the poll is skipped. If DNS crashes during a poll, the error return from the next nameserver lookup aborts message delivery and ends the poll. The daemon mode will then quietly spin until DNS comes up again, at which point it will resume delivering mail.</p> </li> </ol> <p>When I designed this support, I was terrified of doing anything that could conceivably cause a mail loop (you should be too). That's why the code as written can only append <em>local</em> names (never @-addresses) to the recipients list.</p> <p>The code in mxget.c is nasty, no two ways about it. But it's utterly necessary, there are a lot of MX pointers out there. It really ought to be a (documented!) entry point in the bind library.</p> <h1>DNS error handling</h1> <p>Fetchmail's behavior on DNS errors is to suppress forwarding and deletion of the individual message that each occurs in, leaving it queued on the server for retrieval on a subsequent poll. The assumption is that DNS errors are transient, due to temporary server outages.</p> <p>Unfortunately this means that if a DNS error is permanent a message can be perpetually stuck in the server mailbox. We've had a couple bug reports of this kind due to subtle RFC822 parsing errors in the fetchmail code that resulted in impossible things getting passed to the DNS lookup routines.</p> <p>Alternative ways to handle the problem: ignore DNS errors (treating them as a non-match on the mailserver domain), or forward messages with errors to fetchmail's invoking user in addition to any other recipients. These would fit an assumption that DNS lookup errors are likely to be permanent problems associated with an address.</p> <h1>IPv6 and IPSEC</h1> <p>The IPv6 support patches are really more protocol-family independence patches. Because of this, in most places, "ports" (numbers) have been replaced with "services" (strings, that may be digits). This allows us to run with certain protocols that use strings as "service names" where we in the IP world think of port numbers. Someday we'll plumb strings all over and then, if inet6 is not enabled, do a getservbyname() down in SocketOpen. The IPv6 support patches use getaddrinfo(), which is a POSIX p1003.1g mandated function. So, in the not too distant future, we'll zap the ifdefs and just let autoconf check for getaddrinfo. IPv6 support comes pretty much automatically once you have protocol family independence.</p> <h1>Internationalization</h1> <p>Internationalization is handled using GNU gettext (see the file ABOUT_NLS in the source distribution). This places some minor constraints on the code.</p> <p>Strings that must be subject to translation should be wrapped with GT_() or N_() -- the former in function arguments, the latter in static initializers and other non-function-argument contexts.</p> <h1>Checklist for Adding Options</h1> <p>Adding a control option is not complicated in principle, but there are a lot of fiddly details in the process. You'll need to do the following minimum steps.</p> <ul> <li>Add a field to represent the control in <code>struct run</code>, <code>struct query</code>, or <code>struct hostdata</code>.</li> <li>Go to <code>rcfile_y.y</code>. Add the token to the grammar. Don't forget the <code>%token</code> declaration.</li> <li>Pick an actual string to declare the option in the .fetchmailrc file. Add the token to <code>rcfile_l</code>.</li> <li>Pick a long-form option name, and a one-letter short option if any are left. Go to <code>options.c</code>. Pick a new <code>LA_</code> value. Hack the <code>longoptions</code> table to set up the association. Hack the big switch statement to set the option. Hack the `?' message to describe it.</li> <li>If the default is nonzero, set it in <code>def_opts</code> near the top of <code>load_params</code> in <code>fetchmail.c</code>.</li> <li>Add code to dump the option value in <code>fetchmail.c:dump_params</code>.</li> <li>For a per-site or per-user option, add proper <code>FLAG_MERGE</code> actions in fetchmail.c's optmerge() function. For a global option, add an override at the end of load_params; this will involve copying a "cmd_run." field to a corresponding "run." field, see the existing code for models.</li> <li>Document the option in fetchmail.man. This will require at least two changes; one to the collected table of options, and one full text description of the option.</li> <li>Hack fetchmailconf to configure it. Bump the fetchmailconf version.</li> <li>Hack conf.c to dump the option so we won't have a version-skew problem.</li> <li>Add an entry to NEWS.</li> <li>If the option implements a new feature, add a note to the feature list.</li> </ul> <p>There may be other things you have to do in the way of logic, of course.</p> <p>Before you implement an option, though, think hard. Is there any way to make fetchmail automatically detect the circumstances under which it should change its behavior? If so, don't write an option. Just do the check!</p> <h1>Lessons learned</h1> <h3>1. Server-side state is essential</h3> <p>The person(s) responsible for removing LAST from POP3 deserve to suffer. Without it, a client has no way to know which messages in a box have been read by other means, such as an MUA running on the server.</p> <p>The POP3 UID feature described in RFC1725 to replace LAST is insufficient. The only problem it solves is tracking which messages have been read <em>by this client</em> -- and even that requires tricky, fragile implementation.</p> <p>The underlying lesson is that maintaining accessible server-side `seen' state bits associated with Status headers is indispensible in a Unix/RFC822 mail server protocol. IMAP gets this right.</p> <h3>2. Readable text protocol transactions are a Good Thing</h3> <p>A nice thing about the general class of text-based protocols that SMTP, POP2, POP3, and IMAP belongs to is that client/server transactions are easy to watch and transaction code correspondingly easy to debug. Given a decent layer of socket utility functions (which Carl provided) it's easy to write protocol engines and not hard to show that they're working correctly.</p> <p>This is an advantage not to be despised! Because of it, this project has been interesting and fun -- no serious or persistent bugs, no long hours spent looking for subtle pathologies.</p> <h3>3. IMAP is a Good Thing.</h3> <p>Now that there is a standard IMAP equivalent of the POP3 APOP validation in CRAM-MD5, POP3 is completely obsolete.</p> <h3>4. SMTP is the Right Thing</h3> <p>In retrospect it seems clear that this program (and others like it) should have been designed to forward via SMTP from the beginning. This lesson may be applicable to other Unix programs that now call the local MDA/MTA as a program.</p> <h3>5. Syntactic noise can be your friend</h3> <p>The optional `noise' keywords in the rc file syntax started out as a late-night experiment. The English-like syntax they allow is considerably more readable than the traditional terse keyword-value pairs you get when you strip them all out. I think there may be a wider lesson here.</p> <h1>Motivation and validation</h1> <p>It is truly written: the best hacks start out as personal solutions to the author's everyday problems, and spread because the problem turns out to be typical for a large class of users. So it was with Carl Harris and the ancestral popclient, and so with me and fetchmail.</p> <p>It's gratifying that fetchmail has become so popular. Until just before 1.9 I was designing strictly to my own taste. The multi-drop mailbox support and the new --limit option were the first features to go in that I didn't need myself.</p> <p>By 1.9, four months after I started hacking on popclient and a month after the first fetchmail release, there were literally a hundred people on the fetchmail-friends contact list. That's pretty powerful motivation. And they were a good crowd, too, sending fixes and intelligent bug reports in volume. A user population like that is a gift from the gods, and this is my expression of gratitude.</p> <p>The beta testers didn't know it at the time, but they were also the subjects of a sociological experiment. The results are described in my paper, <a href="//www.catb.org/~esr/writings/cathedral-bazaar/">The Cathedral And The Bazaar</a>.</p> <h1>Credits</h1> <p>Special thanks go to Carl Harris, who built a good solid code base and then tolerated me hacking it out of recognition. And to Harry Hochheiser, who gave me the idea of the SMTP-forwarding delivery mode.</p> <p>Other significant contributors to the code have included Dave Bodenstab (error.c code and --syslog), George Sipe (--monitor and --interface), Gordon Matzigkeit (netrc.c), Al Longyear (UIDL support), Chris Hanson (Kerberos V4 support), and Craig Metz (OPIE, IPv6, IPSEC).</p> <h1>Conclusion</h1> <p>At this point, the fetchmail code appears to be pretty stable. It will probably undergo substantial change only if and when support for a new retrieval protocol or authentication method is added.</p> <h1>Relevant RFCS</h1> <p>Not all of these describe standards explicitly used in fetchmail, but they all shaped the design in one way or another.</p> <dl> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc821.txt">RFC821</a></dt> <dd>SMTP protocol</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc822.txt">RFC822</a></dt> <dd>Mail header format</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc937.txt">RFC937</a></dt> <dd>Post Office Protocol - Version 2</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc974.txt">RFC974</a></dt> <dd>MX routing</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc976.txt">RFC976</a></dt> <dd>UUCP mail format</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1081.txt">RFC1081</a></dt> <dd>Post Office Protocol - Version 3</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1123.txt">RFC1123</a></dt> <dd>Host requirements (modifies 821, 822, and 974)</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1176.txt">RFC1176</a></dt> <dd>Interactive Mail Access Protocol - Version 2</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1203.txt">RFC1203</a></dt> <dd>Interactive Mail Access Protocol - Version 3</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1225.txt">RFC1225</a></dt> <dd>Post Office Protocol - Version 3</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1344.txt">RFC1344</a></dt> <dd>Implications of MIME for Internet Mail Gateways</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1413.txt">RFC1413</a></dt> <dd>Identification server</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1428.txt">RFC1428</a></dt> <dd>Transition of Internet Mail from Just-Send-8 to 8-bit SMTP/MIME</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1460.txt">RFC1460</a></dt> <dd>Post Office Protocol - Version 3</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1508.txt">RFC1508</a></dt> <dd>Generic Security Service Application Program Interface</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1521.txt">RFC1521</a></dt> <dd>MIME: Multipurpose Internet Mail Extensions</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1869.txt">RFC1869</a></dt> <dd>SMTP Service Extensions (ESMTP spec)</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1652.txt">RFC1652</a></dt> <dd>SMTP Service Extension for 8bit-MIMEtransport</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1725.txt">RFC1725</a></dt> <dd>Post Office Protocol - Version 3</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1730.txt">RFC1730</a></dt> <dd>Interactive Mail Access Protocol - Version 4</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1731.txt">RFC1731</a></dt> <dd>IMAP4 Authentication Mechanisms</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1732.txt">RFC1732</a></dt> <dd>IMAP4 Compatibility With IMAP2 And IMAP2bis</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1734.txt">RFC1734</a></dt> <dd>POP3 AUTHentication command</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1870.txt">RFC1870</a></dt> <dd>SMTP Service Extension for Message Size Declaration</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1891.txt">RFC1891</a></dt> <dd>SMTP Service Extension for Delivery Status Notifications</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1892.txt">RFC1892</a></dt> <dd>The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1894.txt">RFC1894</a></dt> <dd>An Extensible Message Format for Delivery Status Notifications</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1893.txt">RFC1893</a></dt> <dd>Enhanced Mail System Status Codes</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1894.txt">RFC1894</a></dt> <dd>An Extensible Message Format for Delivery Status Notifications</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1938.txt">RFC1938</a></dt> <dd>A One-Time Password System</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1939.txt">RFC1939</a></dt> <dd>Post Office Protocol - Version 3</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1957.txt">RFC1957</a></dt> <dd>Some Observations on Implementations of the Post Office Protocol (POP3)</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc1985.txt">RFC1985</a></dt> <dd>SMTP Service Extension for Remote Message Queue Starting</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2033.txt">RFC2033</a></dt> <dd>Local Mail Transfer Protocol</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2060.txt">RFC2060</a></dt> <dd>Internet Message Access Protocol - Version 4rev1</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2061.txt">RFC2061</a></dt> <dd>IMAP4 Compatibility With IMAP2bis</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2062.txt">RFC2062</a></dt> <dd>Internet Message Access Protocol - Obsolete Syntax</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2195.txt">RFC2195</a></dt> <dd>IMAP/POP AUTHorize Extension for Simple Challenge/Response</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2177.txt">RFC2177</a></dt> <dd>IMAP IDLE command</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2449.txt">RFC2449</a></dt> <dd>POP3 Extension Mechanism</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2554.txt">RFC2554</a></dt> <dd>SMTP Service Extension for Authentication</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2595.txt">RFC2595</a></dt> <dd>Using TLS with IMAP, POP3 and ACAP</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2645.txt">RFC2645</a></dt> <dd>On-Demand Mail Relay: SMTP with Dynamic IP Addresses</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2683.txt">RFC2683</a></dt> <dd>IMAP4 Implementation Recommendations</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2821.txt">RFC2821</a></dt> <dd>Simple Mail Transfer Protocol</dd> <dt><a href="ftp://ftp.isi.edu/in-notes/rfc2822.txt">RFC2822</a></dt> <dd>Internet Message Format</dd> </dl> <!-- RFC2192 IMAP URL Scheme RFC2193 IMAP4 Mailbox Referrals RFC2221 IMAP4 Login Referrals --> <h1>Other useful documents</h1> <dl> <dt><a href="http://www.faqs.org/faqs/LANs/mail-protocols/">http://www.faqs.org/faqs/LANs/mail-protocols/</a></dt> <dd>LAN Mail Protocols Summary</dd> </dl> <hr /> <table width="100%" cellpadding="0" summary="Canned page footer"> <tr> <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a></td> <td width="30%" align="right">$Date$</td> </tr> </table> <br clear="left" /> <address>Eric S. Raymond <a href="mailto:esr@thyrsus.com">&lt;esr@snark.thyrsus.com&gt;</a></address> </body> </html>