Pileus Git - ~andy/fetchmail/blob - design-notes.html

   1 <?xml version="1.0" encoding="ISO-8859-1"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   3     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   4 <html xmlns="http://www.w3.org/1999/xhtml">
   5 <head>
   6 <title>Design notes on fetchmail</title>
   7 <link rev="made" href="mailto:esr@snark.thyrsus.com" />
   8 <meta name="description" content="Design notes on fetchmail." />
   9 <meta name="keywords" content="fetchmail, POP, POP2, POP3, IMAP, remote mail" />
  10 <style type="text/css">
  11 /*<![CDATA[*/
  12  h1.c1 {text-align: center}
  13 /*]]>*/
  14 </style>
  15 </head>
  16 <body>
  17 <table width="100%" cellpadding="0" summary="Canned page header">
  18 <tr>
  19 <td width="30%">Back to <a href="/~esr/index.html">Fetchmail Home Page</a></td>
  20 <td width="30%" align="center">To <a href="/~esr/sitemap.html">Site Map</a></td>
  21 <td width="30%" align="right">$Date: 2002/07/30 13:31:18 $</td>
  22 </tr>
  23 </table>
  24
  25 <hr />
  26 <h1 class="c1">Design Notes On Fetchmail</h1>
  27
  28 <p>These notes are for the benefit of future hackers and
  29 maintainers. The following sections are both functional and
  30 narrative, read from beginning to end.</p>
  31
  32 <h1>History</h1>
  33
  34 <p>A direct ancestor of the fetchmail program was originally
  35 authored (under the name popclient) by Carl Harris
  36 &lt;ceharris@mal.com&gt;. I took over development in June 1996 and
  37 subsequently renamed the program `fetchmail' to reflect the
  38 addition of IMAP support and SMTP delivery. In early November 1996
  39 Carl officially ended support for the last popclient versions.</p>
  40
  41 <p>Before accepting responsibility for the popclient sources from
  42 Carl, I had investigated and used and tinkered with every other
  43 UNIX remote-mail forwarder I could find, including fetchpop1.9,
  44 PopTart-0.9.3, get-mail, gwpop, pimp-1.0, pop-perl5-1.2, popc,
  45 popmail-1.6 and upop. My major goal was to get a header-rewrite
  46 feature like fetchmail's working so I wouldn't have reply problems
  47 anymore.</p>
  48
  49 <p>Despite having done a good bit of work on fetchpop1.9, when I
  50 found popclient I quickly concluded that it offered the solidest
  51 base for future development. I was convinced of this primarily by
  52 the presence of multiple-protocol support. The competition didn't
  53 do POP2/RPOP/APOP, and I was already having vague thoughts of maybe
  54 adding IMAP. (This would advance two other goals: learn IMAP and
  55 get comfortable writing TCP/IP client software.)</p>
  56
  57 <p>Until popclient 3.05 I was simply following out the implications
  58 of Carl's basic design. He already had daemon.c in the
  59 distribution, and I wanted daemon mode almost as badly as I wanted
  60 the header rewrite feature. The other things I added were bug fixes
  61 or minor extensions.</p>
  62
  63 <p>After 3.1, when I put in SMTP-forwarding support (more about
  64 this below) the nature of the project changed -- it became a
  65 carefully-thought-out attempt to render obsolete every other
  66 program in its class. The name change quickly followed.</p>
  67
  68 <h1>The rewrite option</h1>
  69
  70 <p>MTAs ought to canonicalize the addresses of outgoing non-local
  71 mail so that From:, To:, Cc:, Bcc: and other address headers
  72 contain only fully qualified domain names. Failure to do so can
  73 break the reply function on many mailers. (Sendmail has an option
  74 to do this.)</p>
  75
  76 <p>This problem only becomes obvious when a reply is generated on a
  77 machine different from where the message was delivered. The two
  78 machines will have different local username spaces, potentially
  79 leading to misrouted mail.</p>
  80
  81 <p>Most MTAs (and sendmail in particular) do not canonicalize
  82 address headers in this way (violating RFC 1123). Fetchmail
  83 therefore has to do it. This is the first feature I added to the
  84 ancestral popclient.</p>
  85
  86 <h1>Reorganization</h1>
  87
  88 <p>The second thing I did reorganize and simplify popclient a lot.
  89 Carl Harris's implementation was very sound, but exhibited a kind
  90 of unnecessary complexity common to many C programmers. He treated
  91 the code as central and the data structures as support for the
  92 code. As a result, the code was beautiful but the data structure
  93 design ad-hoc and rather ugly (at least to this old LISP
  94 hacker).</p>
  95
  96 <p>I was able to improve matters significantly by reorganizing most
  97 of the program around the `query' data structure and eliminating a
  98 bunch of global context. This especially simplified the main
  99 sequence in fetchmail.c and was critical in enabling the daemon
 100 mode changes.</p>
 101
 102 <h1>IMAP support and the method table</h1>
 103
 104 <p>The next step was IMAP support. I initially wrote the IMAP code
 105 as a generic query driver and a method table. The idea was to have
 106 all the protocol-independent setup logic and flow of control in the
 107 driver, and the protocol-specific stuff in the method table.</p>
 108
 109 <p>Once this worked, I rewrote the POP3 code to use the same
 110 organization. The POP2 code kept its own driver for a couple more
 111 releases, until I found sources of a POP2 server to test against
 112 (the breed seems to be nearly extinct).</p>
 113
 114 <p>The purpose of this reorganization, of course, is to trivialize
 115 the development of support for future protocols as much as
 116 possible. All mail-retrieval protocols have to have pretty similar
 117 logical design by the nature of the task. By abstracting out that
 118 common logic and its interface to the rest of the program, both the
 119 common and protocol-specific parts become easier to understand.</p>
 120
 121 <p>Furthermore, many kinds of new features can instantly be
 122 supported across all protocols by modifying the one driver
 123 module.</p>
 124
 125 <h1>Implications of smtp forwarding</h1>
 126
 127 <p>The direction of the project changed radically when Harry
 128 Hochheiser sent me his scratch code for forwarding fetched mail to
 129 the SMTP port. I realized almost immediately that a reliable
 130 implementation of this feature would make all the other delivery
 131 modes obsolete.</p>
 132
 133 <p>Why mess with all the complexity of configuring an MDA or
 134 setting up lock-and-append on a mailbox when port 25 is guaranteed
 135 to be there on any platform with TCP/IP support in the first place?
 136 Especially when this means retrieved mail is guaranteed to look
 137 like normal sender- initiated SMTP mail, which is really what we
 138 want anyway.</p>
 139
 140 <p>Clearly, the right thing to do was (1) hack SMTP forwarding
 141 support into the generic driver, (2) make it the default mode, and
 142 (3) eventually throw out all the other delivery modes.</p>
 143
 144 <p>I hesitated over step 3 for some time, fearing to upset
 145 long-time popclient users dependent on the alternate delivery
 146 mechanisms. In theory, they could immediately switch to .forward
 147 files or their non-sendmail equivalents to get the same effects. In
 148 practice the transition might have been messy.</p>
 149
 150 <p>But when I did it (see the NEWS note on the great options
 151 massacre) the benefits proved huge. The cruftiest parts of the
 152 driver code vanished. Configuration got radically simpler -- no
 153 more grovelling around for the system MDA and user's mailbox, no
 154 more worries about whether the underlying OS supports file
 155 locking.</p>
 156
 157 <p>Also, the only way to lose mail vanished. If you specified
 158 localfolder and the disk got full, your mail got lost. This can't
 159 happen with SMTP forwarding because your SMTP listener won't return
 160 OK unless the message can be spooled or processed.</p>
 161
 162 <p>Also, performance improved (though not so you'd notice it in a
 163 single run). Another not insignificant benefit of this change was
 164 that the manual page got a lot simpler.</p>
 165
 166 <p>Later, I had to bring --mda back in order to allow handling of
 167 some obscure situations involving dynamic SLIP. But I found a much
 168 simpler way to do it.</p>
 169
 170 <p>The moral? Don't hesitate to throw away superannuated features
 171 when you can do it without loss of effectiveness. I tanked a couple
 172 I'd added myself and have no regrets at all. As Saint-Exupery said,
 173 "Perfection [in design] is achieved not when there is nothing more
 174 to add, but rather when there is nothing more to take away." This
 175 program isn't perfect, but it's trying.</p>
 176
 177 <h1>The most-requested features that I will never add, and why
 178 not:</h1>
 179
 180 <h2>Password encryption in .fetchmailrc</h2>
 181
 182 <p>The reason there's no facility to store passwords encrypted in
 183 the .fetchmailrc file is because this doesn't actually add
 184 protection.</p>
 185
 186 <p>Anyone who's acquired the 0600 permissions needed to read your
 187 .fetchmailrc file will be able to run fetchmail as you anyway --
 188 and if it's your password they're after, they'd be able to rip the
 189 necessary decoder out of the fetchmail code itself to get it.</p>
 190
 191 <p>All .fetchmailrc encryption would do is give a false sense of
 192 security to people who don't think very hard.</p>
 193
 194 <h2>Truly concurrent queries to multiple hosts</h2>
 195
 196 <p>Occasionally I get a request for this on "efficiency" grounds.
 197 These people aren't thinking either. True concurrency would do
 198 nothing to lessen fetchmail's total IP volume. The best it could
 199 possibly do is change the usage profile to shorten the duration of
 200 the active part of a poll cycle at the cost of increasing its
 201 demand on IP volume per unit time.</p>
 202
 203 <p>If one could thread the protocol code so that fetchmail didn't
 204 block on waiting for a protocol response, but rather switched to
 205 trying to process another host query, one might get an efficiency
 206 gain (close to constant loading at the single-host level).</p>
 207
 208 <p>Fortunately, I've only seldom seen a server that incurred
 209 significant wait time on an individual response. I judge the gain
 210 from this not worth the hideous complexity increase it would
 211 require in the code.</p>
 212
 213 <h2>Multiple concurrent instances of fetchmail</h2>
 214
 215 <p>Fetchmail locking is on a per-invoking-user because
 216 finer-grained locks would be really hard to implement in a portable
 217 way. The problem is that you don't want two fetchmails querying the
 218 same site for the same remote user at the same time.</p>
 219
 220 <p>To handle this optimally, multiple fetchmails would have to
 221 associate a system-wide semaphore with each active pair of a remote
 222 user and host canonical address. A fetchmail would have to block
 223 until getting this semaphore at the start of a query, and release
 224 it at the end of a query.</p>
 225
 226 <p>This would be way too complicated to do just for an "it might be
 227 nice" feature. Instead, you can run a single root fetchmail polling
 228 for multiple users in either single-drop or multidrop mode.</p>
 229
 230 <p>The fundamental problem here is how an instance of fetchmail
 231 polling host foo can assert that it's doing so in a way visible to
 232 all other fetchmails. System V semaphores would be ideal for this
 233 purpose, but they're not portable.</p>
 234
 235 <p>I've thought about this a lot and roughed up several designs.
 236 All are complicated and fragile, with a bunch of the standard
 237 problems (what happens if a fetchmail aborts before clearing its
 238 semaphore, and how do we recover reliably?).</p>
 239
 240 <p>I'm just not satisfied that there's enough functional gain here
 241 to pay for the large increase in complexity that adding these
 242 semaphores would entail.</p>
 243
 244 <h1>Multidrop and alias handling</h1>
 245
 246 <p>I decided to add the multidrop support partly because some users
 247 were clamoring for it, but mostly because I thought it would shake
 248 bugs out of the single-drop code by forcing me to deal with
 249 addressing in full generality. And so it proved.</p>
 250
 251 <p>There are two important aspects of the features for handling
 252 multiple-drop aliases and mailing lists which future hackers should
 253 be careful to preserve.</p>
 254
 255 <ol>
 256 <li>
 257 <p>The logic path for single-recipient mailboxes doesn't involve
 258 header parsing or DNS lookups at all. This is important -- it means
 259 the code for the most common case can be much simpler and more
 260 robust.</p>
 261 </li>
 262
 263 <li>
 264 <p>The multidrop handing does <em>not</em> rely on doing the
 265 equivalent of passing the message to sendmail -oem -t. Instead, it
 266 explicitly mines members of a specified set of local usernames out
 267 of the header.</p>
 268 </li>
 269
 270 <li>
 271 <p>We do <em>not</em> attempt delivery to multidrop mailboxes in
 272 the presence of DNS errors. Before each multidrop poll we probe DNS
 273 to see if we have a nameserver handy. If not, the poll is skipped.
 274 If DNS crashes during a poll, the error return from the next
 275 nameserver lookup aborts message delivery and ends the poll. The
 276 daemon mode will then quietly spin until DNS comes up again, at
 277 which point it will resume delivering mail.</p>
 278 </li>
 279 </ol>
 280
 281 <p>When I designed this support, I was terrified of doing anything
 282 that could conceivably cause a mail loop (you should be too).
 283 That's why the code as written can only append <em>local</em> names
 284 (never @-addresses) to the recipients list.</p>
 285
 286 <p>The code in mxget.c is nasty, no two ways about it. But it's
 287 utterly necessary, there are a lot of MX pointers out there. It
 288 really ought to be a (documented!) entry point in the bind
 289 library.</p>
 290
 291 <h1>DNS error handling</h1>
 292
 293 <p>Fetchmail's behavior on DNS errors is to suppress forwarding and
 294 deletion of the individual message that each occurs in, leaving it
 295 queued on the server for retrieval on a subsequent poll. The
 296 assumption is that DNS errors are transient, due to temporary
 297 server outages.</p>
 298
 299 <p>Unfortunately this means that if a DNS error is permanent a
 300 message can be perpetually stuck in the server mailbox. We've had a
 301 couple bug reports of this kind due to subtle RFC822 parsing errors
 302 in the fetchmail code that resulted in impossible things getting
 303 passed to the DNS lookup routines.</p>
 304
 305 <p>Alternative ways to handle the problem: ignore DNS errors
 306 (treating them as a non-match on the mailserver domain), or forward
 307 messages with errors to fetchmail's invoking user in addition to
 308 any other recipients. These would fit an assumption that DNS lookup
 309 errors are likely to be permanent problems associated with an
 310 address.</p>
 311
 312 <h1>IPv6 and IPSEC</h1>
 313
 314 <p>The IPv6 support patches are really more protocol-family
 315 independence patches. Because of this, in most places, "ports"
 316 (numbers) have been replaced with "services" (strings, that may be
 317 digits). This allows us to run with certain protocols that use
 318 strings as "service names" where we in the IP world think of port
 319 numbers. Someday we'll plumb strings all over and then, if inet6 is
 320 not enabled, do a getservbyname() down in SocketOpen. The IPv6
 321 support patches use getaddrinfo(), which is a POSIX p1003.1g
 322 mandated function. So, in the not too distant future, we'll zap the
 323 ifdefs and just let autoconf check for getaddrinfo. IPv6 support
 324 comes pretty much automatically once you have protocol family
 325 independence.</p>
 326
 327 <h1>Internationalization</h1>
 328
 329 <p>Internationalization is handled using GNU gettext (see the file
 330 ABOUT_NLS in the source distribution). This places some minor
 331 constraints on the code.</p>
 332
 333 <p>Strings that must be subject to translation should be wrapped
 334 with GT_() or N_() -- the former in function arguments, the latter
 335 in static initializers and other non-function-argument
 336 contexts.</p>
 337
 338 <h1>Checklist for Adding Options</h1>
 339
 340 <p>Adding a control option is not complicated in principle, but
 341 there are a lot of fiddly details in the process. You'll need to do
 342 the following minimum steps.</p>
 343
 344 <ul>
 345 <li>Add a field to represent the control in <code>struct
 346 run</code>, <code>struct query</code>, or <code>struct
 347 hostdata</code>.</li>
 348
 349 <li>Go to <code>rcfile_y.y</code>. Add the token to the grammar.
 350 Don't forget the <code>%token</code> declaration.</li>
 351
 352 <li>Pick an actual string to declare the option in the .fetchmailrc
 353 file. Add the token to <code>rcfile_l</code>.</li>
 354
 355 <li>Pick a long-form option name, and a one-letter short option if
 356 any are left. Go to <code>options.c</code>. Pick a new
 357 <code>LA_</code> value. Hack the <code>longoptions</code> table to
 358 set up the association. Hack the big switch statement to set the
 359 option. Hack the `?' message to describe it.</li>
 360
 361 <li>If the default is nonzero, set it in <code>def_opts</code> near
 362 the top of <code>load_params</code> in
 363 <code>fetchmail.c</code>.</li>
 364
 365 <li>Add code to dump the option value in
 366 <code>fetchmail.c:dump_params</code>.</li>
 367
 368 <li>For a per-site or per-user option, add proper
 369 <code>FLAG_MERGE</code> actions in fetchmail.c's optmerge()
 370 function. For a global option, add an override at the end of
 371 load_params; this will involve copying a "cmd_run." field to a
 372 corresponding "run." field, see the existing code for models.</li>
 373
 374 <li>Document the option in fetchmail.man. This will require at
 375 least two changes; one to the collected table of options, and one
 376 full text description of the option.</li>
 377
 378 <li>Hack fetchmailconf to configure it. Bump the fetchmailconf
 379 version.</li>
 380
 381 <li>Hack conf.c to dump the option so we won't have a version-skew
 382 problem.</li>
 383
 384 <li>Add an entry to NEWS.</li>
 385
 386 <li>If the option implements a new feature, add a note to the
 387 feature list.</li>
 388 </ul>
 389
 390 <p>There may be other things you have to do in the way of logic, of
 391 course.</p>
 392
 393 <p>Before you implement an option, though, think hard. Is there any
 394 way to make fetchmail automatically detect the circumstances under
 395 which it should change its behavior? If so, don't write an option.
 396 Just do the check!</p>
 397
 398 <h1>Lessons learned</h1>
 399
 400 <h3>1. Server-side state is essential</h3>
 401
 402 <p>The person(s) responsible for removing LAST from POP3 deserve to
 403 suffer. Without it, a client has no way to know which messages in a
 404 box have been read by other means, such as an MUA running on the
 405 server.</p>
 406
 407 <p>The POP3 UID feature described in RFC1725 to replace LAST is
 408 insufficient. The only problem it solves is tracking which messages
 409 have been read <em>by this client</em> -- and even that requires
 410 tricky, fragile implementation.</p>
 411
 412 <p>The underlying lesson is that maintaining accessible server-side
 413 `seen' state bits associated with Status headers is indispensible
 414 in a Unix/RFC822 mail server protocol. IMAP gets this right.</p>
 415
 416 <h3>2. Readable text protocol transactions are a Good Thing</h3>
 417
 418 <p>A nice thing about the general class of text-based protocols
 419 that SMTP, POP2, POP3, and IMAP belongs to is that client/server
 420 transactions are easy to watch and transaction code correspondingly
 421 easy to debug. Given a decent layer of socket utility functions
 422 (which Carl provided) it's easy to write protocol engines and not
 423 hard to show that they're working correctly.</p>
 424
 425 <p>This is an advantage not to be despised! Because of it, this
 426 project has been interesting and fun -- no serious or persistent
 427 bugs, no long hours spent looking for subtle pathologies.</p>
 428
 429 <h3>3. IMAP is a Good Thing.</h3>
 430
 431 <p>Now that there is a standard IMAP equivalent of the POP3 APOP
 432 validation in CRAM-MD5, POP3 is completely obsolete.</p>
 433
 434 <h3>4. SMTP is the Right Thing</h3>
 435
 436 <p>In retrospect it seems clear that this program (and others like
 437 it) should have been designed to forward via SMTP from the
 438 beginning. This lesson may be applicable to other Unix programs
 439 that now call the local MDA/MTA as a program.</p>
 440
 441 <h3>5. Syntactic noise can be your friend</h3>
 442
 443 <p>The optional `noise' keywords in the rc file syntax started out
 444 as a late-night experiment. The English-like syntax they allow is
 445 considerably more readable than the traditional terse keyword-value
 446 pairs you get when you strip them all out. I think there may be a
 447 wider lesson here.</p>
 448
 449 <h1>Motivation and validation</h1>
 450
 451 <p>It is truly written: the best hacks start out as personal
 452 solutions to the author's everyday problems, and spread because the
 453 problem turns out to be typical for a large class of users. So it
 454 was with Carl Harris and the ancestral popclient, and so with me
 455 and fetchmail.</p>
 456
 457 <p>It's gratifying that fetchmail has become so popular. Until just
 458 before 1.9 I was designing strictly to my own taste. The multi-drop
 459 mailbox support and the new --limit option were the first features
 460 to go in that I didn't need myself.</p>
 461
 462 <p>By 1.9, four months after I started hacking on popclient and a
 463 month after the first fetchmail release, there were literally a
 464 hundred people on the fetchmail-friends contact list. That's pretty
 465 powerful motivation. And they were a good crowd, too, sending fixes
 466 and intelligent bug reports in volume. A user population like that
 467 is a gift from the gods, and this is my expression of
 468 gratitude.</p>
 469
 470 <p>The beta testers didn't know it at the time, but they were also
 471 the subjects of a sociological experiment. The results are
 472 described in my paper, <a
 473 href="//www.tuxedo.org/~esr/writings/cathedral-bazaar/">The
 474 Cathedral And The Bazaar</a>.</p>
 475
 476 <h1>Credits</h1>
 477
 478 <p>Special thanks go to Carl Harris, who built a good solid code
 479 base and then tolerated me hacking it out of recognition. And to
 480 Harry Hochheiser, who gave me the idea of the SMTP-forwarding
 481 delivery mode.</p>
 482
 483 <p>Other significant contributors to the code have included Dave
 484 Bodenstab (error.c code and --syslog), George Sipe (--monitor and
 485 --interface), Gordon Matzigkeit (netrc.c), Al Longyear (UIDL
 486 support), Chris Hanson (Kerberos V4 support), and Craig Metz (OPIE,
 487 IPv6, IPSEC).</p>
 488
 489 <h1>Conclusion</h1>
 490
 491 <p>At this point, the fetchmail code appears to be pretty stable.
 492 It will probably undergo substantial change only if and when
 493 support for a new retrieval protocol or authentication method is
 494 added.</p>
 495
 496 <h1>Relevant RFCS</h1>
 497
 498 <p>Not all of these describe standards explicitly used in
 499 fetchmail, but they all shaped the design in one way or
 500 another.</p>
 501
 502 <dl>
 503 <dt><a href="ftp://ftp.isi.edu/in-notes/rfc821.txt">RFC821</a></dt>
 504
 505 <dd>SMTP protocol</dd>
 506
 507 <dt><a href="ftp://ftp.isi.edu/in-notes/rfc822.txt">RFC822</a></dt>
 508
 509 <dd>Mail header format</dd>
 510
 511 <dt><a href="ftp://ftp.isi.edu/in-notes/rfc937.txt">RFC937</a></dt>
 512
 513 <dd>Post Office Protocol - Version 2</dd>
 514
 515 <dt><a href="ftp://ftp.isi.edu/in-notes/rfc974.txt">RFC974</a></dt>
 516
 517 <dd>MX routing</dd>
 518
 519 <dt><a href="ftp://ftp.isi.edu/in-notes/rfc976.txt">RFC976</a></dt>
 520
 521 <dd>UUCP mail format</dd>
 522
 523 <dt><a
 524 href="ftp://ftp.isi.edu/in-notes/rfc1081.txt">RFC1081</a></dt>
 525
 526 <dd>Post Office Protocol - Version 3</dd>
 527
 528 <dt><a
 529 href="ftp://ftp.isi.edu/in-notes/rfc1123.txt">RFC1123</a></dt>
 530
 531 <dd>Host requirements (modifies 821, 822, and 974)</dd>
 532
 533 <dt><a
 534 href="ftp://ftp.isi.edu/in-notes/rfc1176.txt">RFC1176</a></dt>
 535
 536 <dd>Interactive Mail Access Protocol - Version 2</dd>
 537
 538 <dt><a
 539 href="ftp://ftp.isi.edu/in-notes/rfc1203.txt">RFC1203</a></dt>
 540
 541 <dd>Interactive Mail Access Protocol - Version 3</dd>
 542
 543 <dt><a
 544 href="ftp://ftp.isi.edu/in-notes/rfc1225.txt">RFC1225</a></dt>
 545
 546 <dd>Post Office Protocol - Version 3</dd>
 547
 548 <dt><a
 549 href="ftp://ftp.isi.edu/in-notes/rfc1344.txt">RFC1344</a></dt>
 550
 551 <dd>Implications of MIME for Internet Mail Gateways</dd>
 552
 553 <dt><a
 554 href="ftp://ftp.isi.edu/in-notes/rfc1413.txt">RFC1413</a></dt>
 555
 556 <dd>Identification server</dd>
 557
 558 <dt><a
 559 href="ftp://ftp.isi.edu/in-notes/rfc1428.txt">RFC1428</a></dt>
 560
 561 <dd>Transition of Internet Mail from Just-Send-8 to 8-bit
 562 SMTP/MIME</dd>
 563
 564 <dt><a
 565 href="ftp://ftp.isi.edu/in-notes/rfc1460.txt">RFC1460</a></dt>
 566
 567 <dd>Post Office Protocol - Version 3</dd>
 568
 569 <dt><a
 570 href="ftp://ftp.isi.edu/in-notes/rfc1508.txt">RFC1508</a></dt>
 571
 572 <dd>Generic Security Service Application Program Interface</dd>
 573
 574 <dt><a
 575 href="ftp://ftp.isi.edu/in-notes/rfc1521.txt">RFC1521</a></dt>
 576
 577 <dd>MIME: Multipurpose Internet Mail Extensions</dd>
 578
 579 <dt><a
 580 href="ftp://ftp.isi.edu/in-notes/rfc1869.txt">RFC1869</a></dt>
 581
 582 <dd>SMTP Service Extensions (ESMTP spec)</dd>
 583
 584 <dt><a
 585 href="ftp://ftp.isi.edu/in-notes/rfc1652.txt">RFC1652</a></dt>
 586
 587 <dd>SMTP Service Extension for 8bit-MIMEtransport</dd>
 588
 589 <dt><a
 590 href="ftp://ftp.isi.edu/in-notes/rfc1725.txt">RFC1725</a></dt>
 591
 592 <dd>Post Office Protocol - Version 3</dd>
 593
 594 <dt><a
 595 href="ftp://ftp.isi.edu/in-notes/rfc1730.txt">RFC1730</a></dt>
 596
 597 <dd>Interactive Mail Access Protocol - Version 4</dd>
 598
 599 <dt><a
 600 href="ftp://ftp.isi.edu/in-notes/rfc1731.txt">RFC1731</a></dt>
 601
 602 <dd>IMAP4 Authentication Mechanisms</dd>
 603
 604 <dt><a
 605 href="ftp://ftp.isi.edu/in-notes/rfc1732.txt">RFC1732</a></dt>
 606
 607 <dd>IMAP4 Compatibility With IMAP2 And IMAP2bis</dd>
 608
 609 <dt><a
 610 href="ftp://ftp.isi.edu/in-notes/rfc1734.txt">RFC1734</a></dt>
 611
 612 <dd>POP3 AUTHentication command</dd>
 613
 614 <dt><a
 615 href="ftp://ftp.isi.edu/in-notes/rfc1870.txt">RFC1870</a></dt>
 616
 617 <dd>SMTP Service Extension for Message Size Declaration</dd>
 618
 619 <dt><a
 620 href="ftp://ftp.isi.edu/in-notes/rfc1891.txt">RFC1891</a></dt>
 621
 622 <dd>SMTP Service Extension for Delivery Status Notifications</dd>
 623
 624 <dt><a
 625 href="ftp://ftp.isi.edu/in-notes/rfc1892.txt">RFC1892</a></dt>
 626
 627 <dd>The Multipart/Report Content Type for the Reporting of Mail
 628 System Administrative Messages</dd>
 629
 630 <dt><a
 631 href="ftp://ftp.isi.edu/in-notes/rfc1894.txt">RFC1894</a></dt>
 632
 633 <dd>An Extensible Message Format for Delivery Status
 634 Notifications</dd>
 635
 636 <dt><a
 637 href="ftp://ftp.isi.edu/in-notes/rfc1893.txt">RFC1893</a></dt>
 638
 639 <dd>Enhanced Mail System Status Codes</dd>
 640
 641 <dt><a
 642 href="ftp://ftp.isi.edu/in-notes/rfc1894.txt">RFC1894</a></dt>
 643
 644 <dd>An Extensible Message Format for Delivery Status
 645 Notifications</dd>
 646
 647 <dt><a
 648 href="ftp://ftp.isi.edu/in-notes/rfc1938.txt">RFC1938</a></dt>
 649
 650 <dd>A One-Time Password System</dd>
 651
 652 <dt><a
 653 href="ftp://ftp.isi.edu/in-notes/rfc1939.txt">RFC1939</a></dt>
 654
 655 <dd>Post Office Protocol - Version 3</dd>
 656
 657 <dt><a
 658 href="ftp://ftp.isi.edu/in-notes/rfc1957.txt">RFC1957</a></dt>
 659
 660 <dd>Some Observations on Implementations of the Post Office
 661 Protocol (POP3)</dd>
 662
 663 <dt><a
 664 href="ftp://ftp.isi.edu/in-notes/rfc1985.txt">RFC1985</a></dt>
 665
 666 <dd>SMTP Service Extension for Remote Message Queue Starting</dd>
 667
 668 <dt><a
 669 href="ftp://ftp.isi.edu/in-notes/rfc2033.txt">RFC2033</a></dt>
 670
 671 <dd>Local Mail Transfer Protocol</dd>
 672
 673 <dt><a
 674 href="ftp://ftp.isi.edu/in-notes/rfc2060.txt">RFC2060</a></dt>
 675
 676 <dd>Internet Message Access Protocol - Version 4rev1</dd>
 677
 678 <dt><a
 679 href="ftp://ftp.isi.edu/in-notes/rfc2061.txt">RFC2061</a></dt>
 680
 681 <dd>IMAP4 Compatibility With IMAP2bis</dd>
 682
 683 <dt><a
 684 href="ftp://ftp.isi.edu/in-notes/rfc2062.txt">RFC2062</a></dt>
 685
 686 <dd>Internet Message Access Protocol - Obsolete Syntax</dd>
 687
 688 <dt><a
 689 href="ftp://ftp.isi.edu/in-notes/rfc2195.txt">RFC2195</a></dt>
 690
 691 <dd>IMAP/POP AUTHorize Extension for Simple Challenge/Response</dd>
 692
 693 <dt><a
 694 href="ftp://ftp.isi.edu/in-notes/rfc2177.txt">RFC2177</a></dt>
 695
 696 <dd>IMAP IDLE command</dd>
 697
 698 <dt><a
 699 href="ftp://ftp.isi.edu/in-notes/rfc2449.txt">RFC2449</a></dt>
 700
 701 <dd>POP3 Extension Mechanism</dd>
 702
 703 <dt><a
 704 href="ftp://ftp.isi.edu/in-notes/rfc2554.txt">RFC2554</a></dt>
 705
 706 <dd>SMTP Service Extension for Authentication</dd>
 707
 708 <dt><a
 709 href="ftp://ftp.isi.edu/in-notes/rfc2595.txt">RFC2595</a></dt>
 710
 711 <dd>Using TLS with IMAP, POP3 and ACAP</dd>
 712
 713 <dt><a
 714 href="ftp://ftp.isi.edu/in-notes/rfc2645.txt">RFC2645</a></dt>
 715
 716 <dd>On-Demand Mail Relay: SMTP with Dynamic IP Addresses</dd>
 717
 718 <dt><a
 719 href="ftp://ftp.isi.edu/in-notes/rfc2683.txt">RFC2683</a></dt>
 720
 721 <dd>IMAP4 Implementation Recommendations</dd>
 722
 723 <dt><a
 724 href="ftp://ftp.isi.edu/in-notes/rfc2821.txt">RFC2821</a></dt>
 725
 726 <dd>Simple Mail Transfer Protocol</dd>
 727
 728 <dt><a
 729 href="ftp://ftp.isi.edu/in-notes/rfc2822.txt">RFC2822</a></dt>
 730
 731 <dd>Internet Message Format</dd>
 732 </dl>
 733
 734 <!--
 735 RFC2192 IMAP URL Scheme
 736 RFC2193 IMAP4 Mailbox Referrals
 737 RFC2221 IMAP4 Login Referrals
 738 -->
 739 <hr />
 740 <table width="100%" cellpadding="0" summary="Canned page footer">
 741 <tr>
 742 <td width="30%">Back to <a href="index.html">Fetchmail Home Page</a></td>
 743 <td width="30%" align="center">To <a href="/~esr/sitemap.html">Site Map</a></td>
 744 <td width="30%" align="right">$Date: 2002/07/30 13:31:18 $</td>
 745 </tr>
 746 </table>
 747
 748 <br clear="left" />
 749 <address>Eric S. Raymond <a
 750 href="mailto:esr@thyrsus.com">&lt;esr@snark.thyrsus.com&gt;</a></address>
 751 </body>
 752 </html>
 753