1 <!doctype HTML public "-//W3O//DTD W3 HTML 3.2//EN">
4 <TITLE>Design notes on fetchmail</TITLE>
5 <link rev=made href="mailto:esr@snark.thyrsus.com">
6 <meta name="description" content="Design notes on fetchmail.">
7 <meta name="keywords" content="fetchmail, POP, POP2, POP3, IMAP, remote mail">
10 <table width="100%" cellpadding=0><tr>
11 <td width="30%">Back to <a href="/~esr/index.html">Fetchmail Home Page</a>
12 <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a>
13 <td width="30%" align=right>$Date: 2000/01/03 22:59:48 $
16 <H1 ALIGN=CENTER>Design Notes On Fetchmail</H1>
18 These notes are for the benefit of future hackers and maintainers.
19 The following sections are both functional and narrative, read from
24 A direct ancestor of the fetchmail program was originally authored
25 (under the name popclient) by Carl Harris <ceharris@mal.com>. I took
26 over development in June 1996 and subsequently renamed the program
27 `fetchmail' to reflect the addition of IMAP support. In early
28 November 1996 Carl officially ended support for the last popclient
31 Before accepting responsibility for the popclient sources from Carl, I
32 had investigated and used and tinkered with every other UNIX
33 remote-mail forwarder I could find, including fetchpop1.9,
34 PopTart-0.9.3, get-mail, gwpop, pimp-1.0, pop-perl5-1.2, popc,
35 popmail-1.6 and upop. My major goal was to get a header-rewrite
36 feature like fetchmail's working so I wouldn't have reply problems
39 Despite having done a good bit of work on fetchpop1.9, when I found
40 popclient I quickly concluded that it offered the solidest base for
41 future development. I was convinced of this primarily by the presence
42 of multiple-protocol support. The competition didn't do
43 POP2/RPOP/APOP, and I was already having vague thoughts of maybe
44 adding IMAP. (This would advance two other goals: learn IMAP and get
45 comfortable writing TCP/IP client software.)<P>
47 Until popclient 3.05 I was simply following out the implications of
48 Carl's basic design. He already had daemon.c in the distribution,
49 and I wanted daemon mode almost as badly as I wanted the header
50 rewrite feature. The other things I added were bug fixes or
53 After 3.1, when I put in SMTP-forwarding support (more about this
54 below) the nature of the project changed -- it became a
55 carefully-thought-out attempt to render obsolete every other program
56 in its class. The name change quickly followed.<P>
58 <H1>The rewrite option</H1>
60 RFC 1123 stipulates that MTAs ought to canonicalize the addresses of
61 outgoing mail so that From:, To:, Cc:, Bcc: and other address headers
62 contain only fully qualified domain names. Failure to do so can break
63 the reply function on many mailers.<P>
65 This problem only becomes obvious when a reply is generated on a
66 machine different from where the message was delivered. The
67 two machines will have different local username spaces, potentially
68 leading to misrouted mail.<P>
70 Most MTAs (and sendmail in particular) do not canonicalize address headers
71 in this way (violating RFC 1123). Fetchmail therefore has to do it. This
72 is the first feature I added to the ancestral popclient.<P>
74 <H1>Reorganization</H1>
76 The second thing I did reorganize and simplify popclient a lot. Carl
77 Harris's implementation was very sound, but exhibited a kind of
78 unnecessary complexity common to many C programmers. He treated the
79 code as central and the data structures as support for the code. As a
80 result, the code was beautiful but the data structure design ad-hoc
81 and rather ugly (at least to this old LISP hacker).<P>
83 I was able to improve matters significantly by reorganizing most of the
84 program around the `query' data structure and eliminating a bunch of
85 global context. This especially simplified the main sequence in
86 fetchmail.c and was critical in enabling the daemon mode changes.<P>
88 <H1>IMAP support and the method table</H1>
90 The next step was IMAP support. I initially wrote the IMAP code
91 as a generic query driver and a method table. The idea was to have
92 all the protocol-independent setup logic and flow of control in the
93 driver, and the protocol-specific stuff in the method table.<P>
95 Once this worked, I rewrote the POP3 code to use the same organization.
96 The POP2 code kept its own driver for a couple more releases, until
97 I found sources of a POP2 server to test against (the breed seems
98 to be nearly extinct).<P>
100 The purpose of this reorganization, of course, is to trivialize
101 the development of support for future protocols as much as possible.
102 All mail-retrieval protocols have to have pretty similar logical
103 design by the nature of the task. By abstracting out that common
104 logic and its interface to the rest of the program, both the common
105 and protocol-specific parts become easier to understand.<P>
107 Furthermore, many kinds of new features can instantly be supported
108 across all protocols by modifying the one driver module.<P>
110 <H1>Implications of smtp forwarding</H1>
112 The direction of the project changed radically when Harry Hochheiser
113 sent me his scratch code for forwarding fetched mail to the SMTP port.
114 I realized almost immediately that a reliable implementation of this
115 feature would make all the other delivery modes obsolete.<P>
117 Why mess with all the complexity of configuring an MDA or setting up
118 lock-and-append on a mailbox when port 25 is guaranteed to be there on
119 any platform with TCP/IP support in the first place? Especially when
120 this means retrieved mail is guaranteed to look like normal sender-
121 initiated SMTP mail, which is really what we want anyway.<P>
123 Clearly, the right thing to do was (1) hack SMTP forwarding support
124 into the generic driver, (2) make it the default mode, and (3) eventually
125 throw out all the other delivery modes. <P>
127 I hesitated over step 3 for some time, fearing to upset long-time
128 popclient users dependent on the alternate delivery mechanisms. In
129 theory, they could immediately switch to .forward files or their
130 non-sendmail equivalents to get the same effects. In practice the
131 transition might have been messy.<P>
133 But when I did it (see the NEWS note on the great options massacre)
134 the benefits proved huge. The cruftiest parts of the driver code
135 vanished. Configuration got radically simpler -- no more grovelling
136 around for the system MDA and user's mailbox, no more worries about
137 whether the underlying OS supports file locking.<P>
139 Also, the only way to lose mail vanished. If you specified localfolder
140 and the disk got full, your mail got lost. This can't happen with
141 SMTP forwarding because your SMTP listener won't return OK unless
142 the message can be spooled or processed.<P>
144 Also, performance improved (though not so you'd notice it in a single
145 run). Another not insignificant benefit of this change was that the
146 manual page got a lot simpler.<P>
148 Later, I had to bring --mda back in order to allow handling of some
149 obscure situations involving dynamic SLIP. But I found a much simpler
152 The moral? Don't hesitate to throw away superannuated features when
153 you can do it without loss of effectiveness. I tanked a couple I'd
154 added myself and have no regrets at all. As Saint-Exupery said,
155 "Perfection [in design] is achieved not when there is nothing more to
156 add, but rather when there is nothing more to take away." This
157 program isn't perfect, but it's trying.<P>
159 <H1>The most-requested features that I will never add, and why not:</H1>
161 <H2>Password encryption in .fetchmailrc</H2>
163 The reason there's no facility to store passwords encrypted in the
164 .fetchmailrc file is because this doesn't actually add protection.<P>
166 Anyone who's acquired the 0600 permissions needed to read your
167 .fetchmailrc file will be able to run fetchmail as you anyway -- and
168 if it's your password they're after, they'd be able to rip the
169 necessary decoder out of the fetchmail code itself to get it.<P>
171 All .fetchmailrc encryption would do is give a false sense of
172 security to people who don't think very hard.<P>
174 <H2>Truly concurrent queries to multiple hosts</H2>
176 Occasionally I get a request for this on "efficiency" grounds. These
177 people aren't thinking either. True concurrency would do nothing to lessen
178 fetchmail's total IP volume. The best it could possibly do is change the
179 usage profile to shorten the duration of the active part of a poll cycle
180 at the cost of increasing its demand on IP volume per unit time.<P>
182 If one could thread the protocol code so that fetchmail didn't block
183 on waiting for a protocol response, but rather switched to trying to
184 process another host query, one might get an efficiency gain (close to
185 constant loading at the single-host level).<P>
187 Fortunately, I've only seldom seen a server that incurred significant
188 wait time on an individual response. I judge the gain from this not
189 worth the hideous complexity increase it would require in the code.<P>
191 <H2>Multiple concurrent instances of fetchmail</H2>
193 Fetchmail locking is on a per-invoking-user because finer-grained
194 locks would be really hard to implement in a portable way. The
195 problem is that you don't want two fetchmails querying the same site
196 for the same remote user at the same time.<P>
198 To handle this optimally, multiple fetchmails would have to associate
199 a system-wide semaphore with each active pair of a remote user and
200 host canonical address. A fetchmail would have to block until getting
201 this semaphore at the start of a query, and release it at the end of a
204 This would be way too complicated to do just for an "it might be nice"
205 feature. Instead, you can run a single root fetchmail polling for
206 multiple users in either single-drop or multidrop mode.<P>
208 The fundamental problem here is how an instance of fetchmail polling
209 host foo can assert that it's doing so in a way visible to all other
210 fetchmails. System V semaphores would be ideal for this purpose, but
211 they're not portable.<P>
213 I've thought about this a lot and roughed up several designs. All are
214 complicated and fragile, with a bunch of the standard problems (what
215 happens if a fetchmail aborts before clearing its semaphore, and how
216 do we recover reliably?).<P>
218 I'm just not satisfied that there's enough functional gain here to pay
219 for the large increase in complexity that adding these semaphores
222 <H1>Multidrop and alias handling</H1>
224 I decided to add the multidrop support partly because some users were
225 clamoring for it, but mostly because I thought it would shake bugs out
226 of the single-drop code by forcing me to deal with addressing in full
227 generality. And so it proved.<P>
229 There are two important aspects of the features for handling
230 multiple-drop aliases and mailing lists which future hackers should be
231 careful to preserve.<P>
235 The logic path for single-recipient mailboxes doesn't involve header
236 parsing or DNS lookups at all. This is important -- it means the code
237 for the most common case can be much simpler and more robust.<P>
240 The multidrop handing does <EM>not</EM> rely on doing the equivalent of
241 passing the message to sendmail -oem -t. Instead, it explicitly mines
242 members of a specified set of local usernames out of the header.<P>
245 We do <EM>not</EM> attempt delivery to multidrop mailboxes in the presence
246 of DNS errors. Before each multidrop poll we probe DNS to see if we have a
247 nameserver handy. If not, the poll is skipped. If DNS crashes during a
248 poll, the error return from the next nameserver lookup aborts message
249 delivery and ends the poll. The daemon mode will then quietly spin until
250 DNS comes up again, at which point it will resume delivering mail.
253 When I designed this support, I was terrified of doing anything that could
254 conceivably cause a mail loop (you should be too). That's why the code
255 as written can only append <EM>local</EM> names (never @-addresses) to the
258 The code in mxget.c is nasty, no two ways about it. But it's utterly
259 necessary, there are a lot of MX pointers out there. It really ought
260 to be a (documented!) entry point in the bind library.<P>
262 <H1>DNS error handling</H1>
264 Fetchmail's behavior on DNS errors is to suppress forwarding and
265 deletion of the individual message that each occurs in, leaving it
266 queued on the server for retrieval on a subsequent poll. The
267 assumption is that DNS errors are transient, due to temporary server
270 Unfortunately this means that if a DNS error is permanent a message
271 can be perpetually stuck in the server mailbox. We've had a couple
272 bug reports of this kind due to subtle RFC822 parsing errors in the fetchmail
273 code that resulted in impossible things getting passed to the DNS lookup
276 Alternative ways to handle the problem: ignore DNS errors (treating
277 them as a non-match on the mailserver domain), or forward messages
278 with errors to fetchmail's invoking user in addition to any other
279 recipients. These would fit an assumption that DNS lookup errors are
280 likely to be permanent problems associated with an address.<P>
282 <H1>IPv6 and IPSEC</H1>
284 The IPv6 support patches are really more protocol-family independence
285 patches. Because of this, in most places, "ports" (numbers) have been
286 replaced with "services" (strings, that may be digits). This allows us
287 to run with certain protocols that use strings as "service names"
288 where we in the IP world think of port numbers. Someday we'll plumb
289 strings all over and then, if inet6 is not enabled, do a
290 getservbyname() down in SocketOpen. The IPv6 support patches use
291 getaddrinfo(), which is a POSIX p1003.1g mandated function. So, in the
292 not too distant future, we'll zap the ifdefs and just let autoconf
293 check for getaddrinfo. IPv6 support comes pretty much automatically
294 once you have protocol family independence.<P>
296 <H1>Internationalization</H1>
298 Internationalization is handled using GNU gettext (see the file
299 ABOUT_NLS in the source distribution). This places some
300 minor constraints on the code.<P>
302 Strings that must be subject to translation should be wrapped with _()
303 or N_() -- the former in functuib arguments, the latter in static
304 initializers and other non-function-argument contexts.<p>
308 <H1>Checklist for Adding Options</H1>
310 Adding a control option is not complicated in principle, but there are
311 a lot of fiddly details in the process. You'll need to do the
312 following minimum steps.
315 <LI>Add a field to represent the control in <code>struct run</code>,
316 <code>struct query</code>, or <code>struct hostdata</code>.
318 <LI>Go to <code>rcfile_y.y</code>. Add the token to the grammar. Don't
319 forget the <code>%token</code> declaration.
321 <LI>Pick an actual string to declare the option in the .fetchmailrc file. Add
322 the token to <code>rcfile_l</code>.
324 <LI>Pick a long-form option name, and a one-letter short option if any
325 are left. Go to <code>options.c</code>. Pick a new <code>LA_</code>
326 value. Hack the <code>longoptions</code> table to set up the
327 association. Hack the big switch statement to set the option.
328 Hack the `?' message to describe it.
330 <LI>If the default is nonzero, set it in <code>def_opts</code> near the top of
331 <code>load_params</code> in <code>fetchmail.c</code>.
333 <LI>Add code to dump the option value in <code>fetchmail.c:dump_params</code>.
335 <LI>Add proper <code>FLAG_MERGE</code> actions in fetchmail.c's
336 optmerge() function. (If it's a global option, add an override
337 at the end of load_params.)
339 <LI>Document the option in fetchmail.man. This will require at least
340 two changes; one to the collected table of options, and one full
341 text description of the option.
343 <LI>Add the new token and a brief description to the header comment of
346 <LI>Hack fetchmailconf to configure it. Bump the fetchmailconf version.
348 <LI>Hack conf.c to dump the option so we won't have a version-skew problem.
350 <LI>Add an entry to NEWS.
353 There may be other things you have to do in the way of logic, of course.<P>
355 Before you implement an option, though, think hard. Is there any way
356 to make fetchmail automatically detect the circumstances under which
357 it should change its behavior? If so, don't write an option. Just do
360 <H1>Lessons learned</H1>
362 <H3>1. Server-side state is essential</H3>
364 The person(s) responsible for removing LAST from POP3 deserve to suffer.
365 Without it, a client has no way to know which messages in a box have been
366 read by other means, such as an MUA running on the server.<P>
368 The POP3 UID feature described in RFC1725 to replace LAST is
369 insufficient. The only problem it solves is tracking which messages
370 have been read <EM>by this client</EM> -- and even that requires
371 tricky, fragile implementation.<P>
373 The underlying lesson is that maintaining accessible server-side
374 `seen' state bits associated with Status headers is indispensible in a
375 Unix/RFC822 mail server protocol. IMAP gets this right.<P>
377 <H3>2. Readable text protocol transactions are a Good Thing</H3>
379 A nice thing about the general class of text-based protocols that SMTP,
380 POP2, POP3, and IMAP belongs to is that client/server transactions are
381 easy to watch and transaction code correspondingly easy to debug. Given
382 a decent layer of socket utility functions (which Carl provided) it's
383 easy to write protocol engines and not hard to show that they're working
386 This is an advantage not to be despised! Because of it, this project has
387 been interesting and fun -- no serious or persistent bugs, no long
388 hours spent looking for subtle pathologies.<P>
390 <H3>3. IMAP is a Good Thing.</H3>
392 If there were a standard IMAP equivalent of the POP3 APOP validation,
393 POP3 would be completely obsolete.<P>
395 <H3>4. SMTP is the Right Thing</H3>
397 In retrospect it seems clear that this program (and others like it)
398 should have been designed to forward via SMTP from the beginning.
399 This lesson may be applicable to other Unix programs that now call the
400 local MDA/MTA as a program.<P>
402 <H3>5. Syntactic noise can be your friend</H3>
404 The optional `noise' keywords in the rc file syntax started out as
405 a late-night experiment. The English-like syntax they allow is
406 considerably more readable than the traditional terse keyword-value
407 pairs you get when you strip them all out. I think there may be a
408 wider lesson here.<P>
410 <H1>Motivation and validation</H1>
412 It is truly written: the best hacks start out as personal solutions to
413 the author's everyday problems, and spread because the problem turns
414 out to be typical for a large class of users. So it was with Carl Harris
415 and the ancestral popclient, and so with me and fetchmail.<P>
417 It's gratifying that fetchmail has become so popular. Until just before
418 1.9 I was designing strictly to my own taste. The multi-drop mailbox
419 support and the new --limit option were the first features to go in that
420 I didn't need myself.<P>
422 By 1.9, four months after I started hacking on popclient and a month
423 after the first fetchmail release, there were literally a hundred
424 people on the fetchmail-friends contact list. That's pretty powerful
425 motivation. And they were a good crowd, too, sending fixes and
426 intelligent bug reports in volume. A user population like that is
427 a gift from the gods, and this is my expression of gratitude.<P>
429 The beta testers didn't know it at the time, but they were also the
430 subjects of a sociological experiment. The results are described in
432 HREF="//www.tuxedo.org/~esr/writings/cathedral-bazaar/">The Cathedral
433 And The Bazaar</A>.<P>
437 Special thanks go to Carl Harris, who built a good solid code base
438 and then tolerated me hacking it out of recognition. And to Harry
439 Hochheiser, who gave me the idea of the SMTP-forwarding delivery mode.<P>
441 Other significant contributors to the code have included Dave Bodenstab
442 (error.c code and --syslog), George Sipe (--monitor and --interface),
443 Gordon Matzigkeit (netrc.c), Al Longyear (UIDL support), Chris
444 Hanson (Kerberos V4 support), and Craig Metz (OPIE, IPv6, IPSEC).<P>
448 At this point, the fetchmail code appears to be pretty stable.
449 It will probably undergo substantial change only if and when support
450 for a new retrieval protocol or authentication method is added.<P>
452 <H1>Relevant RFCS</H1>
454 Not all of these describe standards explicitly used in fetchmail, but they
455 all shaped the design in one way or another.<P>
458 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc821.txt">RFC821</A>
460 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc822.txt">RFC822</A>
461 <DD> Mail header format
462 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc937.txt">RFC937</A>
463 <DD> Post Office Protocol - Version 2
464 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc974.txt">RFC974</A>
466 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc976.txt">RFC976</A>
467 <DD> UUCP mail format
468 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1081.txt">RFC1081</A>
469 <DD> Post Office Protocol - Version 3
470 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1123.txt">RFC1123</A>
471 <DD> Host requirements (modifies 821, 822, and 974)
472 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1176.txt">RFC1176</A>
473 <DD> Interactive Mail Access Protocol - Version 2
474 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1203.txt">RFC1203</A>
475 <DD> Interactive Mail Access Protocol - Version 3
476 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1225.txt">RFC1225</A>
477 <DD> Post Office Protocol - Version 3
478 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1344.txt">RFC1344</A>
479 <DD> Implications of MIME for Internet Mail Gateways
480 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1413.txt">RFC1413</A>
481 <DD> Identification server
482 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1428.txt">RFC1428</A>
483 <DD> Transition of Internet Mail from Just-Send-8 to 8-bit SMTP/MIME
484 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1460.txt">RFC1460</A>
485 <DD> Post Office Protocol - Version 3
486 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1521.txt">RFC1521</A>
487 <DD> MIME: Multipurpose Internet Mail Extensions
488 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1869.txt">RFC1869</A>
489 <DD> SMTP Service Extensions (ESMTP spec)
490 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1652.txt">RFC1652</A>
491 <DD> SMTP Service Extension for 8bit-MIMEtransport
492 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1725.txt">RFC1725</A>
493 <DD> Post Office Protocol - Version 3
494 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1730.txt">RFC1730</A>
495 <DD> Interactive Mail Access Protocol - Version 4
496 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1731.txt">RFC1731</A>
497 <DD> IMAP4 Authentication Mechanisms
498 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1732.txt">RFC1732</A>
499 <DD> IMAP4 Compatibility With IMAP2 And IMAP2bis
500 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1734.txt">RFC1734</A>
501 <DD> POP3 AUTHentication command
502 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1870.txt">RFC1870</A>
503 <DD> SMTP Service Extension for Message Size Declaration
504 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1891.txt">RFC1891</A>
505 <DD> SMTP Service Extension for Delivery Status Notifications
506 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1892.txt">RFC1892</A>
507 <DD> The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
508 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1894.txt">RFC1894</A>
509 <DD>An Extensible Message Format for Delivery Status Notifications
510 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1893.txt">RFC1893</A>
511 <DD> Enhanced Mail System Status Codes
512 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1894.txt">RFC1894</A>
513 <DD> An Extensible Message Format for Delivery Status Notifications
514 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1938.txt">RFC1938</A>
515 <DD> A One-Time Password System
516 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1939.txt">RFC1939</A>
517 <DD> Post Office Protocol - Version 3
518 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc1985.txt">RFC1985</A>
519 <DD> SMTP Service Extension for Remote Message Queue Starting
520 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc2033.txt">RFC2033</A>
521 <DD> Local Mail Transfer Protocol
522 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc2060.txt">RFC2060</A>
523 <DD> Internet Message Access Protocol - Version 4rev1
524 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc2061.txt">RFC2061</A>
525 <DD> IMAP4 Compatibility With IMAP2bis
526 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc2062.txt">RFC2062</A>
527 <DD> Internet Message Access Protocol - Obsolete Syntax
528 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc2195.txt">RFC2449</A>
529 <DD> IMAP/POP AUTHorize Extension for Simple Challenge/Response
530 <DT><A HREF="ftp://ftp.isi.edu/in-notes/rfc2449.txt">RFC2449</A>
531 <DD> POP3 Extension Mechanism
535 <table width="100%" cellpadding=0><tr>
536 <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a>
537 <td width="30%" align=center>To <a href="/~esr/sitemap.html">Site Map</a>
538 <td width="30%" align=right>$Date: 2000/01/03 22:59:48 $
541 <P><ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com"><esr@snark.thyrsus.com></A></ADDRESS>
projects / ~andy / fetchmail / blob