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

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