197 files changed, 124192 insertions, 0 deletions

diff --git a/.cvsignore b/.cvsignore
new file mode 100644
index 00000000..883dc490
--- /dev/null
+++ b/.cvsignore
@@ -0,0 +1,8 @@
+aclocal.m4
+config.h.in
+configure
+config.guess
+config.sub
+install-sh
+mkinstalldirs
+missing
diff --git a/ABOUT-NLS b/ABOUT-NLS
new file mode 100644
index 00000000..28d38c76
--- /dev/null
+++ b/ABOUT-NLS
@@ -0,0 +1,226 @@
+Notes on the Free Translation Project
+*************************************
+
+   Free software is going international!  The Free Translation Project
+is a way to get maintainers of free software, translators, and users all
+together, so that will gradually become able to speak many languages.
+A few packages already provide translations for their messages.
+
+   If you found this `ABOUT-NLS' file inside a distribution, you may
+assume that the distributed package does use GNU `gettext' internally,
+itself available at your nearest GNU archive site.  But you do *not*
+need to install GNU `gettext' prior to configuring, installing or using
+this package with messages translated.
+
+   Installers will find here some useful hints.  These notes also
+explain how users should proceed for getting the programs to use the
+available translations.  They tell how people wanting to contribute and
+work at translations should contact the appropriate team.
+
+   When reporting bugs in the `intl/' directory or bugs which may be
+related to internationalization, you should tell about the version of
+`gettext' which is used.  The information can be found in the
+`intl/VERSION' file, in internationalized packages.
+
+One advise in advance
+=====================
+
+   If you want to exploit the full power of internationalization, you
+should configure it using
+
+     ./configure --with-included-gettext
+
+to force usage of internationalizing routines provided within this
+package, despite the existence of internationalizing capabilities in the
+operating system where this package is being installed.  So far, only
+the `gettext' implementation in the GNU C library version 2 provides as
+many features (such as locale alias or message inheritance) as the
+implementation here.  It is also not possible to offer this additional
+functionality on top of a `catgets' implementation.  Future versions of
+GNU `gettext' will very likely convey even more functionality.  So it
+might be a good idea to change to GNU `gettext' as soon as possible.
+
+   So you need not provide this option if you are using GNU libc 2 or
+you have installed a recent copy of the GNU gettext package with the
+included `libintl'.
+
+INSTALL Matters
+===============
+
+   Some packages are "localizable" when properly installed; the
+programs they contain can be made to speak your own native language.
+Most such packages use GNU `gettext'.  Other packages have their own
+ways to internationalization, predating GNU `gettext'.
+
+   By default, this package will be installed to allow translation of
+messages.  It will automatically detect whether the system provides
+usable `catgets' (if using this is selected by the installer) or
+`gettext' functions.  If neither is available, the GNU `gettext' own
+library will be used.  This library is wholly contained within this
+package, usually in the `intl/' subdirectory, so prior installation of
+the GNU `gettext' package is *not* required.  Installers may use
+special options at configuration time for changing the default
+behaviour.  The commands:
+
+     ./configure --with-included-gettext
+     ./configure --with-catgets
+     ./configure --disable-nls
+
+will respectively bypass any pre-existing `catgets' or `gettext' to use
+the internationalizing routines provided within this package, enable
+the use of the `catgets' functions (if found on the locale system), or
+else, *totally* disable translation of messages.
+
+   When you already have GNU `gettext' installed on your system and run
+configure without an option for your new package, `configure' will
+probably detect the previously built and installed `libintl.a' file and
+will decide to use this.  This might be not what is desirable.  You
+should use the more recent version of the GNU `gettext' library.  I.e.
+if the file `intl/VERSION' shows that the library which comes with this
+package is more recent, you should use
+
+     ./configure --with-included-gettext
+
+to prevent auto-detection.
+
+   By default the configuration process will not test for the `catgets'
+function and therefore they will not be used.  The reasons are already
+given above: the emulation on top of `catgets' cannot provide all the
+extensions provided by the GNU `gettext' library.  If you nevertheless
+want to use the `catgets' functions use
+
+     ./configure --with-catgets
+
+to enable the test for `catgets' (this causes no harm if `catgets' is
+not available on your system).  If you really select this option we
+would like to hear about the reasons because we cannot think of any
+good one ourself.
+
+   Internationalized packages have usually many `po/LL.po' files, where
+LL gives an ISO 639 two-letter code identifying the language.  Unless
+translations have been forbidden at `configure' time by using the
+`--disable-nls' switch, all available translations are installed
+together with the package.  However, the environment variable `LINGUAS'
+may be set, prior to configuration, to limit the installed set.
+`LINGUAS' should then contain a space separated list of two-letter
+codes, stating which languages are allowed.
+
+Using This Package
+==================
+
+   As a user, if your language has been installed for this package, you
+only have to set the `LANG' environment variable to the appropriate
+ISO 639 `LL' two-letter code prior to using the programs in the
+package.  For example, let's suppose that you speak German.  At the
+shell prompt, merely execute `setenv LANG de' (in `csh'),
+`export LANG; LANG=de' (in `sh') or `export LANG=de' (in `bash').  This
+can be done from your `.login' or `.profile' file, once and for all.
+
+   An operating system might already offer message localization for
+many of its programs, while other programs have been installed locally
+with the full capabilities of GNU `gettext'.  Just using `gettext'
+extended syntax for `LANG' would break proper localization of already
+available operating system programs.  In this case, users should set
+both `LANGUAGE' and `LANG' variables in their environment, as programs
+using GNU `gettext' give preference to `LANGUAGE'.  For example, some
+Swedish users would rather read translations in German than English for
+when Swedish is not available.  This is easily accomplished by setting
+`LANGUAGE' to `sv:de' while leaving `LANG' to `sv'.
+
+Translating Teams
+=================
+
+   For the Free Translation Project to be a success, we need interested
+people who like their own language and write it well, and who are also
+able to synergize with other translators speaking the same language.
+Each translation team has its own mailing list, courtesy of Linux
+International.  You may reach your translation team at the address
+`LL@li.org', replacing LL by the two-letter ISO 639 code for your
+language.  Language codes are *not* the same as the country codes given
+in ISO 3166.  The following translation teams exist, as of December
+1997:
+
+     Chinese `zh', Czech `cs', Danish `da', Dutch `nl', English `en',
+     Esperanto `eo', Finnish `fi', French `fr', German `de', Hungarian
+     `hu', Irish `ga', Italian `it', Indonesian `id', Japanese `ja',
+     Korean `ko', Latin `la', Norwegian `no', Persian `fa', Polish
+     `pl', Portuguese `pt', Russian `ru', Slovenian `sl', Spanish `es',
+     Swedish `sv', and Turkish `tr'.
+
+For example, you may reach the Chinese translation team by writing to
+`zh@li.org'.
+
+   If you'd like to volunteer to *work* at translating messages, you
+should become a member of the translating team for your own language.
+The subscribing address is *not* the same as the list itself, it has
+`-request' appended.  For example, speakers of Swedish can send a
+message to `sv-request@li.org', having this message body:
+
+     subscribe
+
+   Keep in mind that team members are expected to participate
+*actively* in translations, or at solving translational difficulties,
+rather than merely lurking around.  If your team does not exist yet and
+you want to start one, or if you are unsure about what to do or how to
+get started, please write to `translation@iro.umontreal.ca' to reach the
+coordinator for all translator teams.
+
+   The English team is special.  It works at improving and uniformizing
+the terminology in use.  Proven linguistic skill are praised more than
+programming skill, here.
+
+Available Packages
+==================
+
+   Languages are not equally supported in all packages.  The following
+matrix shows the current state of internationalization, as of December
+1997.  The matrix shows, in regard of each package, for which languages
+PO files have been submitted to translation coordination.
+
+     Ready PO files    cs da de en es fi fr it ja ko nl no pl pt ru sl sv
+                     .----------------------------------------------------.
+     bash            |       []          []          []                   |  3
+     bison           |       []          []          []                   |  3
+     clisp           |       [] [] []    []                               |  4
+     cpio            |       []    []    []       [] []    []             |  6
+     diffutils       |       []    []    []                []          [] |  5
+     enscript        |       []    [] [] []          []             []    |  6
+     fileutils       | []    []    []    []       [] []    [] []    [] [] | 10
+     findutils       |       []    []    [] []    [] []    []    []    [] |  9
+     flex            |             []    []       []                   [] |  4
+     gcal            |       []          []          []    []          [] |  5
+     gettext         |    [] []    []    []       [] [] [] [] []    [] [] | 12
+     grep            |       []    []    []       [] [] [] []    [] [] [] | 10
+     hello           |    [] []    []    []       [] [] [] [] []    [] [] | 11
+     id-utils        |       []          []                []             |  3
+     indent          |    [] []                   []       []    []       |  5
+     libc            |       []    []    []       [] []    []          [] |  7
+     m4              |       []          []    []    []          []    [] |  6
+     make            |       []    []    []       [] []    []             |  6
+     music           |                   []                []             |  2
+     ptx             |       []    []    []          [] [] [] []       [] |  8
+     recode          |    [] []    []    []          []    [] []    [] [] |  9
+     sh-utils        |       []    []    []          [] [] [] []       [] |  8
+     sharutils       | []    []    []    []          []                [] |  6
+     tar             | []    []          [] []    [] [] [] [] []    [] [] | 11
+     texinfo         | []    []          []                               |  3
+     textutils       | []    []    []    []       [] [] [] []          [] |  9
+     wdiff           | []    []    []    []          [] [] []          [] |  8
+                     `----------------------------------------------------'
+       17 languages    cs da de en es fi fr it ja ko nl no pl pt ru sl sv
+       27 packages      6  4 25  1 18  1 26  2  1 12 20  9 19  7  4  7 17  179
+
+   Some counters in the preceding matrix are higher than the number of
+visible blocks let us expect.  This is because a few extra PO files are
+used for implementing regional variants of languages, or language
+dialects.
+
+   For a PO file in the matrix above to be effective, the package to
+which it applies should also have been internationalized and
+distributed as such by its maintainer.  There might be an observable
+lag between the mere existence a PO file and its wide availability in a
+distribution.
+
+   If December 1997 seems to be old, you may fetch a more recent copy
+of this `ABOUT-NLS' file on most GNU archive sites.
+
diff --git a/CHANGES b/CHANGES
new file mode 100644
index 00000000..8a943ee9
--- /dev/null
+++ b/CHANGES
@@ -0,0 +1,4 @@
+                     Changelog for fetchmail
+
+* Mon Jan 12 2004 <esr@thyrsus.com> 
+- See the project news file for recent changes.
diff --git a/FetchmailOfSatan.gif b/FetchmailOfSatan.gif
new file mode 100644
index 00000000..15cfdc31
--- /dev/null
+++ b/FetchmailOfSatan.gif
diff --git a/OPTIONS b/OPTIONS
new file mode 100644
index 00000000..96886366
--- /dev/null
+++ b/OPTIONS
@@ -0,0 +1,77 @@
+Summary of responses on `Nuke the options?': 
+
+Yes:
+
+Felix Morley Finch <felix@crowfix.com>
+Nathan Myers <ncm@cantrip.org>
+Irving Wolfe <Irving_Wolfe@wolfe.net>
+Craig Metz <cmetz@inner.net>
+Alexander Kourakos <awk@bnt.com>
+John Swinbank <john@swinbank.u-net.com>
+Alexandros Manoussakis <alx@beryl.kapatel.gr>
+
+No:
+
+Guenther Leber <gleber@gams.at>
+Dave Bodenstab <imdave@mcs.net>
+Erik Soosalu <esoosalu@geocities.com>
+Jonathan Marten <jonathan.marten@uk.Sun.COM>
+
+Other:
+
+Chris Hanson <cph@martigny.ai.mit.edu> thinks --smtphost can be useful,
+but says the change won't affect him.
+
+Matt Simmons <simmonmt@acm.org> didn't express a general opinion but wants 
+-B/fetchlimit kept.
+
+Steffen Opel <opel@rumpelkammer.uni-mannheim.de> makes a good argument
+that --limit should be settable from the command line as a way to throttle
+fetches according to day-night rates.
+
+Comments:
+	felix@crowfix.com:  "Using --fetchmailrc, someone could
+write a Perl wrapper which would dummy up a temporary control file
+using the soon-to-be-banned options, if someone really wanted such a
+program."
+	ncm@cantrip.org doesn't want fetchmailrc to require a control file.
+	gleber@gams.at: "I like the flexibility I get from [command-line
+options] and use it very often."
+	awk@bnt.com: keep -u, -p, nuke the others.
+	alx@beryl.kapatel.gr: keep -u, -p, -t, nuke the others.
+	esoosalu@geocities.com: "I would have an objection to removing
+command line options:  It makes it a lot harder to debug the inital setup."
+	jonathan.marten@uk.Sun.COM: particularly (and not unreasonably)
+objects to losing -r.
+
+Alexandros Manoussakis <alx@beryl.kapatel.gr> offered the following summary:
+
+It seems like many of us want to be able to use
+fetchmail without the need of a .fetchmailrc file.
+Regarding your list of commands to remove from
+the command line, taking into account the feedback
+regarding the matter we have (* denotes wanted options):
+
+  -I, --interface   interface required specification
+  -M, --monitor     monitor interface for activity
+*  -p, --protocol    specify pop2, pop3, imap, apop, rpop, kpop, etrn
+  -U, --uidl        force the use of UIDLs (pop3 only)
+  -P, --port        TCP/IP service port to connect to
+  -A, --auth        authentication type (password or kerberos)
+  -E, --envelope    envelope address header
+  -Q, --qvirtual    prefix to remove from local user id
+*  -u, --username    specify users's login on server
+  -n, --norewrite   don't rewrite header addresses
+*  -l, --limit       don't fetch messages over given size
+*  -K, --nokeep      delete new messages after retrieval
+*  -S, --smtphost    set SMTP forwarding host
+  -D, --smtpaddress set SMTP delivery domain to use
+  -Z, --antispam,   set antispam response value
+  -b, --batchlimit  set batch limit for SMTP connections
+  -B, --fetchlimit  set fetch limit for server connections
+  -e, --expunge     set max deletions between expunges
+*  -r, --folder      specify remote folder name
+*  -t, --timeout     server nonresponse timeout
+
+Let's see how it goes and you can remove at least the options
+no-one complains about!
diff --git a/README.NTLM b/README.NTLM
new file mode 100644
index 00000000..964ba598
--- /dev/null
+++ b/README.NTLM
@@ -0,0 +1,83 @@
+NTLM support by Grant Edwards <grante@visi.com>
+
+This directory contains sources for a library which provides
+routines to manipulate the structures used for the client end
+of Microsoft NTLM authentication.
+
+This code (the ntlm.h file and smb*.[ch] files) was taken mostly from
+the Samba project and was initially intended for use with Microsoft
+Exchange Server when it is configured to require NTLM authentication
+for clients of its IMAP server.
+
+Not much effort has been put into making this portable, and the author
+only know for sure that it works on i386 Linux glibc systems -- though
+there shouldn't be anything all that system-specific anywhere.  System
+byte order differences should already be taken care of.
+
+USAGE  
+  
+The application program must convert these structures to/from base64
+which is used to transfer data for IMAP authentication.  For example
+usage see the sources for the mutt MUA or here in the fetchmail
+package.
+
+In general the usage is something like shown below (no, I don't
+know if this code even compiles, but you get the idea
+hopefully):
+
+
+#include <ntlm.h>
+
+extern char *seqTag;  /* IMAP sequence number */
+
+int imap_auth_ntlm(char *user, char *domain, char *pass)
+{
+  tSmbNtlmAuthRequest   request;              
+  tSmbNtlmAuthChallenge challenge;
+  tSmbNtlmAuthResponse  response;
+  char buffer[512];
+  char tmpstr[32];
+  
+  writeToServer("%s AUTHENTICATE NTLM\r\n",seqTag);
+  readFromServer(buffer)
+  
+  /* buffer should be "+", but we won't show code to check */
+
+  /* 
+   * prepare the request, convert to base64, and send it to
+   * the the server.  My server didn't care about domain, and NULL
+   * worked fine.
+   */
+
+  buildSmbNtlmAuthRequest(&request,user,domain);
+  convertToBase64(buffer, &request, SmbLength(&request));
+  writeToServer("%s\r\n",buffer);
+  
+  /* read challange data from server, convert from base64 */
+  
+  readFromServer(buffer);
+  
+  /* buffer should contain the string "+ [base 64 data]" */
+  
+  convertFromBase64(&challenge, buffer+2);
+  
+  /* prepare response, convert to base64, send to server */
+  
+  buildSmbNtlmAuthResponse(&challenge, &response, user, pass);
+  convertToBase64(buffer,&response,SmbLength(&response));
+  writeToServer("%s\r\n",buffer);
+  
+  /* read line from server, it should be "[seq] OK blah blah blah" */
+  
+  readFromServer(buffer);
+  
+  sprintf(tmpstr,"%s OK",seqTag);
+  
+  if (strncmp(buffer,tmpstr,strlen(tmpstr)))
+  {
+    /* login failed */
+    return -1;
+  }
+  
+  return 0;
+}
diff --git a/README.SSL b/README.SSL
new file mode 100644
index 00000000..44f0c195
--- /dev/null
+++ b/README.SSL
@@ -0,0 +1,92 @@
+Fetchmail SSL support
+=====================
+
+NOTE: This text is maybe not explanatory enough, so a little knowledge about
+public-key-cryptography and associated topics is required.
+
+Using the fetchmail ssl option, you can have the data transferred between you
+and the server in an encrypted form, so that eavesdropping should become
+practically impossible.
+
+This works as following: the server has a key pair (a secret and a public key),
+and it sends the client it's public key. Messages encrypted with the public key
+can be decrypted using the private one and vice versa.
+A symmetric session key (symmetric means that the same key is used for
+encryption and decryption) can now be agreed upon by the two parties using
+the secure channel the key pair builds. The session key is now used to encrypt
+the traffic.
+
+In the fetchmail case, the client can now authenticate itself to the server by
+using the usual POP/IMAP/whatever authentication mechanisms.
+
+However, so called man-in-the-middle attacks are still possible: in such a
+setting, an attacker imposes the server, and thus can e.g. get your
+authentication information if you don't use a challenge based authentication
+mechanism (because he is thought to be the real server, fetchmail will try to
+authenticate against it by telling it your password).
+
+So, not only you need to prove your identity to the server, the server likewise
+needs to prove it's to you.
+In the standard setting, the server has a certificate (the client can have a
+certificate too to prove its identity, but this is not covered by this
+document). This certificate contains the server's public key, some data about
+the server, and a digital signature and data about the signer.
+Digital signatures can also be made using a key pair as described earlier.
+
+To check this certificate, you may use the new option sslcertck. When it is
+specified, the signature of server certificate is checked against local trusted
+certificates to see whether the owner of one of the ceritificates has signed
+that server certificate, and if so, whether the signature is valid.
+So, if the server certificate is signed by a Certification Authority (CA),
+you put the CA's certificate into a directory where you keep trusted
+certificates, and point fetchmail to it. Fetchmail will then accept certificates
+signed by the owner of that certificate with the private key belonging to the
+public key in the certificate.
+You can specifiy this path using the sslcertpath option.
+The idea is that the CA only gives certificates to entities of which it has
+checked and verified the identity of (and in this case, that the server name you
+specify does belong to it). So, if you chose the intentions and the thoroughness
+of a CA, you can be reasonably sure that if a certificate is signed by the CA,
+it really belongs to the server and owner that it claims to.
+
+Certificates are only valid in a certain time window, so your system clock
+should be reasonably accurate when checking certificates.
+
+Additionally, CAs keep Certificate Revocation Lists (CRLs) in which they note
+the certificates that are to be treated as invalid (e.g. because the server
+name has changed, another ceritifcate was granted, or even because the
+certificate was not granted to the rightful owner).
+
+The really paranoid (who chose to not trust a CA) can check the fingerprint of
+the public key that is used by the server. The fingerprint is a hash of that
+key that (hopefully) has few collisions and is hard to attack using a "birthday
+attack", i.e. nobody can generate a second key that hashes to the same value
+of the original key in reasonable time. So, if the fingerprint matches, you
+can be reasonable sure that you talk to the original server, because only that
+knows the secret key, and it is very hard to generate a matching secret key from
+the public key. If it doesn't, it might be an attack, but keep in mind that the
+server key may also have changed legitimately before panicing ;)
+
+fetchmail will present the fingerprint to you. Another mode, that strictly
+checks the fingerprint, is available (using the sslfingerprint option, and
+giving the desired fingerprint as an argument). If you want to check finger-
+prints, you should use that option, because otherwise, it may be too late
+to cancel if you see the fingerprint (your password may already have been
+transmitted)!
+
+The certificate directory must be hashed in a way OpenSSL expects it: each
+time you modify a file in that directory or add a file to it, you need
+to use the c_rehash perl script that comes with OpenSSL (in the tools/
+subdirectory, in case that it isn't installed). Additionally, you might
+need to convert the ceriticates to different formats (the PEM format is expected
+and usually is available, DER is another one; you can convert between
+both using the openssl(1) utility).
+
+The fingerprints fetchmail uses are MD5 sums. You can generate them e.g. useing
+the openssl(1) "x509 -fingerprint" command. The format is a hexadecimal string
+with a ":" separating two byes (i.e. a ":" every two hex "digits"). The letter
+hex digits must be in upper case!
+
+*CAVEAT*: OpenSSL seems to be unable to check CRLs at the moment!
+
+	- Thomas Moestl <tmoestl@gmx.net>
diff --git a/RELEASE-INSTRUCTIONS b/RELEASE-INSTRUCTIONS
new file mode 100644
index 00000000..e40b2b57
--- /dev/null
+++ b/RELEASE-INSTRUCTIONS
@@ -0,0 +1,10 @@
+To do a release:
+
+1. Torture-test the code against the list of test sites usuing the
+   torturetest script.
+
+2. Check in all files to RCS with an appropriate release label.
+
+3. Run "makerelease" is root.  Read the script to see what it generates.
+
+4. Run "upload" as yourself.
diff --git a/RFC/draft-klensin-cram-03.txt b/RFC/draft-klensin-cram-03.txt
new file mode 100644
index 00000000..bfac1d5b
--- /dev/null
+++ b/RFC/draft-klensin-cram-03.txt
@@ -0,0 +1,261 @@
+

+Network Working Group                                        J Klensin

+Internet Draft                                                 R Catoe

+Document: draft-klensin-cram-03.txt                        P Krumviede  

+                                                                   MCI

+							September 1996

+

+

+

+

+       IMAP/POP AUTHorize Extension for Simple Challenge/Response

+

+Status of this Memo

+

+   This document is an Internet Draft.  Internet Drafts are working

+   documents of the Internet Engineering Task Force (IETF), its Areas,

+   and its Working Groups.  Note that other groups may also distribute

+   working documents as Internet Drafts.

+

+   Internet Drafts are draft documents valid for a maximum of six

+   months.  Internet Drafts may be updated, replaced, or obsoleted by

+   other documents at any time.  It is not appropriate to use Internet

+   Drafts as reference material or to cite them other than as a

+   ``working draft'' or ``work in progress``.

+

+   To learn the current status of any Internet-Draft, please check the

+   1id-abstracts.txt listing contained in the Internet-Drafts Shadow

+   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or

+   munnari.oz.au.

+

+   A revised version of this draft document will be submitted to the

+   IESG for processing as a Proposed Standard for the Internet

+   Community, updating RFC 1731.  Discussion and suggestions for

+   improvement are requested. This document reflects editorial

+   comments received during the last call period; the protocol is

+   unchanged from the previous version.  This draft will expire

+   before February 22, 1997.  Distribution of this draft is

+   unlimited. 

+

+

+Abstract

+

+  While IMAP4 supports a number of strong authentication mechanisms

+  as described in RFC 1731, it lacks any mechanism that neither passes

+  cleartext, reusable passwords across the network nor requires either a

+  significant security infrastructure or that the mail server update a

+  mail-system-wide user authentication file on each mail access.  This

+  specification provides a simple challenge-response authentication

+  protocol that is suitable for use with IMAP4.  Since it utilizes

+  Keyed-MD5 digests and does not require that the secret be stored in the

+  clear on the server, it may also constitute an improvement on APOP for

+  POP3 use as specified in RFC 1734.

+

+1. Introduction

+

+   Existing Proposed Standards specify an AUTHENTICATE mechanism for

+   the IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for 

+   the POP3 protocol [POP3-AUTH].  The AUTHENTICATE mechanism is intended

+   to be extensible; the four methods specified in [IMAP-AUTH] are all

+   fairly powerful and require some security infrastructure to support.

+   The base POP3 specification [POP3] also contains a lightweight

+   challenge-response mechanism called APOP.  APOP is associated with

+   most of the risks associated with such protocols: in particular, it

+   requires that both the client and server machines have access to the

+   shared secret in cleartext form. CRAM offers a method for avoiding

+   such cleartext storage while retaining the algorithmic simplicity

+   of APOP in using only MD5, though in a "keyed" method.

+

+   At present, IMAP [IMAP] lacks any facility corresponding to APOP.

+   The only alternative to the strong mechanisms identified in

+   [IMAP-AUTH] is a presumably cleartext username and password,

+   supported through the LOGIN command in [IMAP].  This document

+   describes a simple challenge-response mechanism, similar to APOP and

+   PPP CHAP [PPP], that can be used with IMAP (and, in principle, with

+   POP3).

+

+   This mechanism also has the advantage over some possible

+   alternatives of not requiring that the server maintain information

+   about email "logins" on a per-login basis.  While mechanisms that

+   do require such per-login history records may offer enhanced

+   security, protocols such as IMAP, which may have several

+   connections between a given client and server open more or less

+   simultaneous, may make their implementation particularly

+   challenging. 

+

+

+2. Challenge-Response Authentication Mechanism (CRAM)

+

+   The authentication type associated with CRAM is "CRAM-MD5".

+

+   The data encoded in the first ready response contains an

+   presumptively arbitrary string of random digits, a timestamp,

+   and the fully-qualified primary host name of the server.  The

+   syntax of the unencoded form must correspond to that of an

+   RFC 822 'msg-id' [RFC822] as described in [POP3].

+

+   The client makes note of the data and then responds with a string

+   consisting of the user name, a space, and a 'digest'.  The latter is

+   computed by applying the keyed MD5 algorithm from [KEYED-MD5]

+   where the key is a shared secret and the digested text is

+   the timestamp (including angle-brackets). 

+

+   This shared secret is a string known only to the client and server.

+   The `digest' parameter itself is a 16-octet value which is

+   sent in hexadecimal format, using lower-case ASCII characters. 

+

+   When the server receives this client response, it verifies the digest

+   provided.  If the digest is correct, the server should consider the

+   client authenticated and respond appropriately.

+

+   Keyed MD5 is chosen for this application because of the greater

+   security imparted to authentication of short messages. In addition,

+   the use of the techniques described in [KEYED-MD5] for

+   precomputation of intermediate results make it possible to avoid 

+   explicit cleartext storage of the shared secret on the server system

+   by instead storing the intermediate results which are known as

+   "contexts". 

+ 

+   CRAM does not support a protection mechanism.

+

+

+   Example:

+

+   The examples in this document show the use of the CRAM mechanism with

+   the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of

+   the challenges and responses is part of the IMAP4 AUTHENTICATE

+   command, not part of the CRAM specification itself.

+

+     S: * OK IMAP4 Server

+     C: A0001 AUTHENTICATE CRAM-MD5

+     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+

+     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw

+     S: A0001 OK CRAM authentication successful

+

+     In this example, the shared secret is the string 'tanstaaftanstaaf'.

+     Hence, the Keyed MD5 digest is produced by calculating

+

+        MD5((tanstaaftanstaaf XOR opad),

+            MD5((tanstaaftanstaaf XOR ipad),

+            <1896.697170952@postoffice.reston.mci.net>))

+

+     where ipad and opad are as defined in the keyed-MD5 draft

+     [KEYED-MD5] and the string shown in the challenge is the base64

+     encoding of <1896.697170952@postoffice.reston.mci.net>. The

+     shared secret is null-padded to a length of 64 bytes. If the

+     shared secret is longer than 64 bytes, the MD5 digest of the

+     shared secret is used as a 16 byte input to the keyed MD5

+     calculation.

+

+     This produces a digest value (in hexadecimal) of

+

+

+	   b913a602c7eda7a495b4e6e7334d3890

+

+     The user name is then prepended to it, forming

+

+           tim b913a602c7eda7a495b4e6e7334d3890

+

+     Which is then base64 encoded to meet the requirements of the IMAP4

+     AUTHENTICATE command (or the similar POP3 AUTH command), yielding

+

+           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw

+

+

+

+3. References

+

+   [CHAP]  Lloyd, B. and W. Simpson, "PPP Authentication Protocols",

+       RFC 1334, October 1992.

+

+   [IMAP] Crispin, M. "Internet Message Access Protocol - Version 4",

+       RFC 1730, University of Washington, December, 1994.

+

+   [IMAP-AUTH] Myers, J. "IMAP4 Authentication Mechanisms", 

+       RFC 1731, Carnegie Mellon, December, 1994

+

+   [KEYED-MD5] Krawczyk, H "HMAC-MD5: Keyed-MD5 for Message

+       Authentication" work in progess (draft-ietf-ipsec-hmac-md5-00.txt),

+       IBM, March 1996. 

+

+   [MD5]  Rivest, R. "The MD5 Message Digest Algorithm",

+       RFC 1321, MIT Laboratory for Computer Science, April, 1992.  

+   

+   [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3 ",

+       RFC 1939 (STD 53), Carnegie Mellon, May 1996.

+

+   [POP3-AUTH] Myers, J. "POP3 AUTHentication command", RFC 1734, Carnegie

+       Mellon, December, 1994.

+

+

+4. Security Considerations

+

+   It is conjectured that use of the CRAM authentication mechanism

+   provides origin identification and replay protection for a session.

+   Accordingly, a server that implements both a cleartext password

+   command and this authentication type should not allow both methods of

+   access for a given user.

+

+   While the saving, on the server, of "contexts" (see section 2) is

+   marginally better than saving the shared secrets in cleartext as is

+   required by CHAP [CHAP] and APOP [POP3], it is not sufficient to

+   protect the secrets if the server itself is compromised.

+   Consequently, servers that store the secrets or contexts must both

+   be protected to a level appropriate to the potential information

+   value in user mailboxes and identities.

+

+   As the length of the shared secret increases, so does the difficulty

+   of deriving it.

+

+   While there are now suggestions in the literature that the use of

+   MD5 and keyed MD5 in authentication procedures probably has a

+   limited effective lifetime, the technique is now widely deployed and

+   widely understood.  It is believed that this general understanding

+   may assist with the rapid replacement, by CRAM-MD5, of the current

+   uses of permanent cleartext passwords in IMAP.   This document has

+   been deliberately written to permit easy upgrading to use SHA (or

+   whatever alternatives emerge) when they are considered to be widely

+   available and adequately safe.

+

+   Even with the use of CRAM, users are still vulnerable to active

+   attacks.  An example of an increasingly common active attack is 'TCP

+   Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].

+

+   See section 1 above for additional discussion.

+

+

+5. Acknowledgements

+

+   This memo borrows ideas and some text liberally from [POP3] and

+   [RFC-1731] and thanks are due the authors of those documents.  Ran

+   Atkinson made a number of valuable technical and editorial

+   contributions to the current draft.

+

+

+6. Authors' Addresses

+

+ John C. Klensin

+ MCI Telecommunications

+ 800 Boylston St, 7th floor

+ Boston, MA 02199

+ USA

+    Email: klensin@mci.net

+    Tel: +1 617 960 1011

+

+ Randy Catoe

+ MCI Telecommunications

+ 2100 Reston Parkway

+ Reston, VA 22091

+ USA

+    Email: randy@mci.net

+    Tel: +1 703 715 7366

+

+ Paul Krumviede

+ MCI Telecommunications

+ 2100 Reston Parkway

+ Reston, VA 22091

+ USA

+    Email: paul@mci.net

+    Tel: +1 703 715 7251

+

+

diff --git a/RFC/draft-newman-tls-imappop-05.txt b/RFC/draft-newman-tls-imappop-05.txt
new file mode 100644
index 00000000..680556e8
--- /dev/null
+++ b/RFC/draft-newman-tls-imappop-05.txt
@@ -0,0 +1,618 @@
+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Internet Draft: Using TLS with IMAP4, POP3 and ACAP             Innosoft
+Document: draft-newman-tls-imappop-05.txt                  November 1998
+
+
+                  Using TLS with IMAP4, POP3 and ACAP
+
+
+Status of this memo
+
+     This document is an Internet-Draft.  Internet-Drafts are working
+     documents of the Internet Engineering Task Force (IETF), its areas,
+     and its working groups.  Note that other groups may also distribute
+     working documents as Internet-Drafts.
+
+     Internet-Drafts are draft documents valid for a maximum of six
+     months and may be updated, replaced, or obsoleted by other
+     documents at any time.  It is inappropriate to use Internet-Drafts
+     as reference material or to cite them other than as "work in
+     progress."
+
+     To view the entire list of current Internet-Drafts, please check
+     the "1id-abstracts.txt" listing contained in the Internet-Drafts
+     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
+     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
+     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
+     West Coast).
+
+Abstract
+
+     This specification defines extensions to IMAP [IMAP4], POP [POP3]
+     and ACAP [ACAP] which activate TLS [TLS].  This also defines a
+     simple PLAIN SASL [SASL] mechanism for use underneath strong TLS
+     encryption with ACAP or other protocols lacking a clear-text login
+     command.
+
+1. Motivation
+
+     The TLS protocol [TLS] (formerly known as SSL) provides a way to
+     secure a TCP connection from tampering and eavesdropping.
+     Obviously, the option of using such security is desirable for IMAP
+     [IMAP4], POP [POP3] and ACAP [ACAP].  Although advanced SASL [SASL]
+     authentication mechanisms can provide a lightweight version of this
+     service, TLS is a full service security layer and is complimentary
+     to simple authentication-only SASL mechanisms or clear-text
+     password login commands. Furthermore, many sites have a high
+     investment in authentication infrastructure (e.g., a large database
+     of a one-way-function applied to user passwords), so a privacy
+
+
+
+Newman                                                          [Page 1]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+     layer which is not tightly bound to user authentication can protect
+     against network eavesdropping attacks without requiring a new
+     authentication infrastructure and/or forcing all users to change
+     their password.
+
+1.1. Conventions Used in this Document
+
+     The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
+     NOT", "MAY", and "OPTIONAL" in this document are to be interpreted
+     as described in "Key words for use in RFCs to Indicate Requirement
+     Levels" [KEYWORDS].
+
+     Formal syntax is defined using ABNF [ABNF].
+
+     In examples, "C:" and "S:" indicate lines sent by the client and
+     server respectively.
+
+2. Basic Interoperability and Security Requirements
+
+     The following requirements apply to all implementations of the
+     STARTTLS extension for IMAP4, POP3 and ACAP.
+
+2.1. Cipher Suite Requirements
+
+     Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher
+     suite is REQUIRED.  This is important as it assures that any two
+     compliant implementations can be configured to interoperate.
+
+     All other cipher suites are OPTIONAL.
+
+2.2. TLS Operational Mode Security Requirements
+
+     Both clients and servers SHOULD have an operational mode where use
+     of TLS encryption is required to login.  Clients MAY have an
+     operational mode where TLS is used only when advertised by the
+     server, but login occurs regardless.  For backwards compatibility,
+     servers SHOULD have an operational mode which permits clients to
+     login when TLS is not used.
+
+2.3. Clear-Text Password Requirement
+
+     A server which implements both STARTTLS and a clear-text password
+     authentication mechanism (including but not limited to the IMAP4
+     LOGIN command, POP3 PASS command and the PLAIN mechanism in section
+     6) MUST have an operational mode where all clear-text login
+     commands and mechanisms are disabled unless TLS encryption is
+     active.
+
+
+
+
+Newman                                                          [Page 2]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+2.4. Server Identity Check
+
+     During the TLS negotiation, the client MUST check its understanding
+     of the server hostname against the server's identity as presented
+     in the server Certificate message, in order to prevent
+     man-in-the-middle attacks.  Matching is performed according to
+     these rules:
+
+     o   The client MUST use the server hostname it used to open the
+         connection as the value to compare against the server name as
+         expressed in the server certificate.  The client MUST NOT use
+         any form of the server hostname derived from an insecure remote
+         source (e.g., insecure DNS reverse lookup).
+
+     o   If a subjectAltName extension of type dNSName is present in the
+         certificate, it SHOULD be used as the source of the server's
+         identity.
+
+     o   Matching is case-insensitive.
+
+     o   A "*" wildcard character MAY be used as the left-most name
+         component in the certificate.  For example, *.example.com would
+         match a.example.com, foo.example.com, etc. but would not match
+         example.com.
+
+     o   If the certificate contains multiple names (e.g. more than one
+         dNSName field), then a match with any one of the fields is
+         considered acceptable.
+
+     If the match fails, the client SHOULD either ask for explicit user
+     confirmation, or terminate the connection and indicate the server's
+     identity is suspect.
+
+3. IMAP4 STARTTLS extension
+
+     When the TLS extension is present in IMAP4, "STARTTLS" is listed as
+     a capability in response to the CAPABILITY command.  This extension
+     adds a single command, "STARTTLS" to the IMAP4 protocol which is
+     used to begin a TLS negotiation.
+
+3.1. STARTTLS Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - begin TLS negotiation
+               NO - security layer already active
+
+
+
+Newman                                                          [Page 3]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+               BAD - command unknown or arguments invalid
+
+      A TLS negotiation begins immediately after the CRLF at the end of
+      the tagged OK response from the server.  Once a client issues a
+      STARTTLS command, it MUST NOT issue further commands until a
+      server response is seen and the TLS negotiation is complete.
+
+      The STARTTLS command is only valid in non-authenticated state.
+      The server remains in non-authenticated state, even if client
+      credentials are supplied during the TLS negotiation.  The SASL
+      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
+      client credentials are successfully exchanged, but servers
+      supporting the STARTTLS command are not required to support the
+      EXTERNAL mechanism.
+
+      Once TLS has been started, the client SHOULD discard cached
+      information about server capabilities and re-issue the CAPABILITY
+      command.  This is necessary to protect against man-in-the-middle
+      attacks which alter the capabilities list prior to STARTTLS.  The
+      server MAY advertise different capabilities after STARTTLS.
+
+      The formal syntax for IMAP4 is amended as follows:
+
+        command_any   =/  "STARTTLS"
+
+   Example:    C: a001 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 STARTTLS
+               S: a001 OK CAPABILITY completed
+               C: a002 STARTTLS
+               S: a002 OK Begin TLS negotiation now
+               <TLS negotiation, further commands are under TLS layer>
+               C: a003 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL
+               S: a003 OK CAPABILITY completed
+               C: a004 LOGIN joe password
+               S: a004 OK LOGIN completed
+
+4. POP3 STARTTLS extension
+
+   The POP3 STARTTLS extension adds the STLS command to POP3 servers.
+   If this is implemented, the POP3 extension mechanism [POP3EXT] MUST
+   also be implemented to avoid the need for client probing of multiple
+   commands.  The capability name "STLS" indicates this command is
+   present.
+
+      STLS
+
+         Arguments: none
+
+
+
+Newman                                                          [Page 4]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+         Restrictions:
+             Only permitted in AUTHORIZATION state.
+
+         Discussion:
+             A TLS negotiation begins immediately after the CRLF at the
+             end of the +OK response from the server.  A -ERR response
+             MAY result if a security layer is already active.  Once a
+             client issues a STLS command, it MUST NOT issue further
+             commands until a server response is seen and the TLS
+             negotiation is complete.
+
+             The STLS command is only permitted in AUTHORIZATION state
+             and the server remains in AUTHORIZATION state, even if
+             client credentials are supplied during the TLS negotiation.
+             The AUTH command [POP-AUTH] with the EXTERNAL mechanism
+             [SASL] MAY be used to authenticate once TLS client
+             credentials are successfully exchanged, but servers
+             supporting the STLS command are not required to support the
+             EXTERNAL mechanism.
+
+             Once TLS has been started, the client SHOULD discard cached
+             information about server capabilities and re-issue the CAPA
+             command.  This is necessary to protect against
+             man-in-the-middle attacks which alter the capabilities list
+             prior to STLS.  The server MAY advertise different
+             capabilities after STLS.
+
+         Possible Responses:
+             +OK -ERR
+
+         Examples:
+             C: STLS
+             S: +OK Begin TLS negotiation
+             <TLS negotiation, further commands are under TLS layer>
+               ...
+             C: STLS
+             S: -ERR Security Layer already active
+
+5. ACAP STARTTLS extension
+
+     When the TLS extension is present in ACAP, "STARTTLS" is listed as
+     a capability in the ACAP greeting.  No arguments to this capability
+     are defined at this time.  This extension adds a single command,
+     "STARTTLS" to the ACAP protocol which is used to begin a TLS
+     negotiation.
+
+
+
+
+
+
+Newman                                                          [Page 5]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+5.1. STARTTLS Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - begin TLS negotiation
+               NO - security layer already active
+               BAD - command unknown or arguments invalid
+
+      A TLS negotiation begins immediately after the CRLF at the end of
+      the tagged OK response from the server.  Once a client issues a
+      STARTTLS command, it MUST NOT issue further commands until a
+      server response is seen and the TLS negotiation is complete.
+
+      The STARTTLS command is only valid in non-authenticated state.
+      The server remains in non-authenticated state, even if client
+      credentials are supplied during the TLS negotiation.  The SASL
+      [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS
+      client credentials are successfully exchanged, but servers
+      supporting the STARTTLS command are not required to support the
+      EXTERNAL mechanism.
+
+      After the TLS layer is established, the server MUST re-issue an
+      untagged ACAP greeting.  This is necessary to protect against
+      man-in-the-middle attacks which alter the capabilities list prior
+      to STARTTLS.  The client SHOULD discard cached capability
+      information and replace it with the information from the new ACAP
+      greeting.  The server MAY advertise different capabilities after
+      STARTTLS.
+
+      The formal syntax for ACAP is amended as follows:
+
+        command_any   =/  "STARTTLS"
+
+   Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+               C: a002 STARTTLS
+               S: a002 OK "Begin TLS negotiation now"
+               <TLS negotiation, further commands are under TLS layer>
+               S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
+
+6. PLAIN SASL mechanism
+
+     Clear-text passwords are simple, interoperate with almost all
+     existing operating system authentication databases, and are useful
+     for a smooth transition to a more secure password-based
+     authentication mechanism.  The drawback is that they are
+     unacceptable for use over an unencrypted network connection.
+
+
+
+Newman                                                          [Page 6]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+     This defines the "PLAIN" SASL mechanism for use with ACAP and other
+     protocols with no clear-text login command.  This MUST NOT be
+     implemented unless strong TLS encryption or an equivalent strong
+     encryption layer is also implemented.
+
+     The mechanism consists of a single message from the client to the
+     server.  The client sends the authorization identity (identity to
+     login as), followed by a US-ASCII NUL character, followed by the
+     authentication identity (identity whose password will be used),
+     followed by a US-ASCII NUL character, followed by the clear-text
+     password.  The client may leave the authorization identity empty to
+     indicate that it is the same as the authentication identity.
+
+     The server will verify the authentication identity and password
+     with the system authentication database and verify that the
+     authentication credentials permit the client to login as the
+     authorization identity.  If both steps succeed, the user is logged
+     in.
+
+     The server MAY also use the password to initialize any new
+     authentication database, such as one suitable for CRAM-MD5
+     [CRAM-MD5].
+
+     Non-US-ASCII characters are permitted as long as they are
+     represented in UTF-8 [UTF-8].  Use of non-visible characters or
+     characters which a user may be unable to enter on some keyboards is
+     discouraged.
+
+     Clients are encouraged to support pure-binary passwords as they may
+     be safe from dictionary attacks.  However, if the client offers a
+     character-based interface for password entry it MUST use UTF-8
+     encoding for the characters.
+
+     The formal grammar for the client message using Augmented BNF
+     [ABNF] follows.
+
+     message         = [authorize-id] NUL authenticate-id NUL password
+     authenticate-id = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+     authorize-id    = 1*UTF8-SAFE      ; MUST accept up to 255 octets
+     password        = *NZ-OCTET        ; MUST accept up to 255 octets
+     NUL             = %x00
+     NZ-OCTET        = %x01-FF          ; all non-NUL octet values
+     UTF8-SAFE       = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
+                       UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
+     UTF8-1          = %x80-BF
+     UTF8-2          = %xC0-DF UTF8-1
+     UTF8-3          = %xE0-EF 2UTF8-1
+     UTF8-4          = %xF0-F7 3UTF8-1
+
+
+
+Newman                                                          [Page 7]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+     UTF8-5          = %xF8-FB 4UTF8-1
+     UTF8-6          = %xFC-FD 5UTF8-1
+
+     Here is an example of how this might be used to initialize a
+     CRAM-MD5 authentication database for ACAP:
+
+     Example:    S: * ACAP (SASL "CRAM-MD5") (STARTTLS)
+                 C: a001 AUTHENTICATE "CRAM-MD5"
+                 S: + "<1896.697170952@postoffice.reston.mci.net>"
+                 C: "tim b913a602c7eda7a495b4e6e7334d3890"
+                 S: a001 NO (TRANSITION-NEEDED)
+                    "Please change your password, or use TLS to login"
+                 C: a002 STARTTLS
+                 S: a002 OK "Begin TLS negotiation now"
+                 <TLS negotiation, further commands are under TLS layer>
+                 S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL")
+                 C: a003 AUTHENTICATE "PLAIN" {21+}
+                 C: <NUL>tim<NUL>tanstaaftanstaaf
+                 S: a003 OK CRAM-MD5 password initialized
+
+     Note: In this example, <NUL> represents a single ASCII NUL octet.
+
+     Here is an example session where a client erroneously attempts to
+     use PLAIN prior to starting TLS:
+
+     Example:    S: * ACAP (SASL "CRAM-MD5" "PLAIN") (STARTTLS)
+                 C: a001 AUTHENTICATE "PLAIN" {21}
+                 S: a001 NO (ENCRYPT-NEEDED)
+                    "Can't use PLAIN without encryption"
+
+7. imaps and pop3s ports
+
+     The common practice of using a separate port for a "secure" version
+     of each protocol has a number of disadvantages in the IMAP [IMAP4],
+     ACAP [ACAP] and POP [POP3] environment.  Rather than using the best
+     security available, it means that clients have to be explicitly
+     configured to use the separate secure port or suffer the
+     performance loss of probing for active ports.  Furthermore this is
+     even more serious as it would require a new URL scheme which could
+     only be resolved by TLS-enabled clients.
+
+     Separate "imaps" and "pop3s" ports were registered for use with
+     TLS.  Use of these ports is discouraged in favor of the STARTTLS or
+     STLS command.
+
+     One of the arguments used in favor of the separate port technique
+     is that it simplifies configuration of firewalls which filter by IP
+     port.  However, a quality server implementation running on the
+
+
+
+Newman                                                          [Page 8]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+     standard port can be configured to require use of the STARTTLS
+     command or a suitably strong SASL mechanism for non-local
+     connections.  This provides superior functionality as the client
+     need not be re-configured for use outside the firewall and faster
+     non-clear-text SASL mechanisms may be acceptable to many sites for
+     non-local connections.
+
+8. IANA Considerations
+
+     This document constitutes registration of the "STARTTLS" IMAP4
+     capability as required by section 7.2.1 of RFC 2060.
+
+     This document defines the "STLS" POP3 capability as follows:
+
+     CAPA tag:                   STLS
+     Arguments:                  none
+     Added commands:             STLS
+     Standard commands affected: May enable USER/PASS as a side-effect.
+       CAPA command should be re-issued after successful completion.
+     Announced states/Valid states: AUTHORIZATION state only.
+     Specification reference:    this memo
+
+     This document defines the "STARTTLS" ACAP capability as follows:
+
+     Capability name:            STARTTLS
+     Capability keyword:         STARTTLS
+     Capability arguments:       none
+     Published Specification(s): this memo
+     Person and email address for further information:
+         see author's address section below
+
+     This document defines the "PLAIN" SASL mechanism as follows:
+
+     SASL mechanism name:        PLAIN
+     Security Considerations:    See section 9 of this memo
+     Published specification:    this memo
+     Person & email address to contact for further information:
+         see author's address section below
+     Intended usage:             COMMON
+     Author/Change controller:   see author's address section below
+
+9. Security Considerations
+
+     TLS only provides protection for data sent over a network
+     connection.  Messages transferred over IMAP or POP3 are still
+     available to server administrators and usually subject to
+     eavesdropping, tampering and forgery when transmitted through SMTP
+     or NNTP.  TLS is no substitute for an end-to-end message security
+
+
+
+Newman                                                          [Page 9]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+     mechanism using MIME security multiparts [MIME-SEC].
+
+     An active attacker can remove STARTTLS from the capability list.
+     In order to detect such an attack, clients SHOULD either warn the
+     user when session privacy is not active, or be configurable to
+     refuse to proceed without an acceptable level of security.
+
+     Both client and server MUST verify the level of protection
+     negotiated by TLS is adequate for local security policy, and
+     terminate the TCP connection if it is not.  An active attacker can
+     always cause a down-negotiation to the weakest authentication
+     mechanism or cipher suite available.  For this reason,
+     implementations need to be configurable to refuse weak mechanisms
+     or cipher suites.
+
+     Any protocol interactions prior to the TLS handshake are performed
+     in the clear and can be modified by an active attacker.  For this
+     reason, clients SHOULD discard cached information about server
+     capabilities advertised prior to the start of the TLS handshake.
+
+     Clients are encouraged to clearly distinguish between a level of
+     encryption known to be vulnerable to a reasonable attack using
+     modern hardware (such as encryption with a 40-bit key) and one
+     which is believed to be safe from such an attack.
+
+     When the PLAIN mechanism (or the IMAP4 LOGIN or POP3 PASS command)
+     is used, the server gains the ability to impersonate the user to
+     all services with the same password regardless of any encryption
+     provided by TLS or other network privacy mechanisms.  Stronger SASL
+     authentication mechanisms such as Kerberos address this issue.
+
+     Use of clear-text login mechanisms (e.g., the IMAP4 LOGIN command,
+     POP3 PASS command or the PLAIN mechanism) without a suitable
+     encryption layer such as that provided by TLS expose the user's
+     password to a common network eavesdropping attack.  Therefore, the
+     PLAIN mechanism MUST NOT be implemented unless a suitable
+     encryption layer, such as that provided by TLS is also implemented.
+
+     Additional security requirements are discussed in section 2.
+
+10. References
+
+     [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications:
+     ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd,
+     November 1997.
+
+     [ACAP] Newman, Myers, "ACAP -- Application Configuration Access
+     Protocol", RFC 2244, Innosoft, Netscape, November 1997.
+
+
+
+Newman                                                         [Page 10]
+
+Internet Draft    Using TLS with IMAP4, POP3 and ACAP      November 1998
+
+
+     [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
+     for Simple Challenge/Response", RFC 2195, MCI, September 1997.
+
+     [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
+     4rev1", RFC 2060, University of Washington, December 1996.
+
+     [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731,
+     Carnegie-Mellon University, December 1994.
+
+     [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+     Requirement Levels", RFC 2119, Harvard University, March 1997.
+
+     [MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for
+     MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted
+     Information Systems, CyberCash, Innosoft International, October
+     1995.
+
+     [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC
+     1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
+
+     [POP3EXT] Gellens, Newman, Lundblade "POP3 Extension Mechanism",
+     Work in progress.
+
+     [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+     Carnegie Mellon, December 1994.
+
+     [SASL] Myers, J., "Simple Authentication and Security Layer
+     (SASL)", RFC 2222, Netscape Communications, October 1997.
+
+     [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in
+     progress.
+
+     [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
+     RFC 2279, Alis Technologies, January 1998.
+
+11. Author's Address
+
+     Chris Newman
+     Innosoft International, Inc.
+     1050 Lakes Drive
+     West Covina, CA 91790 USA
+
+     Email: chris.newman@innosoft.com
+
+
+
+
+
+
+
+
+Newman                                                         [Page 11]
diff --git a/RFC/lan-mail-protocols b/RFC/lan-mail-protocols
new file mode 100644
index 00000000..13e984ee
--- /dev/null
+++ b/RFC/lan-mail-protocols
@@ -0,0 +1,1330 @@
+
+     SERVING DESKTOP COMPUTERS USING A CENTRAL MAIL SERVER ON AN INTERNET
+                                       
+   
+     _________________________________________________________________
+   
+   Author
+          John Wobus, jmwobus@syr.edu (corrections welcome)
+          
+   Date
+          2/4/1997
+          
+   This file
+          http://web.syr.edu/~jmwobus/comfaqs/lan-mail-protocols.html
+          
+   Other LAN Info
+          http://web.syr.edu/~jmwobus/lans/
+          
+   
+     _________________________________________________________________
+   
+Contents
+
+     * Introduction
+     * List of Protocols and RFCs
+     * Other Sources of Information
+     * Capabilities of Well-known mail clients
+     * List of Implementations
+     * Some other packages for desktop systems
+     * Key and Other Issues
+       
+   
+     _________________________________________________________________
+   
+Introduction
+
+   
+   
+   There are advantages to having a central server receive the mail
+   destined to desktop computers and having the desktop computer collect
+   the mail from the server on demand:
+     * Your desktop computer may be down quite a bit and less network
+       bandwidth and less of the processing resources of the sending
+       computer are used if the computer receiving your mail is ready to
+       receive.
+     * Some people use more than one desktop computer to read mail.
+     * A desktop computer may not have the resources to store all the
+       mail you receive.
+     * It can make your e-mail address more like other users'.
+       
+   
+   
+   The easiest way to "implement" this is to run the central mail server
+   like any multi-user system: let people sign on to it and use some mail
+   utility. Then desktop computer users can use "terminal sessions" to
+   sign on to the central mail server and read their mail (e.g. with Unix
+   "pine"). This has the disadvantage of making the desktop computer
+   users learn and use the central mail server's procedures.
+   
+   SMTP, the "internet" mail protocol used to deliver mail between
+   multi-user systems only supports mail transfer initiated by the sender
+   to actually, it has a method to initiate reception, but the method
+   didn't catch on and is not used). Other protocols have been devised to
+   allow a desktop computer to request transfer of mail, thus able to
+   make use of a central server. These include the published variants of
+   POP, IMAP, and DMSP.
+   
+  POP, POP2, POP3
+  
+   
+   
+   These are rather minimal and are designed to be so. The three are
+   similar but not enough alike to be interoperable. They are basically
+   designed to identify the user by username and password, to transfer
+   the mail from server to desktop computer and to delete the mail
+   transferred. It is assumed that SMTP will be used to send mail.
+   Messages can be retrieved individually, but the only information you
+   can get about a message without transferring it is its length in
+   bytes-- useful for desktop computers with limited storage.
+   
+   POP3 has a number of optional extensions including Xtnd Xmit which
+   allows clients to send mail through the POP3 session rather than using
+   SMTP. Another extension is APOP which allows RSA MD5 encryption of
+   passwords passed over the network.
+   
+   POP3 is now by far the most-used variant of POP, but POP2 may still be
+   used at a few sites. POP3 has a couple of optional extensions: one to
+   avoid sending passwords, and one to aid in reading bulletin boards.
+   
+  IMAP2, IMAP2BIS, IMAP3, IMAP4, IMAP4REV1
+  
+   
+   
+   The IMAP family is similar to the POP family, but also gives clients a
+   way to do string searches through mail that still resides on the
+   server. This is designed to allow the desktop computer to be more
+   selective as to which mail will be transferred. The POP protocols, on
+   the other hand, are designed for simpler server software.
+   
+   IMAP2 is used quite a bit. IMAP3 is an incompatible offshoot that has
+   not been implemented much. IMAP4 is a relatively recent extension of
+   IMAP2 which makes the servers cognizant of the MIME-structure of a
+   message. IMAP2bis was the original name of IMAP4, which has since been
+   refined, but there are/were some implementations of IMAP2bis that are
+   not IMAP4 compliant. IMAP4 also extends IMAP to have many other
+   features including some of DMSP's. IMAP4rev1 includes a few
+   enhancements to IMAP4.
+   
+  ACAP
+  
+   
+   
+   ACAP (Application Configuration Access Protocol), formerly IMSP
+   (Interactive Mail Support Protocol), is a protocol which is being
+   developed to compliment IMAP4 by offering related e-mail services
+   beyond the scope of IMAP4. It includes the ability to subscribe find &
+   subscribe to bulletin boards, mailboxes, and to find and search
+   address books.
+   
+  IMAP VS POP
+  
+   
+   
+   As of this writing (10/96), there are a many more POP than IMAP client
+   implementations and an Internet Service Provider is much more likely
+   to provide POP3 service than IMAP4. But interest in IMAP4 is growing
+   with big-time software houses announcing support. IMAP4 has more
+   features, basically designed to support a model where users store
+   their received mail on a server rather than on their own computer. The
+   big advantage cited for IMAP is that people who "do e-mail" from
+   different computers at different times have the same access to their
+   message store from any of the client-computers they use. The cost of
+   this model (aside from issues such as the complexity and the
+   availability of implementations) is in running a server with
+   sufficient space for the clients' message stores. With personal
+   computer disks now often above a gigabyte (presumeably growing to 10s
+   of gigabytes over the next few years) and multimedia messaging in our
+   future, people storing e-mail on their own hard disk will have a lot
+   of space and ways to use it. A central store serving 10-20 users will
+   not be overly difficult, but one for 1,000 or 10,000 users will be
+   very large (terabytes?) if it is to offer comparable space. The
+   question comes down to the tradeoff between the advantage to users who
+   computer-hop against the costs of managing the large amount of central
+   store. See also online document imap.vs.pop.html (reference below) and
+   section below "Issue of Remote Access".
+   
+  DMSP
+  
+   
+   
+   Also know as PCMAIL. Desktop computers can use this protocol to both
+   send and receive mail. The system is designed around the idea that
+   each user can own more than one workstation; however, the system
+   doesn't seem to handle the idea of a "public workstation" very well.
+   The desktop computers are assumed to hold state information about the
+   mail, a directory so to speak, and when the desktop computer is
+   connected to the server, this directory is updated to "reality". Note:
+   DMSP never gained the following of IMAP or POP and I've heard the
+   software is no longer available.
+   
+  WHO USES THESE PROTOCOLS?
+  
+   
+   
+   These protocols were designed and implemented mostly by
+   Internet-connected universities with some participation by other
+   Internet-connected research institutions. They were certainly devised
+   to handle the type of electronic mail that universities must do. A
+   typical site has probably 10 to 10,000 desktop computers and has an
+   Internet connection and also runs Unix, giving them the Unix sysadmin
+   expertise that makes running a Unix-based server attractive. Most of
+   the servers listed here run under Unix though some run under other
+   large systems and as time goes on, we are seeing more servers that run
+   on PCs and Macintoshes.
+   
+   A more recent use of these protocols has been by Internet Service
+   Providers and their customers. Internet Service Providers require a
+   way to offer e-mail services to however many customers they provide,
+   to customers who are connected to the network only part of the time.
+   Like a campus application, they may have 10 or 10,000 customers to
+   serve. These protocols offer a distinct advantage over SMTP for such
+   purposes and form an attractive complementary e-mail service for WWW
+   users.
+   
+  DISADVANTAGES
+  
+   
+   
+   There are a number of disadvantages associated with the use of these
+   protocols:
+     * since these have long been no more than a small part of the e-mail
+       market, software using these methods is often incompatible with
+       other useful and/or well-known software. A couple of examples are:
+          + Use of mail-enabled applications on desktop computers (there
+            is no fundamental reason that mail software using these
+            protocols can't provide the API used by mail-enabled
+            applications, but in general this hasn't come about yet)
+          + Use of the usual Unix mail readers & the Unix .forward files.
+     * since the server is holding mail for the person, the person can
+       use the server for storage. This leaves the potential for all the
+       disk-space problems inherent in shared disks: people hogging
+       disk-space or forgetting to clean up, etc.
+     * sizing the server: a perennial question people ask is "How big a
+       machine do I need to serve my campus (or department, or
+       whatever)". Naturally no one can give a straight answer because it
+       depends upon so many factors.
+       
+  ISSUE OF REMOTE ACCESS
+  
+   
+   
+   Modern commercial e-mail packages typically have features designed to
+   assist in remote access of ones e-mail. Features include:
+     * ability to download mail through a modem
+     * ability to synchronize two different systems which you are using
+       to read your e-mail by plugging them together.
+       
+   
+   
+   Any method of reading e-mail using PCs or Macintoshes can be used
+   remotely via remote control (the "PCanywhere(tm)" method, e.g. by
+   dialing up your own office PC/Macintosh and using one of the several
+   kinds of software that allow you to control your PC/Macintosh over the
+   phone). Also, any LAN-based method can be used by using one of the
+   several methods of providing the same protocol support over dialup
+   lines as are on LANs (SLIP or PPP for the above-mentioned,
+   TCP/IP-based protocols, ARA for Appletalk-based protocols, etc, and
+   sometimes using two different protocols, one incapsulated in the
+   other) under the constraint that any operations that use the network
+   will be much slower. Also, POP3 is sometime used directly over modems
+   (for example, Eudora can be used in this manner).
+   
+   The ideal protocol for remote access would not penalize the user for
+   the much slower communications speed (usually slower by a factor of
+   100: note that a lot of LAN-based software was written without regard
+   to minimizing the necessary communication, thus is really hurt by such
+   slow speeds), yet would allow the same software to run both remotely
+   and locally, with a wonderful user interface. It would also not be
+   overly expensive in communications equipment or services. This is a
+   difficult set of objectives and the above-three protocols can achieve
+   some of them for some users, but what they actually achieve depends a
+   lot on the user's pattern of e-mail usage. If a user reads just a
+   small amount of mail, then we would not worry about the length of time
+   necessary to download it remotely with POP3, but if the person
+   receives a lot of mail, but just wants to read a small amount of it at
+   home, then with IMAP2, they could pick and choose what to read,
+   eliminating some download time. If someone is paying for the telephone
+   line time (possibly the user if it is a long distance call; in any
+   case, the institution pays a monthly fee for each line it offers,
+   which is dependent upon how many users it is serving, how often they
+   call, and how long their calls are) then IMAP2's natural method of
+   usage which requires the phone call to remain while a user is reading,
+   poking around, sending, and rearranging mail can be much more costly
+   than using POP3 if one call is used to quickly download all the mail
+   and another later call is used to send any replies. Thus with POP3 a
+   user might have two 1 minute calls before and after a 30 minute e-mail
+   session instead of keeping the call for 30 minutes with IMAP2, and
+   each phone line the institution offers could be serving 15 times as
+   many such users who would each pay a lot less in long-distance phone
+   bills. Note that with the advent of multimedia mail (see MIME below)
+   whose messages can be very large, it is possible that downloading even
+   one message that you end up not reading remotely could ruin such a
+   nice-sounding scenario.
+   
+   Note that with the growth of Internet Service Providers, remote access
+   is becoming the normal way for many people to do their e-mail, and
+   offering such services is one of the major growth areas for POP and
+   IMAP.
+   
+  MIME
+  
+   
+   
+   MIME (Multipurpose Internet Mail Extensions) is a relatively new
+   Internet standard for the format for messages with multiple parts, and
+   with non-ASCII data. Any client that can import or export files can
+   use MIME in a clumsy way if you have a program to create and/or decode
+   a MIME message. Some clients have built-in features to do this.
+   Client-server mail protocols generally only deal with entire messages,
+   and can retrieve MIME messages as well as any other messages since
+   MIME was carefully designed to be transparent to existing mail
+   systems. However, IMAP4 has features to allow retrieval of individual
+   parts of MIME-encoded messages. The chart below lists whether a
+   package has MIME support. Servers for protocols that don't offer any
+   special MIME features are marked na for Not Applicable since they need
+   do nothing for users to use MIME. All IMAP4 servers can also do this,
+   but the chart lists whether they include explicit MIME support.
+   
+  APPROACHES NOT COVERED BY THIS MEMO
+     * Proprietary protocols
+     * file sharing
+     * APIs
+     * X.400.
+       
+   
+   
+   Vendors can invent their own protocols similar to those listed above,
+   and some have.
+   
+   LAN e-mail can also be implemented using file sharing, e.g. using NFS
+   to allow separate Unix workstations to share the same mail spool area
+   just as if it were mail being stored on one system, or using Novell's
+   SMF (Simple Message Format) in a Novell file server. If the
+   applications are written so that they are careful to lock files
+   correctly, then this works. An advantage is that any network file
+   protocol can be used and the e-mail application can be somewhat
+   independent of the file protocol. For example, Unix systems could use
+   either AFS or NFS. Pegasus is a PC & Mac application that uses Novell
+   file service to do something similar. Specifications for client-server
+   interaction consist of the file service protocol along with the server
+   directory structures & conventions used for storing e-mail.
+   
+   A very popular approach with commercial vendors is the use of APIs.
+   The client talks to the server using an API (Applications Programming
+   Interface), i.e., a set of subroutine/procedure library call
+   definitions for a library providing subroutines/procedures to send,
+   receive, and manipulate e-mail. With the use of any remote procedure
+   call mechanism, the client can be located on a different computer from
+   the server. This allows some mixing and matching of RPC mechanisms,
+   underlying protocol stacks and APIs: e.g., a vendor defines an API,
+   and it can be run over IPX or TCP/IP, in each case over the protocol
+   stack's RPC mechanism. There are a number of APIs now being pushed by
+   vendors: MAPI (Microsoft); VIM (Lotus); AOCE (Apple). These API's have
+   been the basis for numerous mail-enabled applications: e.g. a word
+   processor that allows you to send or receive documents through e-mail
+   simply uses one of these APIs allowing it to communicate with any
+   server supporting the same API. Specifications for client-server
+   interaction consist of the protocol stack up to the RPC protocol, then
+   the API itself.
+   
+   Note that though the API approach in combination with remote procedure
+   calls allows one to implement client-server e-mail without the use of
+   the protocols covered by this document (IMAP, POP, etc), that there is
+   no theoretical reason why such APIs can't be used in an IMAP or POP
+   environment. The necessary software would be a "driver" or piece of
+   "middleware" that provides the APIs calls to mail-enabled applications
+   and uses POP, IMAP, or whatever over a LAN to reach a server. The
+   advantages/disadvantages of such an approach as compared to the use of
+   RPCs is open to debate. UniPalm's Mail-IT is an example of client
+   software that provides MAPI within the client and uses POP3 to access
+   the server.
+   
+   X.400 is the message transport defined for use between
+   telecommunications vendors and customers by the international
+   consortium of national standards bodies known as ISO. It roughly
+   corresponds to TCP/IP's SMTP and RFC822 header format. A consortium of
+   X.400 vendors (XAPIA) have developed an API for X.400 applications
+   called CMC.
+   
+  LDAP
+  
+   
+   
+   LDAP is a protocol (the Lightweight Directory Access Protocol) being
+   incorporated in some clients as an Internet way for the client to get
+   information about e-mail addresses from a server, i.e. to give you the
+   capability to type in someone's name and have the mail client software
+   retrieve the address from a server-based directory. LDAP also has
+   other uses. There are plans to incorporate LDAP clients into some IMAP
+   and POP clients. LDAP is essentially an Internet-based, simplified
+   X.500-like protocol and one of the original intentions of its creators
+   was to be gatewayed to X.500, thus giving relatively simple Internet
+   clients access to X.500 servers. Both LDAP and X.500 provide a method
+   for naming, retrieving, and searching fields in a directory, but do
+   not define the field-names or what is supposed to go in the fields.
+   Thus server/client interoperability requires further conventions.
+   
+  JAVA
+  
+   
+   
+   Java is a programming language currently (1996) touted as a tool for
+   web-based applications. It can affect the use of LAN protocols in a
+   number of ways: first of all, POP or IMAP clients can be written in
+   Java, using its cross-platform development capabilities to create
+   version for a number of platforms. Second, clients could be written as
+   "Applets", i.e. applications designed to be downloaded into web
+   browsers such as Netscape from a server. With such a design, a user
+   would only need access to a web browser to see their e-mail, e.g. drop
+   into a library and see your e-mail from one of its Internet-browser
+   kyosks. Applets are not normally allowed to access the
+   client-machine's disk files (which would result in too much risk when
+   browsing the Internet from the kind of people who develop computer
+   viruses), so such an application fits a little better into the IMAP
+   model (server storage of e-mail folders) than the POP model (client
+   storage of e-mail folders). Thirdly, Applets enable more practical use
+   of e-mail clients that use non-standard protocols rather than POP or
+   IMAP; interoperability is achieved because the server itself
+   distributes a compatible client applet right when the user accesses
+   the server.
+     _________________________________________________________________
+   
+List of Protocols and RFCs
+
+   
+   
+   Note: for up-to-date information on the RFCs, get an index from an RFC
+   repository. For up-to-date information on the state of each RFC as to
+   the Internet Standards, see the most recent RFC called "Internet
+   Official Protocol Standards".
+
+Name:      Simple Mail Transfer Protocol
+Nickname:  SMTP
+Document:  RFC 821 (Postel, August 1982)
+TCP-port:  25
+Status:    Internet standard (STD 10)
+
+Name:      Post Office Protocol, Version 2
+Nickname:  POP2
+Document:  RFC 937 (Butler et al, February 1985)
+TCP-port:  109
+Status:    Functionally replaced by incompatible POP3 but still used some
+
+Name:      Post Office Protocol, Version 3
+Nickname:  POP3
+Document:  RFC 1939 (Myers & Rose, May 1996)
+TCP-port:  110 (109 also often used)
+Status:    In use, standards track
+Sites:     UC Irvine, MIT
+
+Name       Post Office Protocol, Version 3 Authentication command
+Nickname:  POP3 AUTH
+Document:  RFC1734 (Myers, December 1994)
+
+Name:      Post Office Protocol, Version 3 Extended Service Offerings
+Nickname:  POP3 XTND
+Document:  RFC 1082 (Rose, November 1988)
+
+Name:      Distributed Mail Service Protocol
+Nickname:  DMSP, Pcmail
+Document:  RFC 1056 (Lambert, June 1988)
+TCP-port:  158
+Status:    Used very little
+Sites:     MIT
+
+Name:      Interactive Mail Access Protocol, Version 2
+Nickname:  IMAP2
+Document:  RFC 1176 (Crispin, August 1990)
+TCP-port:  143
+Status:    In use, being replaced by upward-compatible IMAP4
+Sites:     Stanford, U Washington
+
+Name:      Interactive Mail Access Protocol, Version 2bis
+Nickname:  IMAP2bis
+TCP-port:  143
+Status:    Experimental, but in use, being replaced by upward-compatible IMAP4
+
+Name:      Interactive Mail Access Protocol, Version 3
+Nickname:  IMAP3
+Document:  RFC 1203 (Rice, February 1991)
+TCP-port:  220
+Status:    Historical, not used
+Sites:     Stanford
+
+Name:      Internet Message Access Protocol, Version 4
+Nickname:  IMAP4
+Document:  RFC 1730 (Crispin, December 1994)
+TCP-port:  143
+Status:    Implementations exist, being replaced by revised version IMAP4rev1
+Sites:     U Washington
+Related:   RFC 1731 (Myers, December 1994),
+           RFC 1732 (Crispin, December 1994),
+           RFC 1733 (Crispin, December 1994)
+
+Name:      Internet Message Access Protocol, Version 4rev1
+Nickname:  IMAP4rev1
+Document:  RFC 2060 (Crispin, December 1996)
+TCP-port:  143
+Status:    Being implemented, Standards track
+Sites:     U Washington
+Related:   RFC 2061 (Crispin, December 1996),
+           RFC 2062 (Crispin, December 1996)
+
+Name:      Interactive Mail Support Protocol
+Nickname:  IMSP
+Document:  Draft RFC: ? (Myers, June 1995)
+TCP Port:  406
+Status:    Experimental, renamed ACAP
+Sites:     Carnegie Mellon
+
+Name:      Application Configuratino Access Protocol
+Nickname:  ACAP
+Document:  Draft RFC: ? (Myers, June 1996)
+Status:    ?
+Sites:     Carnegie Mellon
+
+   
+   
+   Note: The "I" in IMAP used to stand for "Interactive". Now it stands
+   for "Internet" and the "M" stands for "Message" rather than "Mail".
+   Also, Internet drafts are available at ds.internic.net, munnari.oz.au,
+   and nic.nordu.net in directory internet-drafts. IMAP2bis is
+   essentially an early version of IMAP4.
+     _________________________________________________________________
+   
+Other Sources of Information
+
+   My own info
+          http://web.syr.edu/~jmwobus/lans/#imappop
+          http://web.syr.edu/~jmwobus/internet/
+          
+   The IMAP Connection web site
+          
+        http://www.imap.org
+                Main page
+                
+        http://www.imap.org/products.html
+                List of IMAP implementations
+                
+        http://www.imap.org/imap.vs.pop.brief.html
+                Outlines differences between IMAP and POP.
+                
+        http://www.imap.org/imap.vs.pop.html
+                Same, with more detail.
+                
+        http://www.imap.org/biblio.html
+                Bibliography of IMAP Documents.
+                
+   Information from University of Washington
+          http://www.washington.edu/imap/
+          
+   By anonymous ftp from ftp.cac.washington.edu
+          mail/* (miscellaneous information)
+          
+   Information from andrew2.andrew.cmu.edu
+          
+        http://andrew2.andrew.cmu.edu/cyrus/email/clients-IMAP.html
+                List of IMAP clients
+                
+        http://andrew2.andrew.cmu.edu/cyrus/acap/acap.html
+                The ACAP Home Page
+                
+   Mailing lists:
+          pop@jhunix.hcf.jhu.edu
+          imap@cac.washington.edu
+          CW-EMAIL@EARNCC.EARN.NET
+          
+   By anonymous ftp from rtfm.mit.edu
+          This memo
+          comp.os.msdos.mail-news FAQ Memo
+          Mini FAQ on client-server mail protocols (similar to this memo
+          but shorter and more practical:
+          ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/mailclient-fa
+          q)
+          
+   Consortium
+          "The IMAP Consortium" (Getting under way as of March 1995).
+          
+   Page on MAPI API
+          http://www.wp.com/davidb/emapi.html
+          
+   
+     _________________________________________________________________
+   
+Capabilities of Well-known mail clients
+
+   
+   
+   This section covers what I've been able to find out so far about the
+   well-known mail clients' ability to retrieve mail from a POP or IMAP
+   server.
+
+Client                       POP3           IMAP          MIME
+------                       ----           ----          ----
+Apple PowerMail client          ?              ?             ?
+BeyondMail                    yes        planned-          yes
+CE QuickMail client       planned=       planned=          yes
+Claris Emailer                yes              ?           yes
+DaVinci eMAIL client          yes*             ?           yes*
+Lotus cc:Mail Client           no             no            no
+Lotus Notes mail client        no             no             ?
+Microsoft Mail client          no             no            no
+Microsoft Exchange client     yes+            no           yes&
+Netscape                      yes        planned%          yes
+
+Notes:
+(-) Announced early 1996: target delivery: 4th quarter 1996.
+(=) CE plans to rename the successor to their current client
+    QuickMail LAN, while introducing both a free and a commercial
+    POP3 client, then upgrade the commercial POP3 client to also
+    support IMAP.
+(*) DaVinci SMTP eMAIL: I'm not sure if this is different from
+    the normal DaVinci client.
+(+) Requires Internet Mail Client for Exhange, downloadable from
+    http://www.windows.microsoft.com or included in "Microsoft Plus".
+(&) qp/base64
+(%) Planned for Netscape 4.0
+
+
+
+   
+     _________________________________________________________________
+   
+List of Implementations
+
+
+
+Prot   Computer   Implementation      End  MIME Source
+------ ---------- ------------------- ---- ---- -------------------------------
+DMSP   PC         pc-epsilon (3.1)    clnt ?    allspice.lcs.mit.edu
+DMSP   PC         pc-netmail (3.1)    clnt ?    allspice.lcs.mit.edu
+DMSP   PC         pc-reader           clnt ?    allspice.lcs.mit.edu
+DMSP   Unix       Pcmail 3.1 reposit. srvr na   allspice.lcs.mit.edu
+DMSP   Unix/EMACS Pcmail 4.2          clnt ?    allspice.lcs.mit.edu
+DMSP   PC         PC/TCP 2.3          clnt ?    FTP Software 8/4/94
+DMSP   OS/2       PC/TCP              clnt ?    FTP Software
+DMSP   OS/2       TCP/2               clnt ?    Essex Systems
+DMSP   OS/2       TCP/2 SERVER PACK   srvr na   Essex Systems
+DMSP   OS/2       TCP/2 ADV CLIENT    clnt ?    Essex Systems
+IMAP1  MacOS      MacMS 2.2.1 (obs)   clnt no   sumex-aim.stanford.edu* 7/13/95
+IMAP24 MacOS      Mailstrom 1.04      clnt no   sumex-aim.stanford.edu* 11/7/93
+IMAP24 MacOS      Mailstrom 1.05      clnt no   ftp-camis.stanford.edu 5/21/96
+IMAP24 MacOS      Mailstrom 2(beta)   clnt yes  Tree Star Inc. 12/18/96
+IMAP?  MacOS      Mailstrom           clnt ?    lindy.stanford.edu 9/22/95
+IMAP?  MacOS      Mulberry (beta)     clnt no   mulberry@dial.pipex.com 7/30/96
+IMAP?  MacOS      Mulberry 1.1        clnt ?    CyDaSoft 12/19/96
+IMAPb4 Mac/OT     SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
+IMAPb4 MacOS      SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
+IMAPb4 MS-WIN     SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
+IMAPb4 WIN32      SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
+IMAPb4 Unix/Motif SIMEON 4.1          clnt yes  ESYS Corp www.esys.ca 8/5/96
+IMAP4  ?          SIMEON SERVER       srvr ?    ESYS Corp www.esys.ca 8/1/96
+IMAP2  MacOS      PathWay             clnt no   The Wollongong Group 2/25/94
+IMAP2  Unix/X     PathWay             clnt no   The Wollongong Group 2/25/94
+POP3   MacOS      PathWay             clnt no   The Wollongong Group 2/25/94
+POP3   Unix/X     PathWay             clnt no   The Wollongong Group 2/25/94
+POP3   OS/2       ? (in testing)      srvr no   kf5mg@computek.net 11/28/95
+POP2   MacOS      MacPOP 1.5          clnt ?    ? 10/24/94
+POP2   MS-DOS     PC POP 2.1          clnt ?    ? 10/24/94
+POP3   MacOS      TCP/Connect II      clnt ?    InterCon Systems Corp
+POP3   MS-WIN     TCP/Connect II f W  clnt yes  InterCon Systems Corp 7/8/94
+POP3   NeXT       EasyMail            clnt yes  ftp.cac.washington.edu 11/7/93
+IMAP2  NeXT       MailManager         srvr yes  ftp.cac.washington.edu 11/7/93
+IMAP2  TOPS20     MAPSER              srvr na   ? 11/7/93
+IMAP2  Unix       imap kit            srvr na   ftp.cac.washington.edu 2/1/94
+POP23  Unix       imap kit            srvr na   ftp.cac.washington.edu 2/1/94
+POP23  Unix       IPOP                srvr na   ftp.cac.washington.edu 2/23/96
+IMAP4  Unix       imap4 kit (alpha)   srvr na   ftp.cac.washington.edu 5/31/95
+IMAP24 Unix       Pine 3.90           clnt yes  ftp.cac.washington.edu 9/23/94
+IMAP24 Unix       Pine 3.91           clnt yes  ftp.cac.washington.edu 10/14/94
+IMAP2b Unix       Pine 3.95           clnt yes  ftp.cac.washington.edu 7/30/96
+IMAP24 Unix       Pine 4.0 (future)   clnt yes  ftp.cac.washington.edu 7/30/96
+IMAP24 MS-DOSl+   PC-Pine 3.90        clnt yes  ftp.cac.washington.edu 9/23/94
+IMAP24 MS-DOSl+   PC-Pine 3.91        clnt yes  ftp.cac.washington.edu 10/14/94
+POP23r Unix       popclient x.x (rep) clnt no   Renamed 'fetchmail' 10/7/96
+IMAPb4 Unix       popclient x.x (rep) clnt no   Renamed 'fetchmail' 10/7/96
+POP23r Unix       fetchmail 2.0       clnt no   www.ccil.org/~esr 11/19/96
+IMAPb4 Unix       fetchmail 2.0       clnt no   www.ccil.org/~esr 11/19/96
+POP23r Unix       fetchmail 2.2       clnt no   www.ccil.org/~esr 12/10/96
+IMAPb4 Unix       fetchmail 2.2       clnt no   www.ccil.org/~esr 12/10/96
+POP23r Unix       fetchmail 2.3       clnt no   www.ccil.org/~esr 12/18/96
+POP3k  Unix       fetchmail 2.3       clnt no   www.ccil.org/~esr 12/18/96
+IMAPb4 Unix       fetchmail 2.3       clnt no   www.ccil.org/~esr 12/18/96
+POP23r Unix       fetchmail 2.6       clnt no   www.ccil.org/~esr 12/18/96
+POP3k  Unix       fetchmail 2.6       clnt no   www.ccil.org/~esr 12/18/96
+IMAPb4 Unix       fetchmail 2.6       clnt no   www.ccil.org/~esr 12/18/96
+POP23r Unix       fetchmail 3.3       clnt no   www.ccil.org/~esr 2/4/97
+POP3k  Unix       fetchmail 3.3       clnt no   www.ccil.org/~esr 2/4/97
+IMAPb4 Unix       fetchmail 3.3       clnt no   www.ccil.org/~esr 2/4/97
+POP?   Unix       gwpop               clnt ?    ftp.pasteur.fr 2/9/96
+POP?   Unix       popc                clnt ?    ftp.imag.fr 2/9/96
+POP?   Unix       popmail             clnt ?    ftp.cic.net 2/9/96
+POP?   Unix       movemail            clnt ?    GNU 2/9/96
+IMAP2  VMS        Pine 3.88 port      clnt yes  vms.huji.ac.il 4/12/94
+IMAP?  VMS        Pine in PMDF 4.3    clnt ?    Innosoft 4/1/94
+IMAP2  VMS        ImapD port          srvr yes  vms.huji.ac.il 4/12/94
+POP3u  Win3/95/NT Navigator 2.x       clnt yes  Netscape 7/29/96
+IMAP?  Windows?   pcMail (future)     clnt ?    OzMail 3/19/96
+POP?   Solaris    Navigator 3.0b4(fut)clnt ?    Netscape 6/25/96
+IMAP4  ?          Navigator 4.0 (fut) clnt yes  Netscape 7/30/96
+IMAP4  MacOS      Navigator 4.0 (fut) clnt yes  Netscape 12/18/96
+POP3   Macintosh6 Eudora 1.3.1        clnt no   ftp.qualcomm.com 7/14/94
+POP3   Mac7/PM7   Eudora 1.5.3        clnt yes  ftp.qualcomm.com 8/4/95
+POP3mr Macintosh7 Eudora 2.0.2        clnt yes  Qualcomm 5/10/94
+POP3mr Mac7/PM7   Eudora 2.0.3        clnt yes  Qualcomm 9/13/94
+POP3mrkMac7/PM7   Eudora 2.1          clnt yes  Qualcomm 9/13/94
+POP3mrkMac7/PM7   Eudora 2.1.1        clnt yes  Qualcomm 8/4/95
+POP3mrkMac7/PM7   Eudora 2.1.2        clnt yes  Qualcomm 8/4/95
+POP3mrkMac7/PM7   Eudora 2.1.3        clnt yes  Qualcomm 8/4/95
+POP3   MS-WINw    Eudora 1.4.4        clnt yes  ftp.qualcomm.com 6/23/95
+POP3   MS-WINw    Eudora 1.5.2b1      clnt yes  ftp.qualcomm.com 8/4/95
+POP3   MS-WINw    Eudora 2.0.3        clnt yes  Qualcomm 9/13/94
+POP3   MS-WINw    Eudora 2.1.1        clnt yes  Qualcomm 8/4/95
+POP3   WIN32      Eudora Pro 2.2b8    clnt yes  Qualcomm 12/5/95
+POP3   WIN3/95/NT Eudora Pro ?        clnt yes  Qualcomm 7/29/96
+POP3   Mac        Eudora Pro 3.0      clnt yes  Qualcomm 8/14/96
+POP3   OS/2       PMMail 11           clnt yes  hobbes.nmsu.edu 6/2/95
+POP3   OS/2       POP3D 12            srvr yes  hobbes.nmsu.edu 6/2/95
+POP3   OS/2       POP3D 14A           srvr yes  hobbes.nmsu.edu 9/12/95
+POP3   OS/2       POP3D 14B           srvr yes  hobbes.nmsu.edu 4/5/96
+POP?   OS/2       popsrv99.zip        srvr ?    hobbes.nmsu.edu 2/15/96
+POP3r  OS/2       popsrv10.zip        srvr na   ftp-os2.mnsu.edu 3/15/96
+POP3   MS-WIN     Mi'Mail             clnt yes  http://www.irisoft.be 6/30/95
+
+IMAP2b Unix/XM    ML 1.3.1            clnt yes  ftp-camis.stanford.edu 7/13/95
+IMAP24 Unix/XM    ML 2.0 (future)     clnt yes  Stanford 7/13/95
+IMAP1  Unix       imapd 3.2 (obs)     srvr na   ftp-camis.stanford.edu 7/13/95
+IMAP2b Unix       imapd 3.4/UW        srvr ?    ftp.cac.washington.edu 12/13/94
+IMAP2b Unix       imapd 3.5/UW        srvr ?    ftp.cac.washington.edu 4/25/95
+IMAP2b Unix       imapd 3.6.BETA      srvr ?    ftp.cac.washington.edu 4/25/95
+IMAP2b Unix       imapd 4.0/UW (fut)  srvr ?    U Wash 4/25/95
+IMAP?  Unix       imapd 8.0(124)      srvr ?    U Wash 1/31/97
+IMAP?  Unix       imapd 9.0(161)      srvr ?    U Wash 1/31/97
+IMAP4  ?          imap-4              srvr yes  ftp.cac.washington.edu 10/25/96
+POP3u  ?          imap-4              srvr na   ftp.cac.washington.edu 10/25/96
+IMAP4  ?          imap-4.1 ALPHA      srvr yes  ftp.cac.washington.edu 10/25/96
+POP3u  ?          imap-4.1 ALPHA      srvr na   ftp.cac.washington.edu 10/25/96
+IMAP?  Unix/X     Palm (in dev)       clnt ?    UMiami 11/7/93
+IMAP?  Unix/X     Cyrus (dev on hold) clnt yes  CMU 10/4/94
+IMAP   Unix       Cyrus 1.4           srvr yes  ftp.andrew.cmu.edu 12/1/95
+POP3   Unix       Cyrus 1.4           srvr na   ftp.andrew.cmu.edu 12/1/95
+KPOP   Unix       Cyrus 1.4           srvr na   ftp.andrew.cmu.edu 12/1/95
+POP3u  Unix       Cyrus ?             srvr na   3/12/96
+IMAP41 Unix       Cyrus 1.5           srvr yes  ftp.andrew.cmu.edu 1/3/97
+POP3k  Unix       Cyrus 1.5           srvr na   ftp.andrew.cmu.edu 1/3/97
+KPOP   Unix       Cyrus 1.5           srvr na   ftp.andrew.cmu.edu 1/3/97
+IMAP4  ?          Futr Andrew Msg Sys ?    ?    Carnegie-Mellon 9/20/94
+IMAP?  Xrx Lsp Mc Yes-Way             clnt yes  Stanford U 11/7/93
+IMAP2b MacOS      ECSMail             clnt yes  ESYS Corp www.esys.ca 12/16/96
+IMAP2b MS-WINw    ECSMail             clnt yes  ESYS Corp www.esys.ca 12/16/96
+IMAP2  Unix/XM    ECSMail Motif       clnt yes  ESYS Corp www.esys.ca 12/16/96
+IMAP2b Solaris    ECSMail             clnt yes  ESYS Corp www.esys.ca 12/16/96
+IMAP2  MS-DOS     ECSMail DOS         clnt yes  ESYS Corp www.esys.ca 12/16/96
+IMAP?  NT         ECSMail             clnt yes  ESYS Corp www.esys.ca 12/16/96
+IMAP?  OS/2       ECSMail OS/2        clnt yes  ESYS Corp www.esys.ca 12/16/96
+IMAP?  Unix       UMAIL               clnt no   umail@umail.umd.edu 11/7/93
+IMAP?  Unix       MS                  clnt no   ftp.cac.washington.edu 11/7/93
+IMAP2  MS-WIN     PathWay             clnt no   The Wollongong Group 2/25/94
+POP3   MS-WIN     PathWay             clnt no   The Wollongong Group 2/25/94
+POP?   MS-WIN     PathWay Access 3.0  clnt ?    The Wollongong Group 8/4/94
+POP3   NT         sendmail/POP3 (bet) srvr na   www.metainfo.com 9/15/95
+POP3   NT         sendmail/POP3       srvr na   emwac.ed.ac.uk 12/5/95 (www.emw
+ac.ed.ac.uk)
+IMAP4  NT         sendmail/POP3 (fut) srvr ?    emwac.ed.ac.uk 5/21/96 (www.emw
+ac.ed.ac.uk)
+IMAP2  Amiga      Pine 3.8x (in dev)  clnt yes  UWashington 11/7/93
+POP    MacOS      POPmail 1.7         clnt ?    boombox.micro.umn.edu 9/1/95
+POP23  MacOS      POPmail 2.09b       clnt ?    boombox.micro.umn.edu 9/1/95
+IMAP2  MacOS      POPmail 2.09b       clnt ?    boombox.micro.umn.edu 9/1/95
+POP23  MacOS      POPmail 2.2         clnt ?    boombox.micro.umn.edu 9/1/95
+IMAP2  MacOS      POPmail 2.2         clnt ?    boombox.micro.umn.edu 9/1/95
+POP3   MacOS      POPmail/Lab         clnt ?    boombox.micro.umn.edu 9/1/95
+POP    NeXT OS    BlitzMail           srvr na   ftp.dartmouth.edu 10/23/95
+POP    DEC OSF/1  BlitzMail           srvr na   ftp.dartmouth.edu 10/23/95
+POP    AIX        BlitzMail (in dev)  srvr na   ftp.dartmouth.edu 10/23/95
+POP3   MS-WINw5   POPmail/Lab         clnt ?    boombox.micro.umn.edu 9/1/95
+POP3   MacOS      Emailer 1.1         clnt yes  Claris 7/29/96
+POP3   MacOS      OfficeMail          srvr na   Claris 6/6/96
+IMAP2b Unix       imapperl-0.6        clnt ?    dnpap.et.tudelft.nl 2/6/96
+POP2   MacOS      MailStop 1.1.3      srvr na   boombox.micro.umn.edu 1/18/94
+POP3r  MacOS      MailShare 1.0(beta) srvr na   glenn.anderson@stonebow.otago.a
+c.nz 8/16/94
+POP3r  MacOS      MailShare 1.0fc6    srvr na   ftp.qualcomm.com 8/4/95
+POP3r  MacOS      AIMS 1.0            srvr na   Apple 10/27/95
+POP3r  MacOS      AIMS 1.1            srvr na   Apple 5/21/96 (www.cybertech.ap
+ple.com)
+POP3r  MacOS      AIMS 1.1.1          srvr na   Apple 10/17/96
+POP3r  MacOS      AIMS 2.0 (fut: '97) srvr ?    Apple 10/17/96
+POP3r  MacOS      AIMS 2.1 (fut)      srvr ?    Apple 10/17/96
+IMAP   MacOS      AIMS 2.1 (fut)      srvr ?    Apple 10/17/96
+POP3   MacOS      POPGate 1.1         gway ?    Stalker 3/25/96 (www.stalker.co
+m)
+IMAP?  MacOS      MailDrop 1.1        clnt ?    ackmo.baylor.edu 3/22/96
+IMAP2? MacOS      MailDrop 1.2d6a     clnt ?    ackmo.baylor.edu 3/22/96
+IMAP?  MacOS      MailDrop 2 (dev)    clnt ?    Baylor 1/19/96
+POP2   MS-DOS     LifeLine Mail 2.0   clnt ?    SunSelect 12/7/93
+POP23  MS-DOS     SelectMail 2.1      clnt ?    SunSelect 1/25/94
+POP2   MS-DOSk    ?                   srvr na   ucsd.edu
+POP2   MS-DOSk    net091b             srvr na   boombox.micro.umn.edu 12/3/93
+POP3   MS-DOSk    pop3nos v1.86       srvr na   boombox.micro.umn.edu 12/3/93
+POP2   MS-DOSp    POPMail 3.2.2       clnt ?    boombox.micro.umn.edu 9/1/95
+IMAP?  MS-DOSp    POPMail/PC 3.2.2    clnt ?    boombox.micro.umn.edu 1/11/94
+POP2   MS-DOSp    POPMail 3.2.3 beta2 clnt ?    boombox.micro.umn.edu 9/1/95
+IMAP?  MS-DOSp    POPMail 3.2.3 beta2 clnt ?    boombox.micro.umn.edu 9/1/95
+POP3   MS-DOSk    pop3serv            srvr na   biochemistry.crwu.edu
+POP3   MS-DOSk    nos11c-a.exe        srvr na   biochemistry.bioc.cwru.edu 9/16
+/94
+POP2   MS-DOS     MD/DOS-IP           clnt ?    U Maryland
+POP2   MS-DOS     PC/TCP              clnt ?    FTP Software
+POP2   OS/2       PC/TCP for OS/2     clnt ?    FTP Software 11/2/93
+POP23  MS-WIN     BW-Connect          clnt no   Beame & Whiteside 8/4/94
+POP3   MS-WIN     Air Series 2.06     clnt no   Spry 7/7/94
+IMAP?  MS-WIN     Air Mail            ?    ?    AIR Co. Ltd 9/20/94
+IMAP?  MS-WIN     EMBLA               ?    ?    ICL ProSystems 9/20/94
+IMAP4  ?          Intrnt Msging Srvr  srvr ?    ICL TeamWare 9/8/1
+POP3   ?          Intrnt Msging Srvr  srvr ?    ICL TeamWare 9/8/1
+POP23  MS-DOSp    Minuet 1.0b18a(beta)clnt no   minuet.micro.umn.edu 9/1/95
+POP?   MS-WINls   TCPMail             clnt ?    Pinesoft (pinesoft@net.com)
+POP2   Unix       U Minn popd 1.5c    srvr na   boombox.micro.umn.edu 11/19/93
+POP2   Unix/AIX   aix_new_popd        srvr na   boombox.micro.umn.edu 9/1/95
+POP2   Unix/HP9k  hp9000_popd         srvr na   boombox.micro.umn.edu 9/1/95
+POP23  MS-WINw    POPmail             clnt ?    boombox.micro.umn.edu 9/1/95
+IMAP2  MS-WINw    POPmail             clnt ?    boombox.micro.umn.edu 9/1/95
+POP2   Unix       USC-ISI popd        srvr na   ? 10/24/94
+POP2   Unix       imapd/ipop2d 3.4    srvr na   ftp.cac.washington.edu 12/13/94
+POP3   Unix/curs  Z-Mail Lite 3.2     clnt yes  NetManage 8/23/96 www.netmanage
+.com
+POP3   Unix/line  Z-Mail Lite 3.2     clnt yes  NetManage 8/23/96 www.netmanage
+.com
+POP3   Unix/XM    Z-Mail Motif 3.2.1  clnt yes  NetManage 8/23/96 www.netmanage
+.com
+POP3   WIN3/95/NT Z-Mail 4.0.1        clnt yes  NetManage 8/23/96 www.netmanage
+.com
+POP3   MacOS      Z-Mail 3.3.1        clnt yes  NetManage 8/23/96 www.netmanage
+.com
+IMAP4  WIN3/95/NT Z-Mail Pro          clnt yes  NetManage 8/23/96 www.netmanage
+.com
+IMAP4  WIN3/95/NT Z-Mail Pro 6.0      clnt yes  NetManage 1/31/97 www.netmanage
+.com
+IMAP?  MacOS      Z-Mail ?            clnt yes  NetManage 5/21/96
+POP?   Unix       zync ?              clnt ?    NCD 9/23/94 (www.ncd.com)
+POP23k UnixX      xmh                 clnt ?    ftp.x.org 2/15/94
+POP23k UnixX      exmh                clnt yes  ? 8/8/95
+POP23k UnixX      dxmail/mh           clnt ?    DEC
+POP?   Unix       ucbmail clone       clnt ?    rtfm.mit.edu 12/16/94
+POP?   Unix       pop-perl-1.0        clnt ?    sunsite.unc.edu 9/13/94
+POP?   Unix/XO    SXMail 0.9.74a (b)  clnt ?    ftp.uni-stuttgart.de 10/12/95
+POP2   VM         FAL                 srvr na   IBM
+POP2   MS-WIN     IBM TCP/IP for DOS  clnt no   IBM 7/7/94
+POP2   VM         ?                   srvr na   Texas Tech University
+POP?   VM         ?POPD               srvr na   vmd.cso.uiuc.edu 2/4/94
+POP3   VM         vmpop3.200          srvr na   uriacc.uri.edu 1/10/95
+POP3   MUSIC/SP   POPD 1.0            srvr na   McGill Univ. Sys. Inc. 01/11/95
+POP2   OS/2       TCP/2 SERVER PACK   srvr na   Essex Systems
+POP2   VMS        MultiNet            srvr na   TGV, Inc. 07/26/95
+POP2   HP3000/MPE NetMail/3000        srvr na   3K Associates
+POP3   ?          NetMail/3000        srvr na   3K Associates
+POP3k  MacOS      Eudora 1.3a8k       clnt ?    ftp.brown.edu 8/19/94
+POP3   MacOS      MacPOP (Berkeley)   clnt ?    ftp.cc.berkeley.edu
+POP3k  MacOS      TechMail 2.0        clnt ?    net-dist.mit.edu
+POP3   MacOS      MacMH               clnt ?    jessica.stanford.edu/info
+POP3   MacOS      VersaTerm Link      clnt ?    Synergy Software 10/8/93
+POP3   MacOS      LeeMail 2.0.2 (shw) clnt ?    chs.cusd.claremont.edu 10/12/93
+POP3   Mac7pro    Mail*Link Internet  clnt yes  StarNine Technologies 2/18/94
+POP3t  Unix       popper-1.7          srvr na   ftp.cc.berkeley.edu 10/15/93
+POP3k  Unix       popper-1.7k         srvr na   ftp.brown.edu 10/19/94
+POP3k  Unix       hacked ucbmail      clnt no   UCSC 6/29/95
+POP3k  Unix       hacked pine         clnt yes  UCSC 6/29/95
+POP3   Unix       popper-1.831        srvr na   ftp.cc.berkeley.edu 11/3/93
+POP3   Solaris2.X popper-1.831/uore   srvr na   ftp.uoregon.edu 10/19/93
+POP3   Solaris2.X popper-1.9          srvr na   ftp.chalmers.se 7/26/94
+POP3   Unix       popperQC3           srvr na   ftp.qualcomm.com 8/4/95
+POP3   Unix       qpopper 2.1.3-r5    srvr na   ftp.qualcomm.com 8/4/95
+POP3   Unix       qpopper 2.1.4-r1    srvr na   ftp.qualcomm.com 8/4/95
+POP3u  Unix       qpopper 2.1.4-r3    srvr na   ftp.qualcomm.com 2/26/96
+POP3u  Unix       qpopper 2.1.4-r4    srvr na   QualComm 5/16/95
+POP3r  Unix       Vers of qpopper     srvr na   QualComm 1/26/96
+POP3u  Unix       qpopper 2.2 beta    srvr na   Qualcomm 2/26/96
+POP?   Unix       zpop                srvr na   NCD 9/1/95
+POP3   Unix       popper.rs2          srvr na   ftp.qualcomm.com 8/4/95
+POP3   Unix       perl popper         srvr na   ftp.xensei.com/users/ccrlphr 9/
+1/95
+POP23k Unix       mh-6.8 (UCI RandMH) both yes  ftp.ics.uci.edu 8/30/94
+POP23krUnix       mh-6.8.3 (UCI RndMH)both yes  ftp.ics.uci.edu 9/27/94
+POP23  Unix/EMACS RMAIL               clnt no   ? 8/2/95
+POP23  Unix/EMACS vm                  clnt no   ftp.uu.net 8/2/95
+POP3   Linux      miniclient          clnt ?    sunsite.unc.edu 8/30/94
+POP3   Unix       imapd/ipop3d 3.4    srvr na   ftp.cac.washington.edu 12/13/94
+POP3   Unix       pop3d 1.004         srvr na   ftp.ucdavis.edu 12/3/93
+POP2   Unix       pop2d 1.001         srvr na   ftp.ucdavis.edu 12/3/93
+POP3   Unix       mush 7.2.5          clnt ?    ? 12/16/94
+POP23k Unix       popmaild            srvr na   ftp.wu-wien.ac.at 4/5/95
+IMAP   AIX        imap server         srvr ?    ftp.wu-wien.ac.at 4/5/95
+POP3   MacOS/AOCE MailConnect         clnt yes  ? 7/5/95
+POP3t  MS-DOSnpo  PC/TCP              clnt ?    FTP Software
+POP3   OS/2       PC/TCP for OS/2     clnt ?    FTP Software 11/2/93
+POP3   MS-DOS     TechMail(future)    clnt ?    ?
+POP3   MS-WINl    TechMail for Wind.  clnt ?    net-dist.mit.edu 2/25/94
+POP3   OS/2l      TechMail for Wind.  clnt ?    net-dist.mit.edu 2/25/94
+POP3   MS-DOSp    NUPop 1.03          clnt no   ftp.acns.nwu.edu 11/5/93
+POP3   MS-DOSp    NUPop 2.02          clnt no   ftp.acns.nwu.edu 1/18/94
+POP3   MS-DOSp    NUPop 2.10 (alpha)  clnt yes  ftp.acns.nwu.edu 6/10/94
+POP23  MS-WINw    Trumpet             clnt no   ftp.psychol.utas.edu.au 7/7/94
+POP3   MS-WIN     Pceudora            clnt ?    ftp.qualcomm.com 9/24/93
+POP3   MS-WINw    WinPmail 2.0b4      clnt ?    risc.ua.edu 6/6/95
+POP3   MS-DOSp    POPgate (Pmail gw)  clnt ?    risc.ua.edu 4/1/94
+POP3   MS-DOSl    PMPOP (Pmail gw)    clnt ?    risc.ua.edu 4/1/94
+POP3x  MS-WIN     WinQVT (2.1)        clnt ?    QPC Software (shareware) 7/12/9
+4
+POP3   MS-WINp    wnqvtnet 3.0        clnt ?    ftp.cica.indiana.edu
+POP3   MS-WINp    wnqvtnet 3.9        clnt ?    ftp.cica.indiana.edu 2/1/94
+POP3   MS-WIN     Open Systems Mail   clnt ?    Pine Software
+POP3   MS-WIN?    IMAIL               both ?    Ipswitch 7/12/94
+POP3   NT         Ipswitch            srvr ?    Ipswitch 5/24/96
+POP3   VMS        IUPOP3 v1.7         srvr na   ftp.indiana.edu 7/25/94
+POP3   VMS        IUPOP3 v1.7-CMU-TEK srvr na   ftp.indiana.edu 7/25/94
+POP3   VMS        IUPOP3 v1.8-1       srvr na   ftp.indiana.edu 7/25/94
+POP3   MS-DOS     POP3 0.9            clnt na   ftp.indiana.edu 7/25/94
+POP3   VMS        MultiNet            both ?    TGV, Inc. 07/26/95
+POP3   VMS        PMDF 5.1            srvr na   Innosoft 9/24/96 www.innosoft.c
+om
+POP3   Solaris    PMDF 5.1            srvr na   Innosoft 9/24/96 www.innosoft.c
+om
+POP3   DigUNIX    PMDF 5.1            srvr na   Innosoft 9/24/96 www.innosoft.c
+om
+POP3   OpenVMS    PMDF 5.1            srvr na   Innosoft 9/24/96 www.innosoft.c
+om
+IMAP?  VMS        PMDF 5.1            srvr ?    Innosoft 9/24/96 www.innosoft.c
+om
+IMAP?  Solaris    PMDF 5.1            srvr ?    Innosoft 9/24/96 www.innosoft.c
+om
+IMAP?  DigUNIX    PMDF 5.1            srvr ?    Innosoft 9/24/96 www.innosoft.c
+om
+IMAP?  OpenVMS    PMDF 5.1            srvr ?    Innosoft 9/24/96 www.innosoft.c
+om
+IMAP?  MS-DOS     PMDF E-mail Interc  clnt ?    Innosoft 3/2/94 www.innosoft.co
+m
+IMAP?  MacOS      PMDF E-mail Interc  clnt ?    Innosoft 3/2/94 www.innosoft.co
+m
+POP?   VMS        PMDF E-mail Interc  ?    ?    Innosoft 6/24/96 www.innosoft.c
+om
+IMAP?  VMS        PMDF E-mail Interc  ?    ?    Innosoft 6/24/96 www.innosoft.c
+om
+POP3r  VMS        PMDF popstore       clnt ?    Innosoft 9/24/96 www.innosoft.c
+om
+IMAP4  SolarisX   Roam (Future)       clnt ?    Sun 9/26/95
+IMAP?  Windows?   Roam (Future)       clnt ?    Sun 3/19/96
+IMAP4  SolarisX   imapd (Future)      clnt ?    Sun 9/26/95
+IMAP4  Solaris    Solstice IMS1.0     srvr yes  SunSoft 10/17/96 http://www.sun
+.com
+POP3   Solaris    Solstice IMS1.0     srvr yes  SunSoft 10/17/96 http://www.sun
+.com
+
+IMAP4  Solaris    Solstice IMS2.0 (f) srvr yes  SunSoft 10/17/96 http://www.sun
+.com
+POP3   Solaris    Solstice IMS2.0 (f) srvr yes  SunSoft 10/17/96 http://www.sun
+.com
+IMAP4  Solaris    Solstice IMC0.9     clnt yes  SunSoft 4/5/96 http://www.sun.c
+om
+IMAP4  Solaris    Solstice IMC? (fut) clnt yes  SunSoft 4/5/96 http://www.sun.c
+om
+IMAP4  MS-WIN3.11 Solstice IMC0.9     clnt yes  SunSoft 4/5/96 http://www.sun.c
+om
+IMAP4  MS-WIN3.11 Solstice IMC? (fut) clnt yes  SunSoft 4/5/96 http://www.sun.c
+om
+IMAP4  MS-WIN95   Solstice IMC0.9     clnt yes  SunSoft 4/5/96 http://www.sun.c
+om
+IMAP4  MS-WIN95   Solstice IMC? (fut) clnt yes  SunSoft 4/5/96 http://www.sun.c
+om
+IMAP4  NT         Solstice IMC0.9     clnt yes  SunSoft 4/5/96 http://www.sun.c
+om
+IMAP4  NT         Solstice IMC? (fut) clnt yes  SunSoft 4/5/96 http://www.sun.c
+om
+IMAP4  Win95      SOlstice 2.0        clnt ?    SunSoft 1/31/97
+POP3   OS/2       TCP/2 SERVER PACK   srvr na   Essex Systems
+POP3   OS/2       TCP/2 ADV CLIENT    clnt ?    Essex Systems
+POP?   MS-DOS     UCDmail             clnt ?    ftp.ucdavis.edu 10/24/94
+POP?   MS-DOS     PC POP              clnt ?    ?Bill Schweickert/Sterling Fed
+POP23  MS-WINnpo  Super-TCP for W e.0 clnt yes  Frontier Technologies 6/10/94
+POP?   MS-WINnpo  Super-TCP for W e.0 srvr yes  Frontier Technologies 7/12/94
+POP3   WIN3/95/NT SuperHghwy Access 2 clnt yes  Frontier Technologies 7/29/96
+POP?   MS-WINw    Windows ELM         clnt ?    lister.cc.ic.ac.uk 7/12/94
+IMAP?  ?          ELM patches         clnt ?    www.math.fu-berlin.de/~guckes/e
+lm/patches 7/16/96
+POP23  MS-DOSni   ChameleonNFS        both ?    NetManage 8/4/94
+POP23  MS-DOSni   Chameleon beta      clnt yes  NetManage
+POP23  MS-WINw    Internet Chameleon  clnt yes  NetManage 7/12/94
+POP23  NT         Chameleon V5.0 f NT both ?    NetManage 11/28/95
+IMAP?  Windows?   Chameleon (future)  clnt ?    NetManage 3/19/96
+POP?   MacOS      MEWS                clnt ?    ?
+POP?   MacOS      byupopmail          clnt ?    ?
+POP?   VM         ?                   srvr na   TTUVM1
+POP3   MacOS      HyperMail           ?    ?    ?
+?      OS/2       lamailpop           ?    ?    ftp-so2.cdrom.com
+POP?   OS/2       Popclient           clnt yes  ? 1/19/96
+POP?   OS/2       Emacs 19.xx         clnt yes  ? 1/19/96
+POP3   MS-DOSs    pcelm               clnt ?    lister.cc.ic.ac.uk 1/25/94
+POP3   MS-WINs    winelm              clnt ?    lister.cc.ic.ac.uk 1/25/94
+POP3   NetWare    Mercury 1.11        srvr na   risc.ua.edu 2/4/94
+POP3   NetWare34  Mercury 1.2.1       srvr na   risc.ua.edu 3/29/96
+POP3   NetWare34  Mercury 1.3         srvr na   risc.ua.edu 8/2/96
+POP3   MS-WINw    IMail               srvr na   Ipswitch 7/15/94
+POP3   MS-Windows Pegasus/Win 2.3     clnt ?    risc.ua.edu 6/6/96
+POP3   MS-Windows Pegasus/Win 2.2(r3) clnt ?    risc.ua.edu 6/6/96
+POP3   MS-Windows Pegasus/Win 2.0(r1) clnt ?    risc.ua.edu 6/6/96
+POP3   MS-DOS     Pegasus/DOS 3.2(r2) clnt ?    risc.ua.edu 6/6/96
+POP3   MacOS      Pegasus/MAC 2.1.2   clnt ?    risc.ua.edu 6/6/96
+POP23  MS-WINw    Mail-IT 2           clnt yes  mail-it@unipalm.co.uk 7/12/94
+POP23  Unix       Mail-IT 2           clnt yes  mail-it@unipalm.co.uk 9/9/94
+POP23  Unix       servers w Mail-IT   srvr na   mail-it@unipalm.co.uk 12/16/94
+POP?   MS-WIN     RFD Mail 1.22       clnt ?    ftp.std.com 7/19/94
+POP?   MS-WIN     RFD Mail 1.23       clnt ?    ftp.std.com 9/16/94
+POP3   MS-WINw    ws_gmail            srvr na   buckshot.usma.edu 9/16/94
+POP3   MS-WINw    IMAIL               srvr na   Ipswitch 9/16/94
+POP3   MS-WINw    Pronto Mail 2.01    clnt yes  Commtouch 4/24/96 (www.commtouc
+h.com)
+IMAP   MS-WINw    Pronto              clnt yes  Commtouch 9/5/95
+IMAP4  ?          Pronto97            clnt yes  CommTouch 1/7/97 (www.commtouch
+.com)
+POP3   ?          Pronto97            clnt yes  CommTouch 1/7/97 (www.commtouch
+.com)
+POP23  MS-WINw    Turnpike            clnt yes  Turnpike Ltd, http:www.turnpike
+.com 8/11/95
+POP3   MS-WIN     WinSmtp             srvr na   Seattle Labs, http://wildside.k
+wnet.on.ca/winsmtp.html 11/3/95
+POP3r  WIN95      SLmail95            srvr na   http://www.seattlelab.com/ 5/14
+/96
+POP3r  NT         SLmailNT            srvr na   http://www.seattlelab.com/ 3/29
+/96
+POP3   ?          VA Professional     clnt yes  Ashmount 4/30/96 http://www.asn
+mount.com
+POP3   ?          VA Workgroup        clnt yes  Ashmount 4/30/96 http://www.asn
+mount.com
+POP3   NT         post.office         srvr na   Software.com, Inc. 12/11/95 (ww
+w.software.com)
+POP3   Solaris    post.office         srvr na   Software.com, Inc. 12/11/95 (ww
+w.software.com)
+POP?   MS-?       Exchange            clnt ?    Microsoft 10/24/95
+POP3   MS-?       Exchange Server (f) srvr yes  Microsoft 9/11/96
+IMAP4  MS-?       Exch Server (maybe) srvr ?    Microsoft 6/21/96
+POP3   MS-?       Exchange Server 5.0 srvr ?    Microsoft 1/14/97
+POP3   MS-?       Inter. Mail & News  clnt yes  Microsoft 6/4/96 (www.microsoft
+.com)
+POP3   MS-?       Inter. Mail Service gway ?    Microsoft 6/4/96 (www.microsoft
+.com)
+POP3u  NT         Exchpop(?) 1.0      gway yes  http://www.sts.co.il/pop3.htm 6
+/14/96
+POP3   MacOS      Powertalk           ?    ?    ? 11/7/95
+IMAP2  MS-WIN     Siren Mail          clnt yes  Siren Software 12/28/95
+IMAP?  Windows?   Siren Mail 3.0      clnt yes  Siren Software 3/19/96
+POP3   MS-WIN     Siren Mail          clnt yes  Siren Software 12/28/95
+IMAP2  WIN95      Siren Mail          clnt yes  Siren Software 12/28/95
+POP3   WIN95      Siren Mail          clnt yes  Siren Software 12/28/95
+IMAP2  NTclient   Siren Mail          clnt yes  Siren Software 12/28/95
+POP3   NTclient   Siren Mail          clnt yes  Siren Software 12/28/95
+?      Unix       Siren Mail          srvr ?    Siren Software 12/28/95
+IMAP2  ?          Siren Mail Server   srvr ?    Siren Software 8/1/96
+POP3   ?          Siren Mail Server   srvr ?    Siren Software 8/1/96
+IMAP4  ?          Siren Mail (future) clnt yes  Siren Software 12/28/95
+IMAP?  MacOS      Siren Mail (future) clnt yes  Siren Software 1/21/96
+IMAP?  WIN95      Siren Mail (beta)   clnt yes  Siren Software 7/30/96
+POP3   MacOS      NetAlly             srvr na   Delphic (www.delphic.com) 11/17
+/95
+POP3   DOSWIN     BeyondMail          clnt yes  Banyan (beyondmail.banyan.com)
+2/6/96
+IMAP4  ?          BeyondMail (future) clnt yes  Banyan (beyondmail.banyan.com)
+9/6/96
+POP?   NT         MailSrv from Res K. srvr na   Microsoft?
+IMAP   WIN?       ?                   clnt ?    Email connection 12/8/95
+POP3   NetWare34  SoftNet WEBserv     srvr na   Puzzle Systems 12/15/95 (info@p
+uzzle.com)
+POP3   NT         Netscape Mail Srvr  srvr na   Netscape 12/18/95 (info@netscap
+e.com)
+POP3   SunOS      Netscape Mail Srvr  srvr na   Netscape 12/18/95 (info@netscap
+e.com)
+POP3   Solaris    Netscape Mail Srvr  srvr na   Netscape 12/18/95 (info@netscap
+e.com)
+IMAP4  NT         Netscape M S 2.0(f) srvr ?    Netscape 6/21/96
+IMAP4  NT         Netscape M S 2.02   srvr ?    Netscape 1/31/97
+POP3   OpenVMS    TCPware Internet Sr srvr na   Process Software 12/20/95 (info
+@process.com)
+POP3   Unix       UMT (beta)          clnt ?    ftp.topaz.kiev.ua 12/29/95 (www
+.topaz.kiev.ua)
+POP3   NetWare 4  LAN WorkGroup 5     ???? na   Novell 1/1/96
+IMAP2  Solaris    MMail               clnt yes  Atelier de Software Ltd. 5/21/9
+6
+IMAP2  MacOS      MMail (planned)     clnt yes  Atelier de Software Ltd. 5/21/9
+6
+POP?   OS/2       Yarn/Souper(?)      clnt ?    ? 1/16/96
+POP3   NT         Sendmail w POP3 1.0 srvr na   MetaInfo 1/19/96 http://www.met
+ainfo.com
+POP3   NT         Sendmail w POP3 1.1 srvr na   MetaInfo 12/4/96 http://www.met
+ainfo.com
+POP3   ?          PopGate             gway na   ftp.esi sys.com 1/19/96
+POP3   OS/2       ? (future)          srvr na   Secant 1/23/96
+?POP3  NT         NT MAIL             ?    ?    http://bhs.com 1/26/96
+POP3   NT         MAILbus Internet    srvr na   Digital 2/20/96 (www.digital.co
+m)
+POP3   DEC UNIX   MAILbus Internet    srvr na   Digital 2/20/96 (www.digital.co
+m)
+POP3r  NT         MAILbus Internet(b) srvr na   Digital 2/20/96 (www.digital.co
+m)
+POP3r  DEC UNIX   MAILbus Internet(b) srvr na   Digital 2/20/96 (www.digital.co
+m)
+POP?   OS/2       lampop(?)           clnt ?    ? 1/26/96
+POP?   NT         NTMail              clnt ?    www.mortimer.com 2/9/96
+POP3   DOSWINMac  OpenMail (future)   clnt ?    HP 3/29/96 http://www.openmail.
+external.hp.com
+IMAP   DOSWINMac  OpenMail (future)   clnt ?    HP 3/29/96 http://www.openmail.
+external.hp.com
+POP3   NetWare4   Connect2SMTP        srvr ?    Infinite Technologies 3/29/96
+POP3   OS/2       PowerWeb Server++   srvr na   CompuSource 4/16/96 http://www.
+compusource.co.za
+POP3   OS/2       SIDIS/2             srvr na   stargate.rz.fh-offenburg.de 6/4
+/96
+POP3   ?          WIG v2.0            gway ?    http://www.demon.co.uk/ 4/19/96
+POP3   WIN95      Windis32            srvr na   Demon Internet 6/6/96 (www.demo
+n.co.uk)
+POP3   DOSWINMac  DaVinci SMTP eMAIL  clnt yes  On Technology 4/24/96
+POP?   WIN32      Mail OnNet (OnNet32)clnt yes  FTP Software 5/3/96 (www.ftp.co
+m)
+POP?   Unix       xfmail              clnt ?    burka.netvision.net.il 5/110/96
+POP3rutOS/2       POP3s v1.01         srvr ?    www.secant.com 5/14/96
+POP3   Java Aplt  Yamp                clnt ?    www.mcs.net/~faisal/Yamp/yampix
+.html 5/24/96
+POP3   NT         NT Mail             gway ?    www.net-shopper.co.uk 5/31/96
+POP3   WIN?       Mailcall            chkr na   ? 6/11/96
+POP3   WIN?       Mailcheck           chkr na   ? 6/11/96
+POP3   DOS        C2SMTP              srvr na   Infinite Technologies 6/11/96
+POP    MacOS      Quarterdeck v4(fut) clnt yes  Starnine 6/11/96 (www.starnine.
+com)
+POP    MacOS      List Star           ?    ?    Starnine 6/24/96 (www.starnine.
+com)
+POP3   MacOS      Marionet 1.0        srvr na   Allegiant 6/12/96 (www.allegian
+t.com)
+POP3   ?          Mailcoach V1.0      srvr na   http://www.multi.se/ymex/mailco
+ach.htm 6/14/96
+IMAP4  WIN3/NT/95 JetMail             clnt yes  NetManage 7/29/96
+POP3   WIN3/NT/95 JetMail             clnt yes  NetManage 7/29/96
+POP3   NT         Post.Office         srvr na   NetManage 8/22/96 www.netmanage
+.com
+POP3   SunOS      Post.Office         srvr na   NetManage 8/22/96 www.netmanage
+.com
+POP3   Solaris    Post.Office         srvr na   NetManage 8/22/96 www.netmanage
+.com
+POP3   Unix       Z-Pop 1.0           srvr na   NetManage 8/22/96 www.netmanage
+.com
+POP3   AppleShare FutureShare (fut)   srvr na   Apple 6/14/96
+POP?   ?          Applixware          ?    ?    Applix 6/24/96
+POP3   Unix       Mail*Hub            srvr ?    CDC 10/23/96 www.cdc.com
+IMAP4  Unix       Mail*Hub            srvr ?    CDC 10/23/96 www.cdc.com
+POP?   Unix       TkRat               clnt ?    www.dtek.chalmers.se/~maf/ratat
+osk 6/24/96
+IMAP?  Unix       TkRat               clnt ?    www.dtek.chalmers.se/~maf/ratat
+osk 6/24/96
+IMAP?  Unix       Elm                 clnt ?    ? 7/1/96
+POP3   WIN16/32   Virtual Access      clnt yes  www.ashmount.com 8/9/96
+POP3   ?          pop-perl5           clnt ?    ? 7/23/96
+POP3   WIN95      Agent               clnt ?    ? 7/23/96
+POP3   ?          Mail eXtension 1.60 clnt ?    Terckland 7/26/96 (ourworld.com
+puserve.com/homepages/mailx)
+POP3   WIN3/95/NT Emissary Office 1.1 clnt yes  Attachmate 7/29/96
+POP3   WIN3/95    Pronto Mail 2.0     clnt yes  CommTouch 7/29/96
+POP3   ?          gcMail 081b (beta)  clnt ?    www.greencedars.com 8/9/96
+POP3r  Java       shareware Java cls  clnt ?    Koehn Consulting 8/2/96
+POP3   ?          cucipop (future)    srvr na   cuci.nl 8/6/96
+POP3   MacOS      QuickMail Pro       clnt ?    CE Software www.cesoft.com 12/1
+9/96
+POP3   ?          QuickMail Pro (fut) clnt ?    CE Software www.cesoft.com 8/9/
+96
+IMAP?  ?          QuickMail Pro (fut) clnt ?    CE Software www.cesoft.com 8/9/
+96
+POP3   ?          QuickMail POP (fut) clnt ?    CE Software www.cesoft.com 8/9/
+96
+POP3   ?          QM-Internet Gateway ?    ?    CE Software 6/24/96
+POP3   ?          Lotus Notes 4.5 srv srvr ?    Lotus 10/17/97
+POP3   Be         BeMail              clnt ?    www.be.com 11/25/96
+POP3   NT         Metainfo/Intergate  srvr na   ? 11/26/96
+POP3   Java       Novita Mail         clnt ?    Novita Comm 12/10/96
+IMAP?  Java       Novita Mail         clnt ?    Novita Comm 12/10/96
+IMAP?  Windows    Winbox 3.1 Beta 1   clnt ?    ftp.uv.es 12/13/96
+POP?   Windows    Winbox 3.1 Beta 1   clnt ?    ftp.uv.es 12/13/96
+POP3   MacOS      Bluto (future)      clnt yes  Bare Bones www.barebones.com 12
+/18/96
+POP3   WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
+com 1/14/97
+IMAP   WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
+com 1/14/97
+------ ---------- ------------------- ---- ---- -------------------------------
+
+   
+     _________________________________________________________________
+   
+Some other packages for desktop systems
+
+
+------ ---------- ------------------- ---- ---- -------------------------------
+?      MS-DOSs    CMM                 peer ?    Cinetic Systems 1/25/94
+?      MS-DOSs    WinMail 1.1a        peer ?    Obsolete
+SMTP   MacOS      LeeMail 1.2.4       peer ?    Shareware, laf@mitre.org
+SMTP   MacOS      LeeMail 2.0.2 (shw) peer ?    chs.cusd.claremont.edu 10/12/93
+SMTP   MS-DOSni   ChameleonNFS        peer ?    NetManage 2/25/94
+SMTP   MS-WINw    ws_gmail            peer ?    buckshot.usma.edu 5/26/94
+uucp   MacOS      FernMail            peer ?    Shareware, dplatt@snulbug.mtvie
+w.ca.us
+prop   MacOS      MacPost             both ?    ftp.lu.se 10/19/93
+uucp   MacOS      Eudora >1.3.1       peer yes  ftp.qualcomm.com 5/10/94
+MAPI   WIN3/95/NT Eudora Pro ?        clnt yes  Qualcomm 7/29/96
+uucp   MacOS      UUPC                peer ?    dplatt@snulbug.mtview.ca.us
+uucp   MacOS      gnuucp              peer ?    jim@fpr.com
+uucp   MS-DOS     waffle              peer ?    ? dell@vox.darkside.com 10/24/9
+4
+uucp   MS-DOS     UUPC                peer ?    ? help@kew.com 10/24/94
+fshare MS-Windows Pegasus/Win 2.3     clnt ?    risc.ua.edu 6/6/96
+fshare MS-Windows Pegasus/Win 2.2(r3) clnt ?    risc.ua.edu 6/6/96
+fshare MS-Windows Pegasus/Win 2.0(r1) clnt ?    risc.ua.edu 6/6/96
+fshare MS-DOS     Pegasus/DOS 3.2(r2) clnt ?    risc.ua.edu 6/6/96
+fshare MacOS      Pegasus/MAC 2.1.2   clnt ?    risc.ua.edu 6/6/96
+fshare MS-Windows Pegasus/Win 2.4.2   clnt ?    risc.ua.edu 8/2/96
+fshare MS-DOS     Pegasus/DOS 3.3.1   clnt ?    risc.ua.edu 8/2/96
+SMTP   MS-DOS     Charon              gway ?    risc.ua.edu 10/15/93
+Waffle MS-WIN     Boxer               clnt ?    ftp.halcyon.com 12/3/93
+?      MS-?       pcelm               clnt ?    simtel 12/3/93
+?      MS-?       elm-pc              clnt ?    lister.cc.ic.ac.uk 12/3/93
+SMTP   MS-WINw    Internt Ex for cc:m gway yes  IMA 1/31/94
+SMTP   Netware    Mercury 1.11        gway ?    risc.ua.edu 2/4/94
+?      MacOS      PowerMail           clnt ?    Apple 2/18/94
+SMTP   OS/2       PC/TCP v1.3         peer ?    FTP Software 2/18/94
+MAPI   MS-DOS?    Microsoft Mail      clnt ?    Microsoft 3/2/94
+?      MacOS      Microsoft Mail      clnt ?    Microsoft 3/15/94
+VIM    DOSWINMac  cc:mail             clnt ?    Lotus 3/15/94
+MHS/G  DOSWINMac  DaVinci eMAIL       clnt ?    On Technology 4/24/96
+P7uucp DOSWINMac  OpenMail            clnt ?    HP 3/2/94
+?      DOSWINMac  WordPerfect Office  clnt ?    WordPerfect Corp. 3/15/94
+?      DOSMac     MailWorks           clnt ?    DEC 3/2/94
+MHS/G  DOSWIN     BeyondMail          clnt yes  Banyan (beyondmail.banyan.com)
+2/6/96
+?      DOSOS/2    Higgins Mail        clnt ?    Enable Software 1/26/95
+?      MacOS      QuickMail 3.6       clnt ?    CE Software 6/6/96
+?      DOS        QuickMail 3.0       clnt ?    CE Software 6/6/96
+?      MS-WIN     QuickMail 3.5       clnt ?    CE Software 6/6/96
+?      MacOS      QuickMail 4.0 (fut) clnt ?    CE Software 6/6/96
+?      ?          QuickMail ?         clnt yes  CE Software 7/15/96
+?      MS-WIN     Team                clnt ?    Futurus 1/26/95
+?      DOSWIN     ExpressIT!          clnt ?    Infinite Technologies 1/26/95
+MAPI   WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
+com 1/14/97
+MHS    WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
+com 1/14/97
+VIM    WIN95/NT   ExpressIT! 2000     clnt ?    Infinite Technologies www.ihub.
+com 1/14/97
+?      ?          GroupWise           cnlt ?    Novell 1/26/95
+?      DOSWINMac  Lotus Notes         clnt ?    Lotus 3/15/94
+FCP    MacOS      FirstClass 2.5      clnt no   SoftArc 7/12/94
+FCP    MS-WIN     FirstClass 2.5      clnt no   SoftArc 7/12/94
+FCP    MacOS      FirstClass 2.5      srvr no   SoftArc 7/12/94
+MHS    MacOS      FirstClass/MHS      gway no   SoftArc 7/12/94
+UUCP   MacOS      FirstClass/UUCP     gway no   SoftArc 7/12/94
+MAPI   MS-WINw    Mail-IT 2           clnt yes  mail-it@unipalm.co.uk 7/12/94
+MAPI   ?          ECSmail             clnt ?    ESYS Corp www.esys.ca 12/16/96
+VIM    ?          ECSmail             clnt ?    ESYS Corp www.esys.ca 12/16/96
+MAPI   MS-WIN     SIMEON 4.1          clnt ?    ESYS Corp 222.esys.ca 12/16/96
+MAPI   WIN3/95/NT Z-Mail 4.0.1        clnt yes  NetManage 8/22/96 www.netmanage
+.com
+MAPI   MS-WIN     Air Mail            ?    ?    AIR Co. Ltd 10/7/94
+MAPIs  MS-WIN     Siren Mail          ?    ?    Siren Software 12/28/95
+MAPIs  WIN95      Siren Mail          ?    ?    Siren Software 12/28/95
+MAPIs  NTclient   Siren Mail          ?    ?    Siren Software 12/28/95
+SMTP   MS-WINw    Mail-IT 2           peer yes  mail-it@unipalm.co.uk 7/12/94
+?      MS-WINw    Panda               ?    ?    ftp.cica.indiana.edu 7/12/94
+PSS    MS-Win     pMail 3.0           clnt no   CommTouch 9/27/94
+PSS    MS-DOS     pMail 3.0           clnt no   CommTouch 9/27/94
+PROP   MacOS      BlitzMail           clnt no   ftp.dartmouth.edu 10/23/95
+PROP   NeXT OS    BlitzMail           srvr no   ftp.dartmouth.edu 10/23/95
+PROP   DEC OSF/1  BlitzMail           srvr no   ftp.dartmouth.edu 10/23/95
+PROP   AIX        BlitzMail (in dev)  srvr no   ftp.dartmouth.edu 10/23/95
+PROP   ?          FreeMail            ?    ?    whttp://www.montana.com/freemai
+l 95/12/8
+PROP   MacOS      CommuniGate         both ?    Stalker 5/21/96 (www.stalker.co
+m)
+SMPT   MacOS      SMTPGate            gway ?    Stalker 3/25/96 (www.stalker.co
+m)
+UUCP   MacOS      UUCPGate            gway ?    Stalker 3/25/96 (www.stalker.co
+m)
+?      MacOS      Quarterdeck Mail    both yes  Starnine 6/11/96 (www.starnine.
+com)
+MAPI   WIN3/NT/95 JetMail             clnt yes  NetManage 7/29/96
+------ ---------- ------------------- ---- ---- -------------------------------
+
+   
+     _________________________________________________________________
+   
+Key and Other Issues
+
+
+(a) What are the common extensions to POP3 and which clients/servers
+ support them?
+POP3k - Kerberos
+POP3a - AFS Kerberos
+POP3x - ?
+POP3t - xtnd xmit facility--allows client to send mail through additional
+ POP commands, thus allowing server to verify/log source of mail.
+POP3r - APOP
+POP3m - ?
+POP3u - with UIDL command.
+(b) What DOS protocol stacks are supported?
+MS-DOSm - Lan Manager
+MS-DOSn - NDIS Drivers
+MS-DOSl - Lan Workplace for Dos
+MS-DOSs - Sun PCNFS
+MS-DOSp - Packet Drivers
+MS-DOSo - ODI Drivers
+MS-DOSi - IPXLink
+MS-DOSf - FTP Software PC/TCP
+MS-DOSk - KA9Q I think
+MS-WIN? - similar
+MS-WINw - WinSock compliant
+MS-WIN5 - Windows 95
+WIN3 - Windows 3.x winsock
+WIN3/95/NT - Windows 3.x Winsock, Windows 95 and Windows NT
+WIN3/95 - Windows 3.x Winsock and WIndows 95
+NetWare3 - NetWare 3.x
+NetWare4 - NetWare 4.x
+NetWare34 - NetWare 3.x and 4.x
+(c) Other notes
+IMAP1 - Original IMAP: I've heard that MacMS actually uses a unique
+        dialect of it.  Definitely obselete, unsupported, discouraged.
+IMAP2b - IMAP2bis: name applied to various improved versions of IMAP2.
+ This development effort culminated in IMAP4.
+IMAP24 - IMAP2 or IMAP4
+fshare - uses file sharing.
+IMAPb4 - IMAP2, IMAP2bis, or IMAP4.
+IMAP41 - IMAP4rev1
+MAPI - Microsoft's Messaging API
+MAPIs - Simple MAPI.
+VIM - Lotus's Vendor Independent Messaging API
+CMC - XAPIA's Common Message Calls API
+AOCE - Apple Open Collaborative Environment
+PROP - System-specific proprietary protocol
+FCP - Softarc's proprietary client-server protocol.
+Unix/X - X Windows based
+Unix/XM - Motif based
+Unix/XO - OpenWindows based
+PSS - PROFS Screen Scraper
+sumex-aim.stanford.edu* - almost dead as of 7/13/95, to be replaced by
+ info-mac.org.
+Metamail - a package with which MIME messages can be processed from
+ basically any Unix-based mail client.
+POPGate (Stalker Software) - gateway to/from Stalker's CommuniGate
+ system:  enables both use of POP3 to get software from a POP3 server
+ for use within a CommuniGate community, and to allow POP3 clients to
+ retrieve mail from a CommuniGate server.
+DigUNIX - Digital Unix
+Solaris - Solaris 2.x
+(d) IMAP/MAPI adaptors:
+Wollongong's Pathway Access 7/12/94
+mail-it@unipalm.co.uk's Mail-IT 7/12/94
+(e) IMAP/POP3 adaptors:
+Included with NCD Z-mail 4.0 for Windows 9/14/95
+------ ----------- ------------------- ------- -------------------------------
diff --git a/RFC/rfc1081.txt b/RFC/rfc1081.txt
new file mode 100644
index 00000000..c21d6e48
--- /dev/null
+++ b/RFC/rfc1081.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                            M. Rose
+Request for Comments: 1081                                           TWG
+                                                           November 1988
+
+                    Post Office Protocol - Version 3
+
+
+Status of this Memo
+
+   This memo suggests a simple method for workstations to dynamically
+   access mail from a mailbox server.  This RFC specifies a proposed
+   protocol for the Internet community, and requests discussion and
+   suggestions for improvements.  Distribution of this memo is
+   unlimited.
+
+   This memo is based on RFC 918 (since revised as RFC 937).  Although
+   similar in form to the original Post Office Protocol (POP) proposed
+   for the Internet community, the protocol discussed in this memo is
+   similar in spirit to the ideas investigated by the MZnet project at
+   the University of California, Irvine.
+
+   Further, substantial work was done on examining POP in a PC-based
+   environment.  This work, which resulted in additional functionality
+   in this protocol, was performed by the ACIS Networking Systems Group
+   at Stanford University.  The author gratefully acknowledges their
+   interest.
+
+Introduction
+
+   On certain types of smaller nodes in the Internet it is often
+   impractical to maintain a message transport system (MTS).  For
+   example, a workstation may not have sufficient resources (cycles,
+   disk space) in order to permit a SMTP server and associated local
+   mail delivery system to be kept resident and continuously running.
+   Similarly, it may be expensive (or impossible) to keep a personal
+   computer interconnected to an IP-style network for long amounts of
+   time (the node is lacking the resource known as "connectivity").
+
+   Despite this, it is often very useful to be able to manage mail on
+   these smaller nodes, and they often support a user agent (UA) to aid
+   the tasks of mail handling.  To solve this problem, a node which can
+   support an MTS entity offers a maildrop service to these less endowed
+   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
+   permit a workstation to dynamically access a maildrop on a server
+   host in a useful fashion.  Usually, this means that the POP3 is used
+   to allow a workstation to retrieve mail that the server is holding
+   for it.
+
+
+
+
+Rose                                                            [Page 1]
+
+RFC 1081                          POP3                     November 1988
+
+
+   For the remainder of this memo, the term "client host" refers to a
+   host making use of the POP3 service, while the term "server host"
+   refers to a host which offers the POP3 service.
+
+A Short Digression
+
+   This memo does not specify how a client host enters mail into the
+   transport system, although a method consistent with the philosophy of
+   this memo is presented here:
+
+      When the user agent on a client host wishes to enter a message
+      into the transport system, it establishes an SMTP connection to
+      its relay host (this relay host could be, but need not be, the
+      POP3 server host for the client host).
+
+   If this method is followed, then the client host appears to the MTS
+   as a user agent, and should NOT be regarded as a "trusted" MTS entity
+   in any sense whatsoever.  This concept, along with the role of the
+   POP3 as a part of a split-UA model is discussed later in this memo.
+
+   Initially, the server host starts the POP3 service by listening on
+   TCP port 110.  When a client host wishes to make use of the service,
+   it establishes a TCP connection with the server host.  When the
+   connection is established, the POP3 server sends a greeting.  The
+   client and POP3 server then exchange commands and responses
+   (respectively) until the connection is closed or aborted.
+
+   Commands in the POP3 consist of a keyword possibly followed by an
+   argument.  All commands are terminated by a CRLF pair.
+
+   Responses in the POP3 consist of a success indicator and a keyword
+   possibly followed by additional information.  All responses are
+   terminated by a CRLF pair.  There are currently two success
+   indicators: positive ("+OK") and negative ("-ERR").
+
+   Responses to certain commands are multi-line.  In these cases, which
+   are clearly indicated below, after sending the first line of the
+   response and a CRLF, any additional lines are sent, each terminated
+   by a CRLF pair.  When all lines of the response have been sent, a
+   final line is sent, consisting of a termination octet (decimal code
+   046, ".") and a CRLF pair.  If any line of the multi-line response
+   begins with the termination octet, the line is "byte-stuffed" by
+   pre-pending the termination octet to that line of the response.
+   Hence a multi-line response is terminated with the five octets
+   "CRLF.CRLF".  When examining a multi-line response, the client checks
+   to see if the line begins with the termination octet.  If so and if
+   octets other than CRLF follow, the the first octet of the line (the
+   termination octet) is stripped away.  If so and if CRLF immediately
+
+
+
+Rose                                                            [Page 2]
+
+RFC 1081                          POP3                     November 1988
+
+
+   follows the termination character, then the response from the POP
+   server is ended and the line containing ".CRLF" is not considered
+   part of the multi-line response.
+
+   A POP3 session progresses through a number of states during its
+   lifetime.  Once the TCP connection has been opened and the POP3
+   server has sent the greeting, the session enters the AUTHORIZATION
+   state.  In this state, the client must identify itself to the POP3
+   server.  Once the client has successfully done this, the server
+   acquires resources associated with the client's maildrop, and the
+   session enters the TRANSACTION state.  In this state, the client
+   requests actions on the part of the POP3 server.  When the client has
+   finished its transactions, the session enters the UPDATE state.  In
+   this state, the POP3 server releases any resources acquired during
+   the TRANSACTION state and says goodbye.  The TCP connection is then
+   closed.
+
+The AUTHORIZATION State
+
+   Once the TCP connection has been opened by a POP3 client, the POP3
+   server issues a one line greeting.  This can be any string terminated
+   by CRLF.  An example might be:
+
+      S.  +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
+
+   Note that this greeting is a POP3 reply.  The POP3 server should
+   always give a positive response as the greeting.
+
+   The POP3 session is now in the AUTHORIZATION state.  The client must
+   now issue the USER command.  If the POP3 server responds with a
+   positive success indicator ("+OK"), then the client may issue either
+   the PASS command to complete the authorization, or the QUIT command
+   to terminate the POP3 session.  If the POP3 server responds with a
+   negative success indicator ("-ERR") to the USER command, then the
+   client may either issue a new USER command or may issue the QUIT
+   command.
+
+   When the client issues the PASS command, the POP3 server uses the
+   argument pair from the USER and PASS commands to determine if the
+   client should be given access to the appropriate maildrop.  If so,
+   the POP3 server then acquires an exclusive-access lock on the
+   maildrop.  If the lock is successfully acquired, the POP3 server
+   parses the maildrop into individual messages (read note below),
+   determines the last message (if any) present in the maildrop that was
+   referenced by the RETR command, and responds with a positive success
+   indicator.  The POP3 session now enters the TRANSACTION state.  If
+   the lock can not be acquired or the client should is denied access to
+   the appropriate maildrop or the maildrop can't be parsed for some
+
+
+
+Rose                                                            [Page 3]
+
+RFC 1081                          POP3                     November 1988
+
+
+   reason, the POP3 server responds with a negative success indicator.
+   (If a lock was acquired but the POP3 server intends to respond with a
+   negative success indicator, the POP3 server must release the lock
+   prior to rejecting the command.)  At this point, the client may
+   either issue a new USER command and start again, or the client may
+   issue the QUIT command.
+
+                 NOTE: Minimal implementations of the POP3 need only be
+                 able to break a maildrop into its component messages;
+                 they need NOT be able to parse individual messages.
+                 More advanced implementations may wish to have this
+                 capability, for reasons discussed later.
+
+   After the POP3 server has parsed the maildrop into individual
+   messages, it assigns a message-id to each message, and notes the size
+   of the message in octets.  The first message in the maildrop is
+   assigned a message-id of "1", the second is assigned "2", and so on,
+   so that the n'th message in a maildrop is assigned a message-id of
+   "n".  In POP3 commands and responses, all message-id's and message
+   sizes are expressed in base-10 (i.e., decimal).
+
+   It sets the "highest number accessed" to be that of the last message
+   referenced by the RETR command.
+
+   Here are summaries for the three POP3 commands discussed thus far:
+
+           USER name
+               Arguments: a server specific user-id (required)
+               Restrictions: may only be given in the AUTHORIZATION
+                   state after the POP3 greeting or after an
+                   unsuccessful USER or PASS command
+               Possible Responses:
+                   +OK name is welcome here
+                   -ERR never heard of name
+               Examples:
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                     ...
+                   C:    USER frated
+                   S:    -ERR sorry, frated doesn't get his mail here
+
+           PASS string
+               Arguments: a server/user-id specific password (required)
+               Restrictions: may only be given in the AUTHORIZATION
+                   state after a successful USER command
+               Possible Responses:
+                   +OK maildrop locked and ready
+                   -ERR invalid password
+
+
+
+Rose                                                            [Page 4]
+
+RFC 1081                          POP3                     November 1988
+
+
+                   -ERR unable to lock maildrop
+               Examples:
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                   C:    PASS secret
+                   S:    +OK mrose's maildrop has 2 messages
+                         (320 octets)
+                     ...
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                   C:    PASS secret
+                   S:    -ERR unable to lock mrose's maildrop, file
+                         already locked
+
+           QUIT
+               Arguments: none
+               Restrictions: none
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    QUIT
+                   S:    +OK dewey POP3 server signing off
+
+
+The TRANSACTION State
+
+   Once the client has successfully identified itself to the POP3 server
+   and the POP3 server has locked and burst the appropriate maildrop,
+   the POP3 session is now in the TRANSACTION state.  The client may now
+   issue any of the following POP3 commands repeatedly.  After each
+   command, the POP3 server issues a response.  Eventually, the client
+   issues the QUIT command and the POP3 session enters the UPDATE state.
+
+   Here are the POP3 commands valid in the TRANSACTION state:
+
+           STAT
+               Arguments: none
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server issues a positive response with a line
+                 containing information for the maildrop.  This line is
+                 called a "drop listing" for that maildrop.
+
+                 In order to simplify parsing, all POP3 servers are
+                 required to use a certain format for drop listings.
+                 The first octets present must indicate the number of
+                 messages in the maildrop.  Following this is the size
+
+
+
+Rose                                                            [Page 5]
+
+RFC 1081                          POP3                     November 1988
+
+
+                 of the maildrop in octets.  This memo makes no
+                 requirement on what follows the maildrop size.
+                 Minimal implementations should just end that line of
+                 the response with a CRLF pair.  More advanced
+                 implementations may include other information.
+
+                      NOTE: This memo STRONGLY discourages
+                      implementations from supplying additional
+                      information in the drop listing.  Other,
+                      optional, facilities are discussed later on
+                      which permit the client to parse the messages
+                      in the maildrop.
+
+                 Note that messages marked as deleted are not counted in
+                 either total.
+
+               Possible Responses:
+                   +OK nn mm
+               Examples:
+                   C:    STAT
+                   S:    +OK 2 320
+
+           LIST [msg]
+               Arguments: a message-id (optionally)  If a message-id is
+                   given, it may NOT refer to a message marked as
+                   deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 If an argument was given and the POP3 server issues a
+                 positive response with a line containing information
+                 for that message.  This line is called a "scan listing"
+                 for that message.
+
+                 If no argument was given and the POP3 server issues a
+                 positive response, then the response given is
+                 multi-line.  After the initial +OK, for each message
+                 in the maildrop, the POP3 server responds with a line
+                 containing information for that message.  This line
+                 is called a "scan listing" for that message.
+
+                 In order to simplify parsing, all POP3 servers are
+                 required to use a certain format for scan listings.
+                 The first octets present must be the message-id of
+                 the message.  Following the message-id is the size of
+                 the message in octets.  This memo makes no requirement
+                 on what follows the message size in the scan listing.
+                 Minimal implementations should just end that line of
+
+
+
+Rose                                                            [Page 6]
+
+RFC 1081                          POP3                     November 1988
+
+
+                 the response with a CRLF pair.  More advanced
+                 implementations may include other information, as
+                 parsed from the message.
+
+                      NOTE: This memo STRONGLY discourages
+                      implementations from supplying additional
+                      information in the scan listing.  Other, optional,
+                      facilities are discussed later on which permit
+                      the client to parse the messages in the maildrop.
+
+                 Note that messages marked as deleted are not listed.
+
+               Possible Responses:
+                   +OK scan listing follows
+                   -ERR no such message
+               Examples:
+                   C:    LIST
+                   S:    +OK 2 messages (320 octets)
+                   S:    1 120
+                   S:    2 200
+                   S:    .
+                     ...
+                   C:    LIST 2
+                   S:    +OK 2 200
+                     ...
+                   C:    LIST 3
+                   S:    -ERR no such message, only 2 messages in
+                         maildrop
+
+           RETR msg
+               Arguments: a message-id (required)  This message-id may
+                   NOT refer to a message marked as deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 If the POP3 server issues a positive response, then the
+                 response given is multi-line.  After the initial +OK,
+                 the POP3 server sends the message corresponding to the
+                 given message-id, being careful to byte-stuff the
+                 termination character (as with all multi-line
+                 responses).
+
+                 If the number associated with this message is higher
+                 than the "highest number accessed" in the maildrop, the
+                 POP3 server updates the "highest number accessed" to
+                 the number associated with this message.
+
+
+
+
+
+Rose                                                            [Page 7]
+
+RFC 1081                          POP3                     November 1988
+
+
+               Possible Responses:
+                   +OK message follows
+                   -ERR no such message
+               Examples:
+                   C:    RETR 1
+                   S:    +OK 120 octets
+                   S:    <the POP3 server sends the entire message here>
+                   S:    .
+
+           DELE msg
+               Arguments: a message-id (required)  This message-id
+                   may NOT refer to a message marked as deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server marks the message as deleted.  Any
+                 future reference to the message-id associated with the
+                 message in a POP3 command generates an error.  The POP3
+                 server does not actually delete the message until the
+                 POP3 session enters the UPDATE state.
+
+                 If the number associated with this message is higher
+                 than the "highest number accessed" in the maildrop,
+                 the POP3 server updates the "highest number accessed"
+                 to the number associated with this message.
+
+               Possible Responses:
+                   +OK message deleted
+                   -ERR no such message
+               Examples:
+                   C:    DELE 1
+                   S:    +OK message 1 deleted
+                     ...
+                   C:    DELE 2
+                   S:    -ERR message 2 already deleted
+
+           NOOP
+               Arguments: none
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server does nothing, it merely replies with a
+                 positive response.
+
+               Possible Responses:
+                   +OK
+
+
+
+
+
+Rose                                                            [Page 8]
+
+RFC 1081                          POP3                     November 1988
+
+
+               Examples:
+                   C:    NOOP
+                   S:    +OK
+
+           LAST
+               Arguments: none
+               Restrictions: may only be issued in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server issues a positive response with a line
+                 containing the highest message number which accessed.
+                 Zero is returned in case no message in the maildrop has
+                 been accessed during previous transactions.  A client
+                 may thereafter infer that messages, if any, numbered
+                 greater than the response to the LAST command are
+                 messages not yet accessed by the client.
+
+             Possible Response:
+                   +OK nn
+
+             Examples:
+                   C:      STAT
+                   S:      +OK 4 320
+                   C:      LAST
+                   S:      +OK 1
+                   C:      RETR 3
+                   S:      +OK 120 octets
+                   S:      <the POP3 server sends the entire message
+                           here>
+                   S:      .
+                   C:      LAST
+                   S:      +OK 3
+                   C:      DELE 2
+                   S:      +OK message 2 deleted
+                   C:      LAST
+                   S:      +OK 3
+                   C:      RSET
+                   S:      +OK
+                   C:      LAST
+                   S:      +OK 1
+
+           RSET
+               Arguments: none
+               Restrictions: may only be given in the TRANSACTION
+                   state.
+               Discussion:
+
+                 If any messages have been marked as deleted by the POP3
+
+
+
+Rose                                                            [Page 9]
+
+RFC 1081                          POP3                     November 1988
+
+
+                 server, they are unmarked.  The POP3 server then
+                 replies with a positive response.  In addition, the
+                 "highest number accessed" is also reset to the value
+                 determined at the beginning of the POP3 session.
+
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    RSET
+                   S:    +OK maildrop has 2 messages (320 octets)
+
+
+
+The UPDATE State
+
+   When the client issues the QUIT command from the TRANSACTION state,
+   the POP3 session enters the UPDATE state.  (Note that if the client
+   issues the QUIT command from the AUTHORIZATION state, the POP3
+   session terminates but does NOT enter the UPDATE state.)
+
+           QUIT
+               Arguments: none
+               Restrictions: none
+               Discussion:
+
+                 The POP3 server removes all messages marked as deleted
+                 from the maildrop.  It then releases the
+                 exclusive-access lock on the maildrop and replies as
+                 to the success of
+                 these operations.  The TCP connection is then closed.
+
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    QUIT
+                   S:    +OK dewey POP3 server signing off (maildrop
+                         empty)
+                     ...
+                   C:    QUIT
+                   S:    +OK dewey POP3 server signing off (2 messages
+                         left)
+                     ...
+
+
+Optional POP3 Commands
+
+   The POP3 commands discussed above must be supported by all minimal
+   implementations of POP3 servers.
+
+
+
+Rose                                                           [Page 10]
+
+RFC 1081                          POP3                     November 1988
+
+
+   The optional POP3 commands described below permit a POP3 client
+   greater freedom in message handling, while preserving a simple POP3
+   server implementation.
+
+                 NOTE: This memo STRONGLY encourages implementations to
+                 support these commands in lieu of developing augmented
+                 drop and scan listings.  In short, the philosophy of
+                 this memo is to put intelligence in the part of the
+                 POP3 client and not the POP3 server.
+
+           TOP msg n
+               Arguments: a message-id (required) and a number.  This
+                   message-id may NOT refer to a message marked as
+                   deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 If the POP3 server issues a positive response, then
+                 the response given is multi-line.  After the initial
+                 +OK, the POP3 server sends the headers of the message,
+                 the blank line separating the headers from the body,
+                 and then the number of lines indicated message's body,
+                 being careful to byte-stuff the termination character
+                 (as with all multi-line responses).
+
+                 Note that if the number of lines requested by the POP3
+                 client is greater than than the number of lines in the
+                 body, then the POP3 server sends the entire message.
+
+               Possible Responses:
+                   +OK top of message follows
+                   -ERR no such message
+               Examples:
+                   C:    TOP 10
+                   S:    +OK
+                   S:    <the POP3 server sends the headers of the
+                          message, a blank line, and the first 10 lines
+                          of the body of the message>
+                   S:    .
+                     ...
+                   C:    TOP 100
+                   S:    -ERR no such message
+
+           RPOP user
+               Arguments: a client specific user-id (required)
+               Restrictions: may only be given in the AUTHORIZATION
+                   state after a successful USER command; in addition,
+                   may only be given if the client used a reserved
+
+
+
+Rose                                                           [Page 11]
+
+RFC 1081                          POP3                     November 1988
+
+
+                   (privileged) TCP port to connect to the server.
+               Discussion:
+
+                 The RPOP command may be used instead of the PASS
+                 command to authenticate access to the maildrop.  In
+                 order for this command to be successful, the POP3
+                 client must use a reserved TCP port (port < 1024) to
+                 connect tothe server.  The POP3 server uses the
+                 argument pair from the USER and RPOP commands to
+                 determine if the client should be given access to
+                 the appropriate maildrop.  Unlike the PASS command
+                 however, the POP3 server considers if the remote user
+                 specified by the RPOP command who resides on the POP3
+                 client host is allowed to access the maildrop for the
+                 user specified by the USER command (e.g., on Berkeley
+                 UNIX, the .rhosts mechanism is used).  With the
+                 exception of this differing in authentication, this
+                 command is identical to the PASS command.
+
+                 Note that the use of this feature has allowed much wider
+                 penetration into numerous hosts on local networks (and
+                 sometimes remote networks) by those who gain illegal
+                 access to computers by guessing passwords or otherwise
+                 breaking into the system.
+
+               Possible Responses:
+                   +OK maildrop locked and ready
+                   -ERR permission denied
+               Examples:
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                   C:    RPOP mrose
+                   S:    +OK mrose's maildrop has 2 messages (320
+                         octets)
+
+       Minimal POP3 Commands:
+           USER name               valid in the AUTHORIZATION state
+           PASS string
+           QUIT
+
+           STAT                    valid in the TRANSACTION state
+           LIST [msg]
+           RETR msg
+           DELE msg
+           NOOP
+           LAST
+           RSET
+
+
+
+
+Rose                                                           [Page 12]
+
+RFC 1081                          POP3                     November 1988
+
+
+           QUIT                    valid in the UPDATE state
+
+       Optional POP3 Commands:
+           RPOP user               valid in the AUTHORIZATION state
+
+           TOP msg n               valid in the TRANSACTION state
+
+       POP3 Replies:
+           +OK
+           -ERR
+
+       Note that with the exception of the STAT command, the reply given
+       by the POP3 server to any command is significant only to "+OK"
+       and "-ERR".  Any text occurring after this reply may be ignored
+       by the client.
+
+Example POP3 Session
+
+    S: <wait for connection on TCP port 110>
+        ...
+    C: <open connection>
+    S:    +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
+    C:    USER mrose
+    S:    +OK mrose is a real hoopy frood
+    C:    PASS secret
+    S:    +OK mrose's maildrop has 2 messages (320 octets)
+    C:    STAT
+    S:    +OK 2 320
+    C:    LIST
+    S:    +OK 2 messages (320 octets)
+    S:    1 120
+    S:    2 200
+    S:    .
+    C:    RETR 1
+    S:    +OK 120 octets
+    S:    <the POP3 server sends message 1>
+    S:    .
+    C:    DELE 1
+    S:    +OK message 1 deleted
+    C:    RETR 2
+    S:    +OK 200 octets
+    S:    <the POP3 server sends message 2>
+    S:    .
+    C:    DELE 2
+    S:    +OK message 2 deleted
+    C:    QUIT
+
+
+
+
+
+Rose                                                           [Page 13]
+
+RFC 1081                          POP3                     November 1988
+
+
+    S:    +OK dewey POP3 server signing off (maildrop empty)
+    C:  <close connection>
+    S:  <wait for next connection>
+
+Message Format
+
+   All messages transmitted during a POP3 session are assumed to conform
+   to the standard for the format of Internet text messages [RFC822].
+
+   It is important to note that the byte count for a message on the
+   server host may differ from the octet count assigned to that message
+   due to local conventions for designating end-of-line.  Usually,
+   during the AUTHORIZATION state of the POP3 session, the POP3 client
+   can calculate the size of each message in octets when it parses the
+   maildrop into messages.  For example, if the POP3 server host
+   internally represents end-of-line as a single character, then the
+   POP3 server simply counts each occurrence of this character in a
+   message as two octets.  Note that lines in the message which start
+   with the termination octet need not be counted twice, since the POP3
+   client will remove all byte-stuffed termination characters when it
+   receives a multi-line response.
+
+The POP and the Split-UA model
+
+   The underlying paradigm in which the POP3 functions is that of a
+   split-UA model.  The POP3 client host, being a remote PC based
+   workstation, acts solely as a client to the message transport system.
+   It does not provide delivery/authentication services to others.
+   Hence, it is acting as a UA, on behalf of the person using the
+   workstation.  Furthermore, the workstation uses SMTP to enter mail
+   into the MTS.
+
+   In this sense, we have two UA functions which interface to the
+   message transport system: Posting (SMTP) and Retrieval (POP3).  The
+   entity which supports this type of environment is called a split-UA
+   (since the user agent is split between two hosts which must
+   interoperate to provide these functions).
+
+                 ASIDE:  Others might term this a remote-UA instead.
+                 There are arguments supporting the use of both terms.
+
+   This memo has explicitly referenced TCP as the underlying transport
+   agent for the POP3.  This need not be the case.  In the MZnet split-
+   UA, for example, personal micro-computer systems are used which do
+   not have IP-style networking capability.  To connect to the POP3
+   server host, a PC establishes a terminal connection using some simple
+   protocol (PhoneNet).  A program on the PC drives the connection,
+   first establishing a login session as a normal user.  The login shell
+
+
+
+Rose                                                           [Page 14]
+
+RFC 1081                          POP3                     November 1988
+
+
+   for this pseudo-user is a program which drives the other half of the
+   terminal protocol and communicates with one of two servers.  Although
+   MZnet can support several PCs, a single pseudo-user login is present
+   on the server host.  The user-id and password for this pseudo-user
+   login is known to all members of MZnet.  Hence, the first action of
+   the login shell, after starting the terminal protocol, is to demand a
+   USER/PASS authorization pair from the PC.  This second level of
+   authorization is used to ascertain who is interacting with the MTS.
+   Although the server host is deemed to support a "trusted" MTS entity,
+   PCs in MZnet are not.  Naturally, the USER/PASS authorization pair
+   for a PC is known only to the owner of the PC (in theory, at least).
+
+   After successfully verifying the identity of the client, a modified
+   SMTP server is started, and the PC posts mail with the server host.
+   After the QUIT command is given to the SMTP server and it terminates,
+   a modified POP3 server is started, and the PC retrieves mail from the
+   server host.  After the QUIT command is given to the POP3 server and
+   it terminates, the login shell for the pseudo-user terminates the
+   terminal protocol and logs the job out.  The PC then closes the
+   terminal connection to the server host.
+
+   The SMTP server used by MZnet is modified in the sense that it knows
+   that it's talking to a user agent and not a "trusted" entity in the
+   message transport system.  Hence, it does performs the validation
+   activities normally performed by an entity in the MTS when it accepts
+   a message from a UA.
+
+   The POP3 server used by MZnet is modified in the sense that it does
+   not require a USER/PASS combination before entering the TRANSACTION
+   state.  The reason for this (of course) is that the PC has already
+   identified itself during the second-level authorization step
+   described above.
+
+                 NOTE: Truth in advertising laws require that the author
+                 of this memo state that MZnet has not actually been
+                 fully implemented.  The concepts presented and proven
+                 by the project led to the notion of the MZnet
+                 split-slot model.  This notion has inspired the
+                 split-UA concept described in this memo, led to the
+                 author's interest in the POP, and heavily influenced
+                 the the description of the POP3 herein.
+
+   In fact, some UAs present in the Internet already support the notion
+   of posting directly to an SMTP server and retrieving mail directly
+   from a POP server, even if the POP server and client resided on the
+   same host!
+
+                 ASIDE: this discussion raises an issue which this memo
+
+
+
+Rose                                                           [Page 15]
+
+RFC 1081                          POP3                     November 1988
+
+
+                 purposedly avoids: how does SMTP know that it's talking
+                 to a "trusted" MTS entity?
+
+References
+
+     [MZnet]   Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail
+               Service for Personal Micro-Computer Systems",
+               Proceedings, IFIP 6.5 International Conference on
+               Computer Message Systems, Nottingham, U.K., May 1984.
+
+     [RFC821]  Postel, J., "Simple Mail Transfer Protocol",
+               USC/Information Sciences Institute, August 1982.
+
+     [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
+               Text Messages", University of Delaware, August 1982.
+
+     [RFC937]  Butler, M., J. Postel, D. Chase, J. Goldberger, and J.
+               Reynolds, "Post Office Protocol - Version 2", RFC 937,
+               USC/Information Sciences Institute, February 1985.
+
+     [RFC1010] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
+               1010, USC/Information Sciences Institute, May 1987.
+
+Author's Address:
+
+
+   Marshall Rose
+   The Wollongong Group
+   1129 San Antonio Rd.
+   Palo Alto, California 94303
+
+   Phone: (415) 962-7100
+
+   Email: MRose@TWG.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                                                           [Page 16]
+
\ No newline at end of file
diff --git a/RFC/rfc1123.txt b/RFC/rfc1123.txt
new file mode 100644
index 00000000..51cdf83c
--- /dev/null
+++ b/RFC/rfc1123.txt
@@ -0,0 +1,5782 @@
+
+
+
+
+
+
+Network Working Group                    Internet Engineering Task Force
+Request for Comments: 1123                             R. Braden, Editor
+                                                            October 1989
+
+
+       Requirements for Internet Hosts -- Application and Support
+
+Status of This Memo
+
+   This RFC is an official specification for the Internet community.  It
+   incorporates by reference, amends, corrects, and supplements the
+   primary protocol standards documents relating to hosts.  Distribution
+   of this document is unlimited.
+
+Summary
+
+   This RFC is one of a pair that defines and discusses the requirements
+   for Internet host software.  This RFC covers the application and
+   support protocols; its companion RFC-1122 covers the communication
+   protocol layers: link layer, IP layer, and transport layer.
+
+
+
+                           Table of Contents
+
+
+
+
+   1.  INTRODUCTION ...............................................    5
+      1.1  The Internet Architecture ..............................    6
+      1.2  General Considerations .................................    6
+         1.2.1  Continuing Internet Evolution .....................    6
+         1.2.2  Robustness Principle ..............................    7
+         1.2.3  Error Logging .....................................    8
+         1.2.4  Configuration .....................................    8
+      1.3  Reading this Document ..................................   10
+         1.3.1  Organization ......................................   10
+         1.3.2  Requirements ......................................   10
+         1.3.3  Terminology .......................................   11
+      1.4  Acknowledgments ........................................   12
+
+   2.  GENERAL ISSUES .............................................   13
+      2.1  Host Names and Numbers .................................   13
+      2.2  Using Domain Name Service ..............................   13
+      2.3  Applications on Multihomed hosts .......................   14
+      2.4  Type-of-Service ........................................   14
+      2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY ...............   15
+
+
+
+
+Internet Engineering Task Force                                 [Page 1]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+   3.  REMOTE LOGIN -- TELNET PROTOCOL ............................   16
+      3.1  INTRODUCTION ...........................................   16
+      3.2  PROTOCOL WALK-THROUGH ..................................   16
+         3.2.1  Option Negotiation ................................   16
+         3.2.2  Telnet Go-Ahead Function ..........................   16
+         3.2.3  Control Functions .................................   17
+         3.2.4  Telnet "Synch" Signal .............................   18
+         3.2.5  NVT Printer and Keyboard ..........................   19
+         3.2.6  Telnet Command Structure ..........................   20
+         3.2.7  Telnet Binary Option ..............................   20
+         3.2.8  Telnet Terminal-Type Option .......................   20
+      3.3  SPECIFIC ISSUES ........................................   21
+         3.3.1  Telnet End-of-Line Convention .....................   21
+         3.3.2  Data Entry Terminals ..............................   23
+         3.3.3  Option Requirements ...............................   24
+         3.3.4  Option Initiation .................................   24
+         3.3.5  Telnet Linemode Option ............................   25
+      3.4  TELNET/USER INTERFACE ..................................   25
+         3.4.1  Character Set Transparency ........................   25
+         3.4.2  Telnet Commands ...................................   26
+         3.4.3  TCP Connection Errors .............................   26
+         3.4.4  Non-Default Telnet Contact Port ...................   26
+         3.4.5  Flushing Output ...................................   26
+      3.5.  TELNET REQUIREMENTS SUMMARY ...........................   27
+
+   4.  FILE TRANSFER ..............................................   29
+      4.1  FILE TRANSFER PROTOCOL -- FTP ..........................   29
+         4.1.1  INTRODUCTION ......................................   29
+         4.1.2.  PROTOCOL WALK-THROUGH ............................   29
+            4.1.2.1  LOCAL Type ...................................   29
+            4.1.2.2  Telnet Format Control ........................   30
+            4.1.2.3  Page Structure ...............................   30
+            4.1.2.4  Data Structure Transformations ...............   30
+            4.1.2.5  Data Connection Management ...................   31
+            4.1.2.6  PASV Command .................................   31
+            4.1.2.7  LIST and NLST Commands .......................   31
+            4.1.2.8  SITE Command .................................   32
+            4.1.2.9  STOU Command .................................   32
+            4.1.2.10  Telnet End-of-line Code .....................   32
+            4.1.2.11  FTP Replies .................................   33
+            4.1.2.12  Connections .................................   34
+            4.1.2.13  Minimum Implementation; RFC-959 Section .....   34
+         4.1.3  SPECIFIC ISSUES ...................................   35
+            4.1.3.1  Non-standard Command Verbs ...................   35
+            4.1.3.2  Idle Timeout .................................   36
+            4.1.3.3  Concurrency of Data and Control ..............   36
+            4.1.3.4  FTP Restart Mechanism ........................   36
+         4.1.4  FTP/USER INTERFACE ................................   39
+
+
+
+Internet Engineering Task Force                                 [Page 2]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+            4.1.4.1  Pathname Specification .......................   39
+            4.1.4.2  "QUOTE" Command ..............................   40
+            4.1.4.3  Displaying Replies to User ...................   40
+            4.1.4.4  Maintaining Synchronization ..................   40
+         4.1.5   FTP REQUIREMENTS SUMMARY .........................   41
+      4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP .................   44
+         4.2.1  INTRODUCTION ......................................   44
+         4.2.2  PROTOCOL WALK-THROUGH .............................   44
+            4.2.2.1  Transfer Modes ...............................   44
+            4.2.2.2  UDP Header ...................................   44
+         4.2.3  SPECIFIC ISSUES ...................................   44
+            4.2.3.1  Sorcerer's Apprentice Syndrome ...............   44
+            4.2.3.2  Timeout Algorithms ...........................   46
+            4.2.3.3  Extensions ...................................   46
+            4.2.3.4  Access Control ...............................   46
+            4.2.3.5  Broadcast Request ............................   46
+         4.2.4  TFTP REQUIREMENTS SUMMARY .........................   47
+
+   5.  ELECTRONIC MAIL -- SMTP and RFC-822 ........................   48
+      5.1  INTRODUCTION ...........................................   48
+      5.2  PROTOCOL WALK-THROUGH ..................................   48
+         5.2.1  The SMTP Model ....................................   48
+         5.2.2  Canonicalization ..................................   49
+         5.2.3  VRFY and EXPN Commands ............................   50
+         5.2.4  SEND, SOML, and SAML Commands .....................   50
+         5.2.5  HELO Command ......................................   50
+         5.2.6  Mail Relay ........................................   51
+         5.2.7  RCPT Command ......................................   52
+         5.2.8  DATA Command ......................................   53
+         5.2.9  Command Syntax ....................................   54
+         5.2.10  SMTP Replies .....................................   54
+         5.2.11  Transparency .....................................   55
+         5.2.12  WKS Use in MX Processing .........................   55
+         5.2.13  RFC-822 Message Specification ....................   55
+         5.2.14  RFC-822 Date and Time Specification ..............   55
+         5.2.15  RFC-822 Syntax Change ............................   56
+         5.2.16  RFC-822  Local-part ..............................   56
+         5.2.17  Domain Literals ..................................   57
+         5.2.18  Common Address Formatting Errors .................   58
+         5.2.19  Explicit Source Routes ...........................   58
+      5.3  SPECIFIC ISSUES ........................................   59
+         5.3.1  SMTP Queueing Strategies ..........................   59
+            5.3.1.1 Sending Strategy ..............................   59
+            5.3.1.2  Receiving strategy ...........................   61
+         5.3.2  Timeouts in SMTP ..................................   61
+         5.3.3  Reliable Mail Receipt .............................   63
+         5.3.4  Reliable Mail Transmission ........................   63
+         5.3.5  Domain Name Support ...............................   65
+
+
+
+Internet Engineering Task Force                                 [Page 3]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         5.3.6  Mailing Lists and Aliases .........................   65
+         5.3.7  Mail Gatewaying ...................................   66
+         5.3.8  Maximum Message Size ..............................   68
+      5.4  SMTP REQUIREMENTS SUMMARY ..............................   69
+
+   6. SUPPORT SERVICES ............................................   72
+      6.1 DOMAIN NAME TRANSLATION .................................   72
+         6.1.1 INTRODUCTION .......................................   72
+         6.1.2  PROTOCOL WALK-THROUGH .............................   72
+            6.1.2.1  Resource Records with Zero TTL ...............   73
+            6.1.2.2  QCLASS Values ................................   73
+            6.1.2.3  Unused Fields ................................   73
+            6.1.2.4  Compression ..................................   73
+            6.1.2.5  Misusing Configuration Info ..................   73
+         6.1.3  SPECIFIC ISSUES ...................................   74
+            6.1.3.1  Resolver Implementation ......................   74
+            6.1.3.2  Transport Protocols ..........................   75
+            6.1.3.3  Efficient Resource Usage .....................   77
+            6.1.3.4  Multihomed Hosts .............................   78
+            6.1.3.5  Extensibility ................................   79
+            6.1.3.6  Status of RR Types ...........................   79
+            6.1.3.7  Robustness ...................................   80
+            6.1.3.8  Local Host Table .............................   80
+         6.1.4  DNS USER INTERFACE ................................   81
+            6.1.4.1  DNS Administration ...........................   81
+            6.1.4.2  DNS User Interface ...........................   81
+            6.1.4.3 Interface Abbreviation Facilities .............   82
+         6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ...........   84
+      6.2  HOST INITIALIZATION ....................................   87
+         6.2.1  INTRODUCTION ......................................   87
+         6.2.2  REQUIREMENTS ......................................   87
+            6.2.2.1  Dynamic Configuration ........................   87
+            6.2.2.2  Loading Phase ................................   89
+      6.3  REMOTE MANAGEMENT ......................................   90
+         6.3.1  INTRODUCTION ......................................   90
+         6.3.2  PROTOCOL WALK-THROUGH .............................   90
+         6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92
+
+   7.  REFERENCES .................................................   93
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                 [Page 4]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+1.  INTRODUCTION
+
+   This document is one of a pair that defines and discusses the
+   requirements for host system implementations of the Internet protocol
+   suite.  This RFC covers the applications layer and support protocols.
+   Its companion RFC, "Requirements for Internet Hosts -- Communications
+   Layers" [INTRO:1] covers the lower layer protocols: transport layer,
+   IP layer, and link layer.
+
+   These documents are intended to provide guidance for vendors,
+   implementors, and users of Internet communication software.  They
+   represent the consensus of a large body of technical experience and
+   wisdom, contributed by members of the Internet research and vendor
+   communities.
+
+   This RFC enumerates standard protocols that a host connected to the
+   Internet must use, and it incorporates by reference the RFCs and
+   other documents describing the current specifications for these
+   protocols.  It corrects errors in the referenced documents and adds
+   additional discussion and guidance for an implementor.
+
+   For each protocol, this document also contains an explicit set of
+   requirements, recommendations, and options.  The reader must
+   understand that the list of requirements in this document is
+   incomplete by itself; the complete set of requirements for an
+   Internet host is primarily defined in the standard protocol
+   specification documents, with the corrections, amendments, and
+   supplements contained in this RFC.
+
+   A good-faith implementation of the protocols that was produced after
+   careful reading of the RFC's and with some interaction with the
+   Internet technical community, and that followed good communications
+   software engineering practices, should differ from the requirements
+   of this document in only minor ways.  Thus, in many cases, the
+   "requirements" in this RFC are already stated or implied in the
+   standard protocol documents, so that their inclusion here is, in a
+   sense, redundant.  However, they were included because some past
+   implementation has made the wrong choice, causing problems of
+   interoperability, performance, and/or robustness.
+
+   This document includes discussion and explanation of many of the
+   requirements and recommendations.  A simple list of requirements
+   would be dangerous, because:
+
+   o    Some required features are more important than others, and some
+        features are optional.
+
+   o    There may be valid reasons why particular vendor products that
+
+
+
+Internet Engineering Task Force                                 [Page 5]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+        are designed for restricted contexts might choose to use
+        different specifications.
+
+   However, the specifications of this document must be followed to meet
+   the general goal of arbitrary host interoperation across the
+   diversity and complexity of the Internet system.  Although most
+   current implementations fail to meet these requirements in various
+   ways, some minor and some major, this specification is the ideal
+   towards which we need to move.
+
+   These requirements are based on the current level of Internet
+   architecture.  This document will be updated as required to provide
+   additional clarifications or to include additional information in
+   those areas in which specifications are still evolving.
+
+   This introductory section begins with general advice to host software
+   vendors, and then gives some guidance on reading the rest of the
+   document.  Section 2 contains general requirements that may be
+   applicable to all application and support protocols.  Sections 3, 4,
+   and 5 contain the requirements on protocols for the three major
+   applications: Telnet, file transfer, and electronic mail,
+   respectively. Section 6 covers the support applications: the domain
+   name system, system initialization, and management.  Finally, all
+   references will be found in Section 7.
+
+   1.1  The Internet Architecture
+
+      For a brief introduction to the Internet architecture from a host
+      viewpoint, see Section 1.1 of [INTRO:1].  That section also
+      contains recommended references for general background on the
+      Internet architecture.
+
+   1.2  General Considerations
+
+      There are two important lessons that vendors of Internet host
+      software have learned and which a new vendor should consider
+      seriously.
+
+      1.2.1  Continuing Internet Evolution
+
+         The enormous growth of the Internet has revealed problems of
+         management and scaling in a large datagram-based packet
+         communication system.  These problems are being addressed, and
+         as a result there will be continuing evolution of the
+         specifications described in this document.  These changes will
+         be carefully planned and controlled, since there is extensive
+         participation in this planning by the vendors and by the
+         organizations responsible for operations of the networks.
+
+
+
+Internet Engineering Task Force                                 [Page 6]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         Development, evolution, and revision are characteristic of
+         computer network protocols today, and this situation will
+         persist for some years.  A vendor who develops computer
+         communication software for the Internet protocol suite (or any
+         other protocol suite!) and then fails to maintain and update
+         that software for changing specifications is going to leave a
+         trail of unhappy customers.  The Internet is a large
+         communication network, and the users are in constant contact
+         through it.  Experience has shown that knowledge of
+         deficiencies in vendor software propagates quickly through the
+         Internet technical community.
+
+      1.2.2  Robustness Principle
+
+         At every layer of the protocols, there is a general rule whose
+         application can lead to enormous benefits in robustness and
+         interoperability:
+
+                "Be liberal in what you accept, and
+                 conservative in what you send"
+
+         Software should be written to deal with every conceivable
+         error, no matter how unlikely; sooner or later a packet will
+         come in with that particular combination of errors and
+         attributes, and unless the software is prepared, chaos can
+         ensue.  In general, it is best to assume that the network is
+         filled with malevolent entities that will send in packets
+         designed to have the worst possible effect.  This assumption
+         will lead to suitable protective design, although the most
+         serious problems in the Internet have been caused by
+         unenvisaged mechanisms triggered by low-probability events;
+         mere human malice would never have taken so devious a course!
+
+         Adaptability to change must be designed into all levels of
+         Internet host software.  As a simple example, consider a
+         protocol specification that contains an enumeration of values
+         for a particular header field -- e.g., a type field, a port
+         number, or an error code; this enumeration must be assumed to
+         be incomplete.  Thus, if a protocol specification defines four
+         possible error codes, the software must not break when a fifth
+         code shows up.  An undefined code might be logged (see below),
+         but it must not cause a failure.
+
+         The second part of the principle is almost as important:
+         software on other hosts may contain deficiencies that make it
+         unwise to exploit legal but obscure protocol features.  It is
+         unwise to stray far from the obvious and simple, lest untoward
+         effects result elsewhere.  A corollary of this is "watch out
+
+
+
+Internet Engineering Task Force                                 [Page 7]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         for misbehaving hosts"; host software should be prepared, not
+         just to survive other misbehaving hosts, but also to cooperate
+         to limit the amount of disruption such hosts can cause to the
+         shared communication facility.
+
+      1.2.3  Error Logging
+
+         The Internet includes a great variety of host and gateway
+         systems, each implementing many protocols and protocol layers,
+         and some of these contain bugs and mis-features in their
+         Internet protocol software.  As a result of complexity,
+         diversity, and distribution of function, the diagnosis of user
+         problems is often very difficult.
+
+         Problem diagnosis will be aided if host implementations include
+         a carefully designed facility for logging erroneous or
+         "strange" protocol events.  It is important to include as much
+         diagnostic information as possible when an error is logged.  In
+         particular, it is often useful to record the header(s) of a
+         packet that caused an error.  However, care must be taken to
+         ensure that error logging does not consume prohibitive amounts
+         of resources or otherwise interfere with the operation of the
+         host.
+
+         There is a tendency for abnormal but harmless protocol events
+         to overflow error logging files; this can be avoided by using a
+         "circular" log, or by enabling logging only while diagnosing a
+         known failure.  It may be useful to filter and count duplicate
+         successive messages.  One strategy that seems to work well is:
+         (1) always count abnormalities and make such counts accessible
+         through the management protocol (see Section 6.3); and (2)
+         allow the logging of a great variety of events to be
+         selectively enabled.  For example, it might useful to be able
+         to "log everything" or to "log everything for host X".
+
+         Note that different managements may have differing policies
+         about the amount of error logging that they want normally
+         enabled in a host.  Some will say, "if it doesn't hurt me, I
+         don't want to know about it", while others will want to take a
+         more watchful and aggressive attitude about detecting and
+         removing protocol abnormalities.
+
+      1.2.4  Configuration
+
+         It would be ideal if a host implementation of the Internet
+         protocol suite could be entirely self-configuring.  This would
+         allow the whole suite to be implemented in ROM or cast into
+         silicon, it would simplify diskless workstations, and it would
+
+
+
+Internet Engineering Task Force                                 [Page 8]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         be an immense boon to harried LAN administrators as well as
+         system vendors.  We have not reached this ideal; in fact, we
+         are not even close.
+
+         At many points in this document, you will find a requirement
+         that a parameter be a configurable option.  There are several
+         different reasons behind such requirements.  In a few cases,
+         there is current uncertainty or disagreement about the best
+         value, and it may be necessary to update the recommended value
+         in the future.  In other cases, the value really depends on
+         external factors -- e.g., the size of the host and the
+         distribution of its communication load, or the speeds and
+         topology of nearby networks -- and self-tuning algorithms are
+         unavailable and may be insufficient.  In some cases,
+         configurability is needed because of administrative
+         requirements.
+
+         Finally, some configuration options are required to communicate
+         with obsolete or incorrect implementations of the protocols,
+         distributed without sources, that unfortunately persist in many
+         parts of the Internet.  To make correct systems coexist with
+         these faulty systems, administrators often have to "mis-
+         configure" the correct systems.  This problem will correct
+         itself gradually as the faulty systems are retired, but it
+         cannot be ignored by vendors.
+
+         When we say that a parameter must be configurable, we do not
+         intend to require that its value be explicitly read from a
+         configuration file at every boot time.  We recommend that
+         implementors set up a default for each parameter, so a
+         configuration file is only necessary to override those defaults
+         that are inappropriate in a particular installation.  Thus, the
+         configurability requirement is an assurance that it will be
+         POSSIBLE to override the default when necessary, even in a
+         binary-only or ROM-based product.
+
+         This document requires a particular value for such defaults in
+         some cases.  The choice of default is a sensitive issue when
+         the configuration item controls the accommodation to existing
+         faulty systems.  If the Internet is to converge successfully to
+         complete interoperability, the default values built into
+         implementations must implement the official protocol, not
+         "mis-configurations" to accommodate faulty implementations.
+         Although marketing considerations have led some vendors to
+         choose mis-configuration defaults, we urge vendors to choose
+         defaults that will conform to the standard.
+
+         Finally, we note that a vendor needs to provide adequate
+
+
+
+Internet Engineering Task Force                                 [Page 9]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         documentation on all configuration parameters, their limits and
+         effects.
+
+
+   1.3  Reading this Document
+
+      1.3.1  Organization
+
+         In general, each major section is organized into the following
+         subsections:
+
+         (1)  Introduction
+
+         (2)  Protocol Walk-Through -- considers the protocol
+              specification documents section-by-section, correcting
+              errors, stating requirements that may be ambiguous or
+              ill-defined, and providing further clarification or
+              explanation.
+
+         (3)  Specific Issues -- discusses protocol design and
+              implementation issues that were not included in the walk-
+              through.
+
+         (4)  Interfaces -- discusses the service interface to the next
+              higher layer.
+
+         (5)  Summary -- contains a summary of the requirements of the
+              section.
+
+         Under many of the individual topics in this document, there is
+         parenthetical material labeled "DISCUSSION" or
+         "IMPLEMENTATION".  This material is intended to give
+         clarification and explanation of the preceding requirements
+         text.  It also includes some suggestions on possible future
+         directions or developments.  The implementation material
+         contains suggested approaches that an implementor may want to
+         consider.
+
+         The summary sections are intended to be guides and indexes to
+         the text, but are necessarily cryptic and incomplete.  The
+         summaries should never be used or referenced separately from
+         the complete RFC.
+
+      1.3.2  Requirements
+
+         In this document, the words that are used to define the
+         significance of each particular requirement are capitalized.
+         These words are:
+
+
+
+Internet Engineering Task Force                                [Page 10]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         *    "MUST"
+
+              This word or the adjective "REQUIRED" means that the item
+              is an absolute requirement of the specification.
+
+         *    "SHOULD"
+
+              This word or the adjective "RECOMMENDED" means that there
+              may exist valid reasons in particular circumstances to
+              ignore this item, but the full implications should be
+              understood and the case carefully weighed before choosing
+              a different course.
+
+         *    "MAY"
+
+              This word or the adjective "OPTIONAL" means that this item
+              is truly optional.  One vendor may choose to include the
+              item because a particular marketplace requires it or
+              because it enhances the product, for example; another
+              vendor may omit the same item.
+
+
+         An implementation is not compliant if it fails to satisfy one
+         or more of the MUST requirements for the protocols it
+         implements.  An implementation that satisfies all the MUST and
+         all the SHOULD requirements for its protocols is said to be
+         "unconditionally compliant"; one that satisfies all the MUST
+         requirements but not all the SHOULD requirements for its
+         protocols is said to be "conditionally compliant".
+
+      1.3.3  Terminology
+
+         This document uses the following technical terms:
+
+         Segment
+              A segment is the unit of end-to-end transmission in the
+              TCP protocol.  A segment consists of a TCP header followed
+              by application data.  A segment is transmitted by
+              encapsulation in an IP datagram.
+
+         Message
+              This term is used by some application layer protocols
+              (particularly SMTP) for an application data unit.
+
+         Datagram
+              A [UDP] datagram is the unit of end-to-end transmission in
+              the UDP protocol.
+
+
+
+
+Internet Engineering Task Force                                [Page 11]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         Multihomed
+              A host is said to be multihomed if it has multiple IP
+              addresses to connected networks.
+
+
+
+   1.4  Acknowledgments
+
+      This document incorporates contributions and comments from a large
+      group of Internet protocol experts, including representatives of
+      university and research labs, vendors, and government agencies.
+      It was assembled primarily by the Host Requirements Working Group
+      of the Internet Engineering Task Force (IETF).
+
+      The Editor would especially like to acknowledge the tireless
+      dedication of the following people, who attended many long
+      meetings and generated 3 million bytes of electronic mail over the
+      past 18 months in pursuit of this document: Philip Almquist, Dave
+      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
+      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
+      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
+      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
+      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
+
+      In addition, the following people made major contributions to the
+      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
+      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
+      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
+      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
+      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
+      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
+      Technology), and Mike StJohns (DCA).  The following also made
+      significant contributions to particular areas: Eric Allman
+      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
+      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
+      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
+      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
+      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
+      (Toronto).
+
+      We are grateful to all, including any contributors who may have
+      been inadvertently omitted from this list.
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 12]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+2.  GENERAL ISSUES
+
+   This section contains general requirements that may be applicable to
+   all application-layer protocols.
+
+   2.1  Host Names and Numbers
+
+      The syntax of a legal Internet host name was specified in RFC-952
+      [DNS:4].  One aspect of host name syntax is hereby changed: the
+      restriction on the first character is relaxed to allow either a
+      letter or a digit.  Host software MUST support this more liberal
+      syntax.
+
+      Host software MUST handle host names of up to 63 characters and
+      SHOULD handle host names of up to 255 characters.
+
+      Whenever a user inputs the identity of an Internet host, it SHOULD
+      be possible to enter either (1) a host domain name or (2) an IP
+      address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
+      the string syntactically for a dotted-decimal number before
+      looking it up in the Domain Name System.
+
+      DISCUSSION:
+           This last requirement is not intended to specify the complete
+           syntactic form for entering a dotted-decimal host number;
+           that is considered to be a user-interface issue.  For
+           example, a dotted-decimal number must be enclosed within
+           "[ ]" brackets for SMTP mail (see Section 5.2.17).  This
+           notation could be made universal within a host system,
+           simplifying the syntactic checking for a dotted-decimal
+           number.
+
+           If a dotted-decimal number can be entered without such
+           identifying delimiters, then a full syntactic check must be
+           made, because a segment of a host domain name is now allowed
+           to begin with a digit and could legally be entirely numeric
+           (see Section 6.1.2.4).  However, a valid host name can never
+           have the dotted-decimal form #.#.#.#, since at least the
+           highest-level component label will be alphabetic.
+
+   2.2  Using Domain Name Service
+
+      Host domain names MUST be translated to IP addresses as described
+      in Section 6.1.
+
+      Applications using domain name services MUST be able to cope with
+      soft error conditions.  Applications MUST wait a reasonable
+      interval between successive retries due to a soft error, and MUST
+
+
+
+Internet Engineering Task Force                                [Page 13]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+      allow for the possibility that network problems may deny service
+      for hours or even days.
+
+      An application SHOULD NOT rely on the ability to locate a WKS
+      record containing an accurate listing of all services at a
+      particular host address, since the WKS RR type is not often used
+      by Internet sites.  To confirm that a service is present, simply
+      attempt to use it.
+
+   2.3  Applications on Multihomed hosts
+
+      When the remote host is multihomed, the name-to-address
+      translation will return a list of alternative IP addresses.  As
+      specified in Section 6.1.3.4, this list should be in order of
+      decreasing preference.  Application protocol implementations
+      SHOULD be prepared to try multiple addresses from the list until
+      success is obtained.  More specific requirements for SMTP are
+      given in Section 5.3.4.
+
+      When the local host is multihomed, a UDP-based request/response
+      application SHOULD send the response with an IP source address
+      that is the same as the specific destination address of the UDP
+      request datagram.  The "specific destination address" is defined
+      in the "IP Addressing" section of the companion RFC [INTRO:1].
+
+      Similarly, a server application that opens multiple TCP
+      connections to the same client SHOULD use the same local IP
+      address for all.
+
+   2.4  Type-of-Service
+
+      Applications MUST select appropriate TOS values when they invoke
+      transport layer services, and these values MUST be configurable.
+      Note that a TOS value contains 5 bits, of which only the most-
+      significant 3 bits are currently defined; the other two bits MUST
+      be zero.
+
+      DISCUSSION:
+           As gateway algorithms are developed to implement Type-of-
+           Service, the recommended values for various application
+           protocols may change.  In addition, it is likely that
+           particular combinations of users and Internet paths will want
+           non-standard TOS values.  For these reasons, the TOS values
+           must be configurable.
+
+           See the latest version of the "Assigned Numbers" RFC
+           [INTRO:5] for the recommended TOS values for the major
+           application protocols.
+
+
+
+Internet Engineering Task Force                                [Page 14]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+   2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY
+
+                                               |          | | | |S| |
+                                               |          | | | |H| |F
+                                               |          | | | |O|M|o
+                                               |          | |S| |U|U|o
+                                               |          | |H| |L|S|t
+                                               |          |M|O| |D|T|n
+                                               |          |U|U|M| | |o
+                                               |          |S|L|A|N|N|t
+                                               |          |T|D|Y|O|O|t
+FEATURE                                        |SECTION   | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+User interfaces:                               |          | | | | | |
+  Allow host name to begin with digit          |2.1       |x| | | | |
+  Host names of up to 635 characters           |2.1       |x| | | | |
+  Host names of up to 255 characters           |2.1       | |x| | | |
+  Support dotted-decimal host numbers          |2.1       | |x| | | |
+  Check syntactically for dotted-dec first     |2.1       | |x| | | |
+                                               |          | | | | | |
+Map domain names per Section 6.1               |2.2       |x| | | | |
+Cope with soft DNS errors                      |2.2       |x| | | | |
+   Reasonable interval between retries         |2.2       |x| | | | |
+   Allow for long outages                      |2.2       |x| | | | |
+Expect WKS records to be available             |2.2       | | | |x| |
+                                               |          | | | | | |
+Try multiple addr's for remote multihomed host |2.3       | |x| | | |
+UDP reply src addr is specific dest of request |2.3       | |x| | | |
+Use same IP addr for related TCP connections   |2.3       | |x| | | |
+Specify appropriate TOS values                 |2.4       |x| | | | |
+  TOS values configurable                      |2.4       |x| | | | |
+  Unused TOS bits zero                         |2.4       |x| | | | |
+                                               |          | | | | | |
+                                               |          | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 15]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+3.  REMOTE LOGIN -- TELNET PROTOCOL
+
+   3.1  INTRODUCTION
+
+      Telnet is the standard Internet application protocol for remote
+      login.  It provides the encoding rules to link a user's
+      keyboard/display on a client ("user") system with a command
+      interpreter on a remote server system.  A subset of the Telnet
+      protocol is also incorporated within other application protocols,
+      e.g., FTP and SMTP.
+
+      Telnet uses a single TCP connection, and its normal data stream
+      ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
+      escape sequences to embed control functions.  Telnet also allows
+      the negotiation of many optional modes and functions.
+
+      The primary Telnet specification is to be found in RFC-854
+      [TELNET:1], while the options are defined in many other RFCs; see
+      Section 7 for references.
+
+   3.2  PROTOCOL WALK-THROUGH
+
+      3.2.1  Option Negotiation: RFC-854, pp. 2-3
+
+         Every Telnet implementation MUST include option negotiation and
+         subnegotiation machinery [TELNET:2].
+
+         A host MUST carefully follow the rules of RFC-854 to avoid
+         option-negotiation loops.  A host MUST refuse (i.e, reply
+         WONT/DONT to a DO/WILL) an unsupported option.  Option
+         negotiation SHOULD continue to function (even if all requests
+         are refused) throughout the lifetime of a Telnet connection.
+
+         If all option negotiations fail, a Telnet implementation MUST
+         default to, and support, an NVT.
+
+         DISCUSSION:
+              Even though more sophisticated "terminals" and supporting
+              option negotiations are becoming the norm, all
+              implementations must be prepared to support an NVT for any
+              user-server communication.
+
+      3.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
+
+         On a host that never sends the Telnet command Go Ahead (GA),
+         the Telnet Server MUST attempt to negotiate the Suppress Go
+         Ahead option (i.e., send "WILL Suppress Go Ahead").  A User or
+         Server Telnet MUST always accept negotiation of the Suppress Go
+
+
+
+Internet Engineering Task Force                                [Page 16]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+         Ahead option.
+
+         When it is driving a full-duplex terminal for which GA has no
+         meaning, a User Telnet implementation MAY ignore GA commands.
+
+         DISCUSSION:
+              Half-duplex ("locked-keyboard") line-at-a-time terminals
+              for which the Go-Ahead mechanism was designed have largely
+              disappeared from the scene.  It turned out to be difficult
+              to implement sending the Go-Ahead signal in many operating
+              systems, even some systems that support native half-duplex
+              terminals.  The difficulty is typically that the Telnet
+              server code does not have access to information about
+              whether the user process is blocked awaiting input from
+              the Telnet connection, i.e., it cannot reliably determine
+              when to send a GA command.  Therefore, most Telnet Server
+              hosts do not send GA commands.
+
+              The effect of the rules in this section is to allow either
+              end of a Telnet connection to veto the use of GA commands.
+
+              There is a class of half-duplex terminals that is still
+              commercially important: "data entry terminals," which
+              interact in a full-screen manner.  However, supporting
+              data entry terminals using the Telnet protocol does not
+              require the Go Ahead signal; see Section 3.3.2.
+
+      3.2.3  Control Functions: RFC-854, pp. 7-8
+
+         The list of Telnet commands has been extended to include EOR
+         (End-of-Record), with code 239 [TELNET:9].
+
+         Both User and Server Telnets MAY support the control functions
+         EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
+         SB, and SE.
+
+         A host MUST be able to receive and ignore any Telnet control
+         functions that it does not support.
+
+         DISCUSSION:
+              Note that a Server Telnet is required to support the
+              Telnet IP (Interrupt Process) function, even if the server
+              host has an equivalent in-stream function (e.g., Control-C
+              in many systems).  The Telnet IP function may be stronger
+              than an in-stream interrupt command, because of the out-
+              of-band effect of TCP urgent data.
+
+              The EOR control function may be used to delimit the
+
+
+
+Internet Engineering Task Force                                [Page 17]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              stream.  An important application is data entry terminal
+              support (see Section 3.3.2).  There was concern that since
+              EOR had not been defined in RFC-854, a host that was not
+              prepared to correctly ignore unknown Telnet commands might
+              crash if it received an EOR.  To protect such hosts, the
+              End-of-Record option [TELNET:9] was introduced; however, a
+              properly implemented Telnet program will not require this
+              protection.
+
+      3.2.4  Telnet "Synch" Signal: RFC-854, pp. 8-10
+
+         When it receives "urgent" TCP data, a User or Server Telnet
+         MUST discard all data except Telnet commands until the DM (and
+         end of urgent) is reached.
+
+         When it sends Telnet IP (Interrupt Process), a User Telnet
+         SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
+         TCP urgent data the sequence "IAC IP IAC DM".  The TCP urgent
+         pointer points to the DM octet.
+
+         When it receives a Telnet IP command, a Server Telnet MAY send
+         a Telnet "Synch" sequence back to the user, to flush the output
+         stream.  The choice ought to be consistent with the way the
+         server operating system behaves when a local user interrupts a
+         process.
+
+         When it receives a Telnet AO command, a Server Telnet MUST send
+         a Telnet "Synch" sequence back to the user, to flush the output
+         stream.
+
+         A User Telnet SHOULD have the capability of flushing output
+         when it sends a Telnet IP; see also Section 3.4.5.
+
+         DISCUSSION:
+              There are three possible ways for a User Telnet to flush
+              the stream of server output data:
+
+              (1)  Send AO after IP.
+
+                   This will cause the server host to send a "flush-
+                   buffered-output" signal to its operating system.
+                   However, the AO may not take effect locally, i.e.,
+                   stop terminal output at the User Telnet end, until
+                   the Server Telnet has received and processed the AO
+                   and has sent back a "Synch".
+
+              (2)  Send DO TIMING-MARK [TELNET:7] after IP, and discard
+                   all output locally until a WILL/WONT TIMING-MARK is
+
+
+
+Internet Engineering Task Force                                [Page 18]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+                   received from the Server Telnet.
+
+                   Since the DO TIMING-MARK will be processed after the
+                   IP at the server, the reply to it should be in the
+                   right place in the output data stream.  However, the
+                   TIMING-MARK will not send a "flush buffered output"
+                   signal to the server operating system.  Whether or
+                   not this is needed is dependent upon the server
+                   system.
+
+              (3)  Do both.
+
+              The best method is not entirely clear, since it must
+              accommodate a number of existing server hosts that do not
+              follow the Telnet standards in various ways.  The safest
+              approach is probably to provide a user-controllable option
+              to select (1), (2), or (3).
+
+      3.2.5  NVT Printer and Keyboard: RFC-854, p. 11
+
+         In NVT mode, a Telnet SHOULD NOT send characters with the
+         high-order bit 1, and MUST NOT send it as a parity bit.
+         Implementations that pass the high-order bit to applications
+         SHOULD negotiate binary mode (see Section 3.2.6).
+
+
+         DISCUSSION:
+              Implementors should be aware that a strict reading of
+              RFC-854 allows a client or server expecting NVT ASCII to
+              ignore characters with the high-order bit set.  In
+              general, binary mode is expected to be used for
+              transmission of an extended (beyond 7-bit) character set
+              with Telnet.
+
+              However, there exist applications that really need an 8-
+              bit NVT mode, which is currently not defined, and these
+              existing applications do set the high-order bit during
+              part or all of the life of a Telnet connection.  Note that
+              binary mode is not the same as 8-bit NVT mode, since
+              binary mode turns off end-of-line processing.  For this
+              reason, the requirements on the high-order bit are stated
+              as SHOULD, not MUST.
+
+              RFC-854 defines a minimal set of properties of a "network
+              virtual terminal" or NVT; this is not meant to preclude
+              additional features in a real terminal.  A Telnet
+              connection is fully transparent to all 7-bit ASCII
+              characters, including arbitrary ASCII control characters.
+
+
+
+Internet Engineering Task Force                                [Page 19]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              For example, a terminal might support full-screen commands
+              coded as ASCII escape sequences; a Telnet implementation
+              would pass these sequences as uninterpreted data.  Thus,
+              an NVT should not be conceived as a terminal type of a
+              highly-restricted device.
+
+      3.2.6  Telnet Command Structure: RFC-854, p. 13
+
+         Since options may appear at any point in the data stream, a
+         Telnet escape character (known as IAC, with the value 255) to
+         be sent as data MUST be doubled.
+
+      3.2.7  Telnet Binary Option: RFC-856
+
+         When the Binary option has been successfully negotiated,
+         arbitrary 8-bit characters are allowed.  However, the data
+         stream MUST still be scanned for IAC characters, any embedded
+         Telnet commands MUST be obeyed, and data bytes equal to IAC
+         MUST be doubled.  Other character processing (e.g., replacing
+         CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
+         there is no end-of-line convention (see Section 3.3.1) in
+         binary mode.
+
+         DISCUSSION:
+              The Binary option is normally negotiated in both
+              directions, to change the Telnet connection from NVT mode
+              to "binary mode".
+
+              The sequence IAC EOR can be used to delimit blocks of data
+              within a binary-mode Telnet stream.
+
+      3.2.8  Telnet Terminal-Type Option: RFC-1091
+
+         The Terminal-Type option MUST use the terminal type names
+         officially defined in the Assigned Numbers RFC [INTRO:5], when
+         they are available for the particular terminal.  However, the
+         receiver of a Terminal-Type option MUST accept any name.
+
+         DISCUSSION:
+              RFC-1091 [TELNET:10] updates an earlier version of the
+              Terminal-Type option defined in RFC-930.  The earlier
+              version allowed a server host capable of supporting
+              multiple terminal types to learn the type of a particular
+              client's terminal, assuming that each physical terminal
+              had an intrinsic type.  However, today a "terminal" is
+              often really a terminal emulator program running in a PC,
+              perhaps capable of emulating a range of terminal types.
+              Therefore, RFC-1091 extends the specification to allow a
+
+
+
+Internet Engineering Task Force                                [Page 20]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              more general terminal-type negotiation between User and
+              Server Telnets.
+
+   3.3  SPECIFIC ISSUES
+
+      3.3.1  Telnet End-of-Line Convention
+
+         The Telnet protocol defines the sequence CR LF to mean "end-
+         of-line".  For terminal input, this corresponds to a command-
+         completion or "end-of-line" key being pressed on a user
+         terminal; on an ASCII terminal, this is the CR key, but it may
+         also be labelled "Return" or "Enter".
+
+         When a Server Telnet receives the Telnet end-of-line sequence
+         CR LF as input from a remote terminal, the effect MUST be the
+         same as if the user had pressed the "end-of-line" key on a
+         local terminal.  On server hosts that use ASCII, in particular,
+         receipt of the Telnet sequence CR LF must cause the same effect
+         as a local user pressing the CR key on a local terminal.  Thus,
+         CR LF and CR NUL MUST have the same effect on an ASCII server
+         host when received as input over a Telnet connection.
+
+         A User Telnet MUST be able to send any of the forms: CR LF, CR
+         NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
+         user-controllable mode to send either CR LF or CR NUL when the
+         user presses the "end-of-line" key, and CR LF SHOULD be the
+         default.
+
+         The Telnet end-of-line sequence CR LF MUST be used to send
+         Telnet data that is not terminal-to-computer (e.g., for Server
+         Telnet sending output, or the Telnet protocol incorporated
+         another application protocol).
+
+         DISCUSSION:
+              To allow interoperability between arbitrary Telnet clients
+              and servers, the Telnet protocol defined a standard
+              representation for a line terminator.  Since the ASCII
+              character set includes no explicit end-of-line character,
+              systems have chosen various representations, e.g., CR, LF,
+              and the sequence CR LF.  The Telnet protocol chose the CR
+              LF sequence as the standard for network transmission.
+
+              Unfortunately, the Telnet protocol specification in RFC-
+              854 [TELNET:1] has turned out to be somewhat ambiguous on
+              what character(s) should be sent from client to server for
+              the "end-of-line" key.  The result has been a massive and
+              continuing interoperability headache, made worse by
+              various faulty implementations of both User and Server
+
+
+
+Internet Engineering Task Force                                [Page 21]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              Telnets.
+
+              Although the Telnet protocol is based on a perfectly
+              symmetric model, in a remote login session the role of the
+              user at a terminal differs from the role of the server
+              host.  For example, RFC-854 defines the meaning of CR, LF,
+              and CR LF as output from the server, but does not specify
+              what the User Telnet should send when the user presses the
+              "end-of-line" key on the terminal; this turns out to be
+              the point at issue.
+
+              When a user presses the "end-of-line" key, some User
+              Telnet implementations send CR LF, while others send CR
+              NUL (based on a different interpretation of the same
+              sentence in RFC-854).  These will be equivalent for a
+              correctly-implemented ASCII server host, as discussed
+              above.  For other servers, a mode in the User Telnet is
+              needed.
+
+              The existence of User Telnets that send only CR NUL when
+              CR is pressed creates a dilemma for non-ASCII hosts: they
+              can either treat CR NUL as equivalent to CR LF in input,
+              thus precluding the possibility of entering a "bare" CR,
+              or else lose complete interworking.
+
+              Suppose a user on host A uses Telnet to log into a server
+              host B, and then execute B's User Telnet program to log
+              into server host C.  It is desirable for the Server/User
+              Telnet combination on B to be as transparent as possible,
+              i.e., to appear as if A were connected directly to C.  In
+              particular, correct implementation will make B transparent
+              to Telnet end-of-line sequences, except that CR LF may be
+              translated to CR NUL or vice versa.
+
+         IMPLEMENTATION:
+              To understand Telnet end-of-line issues, one must have at
+              least a general model of the relationship of Telnet to the
+              local operating system.  The Server Telnet process is
+              typically coupled into the terminal driver software of the
+              operating system as a pseudo-terminal.  A Telnet end-of-
+              line sequence received by the Server Telnet must have the
+              same effect as pressing the end-of-line key on a real
+              locally-connected terminal.
+
+              Operating systems that support interactive character-at-
+              a-time applications (e.g., editors) typically have two
+              internal modes for their terminal I/O: a formatted mode,
+              in which local conventions for end-of-line and other
+
+
+
+Internet Engineering Task Force                                [Page 22]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              formatting rules have been applied to the data stream, and
+              a "raw" mode, in which the application has direct access
+              to every character as it was entered.  A Server Telnet
+              must be implemented in such a way that these modes have
+              the same effect for remote as for local terminals.  For
+              example, suppose a CR LF or CR NUL is received by the
+              Server Telnet on an ASCII host.  In raw mode, a CR
+              character is passed to the application; in formatted mode,
+              the local system's end-of-line convention is used.
+
+      3.3.2  Data Entry Terminals
+
+         DISCUSSION:
+              In addition to the line-oriented and character-oriented
+              ASCII terminals for which Telnet was designed, there are
+              several families of video display terminals that are
+              sometimes known as "data entry terminals" or DETs.  The
+              IBM 3270 family is a well-known example.
+
+              Two Internet protocols have been designed to support
+              generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
+              option [TELNET:18, TELNET:19].  The DET option drives a
+              data entry terminal over a Telnet connection using (sub-)
+              negotiation.  SUPDUP is a completely separate terminal
+              protocol, which can be entered from Telnet by negotiation.
+              Although both SUPDUP and the DET option have been used
+              successfully in particular environments, neither has
+              gained general acceptance or wide implementation.
+
+              A different approach to DET interaction has been developed
+              for supporting the IBM 3270 family through Telnet,
+              although the same approach would be applicable to any DET.
+              The idea is to enter a "native DET" mode, in which the
+              native DET input/output stream is sent as binary data.
+              The Telnet EOR command is used to delimit logical records
+              (e.g., "screens") within this binary stream.
+
+         IMPLEMENTATION:
+              The rules for entering and leaving native DET mode are as
+              follows:
+
+              o    The Server uses the Terminal-Type option [TELNET:10]
+                   to learn that the client is a DET.
+
+              o    It is conventional, but not required, that both ends
+                   negotiate the EOR option [TELNET:9].
+
+              o    Both ends negotiate the Binary option [TELNET:3] to
+
+
+
+Internet Engineering Task Force                                [Page 23]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+                   enter native DET mode.
+
+              o    When either end negotiates out of binary mode, the
+                   other end does too, and the mode then reverts to
+                   normal NVT.
+
+
+      3.3.3  Option Requirements
+
+         Every Telnet implementation MUST support the Binary option
+         [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
+         SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
+         Record [TELNET:9], and Extended Options List [TELNET:8]
+         options.
+
+         A User or Server Telnet SHOULD support the Window Size Option
+         [TELNET:12] if the local operating system provides the
+         corresponding capability.
+
+         DISCUSSION:
+              Note that the End-of-Record option only signifies that a
+              Telnet can receive a Telnet EOR without crashing;
+              therefore, every Telnet ought to be willing to accept
+              negotiation of the End-of-Record option.  See also the
+              discussion in Section 3.2.3.
+
+      3.3.4  Option Initiation
+
+         When the Telnet protocol is used in a client/server situation,
+         the server SHOULD initiate negotiation of the terminal
+         interaction mode it expects.
+
+         DISCUSSION:
+              The Telnet protocol was defined to be perfectly
+              symmetrical, but its application is generally asymmetric.
+              Remote login has been known to fail because NEITHER side
+              initiated negotiation of the required non-default terminal
+              modes.  It is generally the server that determines the
+              preferred mode, so the server needs to initiate the
+              negotiation; since the negotiation is symmetric, the user
+              can also initiate it.
+
+         A client (User Telnet) SHOULD provide a means for users to
+         enable and disable the initiation of option negotiation.
+
+         DISCUSSION:
+              A user sometimes needs to connect to an application
+              service (e.g., FTP or SMTP) that uses Telnet for its
+
+
+
+Internet Engineering Task Force                                [Page 24]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              control stream but does not support Telnet options.  User
+              Telnet may be used for this purpose if initiation of
+              option negotiation is  disabled.
+
+      3.3.5  Telnet Linemode Option
+
+         DISCUSSION:
+              An important new Telnet option, LINEMODE [TELNET:12], has
+              been proposed.  The LINEMODE option provides a standard
+              way for a User Telnet and a Server Telnet to agree that
+              the client rather than the server will perform terminal
+              character processing.  When the client has prepared a
+              complete line of text, it will send it to the server in
+              (usually) one TCP packet.  This option will greatly
+              decrease the packet cost of Telnet sessions and will also
+              give much better user response over congested or long-
+              delay networks.
+
+              The LINEMODE option allows dynamic switching between local
+              and remote character processing.  For example, the Telnet
+              connection will automatically negotiate into single-
+              character mode while a full screen editor is running, and
+              then return to linemode when the editor is finished.
+
+              We expect that when this RFC is released, hosts should
+              implement the client side of this option, and may
+              implement the server side of this option.  To properly
+              implement the server side, the server needs to be able to
+              tell the local system not to do any input character
+              processing, but to remember its current terminal state and
+              notify the Server Telnet process whenever the state
+              changes.  This will allow password echoing and full screen
+              editors to be handled properly, for example.
+
+   3.4  TELNET/USER INTERFACE
+
+      3.4.1  Character Set Transparency
+
+         User Telnet implementations SHOULD be able to send or receive
+         any 7-bit ASCII character.  Where possible, any special
+         character interpretations by the user host's operating system
+         SHOULD be bypassed so that these characters can conveniently be
+         sent and received on the connection.
+
+         Some character value MUST be reserved as "escape to command
+         mode"; conventionally, doubling this character allows it to be
+         entered as data.  The specific character used SHOULD be user
+         selectable.
+
+
+
+Internet Engineering Task Force                                [Page 25]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+         On binary-mode connections, a User Telnet program MAY provide
+         an escape mechanism for entering arbitrary 8-bit values, if the
+         host operating system doesn't allow them to be entered directly
+         from the keyboard.
+
+         IMPLEMENTATION:
+              The transparency issues are less pressing on servers, but
+              implementors should take care in dealing with issues like:
+              masking off parity bits (sent by an older, non-conforming
+              client) before they reach programs that expect only NVT
+              ASCII, and properly handling programs that request 8-bit
+              data streams.
+
+      3.4.2  Telnet Commands
+
+         A User Telnet program MUST provide a user the capability of
+         entering any of the Telnet control functions IP, AO, or AYT,
+         and SHOULD provide the capability of entering EC, EL, and
+         Break.
+
+      3.4.3  TCP Connection Errors
+
+         A User Telnet program SHOULD report to the user any TCP errors
+         that are reported by the transport layer (see "TCP/Application
+         Layer Interface" section in [INTRO:1]).
+
+      3.4.4  Non-Default Telnet Contact Port
+
+         A User Telnet program SHOULD allow the user to optionally
+         specify a non-standard contact port number at the Server Telnet
+         host.
+
+      3.4.5  Flushing Output
+
+         A User Telnet program SHOULD provide the user the ability to
+         specify whether or not output should be flushed when an IP is
+         sent; see Section 3.2.4.
+
+         For any output flushing scheme that causes the User Telnet to
+         flush output locally until a Telnet signal is received from the
+         Server, there SHOULD be a way for the user to manually restore
+         normal output, in case the Server fails to send the expected
+         signal.
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 26]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+   3.5.  TELNET REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Option Negotiation                               |3.2.1   |x| | | | |
+  Avoid negotiation loops                        |3.2.1   |x| | | | |
+  Refuse unsupported options                     |3.2.1   |x| | | | |
+  Negotiation OK anytime on connection           |3.2.1   | |x| | | |
+  Default to NVT                                 |3.2.1   |x| | | | |
+  Send official name in Term-Type option         |3.2.8   |x| | | | |
+  Accept any name in Term-Type option            |3.2.8   |x| | | | |
+  Implement Binary, Suppress-GA options          |3.3.3   |x| | | | |
+  Echo, Status, EOL, Ext-Opt-List options        |3.3.3   | |x| | | |
+  Implement Window-Size option if appropriate    |3.3.3   | |x| | | |
+  Server initiate mode negotiations              |3.3.4   | |x| | | |
+  User can enable/disable init negotiations      |3.3.4   | |x| | | |
+                                                 |        | | | | | |
+Go-Aheads                                        |        | | | | | |
+  Non-GA server negotiate SUPPRESS-GA option     |3.2.2   |x| | | | |
+  User or Server accept SUPPRESS-GA option       |3.2.2   |x| | | | |
+  User Telnet ignore GA's                        |3.2.2   | | |x| | |
+                                                 |        | | | | | |
+Control Functions                                |        | | | | | |
+  Support SE NOP DM IP AO AYT SB                 |3.2.3   |x| | | | |
+  Support EOR EC EL Break                        |3.2.3   | | |x| | |
+  Ignore unsupported control functions           |3.2.3   |x| | | | |
+  User, Server discard urgent data up to DM      |3.2.4   |x| | | | |
+  User Telnet send "Synch" after IP, AO, AYT     |3.2.4   | |x| | | |
+  Server Telnet reply Synch to IP                |3.2.4   | | |x| | |
+  Server Telnet reply Synch to AO                |3.2.4   |x| | | | |
+  User Telnet can flush output when send IP      |3.2.4   | |x| | | |
+                                                 |        | | | | | |
+Encoding                                         |        | | | | | |
+  Send high-order bit in NVT mode                |3.2.5   | | | |x| |
+  Send high-order bit as parity bit              |3.2.5   | | | | |x|
+  Negot. BINARY if pass high-ord. bit to applic  |3.2.5   | |x| | | |
+  Always double IAC data byte                    |3.2.6   |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 27]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+  Double IAC data byte in binary mode            |3.2.7   |x| | | | |
+  Obey Telnet cmds in binary mode                |3.2.7   |x| | | | |
+  End-of-line, CR NUL in binary mode             |3.2.7   | | | | |x|
+                                                 |        | | | | | |
+End-of-Line                                      |        | | | | | |
+  EOL at Server same as local end-of-line        |3.3.1   |x| | | | |
+  ASCII Server accept CR LF or CR NUL for EOL    |3.3.1   |x| | | | |
+  User Telnet able to send CR LF, CR NUL, or LF  |3.3.1   |x| | | | |
+    ASCII user able to select CR LF/CR NUL       |3.3.1   | |x| | | |
+    User Telnet default mode is CR LF            |3.3.1   | |x| | | |
+  Non-interactive uses CR LF for EOL             |3.3.1   |x| | | | |
+                                                 |        | | | | | |
+User Telnet interface                            |        | | | | | |
+  Input & output all 7-bit characters            |3.4.1   | |x| | | |
+  Bypass local op sys interpretation             |3.4.1   | |x| | | |
+  Escape character                               |3.4.1   |x| | | | |
+     User-settable escape character              |3.4.1   | |x| | | |
+  Escape to enter 8-bit values                   |3.4.1   | | |x| | |
+  Can input IP, AO, AYT                          |3.4.2   |x| | | | |
+  Can input EC, EL, Break                        |3.4.2   | |x| | | |
+  Report TCP connection errors to user           |3.4.3   | |x| | | |
+  Optional non-default contact port              |3.4.4   | |x| | | |
+  Can spec: output flushed when IP sent          |3.4.5   | |x| | | |
+  Can manually restore output mode               |3.4.5   | |x| | | |
+                                                 |        | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 28]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+4.  FILE TRANSFER
+
+   4.1  FILE TRANSFER PROTOCOL -- FTP
+
+      4.1.1  INTRODUCTION
+
+         The File Transfer Protocol FTP is the primary Internet standard
+         for file transfer.  The current specification is contained in
+         RFC-959 [FTP:1].
+
+         FTP uses separate simultaneous TCP connections for control and
+         for data transfer.  The FTP protocol includes many features,
+         some of which are not commonly implemented.  However, for every
+         feature in FTP, there exists at least one implementation.  The
+         minimum implementation defined in RFC-959 was too small, so a
+         somewhat larger minimum implementation is defined here.
+
+         Internet users have been unnecessarily burdened for years by
+         deficient FTP implementations.  Protocol implementors have
+         suffered from the erroneous opinion that implementing FTP ought
+         to be a small and trivial task.  This is wrong, because FTP has
+         a user interface, because it has to deal (correctly) with the
+         whole variety of communication and operating system errors that
+         may occur, and because it has to handle the great diversity of
+         real file systems in the world.
+
+      4.1.2.  PROTOCOL WALK-THROUGH
+
+         4.1.2.1  LOCAL Type: RFC-959 Section 3.1.1.4
+
+            An FTP program MUST support TYPE I ("IMAGE" or binary type)
+            as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
+            A machine whose memory is organized into m-bit words, where
+            m is not a multiple of 8, MAY also support TYPE L m.
+
+            DISCUSSION:
+                 The command "TYPE L 8" is often required to transfer
+                 binary data between a machine whose memory is organized
+                 into (e.g.) 36-bit words and a machine with an 8-bit
+                 byte organization.  For an 8-bit byte machine, TYPE L 8
+                 is equivalent to IMAGE.
+
+                 "TYPE L m" is sometimes specified to the FTP programs
+                 on two m-bit word machines to ensure the correct
+                 transfer of a native-mode binary file from one machine
+                 to the other.  However, this command should have the
+                 same effect on these machines as "TYPE I".
+
+
+
+
+Internet Engineering Task Force                                [Page 29]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.2.2  Telnet Format Control: RFC-959 Section 3.1.1.5.2
+
+            A host that makes no distinction between TYPE N and TYPE T
+            SHOULD implement TYPE T to be identical to TYPE N.
+
+            DISCUSSION:
+                 This provision should ease interoperation with hosts
+                 that do make this distinction.
+
+                 Many hosts represent text files internally as strings
+                 of ASCII characters, using the embedded ASCII format
+                 effector characters (LF, BS, FF, ...) to control the
+                 format when a file is printed.  For such hosts, there
+                 is no distinction between "print" files and other
+                 files.  However, systems that use record structured
+                 files typically need a special format for printable
+                 files (e.g., ASA carriage control).   For the latter
+                 hosts, FTP allows a choice of TYPE N or TYPE T.
+
+         4.1.2.3  Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
+
+            Implementation of page structure is NOT RECOMMENDED in
+            general. However, if a host system does need to implement
+            FTP for "random access" or "holey" files, it MUST use the
+            defined page structure format rather than define a new
+            private FTP format.
+
+         4.1.2.4  Data Structure Transformations: RFC-959 Section 3.1.2
+
+            An FTP transformation between record-structure and file-
+            structure SHOULD be invertible, to the extent possible while
+            making the result useful on the target host.
+
+            DISCUSSION:
+                 RFC-959 required strict invertibility between record-
+                 structure and file-structure, but in practice,
+                 efficiency and convenience often preclude it.
+                 Therefore, the requirement is being relaxed.  There are
+                 two different objectives for transferring a file:
+                 processing it on the target host, or just storage.  For
+                 storage, strict invertibility is important.  For
+                 processing, the file created on the target host needs
+                 to be in the format expected by application programs on
+                 that host.
+
+                 As an example of the conflict, imagine a record-
+                 oriented operating system that requires some data files
+                 to have exactly 80 bytes in each record.  While STORing
+
+
+
+Internet Engineering Task Force                                [Page 30]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 a file on such a host, an FTP Server must be able to
+                 pad each line or record to 80 bytes; a later retrieval
+                 of such a file cannot be strictly invertible.
+
+         4.1.2.5  Data Connection Management: RFC-959 Section 3.3
+
+            A User-FTP that uses STREAM mode SHOULD send a PORT command
+            to assign a non-default data port before each transfer
+            command is issued.
+
+            DISCUSSION:
+                 This is required because of the long delay after a TCP
+                 connection is closed until its socket pair can be
+                 reused, to allow multiple transfers during a single FTP
+                 session.  Sending a port command can avoided if a
+                 transfer mode other than stream is used, by leaving the
+                 data transfer connection open between transfers.
+
+         4.1.2.6  PASV Command: RFC-959 Section 4.1.2
+
+            A server-FTP MUST implement the PASV command.
+
+            If multiple third-party transfers are to be executed during
+            the same session, a new PASV command MUST be issued before
+            each transfer command, to obtain a unique port pair.
+
+            IMPLEMENTATION:
+                 The format of the 227 reply to a PASV command is not
+                 well standardized.  In particular, an FTP client cannot
+                 assume that the parentheses shown on page 40 of RFC-959
+                 will be present (and in fact, Figure 3 on page 43 omits
+                 them).  Therefore, a User-FTP program that interprets
+                 the PASV reply must scan the reply for the first digit
+                 of the host and port numbers.
+
+                 Note that the host number h1,h2,h3,h4 is the IP address
+                 of the server host that is sending the reply, and that
+                 p1,p2 is a non-default data transfer port that PASV has
+                 assigned.
+
+         4.1.2.7  LIST and NLST Commands: RFC-959 Section 4.1.3
+
+            The data returned by an NLST command MUST contain only a
+            simple list of legal pathnames, such that the server can use
+            them directly as the arguments of subsequent data transfer
+            commands for the individual files.
+
+            The data returned by a LIST or NLST command SHOULD use an
+
+
+
+Internet Engineering Task Force                                [Page 31]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+            implied TYPE AN, unless the current type is EBCDIC, in which
+            case an implied TYPE EN SHOULD be used.
+
+            DISCUSSION:
+                 Many FTP clients support macro-commands that will get
+                 or put files matching a wildcard specification, using
+                 NLST to obtain a list of pathnames.  The expansion of
+                 "multiple-put" is local to the client, but "multiple-
+                 get" requires cooperation by the server.
+
+                 The implied type for LIST and NLST is designed to
+                 provide compatibility with existing User-FTPs, and in
+                 particular with multiple-get commands.
+
+         4.1.2.8  SITE Command: RFC-959 Section 4.1.3
+
+            A Server-FTP SHOULD use the SITE command for non-standard
+            features, rather than invent new private commands or
+            unstandardized extensions to existing commands.
+
+         4.1.2.9  STOU Command: RFC-959 Section 4.1.3
+
+            The STOU command stores into a uniquely named file.  When it
+            receives an STOU command, a Server-FTP MUST return the
+            actual file name in the "125 Transfer Starting" or the "150
+            Opening Data Connection" message that precedes the transfer
+            (the 250 reply code mentioned in RFC-959 is incorrect).  The
+            exact format of these messages is hereby defined to be as
+            follows:
+
+                125 FILE: pppp
+                150 FILE: pppp
+
+            where pppp represents the unique pathname of the file that
+            will be written.
+
+         4.1.2.10  Telnet End-of-line Code: RFC-959, Page 34
+
+            Implementors MUST NOT assume any correspondence between READ
+            boundaries on the control connection and the Telnet EOL
+            sequences (CR LF).
+
+            DISCUSSION:
+                 Thus, a server-FTP (or User-FTP) must continue reading
+                 characters from the control connection until a complete
+                 Telnet EOL sequence is encountered, before processing
+                 the command (or response, respectively).  Conversely, a
+                 single READ from the control connection may include
+
+
+
+Internet Engineering Task Force                                [Page 32]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 more than one FTP command.
+
+         4.1.2.11  FTP Replies: RFC-959 Section 4.2, Page 35
+
+            A Server-FTP MUST send only correctly formatted replies on
+            the control connection.  Note that RFC-959 (unlike earlier
+            versions of the FTP spec) contains no provision for a
+            "spontaneous" reply message.
+
+            A Server-FTP SHOULD use the reply codes defined in RFC-959
+            whenever they apply.  However, a server-FTP MAY use a
+            different reply code when needed, as long as the general
+            rules of Section 4.2 are followed. When the implementor has
+            a choice between a 4xx and 5xx reply code, a Server-FTP
+            SHOULD send a 4xx (temporary failure) code when there is any
+            reasonable possibility that a failed FTP will succeed a few
+            hours later.
+
+            A User-FTP SHOULD generally use only the highest-order digit
+            of a 3-digit reply code for making a procedural decision, to
+            prevent difficulties when a Server-FTP uses non-standard
+            reply codes.
+
+            A User-FTP MUST be able to handle multi-line replies.  If
+            the implementation imposes a limit on the number of lines
+            and if this limit is exceeded, the User-FTP MUST recover,
+            e.g., by ignoring the excess lines until the end of the
+            multi-line reply is reached.
+
+            A User-FTP SHOULD NOT interpret a 421 reply code ("Service
+            not available, closing control connection") specially, but
+            SHOULD detect closing of the control connection by the
+            server.
+
+            DISCUSSION:
+                 Server implementations that fail to strictly follow the
+                 reply rules often cause FTP user programs to hang.
+                 Note that RFC-959 resolved ambiguities in the reply
+                 rules found in earlier FTP specifications and must be
+                 followed.
+
+                 It is important to choose FTP reply codes that properly
+                 distinguish between temporary and permanent failures,
+                 to allow the successful use of file transfer client
+                 daemons.  These programs depend on the reply codes to
+                 decide whether or not to retry a failed transfer; using
+                 a permanent failure code (5xx) for a temporary error
+                 will cause these programs to give up unnecessarily.
+
+
+
+Internet Engineering Task Force                                [Page 33]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 When the meaning of a reply matches exactly the text
+                 shown in RFC-959, uniformity will be enhanced by using
+                 the RFC-959 text verbatim.  However, a Server-FTP
+                 implementor is encouraged to choose reply text that
+                 conveys specific system-dependent information, when
+                 appropriate.
+
+         4.1.2.12  Connections: RFC-959 Section 5.2
+
+            The words "and the port used" in the second paragraph of
+            this section of RFC-959 are erroneous (historical), and they
+            should be ignored.
+
+            On a multihomed server host, the default data transfer port
+            (L-1) MUST be associated with the same local IP address as
+            the corresponding control connection to port L.
+
+            A user-FTP MUST NOT send any Telnet controls other than
+            SYNCH and IP on an FTP control connection. In particular, it
+            MUST NOT attempt to negotiate Telnet options on the control
+            connection.  However, a server-FTP MUST be capable of
+            accepting and refusing Telnet negotiations (i.e., sending
+            DONT/WONT).
+
+            DISCUSSION:
+                 Although the RFC says: "Server- and User- processes
+                 should follow the conventions for the Telnet
+                 protocol...[on the control connection]", it is not the
+                 intent that Telnet option negotiation is to be
+                 employed.
+
+         4.1.2.13  Minimum Implementation; RFC-959 Section 5.1
+
+            The following commands and options MUST be supported by
+            every server-FTP and user-FTP, except in cases where the
+            underlying file system or operating system does not allow or
+            support a particular command.
+
+                 Type: ASCII Non-print, IMAGE, LOCAL 8
+                 Mode: Stream
+                 Structure: File, Record*
+                 Commands:
+                    USER, PASS, ACCT,
+                    PORT, PASV,
+                    TYPE, MODE, STRU,
+                    RETR, STOR, APPE,
+                    RNFR, RNTO, DELE,
+                    CWD,  CDUP, RMD,  MKD,  PWD,
+
+
+
+Internet Engineering Task Force                                [Page 34]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                    LIST, NLST,
+                    SYST, STAT,
+                    HELP, NOOP, QUIT.
+
+            *Record structure is REQUIRED only for hosts whose file
+            systems support record structure.
+
+            DISCUSSION:
+                 Vendors are encouraged to implement a larger subset of
+                 the protocol.  For example, there are important
+                 robustness features in the protocol (e.g., Restart,
+                 ABOR, block mode) that would be an aid to some Internet
+                 users but are not widely implemented.
+
+                 A host that does not have record structures in its file
+                 system may still accept files with STRU R, recording
+                 the byte stream literally.
+
+      4.1.3  SPECIFIC ISSUES
+
+         4.1.3.1  Non-standard Command Verbs
+
+            FTP allows "experimental" commands, whose names begin with
+            "X".  If these commands are subsequently adopted as
+            standards, there may still be existing implementations using
+            the "X" form.  At present, this is true for the directory
+            commands:
+
+                RFC-959   "Experimental"
+
+                  MKD        XMKD
+                  RMD        XRMD
+                  PWD        XPWD
+                  CDUP       XCUP
+                  CWD        XCWD
+
+            All FTP implementations SHOULD recognize both forms of these
+            commands, by simply equating them with extra entries in the
+            command lookup table.
+
+            IMPLEMENTATION:
+                 A User-FTP can access a server that supports only the
+                 "X" forms by implementing a mode switch, or
+                 automatically using the following procedure: if the
+                 RFC-959 form of one of the above commands is rejected
+                 with a 500 or 502 response code, then try the
+                 experimental form; any other response would be passed
+                 to the user.
+
+
+
+Internet Engineering Task Force                                [Page 35]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.3.2  Idle Timeout
+
+            A Server-FTP process SHOULD have an idle timeout, which will
+            terminate the process and close the control connection if
+            the server is inactive (i.e., no command or data transfer in
+            progress) for a long period of time.  The idle timeout time
+            SHOULD be configurable, and the default should be at least 5
+            minutes.
+
+            A client FTP process ("User-PI" in RFC-959) will need
+            timeouts on responses only if it is invoked from a program.
+
+            DISCUSSION:
+                 Without a timeout, a Server-FTP process may be left
+                 pending indefinitely if the corresponding client
+                 crashes without closing the control connection.
+
+         4.1.3.3  Concurrency of Data and Control
+
+            DISCUSSION:
+                 The intent of the designers of FTP was that a user
+                 should be able to send a STAT command at any time while
+                 data transfer was in progress and that the server-FTP
+                 would reply immediately with status -- e.g., the number
+                 of bytes transferred so far.  Similarly, an ABOR
+                 command should be possible at any time during a data
+                 transfer.
+
+                 Unfortunately, some small-machine operating systems
+                 make such concurrent programming difficult, and some
+                 other implementers seek minimal solutions, so some FTP
+                 implementations do not allow concurrent use of the data
+                 and control connections.  Even such a minimal server
+                 must be prepared to accept and defer a STAT or ABOR
+                 command that arrives during data transfer.
+
+         4.1.3.4  FTP Restart Mechanism
+
+            The description of the 110 reply on pp. 40-41 of RFC-959 is
+            incorrect; the correct description is as follows.  A restart
+            reply message, sent over the control connection from the
+            receiving FTP to the User-FTP, has the format:
+
+                110 MARK ssss = rrrr
+
+            Here:
+
+            *    ssss is a text string that appeared in a Restart Marker
+
+
+
+Internet Engineering Task Force                                [Page 36]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 in the data stream and encodes a position in the
+                 sender's file system;
+
+            *    rrrr encodes the corresponding position in the
+                 receiver's file system.
+
+            The encoding, which is specific to a particular file system
+            and network implementation, is always generated and
+            interpreted by the same system, either sender or receiver.
+
+            When an FTP that implements restart receives a Restart
+            Marker in the data stream, it SHOULD force the data to that
+            point to be written to stable storage before encoding the
+            corresponding position rrrr.  An FTP sending Restart Markers
+            MUST NOT assume that 110 replies will be returned
+            synchronously with the data, i.e., it must not await a 110
+            reply before sending more data.
+
+            Two new reply codes are hereby defined for errors
+            encountered in restarting a transfer:
+
+              554 Requested action not taken: invalid REST parameter.
+
+                 A 554 reply may result from a FTP service command that
+                 follows a REST command.  The reply indicates that the
+                 existing file at the Server-FTP cannot be repositioned
+                 as specified in the REST.
+
+              555 Requested action not taken: type or stru mismatch.
+
+                 A 555 reply may result from an APPE command or from any
+                 FTP service command following a REST command.  The
+                 reply indicates that there is some mismatch between the
+                 current transfer parameters (type and stru) and the
+                 attributes of the existing file.
+
+            DISCUSSION:
+                 Note that the FTP Restart mechanism requires that Block
+                 or Compressed mode be used for data transfer, to allow
+                 the Restart Markers to be included within the data
+                 stream.  The frequency of Restart Markers can be low.
+
+                 Restart Markers mark a place in the data stream, but
+                 the receiver may be performing some transformation on
+                 the data as it is stored into stable storage.  In
+                 general, the receiver's encoding must include any state
+                 information necessary to restart this transformation at
+                 any point of the FTP data stream.  For example, in TYPE
+
+
+
+Internet Engineering Task Force                                [Page 37]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 A transfers, some receiver hosts transform CR LF
+                 sequences into a single LF character on disk.   If a
+                 Restart Marker happens to fall between CR and LF, the
+                 receiver must encode in rrrr that the transfer must be
+                 restarted in a "CR has been seen and discarded" state.
+
+                 Note that the Restart Marker is required to be encoded
+                 as a string of printable ASCII characters, regardless
+                 of the type of the data.
+
+                 RFC-959 says that restart information is to be returned
+                 "to the user".  This should not be taken literally.  In
+                 general, the User-FTP should save the restart
+                 information (ssss,rrrr) in stable storage, e.g., append
+                 it to a restart control file.  An empty restart control
+                 file should be created when the transfer first starts
+                 and deleted automatically when the transfer completes
+                 successfully.  It is suggested that this file have a
+                 name derived in an easily-identifiable manner from the
+                 name of the file being transferred and the remote host
+                 name; this is analogous to the means used by many text
+                 editors for naming "backup" files.
+
+                 There are three cases for FTP restart.
+
+                 (1)  User-to-Server Transfer
+
+                      The User-FTP puts Restart Markers <ssss> at
+                      convenient places in the data stream.  When the
+                      Server-FTP receives a Marker, it writes all prior
+                      data to disk, encodes its file system position and
+                      transformation state as rrrr, and returns a "110
+                      MARK ssss = rrrr" reply over the control
+                      connection.  The User-FTP appends the pair
+                      (ssss,rrrr) to its restart control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (ssss,rrrr) pair from the restart control
+                      file, repositions its local file system and
+                      transformation state using ssss, and sends the
+                      command "REST rrrr" to the Server-FTP.
+
+                 (2)  Server-to-User Transfer
+
+                      The Server-FTP puts Restart Markers <ssss> at
+                      convenient places in the data stream.  When the
+                      User-FTP receives a Marker, it writes all prior
+                      data to disk, encodes its file system position and
+
+
+
+Internet Engineering Task Force                                [Page 38]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                      transformation state as rrrr, and appends the pair
+                      (rrrr,ssss) to its restart control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (rrrr,ssss) pair from the restart control
+                      file, repositions its local file system and
+                      transformation state using rrrr, and sends the
+                      command "REST ssss" to the Server-FTP.
+
+                 (3)  Server-to-Server ("Third-Party") Transfer
+
+                      The sending Server-FTP puts Restart Markers <ssss>
+                      at convenient places in the data stream.  When it
+                      receives a Marker, the receiving Server-FTP writes
+                      all prior data to disk, encodes its file system
+                      position and transformation state as rrrr, and
+                      sends a "110 MARK ssss = rrrr" reply over the
+                      control connection to the User.  The User-FTP
+                      appends the pair (ssss,rrrr) to its restart
+                      control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (ssss,rrrr) pair from the restart control
+                      file, sends "REST ssss" to the sending Server-FTP,
+                      and sends "REST rrrr" to the receiving Server-FTP.
+
+
+      4.1.4  FTP/USER INTERFACE
+
+         This section discusses the user interface for a User-FTP
+         program.
+
+         4.1.4.1  Pathname Specification
+
+            Since FTP is intended for use in a heterogeneous
+            environment, User-FTP implementations MUST support remote
+            pathnames as arbitrary character strings, so that their form
+            and content are not limited by the conventions of the local
+            operating system.
+
+            DISCUSSION:
+                 In particular, remote pathnames can be of arbitrary
+                 length, and all the printing ASCII characters as well
+                 as space (0x20) must be allowed.  RFC-959 allows a
+                 pathname to contain any 7-bit ASCII character except CR
+                 or LF.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 39]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.4.2  "QUOTE" Command
+
+            A User-FTP program MUST implement a "QUOTE" command that
+            will pass an arbitrary character string to the server and
+            display all resulting response messages to the user.
+
+            To make the "QUOTE" command useful, a User-FTP SHOULD send
+            transfer control commands to the server as the user enters
+            them, rather than saving all the commands and sending them
+            to the server only when a data transfer is started.
+
+            DISCUSSION:
+                 The "QUOTE" command is essential to allow the user to
+                 access servers that require system-specific commands
+                 (e.g., SITE or ALLO), or to invoke new or optional
+                 features that are not implemented by the User-FTP.  For
+                 example, "QUOTE" may be used to specify "TYPE A T" to
+                 send a print file to hosts that require the
+                 distinction, even if the User-FTP does not recognize
+                 that TYPE.
+
+         4.1.4.3  Displaying Replies to User
+
+            A User-FTP SHOULD display to the user the full text of all
+            error reply messages it receives.  It SHOULD have a
+            "verbose" mode in which all commands it sends and the full
+            text and reply codes it receives are displayed, for
+            diagnosis of problems.
+
+         4.1.4.4  Maintaining Synchronization
+
+            The state machine in a User-FTP SHOULD be forgiving of
+            missing and unexpected reply messages, in order to maintain
+            command synchronization with the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 40]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+      4.1.5   FTP REQUIREMENTS SUMMARY
+
+                                           |               | | | |S| |
+                                           |               | | | |H| |F
+                                           |               | | | |O|M|o
+                                           |               | |S| |U|U|o
+                                           |               | |H| |L|S|t
+                                           |               |M|O| |D|T|n
+                                           |               |U|U|M| | |o
+                                           |               |S|L|A|N|N|t
+                                           |               |T|D|Y|O|O|t
+FEATURE                                    |SECTION        | | | |T|T|e
+-------------------------------------------|---------------|-|-|-|-|-|--
+Implement TYPE T if same as TYPE N         |4.1.2.2        | |x| | | |
+File/Record transform invertible if poss.  |4.1.2.4        | |x| | | |
+User-FTP send PORT cmd for stream mode     |4.1.2.5        | |x| | | |
+Server-FTP implement PASV                  |4.1.2.6        |x| | | | |
+  PASV is per-transfer                     |4.1.2.6        |x| | | | |
+NLST reply usable in RETR cmds             |4.1.2.7        |x| | | | |
+Implied type for LIST and NLST             |4.1.2.7        | |x| | | |
+SITE cmd for non-standard features         |4.1.2.8        | |x| | | |
+STOU cmd return pathname as specified      |4.1.2.9        |x| | | | |
+Use TCP READ boundaries on control conn.   |4.1.2.10       | | | | |x|
+                                           |               | | | | | |
+Server-FTP send only correct reply format  |4.1.2.11       |x| | | | |
+Server-FTP use defined reply code if poss. |4.1.2.11       | |x| | | |
+  New reply code following Section 4.2     |4.1.2.11       | | |x| | |
+User-FTP use only high digit of reply      |4.1.2.11       | |x| | | |
+User-FTP handle multi-line reply lines     |4.1.2.11       |x| | | | |
+User-FTP handle 421 reply specially        |4.1.2.11       | | | |x| |
+                                           |               | | | | | |
+Default data port same IP addr as ctl conn |4.1.2.12       |x| | | | |
+User-FTP send Telnet cmds exc. SYNCH, IP   |4.1.2.12       | | | | |x|
+User-FTP negotiate Telnet options          |4.1.2.12       | | | | |x|
+Server-FTP handle Telnet options           |4.1.2.12       |x| | | | |
+Handle "Experimental" directory cmds       |4.1.3.1        | |x| | | |
+Idle timeout in server-FTP                 |4.1.3.2        | |x| | | |
+    Configurable idle timeout              |4.1.3.2        | |x| | | |
+Receiver checkpoint data at Restart Marker |4.1.3.4        | |x| | | |
+Sender assume 110 replies are synchronous  |4.1.3.4        | | | | |x|
+                                           |               | | | | | |
+Support TYPE:                              |               | | | | | |
+  ASCII - Non-Print (AN)                   |4.1.2.13       |x| | | | |
+  ASCII - Telnet (AT) -- if same as AN     |4.1.2.2        | |x| | | |
+  ASCII - Carriage Control (AC)            |959 3.1.1.5.2  | | |x| | |
+  EBCDIC - (any form)                      |959 3.1.1.2    | | |x| | |
+  IMAGE                                    |4.1.2.1        |x| | | | |
+  LOCAL 8                                  |4.1.2.1        |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 41]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+  LOCAL m                                  |4.1.2.1        | | |x| | |2
+                                           |               | | | | | |
+Support MODE:                              |               | | | | | |
+  Stream                                   |4.1.2.13       |x| | | | |
+  Block                                    |959 3.4.2      | | |x| | |
+                                           |               | | | | | |
+Support STRUCTURE:                         |               | | | | | |
+  File                                     |4.1.2.13       |x| | | | |
+  Record                                   |4.1.2.13       |x| | | | |3
+  Page                                     |4.1.2.3        | | | |x| |
+                                           |               | | | | | |
+Support commands:                          |               | | | | | |
+  USER                                     |4.1.2.13       |x| | | | |
+  PASS                                     |4.1.2.13       |x| | | | |
+  ACCT                                     |4.1.2.13       |x| | | | |
+  CWD                                      |4.1.2.13       |x| | | | |
+  CDUP                                     |4.1.2.13       |x| | | | |
+  SMNT                                     |959 5.3.1      | | |x| | |
+  REIN                                     |959 5.3.1      | | |x| | |
+  QUIT                                     |4.1.2.13       |x| | | | |
+                                           |               | | | | | |
+  PORT                                     |4.1.2.13       |x| | | | |
+  PASV                                     |4.1.2.6        |x| | | | |
+  TYPE                                     |4.1.2.13       |x| | | | |1
+  STRU                                     |4.1.2.13       |x| | | | |1
+  MODE                                     |4.1.2.13       |x| | | | |1
+                                           |               | | | | | |
+  RETR                                     |4.1.2.13       |x| | | | |
+  STOR                                     |4.1.2.13       |x| | | | |
+  STOU                                     |959 5.3.1      | | |x| | |
+  APPE                                     |4.1.2.13       |x| | | | |
+  ALLO                                     |959 5.3.1      | | |x| | |
+  REST                                     |959 5.3.1      | | |x| | |
+  RNFR                                     |4.1.2.13       |x| | | | |
+  RNTO                                     |4.1.2.13       |x| | | | |
+  ABOR                                     |959 5.3.1      | | |x| | |
+  DELE                                     |4.1.2.13       |x| | | | |
+  RMD                                      |4.1.2.13       |x| | | | |
+  MKD                                      |4.1.2.13       |x| | | | |
+  PWD                                      |4.1.2.13       |x| | | | |
+  LIST                                     |4.1.2.13       |x| | | | |
+  NLST                                     |4.1.2.13       |x| | | | |
+  SITE                                     |4.1.2.8        | | |x| | |
+  STAT                                     |4.1.2.13       |x| | | | |
+  SYST                                     |4.1.2.13       |x| | | | |
+  HELP                                     |4.1.2.13       |x| | | | |
+  NOOP                                     |4.1.2.13       |x| | | | |
+                                           |               | | | | | |
+
+
+
+Internet Engineering Task Force                                [Page 42]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+User Interface:                            |               | | | | | |
+  Arbitrary pathnames                      |4.1.4.1        |x| | | | |
+  Implement "QUOTE" command                |4.1.4.2        |x| | | | |
+  Transfer control commands immediately    |4.1.4.2        | |x| | | |
+  Display error messages to user           |4.1.4.3        | |x| | | |
+    Verbose mode                           |4.1.4.3        | |x| | | |
+  Maintain synchronization with server     |4.1.4.4        | |x| | | |
+
+Footnotes:
+
+(1)  For the values shown earlier.
+
+(2)  Here m is number of bits in a memory word.
+
+(3)  Required for host with record-structured file system, optional
+     otherwise.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 43]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+   4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
+
+      4.2.1  INTRODUCTION
+
+         The Trivial File Transfer Protocol TFTP is defined in RFC-783
+         [TFTP:1].
+
+         TFTP provides its own reliable delivery with UDP as its
+         transport protocol, using a simple stop-and-wait acknowledgment
+         system.  Since TFTP has an effective window of only one 512
+         octet segment, it can provide good performance only over paths
+         that have a small delay*bandwidth product.  The TFTP file
+         interface is very simple, providing no access control or
+         security.
+
+         TFTP's most important application is bootstrapping a host over
+         a local network, since it is simple and small enough to be
+         easily implemented in EPROM [BOOT:1, BOOT:2].  Vendors are
+         urged to support TFTP for booting.
+
+      4.2.2  PROTOCOL WALK-THROUGH
+
+         The TFTP specification [TFTP:1] is written in an open style,
+         and does not fully specify many parts of the protocol.
+
+         4.2.2.1  Transfer Modes: RFC-783, Page 3
+
+            The transfer mode "mail" SHOULD NOT be supported.
+
+         4.2.2.2  UDP Header: RFC-783, Page 17
+
+            The Length field of a UDP header is incorrectly defined; it
+            includes the UDP header length (8).
+
+      4.2.3  SPECIFIC ISSUES
+
+         4.2.3.1  Sorcerer's Apprentice Syndrome
+
+            There is a serious bug, known as the "Sorcerer's Apprentice
+            Syndrome," in the protocol specification.  While it does not
+            cause incorrect operation of the transfer (the file will
+            always be transferred correctly if the transfer completes),
+            this bug may cause excessive retransmission, which may cause
+            the transfer to time out.
+
+            Implementations MUST contain the fix for this problem: the
+            sender (i.e., the side originating the DATA packets) must
+            never resend the current DATA packet on receipt of a
+
+
+
+Internet Engineering Task Force                                [Page 44]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+            duplicate ACK.
+
+            DISCUSSION:
+                 The bug is caused by the protocol rule that either
+                 side, on receiving an old duplicate datagram, may
+                 resend the current datagram.  If a packet is delayed in
+                 the network but later successfully delivered after
+                 either side has timed out and retransmitted a packet, a
+                 duplicate copy of the response may be generated.  If
+                 the other side responds to this duplicate with a
+                 duplicate of its own, then every datagram will be sent
+                 in duplicate for the remainder of the transfer (unless
+                 a datagram is lost, breaking the repetition).  Worse
+                 yet, since the delay is often caused by congestion,
+                 this duplicate transmission will usually causes more
+                 congestion, leading to more delayed packets, etc.
+
+                 The following example may help to clarify this problem.
+
+                     TFTP A                  TFTP B
+
+                 (1)  Receive ACK X-1
+                      Send DATA X
+                 (2)                          Receive DATA X
+                                              Send ACK X
+                        (ACK X is delayed in network,
+                         and  A times out):
+                 (3)  Retransmit DATA X
+
+                 (4)                          Receive DATA X again
+                                              Send ACK X again
+                 (5)  Receive (delayed) ACK X
+                      Send DATA X+1
+                 (6)                          Receive DATA X+1
+                                              Send ACK X+1
+                 (7)  Receive ACK X again
+                      Send DATA X+1 again
+                 (8)                          Receive DATA X+1 again
+                                              Send ACK X+1 again
+                 (9)  Receive ACK X+1
+                      Send DATA X+2
+                 (10)                         Receive DATA X+2
+                                              Send ACK X+3
+                 (11) Receive ACK X+1 again
+                      Send DATA X+2 again
+                 (12)                         Receive DATA X+2 again
+                                              Send ACK X+3 again
+
+
+
+
+Internet Engineering Task Force                                [Page 45]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+                 Notice that once the delayed ACK arrives, the protocol
+                 settles down to duplicate all further packets
+                 (sequences 5-8 and 9-12).  The problem is caused not by
+                 either side timing out, but by both sides
+                 retransmitting the current packet when they receive a
+                 duplicate.
+
+                 The fix is to break the retransmission loop, as
+                 indicated above.  This is analogous to the behavior of
+                 TCP.  It is then possible to remove the retransmission
+                 timer on the receiver, since the resent ACK will never
+                 cause any action; this is a useful simplification where
+                 TFTP is used in a bootstrap program.  It is OK to allow
+                 the timer to remain, and it may be helpful if the
+                 retransmitted ACK replaces one that was genuinely lost
+                 in the network.  The sender still requires a retransmit
+                 timer, of course.
+
+         4.2.3.2  Timeout Algorithms
+
+            A TFTP implementation MUST use an adaptive timeout.
+
+            IMPLEMENTATION:
+                 TCP retransmission algorithms provide a useful base to
+                 work from.  At least an exponential backoff of
+                 retransmission timeout is necessary.
+
+         4.2.3.3  Extensions
+
+            A variety of non-standard extensions have been made to TFTP,
+            including additional transfer modes and a secure operation
+            mode (with passwords).  None of these have been
+            standardized.
+
+         4.2.3.4  Access Control
+
+            A server TFTP implementation SHOULD include some
+            configurable access control over what pathnames are allowed
+            in TFTP operations.
+
+         4.2.3.5  Broadcast Request
+
+            A TFTP request directed to a broadcast address SHOULD be
+            silently ignored.
+
+            DISCUSSION:
+                 Due to the weak access control capability of TFTP,
+                 directed broadcasts of TFTP requests to random networks
+
+
+
+Internet Engineering Task Force                                [Page 46]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+                 could create a significant security hole.
+
+      4.2.4  TFTP REQUIREMENTS SUMMARY
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+Fix Sorcerer's Apprentice Syndrome               |4.2.3.1 |x| | | | |
+Transfer modes:                                  |        | | | | | |
+  netascii                                       |RFC-783 |x| | | | |
+  octet                                          |RFC-783 |x| | | | |
+  mail                                           |4.2.2.1 | | | |x| |
+  extensions                                     |4.2.3.3 | | |x| | |
+Use adaptive timeout                             |4.2.3.2 |x| | | | |
+Configurable access control                      |4.2.3.4 | |x| | | |
+Silently ignore broadcast request                |4.2.3.5 | |x| | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+-------------------------------------------------|--------|-|-|-|-|-|--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 47]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+5.  ELECTRONIC MAIL -- SMTP and RFC-822
+
+   5.1  INTRODUCTION
+
+      In the TCP/IP protocol suite, electronic mail in a format
+      specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
+      Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
+
+      While SMTP has remained unchanged over the years, the Internet
+      community has made several changes in the way SMTP is used.  In
+      particular, the conversion to the Domain Name System (DNS) has
+      caused changes in address formats and in mail routing.  In this
+      section, we assume familiarity with the concepts and terminology
+      of the DNS, whose requirements are given in Section 6.1.
+
+      RFC-822 specifies the Internet standard format for electronic mail
+      messages.  RFC-822 supercedes an older standard, RFC-733, that may
+      still be in use in a few places, although it is obsolete.  The two
+      formats are sometimes referred to simply by number ("822" and
+      "733").
+
+      RFC-822 is used in some non-Internet mail environments with
+      different mail transfer protocols than SMTP, and SMTP has also
+      been adapted for use in some non-Internet environments.  Note that
+      this document presents the rules for the use of SMTP and RFC-822
+      for the Internet environment only; other mail environments that
+      use these protocols may be expected to have their own rules.
+
+   5.2  PROTOCOL WALK-THROUGH
+
+      This section covers both RFC-821 and RFC-822.
+
+      The SMTP specification in RFC-821 is clear and contains numerous
+      examples, so implementors should not find it difficult to
+      understand.  This section simply updates or annotates portions of
+      RFC-821 to conform with current usage.
+
+      RFC-822 is a long and dense document, defining a rich syntax.
+      Unfortunately, incomplete or defective implementations of RFC-822
+      are common.  In fact, nearly all of the many formats of RFC-822
+      are actually used, so an implementation generally needs to
+      recognize and correctly interpret all of the RFC-822 syntax.
+
+      5.2.1  The SMTP Model: RFC-821 Section 2
+
+         DISCUSSION:
+              Mail is sent by a series of request/response transactions
+              between a client, the "sender-SMTP," and a server, the
+
+
+
+Internet Engineering Task Force                                [Page 48]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              "receiver-SMTP".  These transactions pass (1) the message
+              proper, which is composed of header and body, and (2) SMTP
+              source and destination addresses, referred to as the
+              "envelope".
+
+              The SMTP programs are analogous to Message Transfer Agents
+              (MTAs) of X.400.  There will be another level of protocol
+              software, closer to the end user, that is responsible for
+              composing and analyzing RFC-822 message headers; this
+              component is known as the "User Agent" in X.400, and we
+              use that term in this document.  There is a clear logical
+              distinction between the User Agent and the SMTP
+              implementation, since they operate on different levels of
+              protocol.  Note, however, that this distinction is may not
+              be exactly reflected the structure of typical
+              implementations of Internet mail.  Often there is a
+              program known as the "mailer" that implements SMTP and
+              also some of the User Agent functions; the rest of the
+              User Agent functions are included in a user interface used
+              for entering and reading mail.
+
+              The SMTP envelope is constructed at the originating site,
+              typically by the User Agent when the message is first
+              queued for the Sender-SMTP program.  The envelope
+              addresses may be derived from information in the message
+              header, supplied by the user interface (e.g., to implement
+              a bcc: request), or derived from local configuration
+              information (e.g., expansion of a mailing list).  The SMTP
+              envelope cannot in general be re-derived from the header
+              at a later stage in message delivery, so the envelope is
+              transmitted separately from the message itself using the
+              MAIL and RCPT commands of SMTP.
+
+              The text of RFC-821 suggests that mail is to be delivered
+              to an individual user at a host.  With the advent of the
+              domain system and of mail routing using mail-exchange (MX)
+              resource records, implementors should now think of
+              delivering mail to a user at a domain, which may or may
+              not be a particular host.  This DOES NOT change the fact
+              that SMTP is a host-to-host mail exchange protocol.
+
+      5.2.2  Canonicalization: RFC-821 Section 3.1
+
+         The domain names that a Sender-SMTP sends in MAIL and RCPT
+         commands MUST have been  "canonicalized," i.e., they must be
+         fully-qualified principal names or domain literals, not
+         nicknames or domain abbreviations.  A canonicalized name either
+         identifies a host directly or is an MX name; it cannot be a
+
+
+
+Internet Engineering Task Force                                [Page 49]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         CNAME.
+
+      5.2.3  VRFY and EXPN Commands: RFC-821 Section 3.3
+
+         A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
+         (this requirement overrides RFC-821).  However, there MAY be
+         configuration information to disable VRFY and EXPN in a
+         particular installation; this might even allow EXPN to be
+         disabled for selected lists.
+
+         A new reply code is defined for the VRFY command:
+
+              252 Cannot VRFY user (e.g., info is not local), but will
+                  take message for this user and attempt delivery.
+
+         DISCUSSION:
+              SMTP users and administrators make regular use of these
+              commands for diagnosing mail delivery problems.  With the
+              increasing use of multi-level mailing list expansion
+              (sometimes more than two levels), EXPN has been
+              increasingly important for diagnosing inadvertent mail
+              loops.  On the other hand,  some feel that EXPN represents
+              a significant privacy, and perhaps even a security,
+              exposure.
+
+      5.2.4  SEND, SOML, and SAML Commands: RFC-821 Section 3.4
+
+         An SMTP MAY implement the commands to send a message to a
+         user's terminal: SEND, SOML, and SAML.
+
+         DISCUSSION:
+              It has been suggested that the use of mail relaying
+              through an MX record is inconsistent with the intent of
+              SEND to deliver a message immediately and directly to a
+              user's terminal.  However, an SMTP receiver that is unable
+              to write directly to the user terminal can return a "251
+              User Not Local" reply to the RCPT following a SEND, to
+              inform the originator of possibly deferred delivery.
+
+      5.2.5  HELO Command: RFC-821 Section 3.5
+
+         The sender-SMTP MUST ensure that the <domain> parameter in a
+         HELO command is a valid principal host domain name for the
+         client host.  As a result, the receiver-SMTP will not have to
+         perform MX resolution on this name in order to validate the
+         HELO parameter.
+
+         The HELO receiver MAY verify that the HELO parameter really
+
+
+
+Internet Engineering Task Force                                [Page 50]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         corresponds to the IP address of the sender.  However, the
+         receiver MUST NOT refuse to accept a message, even if the
+         sender's HELO command fails verification.
+
+         DISCUSSION:
+              Verifying the HELO parameter requires a domain name lookup
+              and may therefore take considerable time.  An alternative
+              tool for tracking bogus mail sources is suggested below
+              (see "DATA Command").
+
+              Note also that the HELO argument is still required to have
+              valid <domain> syntax, since it will appear in a Received:
+              line; otherwise, a 501 error is to be sent.
+
+         IMPLEMENTATION:
+              When HELO parameter validation fails, a suggested
+              procedure is to insert a note about the unknown
+              authenticity of the sender into the message header (e.g.,
+              in the "Received:"  line).
+
+      5.2.6  Mail Relay: RFC-821 Section 3.6
+
+         We distinguish three types of mail (store-and-) forwarding:
+
+         (1)  A simple forwarder or "mail exchanger" forwards a message
+              using private knowledge about the recipient; see section
+              3.2 of RFC-821.
+
+         (2)  An SMTP mail "relay" forwards a message within an SMTP
+              mail environment as the result of an explicit source route
+              (as defined in section 3.6 of RFC-821).  The SMTP relay
+              function uses the "@...:" form of source route from RFC-
+              822 (see Section 5.2.19 below).
+
+         (3)  A mail "gateway" passes a message between different
+              environments.  The rules for mail gateways are discussed
+              below in Section 5.3.7.
+
+         An Internet host that is forwarding a message but is not a
+         gateway to a different mail environment (i.e., it falls under
+         (1) or (2)) SHOULD NOT alter any existing header fields,
+         although the host will add an appropriate Received: line as
+         required in Section 5.2.8.
+
+         A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
+         explicit source route using the "@...:" address form.  Thus,
+         the relay function defined in section  3.6 of RFC-821 should
+         not be used.
+
+
+
+Internet Engineering Task Force                                [Page 51]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              The intent is to discourage all source routing and to
+              abolish explicit source routing for mail delivery within
+              the Internet environment.  Source-routing is unnecessary;
+              the simple target address "user@domain" should always
+              suffice.  This is the result of an explicit architectural
+              decision to use universal naming rather than source
+              routing for mail.  Thus, SMTP provides end-to-end
+              connectivity, and the DNS provides globally-unique,
+              location-independent names.  MX records handle the major
+              case where source routing might otherwise be needed.
+
+         A receiver-SMTP MUST accept the explicit source route syntax in
+         the envelope, but it MAY implement the relay function as
+         defined in section 3.6 of RFC-821.  If it does not implement
+         the relay function, it SHOULD attempt to deliver the message
+         directly to the host to the right of the right-most "@" sign.
+
+         DISCUSSION:
+              For example, suppose a host that does not implement the
+              relay function receives a message with the SMTP command:
+              "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
+              GAMMA represent domain names.  Rather than immediately
+              refusing the message with a 550 error reply as suggested
+              on page 20 of RFC-821, the host should try to forward the
+              message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
+              Since this host does not support relaying, it is not
+              required to update the reverse path.
+
+              Some have suggested that source routing may be needed
+              occasionally for manually routing mail around failures;
+              however, the reality and importance of this need is
+              controversial.  The use of explicit SMTP mail relaying for
+              this purpose is discouraged, and in fact it may not be
+              successful, as many host systems do not support it.  Some
+              have used the "%-hack" (see Section 5.2.16) for this
+              purpose.
+
+      5.2.7  RCPT Command: RFC-821 Section 4.1.1
+
+         A host that supports a receiver-SMTP MUST support the reserved
+         mailbox "Postmaster".
+
+         The receiver-SMTP MAY verify RCPT parameters as they arrive;
+         however, RCPT responses MUST NOT be delayed beyond a reasonable
+         time (see Section 5.3.2).
+
+         Therefore, a "250 OK" response to a RCPT does not necessarily
+
+
+
+Internet Engineering Task Force                                [Page 52]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         imply that the delivery address(es) are valid.  Errors found
+         after message acceptance will be reported by mailing a
+         notification message to an appropriate address (see Section
+         5.3.3).
+
+         DISCUSSION:
+              The set of conditions under which a RCPT parameter can be
+              validated immediately is an engineering design choice.
+              Reporting destination mailbox errors to the Sender-SMTP
+              before mail is transferred is generally desirable to save
+              time and network bandwidth, but this advantage is lost if
+              RCPT verification is lengthy.
+
+              For example, the receiver can verify immediately any
+              simple local reference, such as a single locally-
+              registered mailbox.  On the other hand, the "reasonable
+              time" limitation generally implies deferring verification
+              of a mailing list until after the message has been
+              transferred and accepted, since verifying a large mailing
+              list can take a very long time.  An implementation might
+              or might not choose to defer validation of addresses that
+              are non-local and therefore require a DNS lookup.  If a
+              DNS lookup is performed but a soft domain system error
+              (e.g., timeout) occurs, validity must be assumed.
+
+      5.2.8  DATA Command: RFC-821 Section 4.1.1
+
+         Every receiver-SMTP (not just one that "accepts a message for
+         relaying or for final delivery" [SMTP:1]) MUST insert a
+         "Received:" line at the beginning of a message.  In this line,
+         called a "time stamp line" in RFC-821:
+
+         *    The FROM field SHOULD contain both (1) the name of the
+              source host as presented in the HELO command and (2) a
+              domain literal containing the IP address of the source,
+              determined from the TCP connection.
+
+         *    The ID field MAY contain an "@" as suggested in RFC-822,
+              but this is not required.
+
+         *    The FOR field MAY contain a list of <path> entries when
+              multiple RCPT commands have been given.
+
+
+         An Internet mail program MUST NOT change a Received: line that
+         was previously added to the message header.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 53]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              Including both the source host and the IP source address
+              in the Received: line may provide enough information for
+              tracking illicit mail sources and eliminate a need to
+              explicitly verify the HELO parameter.
+
+              Received: lines are primarily intended for humans tracing
+              mail routes, primarily of diagnosis of faults.  See also
+              the discussion under 5.3.7.
+
+         When the receiver-SMTP makes "final delivery" of a message,
+         then it MUST pass the MAIL FROM: address from the SMTP envelope
+         with the message, for use if an error notification message must
+         be sent later (see Section 5.3.3).  There is an analogous
+         requirement when gatewaying from the Internet into a different
+         mail environment; see Section 5.3.7.
+
+         DISCUSSION:
+              Note that the final reply to the DATA command depends only
+              upon the successful transfer and storage of the message.
+              Any problem with the destination address(es) must either
+              (1) have been reported in an SMTP error reply to the RCPT
+              command(s), or (2) be reported in a later error message
+              mailed to the originator.
+
+         IMPLEMENTATION:
+              The MAIL FROM: information may be passed as a parameter or
+              in a Return-Path: line inserted at the beginning of the
+              message.
+
+      5.2.9  Command Syntax: RFC-821 Section 4.1.2
+
+         The syntax shown in RFC-821 for the MAIL FROM: command omits
+         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
+         15).  An empty reverse path MUST be supported.
+
+      5.2.10  SMTP Replies:  RFC-821 Section 4.2
+
+         A receiver-SMTP SHOULD send only the reply codes listed in
+         section 4.2.2 of RFC-821 or in this document.  A receiver-SMTP
+         SHOULD use the text shown in examples in RFC-821 whenever
+         appropriate.
+
+         A sender-SMTP MUST determine its actions only by the reply
+         code, not by the text (except for 251 and 551 replies); any
+         text, including no text at all, must be acceptable.  The space
+         (blank) following the reply code is considered part of the
+         text.  Whenever possible, a sender-SMTP SHOULD test only the
+
+
+
+Internet Engineering Task Force                                [Page 54]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         first digit of the reply code, as specified in Appendix E of
+         RFC-821.
+
+         DISCUSSION:
+              Interoperability problems have arisen with SMTP systems
+              using reply codes that are not listed explicitly in RFC-
+              821 Section 4.3 but are legal according to the theory of
+              reply codes explained in Appendix E.
+
+      5.2.11  Transparency: RFC-821 Section 4.5.2
+
+         Implementors MUST be sure that their mail systems always add
+         and delete periods to ensure message transparency.
+
+      5.2.12  WKS Use in MX Processing: RFC-974, p. 5
+
+         RFC-974 [SMTP:3] recommended that the domain system be queried
+         for WKS ("Well-Known Service") records, to verify that each
+         proposed mail target does support SMTP.  Later experience has
+         shown that WKS is not widely supported, so the WKS step in MX
+         processing SHOULD NOT be used.
+
+      The following are notes on RFC-822, organized by section of that
+      document.
+
+      5.2.13  RFC-822 Message Specification: RFC-822 Section 4
+
+         The syntax shown for the Return-path line omits the possibility
+         of a null return path, which is used to prevent looping of
+         error notifications (see Section 5.3.3).  The complete syntax
+         is:
+
+             return = "Return-path"  ":" route-addr
+                    / "Return-path"  ":" "<" ">"
+
+         The set of optional header fields is hereby expanded to include
+         the Content-Type field defined in RFC-1049 [SMTP:7].  This
+         field "allows mail reading systems to automatically identify
+         the type of a structured message body and to process it for
+         display accordingly".  [SMTP:7]  A User Agent MAY support this
+         field.
+
+      5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
+
+         The syntax for the date is hereby changed to:
+
+            date = 1*2DIGIT month 2*4DIGIT
+
+
+
+
+Internet Engineering Task Force                                [Page 55]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         All mail software SHOULD use 4-digit years in dates, to ease
+         the transition to the next century.
+
+         There is a strong trend towards the use of numeric timezone
+         indicators, and implementations SHOULD use numeric timezones
+         instead of timezone names.  However, all implementations MUST
+         accept either notation.  If timezone names are used, they MUST
+         be exactly as defined in RFC-822.
+
+         The military time zones are specified incorrectly in RFC-822:
+         they count the wrong way from UT (the signs are reversed).  As
+         a result, military time zones in RFC-822 headers carry no
+         information.
+
+         Finally, note that there is a typo in the definition of "zone"
+         in the syntax summary of appendix D; the correct definition
+         occurs in Section 3 of RFC-822.
+
+      5.2.15  RFC-822 Syntax Change: RFC-822 Section 6.1
+
+         The syntactic definition of "mailbox" in RFC-822 is hereby
+         changed to:
+
+            mailbox =  addr-spec            ; simple address
+                    / [phrase] route-addr   ; name & addr-spec
+
+         That is, the phrase preceding a route address is now OPTIONAL.
+         This change makes the following header field legal, for
+         example:
+
+             From: <craig@nnsc.nsf.net>
+
+      5.2.16  RFC-822  Local-part: RFC-822 Section 6.2
+
+         The basic mailbox address specification has the form: "local-
+         part@domain".  Here "local-part", sometimes called the "left-
+         hand side" of the address, is domain-dependent.
+
+         A host that is forwarding the message but is not the
+         destination host implied by the right-hand side "domain" MUST
+         NOT interpret or modify the "local-part" of the address.
+
+         When mail is to be gatewayed from the Internet mail environment
+         into a foreign mail environment (see Section 5.3.7), routing
+         information for that foreign environment MAY be embedded within
+         the "local-part" of the address.  The gateway will then
+         interpret this local part appropriately for the foreign mail
+         environment.
+
+
+
+Internet Engineering Task Force                                [Page 56]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              Although source routes are discouraged within the Internet
+              (see Section 5.2.6), there are non-Internet mail
+              environments whose delivery mechanisms do depend upon
+              source routes.  Source routes for extra-Internet
+              environments can generally be buried in the "local-part"
+              of the address (see Section 5.2.16) while mail traverses
+              the Internet.  When the mail reaches the appropriate
+              Internet mail gateway, the gateway will interpret the
+              local-part and build the necessary address or route for
+              the target mail environment.
+
+              For example, an Internet host might send mail to:
+              "a!b!c!user@gateway-domain".  The complex local part
+              "a!b!c!user" would be uninterpreted within the Internet
+              domain, but could be parsed and understood by the
+              specified mail gateway.
+
+              An embedded source route is sometimes encoded in the
+              "local-part" using "%" as a right-binding routing
+              operator.  For example, in:
+
+                 user%domain%relay3%relay2@relay1
+
+              the "%" convention implies that the mail is to be routed
+              from "relay1" through "relay2", "relay3", and finally to
+              "user" at "domain".  This is commonly known as the "%-
+              hack".  It is suggested that "%" have lower precedence
+              than any other routing operator (e.g., "!") hidden in the
+              local-part; for example, "a!b%c" would be interpreted as
+              "(a!b)%c".
+
+              Only the target host (in this case, "relay1") is permitted
+              to analyze the local-part "user%domain%relay3%relay2".
+
+      5.2.17  Domain Literals: RFC-822 Section 6.2.3
+
+         A mailer MUST be able to accept and parse an Internet domain
+         literal whose content ("dtext"; see RFC-822) is a dotted-
+         decimal host address.  This satisfies the requirement of
+         Section 2.1 for the case of mail.
+
+         An SMTP MUST accept and recognize a domain literal for any of
+         its own IP addresses.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 57]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+      5.2.18  Common Address Formatting Errors: RFC-822 Section 6.1
+
+         Errors in formatting or parsing 822 addresses are unfortunately
+         common.  This section mentions only the most common errors.  A
+         User Agent MUST accept all valid RFC-822 address formats, and
+         MUST NOT generate illegal address syntax.
+
+         o    A common error is to leave out the semicolon after a group
+              identifier.
+
+         o    Some systems fail to fully-qualify domain names in
+              messages they generate.  The right-hand side of an "@"
+              sign in a header address field MUST be a fully-qualified
+              domain name.
+
+              For example, some systems fail to fully-qualify the From:
+              address; this prevents a "reply" command in the user
+              interface from automatically constructing a return
+              address.
+
+              DISCUSSION:
+                   Although RFC-822 allows the local use of abbreviated
+                   domain names within a domain, the application of
+                   RFC-822 in Internet mail does not allow this.  The
+                   intent is that an Internet host must not send an SMTP
+                   message header containing an abbreviated domain name
+                   in an address field.  This allows the address fields
+                   of the header to be passed without alteration across
+                   the Internet, as required in Section 5.2.6.
+
+         o    Some systems mis-parse multiple-hop explicit source routes
+              such as:
+
+                  @relay1,@relay2,@relay3:user@domain.
+
+
+         o    Some systems over-qualify domain names by adding a
+              trailing dot to some or all domain names in addresses or
+              message-ids.  This violates RFC-822 syntax.
+
+
+      5.2.19  Explicit Source Routes: RFC-822 Section 6.2.7
+
+         Internet host software SHOULD NOT create an RFC-822 header
+         containing an address with an explicit source route, but MUST
+         accept such headers for compatibility with earlier systems.
+
+         DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 58]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              In an understatement, RFC-822 says "The use of explicit
+              source routing is discouraged".  Many hosts implemented
+              RFC-822 source routes incorrectly, so the syntax cannot be
+              used unambiguously in practice.  Many users feel the
+              syntax is ugly.  Explicit source routes are not needed in
+              the mail envelope for delivery; see Section 5.2.6.  For
+              all these reasons, explicit source routes using the RFC-
+              822 notations are not to be used in Internet mail headers.
+
+              As stated in Section 5.2.16, it is necessary to allow an
+              explicit source route to be buried in the local-part of an
+              address, e.g., using the "%-hack", in order to allow mail
+              to be gatewayed into another environment in which explicit
+              source routing is necessary.  The vigilant will observe
+              that there is no way for a User Agent to detect and
+              prevent the use of such implicit source routing when the
+              destination is within the Internet.  We can only
+              discourage source routing of any kind within the Internet,
+              as unnecessary and undesirable.
+
+   5.3  SPECIFIC ISSUES
+
+      5.3.1  SMTP Queueing Strategies
+
+         The common structure of a host SMTP implementation includes
+         user mailboxes, one or more areas for queueing messages in
+         transit, and one or more daemon processes for sending and
+         receiving mail.  The exact structure will vary depending on the
+         needs of the users on the host and the number and size of
+         mailing lists supported by the host.  We describe several
+         optimizations that have proved helpful, particularly for
+         mailers supporting high traffic levels.
+
+         Any queueing strategy MUST include:
+
+         o    Timeouts on all activities.  See Section 5.3.2.
+
+         o    Never sending error messages in response to error
+              messages.
+
+
+         5.3.1.1 Sending Strategy
+
+            The general model of a sender-SMTP is one or more processes
+            that periodically attempt to transmit outgoing mail.  In a
+            typical system, the program that composes a message has some
+            method for requesting immediate attention for a new piece of
+            outgoing mail, while mail that cannot be transmitted
+
+
+
+Internet Engineering Task Force                                [Page 59]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+            immediately MUST be queued and periodically retried by the
+            sender.  A mail queue entry will include not only the
+            message itself but also the envelope information.
+
+            The sender MUST delay retrying a particular destination
+            after one attempt has failed.  In general, the retry
+            interval SHOULD be at least 30 minutes; however, more
+            sophisticated and variable strategies will be beneficial
+            when the sender-SMTP can determine the reason for non-
+            delivery.
+
+            Retries continue until the message is transmitted or the
+            sender gives up; the give-up time generally needs to be at
+            least 4-5 days.  The parameters to the retry algorithm MUST
+            be configurable.
+
+            A sender SHOULD keep a list of hosts it cannot reach and
+            corresponding timeouts, rather than just retrying queued
+            mail items.
+
+            DISCUSSION:
+                 Experience suggests that failures are typically
+                 transient (the target system has crashed), favoring a
+                 policy of two connection attempts in the first hour the
+                 message is in the queue, and then backing off to once
+                 every two or three hours.
+
+                 The sender-SMTP can shorten the queueing delay by
+                 cooperation with the receiver-SMTP.  In particular, if
+                 mail is received from a particular address, it is good
+                 evidence that any mail queued for that host can now be
+                 sent.
+
+                 The strategy may be further modified as a result of
+                 multiple addresses per host (see Section 5.3.4), to
+                 optimize delivery time vs. resource usage.
+
+                 A sender-SMTP may have a large queue of messages for
+                 each unavailable destination host, and if it retried
+                 all these messages in every retry cycle, there would be
+                 excessive Internet overhead and the daemon would be
+                 blocked for a long period.  Note that an SMTP can
+                 generally determine that a delivery attempt has failed
+                 only after a timeout of a minute or more; a one minute
+                 timeout per connection will result in a very large
+                 delay if it is repeated for dozens or even hundreds of
+                 queued messages.
+
+
+
+
+Internet Engineering Task Force                                [Page 60]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+            When the same message is to be delivered to several users on
+            the same host, only one copy of the message SHOULD be
+            transmitted.  That is, the sender-SMTP should use the
+            command sequence: RCPT, RCPT,... RCPT, DATA instead of the
+            sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
+            Implementation of this efficiency feature is strongly urged.
+
+            Similarly, the sender-SMTP MAY support multiple concurrent
+            outgoing mail transactions to achieve timely delivery.
+            However, some limit SHOULD be imposed to protect the host
+            from devoting all its resources to mail.
+
+            The use of the different addresses of a multihomed host is
+            discussed below.
+
+         5.3.1.2  Receiving strategy
+
+            The receiver-SMTP SHOULD attempt to keep a pending listen on
+            the SMTP port at all times.  This will require the support
+            of multiple incoming TCP connections for SMTP.  Some limit
+            MAY be imposed.
+
+            IMPLEMENTATION:
+                 When the receiver-SMTP receives mail from a particular
+                 host address, it could notify the sender-SMTP to retry
+                 any mail pending for that host address.
+
+      5.3.2  Timeouts in SMTP
+
+         There are two approaches to timeouts in the sender-SMTP:  (a)
+         limit the time for each SMTP command separately, or (b) limit
+         the time for the entire SMTP dialogue for a single mail
+         message.  A sender-SMTP SHOULD use option (a), per-command
+         timeouts.  Timeouts SHOULD be easily reconfigurable, preferably
+         without recompiling the SMTP code.
+
+         DISCUSSION:
+              Timeouts are an essential feature of an SMTP
+              implementation.  If the timeouts are too long (or worse,
+              there are no timeouts), Internet communication failures or
+              software bugs in receiver-SMTP programs can tie up SMTP
+              processes indefinitely.  If the timeouts are too short,
+              resources will be wasted with attempts that time out part
+              way through message delivery.
+
+              If option (b) is used, the timeout has to be very large,
+              e.g., an hour, to allow time to expand very large mailing
+              lists.  The timeout may also need to increase linearly
+
+
+
+Internet Engineering Task Force                                [Page 61]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              with the size of the message, to account for the time to
+              transmit a very large message.  A large fixed timeout
+              leads to two problems:  a failure can still tie up the
+              sender for a very long time, and very large messages may
+              still spuriously time out (which is a wasteful failure!).
+
+              Using the recommended option (a), a timer is set for each
+              SMTP command and for each buffer of the data transfer.
+              The latter means that the overall timeout is inherently
+              proportional to the size of the message.
+
+         Based on extensive experience with busy mail-relay hosts, the
+         minimum per-command timeout values SHOULD be as follows:
+
+         o    Initial 220 Message: 5 minutes
+
+              A Sender-SMTP process needs to distinguish between a
+              failed TCP connection and a delay in receiving the initial
+              220 greeting message.  Many receiver-SMTPs will accept a
+              TCP connection but delay delivery of the 220 message until
+              their system load will permit more mail to be processed.
+
+         o    MAIL Command: 5 minutes
+
+
+         o    RCPT Command: 5 minutes
+
+              A longer timeout would be required if processing of
+              mailing lists and aliases were not deferred until after
+              the message was accepted.
+
+         o    DATA Initiation: 2 minutes
+
+              This is while awaiting the "354 Start Input" reply to a
+              DATA command.
+
+         o    Data Block: 3 minutes
+
+              This is while awaiting the completion of each TCP SEND
+              call transmitting a chunk of data.
+
+         o    DATA Termination: 10 minutes.
+
+              This is while awaiting the "250 OK" reply. When the
+              receiver gets the final period terminating the message
+              data, it typically performs processing to deliver the
+              message to a user mailbox.  A spurious timeout at this
+              point would be very wasteful, since the message has been
+
+
+
+Internet Engineering Task Force                                [Page 62]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              successfully sent.
+
+         A receiver-SMTP SHOULD have a timeout of at least 5 minutes
+         while it is awaiting the next command from the sender.
+
+      5.3.3  Reliable Mail Receipt
+
+         When the receiver-SMTP accepts a piece of mail (by sending a
+         "250 OK" message in response to DATA), it is accepting
+         responsibility for delivering or relaying the message.  It must
+         take this responsibility seriously, i.e., it MUST NOT lose the
+         message for frivolous reasons, e.g., because the host later
+         crashes or because of a predictable resource shortage.
+
+         If there is a delivery failure after acceptance of a message,
+         the receiver-SMTP MUST formulate and mail a notification
+         message.  This notification MUST be sent using a null ("<>")
+         reverse path in the envelope; see Section 3.6 of RFC-821.  The
+         recipient of this notification SHOULD be the address from the
+         envelope return path (or the Return-Path: line).  However, if
+         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
+         notification.  If the address is an explicit source route, it
+         SHOULD be stripped down to its final hop.
+
+         DISCUSSION:
+              For example, suppose that an error notification must be
+              sent for a message that arrived with:
+              "MAIL FROM:<@a,@b:user@d>".  The notification message
+              should be sent to: "RCPT TO:<user@d>".
+
+              Some delivery failures after the message is accepted by
+              SMTP will be unavoidable.  For example, it may be
+              impossible for the receiver-SMTP to validate all the
+              delivery addresses in RCPT command(s) due to a "soft"
+              domain system error or because the target is a mailing
+              list (see earlier discussion of RCPT).
+
+         To avoid receiving duplicate messages as the result of
+         timeouts, a receiver-SMTP MUST seek to minimize the time
+         required to respond to the final "." that ends a message
+         transfer.  See RFC-1047 [SMTP:4] for a discussion of this
+         problem.
+
+      5.3.4  Reliable Mail Transmission
+
+         To transmit a message, a sender-SMTP determines the IP address
+         of the target host from the destination address in the
+         envelope.  Specifically, it maps the string to the right of the
+
+
+
+Internet Engineering Task Force                                [Page 63]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         "@" sign into an IP address.  This mapping or the transfer
+         itself may fail with a soft error, in which case the sender-
+         SMTP will requeue the outgoing mail for a later retry, as
+         required in Section 5.3.1.1.
+
+         When it succeeds, the mapping can result in a list of
+         alternative delivery addresses rather than a single address,
+         because of (a) multiple MX records, (b) multihoming, or both.
+         To provide reliable mail transmission, the sender-SMTP MUST be
+         able to try (and retry) each of the addresses in this list in
+         order, until a delivery attempt succeeds.  However, there MAY
+         also be a configurable limit on the number of alternate
+         addresses that can be tried.  In any case, a host SHOULD try at
+         least two addresses.
+
+         The following information is to be used to rank the host
+         addresses:
+
+         (1)  Multiple MX Records -- these contain a preference
+              indication that should be used in sorting.  If there are
+              multiple destinations with the same preference and there
+              is no clear reason to favor one (e.g., by address
+              preference), then the sender-SMTP SHOULD pick one at
+              random to spread the load across multiple mail exchanges
+              for a specific organization; note that this is a
+              refinement of the procedure in [DNS:3].
+
+         (2)  Multihomed host -- The destination host (perhaps taken
+              from the preferred MX record) may be multihomed, in which
+              case the domain name resolver will return a list of
+              alternative IP addresses.  It is the responsibility of the
+              domain name resolver interface (see Section 6.1.3.4 below)
+              to have ordered this list by decreasing preference, and
+              SMTP MUST try them in the order presented.
+
+         DISCUSSION:
+              Although the capability to try multiple alternative
+              addresses is required, there may be circumstances where
+              specific installations want to limit or disable the use of
+              alternative addresses.  The question of whether a sender
+              should attempt retries using the different addresses of a
+              multihomed host has been controversial.  The main argument
+              for using the multiple addresses is that it maximizes the
+              probability of timely delivery, and indeed sometimes the
+              probability of any delivery; the counter argument is that
+              it may result in unnecessary resource use.
+
+              Note that resource use is also strongly determined by the
+
+
+
+Internet Engineering Task Force                                [Page 64]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              sending strategy discussed in Section 5.3.1.
+
+      5.3.5  Domain Name Support
+
+         SMTP implementations MUST use the mechanism defined in Section
+         6.1 for mapping between domain names and IP addresses.  This
+         means that every Internet SMTP MUST include support for the
+         Internet DNS.
+
+         In particular, a sender-SMTP MUST support the MX record scheme
+         [SMTP:3].  See also Section 7.4 of [DNS:2] for information on
+         domain name support for SMTP.
+
+      5.3.6  Mailing Lists and Aliases
+
+         An SMTP-capable host SHOULD support both the alias and the list
+         form of address expansion for multiple delivery.  When a
+         message is delivered or forwarded to each address of an
+         expanded list form, the return address in the envelope
+         ("MAIL FROM:") MUST be changed to be the address of a person
+         who administers the list, but the message header MUST be left
+         unchanged; in particular, the "From" field of the message is
+         unaffected.
+
+         DISCUSSION:
+              An important mail facility is a mechanism for multi-
+              destination delivery of a single message, by transforming
+              or "expanding" a pseudo-mailbox address into a list of
+              destination mailbox addresses.  When a message is sent to
+              such a pseudo-mailbox (sometimes called an "exploder"),
+              copies are forwarded or redistributed to each mailbox in
+              the expanded list.  We classify such a pseudo-mailbox as
+              an "alias" or a "list", depending upon the expansion
+              rules:
+
+              (a)  Alias
+
+                   To expand an alias, the recipient mailer simply
+                   replaces the pseudo-mailbox address in the envelope
+                   with each of the expanded addresses in turn; the rest
+                   of the envelope and the message body are left
+                   unchanged.  The message is then delivered or
+                   forwarded to each expanded address.
+
+              (b)  List
+
+                   A mailing list may be said to operate by
+                   "redistribution" rather than by "forwarding".  To
+
+
+
+Internet Engineering Task Force                                [Page 65]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   expand a list, the recipient mailer replaces the
+                   pseudo-mailbox address in the envelope with each of
+                   the expanded addresses in turn. The return address in
+                   the envelope is changed so that all error messages
+                   generated by the final deliveries will be returned to
+                   a list administrator, not to the message originator,
+                   who generally has no control over the contents of the
+                   list and will typically find error messages annoying.
+
+
+      5.3.7  Mail Gatewaying
+
+         Gatewaying mail between different mail environments, i.e.,
+         different mail formats and protocols, is complex and does not
+         easily yield to standardization.  See for example [SMTP:5a],
+         [SMTP:5b].  However, some general requirements may be given for
+         a gateway between the Internet and another mail environment.
+
+         (A)  Header fields MAY be rewritten when necessary as messages
+              are gatewayed across mail environment boundaries.
+
+              DISCUSSION:
+                   This may involve interpreting the local-part of the
+                   destination address, as suggested in Section 5.2.16.
+
+                   The other mail systems gatewayed to the Internet
+                   generally use a subset of RFC-822 headers, but some
+                   of them do not have an equivalent to the SMTP
+                   envelope.  Therefore, when a message leaves the
+                   Internet environment, it may be necessary to fold the
+                   SMTP envelope information into the message header.  A
+                   possible solution would be to create new header
+                   fields to carry the envelope information (e.g., "X-
+                   SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
+                   require changes in mail programs in the foreign
+                   environment.
+
+         (B)  When forwarding a message into or out of the Internet
+              environment, a gateway MUST prepend a Received: line, but
+              it MUST NOT alter in any way a Received: line that is
+              already in the header.
+
+              DISCUSSION:
+                   This requirement is a subset of the general
+                   "Received:" line requirement of Section 5.2.8; it is
+                   restated here for emphasis.
+
+                   Received: fields of messages originating from other
+
+
+
+Internet Engineering Task Force                                [Page 66]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   environments may not conform exactly to RFC822.
+                   However, the most important use of Received: lines is
+                   for debugging mail faults, and this debugging can be
+                   severely hampered by well-meaning gateways that try
+                   to "fix" a Received: line.
+
+                   The gateway is strongly encouraged to indicate the
+                   environment and protocol in the "via" clauses of
+                   Received field(s) that it supplies.
+
+         (C)  From the Internet side, the gateway SHOULD accept all
+              valid address formats in SMTP commands and in RFC-822
+              headers, and all valid RFC-822 messages.  Although a
+              gateway must accept an RFC-822 explicit source route
+              ("@...:" format) in either the RFC-822 header or in the
+              envelope, it MAY or may not act on the source route; see
+              Sections 5.2.6 and 5.2.19.
+
+              DISCUSSION:
+                   It is often tempting to restrict the range of
+                   addresses accepted at the mail gateway to simplify
+                   the translation into addresses for the remote
+                   environment.  This practice is based on the
+                   assumption that mail users have control over the
+                   addresses their mailers send to the mail gateway.  In
+                   practice, however, users have little control over the
+                   addresses that are finally sent; their mailers are
+                   free to change addresses into any legal RFC-822
+                   format.
+
+         (D)  The gateway MUST ensure that all header fields of a
+              message that it forwards into the Internet meet the
+              requirements for Internet mail.  In particular, all
+              addresses in "From:", "To:", "Cc:", etc., fields must be
+              transformed (if necessary) to satisfy RFC-822 syntax, and
+              they must be effective and useful for sending replies.
+
+
+         (E)  The translation algorithm used to convert mail from the
+              Internet protocols to another environment's protocol
+              SHOULD try to ensure that error messages from the foreign
+              mail environment are delivered to the return path from the
+              SMTP envelope, not to the sender listed in the "From:"
+              field of the RFC-822 message.
+
+              DISCUSSION:
+                   Internet mail lists usually place the address of the
+                   mail list maintainer in the envelope but leave the
+
+
+
+Internet Engineering Task Force                                [Page 67]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   original message header intact (with the "From:"
+                   field containing the original sender).  This yields
+                   the behavior the average recipient expects: a reply
+                   to the header gets sent to the original sender, not
+                   to a mail list maintainer; however, errors get sent
+                   to the maintainer (who can fix the problem) and not
+                   the sender (who probably cannot).
+
+         (F)  Similarly, when forwarding a message from another
+              environment into the Internet, the gateway SHOULD set the
+              envelope return path in accordance with an error message
+              return address, if any, supplied by the foreign
+              environment.
+
+
+      5.3.8  Maximum Message Size
+
+         Mailer software MUST be able to send and receive messages of at
+         least 64K bytes in length (including header), and a much larger
+         maximum size is highly desirable.
+
+         DISCUSSION:
+              Although SMTP does not define the maximum size of a
+              message, many systems impose implementation limits.
+
+              The current de facto minimum limit in the Internet is 64K
+              bytes.  However, electronic mail is used for a variety of
+              purposes that create much larger messages.  For example,
+              mail is often used instead of FTP for transmitting ASCII
+              files, and in particular to transmit entire documents.  As
+              a result, messages can be 1 megabyte or even larger.  We
+              note that the present document together with its lower-
+              layer companion contains 0.5 megabytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 68]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+   5.4  SMTP REQUIREMENTS SUMMARY
+
+                                               |          | | | |S| |
+                                               |          | | | |H| |F
+                                               |          | | | |O|M|o
+                                               |          | |S| |U|U|o
+                                               |          | |H| |L|S|t
+                                               |          |M|O| |D|T|n
+                                               |          |U|U|M| | |o
+                                               |          |S|L|A|N|N|t
+                                               |          |T|D|Y|O|O|t
+FEATURE                                        |SECTION   | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+RECEIVER-SMTP:                                 |          | | | | | |
+  Implement VRFY                               |5.2.3     |x| | | | |
+  Implement EXPN                               |5.2.3     | |x| | | |
+    EXPN, VRFY configurable                    |5.2.3     | | |x| | |
+  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
+  Verify HELO parameter                        |5.2.5     | | |x| | |
+    Refuse message with bad HELO               |5.2.5     | | | | |x|
+  Accept explicit src-route syntax in env.     |5.2.6     |x| | | | |
+  Support "postmaster"                         |5.2.7     |x| | | | |
+  Process RCPT when received (except lists)    |5.2.7     | | |x| | |
+      Long delay of RCPT responses             |5.2.7     | | | | |x|
+                                               |          | | | | | |
+  Add Received: line                           |5.2.8     |x| | | | |
+      Received: line include domain literal    |5.2.8     | |x| | | |
+  Change previous Received: line               |5.2.8     | | | | |x|
+  Pass Return-Path info (final deliv/gwy)      |5.2.8     |x| | | | |
+  Support empty reverse path                   |5.2.9     |x| | | | |
+  Send only official reply codes               |5.2.10    | |x| | | |
+  Send text from RFC-821 when appropriate      |5.2.10    | |x| | | |
+  Delete "." for transparency                  |5.2.11    |x| | | | |
+  Accept and recognize self domain literal(s)  |5.2.17    |x| | | | |
+                                               |          | | | | | |
+  Error message about error message            |5.3.1     | | | | |x|
+  Keep pending listen on SMTP port             |5.3.1.2   | |x| | | |
+  Provide limit on recv concurrency            |5.3.1.2   | | |x| | |
+  Wait at least 5 mins for next sender cmd     |5.3.2     | |x| | | |
+  Avoidable delivery failure after "250 OK"    |5.3.3     | | | | |x|
+  Send error notification msg after accept     |5.3.3     |x| | | | |
+    Send using null return path                |5.3.3     |x| | | | |
+    Send to envelope return path               |5.3.3     | |x| | | |
+    Send to null address                       |5.3.3     | | | | |x|
+    Strip off explicit src route               |5.3.3     | |x| | | |
+  Minimize acceptance delay (RFC-1047)         |5.3.3     |x| | | | |
+-----------------------------------------------|----------|-|-|-|-|-|--
+
+
+
+Internet Engineering Task Force                                [Page 69]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                                               |          | | | | | |
+SENDER-SMTP:                                   |          | | | | | |
+  Canonicalized domain names in MAIL, RCPT     |5.2.2     |x| | | | |
+  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
+  Send valid principal host name in HELO       |5.2.5     |x| | | | |
+  Send explicit source route in RCPT TO:       |5.2.6     | | | |x| |
+  Use only reply code to determine action      |5.2.10    |x| | | | |
+  Use only high digit of reply code when poss. |5.2.10    | |x| | | |
+  Add "." for transparency                     |5.2.11    |x| | | | |
+                                               |          | | | | | |
+  Retry messages after soft failure            |5.3.1.1   |x| | | | |
+    Delay before retry                         |5.3.1.1   |x| | | | |
+    Configurable retry parameters              |5.3.1.1   |x| | | | |
+    Retry once per each queued dest host       |5.3.1.1   | |x| | | |
+  Multiple RCPT's for same DATA                |5.3.1.1   | |x| | | |
+  Support multiple concurrent transactions     |5.3.1.1   | | |x| | |
+    Provide limit on concurrency               |5.3.1.1   | |x| | | |
+                                               |          | | | | | |
+  Timeouts on all activities                   |5.3.1     |x| | | | |
+    Per-command timeouts                       |5.3.2     | |x| | | |
+    Timeouts easily reconfigurable             |5.3.2     | |x| | | |
+    Recommended times                          |5.3.2     | |x| | | |
+  Try alternate addr's in order                |5.3.4     |x| | | | |
+    Configurable limit on alternate tries      |5.3.4     | | |x| | |
+    Try at least two alternates                |5.3.4     | |x| | | |
+  Load-split across equal MX alternates        |5.3.4     | |x| | | |
+  Use the Domain Name System                   |5.3.5     |x| | | | |
+    Support MX records                         |5.3.5     |x| | | | |
+    Use WKS records in MX processing           |5.2.12    | | | |x| |
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+MAIL FORWARDING:                               |          | | | | | |
+  Alter existing header field(s)               |5.2.6     | | | |x| |
+  Implement relay function: 821/section 3.6    |5.2.6     | | |x| | |
+    If not, deliver to RHS domain              |5.2.6     | |x| | | |
+  Interpret 'local-part' of addr               |5.2.16    | | | | |x|
+                                               |          | | | | | |
+MAILING LISTS AND ALIASES                      |          | | | | | |
+  Support both                                 |5.3.6     | |x| | | |
+  Report mail list error to local admin.       |5.3.6     |x| | | | |
+                                               |          | | | | | |
+MAIL GATEWAYS:                                 |          | | | | | |
+  Embed foreign mail route in local-part       |5.2.16    | | |x| | |
+  Rewrite header fields when necessary         |5.3.7     | | |x| | |
+  Prepend Received: line                       |5.3.7     |x| | | | |
+  Change existing Received: line               |5.3.7     | | | | |x|
+  Accept full RFC-822 on Internet side         |5.3.7     | |x| | | |
+  Act on RFC-822 explicit source route         |5.3.7     | | |x| | |
+
+
+
+Internet Engineering Task Force                                [Page 70]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+  Send only valid RFC-822 on Internet side     |5.3.7     |x| | | | |
+  Deliver error msgs to envelope addr          |5.3.7     | |x| | | |
+  Set env return path from err return addr     |5.3.7     | |x| | | |
+                                               |          | | | | | |
+USER AGENT -- RFC-822                          |          | | | | | |
+  Allow user to enter <route> address          |5.2.6     | | | |x| |
+  Support RFC-1049 Content Type field          |5.2.13    | | |x| | |
+  Use 4-digit years                            |5.2.14    | |x| | | |
+  Generate numeric timezones                   |5.2.14    | |x| | | |
+  Accept all timezones                         |5.2.14    |x| | | | |
+  Use non-num timezones from RFC-822           |5.2.14    |x| | | | |
+  Omit phrase before route-addr                |5.2.15    | | |x| | |
+  Accept and parse dot.dec. domain literals    |5.2.17    |x| | | | |
+  Accept all RFC-822 address formats           |5.2.18    |x| | | | |
+  Generate invalid RFC-822 address format      |5.2.18    | | | | |x|
+  Fully-qualified domain names in header       |5.2.18    |x| | | | |
+  Create explicit src route in header          |5.2.19    | | | |x| |
+  Accept explicit src route in header          |5.2.19    |x| | | | |
+                                               |          | | | | | |
+Send/recv at least 64KB messages               |5.3.8     |x| | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 71]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+6. SUPPORT SERVICES
+
+   6.1 DOMAIN NAME TRANSLATION
+
+      6.1.1 INTRODUCTION
+
+         Every host MUST implement a resolver for the Domain Name System
+         (DNS), and it MUST implement a mechanism using this DNS
+         resolver to convert host names to IP addresses and vice-versa
+         [DNS:1, DNS:2].
+
+         In addition to the DNS, a host MAY also implement a host name
+         translation mechanism that searches a local Internet host
+         table.  See Section 6.1.3.8 for more information on this
+         option.
+
+         DISCUSSION:
+              Internet host name translation was originally performed by
+              searching local copies of a table of all hosts.  This
+              table became too large to update and distribute in a
+              timely manner and too large to fit into many hosts, so the
+              DNS was invented.
+
+              The DNS creates a distributed database used primarily for
+              the translation between host names and host addresses.
+              Implementation of DNS software is required.  The DNS
+              consists of two logically distinct parts: name servers and
+              resolvers (although implementations often combine these
+              two logical parts in the interest of efficiency) [DNS:2].
+
+              Domain name servers store authoritative data about certain
+              sections of the database and answer queries about the
+              data.  Domain resolvers query domain name servers for data
+              on behalf of user processes.  Every host therefore needs a
+              DNS resolver; some host machines will also need to run
+              domain name servers.  Since no name server has complete
+              information, in general it is necessary to obtain
+              information from more than one name server to resolve a
+              query.
+
+      6.1.2  PROTOCOL WALK-THROUGH
+
+         An implementor must study references [DNS:1] and [DNS:2]
+         carefully.  They provide a thorough description of the theory,
+         protocol, and implementation of the domain name system, and
+         reflect several years of experience.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 72]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.2.1  Resource Records with Zero TTL: RFC-1035 Section 3.2.1
+
+            All DNS name servers and resolvers MUST properly handle RRs
+            with a zero TTL: return the RR to the client but do not
+            cache it.
+
+            DISCUSSION:
+                 Zero TTL values are interpreted to mean that the RR can
+                 only be used for the transaction in progress, and
+                 should not be cached; they are useful for extremely
+                 volatile data.
+
+         6.1.2.2  QCLASS Values: RFC-1035 Section 3.2.5
+
+            A query with "QCLASS=*" SHOULD NOT be used unless the
+            requestor is seeking data from more than one class.  In
+            particular, if the requestor is only interested in Internet
+            data types, QCLASS=IN MUST be used.
+
+         6.1.2.3  Unused Fields: RFC-1035 Section 4.1.1
+
+            Unused fields in a query or response message MUST be zero.
+
+         6.1.2.4  Compression: RFC-1035 Section 4.1.4
+
+            Name servers MUST use compression in responses.
+
+            DISCUSSION:
+                 Compression is essential to avoid overflowing UDP
+                 datagrams; see Section 6.1.3.2.
+
+         6.1.2.5  Misusing Configuration Info: RFC-1035 Section 6.1.2
+
+            Recursive name servers and full-service resolvers generally
+            have some configuration information containing hints about
+            the location of root or local name servers.  An
+            implementation MUST NOT include any of these hints in a
+            response.
+
+            DISCUSSION:
+                 Many implementors have found it convenient to store
+                 these hints as if they were cached data, but some
+                 neglected to ensure that this "cached data" was not
+                 included in responses.  This has caused serious
+                 problems in the Internet when the hints were obsolete
+                 or incorrect.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 73]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+      6.1.3  SPECIFIC ISSUES
+
+         6.1.3.1  Resolver Implementation
+
+            A name resolver SHOULD be able to multiplex concurrent
+            requests if the host supports concurrent processes.
+
+            In implementing a DNS resolver, one of two different models
+            MAY optionally be chosen: a full-service resolver, or a stub
+            resolver.
+
+
+            (A)  Full-Service Resolver
+
+                 A full-service resolver is a complete implementation of
+                 the resolver service, and is capable of dealing with
+                 communication failures, failure of individual name
+                 servers, location of the proper name server for a given
+                 name, etc.  It must satisfy the following requirements:
+
+                 o    The resolver MUST implement a local caching
+                      function to avoid repeated remote access for
+                      identical requests, and MUST time out information
+                      in the cache.
+
+                 o    The resolver SHOULD be configurable with start-up
+                      information pointing to multiple root name servers
+                      and multiple name servers for the local domain.
+                      This insures that the resolver will be able to
+                      access the whole name space in normal cases, and
+                      will be able to access local domain information
+                      should the local network become disconnected from
+                      the rest of the Internet.
+
+
+            (B)  Stub Resolver
+
+                 A "stub resolver" relies on the services of a recursive
+                 name server on the connected network or a "nearby"
+                 network.  This scheme allows the host to pass on the
+                 burden of the resolver function to a name server on
+                 another host.  This model is often essential for less
+                 capable hosts, such as PCs, and is also recommended
+                 when the host is one of several workstations on a local
+                 network, because it allows all of the workstations to
+                 share the cache of the recursive name server and hence
+                 reduce the number of domain requests exported by the
+                 local network.
+
+
+
+Internet Engineering Task Force                                [Page 74]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 At a minimum, the stub resolver MUST be capable of
+                 directing its requests to redundant recursive name
+                 servers.  Note that recursive name servers are allowed
+                 to restrict the sources of requests that they will
+                 honor, so the host administrator must verify that the
+                 service will be provided.  Stub resolvers MAY implement
+                 caching if they choose, but if so, MUST timeout cached
+                 information.
+
+
+         6.1.3.2  Transport Protocols
+
+            DNS resolvers and recursive servers MUST support UDP, and
+            SHOULD support TCP, for sending (non-zone-transfer) queries.
+            Specifically, a DNS resolver or server that is sending a
+            non-zone-transfer query MUST send a UDP query first.  If the
+            Answer section of the response is truncated and if the
+            requester supports TCP, it SHOULD try the query again using
+            TCP.
+
+            DNS servers MUST be able to service UDP queries and SHOULD
+            be able to service TCP queries.  A name server MAY limit the
+            resources it devotes to TCP queries, but it SHOULD NOT
+            refuse to service a TCP query just because it would have
+            succeeded with UDP.
+
+            Truncated responses MUST NOT be saved (cached) and later
+            used in such a way that the fact that they are truncated is
+            lost.
+
+            DISCUSSION:
+                 UDP is preferred over TCP for queries because UDP
+                 queries have much lower overhead, both in packet count
+                 and in connection state.  The use of UDP is essential
+                 for heavily-loaded servers, especially the root
+                 servers.  UDP also offers additional robustness, since
+                 a resolver can attempt several UDP queries to different
+                 servers for the cost of a single TCP query.
+
+                 It is possible for a DNS response to be truncated,
+                 although this is a very rare occurrence in the present
+                 Internet DNS.  Practically speaking, truncation cannot
+                 be predicted, since it is data-dependent.  The
+                 dependencies include the number of RRs in the answer,
+                 the size of each RR, and the savings in space realized
+                 by the name compression algorithm.  As a rule of thumb,
+                 truncation in NS and MX lists should not occur for
+                 answers containing 15 or fewer RRs.
+
+
+
+Internet Engineering Task Force                                [Page 75]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 Whether it is possible to use a truncated answer
+                 depends on the application.  A mailer must not use a
+                 truncated MX response, since this could lead to mail
+                 loops.
+
+                 Responsible practices can make UDP suffice in the vast
+                 majority of cases.  Name servers must use compression
+                 in responses.  Resolvers must differentiate truncation
+                 of the Additional section of a response (which only
+                 loses extra information) from truncation of the Answer
+                 section (which for MX records renders the response
+                 unusable by mailers).  Database administrators should
+                 list only a reasonable number of primary names in lists
+                 of name servers, MX alternatives, etc.
+
+                 However, it is also clear that some new DNS record
+                 types defined in the future will contain information
+                 exceeding the 512 byte limit that applies to UDP, and
+                 hence will require TCP.  Thus, resolvers and name
+                 servers should implement TCP services as a backup to
+                 UDP today, with the knowledge that they will require
+                 the TCP service in the future.
+
+            By private agreement, name servers and resolvers MAY arrange
+            to use TCP for all traffic between themselves.  TCP MUST be
+            used for zone transfers.
+
+            A DNS server MUST have sufficient internal concurrency that
+            it can continue to process UDP queries while awaiting a
+            response or performing a zone transfer on an open TCP
+            connection [DNS:2].
+
+            A server MAY support a UDP query that is delivered using an
+            IP broadcast or multicast address.  However, the Recursion
+            Desired bit MUST NOT be set in a query that is multicast,
+            and MUST be ignored by name servers receiving queries via a
+            broadcast or multicast address.  A host that sends broadcast
+            or multicast DNS queries SHOULD send them only as occasional
+            probes, caching the IP address(es) it obtains from the
+            response(s) so it can normally send unicast queries.
+
+            DISCUSSION:
+                 Broadcast or (especially) IP multicast can provide a
+                 way to locate nearby name servers without knowing their
+                 IP addresses in advance.  However, general broadcasting
+                 of recursive queries can result in excessive and
+                 unnecessary load on both network and servers.
+
+
+
+
+Internet Engineering Task Force                                [Page 76]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.3.3  Efficient Resource Usage
+
+            The following requirements on servers and resolvers are very
+            important to the health of the Internet as a whole,
+            particularly when DNS services are invoked repeatedly by
+            higher level automatic servers, such as mailers.
+
+            (1)  The resolver MUST implement retransmission controls to
+                 insure that it does not waste communication bandwidth,
+                 and MUST impose finite bounds on the resources consumed
+                 to respond to a single request.  See [DNS:2] pages 43-
+                 44 for specific recommendations.
+
+            (2)  After a query has been retransmitted several times
+                 without a response, an implementation MUST give up and
+                 return a soft error to the application.
+
+            (3)  All DNS name servers and resolvers SHOULD cache
+                 temporary failures, with a timeout period of the order
+                 of minutes.
+
+                 DISCUSSION:
+                      This will prevent applications that immediately
+                      retry soft failures (in violation of Section 2.2
+                      of this document) from generating excessive DNS
+                      traffic.
+
+            (4)  All DNS name servers and resolvers SHOULD cache
+                 negative responses that indicate the specified name, or
+                 data of the specified type, does not exist, as
+                 described in [DNS:2].
+
+            (5)  When a DNS server or resolver retries a UDP query, the
+                 retry interval SHOULD be constrained by an exponential
+                 backoff algorithm, and SHOULD also have upper and lower
+                 bounds.
+
+                 IMPLEMENTATION:
+                      A measured RTT and variance (if available) should
+                      be used to calculate an initial retransmission
+                      interval.  If this information is not available, a
+                      default of no less than 5 seconds should be used.
+                      Implementations may limit the retransmission
+                      interval, but this limit must exceed twice the
+                      Internet maximum segment lifetime plus service
+                      delay at the name server.
+
+            (6)  When a resolver or server receives a Source Quench for
+
+
+
+Internet Engineering Task Force                                [Page 77]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 a query it has issued, it SHOULD take steps to reduce
+                 the rate of querying that server in the near future.  A
+                 server MAY ignore a Source Quench that it receives as
+                 the result of sending a response datagram.
+
+                 IMPLEMENTATION:
+                      One recommended action to reduce the rate is to
+                      send the next query attempt to an alternate
+                      server, if there is one available.  Another is to
+                      backoff the retry interval for the same server.
+
+
+         6.1.3.4  Multihomed Hosts
+
+            When the host name-to-address function encounters a host
+            with multiple addresses, it SHOULD rank or sort the
+            addresses using knowledge of the immediately connected
+            network number(s) and any other applicable performance or
+            history information.
+
+            DISCUSSION:
+                 The different addresses of a multihomed host generally
+                 imply different Internet paths, and some paths may be
+                 preferable to others in performance, reliability, or
+                 administrative restrictions.  There is no general way
+                 for the domain system to determine the best path.  A
+                 recommended approach is to base this decision on local
+                 configuration information set by the system
+                 administrator.
+
+            IMPLEMENTATION:
+                 The following scheme has been used successfully:
+
+                 (a)  Incorporate into the host configuration data a
+                      Network-Preference List, that is simply a list of
+                      networks in preferred order.  This list may be
+                      empty if there is no preference.
+
+                 (b)  When a host name is mapped into a list of IP
+                      addresses, these addresses should be sorted by
+                      network number, into the same order as the
+                      corresponding networks in the Network-Preference
+                      List.  IP addresses whose networks do not appear
+                      in the Network-Preference List should be placed at
+                      the end of the list.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 78]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.3.5  Extensibility
+
+            DNS software MUST support all well-known, class-independent
+            formats [DNS:2], and SHOULD be written to minimize the
+            trauma associated with the introduction of new well-known
+            types and local experimentation with non-standard types.
+
+            DISCUSSION:
+                 The data types and classes used by the DNS are
+                 extensible, and thus new types will be added and old
+                 types deleted or redefined.  Introduction of new data
+                 types ought to be dependent only upon the rules for
+                 compression of domain names inside DNS messages, and
+                 the translation between printable (i.e., master file)
+                 and internal formats for Resource Records (RRs).
+
+                 Compression relies on knowledge of the format of data
+                 inside a particular RR.  Hence compression must only be
+                 used for the contents of well-known, class-independent
+                 RRs, and must never be used for class-specific RRs or
+                 RR types that are not well-known.  The owner name of an
+                 RR is always eligible for compression.
+
+                 A name server may acquire, via zone transfer, RRs that
+                 the server doesn't know how to convert to printable
+                 format.  A resolver can receive similar information as
+                 the result of queries.  For proper operation, this data
+                 must be preserved, and hence the implication is that
+                 DNS software cannot use textual formats for internal
+                 storage.
+
+                 The DNS defines domain name syntax very generally -- a
+                 string of labels each containing up to 63 8-bit octets,
+                 separated by dots, and with a maximum total of 255
+                 octets.  Particular applications of the DNS are
+                 permitted to further constrain the syntax of the domain
+                 names they use, although the DNS deployment has led to
+                 some applications allowing more general names.  In
+                 particular, Section 2.1 of this document liberalizes
+                 slightly the syntax of a legal Internet host name that
+                 was defined in RFC-952 [DNS:4].
+
+         6.1.3.6  Status of RR Types
+
+            Name servers MUST be able to load all RR types except MD and
+            MF from configuration files.  The MD and MF types are
+            obsolete and MUST NOT be implemented; in particular, name
+            servers MUST NOT load these types from configuration files.
+
+
+
+Internet Engineering Task Force                                [Page 79]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+            DISCUSSION:
+                 The RR types MB, MG, MR, NULL, MINFO and RP are
+                 considered experimental, and applications that use the
+                 DNS cannot expect these RR types to be supported by
+                 most domains.  Furthermore these types are subject to
+                 redefinition.
+
+                 The TXT and WKS RR types have not been widely used by
+                 Internet sites; as a result, an application cannot rely
+                 on the the existence of a TXT or WKS RR in most
+                 domains.
+
+         6.1.3.7  Robustness
+
+            DNS software may need to operate in environments where the
+            root servers or other servers are unavailable due to network
+            connectivity or other problems.  In this situation, DNS name
+            servers and resolvers MUST continue to provide service for
+            the reachable part of the name space, while giving temporary
+            failures for the rest.
+
+            DISCUSSION:
+                 Although the DNS is meant to be used primarily in the
+                 connected Internet, it should be possible to use the
+                 system in networks which are unconnected to the
+                 Internet.  Hence implementations must not depend on
+                 access to root servers before providing service for
+                 local names.
+
+         6.1.3.8  Local Host Table
+
+            DISCUSSION:
+                 A host may use a local host table as a backup or
+                 supplement to the DNS.  This raises the question of
+                 which takes precedence, the DNS or the host table; the
+                 most flexible approach would make this a configuration
+                 option.
+
+                 Typically, the contents of such a supplementary host
+                 table will be determined locally by the site.  However,
+                 a publically-available table of Internet hosts is
+                 maintained by the DDN Network Information Center (DDN
+                 NIC), with a format documented in [DNS:4].  This table
+                 can be retrieved from the DDN NIC using a protocol
+                 described in [DNS:5].  It must be noted that this table
+                 contains only a small fraction of all Internet hosts.
+                 Hosts using this protocol to retrieve the DDN NIC host
+                 table should use the VERSION command to check if the
+
+
+
+Internet Engineering Task Force                                [Page 80]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 table has changed before requesting the entire table
+                 with the ALL command.  The VERSION identifier should be
+                 treated as an arbitrary string and tested only for
+                 equality; no numerical sequence may be assumed.
+
+                 The DDN NIC host table includes administrative
+                 information that is not needed for host operation and
+                 is therefore not currently included in the DNS
+                 database; examples include network and gateway entries.
+                 However, much of this additional information will be
+                 added to the DNS in the future.  Conversely, the DNS
+                 provides essential services (in particular, MX records)
+                 that are not available from the DDN NIC host table.
+
+      6.1.4  DNS USER INTERFACE
+
+         6.1.4.1  DNS Administration
+
+            This document is concerned with design and implementation
+            issues in host software, not with administrative or
+            operational issues.  However, administrative issues are of
+            particular importance in the DNS, since errors in particular
+            segments of this large distributed database can cause poor
+            or erroneous performance for many sites.  These issues are
+            discussed in [DNS:6] and [DNS:7].
+
+         6.1.4.2  DNS User Interface
+
+            Hosts MUST provide an interface to the DNS for all
+            application programs running on the host.  This interface
+            will typically direct requests to a system process to
+            perform the resolver function [DNS:1, 6.1:2].
+
+            At a minimum, the basic interface MUST support a request for
+            all information of a specific type and class associated with
+            a specific name, and it MUST return either all of the
+            requested information, a hard error code, or a soft error
+            indication.  When there is no error, the basic interface
+            returns the complete response information without
+            modification, deletion, or ordering, so that the basic
+            interface will not need to be changed to accommodate new
+            data types.
+
+            DISCUSSION:
+                 The soft error indication is an essential part of the
+                 interface, since it may not always be possible to
+                 access particular information from the DNS; see Section
+                 6.1.3.3.
+
+
+
+Internet Engineering Task Force                                [Page 81]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+            A host MAY provide other DNS interfaces tailored to
+            particular functions, transforming the raw domain data into
+            formats more suited to these functions.  In particular, a
+            host MUST provide a DNS interface to facilitate translation
+            between host addresses and host names.
+
+         6.1.4.3 Interface Abbreviation Facilities
+
+            User interfaces MAY provide a method for users to enter
+            abbreviations for commonly-used names.  Although the
+            definition of such methods is outside of the scope of the
+            DNS specification, certain rules are necessary to insure
+            that these methods allow access to the entire DNS name space
+            and to prevent excessive use of Internet resources.
+
+            If an abbreviation method is provided, then:
+
+            (a)  There MUST be some convention for denoting that a name
+                 is already complete, so that the abbreviation method(s)
+                 are suppressed.  A trailing dot is the usual method.
+
+            (b)  Abbreviation expansion MUST be done exactly once, and
+                 MUST be done in the context in which the name was
+                 entered.
+
+
+            DISCUSSION:
+                 For example, if an abbreviation is used in a mail
+                 program for a destination, the abbreviation should be
+                 expanded into a full domain name and stored in the
+                 queued message with an indication that it is already
+                 complete.  Otherwise, the abbreviation might be
+                 expanded with a mail system search list, not the
+                 user's, or a name could grow due to repeated
+                 canonicalizations attempts interacting with wildcards.
+
+            The two most common abbreviation methods are:
+
+            (1)  Interface-level aliases
+
+                 Interface-level aliases are conceptually implemented as
+                 a list of alias/domain name pairs. The list can be
+                 per-user or per-host, and separate lists can be
+                 associated with different functions, e.g. one list for
+                 host name-to-address translation, and a different list
+                 for mail domains.  When the user enters a name, the
+                 interface attempts to match the name to the alias
+                 component of a list entry, and if a matching entry can
+
+
+
+Internet Engineering Task Force                                [Page 82]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 be found, the name is replaced by the domain name found
+                 in the pair.
+
+                 Note that interface-level aliases and CNAMEs are
+                 completely separate mechanisms; interface-level aliases
+                 are a local matter while CNAMEs are an Internet-wide
+                 aliasing mechanism which is a required part of any DNS
+                 implementation.
+
+            (2)  Search Lists
+
+                 A search list is conceptually implemented as an ordered
+                 list of domain names.  When the user enters a name, the
+                 domain names in the search list are used as suffixes to
+                 the user-supplied name, one by one, until a domain name
+                 with the desired associated data is found, or the
+                 search list is exhausted.  Search lists often contain
+                 the name of the local host's parent domain or other
+                 ancestor domains.  Search lists are often per-user or
+                 per-process.
+
+                 It SHOULD be possible for an administrator to disable a
+                 DNS search-list facility.  Administrative denial may be
+                 warranted in some cases, to prevent abuse of the DNS.
+
+                 There is danger that a search-list mechanism will
+                 generate excessive queries to the root servers while
+                 testing whether user input is a complete domain name,
+                 lacking a final period to mark it as complete.  A
+                 search-list mechanism MUST have one of, and SHOULD have
+                 both of, the following two provisions to prevent this:
+
+                 (a)  The local resolver/name server can implement
+                      caching  of negative responses (see Section
+                      6.1.3.3).
+
+                 (b)  The search list expander can require two or more
+                      interior dots in a generated domain name before it
+                      tries using the name in a query to non-local
+                      domain servers, such as the root.
+
+                 DISCUSSION:
+                      The intent of this requirement is to avoid
+                      excessive delay for the user as the search list is
+                      tested, and more importantly to prevent excessive
+                      traffic to the root and other high-level servers.
+                      For example, if the user supplied a name "X" and
+                      the search list contained the root as a component,
+
+
+
+Internet Engineering Task Force                                [Page 83]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                      a query would have to consult a root server before
+                      the next search list alternative could be tried.
+                      The resulting load seen by the root servers and
+                      gateways near the root would be multiplied by the
+                      number of hosts in the Internet.
+
+                      The negative caching alternative limits the effect
+                      to the first time a name is used.  The interior
+                      dot rule is simpler to implement but can prevent
+                      easy use of some top-level names.
+
+
+      6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
+
+                                               |           | | | |S| |
+                                               |           | | | |H| |F
+                                               |           | | | |O|M|o
+                                               |           | |S| |U|U|o
+                                               |           | |H| |L|S|t
+                                               |           |M|O| |D|T|n
+                                               |           |U|U|M| | |o
+                                               |           |S|L|A|N|N|t
+                                               |           |T|D|Y|O|O|t
+FEATURE                                        |SECTION    | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+GENERAL ISSUES                                 |           | | | | | |
+                                               |           | | | | | |
+Implement DNS name-to-address conversion       |6.1.1      |x| | | | |
+Implement DNS address-to-name conversion       |6.1.1      |x| | | | |
+Support conversions using host table           |6.1.1      | | |x| | |
+Properly handle RR with zero TTL               |6.1.2.1    |x| | | | |
+Use QCLASS=* unnecessarily                     |6.1.2.2    | |x| | | |
+  Use QCLASS=IN for Internet class             |6.1.2.2    |x| | | | |
+Unused fields zero                             |6.1.2.3    |x| | | | |
+Use compression in responses                   |6.1.2.4    |x| | | | |
+                                               |           | | | | | |
+Include config info in responses               |6.1.2.5    | | | | |x|
+Support all well-known, class-indep. types     |6.1.3.5    |x| | | | |
+Easily expand type list                        |6.1.3.5    | |x| | | |
+Load all RR types (except MD and MF)           |6.1.3.6    |x| | | | |
+Load MD or MF type                             |6.1.3.6    | | | | |x|
+Operate when root servers, etc. unavailable    |6.1.3.7    |x| | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOLVER ISSUES:                               |           | | | | | |
+                                               |           | | | | | |
+Resolver support multiple concurrent requests  |6.1.3.1    | |x| | | |
+Full-service resolver:                         |6.1.3.1    | | |x| | |
+  Local caching                                |6.1.3.1    |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 84]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+  Information in local cache times out         |6.1.3.1    |x| | | | |
+  Configurable with starting info              |6.1.3.1    | |x| | | |
+Stub resolver:                                 |6.1.3.1    | | |x| | |
+  Use redundant recursive name servers         |6.1.3.1    |x| | | | |
+  Local caching                                |6.1.3.1    | | |x| | |
+  Information in local cache times out         |6.1.3.1    |x| | | | |
+Support for remote multi-homed hosts:          |           | | | | | |
+  Sort multiple addresses by preference list   |6.1.3.4    | |x| | | |
+                                               |           | | | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+TRANSPORT PROTOCOLS:                           |           | | | | | |
+                                               |           | | | | | |
+Support UDP queries                            |6.1.3.2    |x| | | | |
+Support TCP queries                            |6.1.3.2    | |x| | | |
+  Send query using UDP first                   |6.1.3.2    |x| | | | |1
+  Try TCP if UDP answers are truncated         |6.1.3.2    | |x| | | |
+Name server limit TCP query resources          |6.1.3.2    | | |x| | |
+  Punish unnecessary TCP query                 |6.1.3.2    | | | |x| |
+Use truncated data as if it were not           |6.1.3.2    | | | | |x|
+Private agreement to use only TCP              |6.1.3.2    | | |x| | |
+Use TCP for zone transfers                     |6.1.3.2    |x| | | | |
+TCP usage not block UDP queries                |6.1.3.2    |x| | | | |
+Support broadcast or multicast queries         |6.1.3.2    | | |x| | |
+  RD bit set in query                          |6.1.3.2    | | | | |x|
+  RD bit ignored by server is b'cast/m'cast    |6.1.3.2    |x| | | | |
+  Send only as occasional probe for addr's     |6.1.3.2    | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOURCE USAGE:                                |           | | | | | |
+                                               |           | | | | | |
+Transmission controls, per [DNS:2]             |6.1.3.3    |x| | | | |
+  Finite bounds per request                    |6.1.3.3    |x| | | | |
+Failure after retries => soft error            |6.1.3.3    |x| | | | |
+Cache temporary failures                       |6.1.3.3    | |x| | | |
+Cache negative responses                       |6.1.3.3    | |x| | | |
+Retries use exponential backoff                |6.1.3.3    | |x| | | |
+  Upper, lower bounds                          |6.1.3.3    | |x| | | |
+Client handle Source Quench                    |6.1.3.3    | |x| | | |
+Server ignore Source Quench                    |6.1.3.3    | | |x| | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+USER INTERFACE:                                |           | | | | | |
+                                               |           | | | | | |
+All programs have access to DNS interface      |6.1.4.2    |x| | | | |
+Able to request all info for given name        |6.1.4.2    |x| | | | |
+Returns complete info or error                 |6.1.4.2    |x| | | | |
+Special interfaces                             |6.1.4.2    | | |x| | |
+  Name<->Address translation                   |6.1.4.2    |x| | | | |
+                                               |           | | | | | |
+Abbreviation Facilities:                       |6.1.4.3    | | |x| | |
+
+
+
+Internet Engineering Task Force                                [Page 85]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+  Convention for complete names                |6.1.4.3    |x| | | | |
+  Conversion exactly once                      |6.1.4.3    |x| | | | |
+  Conversion in proper context                 |6.1.4.3    |x| | | | |
+  Search list:                                 |6.1.4.3    | | |x| | |
+    Administrator can disable                  |6.1.4.3    | |x| | | |
+    Prevention of excessive root queries       |6.1.4.3    |x| | | | |
+      Both methods                             |6.1.4.3    | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+-----------------------------------------------|-----------|-|-|-|-|-|--
+
+1.   Unless there is private agreement between particular resolver and
+     particular server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 86]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+   6.2  HOST INITIALIZATION
+
+      6.2.1  INTRODUCTION
+
+         This section discusses the initialization of host software
+         across a connected network, or more generally across an
+         Internet path.  This is necessary for a diskless host, and may
+         optionally be used for a host with disk drives.  For a diskless
+         host, the initialization process is called "network booting"
+         and is controlled by a bootstrap program located in a boot ROM.
+
+         To initialize a diskless host across the network, there are two
+         distinct phases:
+
+         (1)  Configure the IP layer.
+
+              Diskless machines often have no permanent storage in which
+              to store network configuration information, so that
+              sufficient configuration information must be obtained
+              dynamically to support the loading phase that follows.
+              This information must include at least the IP addresses of
+              the host and of the boot server.  To support booting
+              across a gateway, the address mask and a list of default
+              gateways are also required.
+
+         (2)  Load the host system code.
+
+              During the loading phase, an appropriate file transfer
+              protocol is used to copy the system code across the
+              network from the boot server.
+
+         A host with a disk may perform the first step, dynamic
+         configuration.  This is important for microcomputers, whose
+         floppy disks allow network configuration information to be
+         mistakenly duplicated on more than one host.  Also,
+         installation of new hosts is much simpler if they automatically
+         obtain their configuration information from a central server,
+         saving administrator time and decreasing the probability of
+         mistakes.
+
+      6.2.2  REQUIREMENTS
+
+         6.2.2.1  Dynamic Configuration
+
+            A number of protocol provisions have been made for dynamic
+            configuration.
+
+            o    ICMP Information Request/Reply messages
+
+
+
+Internet Engineering Task Force                                [Page 87]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+                 This obsolete message pair was designed to allow a host
+                 to find the number of the network it is on.
+                 Unfortunately, it was useful only if the host already
+                 knew the host number part of its IP address,
+                 information that hosts requiring dynamic configuration
+                 seldom had.
+
+            o    Reverse Address Resolution Protocol (RARP) [BOOT:4]
+
+                 RARP is a link-layer protocol for a broadcast medium
+                 that allows a host to find its IP address given its
+                 link layer address.  Unfortunately, RARP does not work
+                 across IP gateways and therefore requires a RARP server
+                 on every network.  In addition, RARP does not provide
+                 any other configuration information.
+
+            o    ICMP Address Mask Request/Reply messages
+
+                 These ICMP messages allow a host to learn the address
+                 mask for a particular network interface.
+
+            o    BOOTP Protocol [BOOT:2]
+
+                 This protocol allows a host to determine the IP
+                 addresses of the local host and the boot server, the
+                 name of an appropriate boot file, and optionally the
+                 address mask and list of default gateways.  To locate a
+                 BOOTP server, the host broadcasts a BOOTP request using
+                 UDP.  Ad hoc gateway extensions have been used to
+                 transmit the BOOTP broadcast through gateways, and in
+                 the future the IP Multicasting facility will provide a
+                 standard mechanism for this purpose.
+
+
+            The suggested approach to dynamic configuration is to use
+            the BOOTP protocol with the extensions defined in "BOOTP
+            Vendor Information Extensions" RFC-1084 [BOOT:3].  RFC-1084
+            defines some important general (not vendor-specific)
+            extensions.  In particular, these extensions allow the
+            address mask to be supplied in BOOTP; we RECOMMEND that the
+            address mask be supplied in this manner.
+
+            DISCUSSION:
+                 Historically, subnetting was defined long after IP, and
+                 so a separate mechanism (ICMP Address Mask messages)
+                 was designed to supply the address mask to a host.
+                 However, the IP address mask and the corresponding IP
+                 address conceptually form a pair, and for operational
+
+
+
+Internet Engineering Task Force                                [Page 88]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+                 simplicity they ought to be defined at the same time
+                 and by the same mechanism, whether a configuration file
+                 or a dynamic mechanism like BOOTP.
+
+                 Note that BOOTP is not sufficiently general to specify
+                 the configurations of all interfaces of a multihomed
+                 host.  A multihomed host must either use BOOTP
+                 separately for each interface, or configure one
+                 interface using BOOTP to perform the loading, and
+                 perform the complete initialization from a file later.
+
+                 Application layer configuration information is expected
+                 to be obtained from files after loading of the system
+                 code.
+
+         6.2.2.2  Loading Phase
+
+            A suggested approach for the loading phase is to use TFTP
+            [BOOT:1] between the IP addresses established by BOOTP.
+
+            TFTP to a broadcast address SHOULD NOT be used, for reasons
+            explained in Section 4.2.3.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 89]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   6.3  REMOTE MANAGEMENT
+
+      6.3.1  INTRODUCTION
+
+         The Internet community has recently put considerable effort
+         into the development of network management protocols.  The
+         result has been a two-pronged approach [MGT:1, MGT:6]:  the
+         Simple Network Management Protocol (SNMP) [MGT:4] and the
+         Common Management Information Protocol over TCP (CMOT) [MGT:5].
+
+         In order to be managed using SNMP or CMOT, a host will need to
+         implement an appropriate management agent.  An Internet host
+         SHOULD include an agent for either SNMP or CMOT.
+
+         Both SNMP and CMOT operate on a Management Information Base
+         (MIB) that defines a collection of management values.  By
+         reading and setting these values, a remote application may
+         query and change the state of the managed system.
+
+         A standard MIB [MGT:3] has been defined for use by both
+         management protocols, using data types defined by the Structure
+         of Management Information (SMI) defined in [MGT:2].  Additional
+         MIB variables can be introduced under the "enterprises" and
+         "experimental" subtrees of the MIB naming space [MGT:2].
+
+         Every protocol module in the host SHOULD implement the relevant
+         MIB variables.  A host SHOULD implement the MIB variables as
+         defined in the most recent standard MIB, and MAY implement
+         other MIB variables when appropriate and useful.
+
+      6.3.2  PROTOCOL WALK-THROUGH
+
+         The MIB is intended to cover both hosts and gateways, although
+         there may be detailed differences in MIB application to the two
+         cases.  This section contains the appropriate interpretation of
+         the MIB for hosts.  It is likely that later versions of the MIB
+         will include more entries for host management.
+
+         A managed host must implement the following groups of MIB
+         object definitions: System, Interfaces, Address Translation,
+         IP, ICMP, TCP, and UDP.
+
+         The following specific interpretations apply to hosts:
+
+         o    ipInHdrErrors
+
+              Note that the error "time-to-live exceeded" can occur in a
+              host only when it is forwarding a source-routed datagram.
+
+
+
+Internet Engineering Task Force                                [Page 90]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+         o    ipOutNoRoutes
+
+              This object counts datagrams discarded because no route
+              can be found.  This may happen in a host if all the
+              default gateways in the host's configuration are down.
+
+         o    ipFragOKs, ipFragFails, ipFragCreates
+
+              A host that does not implement intentional fragmentation
+              (see "Fragmentation" section of [INTRO:1]) MUST return the
+              value zero for these three objects.
+
+         o    icmpOutRedirects
+
+              For a host, this object MUST always be zero, since hosts
+              do not send Redirects.
+
+         o    icmpOutAddrMaskReps
+
+              For a host, this object MUST always be zero, unless the
+              host is an authoritative source of address mask
+              information.
+
+         o    ipAddrTable
+
+              For a host, the "IP Address Table" object is effectively a
+              table of logical interfaces.
+
+         o    ipRoutingTable
+
+              For a host, the "IP Routing Table" object is effectively a
+              combination of the host's Routing Cache and the static
+              route table described in "Routing Outbound Datagrams"
+              section of [INTRO:1].
+
+              Within each ipRouteEntry, ipRouteMetric1...4 normally will
+              have no meaning for a host and SHOULD always be -1, while
+              ipRouteType will normally have the value "remote".
+
+              If destinations on the connected network do not appear in
+              the Route Cache (see "Routing Outbound Datagrams section
+              of [INTRO:1]), there will be no entries with ipRouteType
+              of "direct".
+
+
+         DISCUSSION:
+              The current MIB does not include Type-of-Service in an
+              ipRouteEntry, but a future revision is expected to make
+
+
+
+Internet Engineering Task Force                                [Page 91]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+              this addition.
+
+              We also expect the MIB to be expanded to allow the remote
+              management of applications (e.g., the ability to partially
+              reconfigure mail systems).  Network service applications
+              such as mail systems should therefore be written with the
+              "hooks" for remote management.
+
+      6.3.3  MANAGEMENT REQUIREMENTS SUMMARY
+
+                                               |           | | | |S| |
+                                               |           | | | |H| |F
+                                               |           | | | |O|M|o
+                                               |           | |S| |U|U|o
+                                               |           | |H| |L|S|t
+                                               |           |M|O| |D|T|n
+                                               |           |U|U|M| | |o
+                                               |           |S|L|A|N|N|t
+                                               |           |T|D|Y|O|O|t
+FEATURE                                        |SECTION    | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+Support SNMP or CMOT agent                     |6.3.1      | |x| | | |
+Implement specified objects in standard MIB    |6.3.1      | |x| | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 92]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+7.  REFERENCES
+
+   This section lists the primary references with which every
+   implementer must be thoroughly familiar.  It also lists some
+   secondary references that are suggested additional reading.
+
+   INTRODUCTORY REFERENCES:
+
+
+   [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
+        IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
+        October 1989.
+
+   [INTRO:2]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
+        (three volumes), SRI International, December 1985.
+
+   [INTRO:3]  "Official Internet Protocols," J. Reynolds and J. Postel,
+        RFC-1011, May 1987.
+
+        This document is republished periodically with new RFC numbers;
+        the latest version must be used.
+
+   [INTRO:4]  "Protocol Document Order Information," O. Jacobsen and J.
+        Postel, RFC-980, March 1986.
+
+   [INTRO:5]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
+        May 1987.
+
+        This document is republished periodically with new RFC numbers;
+        the latest version must be used.
+
+
+   TELNET REFERENCES:
+
+
+   [TELNET:1]  "Telnet Protocol Specification," J. Postel and J.
+        Reynolds, RFC-854, May 1983.
+
+   [TELNET:2]  "Telnet Option Specification," J. Postel and J. Reynolds,
+        RFC-855, May 1983.
+
+   [TELNET:3]  "Telnet Binary Transmission," J. Postel and J. Reynolds,
+        RFC-856, May 1983.
+
+   [TELNET:4]  "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
+        May 1983.
+
+   [TELNET:5]  "Telnet Suppress Go Ahead Option," J. Postel and J.
+
+
+
+Internet Engineering Task Force                                [Page 93]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+        Reynolds, RFC-858, May 1983.
+
+   [TELNET:6]  "Telnet Status Option," J. Postel and J. Reynolds, RFC-
+        859, May 1983.
+
+   [TELNET:7]  "Telnet Timing Mark Option," J. Postel and J. Reynolds,
+        RFC-860, May 1983.
+
+   [TELNET:8]  "Telnet Extended Options List," J. Postel and J.
+        Reynolds, RFC-861, May 1983.
+
+   [TELNET:9]  "Telnet End-Of-Record Option," J. Postel, RFC-855,
+        December 1983.
+
+   [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
+        February 1989.
+
+        This document supercedes RFC-930.
+
+   [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
+        October 1988.
+
+   [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
+        1989.
+
+   [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
+        December 1988.
+
+   [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
+        1080, November 1988.
+
+
+   SECONDARY TELNET REFERENCES:
+
+
+   [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
+        Defense, May 1984.
+
+        This document is intended to describe the same protocol as RFC-
+        854.  In case of conflict, RFC-854 takes precedence, and the
+        present document takes precedence over both.
+
+   [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
+
+   [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
+        1977.
+
+   [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
+
+
+
+Internet Engineering Task Force                                [Page 94]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
+        Implementation," A. Yasuda and T. Thompson, RFC-1043, February
+        1988.
+
+
+   FTP REFERENCES:
+
+
+   [FTP:1]  "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
+        959, October 1985.
+
+   [FTP:2]  "Document File Format Standards," J. Postel, RFC-678,
+        December 1974.
+
+   [FTP:3]  "File Transfer Protocol," MIL-STD-1780, U.S. Department of
+        Defense, May 1984.
+
+        This document is based on an earlier version of the FTP
+        specification (RFC-765) and is obsolete.
+
+
+   TFTP REFERENCES:
+
+
+   [TFTP:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
+        1981.
+
+
+   MAIL REFERENCES:
+
+
+   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
+        1982.
+
+   [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
+        D. Crocker, RFC-822, August 1982.
+
+        This document obsoleted an earlier specification, RFC-733.
+
+   [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
+        974, January 1986.
+
+        This RFC describes the use of MX records, a mandatory extension
+        to the mail delivery process.
+
+   [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
+        February 1988.
+
+
+
+
+Internet Engineering Task Force                                [Page 95]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [SMTP:5a]  "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
+        June 1986.
+
+   [SMTP:5b]  "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
+
+        The two preceding RFC's define a proposed standard for
+        gatewaying mail between the Internet and the X.400 environments.
+
+   [SMTP:6]  "Simple Mail Transfer Protocol,"  MIL-STD-1781, U.S.
+        Department of Defense, May 1984.
+
+        This specification is intended to describe the same protocol as
+        does RFC-821.  However, MIL-STD-1781 is incomplete; in
+        particular, it does not include MX records [SMTP:3].
+
+   [SMTP:7]  "A Content-Type Field for Internet Messages," M. Sirbu,
+        RFC-1049, March 1988.
+
+
+   DOMAIN NAME SYSTEM REFERENCES:
+
+
+   [DNS:1]  "Domain Names - Concepts and Facilities," P. Mockapetris,
+        RFC-1034, November 1987.
+
+        This document and the following one obsolete RFC-882, RFC-883,
+        and RFC-973.
+
+   [DNS:2]  "Domain Names - Implementation and Specification," RFC-1035,
+        P. Mockapetris, November 1987.
+
+
+   [DNS:3]  "Mail Routing and the Domain System," C. Partridge, RFC-974,
+        January 1986.
+
+
+   [DNS:4]  "DoD Internet Host Table Specification," K. Harrenstein,
+        RFC-952, M. Stahl, E. Feinler, October 1985.
+
+        SECONDARY DNS REFERENCES:
+
+
+   [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
+        RFC-953, October 1985.
+
+   [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
+        1987.
+
+
+
+
+Internet Engineering Task Force                                [Page 96]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [DNS:7]  "Domain Administrators Operations Guide," M. Lottor, RFC-
+        1033, November 1987.
+
+   [DNS:8]  "The Domain Name System Handbook," Vol. 4 of Internet
+        Protocol Handbook, NIC 50007, SRI Network Information Center,
+        August 1989.
+
+
+   SYSTEM INITIALIZATION REFERENCES:
+
+
+   [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
+        1984.
+
+   [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
+        951, September 1985.
+
+   [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
+        1084, December 1988.
+
+        Note: this RFC revised and obsoleted RFC-1048.
+
+   [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
+        Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
+
+
+   MANAGEMENT REFERENCES:
+
+
+   [MGT:1]  "IAB Recommendations for the Development of Internet Network
+        Management Standards," V. Cerf, RFC-1052, April 1988.
+
+   [MGT:2]  "Structure and Identification of Management Information for
+        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
+        August 1988.
+
+   [MGT:3]  "Management Information Base for Network Management of
+        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
+        August 1988.
+
+   [MGT:4]  "A Simple Network Management Protocol," J. Case, M. Fedor,
+        M. Schoffstall, and C. Davin, RFC-1098, April 1989.
+
+   [MGT:5]  "The Common Management Information Services and Protocol
+        over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
+
+   [MGT:6]  "Report of the Second Ad Hoc Network Management Review
+        Group," V. Cerf, RFC-1109, August 1989.
+
+
+
+Internet Engineering Task Force                                [Page 97]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+Security Considerations
+
+   There are many security issues in the application and support
+   programs of host software, but a full discussion is beyond the scope
+   of this RFC.  Security-related issues are mentioned in sections
+   concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
+   EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
+   SMTP DATA command (Section 5.2.8).
+
+Author's Address
+
+   Robert Braden
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695
+
+   Phone: (213) 822 1511
+
+   EMail: Braden@ISI.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 98]
+
diff --git a/RFC/rfc1176.txt b/RFC/rfc1176.txt
new file mode 100644
index 00000000..1ea72a11
--- /dev/null
+++ b/RFC/rfc1176.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 1176                                    Washington
+Obsoletes: RFC 1064                                          August 1990
+
+
+              INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2
+
+
+Status of this Memo
+
+   This RFC suggests a method for personal computers and workstations to
+   dynamically access mail from a mailbox server ("repository").  It
+   obosoletes RFC 1064.  This RFC specifies an Experimental Protocol for
+   the Internet community.  Discussion and suggestions for improvement
+   are requested.  Please refer to the current edition of the "IAB
+   Official Protocol Standards" for the standardization state and status
+   of this protocol.  Distribution of this memo is unlimited.
+
+Introduction
+
+   The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2)
+   is to allow a workstation, personal computer, or similar small
+   machine to access electronic mail from a mailbox server.  Since the
+   distinction between personal computers and workstations is blurring
+   over time, it is desirable to have a single solution that addresses
+   the need in a general fashion.  IMAP2 is the "glue" of a distributed
+   electronic mail system consisting of a family of client and server
+   implementations on a wide variety of platforms, from small single-
+   tasking personal computing engines to complex multi-user timesharing
+   systems.
+
+   Although different in many ways from the Post Office Protocols (POP2
+   and POP3, hereafter referred to collectively as "POP") described in
+   RFC 937 and RFC 1081, IMAP2 may be thought of as a functional
+   superset of these.  RFC 937 was used as a model for this RFC.  There
+   was a cognizant reason for this; POP deals with a similar problem,
+   albeit with a less comprehensive solution, and it was desirable to
+   offer a basis for comparison.
+
+   Like POP, IMAP2 specifies a means of accessing stored mail and not of
+   posting mail; this function is handled by a mail transfer protocol
+   such as SMTP (RFC 821).
+
+   This protocol assumes a reliable data stream such as provided by TCP
+   or any similar protocol.  When TCP is used, the IMAP2 server listens
+   on port 143.
+
+
+
+
+
+Crispin                                                         [Page 1]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+System Model and Philosophy
+
+   Electronic mail is a primary means of communication for the widely
+   spread Internet community.  The advent of distributed personal
+   computers and workstations has forced a significant rethinking of the
+   mechanisms employed to manage electronic mail.  With mainframes, each
+   user tends to receive and process mail at the computer he uses most
+   of the time, his "primary host".  The first inclination of many users
+   when an independent workstation is placed in front of them is to
+   begin receiving mail at the workstation, and many vendors have
+   implemented facilities to do this.  However, this approach has
+   several disadvantages:
+
+      (1) Personal computers and many workstations have a software
+      design that gives full control of all aspects of the system to the
+      user at the console.  As a result, background tasks such as
+      receiving mail may not run for long periods of time; either
+      because the user is asking to use all the machine's resources, or
+      because the user has (perhaps accidentally) manipulated the
+      environment in such a way that it prevents mail reception.  In
+      many personal computers, the operating system is single-tasking
+      and this is the only mode of operation.  Any of these conditions
+      could lead to repeated failed delivery attempts by outside agents.
+
+      (2) The hardware failure of a single machine can keep its user
+      "off the air" for a considerable time, since repair of individual
+      units may be delayed.  Given the growing number of personal
+      computers and workstations spread throughout office environments,
+      quick repair of such systems is not assured.  On the other hand, a
+      central mainframe is generally repaired soon after failure.
+
+      (3) Personal computers and workstations are often not backed up
+      with as much diligence as a central mainframe, if at all.
+
+      (4) It is more difficult to keep track of mailing addresses when
+      each person is associated with a distinct machine.  Consider the
+      difficulty in keeping track of many postal addresses or phone
+      numbers, particularly if there was no single address or phone
+      number for an organization through which you could reach any
+      person in that organization.  Traditionally, electronic mail on
+      the ARPANET involved remembering a name and one of several "hosts"
+      (machines) whose name reflected the organization in which the
+      individual worked.  This was suitable at a time when most
+      organizations had only one central host.  It is less satisfactory
+      today unless the concept of a host is changed to refer to an
+      organizational entity and not a particular machine.
+
+      (5) It is difficult to keep a multitude of heterogeneous machines
+
+
+
+Crispin                                                         [Page 2]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+      working properly with complex mailing protocols, making it
+      difficult to move forward as progress is made in electronic
+      communication and as new standards emerge.  Each system has to
+      worry about receiving incoming mail, routing and delivering
+      outgoing mail, formatting, storing, and providing for the
+      stability of mailboxes over a variety of possible filing and
+      mailing protocols.
+
+   Consequently, while a personal computer or workstation may be viewed
+   as an Internet host in the sense that it implements TCP/IP, it should
+   not be viewed as the entity that contains the user's mailbox.
+   Instead, a mail server machine ("server", sometimes called a
+   "repository") should hold the mailbox, and the personal computer or
+   workstation (hereafter referred to as a "client") should access the
+   mailbox via mail transactions.
+
+   Because the mail server machine is isolated from direct user
+   manipulation, it should achieve high software reliability easily,
+   and, as a shared resource, it should also achieve high hardware
+   reliability, perhaps through redundancy.  The mail server may be
+   accessed from arbitrary locations, allowing users to read mail across
+   campus, town, or country using commonly available clients.
+   Furthermore, the same user may access his mailbox from different
+   clients at different times, and multiple users may access the same
+   mailbox simultaneously.
+
+   The mail server acts an an interface among users, data storage, and
+   other mailers.  A mail access protocol retrieves messages, accesss
+   and changes properties of messages, and otherwise manages mailboxes.
+   This differs from some approaches (e.g., Unix mail via NFS) in that
+   the mail access protocol is used for all message manipulations,
+   isolating the user and the client from all knowledge of how the data
+   storage is used.  This means that the mail server can use the data
+   storage in whatever way is most efficient to organize the mail in
+   that particular environment, without having to worry about storage
+   representation compatibility across different machines.
+
+   A mail access protocol further differs in that it transmits
+   information only on demand.  A well-designed mail access protocol
+   requires considerably less network traffic than Unix mail via NFS,
+   particularly when the mail file is large.  The result is that a mail
+   access protocol can scale well to situations of large mailboxes or
+   networks with high latency or low speed.
+
+   In defining a mail access protocol, it is important to keep in mind
+   that the client and server form a macrosystem, in which it should be
+   possible to exploit the strong points of both while compensating for
+   each other's weaknesses.  Furthermore, it is desirable to allow for a
+
+
+
+Crispin                                                         [Page 3]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   growth path beyond the hoary text-only RFC 822 protocol, specifically
+   in the area of attachments and multi-media mail, to ease the eventual
+   transition to ISO solutions.
+
+   Unlike POP, IMAP2 has extensive features for remote searching and
+   parsing of messages on the server.  A free text search (optionally
+   with other searching) can be made in the entire mailbox by the server
+   and the results made available to the client without the client
+   having to transfer the entire mailbox and searching itself.  Since
+   remote parsing of a message into a structured (and standard format)
+   "envelope" is available, a client can display envelope information
+   and implement commands such as REPLY without having any understanding
+   of how to parse RFC 822, etc. headers.  The effect of this is
+   twofold: it further improves the ability to scale well in instances
+   where network traffic must be reduced, and it reduces the complexity
+   of the client program.
+
+   Additionally, IMAP2 offers several facilities for managing individual
+   message state and the mailbox as a whole beyond the simple "delete
+   message" functionality of POP.  Another benefit of IMAP2 is the use
+   of tagged responses to reduce the possibility of synchronization
+   errors and the concept of state on the client (a "local cache") that
+   the server may update without explicit request by the client.  These
+   concepts and how they are used are explained under "Implementation
+   Discussion" below.
+
+   In spite of this functional richness, IMAP2 is a small protocol.
+   Although servers should implement the full set of IMAP2 functions, a
+   simple client can be written that uses IMAP2 in much the way as a POP
+   client.
+
+   A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL
+   (RFC 1056).  IMAP2 differs from DMSP more fundamentally, reflecting a
+   differing architecture from PCMAIL.  PCMAIL is either an online
+   ("interactive mode"), or offline ("batch mode") system with long-term
+   shared state.  Some POP based systems are also offline; in such
+   systems, since there is no long-term shared state POP is little more
+   than a download mechanism of the "mail file" to the client.  IMAP2-
+   based software is primarily an online system in which real-time and
+   simultaneous mail access were considered important.
+
+   In PCMAIL, there is a long-term client/server relationship in which
+   some mailbox state is preserved on the client.  There is a
+   registration of clients used by a particular user, and the client
+   keeps a set of "descriptors" for each message that summarize the
+   message.  The server and client synchronize their states when the
+   DMSP connection starts up, and, if a client has not accessed the
+   server for a while, the client does a complete reset (reload) of its
+
+
+
+Crispin                                                         [Page 4]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   state from the server.
+
+   In IMAP2-based software, the client/server relationship lasts only
+   for the duration of the TCP connection.  All mailbox state is
+   maintained on the server.  There is no registration of clients.  The
+   function of a descriptor is handled by a structured representation of
+   the message "envelope" as noted above.  There is no client/server
+   synchronization since the client does not remember state between
+   IMAP2 connections.  This is not a problem since in general the client
+   never needs the entire state of the mailbox in a single session,
+   therefore there isn't much overhead in fetching the state information
+   that is needed as it is needed.
+
+   There are also some functional differences between IMAP2 and DMSP.
+   DMSP has functions for sending messages, printing messages, listing
+   mailboxes, and changing passwords; these are done outside IMAP2.
+   DMSP has 16 binary flags of which 8 are defined by the system.  IMAP2
+   has flag names; there are currently 5 defined system flag names and a
+   facility for some number (30 in the current implementations) of user
+   flag names.  IMAP2 has a sophisticated message search facility in the
+   server to identify interesting messages based on dates, addresses,
+   flag status, or textual contents without compelling the client to
+   fetch this data for every message.
+
+   It was felt that maintaining state on the client is advantageous only
+   in those cases where the client is only used by a single user, or if
+   there is some means on the client to restrict access to another
+   user's data.  It can be a serious disadvantage in an environment in
+   which multiple users routinely use the same client, the same user
+   routinely uses different clients, and where there are no access
+   restrictions on the client.  It was also observed that most user mail
+   access is to a small set of "interesting" messages, which were either
+   new mail or mail based on some user-selected criteria.  Consequently,
+   IMAP2 was designed to easily identify those "interesting" messages so
+   that the client could fetch the state of those messages and not those
+   that were not "interesting".
+
+The Protocol
+
+   The IMAP2 protocol consists of a sequence of client commands and
+   server responses, with server data interspersed between the
+   responses.  Unlike most Internet protocols, commands and responses
+   are tagged.  That is, a command begins with a unique identifier
+   (typically a short alphanumeric sequence such as a Lisp "gensym"
+   function would generate e.g., A0001, A0002, etc.), called a tag.  The
+   response to this command is given the same tag from the server.
+   Additionally, the server may send an arbitrary amount of "unsolicited
+   data", which is identified by the special reserved tag of "*".  There
+
+
+
+Crispin                                                         [Page 5]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   is another special reserved tag, "+", discussed below.
+
+   The server must be listening for a connection.  When a connection is
+   opened the server sends an unsolicited OK response as a greeting
+   message and then waits for commands.
+
+   The client opens a connection and waits for the greeting.  The client
+   must not send any commands until it has received the greeting from
+   the server.
+
+   Once the greeting has been received, the client may begin sending
+   commands and is not under any obligation to wait for a server
+   response to this command before sending another command, within the
+   constraints of TCP flow control.  When commands are received the
+   server acts on them and responds with command responses, often
+   interspersed with data.  The effect of a command can not be
+   considered complete until a command response with a tag matching the
+   command is received from the server.
+
+   Although all known IMAP2 servers at the time of this writing process
+   commands to completion before processing the next command, it is not
+   required that a server do so.  However, many commands can affect the
+   results of other commands, creating processing-order dependencies
+   (or, for SEARCH and FIND, ambiguities about which data is associated
+   with which command).  All implementations that operate in a non-
+   lockstep fashion must recognize such dependencies and defer or
+   synchronize execution as necessary.  In general, such multi-
+   processing is limited to consecutive FETCH commands.
+
+   Generally, the first command from the client is a LOGIN command with
+   user name and password arguments to establish identity and access
+   authorization, unless this has already been accomplished through
+   other means, e.g. Kerberos.  Until identity and access authorization
+   have been established, no operations other than LOGIN or LOGOUT are
+   permitted.
+
+   Once identity and authorization have been established, the client
+   must send a SELECT command to access the desired mailbox; no mailbox
+   is selected by default.  SELECT's argument is implementation-
+   dependent; however the word "INBOX" must be implemented to mean the
+   primary or default mailbox for this user, independent of any other
+   server semantics.  On a successful SELECT, the server will send a
+   list of valid flags, number of messages, and number of messages
+   arrived since last access for this mailbox as unsolicited data,
+   followed by an OK response.  The client may terminate access to this
+   mailbox and access a different one with another SELECT command.
+
+   The client reads mailbox information with FETCH commands.  The actual
+
+
+
+Crispin                                                         [Page 6]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   data is transmitted via the unsolicited data mechanism (that is,
+   FETCH should be viewed as instructing the server to include the
+   desired data along with any other data it wishes to transmit to the
+   client).  There are three major categories of data that may be
+   fetched.
+
+   The first category is data that is associated with a message as an
+   entity in the mailbox.  There are now three such items of data: the
+   "internal date", the "RFC 822 size", and the "flags".  The internal
+   date is the date and time that the message was placed in the mailbox.
+   The RFC 822 size is subject to deletion in the future; it is the size
+   in bytes of the message, expressed as an RFC 822 text string.
+   Current clients only use it as part of a status display line.  The
+   flags are a list of status flags associated with the message (see
+   below).  All the first category data can be fetched by using the
+   macro-fetch word "FAST"; that is, "FAST" expands to "(FLAGS
+   INTERNALDATE RFC822.SIZE)".
+
+   The second category is that data that describes the composition and
+   delivery information of a message; that is, information such as the
+   message sender, recipient lists, message-ID, subject, etc.  This is
+   the information that is stored in the message header in RFC 822
+   format message and is traditionally called the "envelope".  [Note:
+   this should not be confused with the SMTP (RFC 821) envelope, which
+   is strictly limited to delivery information.]  IMAP2 defines a
+   structured and unambiguous representation for the envelope that is
+   particularly suited for Lisp-based parsers.  A client can use the
+   envelope for operations such as replying and not worry about RFC 822
+   at all.  Envelopes are discussed in more detail below.  The first two
+   categories of data can be fetched together by using the macro-fetch
+   word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE
+   RFC822.SIZE ENVELOPE)".
+
+   The third category is that data that is intended for direct human
+   viewing.  The present RFC 822 based IMAP2 defines three such items:
+   RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two
+   former appended together in a single text string).  RFC822.HEADER is
+   the "raw", unprocessed RFC 822 format header of the message.
+   Fetching "RFC822" is equivalent to fetching the RFC 822
+   representation of the message as stored on the mailbox without any
+   filtering or processing.
+
+   An intelligent client will "FETCH ALL" for some (or all) of the
+   messages in the mailbox for use as a presentation menu, and when the
+   user wishes to read a particular message will "FETCH RFC822.TEXT" to
+   get the message body.  A more primitive client could, of course,
+   simply "FETCH RFC822" a`la POP-type functionality.
+
+
+
+
+Crispin                                                         [Page 7]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   The client can alter certain data (currently only the flags) by a
+   STORE command.  As an example, a message is deleted from a mailbox by
+   a STORE command that includes the \DELETED flag as a flag being set.
+
+   Other client operations include copying a message to another mailbox
+   (COPY command), permanently removing deleted messages (EXPUNGE
+   command), checking for new messages (CHECK command), and searching
+   for messages that match certain criteria (SEARCH command).
+
+   The client terminates the session with the LOGOUT command.  The
+   server returns a "BYE" followed by an "OK".
+
+   A Typical Scenario
+
+           Client                          Server
+           ------                          ------
+                                       {Wait for Connection}
+       {Open Connection}        -->
+                                   <-- * OK IMAP2 Server Ready
+                                       {Wait for command}
+       A001 LOGIN Fred Secret   -->
+                                   <-- A001 OK User Fred logged in
+                                       {Wait for command}
+       A002 SELECT INBOX        -->
+                                   <-- * FLAGS (Meeting Notice \Answered
+                                                \Flagged \Deleted \Seen)
+                                   <-- * 19 EXISTS
+                                   <-- * 2 RECENT
+                                   <-- A0002 OK Select complete
+                                       {Wait for command}
+       A003 FETCH 1:19 ALL      -->
+                                   <-- * 1 Fetch (......)
+                                           ...
+                                   <-- * 18 Fetch (......)
+                                   <-- * 19 Fetch (......)
+                                   <-- A003 OK Fetch complete
+                                       {Wait for command}
+       A004 FETCH 8 RFC822.TEXT -->
+                                   <-- * 8 Fetch (RFC822.TEXT {893}
+                                           ...893 characters of text...
+                                   <-- )
+                                   <-- A004 OK Fetch complete
+                                       {Wait for command}
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 8]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+       A005 STORE 8 +Flags \Deleted -->
+                                   <-- * 8 Store (Flags (\Deleted
+                                                  \Seen))
+                                   <-- A005 OK Store complete
+                                       {Wait for command}
+       A006 EXPUNGE             -->
+                                   <-- * 19 EXISTS
+                                   <-- * 8 EXPUNGE
+                                   <-- * 18 EXISTS
+                                   <-- A006 Expunge complete
+                                       {Wait for command}
+       A007 LOGOUT              -->
+                                   <-- * BYE IMAP2 server quitting
+                                   <-- A007 OK Logout complete
+       {Close Connection}       --><-- {Close connection}
+                                       {Go back to start}
+Conventions
+
+   The following terms are used in a meta-sense in the syntax
+   specification below:
+
+      An ASCII-STRING is a sequence of arbitrary ASCII characters.
+
+      An ATOM is a sequence of ASCII characters delimited by SP or CRLF.
+
+      A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
+      or "\".
+
+      A CRLF is an ASCII carriage-return character followed immediately
+      by an ASCII linefeed character.
+
+      A NUMBER is a sequence of the ASCII characters that represent
+      decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or
+      ":".
+
+      A SP is the ASCII space character.
+
+      A TEXT_LINE is a human-readable sequence of ASCII characters up to
+      but not including a terminating CRLF.
+
+   A common field in the IMAP2 protocol is a STRING, which may be an
+   ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes),
+   or a LITERAL.  A literal consists of an open brace ("{"), a number, a
+   close brace ("}"), a CRLF, and then an ASCII-STRING of n characters,
+   where n is the value of the number inside the brace.  In general, a
+   string should be represented as an ATOM or QUOTED-STRING if at all
+   possible.  The semantics for QUOTED-STRING or LITERAL are checked
+   before those for ATOM; therefore an ATOM used in a STRING may only
+
+
+
+Crispin                                                         [Page 9]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   contain CHARACTERs.  Literals are most often sent from the server to
+   the client; in the rare case of a client to server literal there is a
+   special consideration (see the "+ text" response below).
+
+   Another important field is the SEQUENCE, which identifies a set of
+   messages by consecutive numbers from 1 to n where n is the number of
+   messages in the mailbox.  A sequence may consist of a single number,
+   a pair of numbers delimited by colon (equivalent to all numbers
+   between those two numbers), or a list of single numbers or number
+   pairs.  For example, the sequence 2,4:7,9,12:15 is equivalent to
+   2,4,5,6,7,9,12,13,14,15 and identifies all those messages.
+
+Definitions of Commands and Responses
+
+     Summary of Commands and Responses
+
+       Commands                            ||      Responses
+       --------                            ||      -------
+       tag NOOP                            ||      tag OK text
+       tag LOGIN user password             ||      tag NO text
+       tag LOGOUT                          ||      tag BAD text
+       tag SELECT mailbox                  ||      * number message_data
+       tag BBOARD bulletin_board           ||      * FLAGS flag_list
+       tag FIND MAILBOXES pattern          ||      * SEARCH sequence
+       tag FIND BBOARDS pattern            ||      * BBOARD string
+       tag CHECK                           ||      * MAILBOX string
+       tag EXPUNGE                         ||      * BYE text
+       tag COPY sequence mailbox           ||      * OK text
+       tag FETCH sequence data             ||      * NO text
+       tag STORE sequence data value       ||      * BAD text
+       tag SEARCH search_program           ||      + text
+
+Commands
+
+   tag NOOP
+
+      The NOOP command returns an OK to the client.  By itself, it does
+      nothing, but certain things may happen as side effects.  For
+      example, server implementations that implicitly check the mailbox
+      for new mail may do so as a result of this command.  The primary
+      use of this command is to for the client to see if the server is
+      still alive (and notify the server that the client is still alive,
+      for those servers that have inactivity autologout timers).
+
+   tag LOGIN user password
+
+      The LOGIN command identifies the user to the server and carries
+      the password authenticating this user.  This information is used
+
+
+
+Crispin                                                        [Page 10]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+      by the server to control access to the mailboxes.
+
+      EXAMPLE:  A001 LOGIN SMITH SESAME
+      logs in as user SMITH with password SESAME.
+
+   tag LOGOUT
+
+      The LOGOUT command informs the server that the client is done with
+      the session.  The server should send an unsolicited BYE response
+      before the (tagged) OK response, and then close the network
+      connection.
+
+   tag SELECT mailbox
+
+      The SELECT command selects a particular mailbox.  The server must
+      check that the user is permitted read access to this mailbox.
+      Before returning an OK to the client, the server must send the
+      following unsolicited data to the client:
+         FLAGS        mailbox's defined flags
+         <n> EXISTS   the number of messages in the mailbox
+         <n> RECENT   the number of new messages in the mailbox
+      in order to define the initial state of the mailbox at the client.
+
+      Multiple SELECT commands are permitted in a session, in which case
+      the previous mailbox is automatically deselected when a new SELECT
+      is made.
+
+      The default mailbox for the SELECT command is INBOX, which is a
+      special name reserved to mean "the primary mailbox for this user
+      on this server".  The format of other mailbox names is operating
+      system dependent (as of this writing, it reflects the filename
+      path of the mailbox file on the current servers).
+
+      It is customary, although not required, for the text of an OK
+      response to the SELECT command to begin with either "[READ-ONLY]"
+      or "[READ-WRITE]" to show the mailbox's access status.
+
+      EXAMPLE: A002 SELECT INBOX
+      selects the default mailbox.
+
+   tag BBOARD bulletin_board
+
+      The BBOARD command is equivalent to SELECT, and returns the same
+      output.  However, it differs from SELECT in that its argument is a
+      shared mailbox (bulletin board) name instead of an ordinary
+      mailbox.  The format of a bulletin name is implementation
+      specific, although it is strongly encouraged to use something that
+      resembles a name in a generic sense and not a file or mailbox name
+
+
+
+Crispin                                                        [Page 11]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+      on the particular system.  There is no requirement that a bulletin
+      board name be a mailbox name or a file name (in particular, Unix
+      netnews has a completely different namespace from mailbox or file
+      names).
+
+      Support for BBOARD is optional.
+
+   tag FIND MAILBOXES pattern
+
+      The FIND MAILBOXES command accepts as an argument a pattern
+      (including wildcards) that specifies some set of mailbox names
+      that are usable by the SELECT command.  The format of mailboxes is
+      implementation dependent.  The special mailbox name INBOX is not
+      included in the output.
+
+      Two wildcard characters are defined; "*" specifies any number
+      (including zero) characters may match at this position and "%"
+      specifies a single character may match at this position.  For
+      example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR,
+      whereas FOO%BAR will match only FOO.BAR.  "*" will match all
+      mailboxes.
+
+      The FIND MAILBOXES command will return some set of unsolicited
+      MAILBOX replies that have as their value a single mailbox name.
+
+      EXAMPLE:  A002 FIND MAILBOXES *
+                * MAILBOX FOOBAR
+                * MAILBOX GENERAL
+                A002 FIND completed
+
+      Although the use of explicit file or path names for mailboxes is
+      discouraged by this standard, it may be unavoidable.  It is
+      important that the value returned in the MAILBOX unsolicited reply
+      be usable in the SELECT command without remembering any path
+      specification that may have been used in the FIND MAILBOXES
+      pattern.
+
+      Support for FIND MAILBOXES is optional.  If a client's attempt
+      returns BAD as a response then the client can make no assumptions
+      about what mailboxes exist on the server other than INBOX.
+
+   tag FIND BBOARDS pattern
+
+      The FIND BBOARDS command accepts as an argument a pattern that
+      specifies some set of bulletin board names that are usable by the
+      BBOARD command.  Wildcards are permitted as in FIND MAILBOXES.
+
+      The FIND BBOARDS command will return some set of unsolicited
+
+
+
+Crispin                                                        [Page 12]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+      BBOARD replies that have as their value a single bulletin board
+      name.
+
+      EXAMPLE:  A002 FIND BBOARDS *
+                * BBOARD FOOBAR
+                * BBOARD GENERAL
+                A002 FIND completed
+
+      Support for FIND BBOARDS is optional.  If a client's attempt
+      returns BAD as a response then the client can make no assumptions
+      about what bulletin boards exist on the server, or that they exist
+      at all.
+
+   tag CHECK
+
+      The CHECK command forces a check for new messages and a rescan of
+      the mailbox for internal change for those implementations that
+      allow multiple simultaneous read/write access to the same mailbox.
+      It is recommend that periodic implicit checks for new mail be done
+      by servers as well.  The server should send unsolicited EXISTS and
+      RECENT responses with the current status before returning an OK to
+      the client.
+
+   tag EXPUNGE
+
+      The EXPUNGE command permanently removes all messages with the
+      \DELETED flag set in its flags from the mailbox.  Before returning
+      an OK to the client, for each message that is removed, an
+      unsolicited EXPUNGE response is sent.  The message number for each
+      successive message in the mailbox is immediately decremented by 1;
+      this means that if the last 5 messages in a 9-message mail file
+      are expunged you will receive 5 unsolicited EXPUNGE responses for
+      message 5.  To ensure mailbox integrity and server/client
+      synchronization, it is recommended that the server do an implicit
+      check before commencing the expunge and again when the expunge is
+      completed.  Furthermore, if the server allows multiple
+      simultaneous access to the same mail file the server must lock the
+      mail file for exclusive access while an expunge is taking place.
+
+      EXPUNGE is not allowed if the user does not have write access to
+      this mailbox.
+
+   tag COPY sequence mailbox
+
+      The COPY command copies the specified message(s) to the specified
+      destination mailbox.  If the destination mailbox does not exist,
+      the server should create it.  Before returning an OK to the
+      client, the server should return an unsolicited <n> COPY response
+
+
+
+Crispin                                                        [Page 13]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+      for each message copied.  A copy should set the \SEEN flag for all
+      messages that were successfully copied (provided, of course, that
+      the user has write access to this mailbox).
+
+      EXAMPLE:  A003 COPY 2:4 MEETING
+      copies messages 2, 3, and 4 to mailbox "MEETING".
+
+      COPY is not allowed if the user does not have write access to the
+      destination mailbox.
+
+   tag FETCH sequence data
+
+      The FETCH command retrieves data associated with a message in the
+      mailbox.  The data items to be fetched may be either a single atom
+      or an S-expression list.  The currently defined data items that
+      can be fetched are:
+
+      ALL             Macro equivalent to:
+                      (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
+
+      ENVELOPE        The envelope of the message.  The envelope is
+                      computed by the server by parsing the RFC 822
+                      header into the component parts, defaulting
+                      various fields as necessary.
+
+      FAST            Macro equivalent to:
+                      (FLAGS INTERNALDATE RFC822.SIZE)
+
+      FLAGS           The flags that are set for this message.
+                      This may include the following system flags:
+
+                              \RECENT    Message arrived since the
+                                          previous time this mailbox
+                                          was read
+                              \SEEN      Message has been read
+                              \ANSWERED  Message has been answered
+                              \FLAGGED   Message is "flagged" for
+                                          urgent/special attention
+                              \DELETED   Message is "deleted" for
+                                          removal by later EXPUNGE
+
+      INTERNALDATE    The date and time the message was written to
+                      the mailbox.
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 14]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+      RFC822          The message in RFC 822 format.  The \SEEN
+                      flag is implicitly set; if this causes the
+                      flags to change they should be included as
+                      part of the fetch results.  This is the
+                      concatenation of RFC822.HEADER and RFC822.TEXT.
+
+      RFC822.HEADER   The "raw" RFC 822 format header of the message
+                      as stored on the server.
+
+      RFC822.SIZE     The number of characters in the message as
+                      expressed in RFC 822 format.
+
+      RFC822.TEXT     The text body of the message, omitting the
+                      RFC 822 header.  The \SEEN flag is implicitly
+                      set as with RFC822 above.
+
+      EXAMPLES:
+
+      A003 FETCH 2:4 ALL
+         fetches the flags, internal date, RFC 822 size, and envelope
+         for messages 2, 3, and 4.
+
+      A004 FETCH 3 RFC822
+         fetches the RFC 822 representation for message 3.
+
+      A005 FETCH 4 (FLAGS RFC822.HEADER)
+         fetches the flags and RFC 822 format header for message 4.
+
+      Note: An attempt to FETCH already-transmitted data may have no
+      result.  See the Implementation Discussion below.
+
+   tag STORE sequence data value
+
+      The STORE command alters data associated with a message in the
+      mailbox.  The currently defined data items that can be stored are:
+
+         FLAGS           Replace the flags for the message with the
+                         argument (in flag list format).
+
+         +FLAGS          Add the flags in the argument to the
+                         message's flag list.
+
+         -FLAGS          Remove the flags in the argument from the
+                         message's flag list.
+
+      STORE is not allowed if the user does not have write access to
+      this mailbox.
+
+
+
+
+Crispin                                                        [Page 15]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+      EXAMPLE:  A003 STORE 2:4 +FLAGS (\DELETED)
+      marks messages 2, 3, and 4 for deletion.
+
+   tag SEARCH search_criteria
+
+      The SEARCH command searches the mailbox for messages that match
+      the given set of criteria.  The unsolicited SEARCH <1#number>
+      response from the server is a list of messages that express the
+      intersection (AND function) of all the messages which match that
+      criteria.  For example,
+              A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
+      returns the message numbers for all deleted messages from Smith
+      that were placed in the mail file since October 1, 1987.
+
+      In all search criteria which use strings, a message matches the
+      criteria if the string is a case-independent substring of that
+      field.  The currently defined criteria are:
+
+      ALL             All messages in the mailbox; the default
+                      initial criterion for ANDing.
+
+      ANSWERED        Messages with the \ANSWERED flag set.
+
+      BCC string      Messages which contain the specified string
+                      in the envelope's BCC field.
+
+      BEFORE date     Messages whose internal date is earlier than
+                      the specified date.
+
+      BODY string     Messages which contain the specified string
+                      in the body of the message.
+
+      CC string       Messages which contain the specified string
+                      in the envelope's CC field.
+
+      DELETED         Messages with the \DELETED flag set.
+
+      FLAGGED         Messages with the \FLAGGED flag set.
+
+      FROM string     Messages which contain the specified string
+                      in the envelope's FROM field.
+
+      KEYWORD flag    Messages with the specified flag set.
+
+      NEW             Messages which have the \RECENT flag set but
+                      not the \SEEN flag.  This is functionally
+                      equivalent to "RECENT UNSEEN".
+
+
+
+
+Crispin                                                        [Page 16]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+      OLD             Messages which do not have the \RECENT flag
+                      set.
+
+      ON date         Messages whose internal date is the same as
+                      the specified date.
+
+      RECENT          Messages which have the \RECENT flag set.
+
+      SEEN            Messages which have the \SEEN flag set.
+
+      SINCE date      Messages whose internal date is later than
+                      the specified date.
+
+      SUBJECT string  Messages which contain the specified string
+                      in the envelope's SUBJECT field.
+
+      TEXT string     Messages which contain the specified string.
+
+      TO string       Messages which contain the specified string in
+                      the envelope's TO field.
+
+      UNANSWERED      Messages which do not have the \ANSWERED flag
+                      set.
+
+      UNDELETED       Messages which do not have the \DELETED flag
+                      set.
+
+      UNFLAGGED       Messages which do not have the \FLAGGED flag
+                      set.
+
+      UNKEYWORD flag  Messages which do not have the specified flag
+                      set.
+
+      UNSEEN          Messages which do not have the \SEEN flag set.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 17]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+Responses
+
+   tag OK text
+
+      This response identifies successful completion of the command with
+      that tag.  The text is a line of human-readable text that may be
+      useful in a protocol telemetry log for debugging purposes.
+
+   tag NO text
+
+      This response identifies unsuccessful completion of the command
+      with that tag.  The text is a line of human-readable text that
+      probably should be displayed to the user in an error report by the
+      client.
+
+   tag BAD text
+
+      This response identifies faulty protocol received from the client;
+      The text is a line of human-readable text that should be recorded
+      in any telemetry as part of a bug report to the maintainer of the
+      client.
+
+   * number message_data
+
+      This response occurs as a result of several different commands.
+      The message_data is one of the following:
+
+      EXISTS  The specified number of messages exists in the mailbox.
+
+      RECENT  The specified number of messages have arrived since the
+              previous time this mailbox was read.
+
+      EXPUNGE The specified message number has been permanently
+              removed from the mailbox, and the next message in the
+              mailbox (if any) becomes that message number.
+
+      STORE data
+              Obsolete and functionally equivalent to FETCH.
+
+      FETCH data
+              This is the principle means by which data about a
+              message is returned to the client.  The data is in a
+              Lisp-like S-expression property list form.  The current
+              properties are:
+
+         ENVELOPE     An S-expression format list that describes the
+                      envelope of a message.  The envelope is computed
+                      by the server by parsing the RFC 822 header into
+
+
+
+Crispin                                                        [Page 18]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+                      the component parts, defaulting various fields
+                      as necessary.
+
+                      The fields of the envelope are in the following
+                      order: date, subject, from, sender, reply-to, to,
+                      cc, bcc, in-reply-to, and message-id.  The date,
+                      subject, in-reply-to, and message-id fields are
+                      strings.  The from, sender, reply-to, to, cc,
+                      and bcc fields are lists of addresses.
+
+                      An address is an S-expression format list that
+                      describes an electronic mail address.  The fields
+                      of an address are in the following order:
+                      personal name, source-route (a.k.a. the
+                      at-domain-list in SMTP), mailbox name, and
+                      host name.
+
+                      Any field of an envelope or address that is
+                      not applicable is presented as the atom NIL.
+                      Note that the server must default the reply-to
+                      and sender fields from the from field; a client is
+                      not expected to know to do this.
+
+         FLAGS        An S-expression format list of flags that are set
+                      for this message.  This may include the following
+                      system flags:
+
+                      \RECENT       Message arrived since the
+                                     previous time this mailbox
+                                     was read
+                      \SEEN         Message has been read
+                      \ANSWERED     Message has been answered
+                      \FLAGGED      Message is "flagged" for
+                                     urgent/special attention
+                      \DELETED      Message is "deleted" for
+                                     removal by later EXPUNGE
+
+         INTERNALDATE  A string containing the date and time the
+                       message was written to the mailbox.
+
+         RFC822        A string expressing the message in RFC 822
+                       format.
+
+         RFC822.HEADER A string expressing the RFC 822 format
+                       header of the message
+
+         RFC822.SIZE   A number indicating the number of
+                       characters in the message as expressed
+
+
+
+Crispin                                                        [Page 19]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+                       in RFC 822 format.
+
+         RFC822.TEXT   A string expressing the text body of the
+                       message, omitting the RFC 822 header.
+
+   * FLAGS flag_list
+
+      This response occurs as a result of a SELECT command.  The flag
+      list are the list of flags (at a minimum, the system-defined
+      flags) that are applicable for this mailbox.  Flags other than the
+      system flags are a function of the server implementation.
+
+   * SEARCH number(s)
+
+      This response occurs as a result of a SEARCH command.  The
+      number(s) refer to those messages that match the search criteria.
+      Each number is delimited by a space, e.g., "SEARCH 2 3 6".
+
+   * BBOARD string
+
+      This response occurs as a result of a FIND BBOARDS command.  The
+      string is a bulletin board name that matches the pattern in the
+      command.
+
+   * MAILBOX string
+
+      This response occurs as a result of a FIND MAILBOXES command.  The
+      string is a mailbox name that matches the pattern in the command.
+
+   * BYE text
+
+      This response identifies that the server is about to close the
+      connection.  The text is a line of human-readable text that should
+      be displayed to the user in a status report by the client.  This
+      may be sent as part of a normal logout sequence, or as a panic
+      shutdown announcement by the server.  It is also used by some
+      servers as an announcement of an inactivity autologout.
+
+   * OK text
+
+      This response identifies normal operation on the server.  No
+      special action by the client is called for, however, the text
+      should be displayed to the user in some fashion.  This is
+      currently only used by servers at startup as a greeting message to
+      show they are ready to accept the first command.
+
+
+
+
+
+
+Crispin                                                        [Page 20]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   * NO text
+
+      This response identifies a warning from the server that does not
+      affect the overall results of any particular request.  The text is
+      a line of human-readable text that should be presented to the user
+      as a warning of improper operation.
+
+   * BAD text
+
+      This response identifies a serious error at the server; it may
+      also indicate faulty protocol from the client in which a tag could
+      not be parsed.  The text is a line of human-readable text that
+      should be presented to the user as a serious or possibly fatal
+      error.  It should also be recorded in any telemetry as part of a
+      bug report to the maintainer of the client and server.
+
+   + text
+
+      This response identifies that the server is ready to accept the
+      text of a literal from the client.  Normally, a command from the
+      client is a single text line.  If the server detects an error in
+      the command, it can simply discard the remainder of the line.  It
+      cannot do this for commands that contain literals, since a literal
+      can be an arbitrarily long amount of text, and the server may not
+      even be expecting a literal.  This mechanism is provided so the
+      client knows not to send a literal until the server expects it,
+      preserving client/server synchronization.
+
+      In practice, this condition is rarely encountered.  In the current
+      protocol, the only client command likely to contain a literal is
+      the LOGIN command.  Consider a server that validates the user
+      before checking the password.  If the password contains "funny"
+      characters and hence is sent as a literal, then if the user is
+      invalid an error would occur before the password is parsed.
+
+      No such synchronization protection is provided for literals sent
+      from the server to the client, for performance reasons.  Any
+      synchronization problems in this direction would be caused by a
+      bug in the client or server.
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 21]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+Sample IMAP2 session
+
+   The following is a transcript of an IMAP2 session.  Server output is
+   identified by "S:" and client output by "U:".  In cases where lines
+   are too long to fit within the boundaries of this document, the line
+   is continued on the next line.
+
+   S:   * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II Service
+         6.1(349) at Thu, 9 Jun 88 14:58:30 PDT
+   U:   a001 login crispin secret
+   S:   a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76
+   U:   a002 select inbox
+   S:   * FLAGS (Bugs SF Party Skating Meeting Flames Request AI Question
+         Note \XXXX \YYYY \Answered \Flagged \Deleted \Seen)
+   S:   * 16 EXISTS
+   S:   * 0 RECENT
+   S:   a002 OK Select complete
+   U:   a003 fetch 16 all
+   S:   * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT"
+         RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
+         "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
+         "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
+         "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
+         "SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH"
+         "SUMEX-AIM.Stanford.EDU")) NIL NIL NIL
+         "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
+   S:   a003 OK Fetch completed
+   U:   a004 fetch 16 rfc822
+   S:   * 16 Fetch (RFC822 {637}
+   S:   Mail-From: RINDFLEISCH created at  9-Jun-88 12:55:43
+   S:   Mail-From: FAGAN created at  4-Jun-88 13:27:12
+   S:   Date: Sat, 4 Jun 88 13:27:11 PDT
+   S:   From: Larry Fagan  <FAGAN@SUMEX-AIM.Stanford.EDU>
+   S:   To: rindflEISCH@SUMEX-AIM.Stanford.EDU
+   S:   Subject: INFO-MAC Mail Message
+   S:   Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>
+   S:   ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT
+   S:   ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
+   S:   ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU,
+         Crispin@SUMEX-AIM.Stanford.EDU
+   S:   ReSent-Message-ID:
+         <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
+   S:
+   S:   The file is <info-mac>usenetv4-55.arc  ...
+   S:   Larry
+   S:   -------
+   S:   )
+   S:   a004 OK Fetch completed
+
+
+
+Crispin                                                        [Page 22]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   U:   a005 logout
+   S:   * BYE DEC-20 IMAP II server terminating connection
+   S:   a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
+         Service logout
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 23]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+Implementation Discussion
+
+   There are several advantages to the scheme of tags and unsolicited
+   responses.  First, the infamous synchronization problems of SMTP and
+   similar protocols do not happen with tagged commands; a command is
+   not considered satisfied until a response with the same tag is seen.
+   Tagging allows an arbitrary amount of other responses ("unsolicited"
+   data) to be sent by the server with no possibility of the client
+   losing synchronization.  Compare this with the problems that FTP or
+   SMTP clients have with continuation, partial completion, and
+   commentary reply codes.
+
+   Another advantage is that a non-lockstep client implementation is
+   possible.  The client could send a command, and entrust the handling
+   of the server responses to a different process that would signal the
+   client when the tagged response comes in.  Under certain
+   circumstances, the client may have more than one command outstanding.
+
+   It was observed that synchronization problems can occur with literals
+   if the literal is not recognized as such.  Fortunately, the cases in
+   which this can happen are rare; a mechanism (the special "+" tag
+   response) was introduced to handle those few cases.  The proper way
+   to address this problem is probably to move towards a record-oriented
+   architecture instead of the text stream model provided by TCP.
+
+   An IMAP2 client must maintain a local cache of data from the mailbox.
+   This cache is an incomplete model of the mailbox, and at startup is
+   empty.  A listener processes all unsolicited data, and updates the
+   cache based on this data.  If a tagged response arrives, the listener
+   unblocks the process that sent the tagged request.
+
+   Unsolicited data needs some discussion.  Unlike most protocols, in
+   which the server merely does the client's bidding, an IMAP2 server
+   has a semi-autonomous role.  By sending "unsolicited data", the
+   server is in effect sending a command to the client -- to update or
+   extend the client's cache with new information from the server.  In
+   other words, a "fetch" command is merely a request to the server to
+   ensure that the client's cache has the most up-to-date version of the
+   requested information.  A server acknowledgement to the "fetch" is a
+   statement that all the requested data has been sent.
+
+   Although no current server does this, a server is not obliged by the
+   protocol to send data that it has already sent and is unchanged.  An
+   exception to this is the actual message text fetching operations
+   (RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly
+   excessive resource consumption of maintaining this data in a cache.
+   It can not be assumed that a FETCH will transmit any data; only that
+   an OK to the FETCH means that the client's cache has the most up-to-
+
+
+
+Crispin                                                        [Page 24]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   date information.
+
+   When a mailbox is selected, the initial unsolicited data from the
+   server arrives.  The first piece of data is the number of messages.
+   By sending a new EXISTS unsolicited data message the server causes
+   the client to resize its cache (this is how newly arrived mail is
+   handled).  If the client attempts to access information from the
+   cache, it will encounter empty spots that will trigger "fetch"
+   requests.  The request would be sent, some unsolicited data including
+   the answer to the fetch will flow back, and then the "fetch" response
+   will unblock the client.
+
+   People familiar with demand-paged virtual memory operating system
+   design will recognize this model as being similar to page-fault
+   handling on a demand-paged system.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 25]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in RFC 822 with one exception; the
+   delimiter used with the "#" construct is a single space (SP) and not
+   a comma.
+
+   address         ::= "(" addr_name SP addr_adl SP addr_mailbox SP
+                       addr_host ")"
+
+   addr_adl        ::= nil / string
+
+   addr_host       ::= nil / string
+
+   addr_mailbox    ::= nil / string
+
+   addr_name       ::= nil / string
+
+   bboard          ::= "BBOARD" SP string
+
+   check           ::= "CHECK"
+
+   copy            ::= "COPY" SP sequence SP mailbox
+
+   data            ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number /
+                       "BYE" SP text_line / "OK" SP text_line /
+                       "NO" SP text_line / "BAD" SP text_line)
+
+   date            ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
+
+   envelope        ::= "(" env_date SP env_subject SP env_from SP
+                       env_sender SP env_reply-to SP env_to SP
+                       env_cc SP env_bcc SP env_in-reply-to SP
+                       env_message-id ")"
+
+   env_bcc         ::= nil / "(" 1*address ")"
+
+   env_cc          ::= nil / "(" 1*address ")"
+
+   env_date        ::= string
+
+   env_from        ::= nil / "(" 1*address ")"
+
+   env_in-reply-to ::= nil / string
+
+   env_message-id  ::= nil / string
+
+   env_reply-to    ::= nil / "(" 1*address ")"
+
+
+
+Crispin                                                        [Page 26]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   env_sender      ::= nil / "(" 1*address ")"
+
+   env_subject     ::= nil / string
+
+   env_to          ::= nil / "(" 1*address ")"
+
+   expunge         ::= "EXPUNGE"
+
+   fetch           ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
+                       fetch_att / "(" 1#fetch_att ")")
+
+   fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
+                       "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
+                       "RFC822.TEXT"
+
+   find            ::= "FIND" SP find_option SP string
+
+   find_option     ::= "MAILBOXES" / "BBOARDS"
+
+   flag_list       ::= ATOM / "(" 1#ATOM ")"
+
+   literal         ::= "{" NUMBER "}" CRLF ASCII-STRING
+
+   login           ::= "LOGIN" SP userid SP password
+
+   logout          ::= "LOGOUT"
+
+   mailbox         ::= "INBOX" / string
+
+   msg_copy        ::= "COPY"
+
+   msg_data        ::= (msg_exists / msg_recent / msg_expunge /
+                       msg_fetch / msg_copy)
+
+   msg_exists      ::= "EXISTS"
+
+   msg_expunge     ::= "EXPUNGE"
+
+   msg_fetch       ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP
+                        envelope / "FLAGS" SP "(" 1#(recent_flag
+                        flag_list) ")" / "INTERNALDATE" SP date /
+                        "RFC822" SP string / "RFC822.HEADER" SP string /
+                        "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
+                        string) ")"
+
+   msg_recent      ::= "RECENT"
+
+   msg_num         ::= NUMBER
+
+
+
+Crispin                                                        [Page 27]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   nil             ::= "NIL"
+
+   noop            ::= "NOOP"
+
+   password        ::= string
+
+   recent_flag     ::= "\RECENT"
+
+   ready           ::= "+" SP text_line
+
+   request         ::= tag SP (noop / login / logout / select / check /
+                       expunge / copy / fetch / store / search / find /
+                       bboard) CRLF
+
+   response        ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF
+
+   search          ::= "SEARCH" SP 1#("ALL" / "ANSWERED" /
+                       "BCC" SP string / "BEFORE" SP string /
+                       "BODY" SP string / "CC" SP string / "DELETED" /
+                       "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
+                       "ON" SP string / "RECENT" / "SEEN" /
+                       "SINCE" SP string / "TEXT" SP string /
+                       "TO" SP string / "UNANSWERED" / "UNDELETED" /
+                       "UNFLAGGED" / "UNKEYWORD" / "UNSEEN")
+
+   select          ::= "SELECT" SP mailbox
+
+   sequence        ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
+                       sequence)
+
+   store           ::= "STORE" SP sequence SP store_att
+
+   store_att       ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
+                       "FLAGS" SP flag_list)
+
+   string          ::= atom / """" 1*character """" / literal
+
+   system_flags    ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
+                       "\SEEN"
+
+   tag             ::= atom
+
+   unsolicited     ::= "*" SP (msg_num SP msg_data / data) CRLF
+
+   userid          ::= string
+
+
+
+
+
+
+Crispin                                                        [Page 28]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+Implementation Status
+
+   This information is current as of this writing.
+
+   The University of Washington has developed an electronic mail client
+   library called the "C-Client". It provides complete IMAP2, SMTP, and
+   local mailbox (both /usr/spool/mail and mail.txt formats) services in
+   a well-defined way to a user interface main program.  Using the C-
+   Client, the University of Washington has created an operational
+   client for BSD Unix and two operational clients (one basic, one
+   advanced) for the NeXT.
+
+   Stanford University/SUMEX has developed operational IMAP2 clients for
+   Xerox Lisp machines, Texas Instruments Explorers, and the Apple
+   Macintosh.  The core of the Macintosh client is an early version of
+   the C-Client.  SUMEX has also developed IMAP2 servers for TOPS-20 and
+   BSD Unix.
+
+   All of the above software is in production use, with enthusiastic
+   local user communities.  Active development continues on the
+   Macintosh and C-Client based clients and the BSD Unix server.  This
+   software is freely available from the University of Washington and
+   SUMEX.
+
+   IMAP2 software exists for other platforms; for example Nippon
+   Telephone and Telegraph (NTT) has developed an operational IMAP2
+   client for the NTT ELIS.  Several organizations are working on a PC
+   client.
+
+   IMAP2 can be used to access mailboxes at very remote sites, where
+   echo delays and frequent outages make TELNET and running a local mail
+   reader intolerable.  For example, from a desktop workstation on the
+   University of Washington local network the author routinely uses
+   IMAP2 to read and manage mailboxes on various University of
+   Washington local servers, at two systems at Stanford University, at a
+   Milnet site, and at a site in Tokyo, Japan.
+
+   This specification does not make any formal definition of size
+   restrictions, but the DEC-20 server has the following limitations:
+
+    . length of a mailbox: 7,077,888 characters
+    . maximum number of messages: 18,432 messages
+    . length of a command line: 10,000 characters
+    . length of the local host name: 64 characters
+    . length of a "short" argument: 39 characters
+    . length of a "long" argument: 491,520 characters
+    . maximum amount of data output in a single fetch:
+      655,360 characters
+
+
+
+Crispin                                                        [Page 29]
+
+RFC 1176                         IMAP2                       August 1990
+
+
+   To date, nobody has run up against any of these limitations, many of
+   which are substantially larger than most current user mail reading
+   programs.
+
+Acknowledgements
+
+   Bill Yeager and Rich Acuff both contributed invaluable suggestions in
+   the evolution of IMAP2 from the original IMAP.  James Rice pointed
+   out several ambiguities in the previous IMAP2 specification and
+   otherwise would not allow me to leave bad enough along.  Laurence
+   Lundblade reviewed a draft of this version and made several helpful
+   suggestions.
+
+   Many dedicated individuals have worked on IMAP2 software, including:
+   Mark Crispin, Frank Gilmurray, Christopher Lane, Hiroshi Okuno,
+   Christopher Schmidt, and Bill Yeager.
+
+   Any mistakes, flaws, or sins of omission in this IMAP2 protocol
+   specification are, however, strictly my own; and the mention of any
+   name above does not imply an endorsement.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Mark R. Crispin
+   Panda Programming
+   6158 Lariat Loop NE
+   Bainbridge Island, WA 98110-2020
+
+   Phone: (206) 842-2385
+
+   EMail: mrc@Tomobiki-Cho.CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 30]
+
\ No newline at end of file
diff --git a/RFC/rfc1203.txt b/RFC/rfc1203.txt
new file mode 100644
index 00000000..a362ca88
--- /dev/null
+++ b/RFC/rfc1203.txt
@@ -0,0 +1,2747 @@
+
+
+
+
+
+
+Network Working Group                                           J. Rice
+Request for Comments: 1203                                     Stanford
+Obsoletes: RFC 1064                                       February 1991
+
+
+              INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3
+
+Status of this Memo
+
+   This RFC suggests a method for workstations to access mail
+   dynamically from a mailbox server ("repository").  This RFC specifies
+   a standard for the SUMEX-AIM community and an Experimental Protocol
+   for the Internet community.  Discussion and suggestions for
+   improvement are requested.  Please refer to the current edition of
+   the "IAB Official Protocol Standards" for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Scope
+
+   The following document is a modified version of RFC 1064, the
+   definition of the IMAP2 protocol.  This RFC has been written
+   specifically as a counter proposal to RFC 1176, which itself proposes
+   modifications to IMAP2.  Sadly, RFC 1176 was made without internal
+   consultation with the IMAP community, so we are in a position of
+   feeling we have to present a counter proposal to what, if we do not
+   act, will become a de facto standard.  The reasons for this counter
+   proposal are numerous but fall mostly into the following categories:
+
+      - IMAP2 is insufficiently powerful for a number of server/client
+        interactions which we believe to be important.  RFC 1176
+        negligibly enhances the functionality of IMAP2.
+
+      - IMAP2 makes what we believe to be an erroneous definition for
+        unsolicited vs. solicited data.  IMAP3 as specified herein
+        attempts to correct this.  RFC 1176 makes no effort to remedy
+        these problems.
+
+      - RFC 1176 has explicitly modified the intent of RFC 1064 by
+        allowing the server to make assumptions about the client's
+        caching architecture.  We believe this to be a grave error
+        and do not support it in this proposal.
+
+      - RFC 1176 specifies a number of "optional" features in the
+        protocol without specifying a suitable metaprotocol by which
+        servers and clients can adequately negotiate over the set of
+        implemented features.  This proposal specifies a mechanism
+        by which servers and clients can come to an unambiguous
+        understanding about which features are usable by each party.
+
+
+
+Rice                                                            [Page 1]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+
+      - RFC 1176 pays only lip-service to being network protocol
+        independent and, in fact assumes the use of TCP/IP.  Neither
+        RFC 1064 nor this proposal make any such assumption.
+
+   Although there are numerous other detailed objections to RFC 1176, we
+   believe that the above will serve to show that we believe strongly in
+   the importance of mailbox abstraction level mail protocols and, after
+   a couple of years of use of IMAP2 under RFC 1064 we believe that we
+   have a good enough understanding of the issues involved to be able to
+   take the next step.
+
+   It is important to take this next step because of the rapid pace of
+   both mail system and user interface development.  We believe that,
+   for IMAP not to die in its infancy, IMAP must be ready to respond to
+   emerging ISO and RFC standards in mail, such as for multi-media mail.
+   We believe that RFC 1176 not only provides a very small increment in
+   functionality over RFC 1064 but also adds a number of bugs, which
+   would be detrimental to the IMAP cause.  Thus we propose the
+   following definition for IMAP3.
+
+Compatibility notes:
+
+   In revising the IMAP2 protocol it has been our intent, wherever
+   possible to make upwards compatible changes to produce IMAP3.  There
+   were, however, some places that had to be changed incompatibly in
+   order to compensate for either ambiguities in the IMAP2 protocol as
+   defined by RFC 1064 or behavior that proved undesirable in the light
+   of experience.
+
+   It is our goal, however, that existing IMAP2 clients should still be
+   supported and that, at least for the foreseeable future, all IMAP3
+   servers will support IMAP2 behavior as their default mode.
+
+   The following are the major differences between this proposal, RFC
+   1176 and RFC 1064:
+
+      - In this proposal we specify a difference between "solicited" and
+        "unsolicited" data sent from the server.  It is generally the
+        case that data sent by the server can be sent either in response
+        to an explicit request by the client or by the server of its own
+        volition.  Any data that the server is required to sent to the
+        client as the result of a request is said to be solicited and
+        carries the same tag as the request that provoked it.  Any data
+        sent by the server to the client that is not required by the
+        protocol is said to be unsolicited and carries the special "*"
+        tag.  RFC 1176 preserves the original RFC 1064 terminology that
+        calls all such data sent by the server "unsolicited" even when
+
+
+
+Rice                                                            [Page 2]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+        it is, in fact, solicited.
+
+      - This proposal introduces the experimental concept of
+        distinguishing between Generic, Canonical and Concrete keys,
+        allowing the mailbox to be viewed as a relational database
+        indexed by these keys.  This should allow the IMAP protocol
+        to evolve away from its current reliance on RFC 822.  RFC 1176
+        does not have such a unifying model.
+
+      - The SEARCH command has been changed so as to allow multiple
+        simultaneous searches to be made and to allow unsolicited
+        search messages to be sent by the server.  Such a change is
+        essential to allow more sophisticated servers that can process
+        commands asynchronously, possibly substantially delaying
+        searches over slow backing storage media, for example.  It is
+        also important to allow servers to be able to send unsolicited
+        search messages that might inform the client of interesting
+        patterns of messages, such as new and unseen mail.
+
+      - This proposal introduces a specific protocol for the negotiation
+        of protocol versions and server features.  This is important
+        because it allows client/server pairs to come to an agreement on
+        what behavior is really available to it.  RFC 1176 introduces a
+        number of "optional" commands, which are in some way analogous
+        to "feature-introduced" commands in this proposal.  The principle
+        distinction between these is that in RFC 1176 there is no way
+        for a client to discover the set of optional commands, nor is
+        there a way for it to determine whether a specific command
+        really is supported, since RFC 1176 requires the use of the
+        "BAD" response if a feature is not supported.  There is,
+        therefore, no way for the client to determine why the attempted
+        command did not work.  This also means that, for example, a
+        client cannot disable certain user commands or make them
+        invisible on menus if they are not supported, since there
+        is no way for the client to discover whether the commands are
+        indeed supported without trying to execute such a command.
+
+      - This proposal introduces a mechanism for clients to create and
+        delete user flags (keywords).  This is nor supported in either
+        RFC 1176 or RFC 1064, requiring the user to add keys manually
+        on the server, generally by editing some form of "init" file.
+
+      - RFC 1064 has no mechanism for determining whether a mailbox is
+        readonly or not.  RFC 1176 introduces a non-enforced convention
+        of encoding data about the readonly status of a mailbox in the
+        SELECT message's OK respose comment field.  This is not regular
+        with respect to the rest of the protocol, in which the comment
+        field is used for no purpose other than documentation.  This
+
+
+
+Rice                                                            [Page 3]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+        proposal introduces specific protocol additions for the dynamic
+        determination and modification of the readonly/readwrite status
+        of mailboxes.
+
+Introduction
+
+   The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3)
+   is to allow a (possibly unreliable) workstation or similar machine to
+   access electronic mail from a reliable mailbox server in an efficient
+   manner.
+
+   Although different in many ways from POP2 (RFC 937), IMAP3 may be
+   thought of as a functional superset of POP2, and the POP2 RFC was
+   used as a model for this RFC.  There was a cognizant reason for this;
+   RFC 937 deals with an identical problem and it was desirable to offer
+   a basis for comparison.
+
+   Like POP2, IMAP3 specifies a means of accessing stored mail and not
+   of posting mail; this function is handled by a mail transfer protocol
+   such as SMTP (RFC 821).  A comparison with the DMSP protocol of
+   PCMAIL can be found at the end of "System Model and Philosophy"
+   section.
+
+   This protocol assumes a reliable data stream such as provided by TCP
+   or any similar protocol.  When TCP is used, the IMAP server listens
+   on port 220.  When CHAOS is used the IMAP server listens for the
+   logical contact name "IMAP3".
+
+   Communication in IMAP is defined to be using the ASCII character
+   interpretation of data.  Communication using other conventions may be
+   possible by the selection of features on some servers.
+
+System Model and Philosophy
+
+   Electronic mail is a primary means of communication for the widely
+   spread SUMEX-AIM community.  The advent of distributed workstations
+   is forcing a significant rethinking of the mechanisms employed to
+   manage such mail.  With mainframes, each user tends to receive and
+   process mail at the computer he used most of the time, his "primary
+   host".  The first inclination of many users when an independent
+   workstation is placed in front of them is to begin receiving mail at
+   the workstation, and, in fact, many vendors have implemented
+   facilities to do this.  However, this approach has several
+   disadvantages:
+
+      (1)  Workstations (especially Lisp workstations) have a software
+           design that gives full control of all aspects of the system
+           to the user at the console.  As a result, background tasks,
+
+
+
+Rice                                                            [Page 4]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+           like receiving mail, could well be kept from running for
+           long periods of time either because the user is asking to
+           use all of the machine's resources, or because, in the course
+           of working, the user has (perhaps accidentally) manipulated
+           the environment in such a way as to prevent mail reception.
+           This could lead to repeated failed delivery attempts by
+           outside agents.
+
+      (2)  The hardware failure of a single workstation could keep its
+           user "off the air" for a considerable time, since repair of
+           individual workstation units might be delayed.  Given the
+           growing number of workstations spread throughout office
+           environments, quick repair would not be assured, whereas a
+           centralized mainframe is generally repaired very soon after
+           failure.
+
+      (3)  It is more difficult to keep track of mailing addresses when
+           each person is associated with a distinct machine.  Consider
+           the difficulty in keeping track of a large number of postal
+           addresses or phone numbers, particularly if there was no
+           single address or phone number for an organization through
+           which you could reach any person in that organization.
+           Traditionally, electronic mail on the ARPANET involved
+           remembering a name and one of several "hosts" (machines)
+           whose name reflected the organization in which the
+           individual worked.  This was suitable at a time when most
+           organizations had only one central host.  It is less
+           satisfactory today unless the concept of a host is changed
+           to refer to an organizational entity and not a particular
+           machine.
+
+      (4)  It is very difficult to keep a multitude of heterogeneous
+           workstations working properly with complex mailing protocols,
+           making it difficult to move forward as progress is made in
+           electronic communication and as new standards emerge.  Each
+           system has to worry about receiving incoming mail, routing
+           and delivering outgoing mail, formatting, storing, and
+           providing for the stability of mailboxes over a variety of
+           possible filing and mailing protocols.
+
+   Consequently, while the workstation may be viewed as an Internet host
+   in the sense that it implements IP, it should not be viewed as the
+   entity which contains the user's mailbox.  Rather, a mail server
+   machine (sometimes called a "repository") should hold the mailbox,
+   and the workstation (hereafter referred to as a "client") should
+   access the mailbox via mail transactions.  Because the mail server
+   machine would be isolated from direct user manipulation, it could
+   achieve high software reliability easily, and, as a shared resource,
+
+
+
+Rice                                                            [Page 5]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   it could achieve high hardware reliability, perhaps through
+   redundancy.  The mail server could be used from arbitrary locations,
+   allowing users to read mail across campus, town, or country using
+   more and more commonly available clients.  Furthermore, the same user
+   may access his mailbox from different clients at different times, and
+   multiple users may access the same mailbox simultaneously.
+
+   The mail server acts an an interface among users, data storage, and
+   other mailers.  The mail access protocol is used to retrieve
+   messages, access and change properties of messages, and manage
+   mailboxes.  This differs from some approaches (e.g., Unix mail via
+   NFS) in that the mail access protocol is used for all message
+   manipulations, isolating the user and the client from all knowledge
+   of how the data storage is used.  This means that the mail server can
+   utilize the data storage in whatever way is most efficient to
+   organize the mail in that particular environment, without having to
+   worry about storage representation compatibility across different
+   machines.
+
+   In defining a mail access protocol, it is important to keep in mind
+   that the client and server form a macrosystem, in which it should be
+   possible to exploit the strong points of both while compensating for
+   each other's weaknesses.  Furthermore, it's desirable to allow for a
+   growth path beyond the hoary text-only RFC 822 protocol.  Unlike
+   POP2, IMAP3 has extensive features for remote searching and parsing
+   of messages on the server.  For example, a free text search
+   (optionally in conjunction with other searching) can be made
+   throughout the entire mailbox by the server and the results made
+   available to the client without the client having to transfer the
+   entire mailbox and searching itself.  Since remote parsing of a
+   message into a structured (and standard format) "envelope" is
+   available, a client can display envelope information and implement
+   commands such as REPLY without having any understanding of how to
+   parse RFC 822, etc., headers.
+
+   Additionally, IMAP3 offers several facilities for managing a mailbox
+   beyond the simple "delete message" functionality of POP2.
+
+   In spite of this, IMAP3 is a relatively simple protocol.  Although
+   servers should implement the full set of IMAP3 functions, a simple
+   client can be written which uses IMAP3 in much the way as a POP2
+   client.
+
+   IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more
+   fundamental manner, reflecting the differing architectures of IMAP
+   and PCMAIL.  PCMAIL is either an online ("interactive mode"), or
+   offline ("batch mode") system.  IMAP is primarily an online system in
+   which real-time and simultaneous mail access were considered
+
+
+
+Rice                                                            [Page 6]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   important.
+
+   In PCMAIL, there is a long-term client/server relationship in which
+   some mailbox state is preserved on the client.  There is a
+   registration of clients used by a particular user, and the client
+   keeps a set of "descriptors" for each message which summarize the
+   message.  The server and client synchronize their states when the
+   DMSP connection starts up, and, if a client has not accessed the
+   server for a while, the client does a complete reset (reload) of its
+   state from the server.
+
+   In IMAP, the client/server relationship lasts only for the duration
+   of the IMAP3 connection.  All mailbox state is maintained on the
+   server.  There is no registration of clients.  The function of a
+   descriptor is handled by a structured representation of the message
+   "envelope".  This structure makes it unnecessary for a client to know
+   anything about RFC 822 parsing.  There is no synchronization since
+   the client does not remember state between IMAP3 connections.  This
+   is not a problem since in general the client never needs the entire
+   state of the mailbox in a single session, therefore there isn't much
+   overhead in fetching the state information that is needed as it is
+   needed.
+
+   There are also some functional differences between IMAP3 and DMSP.
+   DMSP has functions for sending messages, printing messages, and
+   changing passwords, all of which are done outside of IMAP3.  DMSP has
+   16 binary flags of which 8 are defined by the system.  IMAP has flag
+   names; there are currently 5 defined system flag names and a facility
+   for some number (29 in the current implementations) of user flag
+   names.  IMAP3 has a sophisticated message search facility in the
+   server to identify interesting messages based on dates, addresses,
+   flag status, or textual contents without compelling the client to
+   fetch this data for every message.
+
+   It was felt that maintaining state on the client is advantageous only
+   in those cases where the client is only used by a single user, or if
+   there is some means on the client to restrict access to another
+   user's data.  It can be a serious disadvantage in an environment in
+   which multiple users routinely use the same client, the same user
+   routinely uses different clients, and where there are no access
+   restrictions on the client.  It was also observed that most user mail
+   access is to a relatively small set of "interesting" messages, which
+   were either "new" mail or mail based upon some user-selected
+   criteria. Consequently, IMAP3 was designed to easily identify those
+   "interesting" messages so that the client could fetch the state of
+   those messages and not those that were not "interesting".
+
+   One crucial philosophical difference between IMAP and other common
+
+
+
+Rice                                                            [Page 7]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   mail protocols is that IMAP is a mailbox access protocol, not a
+   protocol for manipulating mail files.  In the IMAP model, unlike
+   other mail system models in which mail is stored in a linear mail
+   file, no specification is made for the implementation architecture
+   for mail storage.  Servers may choose to implement mailboxes as files
+   but this is a detail of which the client can be totally unaware.
+
+   What is more, in the IMAP model, mailboxes are viewed as mappings
+   from keys into values.  There are broadly three types of keys,
+   generic, canonical and concrete.  Generic keys are generic, mail
+   protocol independent keys defined by IMAP which are meaningful across
+   multiple mail encoding formats.  An example of such a generic key
+   might be "TO", which would be associated with the "To:" field of an
+   RFC 822 format message.
+
+   Canonical keys represent the way in which the server can associate
+   values that are generally "about" a certain key concept, possibly
+   integrating several mail format specific fields, without having to
+   worry the client with the particular details of any particular
+   message format.  Thus, the canonical TO key (called $TO) could denote
+   anything that could reasonably be construed as being directed towards
+   someone.  Hence, in an RFC 822 message the server could find the
+   union of the "To:", "Resent-To", "Apparently-To:" and "CC:" fields to
+   be the appropriate value associated with the canonical $TO key.
+
+   Concrete keys allow the client to gain access to certain mail format
+   specific concepts, that are not pre-specified by the IMAP protocol,
+   in a well defined manner.  For example, If the client asks for the
+   value associated with the "APPARENTLY-TO" key then, if the message
+   were to be in RFC 822 format, the server would look for a header
+   field called "Apparently-To:".  If no such field is found or the
+   field is not implemented or meaningful for the particular message
+   format then the server will respond with the null value, called NIL,
+   indicating the non-existence of the field.
+
+   Thus, IMAP servers are at liberty to implement mailboxes as a
+   relational databases if it seems convenient.  Indeed, we anticipate
+   that future mail systems will tend to use database technology for the
+   storage and indexing of mailboxes as a result of the pressure caused
+   by the increasing size of mailboxes.
+
+   Although for historical reasons IMAP is currently somewhat closely
+   associated with RFC 822, we anticipate that future developments in
+   IMAP will remove these mail format specific components and will move
+   towards the generic model mentioned above.  This will allow IMAP more
+   easily to incorporate such things as multi-media mail.
+
+
+
+
+
+Rice                                                            [Page 8]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+The Protocol
+
+   The IMAP3 protocol consists of a sequence of client commands and
+   server responses to those commands, with extra information from the
+   server data being sent asynchronously to and independent to the
+   responses to client commands.  Unlike most Internet protocols,
+   commands and responses are tagged.  That is, a command begins with a
+   unique identifier (typically a short alphanumeric sequence such as a
+   Lisp "gensym" function would generate e.g., A0001, A0002, etc.),
+   called a tag.  The response to this command is given the same tag
+   from the server.
+
+   We distinguish between data sent by the server as the result of a
+   client request, which we term "SOLICITED" and data sent by the server
+   not as the result of a client request, which we term "UNSOLICITED".
+   The server may send unsolicited data at any time that would not
+   fragment another piece of data on the same stream rendering it
+   unintelligible.  The server is contractually required, however, to
+   return all data that is solicited by the client before the return of
+   the completion signal for that command, i.e., all solicited data must
+   be returned within the temporal extent of the request/completion
+   acknowledgement wrapper.  This does not, however, preclude the
+   simultaneous processing of multiple requests by the client, it simply
+   requires that the client be confident that it has all the requested
+   data when a request finishes.  This allows the implementation of both
+   synchronous and asynchronous clients.
+
+   Solicited data is identified by the tag of the initial request by the
+   client.  Unsolicited data is identified by the special reserved tag
+   of "*".  There is another special reserved tag, "+", discussed below.
+
+   Note: the tagging of SOLICITED data is only permitted for a selected
+   server version other than 2.0.
+
+   No assumptions concerning serial or monolithic processing by the
+   server can be made by a correct client.  The server is at liberty to
+   process multiple requests by the same client in any order.  This
+   allows servers to process costly searches over mailboxes on slow
+   backing storage media in the background, while still preserving
+   interactive performance.  Clients can, however, assume the
+   serialization of the request/data/completion behavior mentioned
+   above.
+
+   When a connection is opened the server sends an unsolicited OK
+   response as a greeting message and then waits for commands.  When
+   commands are received the server acts on them and responds with
+   responses, often interspersed with data.
+
+
+
+
+Rice                                                            [Page 9]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   The client opens a connection, waits for the greeting, then sends a
+   LOGIN command with user name and password arguments to establish
+   authorization.  Following an OK response from the server, the client
+   then sends a SELECT command to access the desired mailbox.  The
+   user's default mailbox has a special reserved name of "INBOX" which
+   is independent of the operating system that the server is implemented
+   on.  The server will generally send a list of valid flags, number of
+   messages, and number of messages arrived since last access for this
+   mailbox as solicited data, followed by an OK response.  The client
+   may terminate access to this mailbox and access a different one with
+   another SELECT command.
+
+   Because the SELECT command affects the state of the server in a
+   fundamental way, the server is required to process all outstanding
+   commands for any given mailbox before sending the OK tag for the
+   SELECT command.  Thus, the client will always know that all responses
+   before an OK SELECT response will refer to the old mailbox and all
+   responses following it will apply to the new mailbox.
+
+   Because, in the real world, local needs or experimental work will
+   dictate that servers will support both supersets of the defined
+   behavior and incompatible changes, servers will support a
+   SELECT.VERSION command and a SELECT.FEATURES command, the purpose of
+   which is to allow clients to select the overall behavior and specific
+   features that they want from a server.  The default behavior of any
+   server is to process commands and to have interaction syntax the same
+   as is specified by IMAP2 in RFC 1064.  A server may not behave in any
+   other manner unless the SELECT.VERSION or SELECT.FEATURES commands
+   are used to select different behavior.
+
+   Over time, when groups of generally useful changes to the current,
+   default behavior of the server are found, these will be collected
+   together and incorporated in such a way that all of the features can
+   be selected simply by selecting a particular major version number of
+   the protocol.  It should be noted that the version numbers (both
+   major and minor) selected by the SELECT.VERSION command denote
+   versions of the IMAP protocol, not versions of the server per se.
+   Thus, although in general changes to the protocol specification will
+   be made in such a way that they are upwards compatible, this cannot
+   be guaranteed.  No client should rely on tests of the form "if
+   major_version > 2 then..." being valid for all protocol versions,
+   since incompatible changes might be made in the future.
+
+   The client reads mailbox information by means of FETCH commands.  The
+   actual data is transmitted via the solicited data mechanism (that is,
+   FETCH should be viewed as poking the server to include the desired
+   data along with any other data it wishes to transmit to the client).
+   There are three major categories of data which may be fetched.
+
+
+
+Rice                                                           [Page 10]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   The first category is that data which is associated with a message as
+   an entity in the mailbox.  There are presently three such items of
+   data: the "internal date", the "RFC 822 size", and the "flags".  The
+   internal date is the date and time that the message was placed in the
+   mailbox.  The RFC 822 size is subject to deletion in the future; it
+   is the size in bytes of the message, expressed as an RFC 822 text
+   string.  Current clients only use it as part of a status display
+   line.  The flags are a list of status flags associated with the
+   message (see below).  All of the first category data can be fetched
+   by using the macro-fetch word "FAST"; that is, "FAST" expands to
+   "(FLAGS INTERNALDATE RFC822.SIZE)".
+
+   The second category is that data which describes the composition and
+   delivery information of a message; that is, information such as the
+   message sender, recipient lists, message-ID, subject, etc.  This is
+   the information which is stored in the message header in RFC 822
+   format message and is traditionally called the "envelope".  [Note:
+   this should not be confused with the SMTP (RFC 821) envelope, which
+   is strictly limited to delivery information.]  IMAP3 defines a
+   structured and unambiguous representation for the envelope which is
+   particularly nice for Lisp-based parsers.  A client can use the
+   envelope for operations such as replying and not worry about RFC 822
+   at all.  Envelopes are discussed in more detail below.  The first and
+   second category data can be fetched together by using the macro-fetch
+   word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE
+   RFC822.SIZE ENVELOPE)".
+
+   The third category is that data which is intended for direct human
+   viewing.  The present RFC 822 based IMAP3 defines three such items:
+   RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two
+   former appended together in a single text string).  Fetching "RFC822"
+   is equivalent to typing the RFC 822 representation of the message as
+   stored on the mailbox without any filtering or processing.
+
+   Typically, a client will "FETCH ALL" for some or all of the messages
+   in the mailbox for use as a presentation menu, and when the user
+    wishes to read a particular message will "FETCH RFC822.TEXT" to get
+   the message body.  A more primitive client could, of course, simply
+   "FETCH RFC822" a la POP2-type functionality.
+
+   The client can alter certain data by means of a STORE command.  As an
+   example, a message is deleted from a mailbox by a STORE command which
+   includes the \DELETED flag as one of the flags being set.
+
+   Other client operations include copying a message to another mailbox
+   (COPY command), permanently removing deleted messages (EXPUNGE
+   command), checking for new messages (CHECK command), and searching
+   for messages which match certain criteria (SEARCH command).
+
+
+
+Rice                                                           [Page 11]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   The client terminates the session with the LOGOUT command.  The
+   server returns a "BYE" followed by an "OK".
+
+A Typical Scenario
+
+        Client                          Server
+        ------                          ------
+                                    {Wait for Connection}
+    {Open Connection}        -->
+                                <-- * OK IMAP3 Server Ready
+                                    {Wait for command}
+    A001 SUPPORTED.VERSIONS   -->
+                                <-- * SUPPORTED.VERSIONS ((2 0 )
+                                        (3 0 EIGHT.BIT.TRANSPARENT
+                                             AUTO.SET.SEEN
+                                             TAGGED.SOLICITED))
+                                    A001 OK Supported Versions returned.
+                                    {Wait for command}
+    A002 SELECT.VERSION (3 0) -->
+                                <-- A002 OK Version 3.0 Selected.
+                                    {Wait for command}
+    A002 SELECT.FEATURES TAGGED.SOLICITED -->
+                                <-- A002 OK Features selected.
+                                    {Wait for command}
+    A003 LOGIN Fred Secret   -->
+                                <-- A003 OK User Fred logged in
+                                    {Wait for command}
+    A004 SELECT INBOX        -->
+                                <-- A004 FLAGS (Meeting Notice \Answered
+                                             \Flagged \Deleted \Seen)
+                                <-- A004 19 EXISTS
+                                <-- A004 2 RECENT
+                                <-- A004 OK Select complete
+                                    {Wait for command}
+    A005 FETCH 1:19 ALL      -->
+                                <-- A005 1 Fetch (......)
+                                        ...
+                                <-- A005 18 Fetch (......)
+                                <-- A005 19 Fetch (......)
+                                <-- A005 OK Fetch complete
+                                    {Wait for command}
+    A006 FETCH 8 RFC822.TEXT -->
+                                <-- A006 8 Fetch (RFC822.TEXT {893}
+                                       ...893 characters of text...
+                                <-- )
+                                <-- A006 OK Fetch complete
+                                    {Wait for command}
+
+
+
+
+Rice                                                           [Page 12]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+    A007 STORE 8 +Flags \Deleted -->
+                                <-- A007 8 Store (Flags (\Deleted
+                                               \Seen))
+                                <-- A007 OK Store complete
+                                    {Wait for command}
+    A008 EXPUNGE             -->
+                                <-- A008 19 EXISTS
+                                <-- A008 8 EXPUNGE
+                                <-- A008 18 EXISTS
+                                <-- A008 Expunge complete
+                                    {Wait for command}
+    A009 LOGOUT              -->
+                                <-- A009 BYE IMAP3 server quitting
+                                <-- A009 OK Logout complete
+    {Close Connection}       --><-- {Close connection}
+                                    {Go back to start}
+
+   A more complex scenario produced by a pipelining multiprocess client.
+
+        Client                          Server
+        ------                          ------
+                                    {Wait for Connection}
+    {Open session as above}
+                                <-- A004 19 EXISTS
+                                <-- A004 2 RECENT
+                                <-- A004 OK Select complete
+                                    {Wait for command}
+    A005 SEARCH RECENT       -->
+                                <-- A005 SEARCH (18 19) (RECENT)
+                                <---A005 OK Search complete
+    A006 FETCH 18:19 ALL RFC822.TEXT
+    A007 STORE 18:19 +FLAGS (\SEEN)
+    A008 FETCH 1:17 ALL      -->
+                                <-- A006 18 Fetch (... RFC822.TEXT ...)
+    A009 STORE 18 +FLAGS (\DELETED)
+                                <-- A006 19 Fetch (... RFC822.TEXT ...)
+                                <-- A006 OK Fetch complete
+                                <-- A007 18 STORE (Flags (\Seen))
+    A010 STORE 19 +FLAGS (\DELETED)
+                                <-- A007 19 STORE (Flags (\Seen))
+                                <-- A007 OK Store complete
+                                <-- A008 1 Fetch (......)
+                                       ...
+                                <-- A008 16 Fetch (......)
+                                <-- A008 17 Fetch (......)
+                                <-- A008 OK Fetch complete
+                                <-- A009 18 STORE (Flags (\Seen
+                                                          \Deleted))
+
+
+
+Rice                                                           [Page 13]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+                                <-- A009 OK Store complete
+                                <-- A010 19 STORE (Flags (\Seen
+                                                          \Deleted))
+                                <-- A010 OK Store complete
+                                    {Wait for command}
+                                <-- * EXISTS 23
+                                <-- * RECENT 4
+                                <-- * SEARCH (20 21 22 23) (RECENT)
+   A011 FETCH 20:23 ALL RFC822.TEXT
+
+Conventions
+
+   The following terms are used in a meta-sense in the syntax
+   specification below:
+
+      An ASCII-STRING is a sequence of arbitrary ASCII characters.
+
+      An ATOM is a sequence of ASCII characters delimited by SP or CRLF.
+
+      A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
+      or "\".
+
+      A CRLF is an ASCII carriage-return character followed immediately
+      by an ASCII linefeed character.
+
+      A NUMBER is a sequence of the ASCII characters which represent
+      decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or
+      ":".
+
+      A SP is the ASCII space character.
+
+      A TEXT_LINE is a human-readable sequence of ASCII characters up to
+      but not including a terminating CRLF.
+
+   One of the most common fields in the IMAP3 protocol is a STRING,
+   which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside
+   double-quotes), or a LITERAL.  A literal consists of an open brace
+   ("{"), a number, a close brace ("}"), a CRLF, and then an ASCII-
+   STRING of n characters, where n is the value of the number inside the
+   brace. In general, a string should be represented as an ATOM or
+   QUOTED-STRING if at all possible.  The semantics for QUOTED-STRING or
+   LITERAL are checked before those for ATOM; therefore an ATOM used in
+   a STRING may only contain CHARACTERs.  Literals are most often sent
+   from the server to the client; in the rare case of a client to server
+   literal there is a special consideration (see the "+ text" response
+   below).
+
+   Another important field is the SEQUENCE, which identifies a set of
+
+
+
+Rice                                                           [Page 14]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   messages by consecutive numbers from 1 to n where n is the number of
+   messages in the mailbox.  A sequence may consist of a single number,
+   a pair of numbers delimited by colon indicating all numbers between
+   those two numbers, or a list of single numbers and/or number pairs.
+   For example, the sequence 2,4:7,9,12:15 is equivalent to
+   2,4,5,6,7,9,12,13,14,15 and identifies all of those messages.
+
+Definitions of Commands and Responses
+
+   Summary of Commands and Responses
+
+Commands:
+       tag NOOP
+       tag LOGIN user password
+       tag LOGOUT
+       tag SELECT mailbox
+       tag CHECK
+       tag EXPUNGE
+       tag COPY sequence mailbox
+       tag FETCH sequence data
+       tag STORE sequence data value
+       tag SEARCH criteria
+       tag BBOARD bboard
+       tag FIND (BBOARDS / MAILBOXES) pattern
+       tag READONLY
+       tag READWRITE
+       tag SELECT.VERSION (major_version minor_version)
+       tag SELECT.FEATURES features
+       tag SUPPORTED.VERSIONS
+       tag FLAGS
+       tag SET.FLAGS
+
+Responses (can be either solicited or unsolicited):
+       */tag FLAGS flag_list
+       */tag SEARCH (numbers) (criteria)
+       */tag EXISTS
+       */tag RECENT
+       */tag EXPUNGE
+       */tag STORE data
+       */tag FETCH data
+       */tag BBOARD bboard_name
+       */tag MAILBOX non_inbox_mailbox_name
+       */tag SUPPORTED.VERSIONS version_data
+       */tag READONLY
+       */tag READWRITE
+       */tag OK text
+       */tag NO text
+       */tag BAD text
+
+
+
+Rice                                                           [Page 15]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+       */tag BYE text
+
+Responses (can only be solicited):
+       tag COPY message_number
+
+Responses (can only be unsolicited):
+       + text
+
+Commands
+
+   tag NOOP
+
+      The NOOP command returns an OK to the client.  By itself, it does
+      nothing, but certain things may happen as side effects.  For
+      example, server implementations which implicitly check the mailbox
+      for new mail may do so as a result of this command.  The primary
+      use of this command is to for the client to see if the server is
+      still alive (and notify the server that the client is still alive,
+      for those servers which have inactivity autologout timers).
+
+   tag LOGIN user password
+
+      The LOGIN command identifies the user to the server and carries
+      the password authenticating this user.  This information is used
+      by the server to control access to the mailboxes.
+
+      EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with
+      password SESAME.
+
+   tag LOGOUT
+
+      The LOGOUT command indicates the client is done with the session.
+      The server sends a solicited BYE response before the (tagged) OK
+      response, and then closes the connection.
+
+   tag SELECT mailbox
+
+      The SELECT command selects a particular mailbox.  The server must
+      check that the user is permitted read access to this mailbox.
+      Prior to returning an OK to the client, the server must send an
+      solicited FLAGS and <n> EXISTS response to the client giving the
+      flags list for this mailbox (simply the system flags if this
+      mailbox doesn't have any special flags) and the number of messages
+      in the mailbox.  It is also recommended that the server send a <n>
+      RECENT unsolicited response to the client for the benefit of
+      clients which make use of the number of new messages in a mailbox.
+      It is further recommended that servers should send an unsolicited
+      READONLY message if the mailbox that has been selected is not
+
+
+
+Rice                                                           [Page 16]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      writable by the user.
+
+      Multiple SELECT commands are permitted in a session, in which case
+      the prior mailbox is deselected first.
+
+      The default mailbox for the SELECT command is INBOX, which is a
+      special name reserved to mean "the primary mailbox for this user
+      on this server".  The format of other mailbox names is operating
+      system dependent (as of this writing, it reflects the path of the
+      mailbox on the current servers), though it could reflect any
+      server-specific naming convention for the namespace of mailboxes.
+      Such a namespace need not and should not be viewed as being
+      equivalent or linked to the server machine's file system.
+
+      EXAMPLES: A002 SELECT INBOX  ;; selects the default mailbox.
+                A002 197 EXISTS    ;; server says 197 messages in INBOX
+                A002 5 RECENT      ;; server says 5 are recent.
+                A002 OK Select complete.
+      or
+                A003 SELECT /usr/fred/my-mail.txt
+                 ;; select a different user specified mailbox.
+                ...
+
+   tag CHECK
+
+      The CHECK command forces a check for new messages and a rescan of
+      the mailbox for internal change for those implementations which
+      allow multiple simultaneous read/write access to the same mailbox
+      (e.g., TOPS-20).  It is recommend that periodic implicit checks
+      for new mail be done by servers as well.  The server must send a
+      solicited <n> EXISTS response prior to returning an OK to the
+      client.
+
+   tag EXPUNGE
+
+      The EXPUNGE command permanently removes all messages with the
+      \DELETED flag set in its flags from the mailbox.  Prior to
+      returning an OK to the client, for each message which is removed,
+      a solicited <n> EXPUNGE response is sent indicating which message
+      was removed.  The message number of each subsequent message in the
+      mailbox is immediately decremented by 1; this means that if the
+      last 5 messages in a 9-message mailbox are expunged you will
+      receive 5 "5 EXPUNGE" responses for message 5.  To ensure mailbox
+      integrity and server/client synchronization, it is recommended
+      that the server do an implicit check prior to commencing the
+      expunge and again when the expunge is completed.  Furthermore, if
+      the server allows multiple simultaneous access to the same mailbox
+      the server must guarantee both the integrity of the mailbox and
+
+
+
+Rice                                                           [Page 17]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      the views of it held by the clients.
+
+      EXPUNGE is not allowed if the user does not have write access to
+      this mailbox.  If a user does not have write access to the mailbox
+      then the server is required to signal this fact by replying with a
+      NO response with a suitable text string that can be presented to
+      the user explaining that the mailbox is read-only.  It is further
+      recommended that servers send an unsolicited READONLY message to
+      clients that attempt an expunge operation on a read only mailbox.
+
+   tag COPY sequence mailbox
+
+      The COPY command copies the specified message(s) to the specified
+      destination mailbox.  If the destination mailbox does not exist,
+      the server should create it.  Prior to returning an OK to the
+      client, the server must return a solicited <n> COPY response for
+      each message copied.
+
+      EXAMPLE: A003 COPY 2:4 MEETING copies messages 2, 3, and 4 to
+      mailbox "MEETING".
+
+      COPY is not allowed if the user does not have write access to the
+      destination mailbox.  If a user does not have write access to the
+      destination mailbox then the server is required to signal this
+      fact by replying with a NO response with a suitable text string
+      that can be presented to the user explaining that the mailbox is
+      read-only.  It is further recommended that servers send an
+      unsolicited READONLY message to clients that attempt to copy to a
+      read only mailbox.  IMAP3 does not specify "where" the message
+      will be put in the mailbox to which it has been copied.
+
+   tag FETCH sequence fetch_att
+
+      The FETCH command retrieves data associated with a message in the
+      mailbox.  The data items to be fetched may be either a single atom
+      or an S-expression list.  The attributes that can be fetched are
+      any of those mentioned specifically below along with any generic,
+      canonical or concrete key.  The set of predefined generic keys is:
+      {BCC, BODY, CC, FROM, HEADER, SIZE, SUBJECT, TEXT, TO}.  The set
+      of predefined canonical keys is {$CC, $FROM, $SUBJECT, $TO}.  The
+      value returned by the server for a non-existent or non-meaningful
+      key is defined to be the null value, NIL.
+
+      ALL             Equivalent to:
+                      (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
+
+      ENVELOPE        The envelope of the message.  The envelope is
+                      computed by the server by parsing the header,
+
+
+
+Rice                                                           [Page 18]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+                      i.e., the RFC 822 header for an RFC822 format
+                      message, into the component parts, defaulting
+                      various fields as necessary.
+
+      FAST            Macro equivalent to:
+                      (FLAGS INTERNALDATE RFC822.SIZE)
+
+      FLAGS           The flags which are set for this message.
+                      This may include the following system flags:
+
+                              \RECENT    Message arrived since
+                                          last read of this mailbox
+                              \SEEN      Message has been read
+                              \ANSWERED  Message has been answered
+                              \FLAGGED   Message is "flagged" for
+                                          urgent/special attention
+                              \DELETED   Message is "deleted" for
+                                          removal by later EXPUNGE
+
+      INTERNALDATE    The date and time the message was written to
+                      the mailbox.
+
+      RFC822          The message in RFC 822 format.
+
+      RFC822.HEADER   The RFC 822 format header of the message.
+
+      RFC822.SIZE     The number of characters in the message as
+                      expressed in RFC 822 format.
+
+      RFC822.TEXT     The text body of the message, omitting the
+                      RFC 822 header.
+
+      EXAMPLES:
+
+      A003 FETCH 2:4 ALL
+         fetches the flags, internal date, RFC 822 size, and envelope
+         for messages 2, 3, and 4.
+
+      A004 FETCH 3 RFC822
+         fetches the RFC 822 representation for message 3.
+
+      A005 FETCH 4 (FLAGS RFC822.HEADER)
+         fetches the flags and RFC 822 format header for message 4.
+
+      A006 FETCH 42 $SUBJECT
+      A006 FETCH $SUBJECT "Some subject text..."
+      A006 OK FETCH completed ok.
+         fetches the canonical subject field.
+
+
+
+Rice                                                           [Page 19]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      A007 FETCH 42 APPARENTLY-TO
+      A007 FETCH APPARENTLY-TO NIL
+      A007 OK FETCH found no value.
+         fetches the concrete apparently-to field.
+
+   tag STORE sequence data value
+
+      The STORE command alters the values associated with particular
+      keys for a message in the mailbox.  As is the case for the FETCH
+      command, any generic, canonical or concrete key may be used to
+      index the value provided.  In addition to these, the following
+      pre-defined keys are provided.
+
+   FLAGS           Replace the flags for the message with the
+                   argument (in flag list format).
+                  The server must respond with a solicited STORE FLAGS
+                  message, showing the new state of the flags after
+                  the store.
+
+   +FLAGS          Add the flags in the argument to the
+                   message's flag list.
+                 The server must respond with a solicited STORE FLAGS
+                 message, showing the new state of the flags after
+                 the store.
+
+  -FLAGS          Remove the flags in the argument from the
+                  message's flag list.
+                 The server must respond with a solicited STORE FLAGS
+                 message, showing the new state of the flags after
+                 the store.
+
+  RFC822.HEADER   Replace the header of the message(s) with that
+                  specified.  This allows users to use their mailboxes
+                  as databases with header fields as keys.
+                  The server must respond with solicited
+                  STORE RFC822.HEADER, STORE RFC822.SIZE and
+                  STORE ENVELOPE messages,  showing the new state
+                  of the reparsed header after the store.
+
+  RFC822.TEXT     Replace the body of the messages with that specified.
+                  The server must respond with solicited
+                  STORE RFC822.TEXT and STORE RFC822.SIZE messages,
+                  showing the new state of the message after the store.
+
+         STORE is not allowed if the user does not have write access to
+         this mailbox.
+
+         The server is required to send a solicited STORE response for
+
+
+
+Rice                                                           [Page 20]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+         each store operation that results in a format transformation by
+         the server.  For example, the server is required to send a
+         STORE FLAGS response when the client performs a STORE +FLAGS or
+         a STORE -FLAGS, since the client may not easily be able to know
+         what the result of this command will be.  Similarly, if the
+         client emits a STORE FROM command then the server should
+         respond with a suitable STORE FROM response because the client
+         would be sending a string value to be stored and the server
+         should transform this into a set of addresses.  In general,
+         however, although it is legal for the server to send a
+         solicited STORE response for each STORE operation, this is
+         discouraged, since it might result in the retransmission of
+         very large and unnecessary amounts of data that have been
+         stored.
+
+         EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) marks messages 2, 3,
+         and 4 for deletion.
+
+   tag SEARCH search_criteria
+
+      The SEARCH command searches the mailbox for messages which match
+      the given set of criteria.  The server response SEARCH (criteria)
+      (numbers) gives the set of messages which match the conjunction of
+      the criteria specified.  In addition to each of the search
+      criteria there is its logical inverse.  The logical inverse
+      criterion is denoted by the ~ (tilda) sign.
+
+      Thus, no message that matches the criterion:
+         FROM crispin
+
+      will match the criterion:
+         ~FROM crispin
+
+      The criteria for the search can be any generic, canonical or
+      concrete key.  In addition to these, the following pre-defined
+      keys are also provided:
+
+      ALL             All messages in the mailbox; the default
+                      initial criterion for ANDing.
+
+      ANSWERED        Messages with the \ANSWERED flag set.
+
+      BCC string      Messages which contain the specified string
+                      in the envelope's BCC field.
+
+      BEFORE date     Messages whose internal date is earlier than
+                      the specified date.
+
+
+
+
+Rice                                                           [Page 21]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      BODY string     Messages which contain the specified string
+                      in the body of the message.
+
+      CC string       Messages which contain the specified string
+                      in the envelope's CC field.
+
+      DELETED         Messages with the \DELETED flag set.
+
+      FLAGGED         Messages with the \FLAGGED flag set.
+
+      FROM string     Messages which contain the specified string
+                      in the envelope's FROM field.
+
+      HEADER string   Messages which contain the specified string
+                      in the message header.
+
+      KEYWORD flag    Messages with the specified flag set.
+
+      NEW             Messages which have the \RECENT flag set but
+                      not the \SEEN flag.  This is functionally
+                      equivalent to "RECENT UNSEEN".
+
+      OLD             Messages which do not have the \RECENT flag
+                      set.
+
+      ON date         Messages whose internal date is the same as
+                      the specified date.
+
+      RECENT          Messages which have the \RECENT flag set.
+
+      SEEN            Messages which have the \SEEN flag set.
+
+      SINCE date      Messages whose internal date is later than
+                      the specified date.
+
+      SUBJECT string  Messages which contain the specified string
+                      in the envelope's SUBJECT field.
+
+      TEXT string     Messages which contain the specified string.
+
+      TO string       Messages which contain the specified string in
+                      the envelope's TO field.
+
+         EXAMPLE:  A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
+         returns the message numbers for all deleted messages from Smith
+         that were placed in the mailbox since October 1, 1987.
+
+      Implementation note:  The UNANSWERED, UNDELETED, UNFLAGGED,
+
+
+
+Rice                                                           [Page 22]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      UNKEYWORD and UNSEEN criteria, described below, are preserved in
+      IMAP3 for IMAP2 compatibility.  They are, however, considered
+      obsolete and new Client programs are encouraged to use the ~
+      notation for the logical inverses of search criteria with a view
+      to the dropping of this outmoded syntax in later versions.
+
+      UNANSWERED      Messages which do not have the \ANSWERED flag
+                      set.
+
+      UNDELETED       Messages which do not have the \DELETED flag
+                      set.
+
+      UNFLAGGED       Messages which do not have the \FLAGGED flag
+                      set.
+
+      UNKEYWORD flag  Messages which do not have the specified flag
+                      set.
+
+      UNSEEN          Messages which do not have the \SEEN flag set.
+
+   tag READONLY
+
+      The READONLY command indicates that the client wishes to make the
+      mailbox read-only.  The server is required to reply with a
+      solicited READONLY or READWRITE response.
+
+   tag READWRITE
+
+      The READWRITE command indicates that the client wishes to make the
+      mailbox read-write.  The server is required to reply with a
+      solicited READONLY or READWRITE response.
+
+   tag SUPPORTED.VERSIONS
+
+      The SUPPORTED.VERSIONS solicits from the server a
+      SUPPORTED.VERSIONS message, which encapsulates information about
+      which versions and features the server supports.
+
+   tag SELECT.VERSION (major_version minor_version)
+
+      The SELECT.VERSION command indicates that the client wishes to
+      select certain behavior on the part of the server.  The major and
+      minor versions indicate the specific version of the protocol being
+      selected.
+
+      EXAMPLE: A002 SELECT.VERSION (3 0)
+
+      A client may not request a server version that is not supported by
+
+
+
+Rice                                                           [Page 23]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      the server, i.e., which is specifically mentioned in the response
+      to a SUPPORTED.VERSIONS command.  An attempt to do so by a client
+      will result in a NO response from the server.  It is an error for
+      the SELECT.VERSION command to be used after a mailbox has been
+      selected.  The rationale for this is that for some server
+      implementations it might be necessary to spawn separate programs
+      to implement widely divergent protocol versions.  Thus, the client
+      cannot be allowed to expect any server state to be preserved after
+      the use of the SELECT.VERSION command.  The default version of all
+      servers is 2.0, i.e., IMAP2 as defined by RFC 1064.
+
+   tag SELECT.FEATURES 1#features
+
+      The SELECT.FEATURES command indicates that the client wishes to
+      select certain specific features on the part of the server. A
+      client may not request a feature that is not supported by the
+      server, i.e., one that is explicitly mentioned in the set of
+      features for the selected version returned by the
+      SUPPORTED.VERSIONS command.  An attempt to do so by a client will
+      result in a NO response from the server.
+
+      EXAMPLE: A002 SELECT.FEATURES AUTO.SET.SEEN ~TAGGED.SOLICITED
+              EIGHT.BIT.TRANSPARENT
+
+      i.e., select the set of features called AUTO.SET.SEEN and
+      EIGHT.BIT.TRANSPARENT and deselect the feature called
+      TAGGED.SOLICITED.  The use of the SELECT.FEATURES command
+      completely resets the set of selected features.  Note:  These are
+      only example feature names and are not necessarily supported by
+      any server.  See the appendix on features for more information on
+      features.  Note:  Some features, when present in the server, will
+      cause the upwards compatible extension of the grammar, i.e., by
+      adding extra commands.  The server is at liberty not to remove
+      these upwards compatible extensions to the command tables when a
+      feature is disabled.  Thus, it is an error for a client to rely on
+      getting a NO or BAD response in any way, for instance to determine
+      the selectedness or presence of a feature.
+
+   tag BBOARD bboard
+
+      The BBOARD command is equivalent to SELECT, except that its
+      argument is a bulletin board (BBoard) name.  The format of a
+      BBoard name is implementation specific, although it is strongly
+      encouraged to use something that resembles a name in a generic
+      sense and not a file or mailbox name on the particular system.
+      There is no requirement that a BBoard name be a mailbox name or a
+      file name (in particular, Unix netnews has a completely different
+      namespace from mailbox or file names).
+
+
+
+Rice                                                           [Page 24]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      The result from the BBOARD command is identical from that of the
+      SELECT command.  For example, in the TOPS-20 server
+      implementation, the command
+         A0002 BBOARD FOO
+      is exactly equivalent to the command
+         A0002 SELECT POBOX:<BBOARD>FOO.TXT
+         Note: the equivalence in this example is *not* required by the
+         protocol, and merely reflects the fuzzy distinction between
+         mailboxes and BBoards on TOPS-20.
+
+   tag FIND (BBOARDS / MAILBOXES) pattern
+
+      The FIND command accepts as arguments the keywords BBOARDS or
+      MAILBOXES and a pattern which specifies some set of BBoard/mailbox
+      names which are usable by the BBOARD/SELECT command.  Two wildcard
+      characters are defined; "*" specifies that any number (including
+      zero) characters may match at this position and "%" specifies that
+      a single character may match at this position.  For example,
+      FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas
+      FOO%BAR will match only FOO.BAR; furthermore, "*" will match all
+      BBoards/mailboxes.  The following quoting convention applies to
+      wildcards: "\*" is the literal "*" character, "\%" is the literal
+      "%" character and "\\" is the literal "\" character.  Notes: The
+      format of mailboxes is server implementation dependent.  The
+      special mailbox name INBOX is not included in the output to the
+      FIND MAILBOXES command.
+
+      The FIND command solicits any number of BBOARD or MAILBOX
+      responses from the server as appropriate.
+
+      Examples:
+          A0002 FIND BBOARDS *
+          A0002 BBOARD FOOBAR
+          A0002 BBOARD GENERAL
+          A0002 OK FIND completed
+      or
+          A0002 FIND MAILBOXES FOO%BA*
+          A0002 MAILBOX FOO.BAR
+          A0002 MAILBOX FOO.BAZZAR
+          A0002 OK FIND completed
+
+      Note: Although the use of explicit file or path names for
+      mailboxes is discouraged by this standard, it may be unavoidable.
+      It is important that the value returned in the MAILBOX solicited
+      reply be usable in the SELECT command without remembering any path
+      specification which may have been used in the FIND MAILBOXES
+      pattern.
+
+
+
+
+Rice                                                           [Page 25]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   tag FLAGS
+
+      The FLAGS command solicits a FLAGS response from the server.
+
+   tag SET.FLAGS flag_list
+
+      The SET.FLAGS command defines the user specifiable flags for this
+      mailbox, i.e., the keywords.  If this set does not include flags
+      formerly sent to the client by the server in a FLAGS message then
+      this constitutes a request to delete the flag.  Any new flags
+      should be created.  This command does not affect the system
+      defined flags and any system flags that are included in the
+      flag_list will be ignored.  The server must respond to this
+      command with a solicited FLAGS message.  If the deletion of a flag
+      results in the invalidation of the flag sets of any messages then
+      the server is required to send solicited STORE FLAGS messages to
+      the client for each modified message.
+
+Responses:
+
+   */tag OK text
+
+      In its solicited form this response identifies successful
+      completion of the command with the indicated tag.  The text is a
+      line of human-readable text which may be useful in a protocol
+      telemetry log for debugging purposes.
+
+      In its unsolicited form, this response indicates simply that the
+      server is alive.  No special action on the part of the client is
+      called for.  This is presently only used by servers at startup as
+      a greeting message indicating that they are ready to accept the
+      first command.  This usage, although legal, is by no means
+      required.  The text is a line of human-readable text which may be
+      logged in protocol telemetry.
+
+   */tag NO text
+
+      In its solicited form this response identifies unsuccessful
+      completion of the command with the indicated tag.  The text is a
+      line of human-readable text which probably should be displayed to
+      the user in an error report by the client.
+
+      In its unsolicited form this response indicates some operational
+      error at the server which cannot be traced to any protocol
+      command.  The text is a line of human-readable text which should
+      be logged in protocol telemetry for the maintainer of the server
+      and/or the client.
+
+
+
+
+Rice                                                           [Page 26]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   */tag BAD text
+
+      In its solicited form response indicates faulty protocol received
+      from the client and indicates a bug.  The text is a line of
+      human-readable text which should be recorded in any telemetry as
+      part of a bug report to the maintainer of the client.
+
+      In its unsolicited form response indicates some protocol error at
+      the server which cannot be traced to any protocol command.  The
+      text is a line of human-readable text which should be logged in
+      protocol telemetry for the maintainer of the server and/or the
+      client.  This generally indicates a protocol synchronization
+      problem, and examination of the protocol telemetry is advised to
+      determine the cause of the problem.
+
+   */tag BYE text
+
+      This indicates that the server is about to close the connection.
+      The text is a line of human-readable text which should be
+      displayed to the user in a status report by the client.  IMAP2
+      requires that the server emit a solicited BYE response as part of
+      a normal logout sequence.  This solicited form is not required
+      under IMAP3, though is still legal for compatibility.  In its
+      unsolicited form the BYE response is used as a panic shutdown
+      announcement by the server.  It is required to be used by any
+      server which performs autologouts due to inactivity.
+
+   */tag number message_data
+
+      The solicited (tag number message_data) response is generated as
+      the result of a number of client requests.  The server may also
+      emit any the following at any time as unsolicited data (i.e., *
+      number message_data).  The message_data is one of the following:
+
+      EXISTS  The specified number of messages exists in the mailbox.
+
+      RECENT  The specified number of messages have arrived since the
+              last time this mailbox was selected with the SELECT
+              command or equivalent.
+
+      EXPUNGE The specified message number has been permanently
+              removed from the mailbox, and the next message in the
+              mailbox (if any) becomes that message number.
+             The server must send a solicited EXPUNGE response
+             for each message that it expunges as the result
+             of an EXPUNGE command.  Note: future versions of the
+             protocol may allow the use of a message sequence
+             as a value returned by the EXPUNGE response to allow the
+
+
+
+Rice                                                           [Page 27]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+             more efficient compaction of client representations of
+             mailboxes.
+
+      STORE data
+             Functionally equivalent to FETCH, only it is sent by the
+             server when the state of a mailbox changes.  The server
+             must send solicited STORE responses as the result of
+             any change caused by a STORE command.
+
+      FETCH data
+              This is the principle means by which data about a
+              message is sent to the client.  The data is in a
+              Lisp-like S-expression property list form.  Just as the
+              FETCH request from the client can fetch any generic,
+              canonical or concrete key, so also the FETCH response
+              can return values for any of these keys as well as for
+              the pre-defined attributes mentioned below.  Note that
+              the server is permitted to send any unsolicited FETCH
+              or STORE messages that it should choose, be they the
+              values associated with generic, canonical or concrete
+              keys.  Clients are required to ignore any such
+              FETCH responses that it cannot interpret.  For example,
+              clients are not required to be able to understand, i.e.,
+              use fruitfully, the canonical $TO key, but they are
+              required to be able to ignore an unsolicited $TO message
+              correctly.
+
+         ENVELOPE     An S-expression format list which describes the
+                      envelope of a message.  The envelope is computed
+                      by the server by parsing the RFC 822 header into
+                      the component parts, defaulting various fields
+                      as necessary.
+
+                      The fields of the envelope are in the following
+                      order: date, subject, from, sender, reply-to, to,
+                      cc, bcc, in-reply-to, and message-id.  The date,
+                      subject, in-reply-to, and message-id fields are
+                      strings.  The from, sender, reply-to, to, cc,
+                      and bcc fields are lists of addresses.
+
+                      An address is an S-expression format list which
+                      describes an electronic mail address.  The fields
+                      of an address are in the following order:
+                      personal name, source-route (i.e., the
+                      at-domain-list in SMTP), mailbox name, host name
+                      and comments.  Implementation note:  The addition
+                      of the comment field is an incompatible extension
+                      from IMAP2.  The server is required not to provide
+
+
+
+Rice                                                           [Page 28]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+                      this field when running in IMAP2 mode.
+
+                      Any field of an envelope or address which is
+                      not applicable is presented as the atom NIL.
+                      Note that the server must default the reply-to
+                      and sender fields from the from field; a client is
+                      not expected to know to do this.
+
+         FLAGS        An S-expression format list of flags which are set
+                      for this message.  This may include the following
+                      system flags:
+
+                      \RECENT       Message arrived since last
+                                     read of this mailbox
+                      \SEEN         Message has been read
+                      \ANSWERED     Message has been answered
+                      \FLAGGED      Message is "flagged" for
+                                     urgent/special attention
+                      \DELETED      Message is "deleted" for
+                                     removal by later EXPUNGE
+
+         INTERNALDATE  A string containing the date and time the
+                       message was written to the mailbox.
+
+         RFC822        A string expressing the message in RFC 822
+                       format.
+                      Note: Some implementations of IMAP2 servers
+                      had the (undocumented) behavior of setting
+                      the \SEEN flag as a side effect of fetching
+                      the body of a message.  This resulted in
+                      erroneous behavior for clients that prefetch
+                      messages that the user might not get
+                      around to reading.  Thus, this behavior is
+                      explicitly disallowed in IMAP3.
+                      Note: this is not a significant performance
+                      restriction because it is always possible for
+                      IMAP3 clients to use an interaction with the
+                      server of the following type:
+                      A001 FETCH 42 RFC822
+                      A002 STORE 42 +FLAGS (\SEEN)
+                      A001 42 FETCH RFC822 {637} ......
+                      A001 OK Fetch completed
+                      A002 42 STORE FLAGS (\SEEN \FLAGGED...)
+                      A002 OK Store Completed.
+
+         RFC822.HEADER A string expressing the RFC 822 format
+                       header of the message
+
+
+
+
+Rice                                                           [Page 29]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+         RFC822.SIZE   A number indicating the number of
+                       characters in the message as expressed
+                       in RFC 822 format.
+
+         RFC822.TEXT   A string expressing the text body of the
+                       message, omitting the RFC 822 header.
+                      See also note for RFC822.
+
+   */tag FLAGS flag_list
+
+      A solicited FLAGS response must occur as a result of a SELECT
+      command.  The flag list is the list of flags (at a minimum, the
+      IMAP defined flags) which are applicable for this mailbox.  Flags
+      other than the system flags are a function of the server
+      implementation.
+
+   */tag SEARCH (numbers) (search_criteria)
+
+      This response occurs as a result of a SEARCH command.  The
+      number(s) refer to those messages which match the search criteria.
+      In its solicited form this message allows clients to find
+      interesting groups of messages, e.g., unseen messages from
+      Crispin.  In its unsolicited form it allows the server to inform
+      the client of interesting patterns, e.g., when new mail arrives,
+      recent and from Crispin.  Compatibility note:  The search_criteria
+      are sent by the server along with the matching numbers so
+      unsolicited SEARCH messages may be interpreted.  This syntax is
+      not upwards compatible with IMAP2 and so the new syntax is
+      intended to make it simple for clients that are not able to take
+      advantage of unsolicited SEARCH messages still to interpret
+      solicited SEARCH messages simply by ignoring everything that
+      follows the list of numbers with minimal parsing.  Such clients
+      may not, however, simply discard the rest of the line because
+      there might be LITERALs in the search pattern.
+
+      Examples:
+         A00042 SEARCH (2 3 6) (FROM Crispin ~SEEN)
+      and
+         * SEARCH (42) (FROM Crispin RECENT)
+
+   */tag READONLY
+
+      This indicates that the mailbox is read-only.  The server is
+      required to respond to a READONLY or READWRITE command with either
+      a solicited READONLY or a solicited READWRITE response.  Note:  If
+      the client attempts a mutation operation, such as STORE, on a
+      mailbox to which it does not have write access then the server is
+      required to reply with a solicited READONLY response on the first
+
+
+
+Rice                                                           [Page 30]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      such attempted mutation.  The server may also choose to send
+      solicited READONLY responses for each subsequent attempted
+      mutation.
+
+   */tag READWRITE
+
+      This indicates that the mailbox is read-write.  The server is
+      required to respond to a READONLY or READWRITE command with either
+      a solicited READONLY or a solicited READWRITE response.
+
+   */tag BBOARD bboard_name
+
+      This message is produced in its solicited form as a response to a
+      FIND BBOARDS command.  In its unsolicited form it represents a
+      notification by the server that a new BBoard has been added.
+      Bboard_name must be a name that can be supplied to the BBOARD
+      command so as to select the appropriate bboard.
+
+   */tag MAILBOX non_inbox_mailbox_name
+
+      This message is produced in its solicited form as a response to a
+      FIND MAILBOXES command.  In its unsolicited form it represents a
+      notification by the server that a new mailbox has been added,
+      perhaps as the result of a COPY command creating a new mailbox.
+      Non_inbox_mailbox_name must be a name that can be supplied to the
+      SELECT command so as to select the appropriate mailbox.  Note:
+      non_inbox_mailbox_name is never the string "INBOX".
+
+   */tag SUPPORTED.VERSIONS (version_specs)
+
+      This message is used either as a response to the
+      SUPPORTED.VERSIONS or, in its unsolicited form, to indicate the
+      dynamic addition or removal of support for features or protocol
+      versions.  Each version_spec is of the form (4 2
+      EIGHT.BIT.TRANSPARENT AUTO.SET.SEEN ...), i.e., a major version
+      number and a minor version number for the protocol and the set of
+      features supported under the server's implementation of that
+      protocol version.  A server may not dynamically remove support for
+      any version or feature that has been selected by any currently
+      logged in client by the use of the VERSION command.
+
+      Example:
+        A00005 SUPPORTED.VERSIONS ((2 0 )
+              (2 2 TAGGED.SOLICITED)
+              (3 0 EIGHT.BIT.TRANSPARENT TAGGED.SOLICITED))
+
+      Indicates that two major versions are supported and one minor
+      version is supported and that tagged solicited messages are
+
+
+
+Rice                                                           [Page 31]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      supported in versions 2.2 and 3.0 with eight bit characters being
+      supported under version 3.  For each feature mentioned in the list
+      of features there is also always the negation of that feature.
+      For example, if the server supports the TAGGED.SOLICITED feature
+      then it also supports the ~TAGGED.SOLICITED feature, which
+      disables this feature.  Note:  These are only example feature
+      names and are not necessarily supported by any server.  See the
+      appendix on features for more information on features.
+
+   + text
+
+      This response indicates that the server is ready to accept the
+      text of a literal from the client.  Normally, a command from the
+      client is a single text line.  If the server detects an error in
+      the command, it can simply discard the remainder of the line.  It
+      cannot do this in the case of commands which contain literals,
+      since a literal can be an arbitrarily long amount of text, and the
+      server may not even be expecting a literal.  This mechanism is
+      provided so the client knows not to send a literal until the
+      server definitely expects it, preserving client/server
+      synchronization.
+
+      In actual practice, this situation is rarely encountered.  In the
+      current protocol, the only client commands likely to contain
+      literals are the LOGIN command and the STORE RFC822.HEADER or
+      STORE RFC822.TEXT commands.  Consider a situation in which a
+      server validates the user before checking the password.  If the
+      password contains "funny" characters and hence is sent as a
+      literal, then if the user is invalid an error would occur before
+      the password is parsed.
+
+      No such synchronization protection is provided for literals sent
+      from the server to the client, for performance reasons.  Any
+      synchronization problems in this direction would be due to a bug
+      in the client or server and not for some operational problem.
+
+Sample IMAP3 session
+
+   The following is a transcript of an actual IMAP3 session.  Server
+   output is identified by "S:" and client output by "U:".  In cases
+   where lines were too long to fit within the boundaries of this
+   document, the line was continued on the next line preceded by a tab.
+
+   S:     * OK SUMEX-AIM.Stanford.EDU Interactive Mail Access Protocol
+                  III Service 6.1(349) at Mon, 14 May 90 14:58:30 PDT
+   U:     a001 SUPPORTED.VERSIONS
+   S:     * SUPPORTED.VERSIONS ((2 0 ) (3 0 EIGHT.BIT.TRANSPARENT
+                     AUTO.SET.SEEN TAGGED.SOLICITED))
+
+
+
+Rice                                                           [Page 32]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   S:     A001 Supported Versions returned.
+   U:     a002 SELECT.VERSION (3 0)
+   S:     a002 OK Version 3.0 Selected.
+   U:     a003 SELECT.FEATURES TAGGED.SOLICITED
+   S:     a003 OK Features selected.
+   U:     a004 login crispin secret
+   S:     a004 OK User CRISPIN logged in at Thu, 9 Jun 90 14:58:42 PDT,
+                  job 76
+   U:     a005 select inbox
+   S:     a005 FLAGS (Bugs SF Party Skating Meeting Flames Request AI
+                  Question Note \XXXX \YYYY \Answered \Flagged \Deleted
+                  \Seen)
+   S:     a005 16 EXISTS
+   S:     a005 0 RECENT
+   S:     a006 OK Select complete
+   U:     a006 fetch 16 all
+   S:     a006 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:
+              RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
+              "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
+              "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN"
+              "SUMEX-AIM.Stanford.EDU" NIL)) (("Larry Fagan" NIL "FAGAN"
+              "SUMEX-AIM.Stanford.EDU" NIL)) ((NIL NIL "rindflEISCH"
+              "SUMEX-AIM.Stanford.EDU" NIL)) NIL NIL NIL
+              "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
+   S:  a006 OK Fetch completed
+   U:  a007 fetch 16 rfc822
+   S:  a007 16 Fetch (RFC822 {637}
+   S:  Mail-From: RINDFLEISCH created at  9-Jun-88 12:55:43
+   S:  Mail-From: FAGAN created at  4-Jun-88 13:27:12
+   S:  Date: Sat, 4 Jun 88 13:27:11 PDT
+   S:  From: Larry Fagan  <FAGAN@SUMEX-AIM.Stanford.EDU>
+   S:  To: rindflEISCH@SUMEX-AIM.Stanford.EDU
+   S:  Subject: INFO-MAC Mail Message
+   S:  Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>
+   S:  ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT
+   S:  ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
+   S:  ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU,
+                  Crispin@SUMEX-AIM.Stanford.EDU
+   S:  ReSent-Message-ID:
+          <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
+   S:
+   S:  The file is <info-mac>usenetv4-55.arc  ...
+   S:  Larry
+   S:  -------
+   S:  )
+   S:  a007 OK Fetch completed
+   U:  a008 logout
+   S:  a008 BYE UNIX IMAP III server terminating connection
+
+
+
+Rice                                                           [Page 33]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   S:  a008 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
+                  Service logout
+
+Implementation Discussion
+
+   As of this writing, SUMEX has completed an IMAP2 client for Xerox
+   Lisp machines written in hybrid Interlisp/CommonLisp and is beginning
+   distribution of a client for TI Explorer Lisp machines.  SUMEX has
+   also completed a portable IMAP2 client protocol library module
+   written in C.  This library, with the addition of a small main
+   program (primarily user interface) and a TCP/IP driver, became a
+   rudimentary remote system mail-reading program under Unix.  The first
+   production use of this library is as a part of a MacII client which
+   has now been under daily use (by real users) at Stanford for quite
+   some time.
+
+   As of this writing, SUMEX has completed IMAP2 servers for TOPS-20
+   written in DEC-20 assembly language and 4.2/3 BSD Unix written in C.
+   The TOPS-20 server is fully compatible with MM-20, the standard
+   TOPS-20 mailsystem, and requires no special action or setup on the
+   part of the user.  The INBOX under TOPS-20 is the user's MAIL.TXT.
+   The TOPS-20 server also supports multiple simultaneous access to the
+   same mailbox, including simultaneous access between the IMAP3 server
+   and MM-20.  The 4.2/3 BSD Unix server requires that the user use
+   either Unix Mail format or mail.txt format which is compatible with
+   SRI MM-32 or Columbia MM-C.  The 4.2/3 BSD Unix server allows
+   simultaneous read access; write access must be exclusive.  There is
+   also an experimental IMAP3 server running on the TI Explorer class of
+   machine, which uses MM mailbox format and which can communicate over
+   both TCP and Chaos.
+
+   The Xerox Lisp client and DEC-20 server have been in production use
+   for over two years; the Unix server was been in production use for
+   over a year.  IMAP3 has been used to access mailboxes at remote sites
+   from a local workstation via the Internet.  For example, from the
+   Stanford local network one of the authors has read his mailbox at a
+   Milnet site.
+
+   A number of IMAP clients have now been developed or are being
+   developed.  Amongst these are versions that run on the following
+   machines:
+
+    . Xerox Lisp machines
+    . Apple Macintosh
+    . NeXT
+    . IBM PC
+    . TI Explorer Lisp machines
+    . "Glass teletype" version that runs under Unix
+
+
+
+Rice                                                           [Page 34]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+    . GNU Emacs
+    . X Windows
+    . NTT ELIS
+
+   Each of these client programs is carefully tuned to optimize the
+   performance and user interface in a manner that is consistent with
+   the the user interface model of the native machine.  For example, the
+   Macintosh client features a "messy-desk" interface that allows the
+   cutting and pasting of text with the use of the clipboard with a menu
+   driven interface with keyboard accelerators.
+
+   This specification does not make any formal definition of size
+   restrictions, but some of the existing servers have the following
+   limitations:
+
+   DEC-20
+    . length of a mailbox: 7,077,888 characters
+    . maximum number of messages: 18,432 messages
+    . length of a command line: 10,000 characters
+    . length of the local host name: 64 characters
+    . length of a "short" argument: 39 characters
+    . length of a "long" argument: 491,520 characters
+    . maximum amount of data output in a single fetch:
+      655,360 characters
+
+   TI-Explorer
+    . length of a mailbox: limited by the Minimum of the size of the
+      virtual address space and the size of the file system
+    . maximum number of messages: limited by the the size of the
+      virtual address space
+    . length of a command line: limited by the the size of the
+      virtual address space
+    . length of the local host name: limited by the the size of the
+      virtual address space
+    . length of a "short" argument: limited by the the size of the
+      virtual address space
+    . length of a "long" argument: limited by the the size of the
+      virtual address space
+    . maximum amount of data output in a single fetch: not limited
+
+   Typical values for these limits are 30Mb for file systems and 128Mb
+   for virtual address space.
+
+   To date, nobody has run up against any of these limitations, many of
+   which are substantially larger than most current user mail reading
+   programs.
+
+   There are several advantages to the scheme of tags and solicited
+
+
+
+Rice                                                           [Page 35]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   responses and unsolicited data.  First, the infamous synchronization
+   problems of SMTP and similar protocols do not happen with tagged
+   commands; a command is not considered satisfied until a completion
+   acknowledgement with the same tag is seen.  Tagging allows an
+   arbitrary amount of other responses ("solicited" data) to be sent by
+   the server with no possibility of the client losing synchronization.
+   Compare this with the problems that FTP or SMTP clients have with
+   continuation, partial completion, and commentary reply codes.
+
+   Another advantage is that a non-lockstep client implementation is
+   possible.  The client could send a command, and entrust the handling
+   of the server responses to a different process which would signal the
+   client when the tagged response comes in.  Some clients might be
+   implemented in a thoroughly asynchronous manner, having, perhaps,
+   multiple outstanding commands at any given time.  Note:  this does
+   not require that the server process these commands in anything other
+   than a lock-step manner.  It simply allows clients to take advantage
+   of servers that are able to do such asynchronous operations.
+
+   It was observed that synchronization problems can occur with literals
+   if the literal is not recognized as such.  Fortunately, the cases in
+   which this can happen are relatively rare; a mechanism (the special
+   "+" tag response) was introduced to handle those few cases which
+   could happen.  The proper way to address this problem in all cases is
+   probably to move towards a record-oriented architecture instead of
+   the text stream model provided by TCP.
+
+   Unsolicited data needs some discussion.  Unlike most protocols, in
+   which the server merely does the client's bidding, an IMAP3 server
+   has a semi-autonomous role.  By means of sending "unsolicited data",
+   the server is in effect sending a command to the client -- to update
+   and/or extend its (incomplete) model of the mailbox with new
+   information from the server.  In this viewpoint, although a "fetch"
+   command is a request for specific information from the client, the
+   server is always at liberty to include more than the desired data as
+   "unsolicited".  A server acknowledgement to the "fetch" is a
+   statement that at least all the requested data has been sent.
+
+   In terms of implementation, a simple lock-step client may have a
+   local cache of data from the mailbox.  This cache is incomplete in
+   general, and at select time is empty.  A listener on the IMAP
+   connection in the client processes all solicited and unsolicited data
+   symmetrically, and updates the cache based on this data, i.e., the
+   client faults on a cache miss and asks the server to fill that cache
+   slot synchronously.  If a tagged completion response arrives, the
+   listener unblocks the process which sent the tagged request.
+
+   Clearly, given this model it is not strictly necessary to distinguish
+
+
+
+Rice                                                           [Page 36]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   most solicited from unsolicited data.  Doing so, however, apart from
+   being clearer, also allows such simplistic, lock-step client
+   implementations that extract the specific value of the response to
+   command by trapping the tagged response.  This allows the client not
+   to have to block on some complex predicate that involves watching to
+   see an update in a cache cell.
+
+   For example, perhaps as a result of opening a mailbox, solicited data
+   from the server arrives.  The first piece of data is the number of
+   messages.  This is used to size the cache; note that, if new mail
+   arrives, by sending a new "number of messages" unsolicited data
+   message server will cause the cache to be re-sized.  If the client
+   attempts to access information from the cache, it will encounter
+   empty spots which will trigger "fetch" requests.  The request would
+   be sent, some solicited data including the answer to the fetch will
+   flow back, and then the "fetch" response will unblock the client.
+
+   People familiar with demand-paged virtual memory design will
+   recognize this model as being very similar to page-fault handling on
+   a demand-paged system.
+
+Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in RFC 822 with one exception; the
+   delimiter used with the "#" construct is a single space (SP) and not
+   a comma.
+
+address         ::= "(" addr_name SP addr_adl SP addr_mailbox SP
+                    addr_host addr_comment ")"
+
+addr_adl        ::= nil / string
+
+addr_comment    ::= nil / string
+
+addr_host       ::= nil / string
+
+addr_mailbox    ::= nil / string
+
+addr_name       ::= nil / string
+
+bboard          ::= "BBOARD" SP bboard_name
+
+bboard_name     ::= string
+
+bboard_notify   ::= "BBOARD" sp bboard_name
+
+canonical_key   ::= "$CC" /  "$FROM" / "$SUBJECT" / "$TO"
+
+
+
+Rice                                                           [Page 37]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+check           ::= "CHECK"
+
+concrete_key    ::= string
+
+copy            ::= "COPY" SP sequence SP mailbox
+
+criterion       ::= "ALL" / "ANSWERED" /
+                    "BCC" SP string / "BEFORE" SP string /
+                    "BODY" SP string / "CC" SP string / "DELETED" /
+                    "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
+                    "ON" SP string / "RECENT" / "SEEN" /
+                    "SINCE" SP string / "TEXT" SP string /
+                    "TO" SP string / "UNANSWERED" / "UNDELETED" /
+                    "UNFLAGGED" / "UNKEYWORD" / "UNSEEN" / key SP string
+
+criteria        ::= 1#criterion
+
+data            ::= ("FLAGS" SP flag_list /
+                  search_notify / bboard_notify / mailbox_notify /
+                  supported_versions_notify / "READONLY" / "READWRITE" /
+                    "BYE" SP text_line / "OK" SP text_line /
+                    "NO" SP text_line / "BAD" SP text_line)
+
+date            ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
+
+envelope        ::= "(" env_date SP env_subject SP env_from SP
+                    env_sender SP env_reply-to SP env_to SP
+                    env_cc SP env_bcc SP env_in-reply-to SP
+                    env_message-id ")"
+
+env_bcc         ::= nil / "(" 1*address ")"
+
+env_cc          ::= nil / "(" 1*address ")"
+
+env_date        ::= string
+
+env_from        ::= nil / "(" 1*address ")"
+
+env_in-reply-to ::= nil / string
+
+env_length      ::= NUMBER
+
+env_message-id  ::= nil / string
+
+env_reply-to    ::= nil / "(" 1*address ")"
+
+env_sender      ::= nil / "(" 1*address ")"
+
+
+
+
+Rice                                                           [Page 38]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+env_subject     ::= nil / string
+
+env_to          ::= nil / "(" 1*address ")"
+
+expunge         ::= "EXPUNGE"
+
+feature         ::= ATOM
+
+fetch           ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
+                    fetch_att / "(" 1#fetch_att ")")
+
+fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
+                    "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
+                    "RFC822.TEXT" / key
+
+find            ::= "FIND" ("BBOARDS" / "MAILBOXES") pattern
+
+flag_list       ::= ATOM / "(" 1#ATOM ")"
+
+flags           ::= "FLAGS"
+
+generic_key     ::= "BCC" / "BODY" / "CC" / "FROM" / "HEADER" / "SIZE" /
+                    "SUBJECT" / "TEXT" / "TO"
+
+key             ::= generic_key / canonical_key / concrete_key
+
+literal         ::= "{" NUMBER "}" CRLF ASCII-STRING
+
+login           ::= "LOGIN" SP userid SP password
+
+logout          ::= "LOGOUT"
+
+mailbox         ::= "INBOX" / string
+
+mailbox_notify ::= MAILBOX non_inbox_mailbox_name
+
+msg_copy        ::= "COPY"
+
+msg_data        ::= (msg_exists / msg_recent / msg_expunge /
+                    msg_fetch / msg_copy)
+
+msg_exists      ::= "EXISTS"
+
+msg_expunge     ::= "EXPUNGE"
+
+msg_fetch       ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP
+                     env_length envelope / "FLAGS" SP "(" 1#(recent_flag
+                     flag_list) ")" / "INTERNALDATE" SP date /
+
+
+
+Rice                                                           [Page 39]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+                     "RFC822" SP string / "RFC822.HEADER" SP string /
+                     "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
+                     string / key SP string_list) ")"
+
+msg_recent      ::= "RECENT"
+
+msg_num         ::= NUMBER
+
+nil             ::= "NIL"
+
+non_inbox_mailbox_name ::= string
+
+noop            ::= "NOOP"
+
+numbers         ::= 1#NUMBER
+
+password        ::= string
+
+pattern         ::= string
+
+recent_flag     ::= "\RECENT"
+
+read_only       ::= "READONLY"
+
+read_write      ::= "READWRITE"
+
+ready           ::= "+" SP text_line
+
+request         ::= tag SP (noop / login / logout / select / check /
+                    expunge / copy / fetch / store / search /
+                    select_version / select_features /
+                    supported_versions / bboard / find /
+                    read_only / read_write / flags / set_flags ) CRLF
+
+response        ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF
+
+search          ::= "SEARCH" SP criteria
+
+search_notify   ::= "SEARCH" SP (numbers) SP (criteria)
+
+select          ::= "SELECT" SP mailbox
+
+select_features ::= "SELECT.FEATURES" 1#feature
+
+select_version  ::= "SELECT.VERSION" SP "(" NUMBER SP NUMBER ")"
+
+sequence        ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
+                    sequence)
+
+
+
+Rice                                                           [Page 40]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+set_flags       ::= "SET.FLAGS" SP flag_list
+
+solicited       ::= tag SP (msg_num SP msg_data / data /
+                            solicited_only) CRLF
+
+solicited_only  ::=                {None currently defined}
+
+store           ::= "STORE" SP sequence SP store_att
+
+store_att       ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
+                    "FLAGS" SP flag_list / RFC822.TEXT SP string
+                    / RFC822.HEADER SP string / key SP string)
+
+string          ::= atom / """" 1*character """" / literal
+
+string_list     ::= string / ("(" 1#string ")")
+
+supported_versions ::= "SUPPORTED.VERSIONS"
+
+supported_versions_notify ::= "SUPPORTED.VERSIONS" "(" 1#version_spec
+                              ")"
+
+system_flags    ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
+                    "\SEEN"
+
+tag             ::= atom
+
+unsolicited     ::= "*" SP (msg_num SP msg_data / data) CRLF
+
+userid          ::= string
+
+version_spec    ::= "(" NUMBER SP NUMBER SP 1#feature ")"
+
+Appendix: Features.
+
+   In this section we outline the standard features that are supported
+   by all IMAP3 servers and identify those features which are
+   recommended or experimental.  For each of these features the default
+   setting is specified.  This means that it is required of any server
+   that supports a given feature to make the default enabledness of that
+   feature as is specified below.  It is required that for each feature
+   supported by a server the inverse feature should also be supported.
+   The inverse feature name shall always be defined as the feature name
+   preceded by the "~" character.  Thus, the AUTO.SET.SEEN feature is
+   disabled by the ~AUTO.SET.SEEN feature.
+
+
+
+
+
+
+Rice                                                           [Page 41]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+   Required Features:
+
+   AUTO.SET.SEEN - When this features is enabled (default is disabled),
+        the \\SEEN flag is set for all appropriate messages as a side
+        effect of any of the following:
+            FETCH of RFC822
+            FETCH of RFC822.TEXT
+            COPY
+        Justification:  This feature is provided for the use of clients
+        that are unable to pipeline their commands effectively and
+        communicate over high latency connections.  When disabled,
+        the server will not perform any such side effects.  This feature
+        is also provided so as to smooth the transition from IMAP2 to
+        IMAP3.
+
+
+   TAGGED.SOLICITED - When this feature is enabled (default is enabled
+        for IMAP3, disabled for IMAP2 mode), solicited responses from
+        the server will have the tag specified by the client.
+        When this feature is disabled, solicited responses from the
+        server will have the IMAP2 compatible tag "*", not the
+        tag specified by the client.
+        Justification:  This feature is provided so as to smooth the
+        transition from IMAP2 to IMAP3.
+
+   Recommended Features.
+
+   EIGHT.BIT.TRANSPARENT - When this feature is enabled
+        (default is disabled), the server allows the transparent
+        transmission of eight bit characters.  When this feature is
+        disabled, the value of any bit other than the least significant
+        7 bits transmitted by the server is unspecified.  If this
+        feature is enabled, the characters that compose all command
+        keywords specified in the IMAP3 grammar and all feature names
+        use only their 7 least significant bits.
+        Justification:  This feature is provided for the purpose of
+        supporting national character sets within messages, encoded
+        languages such as Japanese Kanji characters and also of binary
+        data, such as programs, graphics and sound.
+
+
+   NEW.MAIL.NOTIFY - When this feature is enabled (default is
+        disabled for compatibility with the majority of existing
+        IMAP2 servers), the server will notify the client of the
+        arrival of new mail in the currently selected mailbox
+        using the appropriate RECENT and EXISTS unsolicited messages
+        without the client needing to send periodic CHECK commands.
+        Justification:  This feature is provided to allow clients to
+
+
+
+Rice                                                           [Page 42]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+        switch off any periodic polling strategy that they may use
+        to look for new mail.  Such polling unnecessarily uses bandwidth
+        and can cause the interactive performance to degrade because
+        the user can be kept waiting while some background process
+        is doing a CHECK.
+
+
+   SEND - When this feature is enabled (default is disabled) a new
+        "SEND" command becomes available to the client.  The SEND
+        command instructs the server to send a message, rather
+        than requiring the client to use its own, local message
+        sending capability, for example.  An example of of the
+        send command might be as follows:
+            tag42 SEND RFC822 {2083}
+            From: James Rice <Rice@Sumex-Aim.Stanford.Edu>
+            To:.....
+        If the server is unable to parse the message being sent then
+        it is required to issue a suitable NO notification to the client.
+        If the message cannot be delivered for some reason then the
+        server should send a suitable message to the FROM: address
+        of the message detailing the delivery failure.
+        When the SEND feature is enabled, the "send" production in
+        the grammar is added and as defined below.  The "send"
+        request is added to the list of requests in the request
+        production also as shown below:
+
+   message_format  ::= RFC822
+
+   request         ::= tag SP (noop / login / logout / select / check /
+                       expunge / copy / fetch / store / search /
+                       select_version / select_features /
+                       supported_versions / bboard / find /
+                       read_only / read_write / flags /
+                       set_flags / send) CRLF
+
+   send            ::= SEND SP message_format SP string
+
+        Justification:  This feature is provided so that mail can be
+        sent by the same reliable server that is used for the storage
+        of mail.  This has, amongst others, the following benefits:
+        - Single process clients need not be delayed by mail
+          transmission.
+        - Mail sent by the client will have the server named as the
+          message's sender.  This can be important because there are
+          a lot of mailers that erroneously cause reply mail to be
+          sent to the Sender, not the From or Reply-To address.  Since
+          the client in general is not listening for mail being sent
+          to it directly this can cause mail to be lost.
+
+
+
+Rice                                                           [Page 43]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+        - Clients can be written that do not have any native message
+          sending capability.
+
+
+   ADD.MESSAGE - When this feature is enabled (default is disabled)
+        a new "ADD.MESSAGE" command becomes available to the client.
+        The ADD.MESSAGE command instructs the server to add the
+        specified message to the designated mailbox.  This command
+        can be thought of as being like a COPY command except in
+        this case the message that is put in the designated mailbox
+        is specified as a string, rather than as a message number to
+        be copied from the currently selected mailbox.  An example
+        use of this command might be as follows:
+            tag42 ADD.MESSAGE OUTGOING-MAIL RFC822 {2083}
+            From: James Rice <Rice@Sumex-Aim.Stanford.Edu>
+            To:.....
+        This will have the effect of adding the message to the mailbox
+        called OUTGOING-MAIL.
+        If the server is unable to parse the message being added then
+        it is required to issue a suitable NO notification to the client.
+        When the ADD.MESSAGE feature is enabled, the "add_message"
+        production in the grammar is added and as defined below.
+        The "add_message" request is added to the list of requests
+        in the request production also as shown below:
+
+   add_message            ::= ADD.MESSAGE SP mailbox SP format SP string
+
+   message_format  ::= RFC822
+
+   request         ::= tag SP (noop / login / logout / select / check /
+                       expunge / copy / fetch / store / search /
+                       select_version / select_features /
+                       supported_versions / bboard / find /
+                       read_only / read_write / flags / set_flags /
+                       add_message) CRLF
+
+        Justification:  This feature is provided so that clients can
+        easily add mail to specific mailboxes.  This allows clients
+        to implement such behavior as outgoing mail storage (BCC)
+        without the need to resort to mailing to special BCC mailboxes.
+
+
+   RENUMBER - When this feature is enabled (default is disabled)
+        the RENUMBER command becomes available to the client.
+        The RENUMBER command will reorder the assignment of message
+        numbers to the messages in the mailbox.  If this results in a
+        change to the association of any message number with any
+        message then the server is required to send solicited RESET
+
+
+
+Rice                                                           [Page 44]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+        responses to the client.  The intent of this command is
+        to allow users to view mailboxes in user-meaningful order
+        efficiently.  While the client could do the ordering,
+        it would be less efficient in general.  Note that the
+        server may or may not change the actual storage of the
+        messages and the ordering may or may not remain in effect
+        after another mailbox is selected or the IMAP session is
+        terminated.  Informally, the syntax for the RENUMBER
+        command is:
+
+            tag RENUMBER field_name ordering_type
+
+        this has the effect of changing the IMAP grammar to be
+        as follows:
+
+   ordering_type   ::= DATE / NUMERIC / ALPHA
+
+   renumber        ::= RENUMBER SP field_name SP ordering_type
+
+   request         ::= tag SP (noop / login / logout / select / check /
+                       expunge / copy / fetch / store / search /
+                       select_version / select_features /
+                       supported_versions / bboard / find /
+                       read_only / read_write / flags / set_flags /
+                       renumber) CRLF
+
+        For example:
+         tag42 RENUMBER FROM ALPHA
+                         ;;;RENUMBER alphabetically by the from field
+         tag42 RESET 10:20,49
+                         ;;;Messages 10 to 20 and 49 have changed
+         tag42 OK RENUMBER finished.  Sequence has changed
+         tag43 FETCH ALL 10:20,49
+                         ;;;Client chooses to fetch the changed msgs.
+
+        To support this the RESET message is defined as follows:
+
+   */tag RESET message_sequence
+       This solicited of unsolicited message from the server informs the
+       client that it should flush any information that it has
+       retained for the specified messages.
+
+        Justification:  This feature is provided so that clients can
+        view mailboxes in an order that is convenient to the user.
+        This is particularly important in the context of mailboxes
+        that the user copies messages to from other mailboxes.  This
+        user-controlled filing process often does not happen in any
+        well-defined order.  Because messages in a mailbox are
+
+
+
+Rice                                                           [Page 45]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+        implicitly ordered (usually by arrival date, though this is
+        not a required ordering predicate), the user can be confused
+        by the apparent order of messages in the mailbox.  The
+        addition of the RENUMBER command makes it unnecessary
+        for the user to leave IMAP and use some other mail system to
+        sort mailboxes.
+
+
+   ENCODING - When this feature is enabled (default is disabled) a new
+        generic key named ENCODING is defined.  The value associated
+        with the generic ENCODING key is a list of (tag encoding-type
+        options...) lists that represent the ordered, possibly encoded
+        body of the message.  Each such list represents a segment of
+        the body of the message and the way in which it is encoded.
+        Any options that follow the encoding_type are further
+        qualifiers that describe the format of the segment.  Each tag
+        is created by the server and is unique with respect to the
+        other tags allocated for the other elements in the ENCODING
+        list.  The client may use the tags returned by the server as
+        concrete keys to access a field which is encoded using the
+        encoding type and options mentioned in the appropriate list.
+        Thus:
+
+ tag41 FETCH 196 ENCODING ; Client asks for encoding field of msg 196.
+ tag41 FETCH ENCODING NIL ; Server replies. This message is not encoded.
+ tag41 OK Fetch completed.
+ tag42 FETCH 197 ENCODING ; Client asks for encoding field of msg 197.
+ tag42 FETCH ENCODING ((G001 UUENCODE) (G002 HEX)) ; Server replies.
+ tag42 OK Fetch completed.
+ tag43 FETCH 197 G002     ; Client asks for field named G002
+ tag43 FETCH G002 "A0 00 FF 13 42......." ; Server sends value of field.
+ tag43 OK Fetch completed.
+
+     or
+
+ tag44 STORE 197 G002 "0A 00 FF 31 24......."
+    ; Store back the segment with nibbles swapped
+
+      Note:  As a side-effect of enabling this feature, the generic key
+      TEXT will be redefined so as to return only those body parts of a
+      message that are of type TEXT.  The concrete key RFC822.TEXT, on
+      the other hand, would still return everything in the body of the
+      message, even if it was full of strange, binary character
+      sequences.
+
+      When the client STOREs to a field denoted by one of the above tags
+      the server will interpret the value being passed as being in the
+      same format as is currently specified in the ENCODING field.  The
+
+
+
+Rice                                                           [Page 46]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      server is not required to be able to reformat the data associated
+      with the ENCODING tags if the client STOREs a new value for the
+      ENCODING field.  The interpretability of a message in the context
+      of its ENCODING field is undefined if the client side-effects that
+      ENCODING field, unless the client also STOREs new, reformatted
+      values for the fields that have had their encoding changed.
+
+      If the client stores a new value for the ENCODING field then the
+      tags in the new value will be used to index the parts of the body.
+      All tags in a client-STOREd ENCODING that are the same as those
+      originally generated by the server in response to a FETCH ENCODING
+      command are said still to denote the fields that they originally
+      denoted, though possibly reordered.  Any tags not originally
+      defined by the server will denote new message parts, in the
+      appropriate format, in the relative position specified.  The
+      exclusion of any tags that the server originally defined in a
+      FETCH of the ENCODING field will indicate the deletion of that
+      part of the message.  Newly created message parts are undefined by
+      default, so if the client fails to follow the STOREing of the
+      ENCODING field with suitable STORE commands for the values
+      associated with any newly created tags, these fields will contain
+      the null value NIL.
+
+      Justification:  This feature is supplied so as to allow support
+      for emergent multi-part and multi-media mail standards.
+
+   INDEXABLE.FIELDS - When this feature is enabled (default is
+        disabled) the grammar of fetch commands is changed to allow the
+        client to select a specific subsequence from the field in
+        question.  For example:
+
+          tag42 FETCH 197 BODY 2000:3999
+
+        would fetch the second two thousand bytes of the body of message
+        197.  This feature allows resource limited clients to access
+        small parts of large messages.  The formal syntax for this is:
+
+   fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
+                       fetch_key / (fetch_key SP NUMBER ":" NUMBER)
+
+   fetch_key       ::= "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
+                       "RFC822.TEXT" / key
+
+      If the lower bound number (the number to the left of the colon)
+      exceeds the maximum size of the field then the empty string is
+      returned.  If the upper bound exceeds the maximum size of the
+      field but the lower bound does not then the server will return the
+      remaining substring of the field after the lower bound.  The
+
+
+
+Rice                                                           [Page 47]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      bounds specified are zero indexed into the fields and the bounds
+      index fields by 8-bit bytes.
+
+      Justification:  This feature is provided so as to allow resource-
+      limited clients to read very large messages and also to allow
+      clients to improve interactive response for the reading of large
+      messages by fetching the first "screen full" of data to display
+      immediately and fetching the rest of the message in the
+      background.
+
+   SET.EOL - When enabled (default is disabled), this feature
+        allows the new command SET.EOL to be available, changing the
+        grammar as follows:
+
+   character       ::= "CR" / "LF" / number
+
+   request         ::= tag SP (noop / login / logout / select / check /
+                       expunge / copy / fetch / store / search /
+                       select_version / select_features /
+                       supported_versions / bboard / find /
+                       read_only / read_write / flags / set_flags /
+                       set_eol) CRLF
+
+   set_eol         ::= "SET.EOL" 1#character
+
+      This has the effect of changing the end of line character sequence
+      generated by the server for newlines within strings to the
+      sequence of characters specified.  The characters in the sequence
+      can be either the specified symbolically named characters or a
+      numerical value, specifying the decimal value of the character to
+      use.  Thus, if the client would like newlines in strings to be
+      indicated by a carriage return followed by a control-d, the client
+      would issue the following command:
+
+           tag42 SET.EOL CR 4
+
+      If the server is unable to support the combination of characters
+      requested by the client as its end-of-line pattern it will reply
+      with a NO response.  This might be the case, for example, if a
+      server is only able to generate its own native line feed pattern
+      and the CRLF required by IMAP by default.
+
+      The server is required to change any length denoting values, such
+      as envelope byte counts for all future transactions to reflect the
+      new eol setting.  This change in reported sizes should apply to
+      all generic size fetching keys, but not to concrete ones such as
+      RFC822.SIZE, which by their very nature require a size measurement
+      in RFC822 format, i.e., with CRLF as the end-of-line convention.
+
+
+
+Rice                                                           [Page 48]
+
+RFC 1203                         IMAP3                     February 1991
+
+
+      Justification: This feature is provided because frequently clients
+      and servers might have end-of-line conventions other than the CRLF
+      specified by RFC822.  It is undesirable that the IMAP be linked
+      too closely to RFC822 and selecting a different convention might
+      allow substantial performance improvements in both clients and
+      servers by saving either client, server or both from having to
+      shuffle text around so as to add or remove non-local end-of-line
+      sequences.
+
+Acknowledgements:
+
+   This text is based on RFC 1064 by Mark Crispin.
+
+   The following have made major contributions to this proposed update
+   to the IMAP2 protocol:
+
+      James Rice               <Rice@sumex-aim.stanford.edu>
+      Richard Acuff            <acuff@sumex-aim.stanford.edu>
+      Bill Yeager              <yeager@sumex-aim.stanford.edu>
+      Christopher Lane         <lane@sumex-aim.stanford.edu>
+      Bjorn Victor             <Bjorn.Victor@docs.uu.se>
+
+   Additional input was also received from:
+
+      Andrew Sweer             <sweer@sumex-aim.stanford.edu>
+      Tom Gruber               <Gruber@sumex-aim.stanford.edu>
+      Kevin Brock              <Brock@Sumex-Aim.Stanford.Edu>
+      Mark Crispin             <MRC@cac.washington.edu>
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   James Rice
+   Stanford University
+   Knowledge Systems Laboratory
+   701 Welch Road
+   Building C
+   Palo Alto, CA 94304
+
+   Phone: (415) 723-8405
+   EMail: RICE@SUMEX-AIM.STANFORD.EDU
+
+
+
+
+
+
+
+Rice                                                           [Page 49]
+
\ No newline at end of file
diff --git a/RFC/rfc1225.txt b/RFC/rfc1225.txt
new file mode 100644
index 00000000..8d7e0029
--- /dev/null
+++ b/RFC/rfc1225.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                            M. Rose
+Request for Comments: 1225             Performance Systems International
+Obsoletes: RFC 1081                                             May 1991
+
+
+                    Post Office Protocol - Version 3
+
+Status of this Memo
+
+   This memo suggests a simple method for workstations to dynamically
+   access mail from a mailbox server.  This RFC specifies an IAB
+   standards track protocol for the Internet community, and requests
+   discussion and suggestions for improvements.  Please refer to the
+   current edition of the "IAB Official Protocol Standards" for the
+   standardization state and status of this protocol.  Distribution of
+   this memo is unlimited.
+
+Overview
+
+   This memo is a republication of RFC 1081 which was based on RFC 918
+   (since revised as RFC 937).  Although similar in form to the original
+   Post Office Protocol (POP) proposed for the Internet community, the
+   protocol discussed in this memo is similar in spirit to the ideas
+   investigated by the MZnet project at the University of California,
+   Irvine.
+
+   Further, substantial work was done on examining POP in a PC-based
+   environment.  This work, which resulted in additional functionality
+   in this protocol, was performed by the ACIS Networking Systems Group
+   at Stanford University.  The author gratefully acknowledges their
+   interest.
+
+Introduction
+
+   On certain types of smaller nodes in the Internet it is often
+   impractical to maintain a message transport system (MTS).  For
+   example, a workstation may not have sufficient resources (cycles,
+   disk space) in order to permit a SMTP server and associated local
+   mail delivery system to be kept resident and continuously running.
+   Similarly, it may be expensive (or impossible) to keep a personal
+   computer interconnected to an IP-style network for long amounts of
+   time (the node is lacking the resource known as "connectivity").
+
+   Despite this, it is often very useful to be able to manage mail on
+   these smaller nodes, and they often support a user agent (UA) to aid
+   the tasks of mail handling.  To solve this problem, a node which can
+   support an MTS entity offers a maildrop service to these less endowed
+   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
+
+
+
+Rose                                                            [Page 1]
+
+RFC 1225                          POP3                          May 1991
+
+
+   permit a workstation to dynamically access a maildrop on a server
+   host in a useful fashion.  Usually, this means that the POP3 is used
+   to allow a workstation to retrieve mail that the server is holding
+   for it.
+
+   For the remainder of this memo, the term "client host" refers to a
+   host making use of the POP3 service, while the term "server host"
+   refers to a host which offers the POP3 service.
+
+A Short Digression
+
+   This memo does not specify how a client host enters mail into the
+   transport system, although a method consistent with the philosophy of
+   this memo is presented here:
+
+      When the user agent on a client host wishes to enter a message
+      into the transport system, it establishes an SMTP connection to
+      its relay host (this relay host could be, but need not be, the
+      POP3 server host for the client host).
+
+   If this method is followed, then the client host appears to the MTS
+   as a user agent, and should NOT be regarded as a "trusted" MTS entity
+   in any sense whatsoever.  This concept, along with the role of the
+   POP3 as a part of a split-UA model is discussed later in this memo.
+
+   Initially, the server host starts the POP3 service by listening on
+   TCP port 110.  When a client host wishes to make use of the service,
+   it establishes a TCP connection with the server host.  When the
+   connection is established, the POP3 server sends a greeting.  The
+   client and POP3 server then exchange commands and responses
+   (respectively) until the connection is closed or aborted.
+
+   Commands in the POP3 consist of a keyword possibly followed by an
+   argument.  All commands are terminated by a CRLF pair.
+
+   Responses in the POP3 consist of a success indicator and a keyword
+   possibly followed by additional information.  All responses are
+   terminated by a CRLF pair.  There are currently two success
+   indicators: positive ("+OK") and negative ("-ERR").
+
+   Responses to certain commands are multi-line.  In these cases, which
+   are clearly indicated below, after sending the first line of the
+   response and a CRLF, any additional lines are sent, each terminated
+   by a CRLF pair.  When all lines of the response have been sent, a
+   final line is sent, consisting of a termination octet (decimal code
+   046, ".") and a CRLF pair.  If any line of the multi-line response
+   begins with the termination octet, the line is "byte-stuffed" by
+   pre-pending the termination octet to that line of the response.
+
+
+
+Rose                                                            [Page 2]
+
+RFC 1225                          POP3                          May 1991
+
+
+   Hence a multi-line response is terminated with the five octets
+   "CRLF.CRLF".  When examining a multi-line response, the client checks
+   to see if the line begins with the termination octet.  If so and if
+   octets other than CRLF follow, the the first octet of the line (the
+   termination octet) is stripped away.  If so and if CRLF immediately
+   follows the termination character, then the response from the POP
+   server is ended and the line containing ".CRLF" is not considered
+   part of the multi-line response.
+
+   A POP3 session progresses through a number of states during its
+   lifetime.  Once the TCP connection has been opened and the POP3
+   server has sent the greeting, the session enters the AUTHORIZATION
+   state.  In this state, the client must identify itself to the POP3
+   server.  Once the client has successfully done this, the server
+   acquires resources associated with the client's maildrop, and the
+   session enters the TRANSACTION state.  In this state, the client
+   requests actions on the part of the POP3 server.  When the client has
+   finished its transactions, the session enters the UPDATE state.  In
+   this state, the POP3 server releases any resources acquired during
+   the TRANSACTION state and says goodbye.  The TCP connection is then
+   closed.
+
+The AUTHORIZATION State
+
+   Once the TCP connection has been opened by a POP3 client, the POP3
+   server issues a one line greeting.  This can be any string terminated
+   by CRLF.  An example might be:
+
+      S.  +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
+
+   Note that this greeting is a POP3 reply.  The POP3 server should
+   always give a positive response as the greeting.
+
+   The POP3 session is now in the AUTHORIZATION state.  The client must
+   now issue the USER command.  If the POP3 server responds with a
+   positive success indicator ("+OK"), then the client may issue either
+   the PASS command to complete the authorization, or the QUIT command
+   to terminate the POP3 session.  If the POP3 server responds with a
+   negative success indicator ("-ERR") to the USER command, then the
+   client may either issue a new USER command or may issue the QUIT
+   command.
+
+   When the client issues the PASS command, the POP3 server uses the
+   argument pair from the USER and PASS commands to determine if the
+   client should be given access to the appropriate maildrop.  If so,
+   the POP3 server then acquires an exclusive-access lock on the
+   maildrop.  If the lock is successfully acquired, the POP3 server
+   parses the maildrop into individual messages (read note below),
+
+
+
+Rose                                                            [Page 3]
+
+RFC 1225                          POP3                          May 1991
+
+
+   determines the last message (if any) present in the maildrop that was
+   referenced by the RETR command, and responds with a positive success
+   indicator.  The POP3 session now enters the TRANSACTION state.  If
+   the lock can not be acquired or the client should is denied access to
+   the appropriate maildrop or the maildrop can't be parsed for some
+   reason, the POP3 server responds with a negative success indicator.
+   (If a lock was acquired but the POP3 server intends to respond with a
+   negative success indicator, the POP3 server must release the lock
+   prior to rejecting the command.)  At this point, the client may
+   either issue a new USER command and start again, or the client may
+   issue the QUIT command.
+
+                 NOTE: Minimal implementations of the POP3 need only be
+                 able to break a maildrop into its component messages;
+                 they need NOT be able to parse individual messages.
+                 More advanced implementations may wish to have this
+                 capability, for reasons discussed later.
+
+   After the POP3 server has parsed the maildrop into individual
+   messages, it assigns a message-id to each message, and notes the size
+   of the message in octets.  The first message in the maildrop is
+   assigned a message-id of "1", the second is assigned "2", and so on,
+   so that the n'th message in a maildrop is assigned a message-id of
+   "n".  In POP3 commands and responses, all message-id's and message
+   sizes are expressed in base-10 (i.e., decimal).
+
+   It sets the "highest number accessed" to be that of the last message
+   referenced by the RETR command.
+
+   Here are summaries for the three POP3 commands discussed thus far:
+
+           USER name
+               Arguments: a server specific user-id (required)
+               Restrictions: may only be given in the AUTHORIZATION
+                   state after the POP3 greeting or after an
+                   unsuccessful USER or PASS command
+               Possible Responses:
+                   +OK name is welcome here
+                   -ERR never heard of name
+               Examples:
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                     ...
+                   C:    USER frated
+                   S:    -ERR sorry, frated doesn't get his mail here
+
+           PASS string
+               Arguments: a server/user-id specific password (required)
+
+
+
+Rose                                                            [Page 4]
+
+RFC 1225                          POP3                          May 1991
+
+
+               Restrictions: may only be given in the AUTHORIZATION
+                   state after a successful USER command
+               Possible Responses:
+                   +OK maildrop locked and ready
+                   -ERR invalid password
+                   -ERR unable to lock maildrop
+               Examples:
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                   C:    PASS secret
+                   S:    +OK mrose's maildrop has 2 messages
+                         (320 octets)
+                     ...
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                   C:    PASS secret
+                   S:    -ERR unable to lock mrose's maildrop, file
+                         already locked
+
+           QUIT
+               Arguments: none
+               Restrictions: none
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    QUIT
+                   S:    +OK dewey POP3 server signing off
+
+
+The TRANSACTION State
+
+   Once the client has successfully identified itself to the POP3 server
+   and the POP3 server has locked and burst the appropriate maildrop,
+   the POP3 session is now in the TRANSACTION state.  The client may now
+   issue any of the following POP3 commands repeatedly.  After each
+   command, the POP3 server issues a response.  Eventually, the client
+   issues the QUIT command and the POP3 session enters the UPDATE state.
+
+   Here are the POP3 commands valid in the TRANSACTION state:
+
+           STAT
+               Arguments: none
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server issues a positive response with a line
+                 containing information for the maildrop.  This line is
+                 called a "drop listing" for that maildrop.
+
+
+
+Rose                                                            [Page 5]
+
+RFC 1225                          POP3                          May 1991
+
+
+                 In order to simplify parsing, all POP3 servers are
+                 required to use a certain format for drop listings.
+                 The first octets present must indicate the number of
+                 messages in the maildrop.  Following this is the size
+                 of the maildrop in octets.  This memo makes no
+                 requirement on what follows the maildrop size.
+                 Minimal implementations should just end that line of
+                 the response with a CRLF pair.  More advanced
+                 implementations may include other information.
+
+                      NOTE: This memo STRONGLY discourages
+                      implementations from supplying additional
+                      information in the drop listing.  Other,
+                      optional, facilities are discussed later on
+                      which permit the client to parse the messages
+                      in the maildrop.
+
+                 Note that messages marked as deleted are not counted in
+                 either total.
+
+               Possible Responses:
+                   +OK nn mm
+               Examples:
+                   C:    STAT
+                   S:    +OK 2 320
+
+           LIST [msg]
+               Arguments: a message-id (optionally)  If a message-id is
+                   given, it may NOT refer to a message marked as
+                   deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 If an argument was given and the POP3 server issues a
+                 positive response with a line containing information
+                 for that message.  This line is called a "scan listing"
+                 for that message.
+
+                 If no argument was given and the POP3 server issues a
+                 positive response, then the response given is
+                 multi-line.  After the initial +OK, for each message
+                 in the maildrop, the POP3 server responds with a line
+                 containing information for that message.  This line
+                 is called a "scan listing" for that message.
+
+                 In order to simplify parsing, all POP3 servers are
+                 required to use a certain format for scan listings.
+                 The first octets present must be the message-id of
+
+
+
+Rose                                                            [Page 6]
+
+RFC 1225                          POP3                          May 1991
+
+
+                 the message.  Following the message-id is the size of
+                 the message in octets.  This memo makes no requirement
+                 on what follows the message size in the scan listing.
+                 Minimal implementations should just end that line of
+                 the response with a CRLF pair.  More advanced
+                 implementations may include other information, as
+                 parsed from the message.
+
+                      NOTE: This memo STRONGLY discourages
+                      implementations from supplying additional
+                      information in the scan listing.  Other, optional,
+                      facilities are discussed later on which permit
+                      the client to parse the messages in the maildrop.
+
+                 Note that messages marked as deleted are not listed.
+
+               Possible Responses:
+                   +OK scan listing follows
+                   -ERR no such message
+               Examples:
+                   C:    LIST
+                   S:    +OK 2 messages (320 octets)
+                   S:    1 120
+                   S:    2 200
+                   S:    .
+                     ...
+                   C:    LIST 2
+                   S:    +OK 2 200
+                     ...
+                   C:    LIST 3
+                   S:    -ERR no such message, only 2 messages in
+                         maildrop
+
+           RETR msg
+               Arguments: a message-id (required)  This message-id may
+                   NOT refer to a message marked as deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 If the POP3 server issues a positive response, then the
+                 response given is multi-line.  After the initial +OK,
+                 the POP3 server sends the message corresponding to the
+                 given message-id, being careful to byte-stuff the
+                 termination character (as with all multi-line
+                 responses).
+
+                 If the number associated with this message is higher
+                 than the "highest number accessed" in the maildrop, the
+
+
+
+Rose                                                            [Page 7]
+
+RFC 1225                          POP3                          May 1991
+
+
+                 POP3 server updates the "highest number accessed" to
+                 the number associated with this message.
+
+               Possible Responses:
+                   +OK message follows
+                   -ERR no such message
+               Examples:
+                   C:    RETR 1
+                   S:    +OK 120 octets
+                   S:    <the POP3 server sends the entire message here>
+                   S:    .
+
+           DELE msg
+               Arguments: a message-id (required)  This message-id
+                   may NOT refer to a message marked as deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server marks the message as deleted.  Any
+                 future reference to the message-id associated with the
+                 message in a POP3 command generates an error.  The POP3
+                 server does not actually delete the message until the
+                 POP3 session enters the UPDATE state.
+
+                 If the number associated with this message is higher
+                 than the "highest number accessed" in the maildrop,
+                 the POP3 server updates the "highest number accessed"
+                 to the number associated with this message.
+
+               Possible Responses:
+                   +OK message deleted
+                   -ERR no such message
+               Examples:
+                   C:    DELE 1
+                   S:    +OK message 1 deleted
+                     ...
+                   C:    DELE 2
+                   S:    -ERR message 2 already deleted
+
+           NOOP
+               Arguments: none
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server does nothing, it merely replies with a
+                 positive response.
+
+               Possible Responses:
+
+
+
+Rose                                                            [Page 8]
+
+RFC 1225                          POP3                          May 1991
+
+
+                   +OK
+               Examples:
+                   C:    NOOP
+                   S:    +OK
+
+           LAST
+               Arguments: none
+               Restrictions: may only be issued in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server issues a positive response with a line
+                 containing the highest message number which accessed.
+                 Zero is returned in case no message in the maildrop has
+                 been accessed during previous transactions.  A client
+                 may thereafter infer that messages, if any, numbered
+                 greater than the response to the LAST command are
+                 messages not yet accessed by the client.
+
+             Possible Response:
+                   +OK nn
+
+             Examples:
+                   C:      STAT
+                   S:      +OK 4 320
+                   C:      LAST
+                   S:      +OK 1
+                   C:      RETR 3
+                   S:      +OK 120 octets
+                   S:      <the POP3 server sends the entire message
+                           here>
+                   S:      .
+                   C:      LAST
+                   S:      +OK 3
+                   C:      DELE 2
+                   S:      +OK message 2 deleted
+                   C:      LAST
+                   S:      +OK 3
+                   C:      RSET
+                   S:      +OK
+                   C:      LAST
+                   S:      +OK 1
+
+           RSET
+               Arguments: none
+               Restrictions: may only be given in the TRANSACTION
+                   state.
+               Discussion:
+
+
+
+
+Rose                                                            [Page 9]
+
+RFC 1225                          POP3                          May 1991
+
+
+                 If any messages have been marked as deleted by the POP3
+                 server, they are unmarked.  The POP3 server then
+                 replies with a positive response.  In addition, the
+                 "highest number accessed" is also reset to the value
+                 determined at the beginning of the POP3 session.
+
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    RSET
+                   S:    +OK maildrop has 2 messages (320 octets)
+
+
+
+The UPDATE State
+
+   When the client issues the QUIT command from the TRANSACTION state,
+   the POP3 session enters the UPDATE state.  (Note that if the client
+   issues the QUIT command from the AUTHORIZATION state, the POP3
+   session terminates but does NOT enter the UPDATE state.)
+
+           QUIT
+               Arguments: none
+               Restrictions: none
+               Discussion:
+
+                 The POP3 server removes all messages marked as deleted
+                 from the maildrop.  It then releases the
+                 exclusive-access lock on the maildrop and replies as
+                 to the success of
+                 these operations.  The TCP connection is then closed.
+
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    QUIT
+                   S:    +OK dewey POP3 server signing off (maildrop
+                         empty)
+                     ...
+                   C:    QUIT
+                   S:    +OK dewey POP3 server signing off (2 messages
+                         left)
+                     ...
+
+
+Optional POP3 Commands
+
+   The POP3 commands discussed above must be supported by all minimal
+
+
+
+Rose                                                           [Page 10]
+
+RFC 1225                          POP3                          May 1991
+
+
+   implementations of POP3 servers.
+
+   The optional POP3 commands described below permit a POP3 client
+   greater freedom in message handling, while preserving a simple POP3
+   server implementation.
+
+                 NOTE: This memo STRONGLY encourages implementations to
+                 support these commands in lieu of developing augmented
+                 drop and scan listings.  In short, the philosophy of
+                 this memo is to put intelligence in the part of the
+                 POP3 client and not the POP3 server.
+
+           TOP msg n
+               Arguments: a message-id (required) and a number.  This
+                   message-id may NOT refer to a message marked as
+                   deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 If the POP3 server issues a positive response, then
+                 the response given is multi-line.  After the initial
+                 +OK, the POP3 server sends the headers of the message,
+                 the blank line separating the headers from the body,
+                 and then the number of lines indicated message's body,
+                 being careful to byte-stuff the termination character
+                 (as with all multi-line responses).
+
+                 Note that if the number of lines requested by the POP3
+                 client is greater than than the number of lines in the
+                 body, then the POP3 server sends the entire message.
+
+               Possible Responses:
+                   +OK top of message follows
+                   -ERR no such message
+               Examples:
+                   C:    TOP 10
+                   S:    +OK
+                   S:    <the POP3 server sends the headers of the
+                          message, a blank line, and the first 10 lines
+                          of the body of the message>
+                   S:    .
+                     ...
+                   C:    TOP 100
+                   S:    -ERR no such message
+
+           RPOP user
+               Arguments: a client specific user-id (required)
+               Restrictions: may only be given in the AUTHORIZATION
+
+
+
+Rose                                                           [Page 11]
+
+RFC 1225                          POP3                          May 1991
+
+
+                   state after a successful USER command; in addition,
+                   may only be given if the client used a reserved
+                   (privileged) TCP port to connect to the server.
+               Discussion:
+
+                 The RPOP command may be used instead of the PASS
+                 command to authenticate access to the maildrop.  In
+                 order for this command to be successful, the POP3
+                 client must use a reserved TCP port (port < 1024) to
+                 connect tothe server.  The POP3 server uses the
+                 argument pair from the USER and RPOP commands to
+                 determine if the client should be given access to
+                 the appropriate maildrop.  Unlike the PASS command
+                 however, the POP3 server considers if the remote user
+                 specified by the RPOP command who resides on the POP3
+                 client host is allowed to access the maildrop for the
+                 user specified by the USER command (e.g., on Berkeley
+                 UNIX, the .rhosts mechanism is used).  With the
+                 exception of this differing in authentication, this
+                 command is identical to the PASS command.
+
+                 Note that the use of this feature has allowed much wider
+                 penetration into numerous hosts on local networks (and
+                 sometimes remote networks) by those who gain illegal
+                 access to computers by guessing passwords or otherwise
+                 breaking into the system.
+
+               Possible Responses:
+                   +OK maildrop locked and ready
+                   -ERR permission denied
+               Examples:
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                   C:    RPOP mrose
+                   S:    +OK mrose's maildrop has 2 messages (320
+                         octets)
+
+       Minimal POP3 Commands:
+           USER name               valid in the AUTHORIZATION state
+           PASS string
+           QUIT
+
+           STAT                    valid in the TRANSACTION state
+           LIST [msg]
+           RETR msg
+           DELE msg
+           NOOP
+           LAST
+
+
+
+Rose                                                           [Page 12]
+
+RFC 1225                          POP3                          May 1991
+
+
+           RSET
+
+           QUIT                    valid in the UPDATE state
+
+       Optional POP3 Commands:
+           RPOP user               valid in the AUTHORIZATION state
+
+           TOP msg n               valid in the TRANSACTION state
+
+       POP3 Replies:
+           +OK
+           -ERR
+
+       Note that with the exception of the STAT command, the reply given
+       by the POP3 server to any command is significant only to "+OK"
+       and "-ERR".  Any text occurring after this reply may be ignored
+       by the client.
+
+Example POP3 Session
+
+    S: <wait for connection on TCP port 110>
+        ...
+    C: <open connection>
+    S:    +OK dewey POP3 server ready (Comments to: PostMaster@UDEL.EDU)
+    C:    USER mrose
+    S:    +OK mrose is a real hoopy frood
+    C:    PASS secret
+    S:    +OK mrose's maildrop has 2 messages (320 octets)
+    C:    STAT
+    S:    +OK 2 320
+    C:    LIST
+    S:    +OK 2 messages (320 octets)
+    S:    1 120
+    S:    2 200
+    S:    .
+    C:    RETR 1
+    S:    +OK 120 octets
+    S:    <the POP3 server sends message 1>
+    S:    .
+    C:    DELE 1
+    S:    +OK message 1 deleted
+    C:    RETR 2
+    S:    +OK 200 octets
+    S:    <the POP3 server sends message 2>
+    S:    .
+    C:    DELE 2
+    S:    +OK message 2 deleted
+    C:    QUIT
+
+
+
+Rose                                                           [Page 13]
+
+RFC 1225                          POP3                          May 1991
+
+
+    S:    +OK dewey POP3 server signing off (maildrop empty)
+    C:  <close connection>
+    S:  <wait for next connection>
+
+Message Format
+
+   All messages transmitted during a POP3 session are assumed to conform
+   to the standard for the format of Internet text messages [RFC822].
+
+   It is important to note that the byte count for a message on the
+   server host may differ from the octet count assigned to that message
+   due to local conventions for designating end-of-line.  Usually,
+   during the AUTHORIZATION state of the POP3 session, the POP3 client
+   can calculate the size of each message in octets when it parses the
+   maildrop into messages.  For example, if the POP3 server host
+   internally represents end-of-line as a single character, then the
+   POP3 server simply counts each occurrence of this character in a
+   message as two octets.  Note that lines in the message which start
+   with the termination octet need not be counted twice, since the POP3
+   client will remove all byte-stuffed termination characters when it
+   receives a multi-line response.
+
+The POP and the Split-UA model
+
+   The underlying paradigm in which the POP3 functions is that of a
+   split-UA model.  The POP3 client host, being a remote PC based
+   workstation, acts solely as a client to the message transport system.
+   It does not provide delivery/authentication services to others.
+   Hence, it is acting as a UA, on behalf of the person using the
+   workstation.  Furthermore, the workstation uses SMTP to enter mail
+   into the MTS.
+
+   In this sense, we have two UA functions which interface to the
+   message transport system: Posting (SMTP) and Retrieval (POP3).  The
+   entity which supports this type of environment is called a split-UA
+   (since the user agent is split between two hosts which must
+   interoperate to provide these functions).
+
+                 ASIDE:  Others might term this a remote-UA instead.
+                 There are arguments supporting the use of both terms.
+
+   This memo has explicitly referenced TCP as the underlying transport
+   agent for the POP3.  This need not be the case.  In the MZnet split-
+   UA, for example, personal micro-computer systems are used which do
+   not have IP-style networking capability.  To connect to the POP3
+   server host, a PC establishes a terminal connection using some simple
+   protocol (PhoneNet).  A program on the PC drives the connection,
+   first establishing a login session as a normal user.  The login shell
+
+
+
+Rose                                                           [Page 14]
+
+RFC 1225                          POP3                          May 1991
+
+
+   for this pseudo-user is a program which drives the other half of the
+   terminal protocol and communicates with one of two servers.  Although
+   MZnet can support several PCs, a single pseudo-user login is present
+   on the server host.  The user-id and password for this pseudo-user
+   login is known to all members of MZnet.  Hence, the first action of
+   the login shell, after starting the terminal protocol, is to demand a
+   USER/PASS authorization pair from the PC.  This second level of
+   authorization is used to ascertain who is interacting with the MTS.
+   Although the server host is deemed to support a "trusted" MTS entity,
+   PCs in MZnet are not.  Naturally, the USER/PASS authorization pair
+   for a PC is known only to the owner of the PC (in theory, at least).
+
+   After successfully verifying the identity of the client, a modified
+   SMTP server is started, and the PC posts mail with the server host.
+   After the QUIT command is given to the SMTP server and it terminates,
+   a modified POP3 server is started, and the PC retrieves mail from the
+   server host.  After the QUIT command is given to the POP3 server and
+   it terminates, the login shell for the pseudo-user terminates the
+   terminal protocol and logs the job out.  The PC then closes the
+   terminal connection to the server host.
+
+   The SMTP server used by MZnet is modified in the sense that it knows
+   that it's talking to a user agent and not a "trusted" entity in the
+   message transport system.  Hence, it does performs the validation
+   activities normally performed by an entity in the MTS when it accepts
+   a message from a UA.
+
+   The POP3 server used by MZnet is modified in the sense that it does
+   not require a USER/PASS combination before entering the TRANSACTION
+   state.  The reason for this (of course) is that the PC has already
+   identified itself during the second-level authorization step
+   described above.
+
+                 NOTE: Truth in advertising laws require that the author
+                 of this memo state that MZnet has not actually been
+                 fully implemented.  The concepts presented and proven
+                 by the project led to the notion of the MZnet
+                 split-slot model.  This notion has inspired the
+                 split-UA concept described in this memo, led to the
+                 author's interest in the POP, and heavily influenced
+                 the the description of the POP3 herein.
+
+   In fact, some UAs present in the Internet already support the notion
+   of posting directly to an SMTP server and retrieving mail directly
+   from a POP server, even if the POP server and client resided on the
+   same host!
+
+                 ASIDE: this discussion raises an issue which this memo
+
+
+
+Rose                                                           [Page 15]
+
+RFC 1225                          POP3                          May 1991
+
+
+                 purposedly avoids: how does SMTP know that it's talking
+                 to a "trusted" MTS entity?
+
+References
+
+     [MZnet]   Stefferud, E., J. Sweet, and T. Domae, "MZnet: Mail
+               Service for Personal Micro-Computer Systems",
+               Proceedings, IFIP 6.5 International Conference on
+               Computer Message Systems, Nottingham, U.K., May 1984.
+
+     [RFC821]  Postel, J., "Simple Mail Transfer Protocol",
+               USC/Information Sciences Institute, August 1982.
+
+     [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
+               Text Messages", University of Delaware, August 1982.
+
+     [RFC937]  Butler, M., J. Postel, D. Chase, J. Goldberger, and J.
+               Reynolds, "Post Office Protocol - Version 2", RFC 937,
+               USC/Information Sciences Institute, February 1985.
+
+     [RFC1060] Reynolds, J., and J. Postel, "Assigned Numbers", RFC
+               1060, USC/Information Sciences Institute, March 1990.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address:
+
+   Marshall T. Rose
+   Performance Systems International
+   5201 Great America Parkway
+   Suite 3106
+   Santa Clara, CA  95054
+
+   Phone: +1 408 562 6222
+
+   EMail: mrose@psi.com
+   X.500:  rose, psi, us
+
+
+
+
+
+
+
+
+
+
+
+
+Rose                                                           [Page 16]
+
\ No newline at end of file
diff --git a/RFC/rfc1460.txt b/RFC/rfc1460.txt
new file mode 100644
index 00000000..d6177599
--- /dev/null
+++ b/RFC/rfc1460.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                            M. Rose
+Request for Comments: 1460                  Dover Beach Consulting, Inc.
+Obsoletes: 1225                                                June 1993
+
+
+                    Post Office Protocol - Version 3
+
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Overview
+
+   This memo is a revision to RFC 1225, a Draft Standard.  It makes the
+   following changes from that document:
+
+        - the RPOP facility is removed;
+
+        - the optional APOP facility is added (which is in interoperable,
+          operational use in at least three implementations);
+
+        - a typo was corrected with respect to the interaction of LAST
+          and RSET;
+
+        - section numbers were added; and,
+
+        - an acknowledgements section was added.
+
+1. Introduction
+
+   On certain types of smaller nodes in the Internet it is often
+   impractical to maintain a message transport system (MTS).  For
+   example, a workstation may not have sufficient resources (cycles,
+   disk space) in order to permit a SMTP server [RFC821] and associated
+   local mail delivery system to be kept resident and continuously
+   running.
+
+   Similarly, it may be expensive (or impossible) to keep a personal
+   computer interconnected to an IP-style network for long amounts of
+   time (the node is lacking the resource known as "connectivity").
+
+   Despite this, it is often very useful to be able to manage mail on
+   these smaller nodes, and they often support a user agent (UA) to aid
+
+
+
+Rose                                                            [Page 1]
+
+RFC 1460                          POP3                         June 1993
+
+
+   the tasks of mail handling.  To solve this problem, a node which can
+   support an MTS entity offers a maildrop service to these less endowed
+   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
+   permit a workstation to dynamically access a maildrop on a server
+   host in a useful fashion.  Usually, this means that the POP3 is used
+   to allow a workstation to retrieve mail that the server is holding
+   for it.
+
+   For the remainder of this memo, the term "client host" refers to a
+   host making use of the POP3 service, while the term "server host"
+   refers to a host which offers the POP3 service.
+
+2. A Short Digression
+
+   This memo does not specify how a client host enters mail into the
+   transport system, although a method consistent with the philosophy of
+   this memo is presented here:
+
+      When the user agent on a client host wishes to enter a message
+      into the transport system, it establishes an SMTP connection to
+      its relay host (this relay host could be, but need not be, the
+      POP3 server host for the client host).
+
+   If this method is followed, then the client host appears to the MTS
+   as a user agent, and should NOT be regarded as a "trusted" MTS entity
+   in any sense whatsoever.  This concept, along with the role of the
+   POP3 as a part of a split-UA model is discussed later in this memo.
+
+3. Basic Operation
+
+   Initially, the server host starts the POP3 service by listening on
+   TCP port 110.  When a client host wishes to make use of the service,
+   it establishes a TCP connection with the server host.  When the
+   connection is established, the POP3 server sends a greeting.  The
+   client and POP3 server then exchange commands and responses
+   (respectively) until the connection is closed or aborted.
+
+   Commands in the POP3 consist of a keyword possibly followed by an
+   argument.  All commands are terminated by a CRLF pair.
+
+   Responses in the POP3 consist of a success indicator and a keyword
+   possibly followed by additional information.  All responses are
+   terminated by a CRLF pair.  There are currently two success
+   indicators: positive ("+OK") and negative ("-ERR").
+
+   Responses to certain commands are multi-line.  In these cases, which
+   are clearly indicated below, after sending the first line of the
+   response and a CRLF, any additional lines are sent, each terminated
+
+
+
+Rose                                                            [Page 2]
+
+RFC 1460                          POP3                         June 1993
+
+
+   by a CRLF pair.  When all lines of the response have been sent, a
+   final line is sent, consisting of a termination octet (decimal code
+   046, ".") and a CRLF pair.  If any line of the multi-line response
+   begins with the termination octet, the line is "byte-stuffed" by
+   pre-pending the termination octet to that line of the response.
+
+   Hence a multi-line response is terminated with the five octets
+   "CRLF.CRLF".  When examining a multi-line response, the client checks
+   to see if the line begins with the termination octet.  If so and if
+   octets other than CRLF follow, the the first octet of the line (the
+   termination octet) is stripped away.  If so and if CRLF immediately
+   follows the termination character, then the response from the POP
+   server is ended and the line containing ".CRLF" is not considered
+   part of the multi-line response.
+
+   A POP3 session progresses through a number of states during its
+   lifetime.  Once the TCP connection has been opened and the POP3
+   server has sent the greeting, the session enters the AUTHORIZATION
+   state.  In this state, the client must identify itself to the POP3
+   server.  Once the client has successfully done this, the server
+   acquires resources associated with the client's maildrop, and the
+   session enters the TRANSACTION state.  In this state, the client
+   requests actions on the part of the POP3 server.  When the client has
+   finished its transactions, the session enters the UPDATE state.  In
+   this state, the POP3 server releases any resources acquired during
+   the TRANSACTION state and says goodbye.  The TCP connection is then
+   closed.
+
+4. The AUTHORIZATION State
+
+   Once the TCP connection has been opened by a POP3 client, the POP3
+   server issues a one line greeting.  This can be any string terminated
+   by CRLF.  An example might be:
+
+      S.  +OK POP3 server ready
+
+   Note that this greeting is a POP3 reply.  The POP3 server should
+   always give a positive response as the greeting.
+
+   The POP3 session is now in the AUTHORIZATION state.  The client must
+   now issue the USER command.  If the POP3 server responds with a
+   positive success indicator ("+OK"), then the client may issue either
+   the PASS command to complete the authorization, or the QUIT command
+   to terminate the POP3 session.  If the POP3 server responds with a
+   negative success indicator ("-ERR") to the USER command, then the
+   client may either issue a new USER command or may issue the QUIT
+   command.
+
+
+
+
+Rose                                                            [Page 3]
+
+RFC 1460                          POP3                         June 1993
+
+
+   When the client issues the PASS command, the POP3 server uses the
+   argument pair from the USER and PASS commands to determine if the
+   client should be given access to the appropriate maildrop.  If so,
+   the POP3 server then acquires an exclusive-access lock on the
+   maildrop.  If the lock is successfully acquired, the POP3 server
+   parses the maildrop into individual messages (read note below),
+   determines the last message (if any) present in the maildrop that was
+   referenced by the RETR command, and responds with a positive success
+   indicator.  The POP3 session now enters the TRANSACTION state.  If
+   the lock can not be acquired or the client should is denied access to
+   the appropriate maildrop or the maildrop can't be parsed for some
+   reason, the POP3 server responds with a negative success indicator.
+   (If a lock was acquired but the POP3 server intends to respond with a
+   negative success indicator, the POP3 server must release the lock
+   prior to rejecting the command.)  At this point, the client may
+   either issue a new USER command and start again, or the client may
+   issue the QUIT command.
+
+                 NOTE: Minimal implementations of the POP3 need only be
+                 able to break a maildrop into its component messages;
+                 they need NOT be able to parse individual messages.
+                 More advanced implementations may wish to have this
+                 capability, for reasons discussed later.
+
+   After the POP3 server has parsed the maildrop into individual
+   messages, it assigns a message-id to each message, and notes the size
+   of the message in octets.  The first message in the maildrop is
+   assigned a message-id of "1", the second is assigned "2", and so on,
+   so that the n'th message in a maildrop is assigned a message-id of
+   "n".  In POP3 commands and responses, all message-id's and message
+   sizes are expressed in base-10 (i.e., decimal).
+
+   It sets the "highest number accessed" to be that of the last message
+   referenced by the RETR command.
+
+   Here are summaries for the three POP3 commands discussed thus far:
+
+           USER name
+               Arguments: a server specific user-id (required)
+               Restrictions: may only be given in the AUTHORIZATION
+                   state after the POP3 greeting or after an
+                   unsuccessful USER or PASS command
+               Possible Responses:
+                   +OK name is welcome here
+                   -ERR never heard of name
+               Examples:
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+
+
+
+Rose                                                            [Page 4]
+
+RFC 1460                          POP3                         June 1993
+
+
+                     ...
+                   C:    USER frated
+                   S:    -ERR sorry, frated doesn't get his mail here
+
+           PASS string
+               Arguments: a server/user-id specific password (required)
+               Restrictions: may only be given in the AUTHORIZATION
+                   state after a successful USER command
+               Possible Responses:
+                   +OK maildrop locked and ready
+                   -ERR invalid password
+                   -ERR unable to lock maildrop
+               Examples:
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                   C:    PASS secret
+                   S:    +OK mrose's maildrop has 2 messages
+                         (320 octets)
+                     ...
+                   C:    USER mrose
+                   S:    +OK mrose is a real hoopy frood
+                   C:    PASS secret
+                   S:    -ERR unable to lock mrose's maildrop, file
+                         already locked
+
+           QUIT
+               Arguments: none
+               Restrictions: none
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    QUIT
+                   S:    +OK dewey POP3 server signing off
+
+5. The TRANSACTION State
+
+   Once the client has successfully identified itself to the POP3 server
+   and the POP3 server has locked and burst the appropriate maildrop,
+   the POP3 session is now in the TRANSACTION state.  The client may now
+   issue any of the following POP3 commands repeatedly.  After each
+   command, the POP3 server issues a response.  Eventually, the client
+   issues the QUIT command and the POP3 session enters the UPDATE state.
+
+   Here are the POP3 commands valid in the TRANSACTION state:
+
+           STAT
+               Arguments: none
+               Restrictions: may only be given in the TRANSACTION state.
+
+
+
+Rose                                                            [Page 5]
+
+RFC 1460                          POP3                         June 1993
+
+
+               Discussion:
+
+                 The POP3 server issues a positive response with a line
+                 containing information for the maildrop.  This line is
+                 called a "drop listing" for that maildrop.
+
+                 In order to simplify parsing, all POP3 servers are
+                 required to use a certain format for drop listings.
+                 The first octets present must indicate the number of
+                 messages in the maildrop.  Following this is the size
+                 of the maildrop in octets.  This memo makes no
+                 requirement on what follows the maildrop size.
+                 Minimal implementations should just end that line of
+                 the response with a CRLF pair.  More advanced
+                 implementations may include other information.
+
+                      NOTE: This memo STRONGLY discourages
+                      implementations from supplying additional
+                      information in the drop listing.  Other,
+                      optional, facilities are discussed later on
+                      which permit the client to parse the messages
+                      in the maildrop.
+
+                 Note that messages marked as deleted are not counted in
+                 either total.
+
+               Possible Responses:
+                   +OK nn mm
+               Examples:
+                   C:    STAT
+                   S:    +OK 2 320
+
+           LIST [msg]
+               Arguments: a message-id (optionally)  If a message-id is
+                   given, it may NOT refer to a message marked as
+                   deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 If an argument was given and the POP3 server issues a
+                 positive response with a line containing information
+                 for that message.  This line is called a "scan listing"
+                 for that message.
+
+                 If no argument was given and the POP3 server issues a
+                 positive response, then the response given is
+                 multi-line.  After the initial +OK, for each message
+                 in the maildrop, the POP3 server responds with a line
+
+
+
+Rose                                                            [Page 6]
+
+RFC 1460                          POP3                         June 1993
+
+
+                 containing information for that message.  This line
+                 is called a "scan listing" for that message.
+
+                 In order to simplify parsing, all POP3 servers are
+                 required to use a certain format for scan listings.
+                 The first octets present must be the message-id of
+                 the message.  Following the message-id is the size of
+                 the message in octets.  This memo makes no requirement
+                 on what follows the message size in the scan listing.
+                 Minimal implementations should just end that line of
+                 the response with a CRLF pair.  More advanced
+                 implementations may include other information, as
+                 parsed from the message.
+
+                      NOTE: This memo STRONGLY discourages
+                      implementations from supplying additional
+                      information in the scan listing.  Other, optional,
+                      facilities are discussed later on which permit
+                      the client to parse the messages in the maildrop.
+
+                 Note that messages marked as deleted are not listed.
+
+               Possible Responses:
+                   +OK scan listing follows
+                   -ERR no such message
+               Examples:
+                   C:    LIST
+                   S:    +OK 2 messages (320 octets)
+                   S:    1 120
+                   S:    2 200
+                   S:    .
+                     ...
+                   C:    LIST 2
+                   S:    +OK 2 200
+                     ...
+                   C:    LIST 3
+                   S:    -ERR no such message, only 2 messages in
+                         maildrop
+
+           RETR msg
+               Arguments: a message-id (required)  This message-id may
+                   NOT refer to a message marked as deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 If the POP3 server issues a positive response, then the
+                 response given is multi-line.  After the initial +OK,
+                 the POP3 server sends the message corresponding to the
+
+
+
+Rose                                                            [Page 7]
+
+RFC 1460                          POP3                         June 1993
+
+
+                 given message-id, being careful to byte-stuff the
+                 termination character (as with all multi-line
+                 responses).
+
+                 If the number associated with this message is higher
+                 than the "highest number accessed" in the maildrop, the
+                 POP3 server updates the "highest number accessed" to
+                 the number associated with this message.
+
+               Possible Responses:
+                   +OK message follows
+                   -ERR no such message
+               Examples:
+                   C:    RETR 1
+                   S:    +OK 120 octets
+                   S:    <the POP3 server sends the entire message here>
+                   S:    .
+
+           DELE msg
+               Arguments: a message-id (required)  This message-id
+                   may NOT refer to a message marked as deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server marks the message as deleted.  Any
+                 future reference to the message-id associated with the
+                 message in a POP3 command generates an error.  The POP3
+                 server does not actually delete the message until the
+                 POP3 session enters the UPDATE state.
+
+                 If the number associated with this message is higher
+                 than the "highest number accessed" in the maildrop,
+                 the POP3 server updates the "highest number accessed"
+                 to the number associated with this message.
+
+               Possible Responses:
+                   +OK message deleted
+                   -ERR no such message
+               Examples:
+                   C:    DELE 1
+                   S:    +OK message 1 deleted
+                     ...
+                   C:    DELE 2
+                   S:    -ERR message 2 already deleted
+
+           NOOP
+               Arguments: none
+               Restrictions: may only be given in the TRANSACTION state.
+
+
+
+Rose                                                            [Page 8]
+
+RFC 1460                          POP3                         June 1993
+
+
+               Discussion:
+
+                 The POP3 server does nothing, it merely replies with a
+                 positive response.
+
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    NOOP
+                   S:    +OK
+
+           LAST
+               Arguments: none
+               Restrictions: may only be issued in the TRANSACTION state.
+               Discussion:
+
+                 The POP3 server issues a positive response with a line
+                 containing the highest message number which accessed.
+                 Zero is returned in case no message in the maildrop has
+                 been accessed during previous transactions.  A client
+                 may thereafter infer that messages, if any, numbered
+                 greater than the response to the LAST command are
+                 messages not yet accessed by the client.
+
+             Possible Response:
+                   +OK nn
+
+             Examples:
+                   C:      STAT
+                   S:      +OK 4 320
+                   C:      LAST
+                   S:      +OK 1
+                   C:      RETR 3
+                   S:      +OK 120 octets
+                   S:      <the POP3 server sends the entire message
+                           here>
+                   S:      .
+                   C:      LAST
+                   S:      +OK 3
+                   C:      DELE 2
+                   S:      +OK message 2 deleted
+                   C:      LAST
+                   S:      +OK 3
+                   C:      RSET
+                   S:      +OK
+                   C:      LAST
+                   S:      +OK 0
+
+
+
+
+Rose                                                            [Page 9]
+
+RFC 1460                          POP3                         June 1993
+
+
+           RSET
+               Arguments: none
+               Restrictions: may only be given in the TRANSACTION
+                   state.
+               Discussion:
+
+                 If any messages have been marked as deleted by the POP3
+                 server, they are unmarked.  The POP3 server then
+                 replies with a positive response.  In addition, the
+                 "highest number accessed" is also reset to zero.
+
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    RSET
+                   S:    +OK maildrop has 2 messages (320 octets)
+
+6. The UPDATE State
+
+   When the client issues the QUIT command from the TRANSACTION state,
+   the POP3 session enters the UPDATE state.  (Note that if the client
+   issues the QUIT command from the AUTHORIZATION state, the POP3
+   session terminates but does NOT enter the UPDATE state.)
+
+           QUIT
+               Arguments: none
+               Restrictions: none
+               Discussion:
+
+                 The POP3 server removes all messages marked as deleted
+                 from the maildrop.  It then releases the
+                 exclusive-access lock on the maildrop and replies as
+                 to the success of these operations.  The TCP
+                 connection is then closed.
+
+               Possible Responses:
+                   +OK
+               Examples:
+                   C:    QUIT
+                   S:    +OK dewey POP3 server signing off (maildrop
+                         empty)
+                     ...
+                   C:    QUIT
+                   S:    +OK dewey POP3 server signing off (2 messages
+                         left)
+                     ...
+
+
+
+
+
+Rose                                                           [Page 10]
+
+RFC 1460                          POP3                         June 1993
+
+
+7. Optional POP3 Commands
+
+   The POP3 commands discussed above must be supported by all minimal
+   implementations of POP3 servers.
+
+   The optional POP3 commands described below permit a POP3 client
+   greater freedom in message handling, while preserving a simple POP3
+   server implementation.
+
+                 NOTE: This memo STRONGLY encourages implementations to
+                 support these commands in lieu of developing augmented
+                 drop and scan listings.  In short, the philosophy of
+                 this memo is to put intelligence in the part of the
+                 POP3 client and not the POP3 server.
+
+           TOP msg n
+               Arguments: a message-id (required) and a number.  This
+                   message-id may NOT refer to a message marked as
+                   deleted.
+               Restrictions: may only be given in the TRANSACTION state.
+               Discussion:
+
+                 If the POP3 server issues a positive response, then
+                 the response given is multi-line.  After the initial
+                 +OK, the POP3 server sends the headers of the message,
+                 the blank line separating the headers from the body,
+                 and then the number of lines indicated message's body,
+                 being careful to byte-stuff the termination character
+                 (as with all multi-line responses).
+
+                 Note that if the number of lines requested by the POP3
+                 client is greater than than the number of lines in the
+                 body, then the POP3 server sends the entire message.
+
+               Possible Responses:
+                   +OK top of message follows
+                   -ERR no such message
+               Examples:
+                   C:    TOP 10
+                   S:    +OK
+                   S:    <the POP3 server sends the headers of the
+                          message, a blank line, and the first 10 lines
+                          of the body of the message>
+                   S:    .
+                     ...
+                   C:    TOP 100
+                   S:    -ERR no such message
+
+
+
+
+Rose                                                           [Page 11]
+
+RFC 1460                          POP3                         June 1993
+
+
+           APOP name digest
+               Arguments: a server specific user-id and a digest string
+                    (both required).
+               Restrictions: may only be given in the AUTHORIZATION
+                   state after the POP3 greeting
+               Discussion:
+
+                 Normally, each POP3 session starts with a USER/PASS
+                 exchange.  This results in a server/user-id specific
+                 password being sent in the clear on the network.  For
+                 intermittent use of POP3, this may not introduce a
+                 sizable risk.  However, many POP3 client
+                 implementations connect to the POP3 server on a
+                 regular basis -- to check for new mail.  Further the
+                 interval of session initiation may be on the order of
+                 five minutes.  Hence, the risk of password capture is
+                 greatly enhanced.
+
+                 An alternate method of authentication is required
+                 which provides for both origin authentication and
+                 replay protection, but which does not involve sending
+                 a password in the clear over the network.  The APOP
+                 command provides this functionality.
+
+                 A POP3 server which implements the APOP command will
+                 include a timestamp in its banner greeting.  The
+                 syntax of the timestamp corresponds to the "msg-id"
+                 in [RFC822], and MUST be different each time the POP3
+                 server issues a banner greeting.  For example, on a
+                 UNIX implementation in which a separate UNIX process
+                 is used for each instance of a POP3 server, the
+                 syntax of the timestamp might be:
+
+                    <process-ID.clock@hostname>
+
+                 where "process-ID" is the decimal value of the
+                 process's PID, clock is the decimal value of the
+                 system clock, and hostname is the fully-qualified
+                 domain-name corresponding to the host where the POP3
+                 server is running.
+
+                 The POP3 client makes note of this timestamp, and
+                 then issues the APOP command.  The "name" parameter
+                 has identical semantics to the "name" parameter of
+                 the USER command. The "digest" parameter is
+                 calculated by applying the MD5 algorithm [RFC1321] to
+                 a string consisting of the timestamp (including
+                 angle-brackets) followed by a shared secret.  This
+
+
+
+Rose                                                           [Page 12]
+
+RFC 1460                          POP3                         June 1993
+
+
+                 shared secret is a string known only to the POP3
+                 client and server. Great care should be taken to
+                 prevent unauthorized disclosure of the secret, as
+                 knowledge of the secret will allow any entity to
+                 successfully masquerade as the named user.  The
+                 "digest" parameter itself is a 16-octet value which
+                 is sent in hexadecimal format, using lower-case ASCII
+                 characters.
+
+                 When the POP3 server receives the APOP command, it
+                 verifies the digest provided.  If the digest is
+                 correct, the POP3 server issues a positive response,
+                 and the POP3 session enters the TRANSACTION state.
+                 Otherwise, a negative response is issued and the POP3
+                 session remains in the AUTHORIZATION state.
+
+               Possible Responses:
+                   +OK maildrop locked and ready
+                   -ERR permission denied
+               Examples:
+                   S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+                   C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+                   S: +OK maildrop has 1 message (369 octets)
+
+                 In this example, the shared secret is the string "tanstaaf".
+                 Hence, the MD5 algorithm is applied to the string
+
+                    <1896.697170952@dbc.mtview.ca.us>tanstaaf
+
+                 which produces a digest value of
+
+                    c4c9334bac560ecc979e58001b3e22fb
+
+8. POP3 Command Summary
+
+       Minimal POP3 Commands:
+           USER name               valid in the AUTHORIZATION state
+           PASS string
+           QUIT
+
+           STAT                    valid in the TRANSACTION state
+           LIST [msg]
+           RETR msg
+           DELE msg
+           NOOP
+           LAST
+           RSET
+
+
+
+
+Rose                                                           [Page 13]
+
+RFC 1460                          POP3                         June 1993
+
+
+           QUIT                    valid in the UPDATE state
+
+       Optional POP3 Commands:
+           APOP name digest        valid in the AUTHORIZATION state
+
+           TOP msg n               valid in the TRANSACTION state
+
+       POP3 Replies:
+           +OK
+           -ERR
+
+       Note that with the exception of the STAT command, the reply given
+       by the POP3 server to any command is significant only to "+OK"
+       and "-ERR".  Any text occurring after this reply may be ignored
+       by the client.
+
+9. Example POP3 Session
+
+    S: <wait for connection on TCP port 110>
+        ...
+    C: <open connection>
+    S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+    C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
+    S:    +OK mrose's maildrop has 2 messages (320 octets)
+    C:    STAT
+    S:    +OK 2 320
+    C:    LIST
+    S:    +OK 2 messages (320 octets)
+    S:    1 120
+    S:    2 200
+    S:    .
+    C:    RETR 1
+    S:    +OK 120 octets
+    S:    <the POP3 server sends message 1>
+    S:    .
+    C:    DELE 1
+    S:    +OK message 1 deleted
+    C:    RETR 2
+    S:    +OK 200 octets
+    S:    <the POP3 server sends message 2>
+    S:    .
+    C:    DELE 2
+    S:    +OK message 2 deleted
+    C:    QUIT
+    S:    +OK dewey POP3 server signing off (maildrop empty)
+    C:  <close connection>
+    S:  <wait for next connection>
+
+
+
+
+Rose                                                           [Page 14]
+
+RFC 1460                          POP3                         June 1993
+
+
+10. Message Format
+
+   All messages transmitted during a POP3 session are assumed to conform
+   to the standard for the format of Internet text messages [RFC822].
+
+   It is important to note that the byte count for a message on the
+   server host may differ from the octet count assigned to that message
+   due to local conventions for designating end-of-line.  Usually,
+   during the AUTHORIZATION state of the POP3 session, the POP3 client
+   can calculate the size of each message in octets when it parses the
+   maildrop into messages.  For example, if the POP3 server host
+   internally represents end-of-line as a single character, then the
+   POP3 server simply counts each occurrence of this character in a
+   message as two octets.  Note that lines in the message which start
+   with the termination octet need not be counted twice, since the POP3
+   client will remove all byte-stuffed termination characters when it
+   receives a multi-line response.
+
+11. The POP and the Split-UA model
+
+   The underlying paradigm in which the POP3 functions is that of a
+   split-UA model.  The POP3 client host, being a remote PC based
+   workstation, acts solely as a client to the message transport system.
+   It does not provide delivery/authentication services to others.
+   Hence, it is acting as a UA, on behalf of the person using the
+   workstation.  Furthermore, the workstation uses SMTP to enter mail
+   into the MTS.
+
+   In this sense, we have two UA functions which interface to the
+   message transport system: Posting (SMTP) and Retrieval (POP3).  The
+   entity which supports this type of environment is called a split-UA
+   (since the user agent is split between two hosts which must
+   interoperate to provide these functions).
+
+                 ASIDE:  Others might term this a remote-UA instead.
+                 There are arguments supporting the use of both terms.
+
+   This memo has explicitly referenced TCP as the underlying transport
+   agent for the POP3.  This need not be the case.  In the MZnet split-
+   UA, for example, personal micro-computer systems are used which do
+   not have IP-style networking capability [MZnet].  To connect to the
+   POP3 server host, a PC establishes a terminal connection using some
+   simple protocol (PhoneNet).  A program on the PC drives the
+   connection, first establishing a login session as a normal user.  The
+   login shell for this pseudo-user is a program which drives the other
+   half of the terminal protocol and communicates with one of two
+   servers.  Although MZnet can support several PCs, a single pseudo-
+   user login is present on the server host.  The user-id and password
+
+
+
+Rose                                                           [Page 15]
+
+RFC 1460                          POP3                         June 1993
+
+
+   for this pseudo-user login is known to all members of MZnet.  Hence,
+   the first action of the login shell, after starting the terminal
+   protocol, is to demand a USER/PASS authorization pair from the PC.
+   This second level of authorization is used to ascertain who is
+   interacting with the MTS.  Although the server host is deemed to
+   support a "trusted" MTS entity, PCs in MZnet are not.  Naturally, the
+   USER/PASS authorization pair for a PC is known only to the owner of
+   the PC (in theory, at least).
+
+   After successfully verifying the identity of the client, a modified
+   SMTP server is started, and the PC posts mail with the server host.
+   After the QUIT command is given to the SMTP server and it terminates,
+   a modified POP3 server is started, and the PC retrieves mail from the
+   server host.  After the QUIT command is given to the POP3 server and
+   it terminates, the login shell for the pseudo-user terminates the
+   terminal protocol and logs the job out.  The PC then closes the
+   terminal connection to the server host.
+
+   The SMTP server used by MZnet is modified in the sense that it knows
+   that it's talking to a user agent and not a "trusted" entity in the
+   message transport system.  Hence, it does performs the validation
+   activities normally performed by an entity in the MTS when it accepts
+   a message from a UA.
+
+   The POP3 server used by MZnet is modified in the sense that it does
+   not require a USER/PASS combination before entering the TRANSACTION
+   state.  The reason for this (of course) is that the PC has already
+   identified itself during the second-level authorization step
+   described above.
+
+                 NOTE: Truth in advertising laws require that the author
+                 of this memo state that MZnet has not actually been
+                 fully implemented.  The concepts presented and proven
+                 by the project led to the notion of the MZnet
+                 split-slot model.  This notion has inspired the
+                 split-UA concept described in this memo, led to the
+                 author's interest in the POP, and heavily influenced
+                 the the description of the POP3 herein.
+
+   In fact, some UAs present in the Internet already support the notion
+   of posting directly to an SMTP server and retrieving mail directly
+   from a POP3 server, even if the POP3 server and client resided on the
+   same host!
+
+                 ASIDE: this discussion raises an issue which this memo
+                 purposedly avoids: how does SMTP know that it's talking
+                 to a "trusted" MTS entity?
+
+
+
+
+Rose                                                           [Page 16]
+
+RFC 1460                          POP3                         June 1993
+
+
+12. References
+
+   [MZnet]   Stefferud, E., Sweet, J., and T. Domae, "MZnet: Mail
+             Service for Personal Micro-Computer Systems,:
+             Proceedings, IFIP 6.5 International Conference on
+             Computer Message Systems, Nottingham, U.K., May 1984.
+
+   [RFC821]  Postel, J., "Simple Mail Transfer Protocol", STD 10,
+             RFC 821, USC/Information Sciences Institute, August 1982.
+
+   [RFC822]  Crocker, D., "Standard for the Format of ARPA-Internet
+             Text Messages", STD 11, RFC 822, University of Delaware,
+             August 1982.
+
+   [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", MIT
+             Laboratory for Computer Science, April 1992.
+
+13. Security Considerations
+
+   It is conjectured that use of the APOP command provides origin
+   identification and replay protection for a POP3 session.
+   Accordingly, a POP3 server which implements both the PASS and APOP
+   commands must not allow both methods of access for a given user; that
+   is, for a given "USER name" either the PASS or APOP command is
+   allowed, but not both.
+
+   Otherwise, security issues are not discussed in this memo.
+
+14. Acknowledgements
+
+   The POP family has a long and checkered history.  Although primarily
+   a minor revision to [RFC1225], POP3 is based on the ideas presented
+   in RFCs 918, 937, and 1081.
+
+   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
+   provided significant comments on the APOP command.
+
+15. Author's Address
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   Mountain View, CA  94043-2186
+
+   Phone: +1 415 968 1052
+   Fax:   +1 415 968 2510
+
+   EMail: mrose@dbc.mtview.ca.us
+   X.500: rose, dbc, us
+
+
+
+Rose                                                           [Page 17]
+
\ No newline at end of file
diff --git a/RFC/rfc1521.txt b/RFC/rfc1521.txt
new file mode 100644
index 00000000..cb4ee75a
--- /dev/null
+++ b/RFC/rfc1521.txt
@@ -0,0 +1,4539 @@
+

+

+

+

+

+

+Network Working Group                                      N. Borenstein

+Request for Comments: 1521                                      Bellcore

+Obsoletes: 1341                                                 N. Freed

+Category: Standards Track                                       Innosoft

+                                                          September 1993

+

+

+         MIME (Multipurpose Internet Mail Extensions) Part One:

+                Mechanisms for Specifying and Describing

+                 the Format of Internet Message Bodies

+

+Status of this Memo

+

+   This RFC specifies an Internet standards track protocol for the

+   Internet community, and requests discussion and suggestions for

+   improvements.  Please refer to the current edition of the "Internet

+   Official Protocol Standards" for the standardization state and status

+   of this protocol.  Distribution of this memo is unlimited.

+

+Abstract

+

+   STD 11, RFC 822 defines a message representation protocol which

+   specifies considerable detail about message headers, but which leaves

+   the message content, or message body, as flat ASCII text.  This

+   document redefines the format of message bodies to allow multi-part

+   textual and non-textual message bodies to be represented and

+   exchanged without loss of information.  This is based on earlier work

+   documented in RFC 934 and STD 11, RFC 1049, but extends and revises

+   that work.  Because RFC 822 said so little about message bodies, this

+   document is largely orthogonal to (rather than a revision of) RFC

+   822.

+

+   In particular, this document is designed to provide facilities to

+   include multiple objects in a single message, to represent body text

+   in character sets other than US-ASCII, to represent formatted multi-

+   font text messages, to represent non-textual material such as images

+   and audio fragments, and generally to facilitate later extensions

+   defining new types of Internet mail for use by cooperating mail

+   agents.

+

+   This document does NOT extend Internet mail header fields to permit

+   anything other than US-ASCII text data.  Such extensions are the

+   subject of a companion document [RFC-1522].

+

+   This document is a revision of RFC 1341.  Significant differences

+   from RFC 1341 are summarized in Appendix H.

+

+

+

+

+

+Borenstein & Freed                                              [Page 1]

+

+RFC 1521                          MIME                    September 1993

+

+

+Table of Contents

+

+   1.     Introduction.......................................  3

+   2.     Notations, Conventions, and Generic BNF Grammar....  6

+   3.     The MIME-Version Header Field......................  7

+   4.     The Content-Type Header Field......................  9

+   5.     The Content-Transfer-Encoding Header Field......... 13

+   5.1.   Quoted-Printable Content-Transfer-Encoding......... 18

+   5.2.   Base64 Content-Transfer-Encoding................... 21

+   6.     Additional Content-Header Fields................... 23

+   6.1.   Optional Content-ID Header Field................... 23

+   6.2.   Optional Content-Description Header Field.......... 24

+   7.     The Predefined Content-Type Values................. 24

+   7.1.   The Text Content-Type.............................. 24

+   7.1.1. The charset parameter.............................. 25

+   7.1.2. The Text/plain subtype............................. 28

+   7.2.   The Multipart Content-Type......................... 28

+   7.2.1. Multipart:  The common syntax...................... 29

+   7.2.2. The Multipart/mixed (primary) subtype.............. 34

+   7.2.3. The Multipart/alternative subtype.................. 34

+   7.2.4. The Multipart/digest subtype....................... 36

+   7.2.5. The Multipart/parallel subtype..................... 37

+   7.2.6. Other Multipart subtypes........................... 37

+   7.3.   The Message Content-Type........................... 38

+   7.3.1. The Message/rfc822 (primary) subtype............... 38

+   7.3.2. The Message/Partial subtype........................ 39

+   7.3.3. The Message/External-Body subtype.................. 42

+   7.3.3.1.  The "ftp" and "tftp" access-types............... 44

+   7.3.3.2.  The "anon-ftp" access-type...................... 45

+   7.3.3.3.  The "local-file" and "afs" access-types......... 45

+   7.3.3.4.  The "mail-server" access-type................... 45

+   7.3.3.5.  Examples and Further Explanations............... 46

+   7.4.   The Application Content-Type....................... 49

+   7.4.1. The Application/Octet-Stream (primary) subtype..... 50

+   7.4.2. The Application/PostScript subtype................. 50

+   7.4.3. Other Application subtypes......................... 53

+   7.5.   The Image Content-Type............................. 53

+   7.6.   The Audio Content-Type............................. 54

+   7.7.   The Video Content-Type............................. 54

+   7.8.   Experimental Content-Type Values................... 54

+   8.     Summary............................................ 56

+   9.     Security Considerations............................ 56

+   10.    Authors' Addresses................................. 57

+   11.    Acknowledgements................................... 58

+   Appendix A -- Minimal MIME-Conformance.................... 60

+   Appendix B -- General Guidelines For Sending Email Data... 63

+   Appendix C -- A Complex Multipart Example................. 66

+   Appendix D -- Collected Grammar........................... 68

+

+

+

+Borenstein & Freed                                              [Page 2]

+

+RFC 1521                          MIME                    September 1993

+

+

+   Appendix E -- IANA Registration Procedures................ 72

+   E.1  Registration of New Content-type/subtype Values...... 72

+   E.2  Registration of New Access-type Values

+        for Message/external-body............................ 73

+   Appendix F -- Summary of the Seven Content-types.......... 74

+   Appendix G -- Canonical Encoding Model.................... 76

+   Appendix H -- Changes from RFC 1341....................... 78

+   References................................................ 80

+

+1.    Introduction

+

+   Since its publication in 1982, STD 11, RFC 822 [RFC-822] has defined

+   the standard format of textual mail messages on the Internet.  Its

+   success has been such that the RFC 822 format has been adopted,

+   wholly or partially, well beyond the confines of the Internet and the

+   Internet SMTP transport defined by STD 10, RFC 821 [RFC-821].  As the

+   format has seen wider use, a number of limitations have proven

+   increasingly restrictive for the user community.

+

+   RFC 822 was intended to specify a format for text messages.  As such,

+   non-text messages, such as multimedia messages that might include

+   audio or images, are simply not mentioned.  Even in the case of text,

+   however, RFC 822 is inadequate for the needs of mail users whose

+   languages require the use of character sets richer than US ASCII

+   [US-ASCII]. Since RFC 822 does not specify mechanisms for mail

+   containing audio, video, Asian language text, or even text in most

+   European languages, additional specifications are needed.

+

+   One of the notable limitations of RFC 821/822 based mail systems is

+   the fact that they limit the contents of electronic mail messages to

+   relatively short lines of seven-bit ASCII.  This forces users to

+   convert any non-textual data that they may wish to send into seven-

+   bit bytes representable as printable ASCII characters before invoking

+   a local mail UA (User Agent, a program with which human users send

+   and receive mail). Examples of such encodings currently used in the

+   Internet include pure hexadecimal, uuencode, the 3-in-4 base 64

+   scheme specified in RFC 1421, the Andrew Toolkit Representation

+   [ATK], and many others.

+

+   The limitations of RFC 822 mail become even more apparent as gateways

+   are designed to allow for the exchange of mail messages between RFC

+   822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the

+   inclusion of non-textual body parts within electronic mail messages.

+   The current standards for the mapping of X.400 messages to RFC 822

+   messages specify either that X.400 non-textual body parts must be

+   converted to (not encoded in) an ASCII format, or that they must be

+   discarded, notifying the RFC 822 user that discarding has occurred.

+   This is clearly undesirable, as information that a user may wish to

+

+

+

+Borenstein & Freed                                              [Page 3]

+

+RFC 1521                          MIME                    September 1993

+

+

+   receive is lost.  Even though a user's UA may not have the capability

+   of dealing with the non-textual body part, the user might have some

+   mechanism external to the UA that can extract useful information from

+   the body part.  Moreover, it does not allow for the fact that the

+   message may eventually be gatewayed back into an X.400 message

+   handling system (i.e., the X.400 message is "tunneled" through

+   Internet mail), where the non-textual information would definitely

+   become useful again.

+

+   This document describes several mechanisms that combine to solve most

+   of these problems without introducing any serious incompatibilities

+   with the existing world of RFC 822 mail.  In particular, it

+   describes:

+

+   1. A MIME-Version header field, which uses a version number to

+       declare a message to be conformant with this specification and

+       allows mail processing agents to distinguish between such

+       messages and those generated by older or non-conformant software,

+       which is presumed to lack such a field.

+

+   2. A Content-Type header field, generalized from RFC 1049 [RFC-1049],

+       which can be used to specify the type and subtype of data in the

+       body of a message and to fully specify the native representation

+       (encoding) of such data.

+

+       2.a. A "text" Content-Type value, which can be used to represent

+            textual information in a number of character sets and

+            formatted text description languages in a standardized

+            manner.

+

+       2.b. A "multipart" Content-Type value, which can be used to

+            combine several body parts, possibly of differing types of

+            data, into a single message.

+

+       2.c. An "application" Content-Type value, which can be used to

+            transmit application data or binary data, and hence, among

+            other uses, to implement an electronic mail file transfer

+            service.

+

+       2.d. A "message" Content-Type value, for encapsulating another

+            mail message.

+

+       2.e An "image" Content-Type value, for transmitting still image

+            (picture) data.

+

+       2.f. An "audio" Content-Type value, for transmitting audio or

+            voice data.

+

+

+

+

+Borenstein & Freed                                              [Page 4]

+

+RFC 1521                          MIME                    September 1993

+

+

+       2.g. A "video" Content-Type value, for transmitting video or

+            moving image data, possibly with audio as part of the

+            composite video data format.

+

+   3. A Content-Transfer-Encoding header field, which can be used to

+       specify an auxiliary encoding that was applied to the data in

+       order to allow it to pass through mail transport mechanisms which

+       may have data or character set limitations.

+

+   4. Two additional header fields that can be used to further describe

+       the data in a message body, the Content-ID and Content-

+       Description header fields.

+

+   MIME has been carefully designed as an extensible mechanism, and it

+   is expected that the set of content-type/subtype pairs and their

+   associated parameters will grow significantly with time.  Several

+   other MIME fields, notably including character set names, are likely

+   to have new values defined over time.  In order to ensure that the

+   set of such values is developed in an orderly, well-specified, and

+   public manner, MIME defines a registration process which uses the

+   Internet Assigned Numbers Authority (IANA) as a central registry for

+   such values.  Appendix E provides details about how IANA registration

+   is accomplished.

+

+   Finally, to specify and promote interoperability, Appendix A of this

+   document provides a basic applicability statement for a subset of the

+   above mechanisms that defines a minimal level of "conformance" with

+   this document.

+

+      HISTORICAL NOTE: Several of the mechanisms described in this

+      document may seem somewhat strange or even baroque at first

+      reading.  It is important to note that compatibility with existing

+      standards AND robustness across existing practice were two of the

+      highest priorities of the working group that developed this

+      document.  In particular, compatibility was always favored over

+      elegance.

+

+   MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341]

+   [RFC-1342].  This document is a relatively minor updating of RFC

+   1341, and is intended to supersede it.  The differences between this

+   document and RFC 1341 are summarized in Appendix H.  Please refer to

+   the current edition of the "IAB Official Protocol Standards" for the

+   standardization state and status of this protocol.  Several other RFC

+   documents will be of interest to the MIME implementor, in particular

+   [RFC 1343], [RFC-1344], and [RFC-1345].

+

+

+

+

+

+

+Borenstein & Freed                                              [Page 5]

+

+RFC 1521                          MIME                    September 1993

+

+

+2.    Notations, Conventions, and Generic BNF Grammar

+

+   This document is being published in two versions, one as plain ASCII

+   text and one as PostScript (PostScript is a trademark of Adobe

+   Systems Incorporated.).  While the text version is the official

+   specification, some will find the PostScript version easier to read.

+   The textual contents are identical.  An Andrew-format copy of this

+   document is also available from the first author (Borenstein).

+

+   Although the mechanisms specified in this document are all described

+   in prose, most are also described formally in the modified BNF

+   notation of RFC 822.  Implementors will need to be familiar with this

+   notation in order to understand this specification, and are referred

+   to RFC 822 for a complete explanation of the modified BNF notation.

+

+   Some of the modified BNF in this document makes reference to

+   syntactic entities that are defined in RFC 822 and not in this

+   document.  A complete formal grammar, then, is obtained by combining

+   the collected grammar appendix of this document with that of RFC 822

+   plus the modifications to RFC 822 defined in RFC 1123, which

+   specifically changes the syntax for `return', `date' and `mailbox'.

+

+   The term CRLF, in this document, refers to the sequence of the two

+   ASCII characters CR (13) and LF (10) which, taken together, in this

+   order, denote a line break in RFC 822 mail.

+

+   The term "character set" is used in this document to refer to a

+   method used with one or more tables to convert encoded text to a

+   series of octets.  This definition is intended to allow various kinds

+   of text encodings, from simple single-table mappings such as ASCII to

+   complex table switching methods such as those that use ISO 2022's

+   techniques.  However, a MIME character set name must fully specify

+   the mapping to be performed.

+

+   The term "message", when not further qualified, means either the

+   (complete or "top-level") message being transferred on a network, or

+   a message encapsulated in a body of type "message".

+

+   The term "body part", in this document, means one of the parts of the

+   body of a multipart entity. A body part has a header and a body, so

+   it makes sense to speak about the body of a body part.

+

+   The term "entity", in this document, means either a message or a body

+   part.  All kinds of entities share the property that they have a

+   header and a body.

+

+   The term "body", when not further qualified, means the body of an

+   entity, that is the body of either a message or of a body part.

+

+

+

+Borenstein & Freed                                              [Page 6]

+

+RFC 1521                          MIME                    September 1993

+

+

+      NOTE: The previous four definitions are clearly circular.  This is

+      unavoidable, since the overall structure of a MIME message is

+      indeed recursive.

+

+   In this document, all numeric and octet values are given in decimal

+   notation.

+

+   It must be noted that Content-Type values, subtypes, and parameter

+   names as defined in this document are case-insensitive.  However,

+   parameter values are case-sensitive unless otherwise specified for

+   the specific parameter.

+

+      FORMATTING NOTE: This document has been carefully formatted for

+      ease of reading.  The PostScript version of this document, in

+      particular, places notes like this one, which may be skipped by

+      the reader, in a smaller, italicized, font, and indents it as

+      well.  In the text version, only the indentation is preserved, so

+      if you are reading the text version of this you might consider

+      using the PostScript version instead. However, all such notes will

+      be indented and preceded by "NOTE:" or some similar introduction,

+      even in the text version.

+

+      The primary purpose of these non-essential notes is to convey

+      information about the rationale of this document, or to place this

+      document in the proper historical or evolutionary context.  Such

+      information may be skipped by those who are focused entirely on

+      building a conformant implementation, but may be of use to those

+      who wish to understand why this document is written as it is.

+

+      For ease of recognition, all BNF definitions have been placed in a

+      fixed-width font in the PostScript version of this document.

+

+3.    The MIME-Version Header Field

+

+   Since RFC 822 was published in 1982, there has really been only one

+   format standard for Internet messages, and there has been little

+   perceived need to declare the format standard in use.  This document

+   is an independent document that complements RFC 822. Although the

+   extensions in this document have been defined in such a way as to be

+   compatible with RFC 822, there are still circumstances in which it

+   might be desirable for a mail-processing agent to know whether a

+   message was composed with the new standard in mind.

+

+   Therefore, this document defines a new header field, "MIME-Version",

+   which is to be used to declare the version of the Internet message

+   body format standard in use.

+

+   Messages composed in accordance with this document MUST include such

+

+

+

+Borenstein & Freed                                              [Page 7]

+

+RFC 1521                          MIME                    September 1993

+

+

+   a header field, with the following verbatim text:

+

+   MIME-Version: 1.0

+

+   The presence of this header field is an assertion that the message

+   has been composed in compliance with this document.

+

+   Since it is possible that a future document might extend the message

+   format standard again, a formal BNF is given for the content of the

+   MIME-Version field:

+

+   version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

+

+   Thus, future format specifiers, which might replace or extend "1.0",

+   are constrained to be two integer fields, separated by a period.  If

+   a message is received with a MIME-version value other than "1.0", it

+   cannot be assumed to conform with this specification.

+

+   Note that the MIME-Version header field is required at the top level

+   of a message. It is not required for each body part of a multipart

+   entity.  It is required for the embedded headers of a body of type

+   "message" if and only if the embedded message is itself claimed to be

+   MIME-conformant.

+

+   It is not possible to fully specify how a mail reader that conforms

+   with MIME as defined in this document should treat a message that

+   might arrive in the future with some value of MIME-Version other than

+   "1.0".  However, conformant software is encouraged to check the

+   version number and at least warn the user if an unrecognized MIME-

+   version is encountered.

+

+   It is also worth noting that version control for specific content-

+   types is not accomplished using the MIME-Version mechanism.  In

+   particular, some formats (such as application/postscript) have

+   version numbering conventions that are internal to the document

+   format.  Where such conventions exist, MIME does nothing to supersede

+   them.  Where no such conventions exist, a MIME type might use a

+   "version" parameter in the content-type field if necessary.

+

+   NOTE TO IMPLEMENTORS: All header fields defined in this document,

+   including MIME-Version, Content-type, etc., are subject to the

+   general syntactic rules for header fields specified in RFC 822.  In

+   particular, all can include comments, which means that the following

+   two MIME-Version fields are equivalent:

+

+                    MIME-Version: 1.0

+                    MIME-Version: 1.0 (Generated by GBD-killer 3.7)

+

+

+

+

+Borenstein & Freed                                              [Page 8]

+

+RFC 1521                          MIME                    September 1993

+

+

+4.    The Content-Type Header Field

+

+   The purpose of the Content-Type field is to describe the data

+   contained in the body fully enough that the receiving user agent can

+   pick an appropriate agent or mechanism to present the data to the

+   user, or otherwise deal with the data in an appropriate manner.

+

+   HISTORICAL NOTE: The Content-Type header field was first defined in

+   RFC 1049.  RFC 1049 Content-types used a simpler and less powerful

+   syntax, but one that is largely compatible with the mechanism given

+   here.

+

+   The Content-Type header field is used to specify the nature of the

+   data in the body of an entity, by giving type and subtype

+   identifiers, and by providing auxiliary information that may be

+   required for certain types.  After the type and subtype names, the

+   remainder of the header field is simply a set of parameters,

+   specified in an attribute/value notation.  The set of meaningful

+   parameters differs for the different types.  In particular, there are

+   NO globally-meaningful parameters that apply to all content-types.

+   Global mechanisms are best addressed, in the MIME model, by the

+   definition of additional Content-* header fields.  The ordering of

+   parameters is not significant.  Among the defined parameters is a

+   "charset" parameter by which the character set used in the body may

+   be declared. Comments are allowed in accordance with RFC 822 rules

+   for structured header fields.

+

+   In general, the top-level Content-Type is used to declare the general

+   type of data, while the subtype specifies a specific format for that

+   type of data.  Thus, a Content-Type of "image/xyz" is enough to tell

+   a user agent that the data is an image, even if the user agent has no

+   knowledge of the specific image format "xyz".  Such information can

+   be used, for example, to decide whether or not to show a user the raw

+   data from an unrecognized subtype -- such an action might be

+   reasonable for unrecognized subtypes of text, but not for

+   unrecognized subtypes of image or audio.  For this reason, registered

+   subtypes of audio, image, text, and video, should not contain

+   embedded information that is really of a different type.  Such

+   compound types should be represented using the "multipart" or

+   "application" types.

+

+   Parameters are modifiers of the content-subtype, and do not

+   fundamentally affect the requirements of the host system.  Although

+   most parameters make sense only with certain content-types, others

+   are "global" in the sense that they might apply to any subtype.  For

+   example, the "boundary" parameter makes sense only for the

+   "multipart" content-type, but the "charset" parameter might make

+   sense with several content-types.

+

+

+

+Borenstein & Freed                                              [Page 9]

+

+RFC 1521                          MIME                    September 1993

+

+

+   An initial set of seven Content-Types is defined by this document.

+   This set of top-level names is intended to be substantially complete.

+   It is expected that additions to the larger set of supported types

+   can generally be accomplished by the creation of new subtypes of

+   these initial types.  In the future, more top-level types may be

+   defined only by an extension to this standard.  If another primary

+   type is to be used for any reason, it must be given a name starting

+   with "X-" to indicate its non-standard status and to avoid a

+   potential conflict with a future official name.

+

+   In the Augmented BNF notation of RFC 822, a Content-Type header field

+   value is defined as follows:

+

+     content  :=   "Content-Type"  ":"  type  "/"  subtype  *(";"

+     parameter)

+               ; case-insensitive matching of type and subtype

+

+     type :=          "application"     / "audio"

+               / "image"           / "message"

+               / "multipart"  / "text"

+               / "video"           / extension-token

+               ; All values case-insensitive

+

+     extension-token :=  x-token / iana-token

+

+     iana-token := <a publicly-defined extension token,

+               registered with IANA, as specified in

+               appendix E>

+

+     x-token := <The two characters "X-" or "x-" followed, with

+                 no intervening white space, by any token>

+

+     subtype := token ; case-insensitive

+

+     parameter := attribute "=" value

+

+     attribute := token   ; case-insensitive

+

+     value := token / quoted-string

+

+     token  :=  1*<any (ASCII) CHAR except SPACE, CTLs,

+                   or tspecials>

+

+     tspecials :=  "(" / ")" / "<" / ">" / "@"

+                /  "," / ";" / ":" / "\" / <">

+                /  "/" / "[" / "]" / "?" / "="

+               ; Must be in quoted-string,

+               ; to use within parameter values

+

+

+

+Borenstein & Freed                                             [Page 10]

+

+RFC 1521                          MIME                    September 1993

+

+

+   Note that the definition of "tspecials" is the same as the RFC 822

+   definition of "specials" with the addition of the three characters

+   "/", "?", and "=", and the removal of ".".

+

+   Note also that a subtype specification is MANDATORY.  There are no

+   default subtypes.

+

+   The type, subtype, and parameter names are not case sensitive.  For

+   example, TEXT, Text, and TeXt are all equivalent.  Parameter values

+   are normally case sensitive, but certain parameters are interpreted

+   to be case-insensitive, depending on the intended use.  (For example,

+   multipart boundaries are case-sensitive, but the "access-type" for

+   message/External-body is not case-sensitive.)

+

+   Beyond this syntax, the only constraint on the definition of subtype

+   names is the desire that their uses must not conflict.  That is, it

+   would be undesirable to have two different communities using

+   "Content-Type: application/foobar" to mean two different things.  The

+   process of defining new content-subtypes, then, is not intended to be

+   a mechanism for imposing restrictions, but simply a mechanism for

+   publicizing the usages. There are, therefore, two acceptable

+   mechanisms for defining new Content-Type subtypes:

+

+            1.  Private values (starting with "X-") may be

+                defined bilaterally between two cooperating

+                agents without outside registration or

+                standardization.

+

+            2.  New standard values must be documented,

+                registered with, and approved by IANA, as

+                described in Appendix E.  Where intended for

+                public use, the formats they refer to must

+                also be defined by a published specification,

+                and possibly offered for standardization.

+

+   The seven standard initial predefined Content-Types are detailed in

+   the bulk of this document.  They are:

+

+    text -- textual information.  The primary subtype,

+         "plain", indicates plain (unformatted) text.  No

+         special software is required to get the full

+         meaning of the text, aside from support for the

+         indicated character set.  Subtypes are to be used

+         for enriched text in forms where application

+         software may enhance the appearance of the text,

+         but such software must not be required in order to

+         get the general idea of the content.  Possible

+         subtypes thus include any readable word processor

+

+

+

+Borenstein & Freed                                             [Page 11]

+

+RFC 1521                          MIME                    September 1993

+

+

+         format.  A very simple and portable subtype,

+         richtext, was defined in RFC 1341, with a future

+         revision expected.

+

+    multipart -- data consisting of multiple parts of

+         independent data types.  Four initial subtypes

+         are defined, including the primary "mixed"

+         subtype, "alternative" for representing the same

+         data in multiple formats, "parallel" for parts

+         intended to be viewed simultaneously, and "digest"

+         for multipart entities in which each part is of

+         type "message".

+

+    message -- an encapsulated message.  A body of

+         Content-Type "message" is itself all or part of a

+         fully formatted RFC 822 conformant message which

+         may contain its own different Content-Type header

+         field.  The primary subtype is "rfc822".  The

+         "partial" subtype is defined for partial messages,

+         to permit the fragmented transmission of bodies

+         that are thought to be too large to be passed

+         through mail transport facilities.  Another

+         subtype, "External-body", is defined for

+         specifying large bodies by reference to an

+         external data source.

+

+    image -- image data.  Image requires a display device

+         (such as a graphical display, a printer, or a FAX

+         machine) to view the information.  Initial

+         subtypes are defined for two widely-used image

+         formats, jpeg and gif.

+

+    audio -- audio data, with initial subtype "basic".

+         Audio requires an audio output device (such as a

+         speaker or a telephone) to "display" the contents.

+

+    video -- video data.  Video requires the capability to

+         display moving images, typically including

+         specialized hardware and software.  The initial

+         subtype is "mpeg".

+

+    application -- some other kind of data, typically

+         either uninterpreted binary data or information to

+         be processed by a mail-based application.  The

+         primary subtype, "octet-stream", is to be used in

+         the case of uninterpreted binary data, in which

+         case the simplest recommended action is to offer

+         to write the information into a file for the user.

+

+

+

+Borenstein & Freed                                             [Page 12]

+

+RFC 1521                          MIME                    September 1993

+

+

+         An additional subtype, "PostScript", is defined

+         for transporting PostScript documents in bodies.

+         Other expected uses for "application" include

+         spreadsheets, data for mail-based scheduling

+         systems, and languages for "active"

+         (computational) email.  (Note that active email

+         and other application data may entail several

+         security considerations, which are discussed later

+         in this memo, particularly in the context of

+         application/PostScript.)

+

+   Default RFC 822 messages are typed by this protocol as plain text in

+   the US-ASCII character set, which can be explicitly specified as

+   "Content-type: text/plain; charset=us-ascii".  If no Content-Type is

+   specified, this default is assumed.  In the presence of a MIME-

+   Version header field, a receiving User Agent can also assume that

+   plain US-ASCII text was the sender's intent.  In the absence of a

+   MIME-Version specification, plain US-ASCII text must still be

+   assumed, but the sender's intent might have been otherwise.

+

+      RATIONALE: In the absence of any Content-Type header field or

+      MIME-Version header field, it is impossible to be certain that a

+      message is actually text in the US-ASCII character set, since it

+      might well be a message that, using the conventions that predate

+      this document, includes text in another character set or non-

+      textual data in a manner that cannot be automatically recognized

+      (e.g., a uuencoded compressed UNIX tar file).  Although there is

+      no fully acceptable alternative to treating such untyped messages

+      as "text/plain; charset=us-ascii", implementors should remain

+      aware that if a message lacks both the MIME-Version and the

+      Content-Type header fields, it may in practice contain almost

+      anything.

+

+   It should be noted that the list of Content-Type values given here

+   may be augmented in time, via the mechanisms described above, and

+   that the set of subtypes is expected to grow substantially.

+

+   When a mail reader encounters mail with an unknown Content-type

+   value, it should generally treat it as equivalent to

+   "application/octet-stream", as described later in this document.

+

+5.    The Content-Transfer-Encoding Header Field

+

+   Many Content-Types which could usefully be transported via email are

+   represented, in their "natural" format, as 8-bit character or binary

+   data.  Such data cannot be transmitted over some transport protocols.

+   For example, RFC 821 restricts mail messages to 7-bit US-ASCII data

+   with lines no longer than 1000 characters.

+

+

+

+Borenstein & Freed                                             [Page 13]

+

+RFC 1521                          MIME                    September 1993

+

+

+   It is necessary, therefore, to define a standard mechanism for re-

+   encoding such data into a 7-bit short-line format.  This document

+   specifies that such encodings will be indicated by a new "Content-

+   Transfer-Encoding" header field.  The Content-Transfer-Encoding field

+   is used to indicate the type of transformation that has been used in

+   order to represent the body in an acceptable manner for transport.

+

+   Unlike Content-Types, a proliferation of Content-Transfer-Encoding

+   values is undesirable and unnecessary.  However, establishing only a

+   single Content-Transfer-Encoding mechanism does not seem possible.

+   There is a tradeoff between the desire for a compact and efficient

+   encoding of largely-binary data and the desire for a readable

+   encoding of data that is mostly, but not entirely, 7-bit data.  For

+   this reason, at least two encoding mechanisms are necessary: a

+   "readable" encoding and a "dense" encoding.

+

+   The Content-Transfer-Encoding field is designed to specify an

+   invertible mapping between the "native" representation of a type of

+   data and a representation that can be readily exchanged using 7 bit

+   mail transport protocols, such as those defined by RFC 821 (SMTP).

+   This field has not been defined by any previous standard. The field's

+   value is a single token specifying the type of encoding, as

+   enumerated below.  Formally:

+

+   encoding := "Content-Transfer-Encoding" ":" mechanism

+

+   mechanism :=     "7bit"  ;  case-insensitive

+                  / "quoted-printable"

+                  / "base64"

+                  / "8bit"

+                  / "binary"

+                  / x-token

+

+   These values are not case sensitive.  That is, Base64 and BASE64 and

+   bAsE64 are all equivalent.  An encoding type of 7BIT requires that

+   the body is already in a seven-bit mail-ready representation.  This

+   is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is

+   assumed if the Content-Transfer-Encoding header field is not present.

+

+   The values "8bit", "7bit", and "binary" all mean that NO encoding has

+   been performed. However, they are potentially useful as indications

+   of the kind of data contained in the object, and therefore of the

+   kind of encoding that might need to be performed for transmission in

+   a given transport system.  In particular:

+

+       "7bit" means that the data is all represented as short

+            lines of US-ASCII data.

+

+

+

+

+Borenstein & Freed                                             [Page 14]

+

+RFC 1521                          MIME                    September 1993

+

+

+       "8bit" means that the lines are short, but there may be

+            non-ASCII characters (octets with the high-order

+            bit set).

+

+       "Binary" means that not only may non-ASCII characters

+            be present, but also that the lines are not

+            necessarily short enough for SMTP transport.

+

+   The difference between "8bit" (or any other conceivable bit-width

+   token) and the "binary" token is that "binary" does not require

+   adherence to any limits on line length or to the SMTP CRLF semantics,

+   while the bit-width tokens do require such adherence.  If the body

+   contains data in any bit-width other than 7-bit, the appropriate

+   bit-width Content-Transfer-Encoding token must be used (e.g., "8bit"

+   for unencoded 8 bit wide data).  If the body contains binary data,

+   the "binary" Content-Transfer-Encoding token must be used.

+

+      NOTE: The distinction between the Content-Transfer-Encoding values

+      of "binary", "8bit", etc.  may seem unimportant, in that all of

+      them really mean "none" -- that is, there has been no encoding of

+      the data for transport.  However, clear labeling will be of

+      enormous value to gateways between future mail transport systems

+      with differing capabilities in transporting data that do not meet

+      the restrictions of RFC 821 transport.

+

+      Mail transport for unencoded 8-bit data is defined in RFC-1426

+      [RFC-1426].  As of the publication of this document, there are no

+      standardized Internet mail transports for which it is legitimate

+      to include unencoded binary data in mail bodies.  Thus there are

+      no circumstances in which the "binary" Content-Transfer-Encoding

+      is actually legal on the Internet.  However, in the event that

+      binary mail transport becomes a reality in Internet mail, or when

+      this document is used in conjunction with any other binary-capable

+      transport mechanism, binary bodies should be labeled as such using

+      this mechanism.

+

+      NOTE: The five values defined for the Content-Transfer-Encoding

+      field imply nothing about the Content-Type other than the

+      algorithm by which it was encoded or the transport system

+      requirements if unencoded.

+

+   Implementors may, if necessary, define new Content-Transfer-Encoding

+   values, but must use an x-token, which is a name prefixed by "X-" to

+   indicate its non-standard status, e.g., "Content-Transfer-Encoding:

+   x-my-new-encoding".  However, unlike Content-Types and subtypes, the

+   creation of new Content-Transfer-Encoding values is explicitly and

+   strongly discouraged, as it seems likely to hinder interoperability

+   with little potential benefit.  Their use is allowed only as the

+

+

+

+Borenstein & Freed                                             [Page 15]

+

+RFC 1521                          MIME                    September 1993

+

+

+   result of an agreement between cooperating user agents.

+

+   If a Content-Transfer-Encoding header field appears as part of a

+   message header, it applies to the entire body of that message.  If a

+   Content-Transfer-Encoding header field appears as part of a body

+   part's headers, it applies only to the body of that body part.  If an

+   entity is of type "multipart" or "message", the Content-Transfer-

+   Encoding is not permitted to have any value other than a bit width

+   (e.g., "7bit", "8bit", etc.) or "binary".

+

+   It should be noted that email is character-oriented, so that the

+   mechanisms described here are mechanisms for encoding arbitrary octet

+   streams, not bit streams.  If a bit stream is to be encoded via one

+   of these mechanisms, it must first be converted to an 8-bit byte

+   stream using the network standard bit order ("big-endian"), in which

+   the earlier bits in a stream become the higher-order bits in a byte.

+   A bit stream not ending at an 8-bit boundary must be padded with

+   zeroes.  This document provides a mechanism for noting the addition

+   of such padding in the case of the application Content-Type, which

+   has a "padding" parameter.

+

+   The encoding mechanisms defined here explicitly encode all data in

+   ASCII.  Thus, for example, suppose an entity has header fields such

+   as:

+

+        Content-Type: text/plain; charset=ISO-8859-1

+        Content-transfer-encoding: base64

+

+   This must be interpreted to mean that the body is a base64 ASCII

+   encoding of data that was originally in ISO-8859-1, and will be in

+   that character set again after decoding.

+

+   The following sections will define the two standard encoding

+   mechanisms.  The definition of new content-transfer-encodings is

+   explicitly discouraged and should only occur when absolutely

+   necessary.  All content-transfer-encoding namespace except that

+   beginning with "X-" is explicitly reserved to the IANA for future

+   use.  Private agreements about content-transfer-encodings are also

+   explicitly discouraged.

+

+   Certain Content-Transfer-Encoding values may only be used on certain

+   Content-Types.  In particular, it is expressly forbidden to use any

+   encodings other than "7bit", "8bit", or "binary" with any Content-

+   Type that recursively includes other Content-Type fields, notably the

+   "multipart" and "message" Content-Types.  All encodings that are

+   desired for bodies of type multipart or message must be done at the

+   innermost level, by encoding the actual body that needs to be

+   encoded.

+

+

+

+Borenstein & Freed                                             [Page 16]

+

+RFC 1521                          MIME                    September 1993

+

+

+      NOTE ON ENCODING RESTRICTIONS: Though the prohibition against

+      using content-transfer-encodings on data of type multipart or

+      message may seem overly restrictive, it is necessary to prevent

+      nested encodings, in which data are passed through an encoding

+      algorithm multiple times, and must be decoded multiple times in

+      order to be properly viewed.  Nested encodings add considerable

+      complexity to user agents: aside from the obvious efficiency

+      problems with such multiple encodings, they can obscure the basic

+      structure of a message.  In particular, they can imply that

+      several decoding operations are necessary simply to find out what

+      types of objects a message contains.  Banning nested encodings may

+      complicate the job of certain mail gateways, but this seems less

+      of a problem than the effect of nested encodings on user agents.

+

+      NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-

+      TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding

+      could be inferred from the characteristics of the Content-Type

+      that is to be encoded, or, at the very least, that certain

+      Content-Transfer-Encodings could be mandated for use with specific

+      Content-Types. There are several reasons why this is not the case.

+      First, given the varying types of transports used for mail, some

+      encodings may be appropriate for some Content-Type/transport

+      combinations and not for others.  (For example, in an 8-bit

+      transport, no encoding would be required for text in certain

+      character sets, while such encodings are clearly required for 7-

+      bit SMTP.)  Second, certain Content-Types may require different

+      types of transfer encoding under different circumstances. For

+      example, many PostScript bodies might consist entirely of short

+      lines of 7-bit data and hence require little or no encoding.

+      Other PostScript bodies (especially those using Level 2

+      PostScript's binary encoding mechanism) may only be reasonably

+      represented using a binary transport encoding. Finally, since

+      Content-Type is intended to be an open-ended specification

+      mechanism, strict specification of an association between

+      Content-Types and encodings effectively couples the specification

+      of an application protocol with a specific lower-level transport.

+      This is not desirable since the developers of a Content-Type

+      should not have to be aware of all the transports in use and what

+      their limitations are.

+

+      NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64

+      encodings are designed so that conversion between them is

+      possible.  The only issue that arises in such a conversion is the

+      handling of line breaks.  When converting from quoted-printable to

+      base64 a line break must be converted into a CRLF sequence.

+      Similarly, a CRLF sequence in base64 data must be converted to a

+      quoted-printable line break, but ONLY when converting text data.

+

+

+

+

+Borenstein & Freed                                             [Page 17]

+

+RFC 1521                          MIME                    September 1993

+

+

+      NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in

+      earlier drafts of this memo, regarding the model for when email

+      data was to be converted to canonical form and encoded, and in

+      particular how this process would affect the treatment of CRLFs,

+      given that the representation of newlines varies greatly from

+      system to system, and the relationship between content-transfer-

+      encodings and character sets.  For this reason, a canonical model

+      for encoding is presented as Appendix G.

+

+5.1.  Quoted-Printable Content-Transfer-Encoding

+

+   The Quoted-Printable encoding is intended to represent data that

+   largely consists of octets that correspond to printable characters in

+   the ASCII character set.  It encodes the data in such a way that the

+   resulting octets are unlikely to be modified by mail transport.  If

+   the data being encoded are mostly ASCII text, the encoded form of the

+   data remains largely recognizable by humans.  A body which is

+   entirely ASCII may also be encoded in Quoted-Printable to ensure the

+   integrity of the data should the message pass through a character-

+   translating, and/or line-wrapping gateway.

+

+   In this encoding, octets are to be represented as determined by the

+   following rules:

+

+      Rule #1: (General 8-bit representation) Any octet, except those

+      indicating a line break according to the newline convention of the

+      canonical (standard) form of the data being encoded, may be

+      represented by an "=" followed by a two digit hexadecimal

+      representation of the octet's value.  The digits of the

+      hexadecimal alphabet, for this purpose, are "0123456789ABCDEF".

+      Uppercase letters must be used when sending hexadecimal data,

+      though a robust implementation may choose to recognize lowercase

+      letters on receipt.  Thus, for example, the value 12 (ASCII form

+      feed) can be represented by "=0C", and the value 61 (ASCII EQUAL

+      SIGN) can be represented by "=3D".  Except when the following

+      rules allow an alternative encoding, this rule is mandatory.

+

+      Rule #2: (Literal representation) Octets with decimal values of 33

+      through 60 inclusive, and 62 through 126, inclusive, MAY be

+      represented as the ASCII characters which correspond to those

+      octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN

+      through TILDE, respectively).

+

+      Rule #3: (White Space): Octets with values of 9 and 32 MAY be

+      represented as ASCII TAB (HT) and SPACE characters, respectively,

+      but MUST NOT be so represented at the end of an encoded line. Any

+      TAB (HT) or SPACE characters on an encoded line MUST thus be

+      followed on that line by a printable character.  In particular, an

+

+

+

+Borenstein & Freed                                             [Page 18]

+

+RFC 1521                          MIME                    September 1993

+

+

+      "=" at the end of an encoded line, indicating a soft line break

+      (see rule #5) may follow one or more TAB (HT) or SPACE characters.

+      It follows that an octet with value 9 or 32 appearing at the end

+      of an encoded line must be represented according to Rule #1.  This

+      rule is necessary because some MTAs (Message Transport Agents,

+      programs which transport messages from one user to another, or

+      perform a part of such transfers) are known to pad lines of text

+      with SPACEs, and others are known to remove "white space"

+      characters from the end of a line.  Therefore, when decoding a

+      Quoted-Printable body, any trailing white space on a line must be

+      deleted, as it will necessarily have been added by intermediate

+      transport agents.

+

+      Rule #4 (Line Breaks): A line break in a text body, independent of

+      what its representation is following the canonical representation

+      of the data being encoded, must be represented by a (RFC 822) line

+      break, which is a CRLF sequence, in the Quoted-Printable encoding.

+      Since the canonical representation of types other than text do not

+      generally include the representation of line breaks, no hard line

+      breaks (i.e.  line breaks that are intended to be meaningful and

+      to be displayed to the user) should occur in the quoted-printable

+      encoding of such types.  Of course, occurrences of "=0D", "=0A",

+      "0A=0D" and "=0D=0A" will eventually be encountered.  In general,

+      however, base64 is preferred over quoted-printable for binary

+      data.

+

+      Note that many implementations may elect to encode the local

+      representation of various content types directly, as described in

+      Appendix G.  In particular, this may apply to plain text material

+      on systems that use newline conventions other than CRLF

+      delimiters. Such an implementation is permissible, but the

+      generation of line breaks must be generalized to account for the

+      case where alternate representations of newline sequences are

+      used.

+

+      Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES

+      that encoded lines be no more than 76 characters long. If longer

+      lines are to be encoded with the Quoted-Printable encoding, 'soft'

+      line breaks must be used. An equal sign as the last character on a

+      encoded line indicates such a non-significant ('soft') line break

+      in the encoded text. Thus if the "raw" form of the line is a

+      single unencoded line that says:

+

+          Now's the time for all folk to come to the aid of

+          their country.

+

+      This can be represented, in the Quoted-Printable encoding, as

+

+

+

+

+Borenstein & Freed                                             [Page 19]

+

+RFC 1521                          MIME                    September 1993

+

+

+          Now's the time =

+          for all folk to come=

+           to the aid of their country.

+

+      This provides a mechanism with which long lines are encoded in

+      such a way as to be restored by the user agent.  The 76 character

+      limit does not count the trailing CRLF, but counts all other

+      characters, including any equal signs.

+

+   Since the hyphen character ("-") is represented as itself in the

+   Quoted-Printable encoding, care must be taken, when encapsulating a

+   quoted-printable encoded body in a multipart entity, to ensure that

+   the encapsulation boundary does not appear anywhere in the encoded

+   body.  (A good strategy is to choose a boundary that includes a

+   character sequence such as "=_" which can never appear in a quoted-

+   printable body.  See the definition of multipart messages later in

+   this document.)

+

+      NOTE: The quoted-printable encoding represents something of a

+      compromise between readability and reliability in transport.

+      Bodies encoded with the quoted-printable encoding will work

+      reliably over most mail gateways, but may not work perfectly over

+      a few gateways, notably those involving translation into EBCDIC.

+      (In theory, an EBCDIC gateway could decode a quoted-printable body

+      and re-encode it using base64, but such gateways do not yet

+      exist.)  A higher level of confidence is offered by the base64

+      Content-Transfer-Encoding.  A way to get reasonably reliable

+      transport through EBCDIC gateways is to also quote the ASCII

+      characters

+

+             !"#$@[\]^`{|}~

+

+      according to rule #1.  See Appendix B for more information.

+

+   Because quoted-printable data is generally assumed to be line-

+   oriented, it is to be expected that the representation of the breaks

+   between the lines of quoted printable data may be altered in

+   transport, in the same manner that plain text mail has always been

+   altered in Internet mail when passing between systems with differing

+   newline conventions.  If such alterations are likely to constitute a

+   corruption of the data, it is probably more sensible to use the

+   base64 encoding rather than the quoted-printable encoding.

+

+   WARNING TO IMPLEMENTORS: If binary data are encoded in quoted-

+   printable, care must be taken to encode CR and LF characters as "=0D"

+   and "=0A", respectively.  In particular, a CRLF sequence in binary

+   data should be encoded as "=0D=0A".  Otherwise, if CRLF were

+   represented as a hard line break, it might be incorrectly decoded on

+

+

+

+Borenstein & Freed                                             [Page 20]

+

+RFC 1521                          MIME                    September 1993

+

+

+   platforms with different line break conventions.

+

+   For formalists, the syntax of quoted-printable data is described by

+   the following grammar:

+

+   quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)

+        ; Maximum line length of 76 characters excluding CRLF

+

+   ptext := octet /<any ASCII character except "=", SPACE, or TAB>

+        ; characters not listed as "mail-safe" in Appendix B

+        ; are also not recommended.

+

+   octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

+        ; octet must be used for characters > 127, =, SPACE, or TAB,

+        ; and is recommended for any characters not listed in

+        ; Appendix B as "mail-safe".

+

+5.2.  Base64 Content-Transfer-Encoding

+

+   The Base64 Content-Transfer-Encoding is designed to represent

+   arbitrary sequences of octets in a form that need not be humanly

+   readable.  The encoding and decoding algorithms are simple, but the

+   encoded data are consistently only about 33 percent larger than the

+   unencoded data.  This encoding is virtually identical to the one used

+   in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.

+   The base64 encoding is adapted from RFC 1421, with one change: base64

+   eliminates the "*" mechanism for embedded clear text.

+

+   A 65-character subset of US-ASCII is used, enabling 6 bits to be

+   represented per printable character. (The extra 65th character, "=",

+   is used to signify a special processing function.)

+

+      NOTE: This subset has the important property that it is

+      represented identically in all versions of ISO 646, including US

+      ASCII, and all characters in the subset are also represented

+      identically in all versions of EBCDIC.  Other popular encodings,

+      such as the encoding used by the uuencode utility and the base85

+      encoding specified as part of Level 2 PostScript, do not share

+      these properties, and thus do not fulfill the portability

+      requirements a binary transport encoding for mail must meet.

+

+   The encoding process represents 24-bit groups of input bits as output

+   strings of 4 encoded characters. Proceeding from left to right, a

+   24-bit input group is formed by concatenating 3 8-bit input groups.

+   These 24 bits are then treated as 4 concatenated 6-bit groups, each

+   of which is translated into a single digit in the base64 alphabet.

+   When encoding a bit stream via the base64 encoding, the bit stream

+   must be presumed to be ordered with the most-significant-bit first.

+

+

+

+Borenstein & Freed                                             [Page 21]

+

+RFC 1521                          MIME                    September 1993

+

+

+   That is, the first bit in the stream will be the high-order bit in

+   the first byte, and the eighth bit will be the low-order bit in the

+   first byte, and so on.

+

+   Each 6-bit group is used as an index into an array of 64 printable

+   characters. The character referenced by the index is placed in the

+   output string. These characters, identified in Table 1, below, are

+   selected so as to be universally representable, and the set excludes

+   characters with particular significance to SMTP (e.g., ".", CR, LF)

+   and to the encapsulation boundaries defined in this document (e.g.,

+   "-").

+

+                            Table 1: The Base64 Alphabet

+

+      Value Encoding  Value Encoding  Value Encoding  Value Encoding

+           0 A            17 R            34 i            51 z

+           1 B            18 S            35 j            52 0

+           2 C            19 T            36 k            53 1

+           3 D            20 U            37 l            54 2

+           4 E            21 V            38 m            55 3

+           5 F            22 W            39 n            56 4

+           6 G            23 X            40 o            57 5

+           7 H            24 Y            41 p            58 6

+           8 I            25 Z            42 q            59 7

+           9 J            26 a            43 r            60 8

+          10 K            27 b            44 s            61 9

+          11 L            28 c            45 t            62 +

+          12 M            29 d            46 u            63 /

+          13 N            30 e            47 v

+          14 O            31 f            48 w         (pad) =

+          15 P            32 g            49 x

+          16 Q            33 h            50 y

+

+   The output stream (encoded bytes) must be represented in lines of no

+   more than 76 characters each.  All line breaks or other characters

+   not found in Table 1 must be ignored by decoding software.  In base64

+   data, characters other than those in Table 1, line breaks, and other

+   white space probably indicate a transmission error, about which a

+   warning message or even a message rejection might be appropriate

+   under some circumstances.

+

+   Special processing is performed if fewer than 24 bits are available

+   at the end of the data being encoded.  A full encoding quantum is

+   always completed at the end of a body.  When fewer than 24 input bits

+   are available in an input group, zero bits are added (on the right)

+   to form an integral number of 6-bit groups.  Padding at the end of

+   the data is performed using the '=' character.  Since all base64

+   input is an integral number of octets, only the following cases can

+

+

+

+Borenstein & Freed                                             [Page 22]

+

+RFC 1521                          MIME                    September 1993

+

+

+   arise: (1) the final quantum of encoding input is an integral

+   multiple of 24 bits; here, the final unit of encoded output will be

+   an integral multiple of 4 characters with no "=" padding, (2) the

+   final quantum of encoding input is exactly 8 bits; here, the final

+   unit of encoded output will be two characters followed by two "="

+   padding characters, or (3) the final quantum of encoding input is

+   exactly 16 bits; here, the final unit of encoded output will be three

+   characters followed by one "=" padding character.

+

+   Because it is used only for padding at the end of the data, the

+   occurrence of any '=' characters may be taken as evidence that the

+   end of the data has been reached (without truncation in transit).  No

+   such assurance is possible, however, when the number of octets

+   transmitted was a multiple of three.

+

+   Any characters outside of the base64 alphabet are to be ignored in

+   base64-encoded data.  The same applies to any illegal sequence of

+   characters in the base64 encoding, such as "====="

+

+   Care must be taken to use the proper octets for line breaks if base64

+   encoding is applied directly to text material that has not been

+   converted to canonical form.  In particular, text line breaks must be

+   converted into CRLF sequences prior to base64 encoding. The important

+   thing to note is that this may be done directly by the encoder rather

+   than in a prior canonicalization step in some implementations.

+

+      NOTE: There is no need to worry about quoting apparent

+      encapsulation boundaries within base64-encoded parts of multipart

+      entities because no hyphen characters are used in the base64

+      encoding.

+

+6.    Additional Content-Header Fields

+

+6.1.  Optional Content-ID Header Field

+

+   In constructing a high-level user agent, it may be desirable to allow

+   one body to make reference to another.  Accordingly, bodies may be

+   labeled using the "Content-ID" header field, which is syntactically

+   identical to the "Message-ID" header field:

+

+   id :=  "Content-ID" ":" msg-id

+   Like the Message-ID values, Content-ID values must be generated to be

+   world-unique.

+

+   The Content-ID value may be used for uniquely identifying MIME

+   entities in several contexts, particularly for cacheing data

+   referenced by the message/external-body mechanism.  Although the

+   Content-ID header is generally optional, its use is mandatory in

+

+

+

+Borenstein & Freed                                             [Page 23]

+

+RFC 1521                          MIME                    September 1993

+

+

+   implementations which generate data of the optional MIME Content-type

+   "message/external-body".  That is, each message/external-body entity

+   must have a Content-ID field to permit cacheing of such data.

+

+   It is also worth noting that the Content-ID value has special

+   semantics in the case of the multipart/alternative content-type.

+   This is explained in the section of this document dealing with

+   multipart/alternative.

+

+6.2.  Optional Content-Description Header Field

+

+   The ability to associate some descriptive information with a given

+   body is often desirable. For example, it may be useful to mark an

+   "image" body as "a picture of the Space Shuttle Endeavor."  Such text

+   may be placed in the Content-Description header field.

+

+   description := "Content-Description" ":" *text

+

+   The description is presumed to be given in the US-ASCII character

+   set, although the mechanism specified in [RFC-1522] may be used for

+   non-US-ASCII Content-Description values.

+

+7.    The Predefined Content-Type Values

+

+   This document defines seven initial Content-Type values and an

+   extension mechanism for private or experimental types.  Further

+   standard types must be defined by new published specifications.  It

+   is expected that most innovation in new types of mail will take place

+   as subtypes of the seven types defined here.  The most essential

+   characteristics of the seven content-types are summarized in Appendix

+   F.

+

+7.1  The Text Content-Type

+

+   The text Content-Type is intended for sending material which is

+   principally textual in form.  It is the default Content-Type.  A

+   "charset" parameter may be used to indicate the character set of the

+   body text for some text subtypes, notably including the primary

+   subtype, "text/plain", which indicates plain (unformatted) text.  The

+   default Content-Type for Internet mail is "text/plain; charset=us-

+   ascii".

+

+   Beyond plain text, there are many formats for representing what might

+   be known as "extended text" -- text with embedded formatting and

+   presentation information.  An interesting characteristic of many such

+   representations is that they are to some extent readable even without

+   the software that interprets them.  It is useful, then, to

+   distinguish them, at the highest level, from such unreadable data as

+

+

+

+Borenstein & Freed                                             [Page 24]

+

+RFC 1521                          MIME                    September 1993

+

+

+   images, audio, or text represented in an unreadable form.  In the

+   absence of appropriate interpretation software, it is reasonable to

+   show subtypes of text to the user, while it is not reasonable to do

+   so with most nontextual data.

+

+   Such formatted textual data should be represented using subtypes of

+   text.  Plausible subtypes of text are typically given by the common

+   name of the representation format, e.g., "text/richtext" [RFC-1341].

+

+7.1.1.     The charset parameter

+

+   A critical parameter that may be specified in the Content-Type field

+   for text/plain data is the character set.  This is specified with a

+   "charset" parameter, as in:

+

+        Content-type: text/plain; charset=us-ascii

+

+   Unlike some other parameter values, the values of the charset

+   parameter are NOT case sensitive.  The default character set, which

+   must be assumed in the absence of a charset parameter, is US-ASCII.

+

+   The specification for any future subtypes of "text" must specify

+   whether or not they will also utilize a "charset" parameter, and may

+   possibly restrict its values as well.  When used with a particular

+   body, the semantics of the "charset" parameter should be identical to

+   those specified here for "text/plain", i.e., the body consists

+   entirely of characters in the given charset.  In particular, definers

+   of future text subtypes should pay close attention the the

+   implications of multibyte character sets for their subtype

+   definitions.

+

+   This RFC specifies the definition of the charset parameter for the

+   purposes of MIME to be a unique mapping of a byte stream to glyphs, a

+   mapping which does not require external profiling information.

+

+   An initial list of predefined character set names can be found at the

+   end of this section.  Additional character sets may be registered

+   with IANA, although the standardization of their use requires the

+   usual IESG [RFC-1340] review and approval.  Note that if the

+   specified character set includes 8-bit data, a Content-Transfer-

+   Encoding header field and a corresponding encoding on the data are

+   required in order to transmit the body via some mail transfer

+   protocols, such as SMTP.

+

+   The default character set, US-ASCII, has been the subject of some

+   confusion and ambiguity in the past.  Not only were there some

+   ambiguities in the definition, there have been wide variations in

+   practice.  In order to eliminate such ambiguity and variations in the

+

+

+

+Borenstein & Freed                                             [Page 25]

+

+RFC 1521                          MIME                    September 1993

+

+

+   future, it is strongly recommended that new user agents explicitly

+   specify a character set via the Content-Type header field.  "US-

+   ASCII" does not indicate an arbitrary seven-bit character code, but

+   specifies that the body uses character coding that uses the exact

+   correspondence of codes to characters specified in ASCII.  National

+   use variations of ISO 646 [ISO-646] are NOT ASCII and their use in

+   Internet mail is explicitly discouraged. The omission of the ISO 646

+   character set is deliberate in this regard.  The character set name

+   of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only.

+   The character set name "ASCII" is reserved and must not be used for

+   any purpose.

+

+      NOTE: RFC 821 explicitly specifies "ASCII", and references an

+      earlier version of the American Standard.  Insofar as one of the

+      purposes of specifying a Content-Type and character set is to

+      permit the receiver to unambiguously determine how the sender

+      intended the coded message to be interpreted, assuming anything

+      other than "strict ASCII" as the default would risk unintentional

+      and incompatible changes to the semantics of messages now being

+      transmitted.  This also implies that messages containing

+      characters coded according to national variations on ISO 646, or

+      using code-switching procedures (e.g., those of ISO 2022), as well

+      as 8-bit or multiple octet character encodings MUST use an

+      appropriate character set specification to be consistent with this

+      specification.

+

+   The complete US-ASCII character set is listed in [US-ASCII].  Note

+   that the control characters including DEL (0-31, 127) have no defined

+   meaning apart from the combination CRLF (ASCII values 13 and 10)

+   indicating a new line.  Two of the characters have de facto meanings

+   in wide use: FF (12) often means "start subsequent text on the

+   beginning of a new page"; and TAB or HT (9) often (though not always)

+   means "move the cursor to the next available column after the current

+   position where the column number is a multiple of 8 (counting the

+   first column as column 0)." Apart from this, any use of the control

+   characters or DEL in a body must be part of a private agreement

+   between the sender and recipient.  Such private agreements are

+   discouraged and should be replaced by the other capabilities of this

+   document.

+

+      NOTE: Beyond US-ASCII, an enormous proliferation of character sets

+      is possible. It is the opinion of the IETF working group that a

+      large number of character sets is NOT a good thing.  We would

+      prefer to specify a single character set that can be used

+      universally for representing all of the world's languages in

+      electronic mail.  Unfortunately, existing practice in several

+      communities seems to point to the continued use of multiple

+      character sets in the near future.  For this reason, we define

+

+

+

+Borenstein & Freed                                             [Page 26]

+

+RFC 1521                          MIME                    September 1993

+

+

+      names for a small number of character sets for which a strong

+      constituent base exists.

+

+   The defined charset values are:

+

+   US-ASCII -- as defined in [US-ASCII].

+

+        ISO-8859-X -- where "X" is to be replaced, as necessary, for the

+             parts of ISO-8859 [ISO-8859].  Note that the ISO 646

+             character sets have deliberately been omitted in favor of

+             their 8859 replacements, which are the designated character

+             sets for Internet mail.  As of the publication of this

+             document, the legitimate values for "X" are the digits 1

+             through 9.

+

+   The character sets specified above are the ones that were relatively

+   uncontroversial during the drafting of MIME.  This document does not

+   endorse the use of any particular character set other than US-ASCII,

+   and recognizes that the future evolution of world character sets

+   remains unclear.  It is expected that in the future, additional

+   character sets will be registered for use in MIME.

+

+   Note that the character set used, if anything other than US-ASCII,

+   must always be explicitly specified in the Content-Type field.

+

+   No other character set name may be used in Internet mail without the

+   publication of a formal specification and its registration with IANA,

+   or by private agreement, in which case the character set name must

+   begin with "X-".

+

+   Implementors are discouraged from defining new character sets for

+   mail use unless absolutely necessary.

+

+   The "charset" parameter has been defined primarily for the purpose of

+   textual data, and is described in this section for that reason.

+   However, it is conceivable that non-textual data might also wish to

+   specify a charset value for some purpose, in which case the same

+   syntax and values should be used.

+

+   In general, mail-sending software must always use the "lowest common

+   denominator" character set possible.  For example, if a body contains

+   only US-ASCII characters, it must be marked as being in the US-ASCII

+   character set, not ISO-8859-1, which, like all the ISO-8859 family of

+   character sets, is a superset of US-ASCII.  More generally, if a

+   widely-used character set is a subset of another character set, and a

+   body contains only characters in the widely-used subset, it must be

+   labeled as being in that subset.  This will increase the chances that

+   the recipient will be able to view the mail correctly.

+

+

+

+Borenstein & Freed                                             [Page 27]

+

+RFC 1521                          MIME                    September 1993

+

+

+7.1.2.     The Text/plain subtype

+

+   The primary subtype of text is "plain".  This indicates plain

+   (unformatted) text.  The default Content-Type for Internet mail,

+   "text/plain; charset=us-ascii", describes existing Internet practice.

+   That is, it is the type of body defined by RFC 822.

+

+   No other text subtype is defined by this document.

+

+   The formal grammar for the content-type header field for text is as

+   follows:

+

+   text-type := "text" "/" text-subtype [";" "charset" "=" charset]

+

+   text-subtype := "plain" / extension-token

+

+   charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3"

+          / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7"

+          / "iso-8859-8" / "iso-8859-9" / extension-token

+                    ; case insensitive

+

+7.2.  The Multipart Content-Type

+

+   In the case of multiple part entities, in which one or more different

+   sets of data are combined in a single body, a "multipart" Content-

+   Type field must appear in the entity's header. The body must then

+   contain one or more "body parts," each preceded by an encapsulation

+   boundary, and the last one followed by a closing boundary.  Each part

+   starts with an encapsulation boundary, and then contains a body part

+   consisting of header area, a blank line, and a body area.  Thus a

+   body part is similar to an RFC 822 message in syntax, but different

+   in meaning.

+

+   A body part is NOT to be interpreted as actually being an RFC 822

+   message.  To begin with, NO header fields are actually required in

+   body parts.  A body part that starts with a blank line, therefore, is

+   allowed and is a body part for which all default values are to be

+   assumed.  In such a case, the absence of a Content-Type header field

+   implies that the corresponding body is plain US-ASCII text.  The only

+   header fields that have defined meaning for body parts are those the

+   names of which begin with "Content-".  All other header fields are

+   generally to be ignored in body parts.  Although they should

+   generally be retained in mail processing, they may be discarded by

+   gateways if necessary.  Such other fields are permitted to appear in

+   body parts but must not be depended on.  "X-" fields may be created

+   for experimental or private purposes, with the recognition that the

+   information they contain may be lost at some gateways.

+

+

+

+

+Borenstein & Freed                                             [Page 28]

+

+RFC 1521                          MIME                    September 1993

+

+

+      NOTE: The distinction between an RFC 822 message and a body part

+      is subtle, but important. A gateway between Internet and X.400

+      mail, for example, must be able to tell the difference between a

+      body part that contains an image and a body part that contains an

+      encapsulated message, the body of which is an image.  In order to

+      represent the latter, the body part must have "Content-Type:

+      message", and its body (after the blank line) must be the

+      encapsulated message, with its own "Content-Type: image" header

+      field.  The use of similar syntax facilitates the conversion of

+      messages to body parts, and vice versa, but the distinction

+      between the two must be understood by implementors.  (For the

+      special case in which all parts actually are messages, a "digest"

+      subtype is also defined.)

+

+   As stated previously, each body part is preceded by an encapsulation

+   boundary.  The encapsulation boundary MUST NOT appear inside any of

+   the encapsulated parts.  Thus, it is crucial that the composing agent

+   be able to choose and specify the unique boundary that will separate

+   the parts.

+

+   All present and future subtypes of the "multipart" type must use an

+   identical syntax.  Subtypes may differ in their semantics, and may

+   impose additional restrictions on syntax, but must conform to the

+   required syntax for the multipart type.  This requirement ensures

+   that all conformant user agents will at least be able to recognize

+   and separate the parts of any multipart entity, even of an

+   unrecognized subtype.

+

+   As stated in the definition of the Content-Transfer-Encoding field,

+   no encoding other than "7bit", "8bit", or "binary" is permitted for

+   entities of type "multipart".  The multipart delimiters and header

+   fields are always represented as 7-bit ASCII in any case (though the

+   header fields may encode non-ASCII header text as per [RFC-1522]),

+   and data within the body parts can be encoded on a part-by-part

+   basis, with Content-Transfer-Encoding fields for each appropriate

+   body part.

+

+   Mail gateways, relays, and other mail handling agents are commonly

+   known to alter the top-level header of an RFC 822 message.  In

+   particular, they frequently add, remove, or reorder header fields.

+   Such alterations are explicitly forbidden for the body part headers

+   embedded in the bodies of messages of type "multipart."

+

+7.2.1.     Multipart:  The common syntax

+

+   All subtypes of "multipart" share a common syntax, defined in this

+   section.  A simple example of a multipart message also appears in

+   this section.  An example of a more complex multipart message is

+

+

+

+Borenstein & Freed                                             [Page 29]

+

+RFC 1521                          MIME                    September 1993

+

+

+   given in Appendix C.

+

+   The Content-Type field for multipart entities requires one parameter,

+   "boundary", which is used to specify the encapsulation boundary.  The

+   encapsulation boundary is defined as a line consisting entirely of

+   two hyphen characters ("-", decimal code 45) followed by the boundary

+   parameter value from the Content-Type header field.

+

+      NOTE: The hyphens are for rough compatibility with the earlier RFC

+      934 method of message encapsulation, and for ease of searching for

+      the boundaries in some implementations. However, it should be

+      noted that multipart messages are NOT completely compatible with

+      RFC 934 encapsulations; in particular, they do not obey RFC 934

+      quoting conventions for embedded lines that begin with hyphens.

+      This mechanism was chosen over the RFC 934 mechanism because the

+      latter causes lines to grow with each level of quoting.  The

+      combination of this growth with the fact that SMTP implementations

+      sometimes wrap long lines made the RFC 934 mechanism unsuitable

+      for use in the event that deeply-nested multipart structuring is

+      ever desired.

+

+   WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-

+   type field is such that it is often necessary to enclose the

+   boundaries in quotes on the Content-type line.  This is not always

+   necessary, but never hurts.  Implementors should be sure to study the

+   grammar carefully in order to avoid producing illegal Content-type

+   fields. Thus, a typical multipart Content-Type header field might

+   look like this:

+

+                 Content-Type: multipart/mixed;

+                      boundary=gc0p4Jq0M2Yt08jU534c0p

+

+   But the following is illegal:

+

+                 Content-Type: multipart/mixed;

+                      boundary=gc0p4Jq0M:2Yt08jU534c0p

+

+   (because of the colon) and must instead be represented as

+

+                 Content-Type: multipart/mixed;

+                      boundary="gc0p4Jq0M:2Yt08jU534c0p"

+

+   This indicates that the entity consists of several parts, each itself

+   with a structure that is syntactically identical to an RFC 822

+   message, except that the header area might be completely empty, and

+   that the parts are each preceded by the line

+

+                 --gc0p4Jq0M:2Yt08jU534c0p

+

+

+

+Borenstein & Freed                                             [Page 30]

+

+RFC 1521                          MIME                    September 1993

+

+

+   Note that the encapsulation boundary must occur at the beginning of a

+   line, i.e., following a CRLF, and that the initial CRLF is considered

+   to be attached to the encapsulation boundary rather than part of the

+   preceding part.  The boundary must be followed immediately either by

+   another CRLF and the header fields for the next part, or by two

+   CRLFs, in which case there are no header fields for the next part

+   (and it is therefore assumed to be of Content-Type text/plain).

+

+      NOTE: The CRLF preceding the encapsulation line is conceptually

+      attached to the boundary so that it is possible to have a part

+      that does not end with a CRLF (line break). Body parts that must

+      be considered to end with line breaks, therefore, must have two

+      CRLFs preceding the encapsulation line, the first of which is part

+      of the preceding body part, and the second of which is part of the

+      encapsulation boundary.

+

+   Encapsulation boundaries must not appear within the encapsulations,

+   and must be no longer than 70 characters, not counting the two

+   leading hyphens.

+

+   The encapsulation boundary following the last body part is a

+   distinguished delimiter that indicates that no further body parts

+   will follow.  Such a delimiter is identical to the previous

+   delimiters, with the addition of two more hyphens at the end of the

+   line:

+

+                 --gc0p4Jq0M2Yt08jU534c0p--

+

+   There appears to be room for additional information prior to the

+   first encapsulation boundary and following the final boundary.  These

+   areas should generally be left blank, and implementations must ignore

+   anything that appears before the first boundary or after the last

+   one.

+

+      NOTE: These "preamble" and "epilogue" areas are generally not used

+      because of the lack of proper typing of these parts and the lack

+      of clear semantics for handling these areas at gateways,

+      particularly X.400 gateways.  However, rather than leaving the

+      preamble area blank, many MIME implementations have found this to

+      be a convenient place to insert an explanatory note for recipients

+      who read the message with pre-MIME software, since such notes will

+      be ignored by MIME-compliant software.

+

+      NOTE: Because encapsulation boundaries must not appear in the body

+      parts being encapsulated, a user agent must exercise care to

+      choose a unique boundary.  The boundary in the example above could

+      have been the result of an algorithm designed to produce

+      boundaries with a very low probability of already existing in the

+

+

+

+Borenstein & Freed                                             [Page 31]

+

+RFC 1521                          MIME                    September 1993

+

+

+      data to be encapsulated without having to prescan the data.

+      Alternate algorithms might result in more 'readable' boundaries

+      for a recipient with an old user agent, but would require more

+      attention to the possibility that the boundary might appear in the

+      encapsulated part.  The simplest boundary possible is something

+      like "---", with a closing boundary of "-----".

+

+   As a very simple example, the following multipart message has two

+   parts, both of them plain text, one of them explicitly typed and one

+   of them implicitly typed:

+

+      From: Nathaniel Borenstein <nsb@bellcore.com>

+      To:  Ned Freed <ned@innosoft.com>

+      Subject: Sample message

+      MIME-Version: 1.0

+      Content-type: multipart/mixed; boundary="simple

+      boundary"

+

+      This is the preamble.  It is to be ignored, though it

+      is a handy place for mail composers to include an

+      explanatory note to non-MIME conformant readers.

+      --simple boundary

+

+      This is implicitly typed plain ASCII text.

+      It does NOT end with a linebreak.

+      --simple boundary

+      Content-type: text/plain; charset=us-ascii

+

+      This is explicitly typed plain ASCII text.

+      It DOES end with a linebreak.

+

+      --simple boundary--

+      This is the epilogue.  It is also to be ignored.

+

+   The use of a Content-Type of multipart in a body part within another

+   multipart entity is explicitly allowed.  In such cases, for obvious

+   reasons, care must be taken to ensure that each nested multipart

+   entity must use a different boundary delimiter. See Appendix C for an

+   example of nested multipart entities.

+

+   The use of the multipart Content-Type with only a single body part

+   may be useful in certain contexts, and is explicitly permitted.

+

+   The only mandatory parameter for the multipart Content-Type is the

+   boundary parameter, which consists of 1 to 70 characters from a set

+   of characters known to be very robust through email gateways, and NOT

+   ending with white space.  (If a boundary appears to end with white

+   space, the white space must be presumed to have been added by a

+

+

+

+Borenstein & Freed                                             [Page 32]

+

+RFC 1521                          MIME                    September 1993

+

+

+   gateway, and must be deleted.)  It is formally specified by the

+   following BNF:

+

+   boundary := 0*69<bchars> bcharsnospace

+

+   bchars := bcharsnospace / " "

+

+   bcharsnospace :=    DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_"

+                 / "," / "-" / "." / "/" / ":" / "=" / "?"

+

+   Overall, the body of a multipart entity may be specified  as

+   follows:

+

+   multipart-body := preamble 1*encapsulation

+                  close-delimiter epilogue

+

+   encapsulation := delimiter body-part CRLF

+

+   delimiter := "--" boundary CRLF ; taken from Content-Type field.

+                                   ; There must be no space

+                                   ; between "--" and boundary.

+

+   close-delimiter := "--" boundary "--" CRLF ; Again, no space

+   by "--",

+

+   preamble := discard-text   ;  to  be  ignored upon receipt.

+

+   epilogue := discard-text   ;  to  be  ignored upon receipt.

+

+   discard-text := *(*text CRLF)

+

+   body-part := <"message" as defined in RFC 822,

+             with all header fields optional, and with the

+             specified delimiter not occurring anywhere in

+             the message body, either on a line by itself

+             or as a substring anywhere.  Note that the

+             semantics of a part differ from the semantics

+             of a message, as described in the text.>

+

+      NOTE: In certain transport enclaves, RFC 822 restrictions such as

+      the one that limits bodies to printable ASCII characters may not

+      be in force.  (That is, the transport domains may resemble

+      standard Internet mail transport as specified in RFC821 and

+      assumed by RFC822, but without certain restrictions.)  The

+      relaxation of these restrictions should be construed as locally

+      extending the definition of bodies, for example to include octets

+      outside of the ASCII range, as long as these extensions are

+      supported by the transport and adequately documented in the

+

+

+

+Borenstein & Freed                                             [Page 33]

+

+RFC 1521                          MIME                    September 1993

+

+

+      Content-Transfer-Encoding header field. However, in no event are

+      headers (either message headers or body-part headers) allowed to

+      contain anything other than ASCII characters.

+

+      NOTE: Conspicuously missing from the multipart type is a notion of

+      structured, related body parts.  In general, it seems premature to

+      try to standardize interpart structure yet.  It is recommended

+      that those wishing to provide a more structured or integrated

+      multipart messaging facility should define a subtype of multipart

+      that is syntactically identical, but that always expects the

+      inclusion of a distinguished part that can be used to specify the

+      structure and integration of the other parts, probably referring

+      to them by their Content-ID field.  If this approach is used,

+      other implementations will not recognize the new subtype, but will

+      treat it as the primary subtype (multipart/mixed) and will thus be

+      able to show the user the parts that are recognized.

+

+7.2.2.     The Multipart/mixed (primary) subtype

+

+   The primary subtype for multipart, "mixed", is intended for use when

+   the body parts are independent and need to be bundled in a particular

+   order.  Any multipart subtypes that an implementation does not

+   recognize must be treated as being of subtype "mixed".

+

+7.2.3.     The Multipart/alternative subtype

+

+   The multipart/alternative type is syntactically identical to

+   multipart/mixed, but the semantics are different.  In particular,

+   each of the parts is an "alternative" version of the same

+   information.

+

+   Systems should recognize that the content of the various parts are

+   interchangeable.  Systems should choose the "best" type based on the

+   local environment and preferences, in some cases even through user

+   interaction.  As with multipart/mixed, the order of body parts is

+   significant.  In this case, the alternatives appear in an order of

+   increasing faithfulness to the original content. In general, the best

+   choice is the LAST part of a type supported by the recipient system's

+   local environment.

+

+   Multipart/alternative may be used, for example, to send mail in a

+   fancy text format in such a way that it can easily be displayed

+   anywhere:

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 34]

+

+RFC 1521                          MIME                    September 1993

+

+

+   From:  Nathaniel Borenstein <nsb@bellcore.com>

+   To: Ned Freed <ned@innosoft.com>

+   Subject: Formatted text mail

+   MIME-Version: 1.0

+   Content-Type: multipart/alternative; boundary=boundary42

+

+   --boundary42

+

+   Content-Type: text/plain; charset=us-ascii

+

+      ...plain text version of message goes here....

+   --boundary42

+   Content-Type: text/richtext

+

+      .... RFC 1341 richtext version of same message goes here ...

+   --boundary42

+   Content-Type: text/x-whatever

+

+      .... fanciest formatted version of same  message  goes  here

+      ...

+   --boundary42--

+

+   In this example, users whose mail system understood the "text/x-

+   whatever" format would see only the fancy version, while other users

+   would see only the richtext or plain text version, depending on the

+   capabilities of their system.

+

+   In general, user agents that compose multipart/alternative entities

+   must place the body parts in increasing order of preference, that is,

+   with the preferred format last.  For fancy text, the sending user

+   agent should put the plainest format first and the richest format

+   last.  Receiving user agents should pick and display the last format

+   they are capable of displaying.  In the case where one of the

+   alternatives is itself of type "multipart" and contains unrecognized

+   sub-parts, the user agent may choose either to show that alternative,

+   an earlier alternative, or both.

+

+      NOTE: From an implementor's perspective, it might seem more

+      sensible to reverse this ordering, and have the plainest

+      alternative last.  However, placing the plainest alternative first

+      is the friendliest possible option when multipart/alternative

+      entities are viewed using a non-MIME-conformant mail reader.

+      While this approach does impose some burden on conformant mail

+      readers, interoperability with older mail readers was deemed to be

+      more important in this case.

+

+   It may be the case that some user agents, if they can recognize more

+   than one of the formats, will prefer to offer the user the choice of

+

+

+

+Borenstein & Freed                                             [Page 35]

+

+RFC 1521                          MIME                    September 1993

+

+

+   which format to view.  This makes sense, for example, if mail

+   includes both a nicely-formatted image version and an easily-edited

+   text version.  What is most critical, however, is that the user not

+   automatically be shown multiple versions of the same data.  Either

+   the user should be shown the last recognized version or should be

+   given the choice.

+

+   NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each

+   part of a multipart/alternative entity represents the same data, but

+   the mappings between the two are not necessarily without information

+   loss.  For example, information is lost when translating ODA to

+   PostScript or plain text.  It is recommended that each part should

+   have a different Content-ID value in the case where the information

+   content of the two parts is not identical.  However, where the

+   information content is identical -- for example, where several parts

+   of type "application/external- body" specify alternate ways to access

+   the identical data -- the same Content-ID field value should be used,

+   to optimize any cacheing mechanisms that might be present on the

+   recipient's end.  However, it is recommended that the Content-ID

+   values used by the parts should not be the same Content-ID value that

+   describes the multipart/alternative as a whole, if there is any such

+   Content-ID field.  That is, one Content-ID value will refer to the

+   multipart/alternative entity, while one or more other Content-ID

+   values will refer to the parts inside it.

+

+7.2.4.     The Multipart/digest subtype

+

+   This document defines a "digest" subtype of the multipart Content-

+   Type.  This type is syntactically identical to multipart/mixed, but

+   the semantics are different.  In particular, in a digest, the default

+   Content-Type value for a body part is changed from "text/plain" to

+   "message/rfc822".  This is done to allow a more readable digest

+   format that is largely compatible (except for the quoting convention)

+   with RFC 934.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 36]

+

+RFC 1521                          MIME                    September 1993

+

+

+   A digest in this format might, then, look something like this:

+

+   From: Moderator-Address

+   To: Recipient-List

+   MIME-Version: 1.0

+   Subject:  Internet Digest, volume 42

+   Content-Type: multipart/digest;

+        boundary="---- next message ----"

+

+   ------ next message ----

+

+   From: someone-else

+   Subject: my opinion

+

+      ...body goes here ...

+

+   ------ next message ----

+

+   From: someone-else-again

+   Subject: my different opinion

+

+      ... another body goes here...

+

+   ------ next message ------

+

+7.2.5.     The Multipart/parallel subtype

+

+   This document defines a "parallel" subtype of the multipart Content-

+   Type.  This type is syntactically identical to multipart/mixed, but

+   the semantics are different.  In particular, in a parallel entity,

+   the order of body parts is not significant.

+

+   A common presentation of this type is to display all of the parts

+   simultaneously on hardware and software that are capable of doing so.

+   However, composing agents should be aware that many mail readers will

+   lack this capability and will show the parts serially in any event.

+

+7.2.6.     Other Multipart subtypes

+

+   Other multipart subtypes are expected in the future.  MIME

+   implementations must in general treat unrecognized subtypes of

+   multipart as being equivalent to "multipart/mixed".

+

+   The formal grammar for content-type header fields for multipart data

+   is given by:

+

+   multipart-type := "multipart" "/" multipart-subtype

+                  ";" "boundary" "=" boundary

+

+

+

+Borenstein & Freed                                             [Page 37]

+

+RFC 1521                          MIME                    September 1993

+

+

+   multipart-subtype := "mixed" / "parallel" / "digest"

+                  / "alternative" / extension-token

+

+7.3.  The Message Content-Type

+

+   It is frequently desirable, in sending mail, to encapsulate another

+   mail message. For this common operation, a special Content-Type,

+   "message", is defined.  The primary subtype, message/rfc822, has no

+   required parameters in the Content-Type field.  Additional subtypes,

+   "partial" and "External-body", do have required parameters.  These

+   subtypes are explained below.

+

+      NOTE: It has been suggested that subtypes of message might be

+      defined for forwarded or rejected messages.  However, forwarded

+      and rejected messages can be handled as multipart messages in

+      which the first part contains any control or descriptive

+      information, and a second part, of type message/rfc822, is the

+      forwarded or rejected message.  Composing rejection and forwarding

+      messages in this manner will preserve the type information on the

+      original message and allow it to be correctly presented to the

+      recipient, and hence is strongly encouraged.

+

+   As stated in the definition of the Content-Transfer-Encoding field,

+   no encoding other than "7bit", "8bit", or "binary" is permitted for

+   messages or parts of type "message".  Even stronger restrictions

+   apply to the subtypes "message/partial" and "message/external-body",

+   as specified below.  The message header fields are always US-ASCII in

+   any case, and data within the body can still be encoded, in which

+   case the Content-Transfer-Encoding header field in the encapsulated

+   message will reflect this.  Non-ASCII text in the headers of an

+   encapsulated message can be specified using the mechanisms described

+   in [RFC-1522].

+

+   Mail gateways, relays, and other mail handling agents are commonly

+   known to alter the top-level header of an RFC 822 message.  In

+   particular, they frequently add, remove, or reorder header fields.

+   Such alterations are explicitly forbidden for the encapsulated

+   headers embedded in the bodies of messages of type "message."

+

+7.3.1.     The Message/rfc822 (primary) subtype

+

+   A Content-Type of "message/rfc822" indicates that the body contains

+   an encapsulated message, with the syntax of an RFC 822 message.

+   However, unlike top-level RFC 822 messages, it is not required that

+   each message/rfc822 body must include a "From", "Subject", and at

+   least one destination header.

+

+   It should be noted that, despite the use of the numbers "822", a

+

+

+

+Borenstein & Freed                                             [Page 38]

+

+RFC 1521                          MIME                    September 1993

+

+

+   message/rfc822 entity can include enhanced information as defined in

+   this document.  In other words, a message/rfc822 message may be a

+   MIME message.

+

+7.3.2.     The Message/Partial subtype

+

+   A subtype of message, "partial", is defined in order to allow large

+   objects to be delivered as several separate pieces of mail and

+   automatically reassembled by the receiving user agent.  (The concept

+   is similar to IP fragmentation/reassembly in the basic Internet

+   Protocols.)  This mechanism can be used when intermediate transport

+   agents limit the size of individual messages that can be sent.

+   Content-Type "message/partial" thus indicates that the body contains

+   a fragment of a larger message.

+

+   Three parameters must be specified in the Content-Type field of type

+   message/partial: The first, "id", is a unique identifier, as close to

+   a world-unique identifier as possible, to be used to match the parts

+   together.  (In general, the identifier is essentially a message-id;

+   if placed in double quotes, it can be any message-id, in accordance

+   with the BNF for "parameter" given earlier in this specification.)

+   The second, "number", an integer, is the part number, which indicates

+   where this part fits into the sequence of fragments.  The third,

+   "total", another integer, is the total number of parts. This third

+   subfield is required on the final part, and is optional (though

+   encouraged) on the earlier parts.  Note also that these parameters

+   may be given in any order.

+

+   Thus, part 2 of a 3-part message may have either of the following

+   header fields:

+

+                Content-Type: Message/Partial;

+                     number=2; total=3;

+                     id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

+

+                Content-Type: Message/Partial;

+                     id="oc=jpbe0M2Yt4s@thumper.bellcore.com";

+                     number=2

+

+   But part 3 MUST specify the total number of parts:

+

+                Content-Type: Message/Partial;

+                     number=3; total=3;

+                     id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

+

+   Note that part numbering begins with 1, not 0.

+

+   When the parts of a message broken up in this manner are put

+

+

+

+Borenstein & Freed                                             [Page 39]

+

+RFC 1521                          MIME                    September 1993

+

+

+   together, the result is a complete MIME entity, which may have its

+   own Content-Type header field, and thus may contain any other data

+   type.

+

+   Message fragmentation and reassembly: The semantics of a reassembled

+   partial message must be those of the "inner" message, rather than of

+   a message containing the inner message.  This makes it possible, for

+   example, to send a large audio message as several partial messages,

+   and still have it appear to the recipient as a simple audio message

+   rather than as an encapsulated message containing an audio message.

+   That is, the encapsulation of the message is considered to be

+   "transparent".

+

+   When generating and reassembling the parts of a message/partial

+   message, the headers of the encapsulated message must be merged with

+   the headers of the enclosing entities.  In this process the following

+   rules must be observed:

+

+      (1) All of the header fields from the initial enclosing entity

+      (part one), except those that start with "Content-" and the

+      specific header fields "Message-ID", "Encrypted", and "MIME-

+      Version", must be copied, in order, to the new message.

+

+      (2) Only those header fields in the enclosed message which start

+      with "Content-" and "Message-ID", "Encrypted", and "MIME-Version"

+      must be appended, in order, to the header fields of the new

+      message.  Any header fields in the enclosed message which do not

+      start with "Content-" (except for "Message-ID", "Encrypted", and

+      "MIME-Version") will be ignored.

+

+      (3) All of the header fields from the second and any subsequent

+      messages will be ignored.

+

+   For example, if an audio message is broken into two parts, the first

+   part might look something like this:

+

+      X-Weird-Header-1: Foo

+      From: Bill@host.com

+      To: joe@otherhost.com

+      Subject: Audio mail

+      Message-ID: <id1@host.com>

+      MIME-Version: 1.0

+      Content-type: message/partial;

+           id="ABC@host.com";

+           number=1; total=2

+

+      X-Weird-Header-1: Bar

+      X-Weird-Header-2: Hello

+

+

+

+Borenstein & Freed                                             [Page 40]

+

+RFC 1521                          MIME                    September 1993

+

+

+      Message-ID: <anotherid@foo.com>

+      MIME-Version: 1.0

+      Content-type: audio/basic

+      Content-transfer-encoding: base64

+

+         ... first half of encoded audio data goes here...

+

+   and the second half might look something like this:

+

+      From: Bill@host.com

+      To: joe@otherhost.com

+      Subject: Audio mail

+      MIME-Version: 1.0

+      Message-ID: <id2@host.com>

+      Content-type: message/partial;

+           id="ABC@host.com"; number=2; total=2

+

+         ... second half of encoded audio data goes here...

+

+   Then, when the fragmented message is reassembled, the resulting

+   message to be displayed to the user should look something like this:

+

+      X-Weird-Header-1: Foo

+      From: Bill@host.com

+      To: joe@otherhost.com

+      Subject: Audio mail

+      Message-ID: <anotherid@foo.com>

+      MIME-Version: 1.0

+      Content-type: audio/basic

+      Content-transfer-encoding: base64

+

+         ... first half of encoded audio data goes here...

+         ... second half of encoded audio data goes here...

+

+   Note on encoding of MIME entities encapsulated inside message/partial

+   entities: Because data of type "message" may never be encoded in

+   base64 or quoted-printable, a problem might arise if message/partial

+   entities are constructed in an environment that supports binary or

+   8-bit transport.  The problem is that the binary data would be split

+   into multiple message/partial objects, each of them requiring binary

+   transport.  If such objects were encountered at a gateway into a 7-

+   bit transport environment, there would be no way to properly encode

+   them for the 7-bit world, aside from waiting for all of the parts,

+   reassembling the message, and then encoding the reassembled data in

+   base64 or quoted-printable.  Since it is possible that different

+   parts might go through different gateways, even this is not an

+   acceptable solution.  For this reason, it is specified that MIME

+   entities of type message/partial must always have a content-

+

+

+

+Borenstein & Freed                                             [Page 41]

+

+RFC 1521                          MIME                    September 1993

+

+

+   transfer-encoding of 7-bit (the default).  In particular, even in

+   environments that support binary or 8-bit transport, the use of a

+   content-transfer-encoding of "8bit" or "binary" is explicitly

+   prohibited for entities of type message/partial.

+

+   It should be noted that, because some message transfer agents may

+   choose to automatically fragment large messages, and because such

+   agents may use different fragmentation thresholds, it is possible

+   that the pieces of a partial message, upon reassembly, may prove

+   themselves to comprise a partial message.  This is explicitly

+   permitted.

+

+   It should also be noted that the inclusion of a "References" field in

+   the headers of the second and subsequent pieces of a fragmented

+   message that references the Message-Id on the previous piece may be

+   of benefit to mail readers that understand and track references.

+   However, the generation of such "References" fields is entirely

+   optional.

+

+   Finally, it should be noted that the "Encrypted" header field has

+   been made obsolete by Privacy Enhanced Messaging (PEM), but the rules

+   above are believed to describe the correct way to treat it if it is

+   encountered in the context of conversion to and from message/partial

+   fragments.

+

+7.3.3.     The Message/External-Body subtype

+

+   The external-body subtype indicates that the actual body data are not

+   included, but merely referenced.  In this case, the parameters

+   describe a mechanism for accessing the external data.

+

+   When an entity is of type "message/external-body", it consists of a

+   header, two consecutive CRLFs, and the message header for the

+   encapsulated message.  If another pair of consecutive CRLFs appears,

+   this of course ends the message header for the encapsulated message.

+   However, since the encapsulated message's body is itself external, it

+   does NOT appear in the area that follows.  For example, consider the

+   following message:

+

+      Content-type: message/external-body; access-

+      type=local-file;

+

+           name="/u/nsb/Me.gif"

+

+      Content-type:  image/gif

+      Content-ID: <id42@guppylake.bellcore.com>

+      Content-Transfer-Encoding: binary

+

+

+

+

+Borenstein & Freed                                             [Page 42]

+

+RFC 1521                          MIME                    September 1993

+

+

+      THIS IS NOT REALLY THE BODY!

+

+   The area at the end, which might be called the "phantom body", is

+   ignored for most external-body messages.  However, it may be used to

+   contain auxiliary information for some such messages, as indeed it is

+   when the access-type is "mail-server".  Of the access-types defined

+   by this document, the phantom body is used only when the access-type

+   is "mail-server".  In all other cases, the phantom body is ignored.

+

+   The only always-mandatory parameter for message/external-body is

+   "access-type"; all of the other parameters may be mandatory or

+   optional depending on the value of access-type.

+

+      ACCESS-TYPE -- A case-insensitive word, indicating the supported

+      access mechanism by which the file or data may be obtained.

+      Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP",

+      "AFS", "LOCAL-FILE", and "MAIL-SERVER".  Future values, except for

+      experimental values beginning with "X-" must be registered with

+      IANA, as described in Appendix E .

+

+   In addition, the following three parameters are optional for ALL

+   access-types:

+

+      EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as

+      extended by RFC 1123 to permit 4 digits in the year field) after

+      which the existence of the external data is not guaranteed.

+

+      SIZE -- The size (in octets) of the data.  The intent of this

+      parameter is to help the recipient decide whether or not to expend

+      the necessary resources to retrieve the external data.  Note that

+      this describes the size of the data in its canonical form, that

+      is, before any Content- Transfer-Encoding has been applied or

+      after the data have been decoded.

+

+      PERMISSION -- A case-insensitive field that indicates whether or

+      not it is expected that clients might also attempt to overwrite

+      the data.  By default, or if permission is "read", the assumption

+      is that they are not, and that if the data is retrieved once, it

+      is never needed again.  If PERMISSION is "read-write", this

+      assumption is invalid, and any local copy must be considered no

+      more than a cache.  "Read" and "Read-write" are the only defined

+      values of permission.

+

+   The precise semantics of the access-types defined here are described

+   in the sections that follow.

+

+   The encapsulated headers in ALL message/external-body entities MUST

+   include a Content-ID header field to give a unique identifier by

+

+

+

+Borenstein & Freed                                             [Page 43]

+

+RFC 1521                          MIME                    September 1993

+

+

+   which to reference the data.  This identifier may be used for

+   cacheing mechanisms, and for recognizing the receipt of the data when

+   the access-type is "mail-server".

+

+   Note that, as specified here, the tokens that describe external-body

+   data, such as file names and mail server commands, are required to be

+   in the US-ASCII character set.  If this proves problematic in

+   practice, a new mechanism may be required as a future extension to

+   MIME, either as newly defined access-types for message/external-body

+   or by some other mechanism.

+

+   As with message/partial, it is specified that MIME entities of type

+   message/external-body must always have a content-transfer-encoding of

+   7-bit (the default).  In particular, even in environments that

+   support binary or 8-bit transport, the use of a content-transfer-

+   encoding of "8bit" or "binary" is explicitly prohibited for entities

+   of type message/external-body.

+

+7.3.3.1.  The "ftp" and "tftp" access-types

+

+   An access-type of FTP or TFTP indicates that the message body is

+   accessible as a file using the FTP [RFC-959] or TFTP [RFC-783]

+   protocols, respectively.  For these access-types, the following

+   additional parameters are mandatory:

+

+      NAME -- The name of the file that contains the actual body data.

+

+      SITE -- A machine from which the file may be obtained, using the

+      given protocol. This must be a fully qualified domain name, not a

+      nickname.

+

+   Before any data are retrieved, using FTP, the user will generally

+   need to be asked to provide a login id and a password for the machine

+   named by the site parameter.  For security reasons, such an id and

+   password are not specified as content-type parameters, but must be

+   obtained from the user.

+

+   In addition, the following parameters are optional:

+

+      DIRECTORY -- A directory from which the data named by NAME should

+      be retrieved.

+

+      MODE -- A case-insensitive string indicating the mode to be used

+      when retrieving the information.  The legal values for access-type

+      "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the

+      TFTP protocol [RFC-783].  The legal values for access-type "FTP"

+      are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a

+      decimal integer, typically 8.  These correspond to the

+

+

+

+Borenstein & Freed                                             [Page 44]

+

+RFC 1521                          MIME                    September 1993

+

+

+      representation types "A" "E" "I" and "L n" as specified by the FTP

+      protocol [RFC-959].  Note that "BINARY" and "TENEX" are not valid

+      values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be

+      used instead.  IF MODE is not specified, the default value is

+      "NETASCII" for TFTP and "ASCII" otherwise.

+

+7.3.3.2.  The "anon-ftp" access-type

+

+   The "anon-ftp" access-type is identical to the "ftp" access type,

+   except that the user need not be asked to provide a name and password

+   for the specified site.  Instead, the ftp protocol will be used with

+   login "anonymous" and a password that corresponds to the user's email

+   address.

+

+7.3.3.3.  The "local-file" and "afs" access-types

+

+   An access-type of "local-file" indicates that the actual body is

+   accessible as a file on the local machine.  An access-type of "afs"

+   indicates that the file is accessible via the global AFS file system.

+   In both cases, only a single parameter is required:

+

+      NAME -- The name of the file that contains the actual body data.

+

+   The following optional parameter may be used to describe the locality

+   of reference for the data, that is, the site or sites at which the

+   file is expected to be visible:

+

+      SITE -- A domain specifier for a machine or set of machines that

+      are known to have access to the data file.  Asterisks may be used

+      for wildcard matching to a part of a domain name, such as

+      "*.bellcore.com", to indicate a set of machines on which the data

+      should be directly visible, while a single asterisk may be used to

+      indicate a file that is expected to be universally available,

+      e.g., via a global file system.

+

+7.3.3.4.  The "mail-server" access-type

+

+   The "mail-server" access-type indicates that the actual body is

+   available from a mail server.  The mandatory parameter for this

+   access-type is:

+

+      SERVER -- The email address of the mail server from which the

+      actual body data can be obtained.

+

+   Because mail servers accept a variety of syntaxes, some of which is

+   multiline, the full command to be sent to a mail server is not

+   included as a parameter on the content-type line.  Instead, it is

+   provided as the "phantom body" when the content-type is

+

+

+

+Borenstein & Freed                                             [Page 45]

+

+RFC 1521                          MIME                    September 1993

+

+

+   message/external-body and the access- type is mail-server.

+

+   An optional parameter for this access-type is:

+

+      SUBJECT -- The subject that is to be used in the mail that is sent

+      to obtain the data. Note that keying mail servers on Subject lines

+      is NOT recommended, but such mail servers are known to exist.

+

+   Note that MIME does not define a mail server syntax.  Rather, it

+   allows the inclusion of arbitrary mail server commands in the phantom

+   body.  Implementations must include the phantom body in the body of

+   the message it sends to the mail server address to retrieve the

+   relevant data.

+

+   It is worth noting that, unlike other access-types, mail-server

+   access is asynchronous and will happen at an unpredictable time in

+   the future.  For this reason, it is important that there be a

+   mechanism by which the returned data can be matched up with the

+   original message/external-body entity.  MIME mailservers must use the

+   same Content-ID field on the returned message that was used in the

+   original message/external-body entity, to facilitate such matching.

+

+7.3.3.5.  Examples and Further Explanations

+

+   With the emerging possibility of very wide-area file systems, it

+   becomes very hard to know in advance the set of machines where a file

+   will and will not be accessible directly from the file system.

+   Therefore it may make sense to provide both a file name, to be tried

+   directly, and the name of one or more sites from which the file is

+   known to be accessible.  An implementation can try to retrieve remote

+   files using FTP or any other protocol, using anonymous file retrieval

+   or prompting the user for the necessary name and password.  If an

+   external body is accessible via multiple mechanisms, the sender may

+   include multiple parts of type message/external-body within an entity

+   of type multipart/alternative.

+

+   However, the external-body mechanism is not intended to be limited to

+   file retrieval, as shown by the mail-server access-type.  Beyond

+   this, one can imagine, for example, using a video server for external

+   references to video clips.

+

+   If an entity is of type "message/external-body", then the body of the

+   entity will contain the header fields of the encapsulated message.

+   The body itself is to be found in the external location.  This means

+   that if the body of the "message/external-body" message contains two

+   consecutive CRLFs, everything after those pairs is NOT part of the

+   message itself.  For most message/external-body messages, this

+   trailing area must simply be ignored.  However, it is a convenient

+

+

+

+Borenstein & Freed                                             [Page 46]

+

+RFC 1521                          MIME                    September 1993

+

+

+   place for additional data that cannot be included in the content-type

+   header field.  In particular, if the "access-type" value is "mail-

+   server", then the trailing area must contain commands to be sent to

+   the mail server at the address given by the value of the SERVER

+   parameter.

+

+   The embedded message header fields which appear in the body of the

+   message/external-body data must be used to declare the Content-type

+   of the external body if it is anything other than plain ASCII text,

+   since the external body does not have a header section to declare its

+   type.  Similarly, any Content-transfer-encoding other than "7bit"

+   must also be declared here.  Thus a complete message/external-body

+   message, referring to a document in PostScript format, might look

+   like this:

+

+      From: Whomever

+      To: Someone

+      Subject: whatever

+      MIME-Version: 1.0

+      Message-ID: <id1@host.com>

+      Content-Type: multipart/alternative; boundary=42

+      Content-ID: <id001@guppylake.bellcore.com>

+

+      --42

+      Content-Type: message/external-body;

+           name="BodyFormats.ps";

+           site="thumper.bellcore.com";

+           access-type=ANON-FTP;

+           directory="pub";

+           mode="image";

+           expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

+

+      Content-type: application/postscript

+      Content-ID: <id42@guppylake.bellcore.com>

+

+      --42

+      Content-Type: message/external-body;

+           name="/u/nsb/writing/rfcs/RFC-MIME.ps";

+           site="thumper.bellcore.com";

+           access-type=AFS

+           expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

+

+      Content-type: application/postscript

+      Content-ID: <id42@guppylake.bellcore.com>

+

+      --42

+      Content-Type: message/external-body;

+           access-type=mail-server

+

+

+

+Borenstein & Freed                                             [Page 47]

+

+RFC 1521                          MIME                    September 1993

+

+

+           server="listserv@bogus.bitnet";

+           expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

+

+      Content-type: application/postscript

+      Content-ID: <id42@guppylake.bellcore.com>

+

+      get RFC-MIME.DOC

+

+      --42--

+

+   Note that in the above examples, the default Content-transfer-

+   encoding of "7bit" is assumed for the external postscript data.

+

+   Like the message/partial type, the message/external-body type is

+   intended to be transparent, that is, to convey the data type in the

+   external body rather than to convey a message with a body of that

+   type.  Thus the headers on the outer and inner parts must be merged

+   using the same rules as for message/partial.  In particular, this

+   means that the Content-type header is overridden, but the From and

+   Subject headers are preserved.

+

+   Note that since the external bodies are not transported as mail, they

+   need not conform to the 7-bit and line length requirements, but might

+   in fact be binary files.  Thus a Content-Transfer-Encoding is not

+   generally necessary, though it is permitted.

+

+   Note that the body of a message of type "message/external-body" is

+   governed by the basic syntax for an RFC 822 message.  In particular,

+   anything before the first consecutive pair of CRLFs is header

+   information, while anything after it is body information, which is

+   ignored for most access-types.

+

+   The formal grammar for content-type header fields for data of type

+   message is given by:

+

+   message-type := "message" "/" message-subtype

+

+   message-subtype := "rfc822"

+                   / "partial" 2#3partial-param

+                   / "external-body" 1*external-param

+                   / extension-token

+

+   partial-param :=     (";" "id" "=" value)

+              /  (";" "number" "=" 1*DIGIT)

+              /  (";" "total" "=" 1*DIGIT)

+         ; id & number required; total  required  for  last part

+

+   external-param :=   (";" "access-type" "=" atype)

+

+

+

+Borenstein & Freed                                             [Page 48]

+

+RFC 1521                          MIME                    September 1993

+

+

+              / (";" "expiration" "=" date-time)

+                   ; Note that date-time is quoted

+              / (";" "size" "=" 1*DIGIT)

+              / (";"  "permission"  "="  ("read"  /  "read-write"))

+                   ; Permission is case-insensitive

+              / (";" "name" "="  value)

+              / (";" "site" "=" value)

+              / (";" "dir" "=" value)

+              / (";" "mode" "=" value)

+              / (";" "server" "=" value)

+              / (";" "subject" "=" value)

+          ; access-type required;others required based on access-type

+

+   atype := "ftp" / "anon-ftp" / "tftp" / "local-file"

+                  / "afs" / "mail-server" / extension-token

+                  ; Case-insensitive

+

+7.4.  The Application Content-Type

+

+   The "application" Content-Type is to be used for data which do not

+   fit in any of the other categories, and particularly for data to be

+   processed by mail-based uses of application programs.  This is

+   information which must be processed by an application before it is

+   viewable or usable to a user.  Expected uses for Content-Type

+   application include mail-based file transfer, spreadsheets, data for

+   mail-based scheduling systems, and languages for "active"

+   (computational) email.  (The latter, in particular, can pose security

+   problems which must be understood by implementors, and are considered

+   in detail in the discussion of the application/PostScript content-

+   type.)

+

+   For example, a meeting scheduler might define a standard

+   representation for information about proposed meeting dates.  An

+   intelligent user agent would use this information to conduct a dialog

+   with the user, and might then send further mail based on that dialog.

+   More generally, there have been several "active" messaging languages

+   developed in which programs in a suitably specialized language are

+   sent through the mail and automatically run in the recipient's

+   environment.

+

+   Such applications may be defined as subtypes of the "application"

+   Content-Type.  This document defines two subtypes: octet-stream, and

+   PostScript.

+

+   In general, the subtype of application will often be the name of the

+   application for which the data are intended.  This does not mean,

+   however, that any application program name may be used freely as a

+   subtype of application.  Such usages (other than subtypes beginning

+

+

+

+Borenstein & Freed                                             [Page 49]

+

+RFC 1521                          MIME                    September 1993

+

+

+   with "x-") must be registered with IANA, as described in Appendix E.

+

+7.4.1.     The Application/Octet-Stream (primary) subtype

+

+   The primary subtype of application, "octet-stream", may be used to

+   indicate that a body contains binary data.  The set of possible

+   parameters includes, but is not limited to:

+

+      TYPE -- the general type or category of binary data.  This is

+      intended as information for the human recipient rather than for

+      any automatic processing.

+

+      PADDING -- the number of bits of padding that were appended to the

+      bit-stream comprising the actual contents to produce the enclosed

+      byte-oriented data.  This is useful for enclosing a bit-stream in

+      a body when the total number of bits is not a multiple of the byte

+      size.

+

+   An additional parameter, "conversions", was defined in [RFC-1341] but

+   has been removed.

+

+   RFC 1341 also defined the use of a "NAME" parameter which gave a

+   suggested file name to be used if the data were to be written to a

+   file.  This has been deprecated in anticipation of a separate

+   Content-Disposition header field, to be defined in a subsequent RFC.

+

+   The recommended action for an implementation that receives

+   application/octet-stream mail is to simply offer to put the data in a

+   file, with any Content-Transfer-Encoding undone, or perhaps to use it

+   as input to a user-specified process.

+

+   To reduce the danger of transmitting rogue programs through the mail,

+   it is strongly recommended that implementations NOT implement a

+   path-search mechanism whereby an arbitrary program named in the

+   Content-Type parameter (e.g., an "interpreter=" parameter) is found

+   and executed using the mail body as input.

+

+7.4.2.     The Application/PostScript subtype

+

+   A Content-Type of "application/postscript" indicates a PostScript

+   program.  Currently two variants of the PostScript language are

+   allowed; the original level 1 variant is described in [POSTSCRIPT]

+   and the more recent level 2 variant is described in [POSTSCRIPT2].

+

+   PostScript is a registered trademark of Adobe Systems, Inc.  Use of

+   the MIME content-type "application/postscript" implies recognition of

+   that trademark and all the rights it entails.

+

+

+

+

+Borenstein & Freed                                             [Page 50]

+

+RFC 1521                          MIME                    September 1993

+

+

+   The PostScript language definition provides facilities for internal

+   labeling of the specific language features a given program uses. This

+   labeling, called the PostScript document structuring conventions, is

+   very general and provides substantially more information than just

+   the language level.

+

+   The use of document structuring conventions, while not required, is

+   strongly recommended as an aid to interoperability.  Documents which

+   lack proper structuring conventions cannot be tested to see whether

+   or not they will work in a given environment.  As such, some systems

+   may assume the worst and refuse to process unstructured documents.

+

+   The execution of general-purpose PostScript interpreters entails

+   serious security risks, and implementors are discouraged from simply

+   sending PostScript email bodies to "off-the-shelf" interpreters.

+   While it is usually safe to send PostScript to a printer, where the

+   potential for harm is greatly constrained, implementors should

+   consider all of the following before they add interactive display of

+   PostScript bodies to their mail readers.

+

+   The remainder of this section outlines some, though probably not all,

+   of the possible problems with sending PostScript through the mail.

+

+   Dangerous operations in the PostScript language include, but may not

+   be limited to, the PostScript operators deletefile, renamefile,

+   filenameforall, and file.  File is only dangerous when applied to

+   something other than standard input or output. Implementations may

+   also define additional nonstandard file operators; these may also

+   pose a threat to security.  Filenameforall, the wildcard file search

+   operator, may appear at first glance to be harmless. Note, however,

+   that this operator has the potential to reveal information about what

+   files the recipient has access to, and this information may itself be

+   sensitive.  Message senders should avoid the use of potentially

+   dangerous file operators, since these operators are quite likely to

+   be unavailable in secure PostScript implementations.  Message-

+   receiving and -displaying software should either completely disable

+   all potentially dangerous file operators or take special care not to

+   delegate any special authority to their operation. These operators

+   should be viewed as being done by an outside agency when interpreting

+   PostScript documents.  Such disabling and/or checking should be done

+   completely outside of the reach of the PostScript language itself;

+   care should be taken to insure that no method exists for re-enabling

+   full-function versions of these operators.

+

+   The PostScript language provides facilities for exiting the normal

+   interpreter, or server, loop. Changes made in this "outer"

+   environment are customarily retained across documents, and may in

+   some cases be retained semipermanently in nonvolatile memory. The

+

+

+

+Borenstein & Freed                                             [Page 51]

+

+RFC 1521                          MIME                    September 1993

+

+

+   operators associated with exiting the interpreter loop have the

+   potential to interfere with subsequent document processing. As such,

+   their unrestrained use constitutes a threat of service denial.

+   PostScript operators that exit the interpreter loop include, but may

+   not be limited to, the exitserver and startjob operators.  Message-

+   sending software should not generate PostScript that depends on

+   exiting the interpreter loop to operate. The ability to exit will

+   probably be unavailable in secure PostScript implementations.

+   Message-receiving and -displaying software should, if possible,

+   disable the ability to make retained changes to the PostScript

+   environment, and eliminate the startjob and exitserver commands.  If

+   these commands cannot be eliminated, the password associated with

+   them should at least be set to a hard-to-guess value.

+

+   PostScript provides operators for setting system-wide and device-

+   specific parameters. These parameter settings may be retained across

+   jobs and may potentially pose a threat to the correct operation of

+   the interpreter.  The PostScript operators that set system and device

+   parameters include, but may not be limited to, the setsystemparams

+   and setdevparams operators.  Message-sending software should not

+   generate PostScript that depends on the setting of system or device

+   parameters to operate correctly. The ability to set these parameters

+   will probably be unavailable in secure PostScript implementations.

+   Message-receiving and -displaying software should, if possible,

+   disable the ability to change system and device parameters.  If these

+   operators cannot be disabled, the password associated with them

+   should at least be set to a hard-to-guess value.

+

+   Some PostScript implementations provide nonstandard facilities for

+   the direct loading and execution of machine code.  Such facilities

+   are quite obviously open to substantial abuse.  Message-sending

+   software should not make use of such features. Besides being totally

+   hardware- specific, they are also likely to be unavailable in secure

+   implementations of PostScript.  Message-receiving and -displaying

+   software should not allow such operators to be used if they exist.

+

+   PostScript is an extensible language, and many, if not most,

+   implementations of it provide a number of their own extensions. This

+   document does not deal with such extensions explicitly since they

+   constitute an unknown factor.  Message-sending software should not

+   make use of nonstandard extensions; they are likely to be missing

+   from some implementations. Message-receiving and -displaying software

+   should make sure that any nonstandard PostScript operators are secure

+   and don't present any kind of threat.

+

+   It is possible to write PostScript that consumes huge amounts of

+   various system resources. It is also possible to write PostScript

+   programs that loop infinitely.  Both types of programs have the

+

+

+

+Borenstein & Freed                                             [Page 52]

+

+RFC 1521                          MIME                    September 1993

+

+

+   potential to cause damage if sent to unsuspecting recipients.

+   Message-sending software should avoid the construction and

+   dissemination of such programs, which is antisocial.  Message-

+   receiving and -displaying software should provide appropriate

+   mechanisms to abort processing of a document after a reasonable

+   amount of time has elapsed. In addition, PostScript interpreters

+   should be limited to the consumption of only a reasonable amount of

+   any given system resource.

+

+   Finally, bugs may exist in some PostScript interpreters which could

+   possibly be exploited to gain unauthorized access to a recipient's

+   system.  Apart from noting this possibility, there is no specific

+   action to take to prevent this, apart from the timely correction of

+   such bugs if any are found.

+

+7.4.3.     Other Application subtypes

+

+   It is expected that many other subtypes of application will be

+   defined in the future.  MIME implementations must generally treat any

+   unrecognized subtypes as being equivalent to application/octet-

+   stream.

+

+   The formal grammar for content-type header fields for application

+   data is given by:

+

+   application-type :=  "application" "/" application-subtype

+

+   application-subtype := ("octet-stream" *stream-param)

+                       / "postscript" / extension-token

+

+   stream-param :=  (";" "type" "=" value)

+                       / (";" "padding" "=" padding)

+

+   padding := "0" / "1" /  "2" /  "3" / "4" / "5" / "6" / "7"

+

+7.5.  The Image Content-Type

+

+   A Content-Type of "image" indicates that the body contains an image.

+   The subtype names the specific image format.  These names are case

+   insensitive.  Two initial subtypes are "jpeg" for the JPEG format,

+   JFIF encoding, and "gif" for GIF format [GIF].

+

+   The list of image subtypes given here is neither exclusive nor

+   exhaustive, and is expected to grow as more types are registered with

+   IANA, as described in Appendix E.

+

+   The formal grammar for the content-type header field for data of type

+   image is given by:

+

+

+

+Borenstein & Freed                                             [Page 53]

+

+RFC 1521                          MIME                    September 1993

+

+

+   image-type := "image" "/" ("gif" / "jpeg" / extension-token)

+

+7.6.  The Audio Content-Type

+

+   A Content-Type of "audio" indicates that the body contains audio

+   data.  Although there is not yet a consensus on an "ideal" audio

+   format for use with computers, there is a pressing need for a format

+   capable of providing interoperable behavior.

+

+   The initial subtype of "basic" is specified to meet this requirement

+   by providing an absolutely minimal lowest common denominator audio

+   format.  It is expected that richer formats for higher quality and/or

+   lower bandwidth audio will be defined by a later document.

+

+   The content of the "audio/basic" subtype is audio encoded using 8-bit

+   ISDN mu-law [PCM].  When this subtype is present, a sample rate of

+   8000 Hz and a single channel is assumed.

+

+   The formal grammar for the content-type header field for data of type

+   audio is given by:

+

+   audio-type := "audio" "/" ("basic" / extension-token)

+

+7.7.  The Video Content-Type

+

+   A Content-Type of "video" indicates that the body contains a time-

+   varying-picture image, possibly with color and coordinated sound.

+   The term "video" is used extremely generically, rather than with

+   reference to any particular technology or format, and is not meant to

+   preclude subtypes such as animated drawings encoded compactly.  The

+   subtype "mpeg" refers to video coded according to the MPEG standard

+   [MPEG].

+

+   Note that although in general this document strongly discourages the

+   mixing of multiple media in a single body, it is recognized that many

+   so-called "video" formats include a representation for synchronized

+   audio, and this is explicitly permitted for subtypes of "video".

+

+   The formal grammar for the content-type header field for data of type

+   video is given by:

+

+   video-type := "video" "/" ("mpeg" / extension-token)

+

+7.8.  Experimental Content-Type Values

+

+   A Content-Type value beginning with the characters "X-" is a private

+   value, to be used by consenting mail systems by mutual agreement.

+   Any format without a rigorous and public definition must be named

+

+

+

+Borenstein & Freed                                             [Page 54]

+

+RFC 1521                          MIME                    September 1993

+

+

+   with an "X-" prefix, and publicly specified values shall never begin

+   with "X-".  (Older versions of the widely-used Andrew system use the

+   "X-BE2" name, so new systems should probably choose a different

+   name.)

+

+   In general, the use of "X-" top-level types is strongly discouraged.

+   Implementors should invent subtypes of the existing types whenever

+   possible.  The invention of new types is intended to be restricted

+   primarily to the development of new media types for email, such as

+   digital odors or holography, and not for new data formats in general.

+   In many cases, a subtype of application will be more appropriate than

+   a new top-level type.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 55]

+

+RFC 1521                          MIME                    September 1993

+

+

+8. Summary

+

+   Using the MIME-Version, Content-Type, and Content-Transfer-Encoding

+   header fields, it is possible to include, in a standardized way,

+   arbitrary types of data objects with RFC 822 conformant mail

+   messages.  No restrictions imposed by either RFC 821 or RFC 822 are

+   violated, and care has been taken to avoid problems caused by

+   additional restrictions imposed by the characteristics of some

+   Internet mail transport mechanisms (see Appendix B). The "multipart"

+   and "message" Content-Types allow mixing and hierarchical structuring

+   of objects of different types in a single message.  Further Content-

+   Types provide a standardized mechanism for tagging messages or body

+   parts as audio, image, or several other kinds of data.  A

+   distinguished parameter syntax allows further specification of data

+   format details, particularly the specification of alternate character

+   sets.  Additional optional header fields provide mechanisms for

+   certain extensions deemed desirable by many implementors.  Finally, a

+   number of useful Content-Types are defined for general use by

+   consenting user agents, notably message/partial, and

+   message/external-body.

+

+9. Security Considerations

+

+   Security issues are discussed in Section 7.4.2 and in Appendix F.

+   Implementors should pay special attention to the security

+   implications of any mail content-types that can cause the remote

+   execution of any actions in the recipient's environment.  In such

+   cases, the discussion of the application/postscript content-type in

+   Section 7.4.2 may serve as a model for considering other content-

+   types with remote execution capabilities.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 56]

+

+RFC 1521                          MIME                    September 1993

+

+

+10. Authors' Addresses

+

+   For more information, the authors of this document may be contacted

+   via Internet mail:

+

+   Nathaniel S. Borenstein

+   MRE 2D-296, Bellcore

+   445 South St.

+   Morristown, NJ 07962-1910

+

+   Phone: +1 201 829 4270

+   Fax:  +1 201 829 7019

+   Email: nsb@bellcore.com

+

+

+   Ned Freed

+   Innosoft International, Inc.

+   250 West First Street

+   Suite 240

+   Claremont, CA 91711

+

+   Phone:  +1 909 624 7907

+   Fax: +1 909 621 5319

+   Email: ned@innosoft.com

+

+   MIME is a result of the work of the Internet Engineering Task Force

+   Working Group on Email Extensions. The chairman of that group, Greg

+   Vaudreuil, may be reached at:

+

+   Gregory M. Vaudreuil

+   Tigon Corporation

+   17060 Dallas Parkway

+   Dallas Texas, 75248

+

+   Phone:    +1 214-733-2722

+   EMail: gvaudre@cnri.reston.va.us

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 57]

+

+RFC 1521                          MIME                    September 1993

+

+

+11. Acknowledgements

+

+   This document is the result of the collective effort of a large

+   number of people, at several IETF meetings, on the IETF-SMTP and

+   IETF-822 mailing lists, and elsewhere.  Although any enumeration

+   seems doomed to suffer from egregious omissions, the following are

+   among the many contributors to this effort:

+

+            Harald Tveit Alvestrand       Timo Lehtinen

+            Randall Atkinson              John R. MacMillan

+            Philippe Brandon              Rick McGowan

+            Kevin Carosso                 Leo Mclaughlin

+            Uhhyung Choi                  Goli Montaser-Kohsari

+            Cristian Constantinof         Keith Moore

+            Mark Crispin                  Tom Moore

+            Dave Crocker                  Erik Naggum

+            Terry Crowley                 Mark Needleman

+            Walt Daniels                  John Noerenberg

+            Frank Dawson                  Mats Ohrman

+            Hitoshi Doi                   Julian Onions

+            Kevin Donnelly                Michael Patton

+            Keith Edwards                 David J. Pepper

+            Chris Eich                    Blake C. Ramsdell

+            Johnny Eriksson               Luc Rooijakkers

+            Craig Everhart                Marshall T. Rose

+            Patrik Faeltstroem            Jonathan Rosenberg

+            Erik E. Fair                  Jan Rynning

+            Roger Fajman                  Harri Salminen

+            Alain Fontaine                Michael Sanderson

+            James M. Galvin               Masahiro Sekiguchi

+            Philip Gladstone              Mark Sherman

+            Thomas Gordon                 Keld Simonsen

+            Phill Gross                   Bob Smart

+            James Hamilton                Peter Speck

+            Steve Hardcastle-Kille        Henry Spencer

+            David Herron                  Einar Stefferud

+            Bruce Howard                  Michael Stein

+            Bill Janssen                  Klaus Steinberger

+            Olle Jaernefors               Peter Svanberg

+            Risto Kankkunen               James Thompson

+            Phil Karn                     Steve Uhler

+            Alan Katz                     Stuart Vance

+            Tim Kehres                    Erik van der Poel

+            Neil Katin                    Guido van Rossum

+            Kyuho Kim                     Peter Vanderbilt

+            Anders Klemets                Greg Vaudreuil

+            John Klensin                  Ed Vielmetti

+            Valdis Kletniek               Ryan Waldron

+

+

+

+Borenstein & Freed                                             [Page 58]

+

+RFC 1521                          MIME                    September 1993

+

+

+            Jim Knowles                   Wally Wedel

+            Stev Knowles                  Sven-Ove Westberg

+            Bob Kummerfeld                Brian Wideen

+            Pekka Kytolaakso              John Wobus

+            Stellan Lagerstrom            Glenn Wright

+            Vincent Lau                   Rayan Zachariassen

+            Donald Lindsay                David Zimmerman

+            Marc Andreessen               Bob Braden

+            Brian Capouch                 Peter Clitherow

+            Dave Collier-Brown            John Coonrod

+            Stephen Crocker               Jim Davis

+            Axel Deininger                Dana S Emery

+            Martin Forssen                Stephen Gildea

+            Terry Gray                    Mark Horton

+            Warner Losh                   Carlyn Lowery

+            Laurence Lundblade            Charles Lynn

+            Larry Masinter                Michael J. McInerny

+            Jon Postel                    Christer Romson

+            Yutaka Sato                   Markku Savela

+            Richard Alan Schafer          Larry W. Virden

+            Rhys Weatherly                Jay Weber

+            Dave Wecker

+

+The authors apologize for any omissions from this list, which are

+certainly unintentional.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 59]

+

+RFC 1521                          MIME                    September 1993

+

+

+Appendix A -- Minimal MIME-Conformance

+

+   The mechanisms described in this document are open-ended.  It is

+   definitely not expected that all implementations will support all of

+   the Content-Types described, nor that they will all share the same

+   extensions.  In order to promote interoperability, however, it is

+   useful to define the concept of "MIME-conformance" to define a

+   certain level of implementation that allows the useful interworking

+   of messages with content that differs from US ASCII text.  In this

+   section, we specify the requirements for such conformance.

+

+   A mail user agent that is MIME-conformant MUST:

+

+      1.  Always generate a "MIME-Version: 1.0" header field.

+

+      2.  Recognize the Content-Transfer-Encoding header field, and

+      decode all received data encoded with either the quoted-printable

+      or base64 implementations.  Encode any data sent that is not in

+      seven-bit mail-ready representation using one of these

+      transformations and include the appropriate Content-Transfer-

+      Encoding header field, unless the underlying transport mechanism

+      supports non-seven-bit data, as SMTP does not.

+

+      3.  Recognize and interpret the Content-Type header field, and

+      avoid showing users raw data with a Content-Type field other than

+      text.  Be able to send at least text/plain messages, with the

+      character set specified as a parameter if it is not US-ASCII.

+

+      4.  Explicitly handle the following Content-Type values, to at

+      least the following extents:

+

+      Text:

+

+            -- Recognize and display "text" mail

+                 with the character set "US-ASCII."

+

+            -- Recognize other character sets at

+                 least to the extent of being able

+                 to inform the user about what

+                 character set the message uses.

+

+            -- Recognize the "ISO-8859-*" character

+                 sets to the extent of being able to

+                 display those characters that are

+                 common to ISO-8859-* and US-ASCII,

+                 namely all characters represented

+                 by octet values 0-127.

+

+

+

+

+Borenstein & Freed                                             [Page 60]

+

+RFC 1521                          MIME                    September 1993

+

+

+            -- For unrecognized subtypes, show or

+                 offer to show the user the "raw"

+                 version of the data after

+                 conversion of the content from

+                 canonical form to local form.

+

+       Message:

+

+            -- Recognize and display at least the

+                 primary (822) encapsulation.

+

+       Multipart:

+

+            -- Recognize the primary (mixed)

+                 subtype.  Display all relevant

+                 information on the message level

+                 and the body part header level and

+                 then display or offer to display

+                 each of the body parts individually.

+

+            -- Recognize the "alternative" subtype,

+                 and avoid showing the user

+                 redundant parts of

+                 multipart/alternative mail.

+

+            -- Treat any unrecognized subtypes as if

+                 they were "mixed".

+

+       Application:

+

+            -- Offer the ability to remove either of

+                 the two types of Content-Transfer-

+                 Encoding defined in this document

+                 and put the resulting information

+                 in a user file.

+

+      5.  Upon encountering any unrecognized Content- Type, an

+      implementation must treat it as if it had a Content-Type of

+      "application/octet-stream" with no parameter sub-arguments.  How

+      such data are handled is up to an implementation, but likely

+      options for handling such unrecognized data include offering the

+      user to write it into a file (decoded from its mail transport

+      format) or offering the user to name a program to which the

+      decoded data should be passed as input.  Unrecognized predefined

+      types, which in a MIME-conformant mailer might still include

+      audio, image, or video, should also be treated in this way.

+

+   A user agent that meets the above conditions is said to be MIME-

+

+

+

+Borenstein & Freed                                             [Page 61]

+

+RFC 1521                          MIME                    September 1993

+

+

+   conformant.  The meaning of this phrase is that it is assumed to be

+   "safe" to send virtually any kind of properly-marked data to users of

+   such mail systems, because such systems will at least be able to

+   treat the data as undifferentiated binary, and will not simply splash

+   it onto the screen of unsuspecting users.  There is another sense in

+   which it is always "safe" to send data in a format that is MIME-

+   conformant, which is that such data will not break or be broken by

+   any known systems that are conformant with RFC 821 and RFC 822.  User

+   agents that are MIME-conformant have the additional guarantee that

+   the user will not be shown data that were never intended to be viewed

+   as text.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 62]

+

+RFC 1521                          MIME                    September 1993

+

+

+Appendix B -- General Guidelines For Sending Email Data

+

+   Internet email is not a perfect, homogeneous system.  Mail may become

+   corrupted at several stages in its travel to a final destination.

+   Specifically, email sent throughout the Internet may travel across

+   many networking technologies.  Many networking and mail technologies

+   do not support the full functionality possible in the SMTP transport

+   environment. Mail traversing these systems is likely to be modified

+   in such a way that it can be transported.

+

+   There exist many widely-deployed non-conformant MTAs in the Internet.

+   These MTAs, speaking the SMTP protocol, alter messages on the fly to

+   take advantage of the internal data structure of the hosts they are

+   implemented on, or are just plain broken.

+

+   The following guidelines may be useful to anyone devising a data

+   format (Content-Type) that will survive the widest range of

+   networking technologies and known broken MTAs unscathed.  Note that

+   anything encoded in the base64 encoding will satisfy these rules, but

+   that some well-known mechanisms, notably the UNIX uuencode facility,

+   will not.  Note also that anything encoded in the Quoted-Printable

+   encoding will survive most gateways intact, but possibly not some

+   gateways to systems that use the EBCDIC character set.

+

+      (1) Under some circumstances the encoding used for data may change

+      as part of normal gateway or user agent operation. In particular,

+      conversion from base64 to quoted-printable and vice versa may be

+      necessary. This may result in the confusion of CRLF sequences with

+      line breaks in text bodies. As such, the persistence of CRLF as

+      something other than a line break must not be relied on.

+

+      (2) Many systems may elect to represent and store text data using

+      local newline conventions. Local newline conventions may not match

+      the RFC822 CRLF convention -- systems are known that use plain CR,

+      plain LF, CRLF, or counted records.  The result is that isolated

+      CR and LF characters are not well tolerated in general; they may

+      be lost or converted to delimiters on some systems, and hence must

+      not be relied on.

+

+      (3) TAB (HT) characters may be misinterpreted or may be

+      automatically converted to variable numbers of spaces.  This is

+      unavoidable in some environments, notably those not based on the

+      ASCII character set. Such conversion is STRONGLY DISCOURAGED, but

+      it may occur, and mail formats must not rely on the persistence of

+      TAB (HT) characters.

+

+      (4) Lines longer than 76 characters may be wrapped or truncated in

+      some environments. Line wrapping and line truncation are STRONGLY

+

+

+

+Borenstein & Freed                                             [Page 63]

+

+RFC 1521                          MIME                    September 1993

+

+

+      DISCOURAGED, but unavoidable in some cases. Applications which

+      require long lines must somehow differentiate between soft and

+      hard line breaks.  (A simple way to do this is to use the quoted-

+      printable encoding.)

+

+      (5) Trailing "white space" characters (SPACE, TAB (HT)) on a line

+      may be discarded by some transport agents, while other transport

+      agents may pad lines with these characters so that all lines in a

+      mail file are of equal length.  The persistence of trailing white

+      space, therefore, must not be relied on.

+

+      (6) Many mail domains use variations on the ASCII character set,

+      or use character sets such as EBCDIC which contain most but not

+      all of the US-ASCII characters.  The correct translation of

+      characters not in the "invariant" set cannot be depended on across

+      character converting gateways.  For example, this situation is a

+      problem when sending uuencoded information across BITNET, an

+      EBCDIC system.  Similar problems can occur without crossing a

+      gateway, since many Internet hosts use character sets other than

+      ASCII internally.  The definition of Printable Strings in X.400

+      adds further restrictions in certain special cases.  In

+      particular, the only characters that are known to be consistent

+      across all gateways are the 73 characters that correspond to the

+      upper and lower case letters A-Z and a-z, the 10 digits 0-9, and

+      the following eleven special characters:

+

+                        "'"  (ASCII code 39)

+                        "("  (ASCII code 40)

+                        ")"  (ASCII code 41)

+                        "+"  (ASCII code 43)

+                        ","  (ASCII code 44)

+                        "-"  (ASCII code 45)

+                        "."  (ASCII code 46)

+                        "/"  (ASCII code 47)

+                        ":"  (ASCII code 58)

+                        "="  (ASCII code 61)

+                        "?"  (ASCII code 63)

+

+      A maximally portable mail representation, such as the base64

+      encoding, will confine itself to relatively short lines of text in

+      which the only meaningful characters are taken from this set of 73

+      characters.

+

+      (7) Some mail transport agents will corrupt data that includes

+      certain literal strings.  In particular, a period (".") alone on a

+      line is known to be corrupted by some (incorrect) SMTP

+      implementations, and a line that starts with the five characters

+      "From " (the fifth character is a SPACE) are commonly corrupted as

+

+

+

+Borenstein & Freed                                             [Page 64]

+

+RFC 1521                          MIME                    September 1993

+

+

+      well.  A careful composition agent can prevent these corruptions

+      by encoding the data (e.g., in the quoted-printable encoding,

+      "=46rom " in place of "From " at the start of a line, and "=2E" in

+      place of "." alone on a line.

+

+   Please note that the above list is NOT a list of recommended

+   practices for MTAs.  RFC 821 MTAs are prohibited from altering the

+   character of white space or wrapping long lines.  These BAD and

+   illegal practices are known to occur on established networks, and

+   implementations should be robust in dealing with the bad effects they

+   can cause.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 65]

+

+RFC 1521                          MIME                    September 1993

+

+

+Appendix C -- A Complex Multipart Example

+

+   What follows is the outline of a complex multipart message.  This

+   message has five parts to be displayed serially: two introductory

+   plain text parts, an embedded multipart message, a richtext part, and

+   a closing encapsulated text message in a non-ASCII character set.

+   The embedded multipart message has two parts to be displayed in

+   parallel, a picture and an audio fragment.

+

+      MIME-Version: 1.0

+      From: Nathaniel Borenstein <nsb@bellcore.com>

+      To: Ned Freed <ned@innosoft.com>

+      Subject: A multipart example

+      Content-Type: multipart/mixed;

+           boundary=unique-boundary-1

+

+      This is the preamble area of a multipart message.

+      Mail readers that understand multipart format

+      should ignore this preamble.

+      If you are reading this text, you might want to

+      consider changing to a mail reader that understands

+      how to properly display multipart messages.

+      --unique-boundary-1

+

+         ...Some text appears here...

+      [Note that the preceding blank line means

+      no header fields were given and this is text,

+      with charset US ASCII.  It could have been

+      done with explicit typing as in the next part.]

+

+      --unique-boundary-1

+      Content-type: text/plain; charset=US-ASCII

+

+      This could have been part of the previous part,

+      but illustrates explicit versus implicit

+      typing of body parts.

+

+      --unique-boundary-1

+      Content-Type: multipart/parallel;

+           boundary=unique-boundary-2

+

+

+      --unique-boundary-2

+      Content-Type: audio/basic

+      Content-Transfer-Encoding: base64

+

+         ... base64-encoded 8000 Hz single-channel

+             mu-law-format audio data goes here....

+

+

+

+Borenstein & Freed                                             [Page 66]

+

+RFC 1521                          MIME                    September 1993

+

+

+      --unique-boundary-2

+      Content-Type: image/gif

+      Content-Transfer-Encoding: base64

+

+         ... base64-encoded image data goes here....

+

+      --unique-boundary-2--

+

+      --unique-boundary-1

+      Content-type: text/richtext

+

+      This is <bold><italic>richtext.</italic></bold>

+      <smaller>as defined in RFC 1341</smaller>

+      <nl><nl>Isn't it

+      <bigger><bigger>cool?</bigger></bigger>

+

+      --unique-boundary-1

+      Content-Type: message/rfc822

+

+      From: (mailbox in US-ASCII)

+      To: (address in US-ASCII)

+      Subject: (subject in US-ASCII)

+      Content-Type: Text/plain; charset=ISO-8859-1

+      Content-Transfer-Encoding: Quoted-printable

+

+         ... Additional text in ISO-8859-1 goes here ...

+

+      --unique-boundary-1--

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 67]

+

+RFC 1521                          MIME                    September 1993

+

+

+Appendix D -- Collected Grammar

+

+   This appendix contains the complete BNF grammar for all the syntax

+   specified by this document.

+

+   By itself, however, this grammar is incomplete.  It refers to several

+   entities that are defined by RFC 822.  Rather than reproduce those

+   definitions here, and risk unintentional differences between the two,

+   this document simply refers the reader to RFC 822 for the remaining

+   definitions.  Wherever a term is undefined, it refers to the RFC 822

+   definition.

+

+   application-subtype := ("octet-stream" *stream-param)

+                       / "postscript" / extension-token

+

+   application-type :=  "application" "/" application-subtype

+

+   attribute := token    ; case-insensitive

+

+   atype := "ftp" / "anon-ftp" / "tftp" / "local-file"

+                  / "afs" / "mail-server" / extension-token

+                  ; Case-insensitive

+

+   audio-type := "audio" "/" ("basic" / extension-token)

+

+   body-part := <"message" as defined in RFC 822,

+            with all header fields optional, and with the

+            specified delimiter not occurring anywhere in

+            the message body, either on a line by itself

+            or as a substring anywhere.>

+

+      NOTE: In certain transport enclaves, RFC 822 restrictions such as

+      the one that limits bodies to printable ASCII characters may not

+      be in force.  (That is, the transport domains may resemble

+      standard Internet mail transport as specified in RFC821 and

+      assumed by RFC822, but without certain restrictions.)  The

+      relaxation of these restrictions should be construed as locally

+      extending the definition of bodies, for example to include octets

+      outside of the ASCII range, as long as these extensions are

+      supported by the transport and adequately documented in the

+      Content-Transfer-Encoding header field. However, in no event are

+      headers (either message headers or body-part headers) allowed to

+      contain anything other than ASCII characters.

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 68]

+

+RFC 1521                          MIME                    September 1993

+

+

+   boundary := 0*69<bchars> bcharsnospace

+

+   bchars := bcharsnospace / " "

+

+   bcharsnospace :=    DIGIT / ALPHA / "'" / "(" / ")" / "+"  / "_"

+                  / "," / "-" / "." / "/" / ":" / "=" / "?"

+

+   charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3"

+        / "iso-8859-4" / "iso-8859-5" /  "iso-8859-6" / "iso-8859-7"

+        / "iso-8859-8" / "iso-8859-9" / extension-token

+        ; case insensitive

+

+   close-delimiter := "--" boundary "--" CRLF;Again,no space by "--",

+

+   content  := "Content-Type"  ":" type "/" subtype  *(";" parameter)

+             ; case-insensitive matching of type and subtype

+

+   delimiter := "--" boundary CRLF  ;taken from Content-Type field.

+                                ; There must be no space

+                                ; between "--" and boundary.

+

+   description := "Content-Description" ":" *text

+

+   discard-text := *(*text CRLF)

+

+   encapsulation := delimiter body-part CRLF

+

+   encoding := "Content-Transfer-Encoding" ":" mechanism

+

+   epilogue := discard-text        ;  to  be  ignored upon receipt.

+

+   extension-token :=  x-token / iana-token

+

+   external-param :=   (";" "access-type" "=" atype)

+                  / (";" "expiration" "=" date-time)

+

+                       ; Note that date-time is quoted

+                  / (";" "size" "=" 1*DIGIT)

+                  / (";"  "permission"  "="  ("read" / "read-write"))

+                       ; Permission is case-insensitive

+                  / (";" "name" "="  value)

+                  / (";" "site" "=" value)

+                  / (";" "dir" "=" value)

+                  / (";" "mode" "=" value)

+                  / (";" "server" "=" value)

+                  / (";" "subject" "=" value)

+           ;access-type required; others required based on access-type

+

+

+

+

+Borenstein & Freed                                             [Page 69]

+

+RFC 1521                          MIME                    September 1993

+

+

+   iana-token := <a publicly-defined extension token,

+             registered with IANA, as specified in

+             appendix E>

+

+   id :=  "Content-ID" ":" msg-id

+

+   image-type := "image" "/" ("gif" / "jpeg" / extension-token)

+

+   mechanism :=     "7bit"    ;  case-insensitive

+                  / "quoted-printable"

+                  / "base64"

+                  / "8bit"

+                  / "binary"

+                  / x-token

+

+   message-subtype := "rfc822"

+                  / "partial" 2#3partial-param

+                  / "external-body" 1*external-param

+                  / extension-token

+

+   message-type := "message" "/" message-subtype

+

+   multipart-body :=preamble 1*encapsulation close-delimiter epilogue

+

+   multipart-subtype := "mixed" / "parallel" / "digest"

+                  / "alternative" / extension-token

+

+   multipart-type := "multipart" "/" multipart-subtype

+                  ";" "boundary" "=" boundary

+

+   octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")

+        ; octet must be used for characters > 127, =, SPACE, or

+   TAB,

+        ; and is recommended for any characters not listed in

+        ; Appendix B as "mail-safe".

+

+   padding := "0" / "1" /  "2" /  "3" / "4" / "5" / "6" / "7"

+

+   parameter := attribute "=" value

+

+   partial-param :=     (";" "id" "=" value)

+                  /  (";" "number" "=" 1*DIGIT)

+                  /  (";" "total" "=" 1*DIGIT)

+             ; id & number required;total required for last part

+

+   preamble := discard-text       ;  to  be  ignored upon receipt.

+

+   ptext := octet / <any ASCII character except "=", SPACE,  or TAB>

+

+

+

+Borenstein & Freed                                             [Page 70]

+

+RFC 1521                          MIME                    September 1993

+

+

+        ; characters not listed as "mail-safe" in Appendix B

+        ; are also not recommended.

+

+   quoted-printable := ([*(ptext / SPACE /  TAB)  ptext]  ["="] CRLF)

+        ; Maximum line length of 76 characters excluding CRLF

+

+   stream-param :=  (";" "type" "=" value)

+                / (";" "padding" "=" padding)

+

+   subtype := token  ; case-insensitive

+

+   text-subtype := "plain" / extension-token

+

+   text-type := "text" "/" text-subtype [";" "charset" "=" charset]

+

+   token  :=  1*<any  (ASCII) CHAR except SPACE, CTLs, or tspecials>

+

+   tspecials :=  "(" / ")" / "<" / ">" / "@"

+              /  "," / ";" / ":" / "\" / <">

+              /  "/" / "[" / "]" / "?" / "="

+             ; Must be in quoted-string,

+             ; to use within parameter values

+

+

+   type :=     "application"     /  "audio"   ; case-insensitive

+             / "image"           / "message"

+             / "multipart"  / "text"

+             / "video"           / extension-token

+             ; All values case-insensitive

+

+   value := token / quoted-string

+

+   version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

+

+   video-type := "video" "/" ("mpeg" / extension-token)

+

+   x-token := <The two characters "X-" or "x-" followed, with no

+              intervening white space, by any token>

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 71]

+

+RFC 1521                          MIME                    September 1993

+

+

+Appendix E -- IANA Registration Procedures

+

+   MIME has been carefully designed to have extensible mechanisms, and

+   it is expected that the set of content-type/subtype pairs and their

+   associated parameters will grow significantly with time.  Several

+   other MIME fields, notably character set names, access-type

+   parameters for the message/external-body type, and possibly even

+   Content-Transfer-Encoding values, are likely to have new values

+   defined over time.  In order to ensure that the set of such values is

+   developed in an orderly, well-specified, and public manner, MIME

+   defines a registration process which uses the Internet Assigned

+   Numbers Authority (IANA) as a central registry for such values.

+

+   In general, parameters in the content-type header field are used to

+   convey supplemental information for various content types, and their

+   use is defined when the content-type and subtype are defined.  New

+   parameters should not be defined as a way to introduce new

+   functionality.

+

+   In order to simplify and standardize the registration process, this

+   appendix gives templates for the registration of new values with

+   IANA.  Each of these is given in the form of an email message

+   template, to be filled in by the registering party.

+

+   E.1  Registration of New Content-type/subtype Values

+

+   Note that MIME is generally expected to be extended by subtypes.  If

+   a new fundamental top-level type is needed, its specification must be

+   published as an RFC or submitted in a form suitable to become an RFC,

+   and be subject to the Internet standards process.

+

+      To:  IANA@isi.edu

+      Subject:  Registration of new MIME

+           content-type/subtype

+

+      MIME type name:

+

+      (If the above is not an existing top-level MIME type,

+      please explain why an existing type cannot be used.)

+

+      MIME subtype name:

+

+      Required parameters:

+

+      Optional parameters:

+

+      Encoding considerations:

+

+

+

+

+Borenstein & Freed                                             [Page 72]

+

+RFC 1521                          MIME                    September 1993

+

+

+      Security considerations:

+

+      Published specification:

+

+      (The published specification must be an Internet RFC or

+      RFC-to-be if a new top-level type is being defined, and

+      must be a publicly available specification in any

+      case.)

+

+      Person & email address to contact for further information:

+

+   E.2  Registration of New Access-type Values

+           for Message/external-body

+

+      To:  IANA@isi.edu

+      Subject:  Registration of new MIME Access-type for

+           Message/external-body content-type

+

+      MIME access-type name:

+

+      Required parameters:

+

+      Optional parameters:

+

+      Published specification:

+

+      (The published specification must be an Internet RFC or

+      RFC-to-be.)

+

+      Person & email address to contact for further information:

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 73]

+

+RFC 1521                          MIME                    September 1993

+

+

+Appendix F -- Summary of the Seven Content-types

+

+   Content-type: text

+

+   Subtypes defined by this document:  plain

+

+   Important Parameters: charset

+

+   Encoding notes: quoted-printable generally preferred if an encoding

+      is needed and the character set is mostly an ASCII superset.

+

+   Security considerations: Rich text formats such as TeX and Troff

+      often contain mechanisms for executing arbitrary commands or file

+      system operations, and should not be used automatically unless

+      these security problems have been addressed.  Even plain text may

+      contain control characters that can be used to exploit the

+      capabilities of "intelligent" terminals and cause security

+      violations.  User interfaces designed to run on such terminals

+      should be aware of and try to prevent such problems.

+

+   ________________________________________________________

+   Content-type: multipart

+

+   Subtypes defined by  this  document: mixed, alternative,

+        digest, parallel.

+

+   Important Parameters: boundary

+

+   Encoding notes: No content-transfer-encoding is permitted.

+

+   ________________________________________________________

+   Content-type: message

+

+   Subtypes defined by this document: rfc822, partial, external-body

+

+   Important Parameters: id, number, total, access-type, expiration,

+      size, permission, name, site, directory, mode, server, subject

+

+   Encoding notes: No content-transfer-encoding is permitted.

+      Specifically, only "7bit" is permitted for "message/partial" or

+      "message/external-body", and only "7bit", "8bit", or "binary" are

+      permitted for other subtypes of "message".

+   ______________________________________________________________

+   Content-type: application

+

+   Subtypes defined by this document:  octet-stream, postscript

+

+   Important Parameters:  type, padding

+

+

+

+Borenstein & Freed                                             [Page 74]

+

+RFC 1521                          MIME                    September 1993

+

+

+   Deprecated Parameters: name and conversions were

+                          defined in RFC 1341.

+

+   Encoding notes: base64 preferred for unreadable subtypes.

+

+   Security considerations:  This  type  is  intended  for  the

+   transmission  of data to be interpreted by locally-installed

+   programs.  If used,  for  example,  to  transmit  executable

+   binary  programs  or programs in general-purpose interpreted

+   languages, such as LISP programs or  shell  scripts,  severe

+   security  problems  could  result.   Authors of mail-reading

+   agents are cautioned against giving their systems the  power

+   to  execute  mail-based  application  data without carefully

+   considering  the  security  implications.    While   it   is

+   certainly  possible  to  define safe application formats and

+   even safe interpreters for unsafe formats, each  interpreter

+   should   be   evaluated  separately  for  possible  security

+   problems.

+   ________________________________________________________________

+   Content-type: image

+

+   Subtypes defined by this document:  jpeg, gif

+

+   Important Parameters: none

+

+   Encoding notes: base64 generally preferred

+   ________________________________________________________________

+   Content-type: audio

+

+   Subtypes defined by this document:  basic

+

+   Important Parameters: none

+

+   Encoding notes: base64 generally preferred

+   ________________________________________________________________

+   Content-type: video

+

+   Subtypes defined by this document:  mpeg

+

+   Important Parameters: none

+

+   Encoding notes: base64 generally preferred

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 75]

+

+RFC 1521                          MIME                    September 1993

+

+

+Appendix G -- Canonical Encoding Model

+

+   There was some confusion, in earlier drafts of this memo, regarding

+   the model for when email data was to be converted to canonical form

+   and encoded, and in particular how this process would affect the

+   treatment of CRLFs, given that the representation of newlines varies

+   greatly from system to system.  For this reason, a canonical model

+   for encoding is presented below.

+

+   The process of composing a MIME entity can be modeled as being done

+   in a number of steps.  Note that these steps are roughly similar to

+   those steps used in RFC 1421 and are performed for each 'innermost

+   level' body:

+

+   Step 1.  Creation of local form.

+

+   The body to be transmitted is created in the system's native format.

+   The native character set is used, and where appropriate local end of

+   line conventions are used as well.  The body may be a UNIX-style text

+   file, or a Sun raster image, or a VMS indexed file, or audio data in

+   a system-dependent format stored only in memory, or anything else

+   that corresponds to the local model for the representation of some

+   form of information.  Fundamentally, the data is created in the

+   "native" form specified by the type/subtype information.

+

+   Step 2.  Conversion to canonical form.

+

+   The entire body, including "out-of-band" information such as record

+   lengths and possibly file attribute information, is converted to a

+   universal canonical form.  The specific content type of the body as

+   well as its associated attributes dictate the nature of the canonical

+   form that is used.  Conversion to the proper canonical form may

+   involve character set conversion, transformation of audio data,

+   compression, or various other operations specific to the various

+   content types.  If character set conversion is involved, however,

+   care must be taken to understand the semantics of the content-type,

+   which may have strong implications for any character set conversion,

+   e.g.  with regard to syntactically meaningful characters in a text

+   subtype other than "plain".

+

+   For example, in the case of text/plain data, the text must be

+   converted to a supported character set and lines must be delimited

+   with CRLF delimiters in accordance with RFC822.  Note that the

+   restriction on line lengths implied by RFC822 is eliminated if the

+   next step employs either quoted-printable or base64 encoding.

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 76]

+

+RFC 1521                          MIME                    September 1993

+

+

+   Step 3.  Apply transfer encoding.

+

+   A Content-Transfer-Encoding appropriate for this body is applied.

+   Note that there is no fixed relationship between the content type and

+   the transfer encoding.  In particular, it may be appropriate to base

+   the choice of base64 or quoted-printable on character frequency

+   counts which are specific to a given instance of a body.

+

+   Step 4.  Insertion into entity.

+

+   The encoded object is inserted into a MIME entity with appropriate

+   headers.  The entity is then inserted into the body of a higher-level

+   entity (message or multipart) if needed.

+

+   It is vital to note that these steps are only a model; they are

+   specifically NOT a blueprint for how an actual system would be built.

+   In particular, the model fails to account for two common designs:

+

+      1.  In many cases the conversion to a canonical form prior to

+      encoding will be subsumed into the encoder itself, which

+      understands local formats directly.  For example, the local

+      newline convention for text bodies might be carried through to the

+      encoder itself along with knowledge of what that format is.

+

+      2.  The output of the encoders may have to pass through one or

+      more additional steps prior to being transmitted as a message.  As

+      such, the output of the encoder may not be conformant with the

+      formats specified by RFC822.  In particular, once again it may be

+      appropriate for the converter's output to be expressed using local

+      newline conventions rather than using the standard RFC822 CRLF

+      delimiters.

+

+   Other implementation variations are conceivable as well.  The vital

+   aspect of this discussion is that, in spite of any optimizations,

+   collapsings of required steps, or insertion of additional processing,

+   the resulting messages must be consistent with those produced by the

+   model described here.  For example, a message with the following

+   header fields:

+

+        Content-type: text/foo; charset=bar

+        Content-Transfer-Encoding: base64

+

+   must be first represented in the text/foo form, then (if necessary)

+   represented in the "bar" character set, and finally transformed via

+   the base64 algorithm into a mail-safe form.

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 77]

+

+RFC 1521                          MIME                    September 1993

+

+

+Appendix H -- Changes from RFC 1341

+

+   This document is a relatively minor revision  of  RFC  1341.  For

+   the  convenience  of  those familiar with RFC 1341, the technical

+   changes from that document are summarized in  this appendix.

+

+   1.  The definition of "tspecials" has been changed to no longer

+   include ".".

+

+   2.  The Content-ID field is now mandatory for message/external-body

+   parts.

+

+   3.  The text/richtext type (including the old Section 7.1.3 and

+   Appendix D) has been moved to a separate document.

+

+   4.  The rules on header merging for message/partial data have been

+   changed to treat the Encrypted and MIME-Version headers as special

+   cases.

+

+   5.  The definition of the external-body access-type parameter has

+   been changed so that it can only indicate a single access method

+   (which was all that made sense).

+

+   6.  There is a new "Subject" parameter for message/external-body,

+   access-type mail-server, to permit MIME-based use of mail servers

+   that rely on Subject field information.

+

+   7.  The "conversions" parameter for application/octet-stream has been

+   removed.

+

+   8.  Section 7.4.1 now deprecates the use of the "name" parameter for

+   application/octet-stream, as this will be superseded in the future by

+   a Content-Disposition header.

+

+   9.  The formal grammar for multipart bodies has been changed so that

+   a CRLF is no longer required before the first boundary line.

+

+   10.  MIME entities of type "message/partial" and "message/external-

+   body" are now required to use only the "7bit" transfer-encoding.

+   (Specifically, "binary" and "8bit" are not permitted.)

+

+   11.  The "application/oda" content-type has been removed.

+

+   12.  A note has been added to the end of section 7.2.3, explaining

+   the semantics of Content-ID in a multipart/alternative MIME entity.

+

+   13.  The formal syntax for the "MIME-Version" field has been

+   tightened, but in a way that is completely compatible with the only

+

+

+

+Borenstein & Freed                                             [Page 78]

+

+RFC 1521                          MIME                    September 1993

+

+

+   version number defined in RFC 1341.

+

+   14.  In Section 7.3.1, the definition of message/rfc822 has been

+   relaxed regarding mandatory fields.

+

+   All other changes from RFC 1341 were editorial changes and do not

+   affect the technical content of MIME.  Considerable formal grammar

+   has been added, but this reflects the prose specification that was

+   already in place.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Borenstein & Freed                                             [Page 79]

+

+RFC 1521                          MIME                    September 1993

+

+

+References

+

+   [US-ASCII] Coded Character Set--7-Bit American Standard Code for

+   Information Interchange, ANSI X3.4-1986.

+

+   [ATK] Borenstein, Nathaniel S., Multimedia Applications Development

+   with the Andrew Toolkit, Prentice-Hall, 1990.

+

+   [GIF] Graphics Interchange Format (Version 89a), Compuserve, Inc.,

+   Columbus, Ohio, 1990.

+

+   [ISO-2022] International Standard--Information Processing--ISO 7-bit

+   and 8-bit coded character sets--Code extension techniques, ISO

+   2022:1986.

+

+   [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic

+   Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987.  Part

+   2: Latin alphabet No.  2, ISO 8859-2, 1987.  Part 3: Latin alphabet

+   No. 3, ISO 8859-3, 1988.  Part 4: Latin alphabet No.  4, ISO 8859-4,

+   1988.  Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.  Part 6:

+   Latin/Arabic alphabet, ISO 8859-6, 1987.  Part 7: Latin/Greek

+   alphabet, ISO 8859-7, 1987.  Part 8: Latin/Hebrew alphabet, ISO

+   8859-8, 1988.  Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.

+

+   [ISO-646] International Standard--Information Processing--ISO 7-bit

+   coded character set for information interchange, ISO 646:1983.

+

+   [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/TJC1/SC2/WG11

+   (Motion Picture Experts Group), May, 1991.

+

+   [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva, 1972,

+   "Pulse Code Modulation (PCM) of Voice Frequencies".

+

+   [POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference

+   Manual, Addison-Wesley, 1985.

+

+   [POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference

+   Manual, Addison-Wesley, Second Edition, 1990.

+

+   [X400] Schicker, Pietro, "Message Handling Systems, X.400", Message

+   Handling Systems and Distributed Applications, E.  Stefferud, O-j.

+   Jacobsen, and P.  Schicker, eds., North-Holland, 1989, pp. 3-41.

+

+   [RFC-783] Sollins, K., "TFTP Protocol (revision 2)", RFC 783, MIT,

+   June 1981.

+

+   [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC

+   821, USC/Information Sciences Institute, August 1982.

+

+

+

+Borenstein & Freed                                             [Page 80]

+

+RFC 1521                          MIME                    September 1993

+

+

+   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text

+   Messages", STD 11, RFC 822, UDEL, August 1982.

+

+   [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message

+   Encapsulation", RFC 934, Delaware and NMA, January 1985.

+

+   [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol",

+   STD 9, RFC 959, USC/Information Sciences Institute, October 1985.

+

+   [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet

+   Messages", STD 11, RFC 1049, CMU, March 1988.

+

+   [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail:

+   Part I - Message Encryption and Authentication Procedures", RFC

+   1421, IAB IRTF PSRG, IETF PEM WG, February 1993.

+

+   [RFC-1154] Robinson, D. and R. Ullmann, "Encoding Header Field for

+   Internet Messages", RFC 1154, Prime Computer, Inc., April 1990.

+

+   [RFC-1341] Borenstein, N., and N.  Freed, "MIME (Multipurpose Internet

+   Mail Extensions): Mechanisms for Specifying and Describing the Format

+   of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.

+

+   [RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet

+   Message Headers", RFC 1342, University of Tennessee, June 1992.

+

+   [RFC-1343] Borenstein, N., "A User Agent Configuration Mechanism

+   for Multimedia Mail Format Information", RFC 1343, Bellcore, June

+   1992.

+

+   [RFC-1344] Borenstein, N., "Implications of MIME for Internet

+   Mail Gateways", RFC 1344, Bellcore, June 1992.

+

+   [RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets",

+   RFC 1345, Rationel Almen Planlaegning, June 1992.

+

+   [RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,

+   Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME

+   transport", RFC 1426, United Nations Universit, Innosoft, Dover Beach

+   Consulting, Inc., Network Management Associates, Inc., The Branch

+   Office, February 1993.

+

+   [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet

+   Message Headers" RFC 1522, University of Tennessee, September 1993.

+

+   [RFC-1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC

+   1340, USC/Information Sciences Institute, July 1992.

+

+

+

+

+Borenstein & Freed                                             [Page 81]

+
\ No newline at end of file
diff --git a/RFC/rfc1725.txt b/RFC/rfc1725.txt
new file mode 100644
index 00000000..43fcc518
--- /dev/null
+++ b/RFC/rfc1725.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 1725                               Carnegie Mellon
+Obsoletes: 1460                                                  M. Rose
+Category: Standards Track                   Dover Beach Consulting, Inc.
+                                                           November 1994
+
+
+                    Post Office Protocol - Version 3
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Overview
+
+   This memo is a revision to RFC 1460, a Draft Standard.  It makes the
+   following changes from that document:
+
+      - removed text regarding "split-UA model", which didn't add
+        anything to the understanding of POP
+
+      - clarified syntax of commands, keywords, and arguments
+
+      - clarified behavior on broken connection
+
+      - explicitly permitted an inactivity autologout timer
+
+      - clarified the requirements of the "exclusive-access lock"
+
+      - removed implementation-specific wording regarding the parsing of
+        the maildrop
+
+      - allowed servers to close the connection after a failed
+        authentication command
+
+      - removed the LAST command
+
+      - fixed typo in example of TOP command
+
+      - clarified that the second argument to the TOP command is non-
+        negative
+
+      - added the optional UIDL command
+
+
+
+
+Myers & Rose                                                    [Page 1]
+
+RFC 1725                          POP3                     November 1994
+
+
+      - added warning regarding length of shared secrets with APOP
+
+      - added additional warnings to the security considerations section
+
+1. Introduction
+
+   On certain types of smaller nodes in the Internet it is often
+   impractical to maintain a message transport system (MTS).  For
+   example, a workstation may not have sufficient resources (cycles,
+   disk space) in order to permit a SMTP server [RFC821] and associated
+   local mail delivery system to be kept resident and continuously
+   running.  Similarly, it may be expensive (or impossible) to keep a
+   personal computer interconnected to an IP-style network for long
+   amounts of time (the node is lacking the resource known as
+   "connectivity").
+
+   Despite this, it is often very useful to be able to manage mail on
+   these smaller nodes, and they often support a user agent (UA) to aid
+   the tasks of mail handling.  To solve this problem, a node which can
+   support an MTS entity offers a maildrop service to these less endowed
+   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
+   permit a workstation to dynamically access a maildrop on a server
+   host in a useful fashion.  Usually, this means that the POP3 is used
+   to allow a workstation to retrieve mail that the server is holding
+   for it.
+
+   For the remainder of this memo, the term "client host" refers to a
+   host making use of the POP3 service, while the term "server host"
+   refers to a host which offers the POP3 service.
+
+2. A Short Digression
+
+   This memo does not specify how a client host enters mail into the
+   transport system, although a method consistent with the philosophy of
+   this memo is presented here:
+
+      When the user agent on a client host wishes to enter a message
+      into the transport system, it establishes an SMTP connection to
+      its relay host (this relay host could be, but need not be, the
+      POP3 server host for the client host).
+
+3. Basic Operation
+
+   Initially, the server host starts the POP3 service by listening on
+   TCP port 110.  When a client host wishes to make use of the service,
+   it establishes a TCP connection with the server host.  When the
+   connection is established, the POP3 server sends a greeting.  The
+   client and POP3 server then exchange commands and responses
+
+
+
+Myers & Rose                                                    [Page 2]
+
+RFC 1725                          POP3                     November 1994
+
+
+   (respectively) until the connection is closed or aborted.
+
+   Commands in the POP3 consist of a keyword, possibly followed by one
+   or more arguments.  All commands are terminated by a CRLF pair.
+   Keywords and arguments consist of printable ASCII characters.
+   Keywords and arguments are each separated by a single SPACE
+   character.  Keywords are three or four characters long. Each argument
+   may be up to 40 characters long.
+
+   Responses in the POP3 consist of a status indicator and a keyword
+   possibly followed by additional information.  All responses are
+   terminated by a CRLF pair.  There are currently two status
+   indicators: positive ("+OK") and negative ("-ERR").
+
+   Responses to certain commands are multi-line.  In these cases, which
+   are clearly indicated below, after sending the first line of the
+   response and a CRLF, any additional lines are sent, each terminated
+   by a CRLF pair.  When all lines of the response have been sent, a
+   final line is sent, consisting of a termination octet (decimal code
+   046, ".") and a CRLF pair.  If any line of the multi-line response
+   begins with the termination octet, the line is "byte-stuffed" by
+   pre-pending the termination octet to that line of the response.
+   Hence a multi-line response is terminated with the five octets
+   "CRLF.CRLF".  When examining a multi-line response, the client checks
+   to see if the line begins with the termination octet.  If so and if
+   octets other than CRLF follow, the the first octet of the line (the
+   termination octet) is stripped away.  If so and if CRLF immediately
+   follows the termination character, then the response from the POP
+   server is ended and the line containing ".CRLF" is not considered
+   part of the multi-line response.
+
+   A POP3 session progresses through a number of states during its
+   lifetime.  Once the TCP connection has been opened and the POP3
+   server has sent the greeting, the session enters the AUTHORIZATION
+   state.  In this state, the client must identify itself to the POP3
+   server.  Once the client has successfully done this, the server
+   acquires resources associated with the client's maildrop, and the
+   session enters the TRANSACTION state.  In this state, the client
+   requests actions on the part of the POP3 server.  When the client has
+   issued the QUIT command, the session enters the UPDATE state.  In
+   this state, the POP3 server releases any resources acquired during
+   the TRANSACTION state and says goodbye.  The TCP connection is then
+   closed.
+
+   A POP3 server MAY have an inactivity autologout timer.  Such a timer
+   MUST be of at least 10 minutes' duration.  The receipt of any command
+   from the client during that interval should suffice to reset the
+   autologout timer.  When the timer expires, the session does NOT enter
+
+
+
+Myers & Rose                                                    [Page 3]
+
+RFC 1725                          POP3                     November 1994
+
+
+   the UPDATE state--the server should close the TCP connection without
+   removing any messages or sending any response to the client.
+
+4. The AUTHORIZATION State
+
+   Once the TCP connection has been opened by a POP3 client, the POP3
+   server issues a one line greeting.  This can be any string terminated
+   by CRLF.  An example might be:
+
+      S:  +OK POP3 server ready
+
+   Note that this greeting is a POP3 reply.  The POP3 server should
+   always give a positive response as the greeting.
+
+   The POP3 session is now in the AUTHORIZATION state.  The client must
+   now identify and authenticate itself to the POP3 server.  Two
+   possible mechanisms for doing this are described in this document,
+   the USER and PASS command combination and the APOP command.  The APOP
+   command is described later in this document.
+
+   To authenticate using the USER and PASS command combination, the
+   client must first issue the USER command.  If the POP3 server
+   responds with a positive status indicator ("+OK"), then the client
+   may issue either the PASS command to complete the authentication, or
+   the QUIT command to terminate the POP3 session.  If the POP3 server
+   responds with a negative status indicator ("-ERR") to the USER
+   command, then the client may either issue a new authentication
+   command or may issue the QUIT command.
+
+   When the client issues the PASS command, the POP3 server uses the
+   argument pair from the USER and PASS commands to determine if the
+   client should be given access to the appropriate maildrop.
+
+   Once the POP3 server has determined through the use of any
+   authentication command that the client should be given access to the
+   appropriate maildrop, the POP3 server then acquires an exclusive-
+   access lock on the maildrop, as necessary to prevent messages from
+   being modified or removed before the session enters the UPDATE state.
+   If the lock is successfully acquired, the POP3 server responds with a
+   positive status indicator.  The POP3 session now enters the
+   TRANSACTION state, with no messages marked as deleted.  If the the
+   maildrop cannot be opened for some reason (for example, a lock can
+   not be acquired, the client is denied access to the appropriate
+   maildrop, or the maildrop cannot be parsed), the POP3 server responds
+   with a negative status indicator.  (If a lock was acquired but the
+   POP3 server intends to respond with a negative status indicator, the
+   POP3 server must release the lock prior to rejecting the command.)
+   After returning a negative status indicator, the server may close the
+
+
+
+Myers & Rose                                                    [Page 4]
+
+RFC 1725                          POP3                     November 1994
+
+
+   connection.  If the server does not close the connection, the client
+   may either issue a new authentication command and start again, or the
+   client may issue the QUIT command.
+
+   After the POP3 server has opened the maildrop, it assigns a message-
+   number to each message, and notes the size of each message in octets.
+   The first message in the maildrop is assigned a message-number of
+   "1", the second is assigned "2", and so on, so that the n'th message
+   in a maildrop is assigned a message-number of "n".  In POP3 commands
+   and responses, all message-number's and message sizes are expressed
+   in base-10 (i.e., decimal).
+
+   Here are summaries for the three POP3 commands discussed thus far:
+
+      USER name
+
+         Arguments:
+             a string identifying a mailbox (required), which is of
+             significance ONLY to the server
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state after the POP3
+             greeting or after an unsuccessful USER or PASS command
+
+         Possible Responses:
+             +OK name is a valid mailbox
+             -ERR never heard of mailbox name
+
+         Examples:
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+                ...
+             C: USER frated
+             S: -ERR sorry, no mailbox for frated here
+
+      PASS string
+
+         Arguments:
+             a server/mailbox-specific password (required)
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state after a
+             successful USER command
+
+         Discussion:
+             Since the PASS command has exactly one argument, a POP3
+             server may treat spaces in the argument as part of the
+             password, instead of as argument separators.
+
+
+
+Myers & Rose                                                    [Page 5]
+
+RFC 1725                          POP3                     November 1994
+
+
+         Possible Responses:
+             +OK maildrop locked and ready
+             -ERR invalid password
+             -ERR unable to lock maildrop
+
+         Examples:
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+             C: PASS secret
+             S: +OK mrose's maildrop has 2 messages (320 octets)
+               ...
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+             C: PASS secret
+             S: -ERR maildrop already locked
+
+      QUIT
+
+         Arguments: none
+
+         Restrictions: none
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: QUIT
+             S: +OK dewey POP3 server signing off
+
+5. The TRANSACTION State
+
+   Once the client has successfully identified itself to the POP3 server
+   and the POP3 server has locked and opened the appropriate maildrop,
+   the POP3 session is now in the TRANSACTION state.  The client may now
+   issue any of the following POP3 commands repeatedly.  After each
+   command, the POP3 server issues a response.  Eventually, the client
+   issues the QUIT command and the POP3 session enters the UPDATE state.
+
+   Here are the POP3 commands valid in the TRANSACTION state:
+
+      STAT
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+
+
+
+
+Myers & Rose                                                    [Page 6]
+
+RFC 1725                          POP3                     November 1994
+
+
+         Discussion:
+             The POP3 server issues a positive response with a line
+             containing information for the maildrop.  This line is
+             called a "drop listing" for that maildrop.
+
+             In order to simplify parsing, all POP3 servers required to
+             use a certain format for drop listings.  The positive
+             response consists of "+OK" followed by a single space, the
+             number of messages in the maildrop, a single space, and the
+             size of the maildrop in octets.  This memo makes no
+             requirement on what follows the maildrop size.  Minimal
+             implementations should just end that line of the response
+             with a CRLF pair.  More advanced implementations may
+             include other information.
+
+                NOTE: This memo STRONGLY discourages implementations
+                from supplying additional information in the drop
+                listing.  Other, optional, facilities are discussed
+                later on which permit the client to parse the messages
+                in the maildrop.
+
+             Note that messages marked as deleted are not counted in
+             either total.
+
+         Possible Responses:
+             +OK nn mm
+
+         Examples:
+             C: STAT
+             S: +OK 2 320
+
+      LIST [msg]
+
+         Arguments:
+             a message-number (optional), which, if present, may NOT
+             refer to a message marked as deleted
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If an argument was given and the POP3 server issues a
+             positive response with a line containing information for
+             that message.  This line is called a "scan listing" for
+             that message.
+
+             If no argument was given and the POP3 server issues a
+             positive response, then the response given is multi-line.
+
+
+
+Myers & Rose                                                    [Page 7]
+
+RFC 1725                          POP3                     November 1994
+
+
+             After the initial +OK, for each message in the maildrop,
+             the POP3 server responds with a line containing information
+             for that message.  This line is also called a "scan
+             listing" for that message.
+
+             In order to simplify parsing, all POP3 servers are required
+             to use a certain format for scan listings.  A scan listing
+             consists of the message-number of the message, followed by
+             a single space and the exact size of the message in octets.
+             This memo makes no requirement on what follows the message
+             size in the scan listing.  Minimal implementations should
+             just end that line of the response with a CRLF pair.  More
+             advanced implementations may include other information, as
+             parsed from the message.
+
+                NOTE: This memo STRONGLY discourages implementations
+                from supplying additional information in the scan
+                listing.  Other, optional, facilities are discussed
+                later on which permit the client to parse the messages
+                in the maildrop.
+
+             Note that messages marked as deleted are not listed.
+
+         Possible Responses:
+             +OK scan listing follows
+             -ERR no such message
+
+         Examples:
+             C: LIST
+             S: +OK 2 messages (320 octets)
+             S: 1 120
+             S: 2 200
+             S: .
+               ...
+             C: LIST 2
+             S: +OK 2 200
+               ...
+             C: LIST 3
+             S: -ERR no such message, only 2 messages in maildrop
+
+      RETR msg
+
+         Arguments:
+             a message-number (required) which may not refer to a
+             message marked as deleted
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+
+
+Myers & Rose                                                    [Page 8]
+
+RFC 1725                          POP3                     November 1994
+
+
+         Discussion:
+             If the POP3 server issues a positive response, then the
+             response given is multi-line.  After the initial +OK, the
+             POP3 server sends the message corresponding to the given
+             message-number, being careful to byte-stuff the termination
+             character (as with all multi-line responses).
+
+         Possible Responses:
+             +OK message follows
+             -ERR no such message
+
+         Examples:
+             C: RETR 1
+             S: +OK 120 octets
+             S: <the POP3 server sends the entire message here>
+             S: .
+
+      DELE msg
+
+         Arguments:
+             a message-number (required) which may not refer to a
+             message marked as deleted
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             The POP3 server marks the message as deleted.  Any future
+             reference to the message-number associated with the message
+             in a POP3 command generates an error.  The POP3 server does
+             not actually delete the message until the POP3 session
+             enters the UPDATE state.
+
+         Possible Responses:
+             +OK message deleted
+             -ERR no such message
+
+         Examples:
+             C: DELE 1
+             S: +OK message 1 deleted
+                ...
+             C: DELE 2
+             S: -ERR message 2 already deleted
+
+      NOOP
+
+         Arguments: none
+
+
+
+
+Myers & Rose                                                    [Page 9]
+
+RFC 1725                          POP3                     November 1994
+
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             The POP3 server does nothing, it merely replies with a
+             positive response.
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: NOOP
+             S: +OK
+
+      RSET
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If any messages have been marked as deleted by the POP3
+             server, they are unmarked.  The POP3 server then replies
+             with a positive response.
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: RSET
+             S: +OK maildrop has 2 messages (320 octets)
+
+6. The UPDATE State
+
+   When the client issues the QUIT command from the TRANSACTION state,
+   the POP3 session enters the UPDATE state.  (Note that if the client
+   issues the QUIT command from the AUTHORIZATION state, the POP3
+   session terminates but does NOT enter the UPDATE state.)
+
+   If a session terminates for some reason other than a client-issued
+   QUIT command, the POP3 session does NOT enter the UPDATE state and
+   MUST not remove any messages from the maildrop.
+
+      QUIT
+
+         Arguments: none
+
+
+
+
+Myers & Rose                                                   [Page 10]
+
+RFC 1725                          POP3                     November 1994
+
+
+         Restrictions: none
+
+         Discussion:
+             The POP3 server removes all messages marked as deleted from
+             the maildrop.  It then releases any exclusive-access lock
+             on the maildrop and replies as to the status of these
+             operations.  The TCP connection is then closed.
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: QUIT
+             S: +OK dewey POP3 server signing off (maildrop empty)
+                ...
+             C: QUIT
+             S: +OK dewey POP3 server signing off (2 messages left)
+                ...
+
+7. Optional POP3 Commands
+
+   The POP3 commands discussed above must be supported by all minimal
+   implementations of POP3 servers.
+
+   The optional POP3 commands described below permit a POP3 client
+   greater freedom in message handling, while preserving a simple POP3
+   server implementation.
+
+      NOTE: This memo STRONGLY encourages implementations to support
+      these commands in lieu of developing augmented drop and scan
+      listings.  In short, the philosophy of this memo is to put
+      intelligence in the part of the POP3 client and not the POP3
+      server.
+
+      TOP msg n
+
+         Arguments:
+             a message-number (required) which may NOT refer to to a
+             message marked as deleted, and a non-negative number
+             (required)
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If the POP3 server issues a positive response, then the
+             response given is multi-line.  After the initial +OK, the
+             POP3 server sends the headers of the message, the blank
+
+
+
+Myers & Rose                                                   [Page 11]
+
+RFC 1725                          POP3                     November 1994
+
+
+             line separating the headers from the body, and then the
+             number of lines indicated message's body, being careful to
+             byte-stuff the termination character (as with all multi-
+             line responses).
+
+             Note that if the number of lines requested by the POP3
+             client is greater than than the number of lines in the
+             body, then the POP3 server sends the entire message.
+
+         Possible Responses:
+             +OK top of message follows
+             -ERR no such message
+
+         Examples:
+             C: TOP 1 10
+             S: +OK
+             S: <the POP3 server sends the headers of the
+                message, a blank line, and the first 10 lines
+                of the body of the message>
+             S: .
+                ...
+             C: TOP 100 3
+             S: -ERR no such message
+
+      UIDL [msg]
+
+      Arguments:
+          a message-number (optionally)  If a message-number is given,
+          it may NOT refer to a message marked as deleted.
+
+      Restrictions:
+          may only be given in the TRANSACTION state.
+
+      Discussion:
+          If an argument was given and the POP3 server issues a positive
+          response with a line containing information for that message.
+          This line is called a "unique-id listing" for that message.
+
+          If no argument was given and the POP3 server issues a positive
+          response, then the response given is multi-line.  After the
+          initial +OK, for each message in the maildrop, the POP3 server
+          responds with a line containing information for that message.
+          This line is called a "unique-id listing" for that message.
+
+          In order to simplify parsing, all POP3 servers are required to
+          use a certain format for unique-id listings.  A unique-id
+          listing consists of the message-number of the message,
+          followed by a single space and the unique-id of the message.
+
+
+
+Myers & Rose                                                   [Page 12]
+
+RFC 1725                          POP3                     November 1994
+
+
+          No information follows the unique-id in the unique-id listing.
+
+          The unique-id of a message is an arbitrary server-determined
+          string, consisting of characters in the range 0x21 to 0x7E,
+          which uniquely identifies a message within a maildrop and
+          which persists across sessions. The server should never reuse
+          an unique-id in a given maildrop, for as long as the entity
+          using the unique-id exists.
+
+          Note that messages marked as deleted are not listed.
+
+      Possible Responses:
+          +OK unique-id listing follows
+          -ERR no such message
+
+      Examples:
+          C: UIDL
+          S: +OK
+          S: 1 whqtswO00WBw418f9t5JxYwZ
+          S: 2 QhdPYR:00WBw1Ph7x7
+          S: .
+             ...
+          C: UIDL 2
+          S: +OK 2 QhdPYR:00WBw1Ph7x7
+             ...
+          C: UIDL 3
+          S: -ERR no such message, only 2 messages in maildrop
+
+      APOP name digest
+
+         Arguments:
+             a string identifying a mailbox and a MD5 digest string
+             (both required)
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state after the POP3
+             greeting
+
+         Discussion:
+             Normally, each POP3 session starts with a USER/PASS
+             exchange.  This results in a server/user-id specific
+             password being sent in the clear on the network.  For
+             intermittent use of POP3, this may not introduce a sizable
+             risk.  However, many POP3 client implementations connect to
+             the POP3 server on a regular basis -- to check for new
+             mail.  Further the interval of session initiation may be on
+             the order of five minutes.  Hence, the risk of password
+             capture is greatly enhanced.
+
+
+
+Myers & Rose                                                   [Page 13]
+
+RFC 1725                          POP3                     November 1994
+
+
+             An alternate method of authentication is required which
+             provides for both origin authentication and replay
+             protection, but which does not involve sending a password
+             in the clear over the network.  The APOP command provides
+             this functionality.
+
+             A POP3 server which implements the APOP command will
+             include a timestamp in its banner greeting.  The syntax of
+             the timestamp corresponds to the `msg-id' in [RFC822], and
+             MUST be different each time the POP3 server issues a banner
+             greeting.  For example, on a UNIX implementation in which a
+             separate UNIX process is used for each instance of a POP3
+             server, the syntax of the timestamp might be:
+
+                <process-ID.clock@hostname>
+
+             where `process-ID' is the decimal value of the process's
+             PID, clock is the decimal value of the system clock, and
+             hostname is the fully-qualified domain-name corresponding
+             to the host where the POP3 server is running.
+
+             The POP3 client makes note of this timestamp, and then
+             issues the APOP command.  The `name' parameter has
+             identical semantics to the `name' parameter of the USER
+             command. The `digest' parameter is calculated by applying
+             the MD5 algorithm [RFC1321] to a string consisting of the
+             timestamp (including angle-brackets) followed by a shared
+             secret.  This shared secret is a string known only to the
+             POP3 client and server.  Great care should be taken to
+             prevent unauthorized disclosure of the secret, as knowledge
+             of the secret will allow any entity to successfully
+             masquerade as the named user.  The `digest' parameter
+             itself is a 16-octet value which is sent in hexadecimal
+             format, using lower-case ASCII characters.
+
+             When the POP3 server receives the APOP command, it verifies
+             the digest provided.  If the digest is correct, the POP3
+             server issues a positive response, and the POP3 session
+             enters the TRANSACTION state.  Otherwise, a negative
+             response is issued and the POP3 session remains in the
+             AUTHORIZATION state.
+
+             Note that as the length of the shared secret increases, so
+             does the difficulty of deriving it.  As such, shared
+             secrets should be long strings (considerably longer than
+             the 8-character example shown below).
+
+
+
+
+
+Myers & Rose                                                   [Page 14]
+
+RFC 1725                          POP3                     November 1994
+
+
+         Possible Responses:
+             +OK maildrop locked and ready
+             -ERR permission denied
+
+         Examples:
+             S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+             S: +OK maildrop has 1 message (369 octets)
+
+             In this example, the shared  secret  is  the  string  `tan-
+             staaf'.  Hence, the MD5 algorithm is applied to the string
+
+                <1896.697170952@dbc.mtview.ca.us>tanstaaf
+
+             which produces a digest value of
+
+                c4c9334bac560ecc979e58001b3e22fb
+
+8. POP3 Command Summary
+
+   Minimal POP3 Commands:
+
+      USER name               valid in the AUTHORIZATION state
+      PASS string
+      QUIT
+
+      STAT                    valid in the TRANSACTION state
+      LIST [msg]
+      RETR msg
+      DELE msg
+      NOOP
+      RSET
+
+      QUIT                    valid in the UPDATE state
+
+   Optional POP3 Commands:
+
+      APOP name digest        valid in the AUTHORIZATION state
+
+      TOP msg n               valid in the TRANSACTION state
+      UIDL [msg]
+
+   POP3 Replies:
+
+      +OK
+      -ERR
+
+
+
+
+
+Myers & Rose                                                   [Page 15]
+
+RFC 1725                          POP3                     November 1994
+
+
+   Note that with the exception of the STAT, LIST, and UIDL commands,
+   the reply given by the POP3 server to any command is significant only
+   to "+OK" and "-ERR".  Any text occurring after this reply may be
+   ignored by the client.
+
+9. Example POP3 Session
+
+   S: <wait for connection on TCP port 110>
+   C: <open connection>
+   S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+   C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
+   S:    +OK mrose's maildrop has 2 messages (320 octets)
+   C:    STAT
+   S:    +OK 2 320
+   C:    LIST
+   S:    +OK 2 messages (320 octets)
+   S:    1 120
+   S:    2 200
+   S:    .
+   C:    RETR 1
+   S:    +OK 120 octets
+   S:    <the POP3 server sends message 1>
+   S:    .
+   C:    DELE 1
+   S:    +OK message 1 deleted
+   C:    RETR 2
+   S:    +OK 200 octets
+   S:    <the POP3 server sends message 2>
+   S:    .
+   C:    DELE 2
+   S:    +OK message 2 deleted
+   C:    QUIT
+   S:    +OK dewey POP3 server signing off (maildrop empty)
+   C:  <close connection>
+   S:  <wait for next connection>
+
+10. Message Format
+
+   All messages transmitted during a POP3 session are assumed to conform
+   to the standard for the format of Internet text messages [RFC822].
+
+   It is important to note that the octet count for a message on the
+   server host may differ from the octet count assigned to that message
+   due to local conventions for designating end-of-line.  Usually,
+   during the AUTHORIZATION state of the POP3 session, the POP3 server
+   can calculate the size of each message in octets when it opens the
+   maildrop.  For example, if the POP3 server host internally represents
+   end-of-line as a single character, then the POP3 server simply counts
+
+
+
+Myers & Rose                                                   [Page 16]
+
+RFC 1725                          POP3                     November 1994
+
+
+   each occurrence of this character in a message as two octets.  Note
+   that lines in the message which start with the termination octet need
+   not be counted twice, since the POP3 client will remove all byte-
+   stuffed termination characters when it receives a multi-line
+   response.
+
+11. References
+
+   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+       821, USC/Information Sciences Institute, August 1982.
+
+   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
+       Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+   [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321,
+       MIT Laboratory for Computer Science, April, 1992.
+
+12. Security Considerations
+
+   It is conjectured that use of the APOP command provides origin
+   identification and replay protection for a POP3 session.
+   Accordingly, a POP3 server which implements both the PASS and APOP
+   commands must not allow both methods of access for a given user; that
+   is, for a given "USER name" either the PASS or APOP command is
+   allowed, but not both.
+
+   Further, note that as the length of the shared secret increases, so
+   does the difficulty of deriving it.
+
+   Servers that answer -ERR to the USER command are giving potential
+   attackers clues about which names are valid
+
+   Use of the PASS command sends passwords in the clear over the
+   network.
+
+   Use of the RETR and TOP commands sends mail in the clear over the
+   network.
+
+   Otherwise, security issues are not discussed in this memo.
+
+13. Acknowledgements
+
+   The POP family has a long and checkered history.  Although primarily
+   a minor revision to RFC 1460, POP3 is based on the ideas presented in
+   RFCs 918, 937, and 1081.
+
+   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
+   provided significant comments on the APOP command.
+
+
+
+Myers & Rose                                                   [Page 17]
+
+RFC 1725                          POP3                     November 1994
+
+
+14. Authors' Addresses
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave
+   Pittsburgh, PA 15213
+
+   EMail: jgm+@cmu.edu
+
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   420 Whisman Court
+   Mountain View, CA  94043-2186
+
+   EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                                                   [Page 18]
+
diff --git a/RFC/rfc1730.txt b/RFC/rfc1730.txt
new file mode 100644
index 00000000..fcf72ad7
--- /dev/null
+++ b/RFC/rfc1730.txt
@@ -0,0 +1,4318 @@
+

+

+

+

+

+

+Network Working Group                                         M. Crispin

+Request for Comments: 1730                      University of Washington

+Category: Standards Track                                  December 1994

+

+

+              INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4

+

+

+

+Status of this Memo

+

+   This document specifies an Internet standards track protocol for the

+   Internet community, and requests discussion and suggestions for

+   improvements.  Please refer to the current edition of the "Internet

+   Official Protocol Standards" (STD 1) for the standardization state

+   and status of this protocol.  Distribution of this memo is unlimited.

+

+

+Abstract

+

+   The Internet Message Access Protocol, Version 4 (IMAP4) allows a

+   client to access and manipulate electronic mail messages on a server.

+   IMAP4 permits manipulation of remote message folders, called

+   "mailboxes", in a way that is functionally equivalent to local

+   mailboxes.  IMAP4 also provides the capability for an offline client

+   to resynchronize with the server (see also [IMAP-DISC]).

+

+   IMAP4 includes operations for creating, deleting, and renaming

+   mailboxes; checking for new messages; permanently removing messages;

+   setting and clearing flags; RFC 822 and MIME parsing; searching; and

+   selective fetching of message attributes, texts, and portions

+   thereof.  Messages in IMAP4 are accessed by the use of numbers.

+   These numbers are either message sequence numbers (relative position

+   from 1 to the number of messages in the mailbox) or unique

+   identifiers (immutable, strictly ascending values assigned to each

+   message, but which are not necessarily contiguous).

+

+   IMAP4 supports a single server.  A mechanism for supporting multiple

+   IMAP4 servers is discussed in [IMSP].

+

+   IMAP4 does not specify a means of posting mail; this function is

+   handled by a mail transfer protocol such as [SMTP].

+

+   IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.

+   Compatibility issues are discussed in [IMAP-COMPAT].

+

+

+

+

+

+

+Crispin                                                         [Page i]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+

+

+

+Table of Contents

+

+

+

+IMAP4 Protocol Specification ......................................    1

+1.      Organization of this Document .............................    1

+1.1.    How to Read This Document .................................    1

+1.2.    Conventions Used in this Document .........................    1

+2.      Protocol Overview .........................................    1

+2.1.    Link Level ................................................    1

+2.2.    Commands and Responses ....................................    1

+2.2.1.  Client Protocol Sender and Server Protocol Receiver .......    2

+2.2.2.  Server Protocol Sender and Client Protocol Receiver .......    2

+3.      State and Flow Diagram ....................................    4

+3.1.    Non-Authenticated State ...................................    4

+3.2.    Authenticated State .......................................    4

+3.3.    Selected State ............................................    4

+3.4.    Logout State ..............................................    4

+4.      Data Formats ..............................................    6

+4.1.    Atom ......................................................    6

+4.2.    Number ....................................................    6

+4.3.    String ....................................................    6

+4.3.1.  8-bit and Binary Strings ..................................    7

+4.4.    Parenthesized List ........................................    7

+4.5.    NIL .......................................................    7

+5.      Operational Considerations ................................    8

+5.1.    Mailbox Naming ............................................    8

+5.2.    Mailbox Size and Message Status Updates ...................    8

+5.3.    Response when no Command in Progress ......................    8

+5.4.    Autologout Timer ..........................................    9

+5.5.    Multiple Commands in Progress .............................    9

+6.      Client Commands ...........................................   10

+6.1.    Client Commands - Any State ...............................   10

+6.1.1.  CAPABILITY Command ........................................   10

+6.1.2.  NOOP Command ..............................................   11

+6.1.3.  LOGOUT Command ............................................   11

+6.2.    Client Commands - Non-Authenticated State .................   12

+6.2.1.  AUTHENTICATE Command ......................................   12

+6.2.2.  LOGIN Command .............................................   14

+6.3.    Client Commands - Authenticated State .....................   14

+6.3.1.  SELECT Command ............................................   15

+6.3.2.  EXAMINE Command ...........................................   16

+6.3.3.  CREATE Command ............................................   17

+6.3.4.  DELETE Command ............................................   18

+6.3.5.  RENAME Command ............................................   18

+

+

+

+Crispin                                                        [Page ii]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+6.3.6.  SUBSCRIBE Command .........................................   19

+6.3.7.  UNSUBSCRIBE Command .......................................   19

+6.3.8.  LIST Command ..............................................   20

+6.3.9.  LSUB Command ..............................................   22

+6.3.10. APPEND Command ............................................   22

+6.4.    Client Commands - Selected State ..........................   23

+6.4.1.  CHECK Command .............................................   23

+6.4.2.  CLOSE Command .............................................   24

+6.4.3.  EXPUNGE Command ...........................................   25

+6.4.4.  SEARCH Command ............................................   25

+6.4.5.  FETCH Command .............................................   29

+6.4.6.  PARTIAL Command ...........................................   32

+6.4.7.  STORE Command .............................................   33

+6.4.8.  COPY Command ..............................................   34

+6.4.9.  UID Command ...............................................   35

+6.5.    Client Commands - Experimental/Expansion ..................   37

+6.5.1.  X<atom> Command ...........................................   37

+7.      Server Responses ..........................................   38

+7.1.    Server Responses - Status Responses .......................   39

+7.1.1.  OK Response ...............................................   40

+7.1.2.  NO Response ...............................................   40

+7.1.3.  BAD Response ..............................................   41

+7.1.4.  PREAUTH Response ..........................................   41

+7.1.5.  BYE Response ..............................................   41

+7.2.    Server Responses - Server and Mailbox Status ..............   42

+7.2.1.  CAPABILITY Response .......................................   42

+7.2.2.  LIST Response .............................................   43

+7.2.3.  LSUB Response .............................................   44

+7.2.4.  SEARCH Response ...........................................   44

+7.2.5.  FLAGS Response ............................................   44

+7.3.    Server Responses - Message Status .........................   45

+7.3.1.  EXISTS Response ...........................................   45

+7.3.2.  RECENT Response ...........................................   45

+7.3.3.  EXPUNGE Response ..........................................   45

+7.3.4.  FETCH Response ............................................   46

+7.3.5.  Obsolete Responses ........................................   51

+7.4.    Server Responses - Command Continuation Request ...........   51

+8.      Sample IMAP4 session ......................................   52

+9.      Formal Syntax .............................................   53

+10.     Author's Note .............................................   64

+11.     Security Considerations ...................................   64

+12.     Author's Address ..........................................   64

+Appendices ........................................................   65

+A.      Obsolete Commands .........................................   65

+A.6.3.OBS.1.    FIND ALL.MAILBOXES Command ........................   65

+A.6.3.OBS.2.    FIND MAILBOXES Command ............................   65

+A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command .........................   66

+A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command .......................   66

+

+

+

+Crispin                                                       [Page iii]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+B.      Obsolete Responses ........................................   68

+B.7.2.OBS.1.    MAILBOX Response ..................................   68

+B.7.3.OBS.1.    COPY Response .....................................   68

+B.7.3.OBS.2.    STORE Response ....................................   69

+C.      References ................................................   70

+E.      IMAP4 Keyword Index .......................................   71

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page iv]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+IMAP4 Protocol Specification

+

+1.      Organization of this Document

+

+1.1.    How to Read This Document

+

+   This document is written from the point of view of the implementor of

+   an IMAP4 client or server.  Beyond the protocol overview in section

+   2, it is not optimized for someone trying to understand the operation

+   of the protocol.  The material in sections 3 through 5 provides the

+   general context and definitions with which IMAP4 operates.

+

+   Sections 6, 7, and 9 describe the IMAP commands, responses, and

+   syntax, respectively.  The relationships among these are such that it

+   is almost impossible to understand any of them separately.  In

+   particular, one should not attempt to deduce command syntax from the

+   command section alone; one should instead refer to the formal syntax

+   section.

+

+

+1.2.    Conventions Used in this Document

+

+   In examples, "C:" and "S:" indicate lines sent by the client and

+   server respectively.

+

+

+2.      Protocol Overview

+

+2.1.    Link Level

+

+   The IMAP4 protocol assumes a reliable data stream such as provided by

+   TCP.  When TCP is used, an IMAP4 server listens on port 143.

+

+

+2.2.    Commands and Responses

+

+   An IMAP4 session consists of the establishment of a client/server

+   connection, an initial greeting from the server, and client/server

+   interactions.  These client/server interactions consist of a client

+   command, server data, and a server completion result response.

+

+   All interactions transmitted by client and server are in the form of

+   lines; that is, strings that end with a CRLF.  The protocol receiver

+   of an IMAP4 client or server is either reading a line, or is reading

+   a sequence of octets with a known count followed by a line.

+

+

+

+

+

+

+Crispin                                                         [Page 1]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+2.2.1.  Client Protocol Sender and Server Protocol Receiver

+

+   The client command begins an operation.  Each client command is

+   prefixed with a identifier (typically a short alphanumeric string,

+   e.g. A0001, A0002, etc.) called a "tag".  A different tag is

+   generated by the client for each command.

+

+   There are two cases in which a line from the client does not

+   represent a complete command.  In one case, a command argument is

+   quoted with an octet count (see the description of literal in String

+   under Data Formats); in the other case, the command arguments require

+   server feedback (see the AUTHENTICATE command).  In either case, the

+   server sends a command continuation request response if it is ready

+   for the octets (if appropriate) and the remainder of the command.

+   This response is prefixed with the token "+".

+

+        Note: If, instead, the server detected an error in the

+        command, it sends a BAD completion response with tag

+        matching the command (as described below) to reject the

+        command and prevent the client from sending any more of the

+        command.

+

+        It is also possible for the server to send a completion

+        response for some other command (if multiple commands are

+        in progress), or untagged data.  In either case, the

+        command continuation request is still pending; the client

+        takes the appropriate action for the response, and reads

+        another response from the server.

+

+   The protocol receiver of an IMAP4 server reads a command line from

+   the client, parses the command and its arguments, and transmits

+   server data and a server command completion result response.

+

+

+2.2.2.  Server Protocol Sender and Client Protocol Receiver

+

+   Data transmitted by the server to the client and status responses

+   that do not indicate command completion are prefixed with the token

+   "*", and are called untagged responses.

+

+   Server data may be sent as a result of a client command, or may be

+   sent unilaterally by the server.  There is no syntactic difference

+   between server data that resulted from a specific command and server

+   data that were sent unilaterally.

+

+   The server completion result response indicates the success or

+   failure of the operation.  It is tagged with the same tag as the

+   client command which began the operation.  Thus, if more than one

+

+

+

+Crispin                                                         [Page 2]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   command is in progress, the tag in a server completion response

+   identifies the command to which the response applies.  There are

+   three possible server completion responses: OK (indicating success),

+   NO (indicating failure), or BAD (indicating protocol error such as

+   unrecognized command or command syntax error).

+

+   The protocol receiver of an IMAP4 client reads a response line from

+   the server.  It then takes action on the response based upon the

+   first token of the response, which may be a tag, a "*", or a "+".  As

+   described above.

+

+   A client MUST be prepared to accept any server response at all times.

+   This includes server data that it may not have requested.  Server

+   data SHOULD be recorded, so that the client can reference its

+   recorded copy rather than sending a command to the server to request

+   the data.  In the case of certain server data, recording the data is

+   mandatory.

+

+   This topic is discussed in greater detail in the Server Responses

+   section.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                         [Page 3]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+3.      State and Flow Diagram

+

+   An IMAP4 server is in one of four states.  Most commands are valid in

+   only certain states.  It is a protocol error for the client to

+   attempt a command while the command is in an inappropriate state.  In

+   this case, a server will respond with a BAD or NO (depending upon

+   server implementation) command completion result.

+

+

+3.1.    Non-Authenticated State

+

+   In non-authenticated state, the user must supply authentication

+   credentials before most commands will be permitted.  This state is

+   entered when a connection starts unless the connection has been

+   pre-authenticated.

+

+

+3.2.    Authenticated State

+

+   In authenticated state, the user is authenticated and must select a

+   mailbox to access before commands that affect messages will be

+   permitted.  This state is entered when a pre-authenticated connection

+   starts, when acceptable authentication credentials have been

+   provided, or after an error in selecting a mailbox.

+

+

+3.3.    Selected State

+

+   In selected state, a mailbox has been selected to access.  This state

+   is entered when a mailbox has been successfully selected.

+

+

+3.4.    Logout State

+

+   In logout state, the session is being terminated, and the server will

+   close the connection.  This state can be entered as a result of a

+   client request or by unilateral server decision.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                         [Page 4]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+            +--------------------------------------+

+            |initial connection and server greeting|

+            +--------------------------------------+

+                      || (1)       || (2)        || (3)

+                      VV           ||            ||

+            +-----------------+    ||            ||

+            |non-authenticated|    ||            ||

+            +-----------------+    ||            ||

+             || (7)   || (4)       ||            ||

+             ||       VV           VV            ||

+             ||     +----------------+           ||

+             ||     | authenticated  |<=++       ||

+             ||     +----------------+  ||       ||

+             ||       || (7)   || (5)   || (6)   ||

+             ||       ||       VV       ||       ||

+             ||       ||    +--------+  ||       ||

+             ||       ||    |selected|==++       ||

+             ||       ||    +--------+           ||

+             ||       ||       || (7)            ||

+             VV       VV       VV                VV

+            +--------------------------------------+

+            |     logout and close connection      |

+            +--------------------------------------+

+

+         (1) connection without pre-authentication (OK greeting)

+         (2) pre-authenticated connection (PREAUTH greeting)

+         (3) rejected connection (BYE greeting)

+         (4) successful LOGIN or AUTHENTICATE command

+         (5) successful SELECT or EXAMINE command

+         (6) CLOSE command, or failed SELECT or EXAMINE command

+         (7) LOGOUT command, server shutdown, or connection closed

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                         [Page 5]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+4.      Data Formats

+

+   IMAP4 uses textual commands and responses.  Data in IMAP4 can be in

+   one of several forms: atom, number, string, parenthesized list, or

+   NIL.

+

+

+4.1.    Atom

+

+   An atom consists of one or more non-special characters.

+

+

+4.2.    Number

+

+   A number consists of one or more digit characters, and represents a

+   numeric value.

+

+

+4.3.    String

+

+   A string is in one of two forms: literal and quoted string.  The

+   literal form is the general form of string.  The quoted string form

+   is an alternative that avoids the overhead of processing a literal at

+   the cost of restrictions of what may be in a quoted string.

+

+   A literal is a sequence of zero or more octets (including CR and LF),

+   prefix-quoted with an octet count in the form of an open brace ("{"),

+   the number of octets, close brace ("}"), and CRLF.  In the case of

+   literals transmitted from server to client, the CRLF is immediately

+   followed by the octet data.  In the case of literals transmitted from

+   client to server, the client must wait to receive a command

+   continuation request (described later in this document) before

+   sending the octet data (and the remainder of the command).

+

+   A quoted string is a sequence of zero or more 7-bit characters,

+   excluding CR and LF, with double quote (<">) characters at each end.

+

+   The empty string is respresented as either "" (a quoted string with

+   zero characters between double quotes) or as {0} followed by CRLF (a

+   literal with an octet count of 0).

+

+        Note: Even if the octet count is 0, a client transmitting a

+        literal must wait to receive a command continuation

+        request.

+

+

+

+

+

+

+

+Crispin                                                         [Page 6]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+4.3.1.  8-bit and Binary Strings

+

+   8-bit textual and binary mail is supported through the use of

+   [MIME-1] encoding.  IMAP4 implementations MAY transmit 8-bit or

+   multi-octet characters in literals, but should do so only when the

+   character set is identified.

+

+   Although a BINARY body encoding is defined, unencoded binary strings

+   are not permitted.  A "binary string" is any string with NUL

+   characters.  Implementations MUST encode binary data into a textual

+   form such as BASE64 before transmitting the data.  A string with an

+   excessive amount of CTL characters may also be considered to be

+   binary, although this is not required.

+

+

+4.4.    Parenthesized List

+

+   Data structures are represented as a "parenthesized list"; a sequence

+   of data items, delimited by space, and bounded at each end by

+   parentheses.  A parenthesized list may itself contain other

+   parenthesized lists, using multiple levels of parentheses to indicate

+   nesting.

+

+   The empty list is represented as () -- a parenthesized list with no

+   members.

+

+

+4.5.    NIL

+

+   The special atom "NIL" represents the non-existence of a particular

+   data item that is represented as a string or parenthesized list, as

+   distinct from the empty string "" or the empty parenthesized list ().

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                         [Page 7]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+5.      Operational Considerations

+

+5.1.    Mailbox Naming

+

+   The interpretation of mailbox names is implementation-dependent.

+   However, the mailbox name INBOX is a special name reserved to mean

+   "the primary mailbox for this user on this server".  If it is desired

+   to export hierarchical mailbox names, mailbox names must be

+   left-to-right hierarchical using a single character to separate

+   levels of hierarchy.  The same hierarchy separator character is used

+   for all levels of hierarchy within a single name.

+

+5.2.    Mailbox Size and Message Status Updates

+

+   At any time, a server can send data that the client did not request.

+   Sometimes, such behavior is required.  For example, agents other than

+   the server may add messages to the mailbox (e.g. new mail delivery),

+   change the flags of message in the mailbox (e.g. simultaneous access

+   to the same mailbox by multiple agents), or even remove messages from

+   the mailbox.  A server MUST send mailbox size updates automatically

+   if a mailbox size change is observed during the processing of a

+   command.  A server SHOULD send message flag updates automatically,

+   without requiring the client to request such updates explicitly.

+   Special rules exist for server notification of a client about the

+   removal of messages to prevent synchronization errors; see the

+   description of the EXPUNGE response for more details.

+

+   Regardless of what implementation decisions a client may take on

+   remembering data from the server, a client implementation MUST record

+   mailbox size updates.  It MUST NOT assume that any command after

+   initial mailbox selection will return the size of the mailbox.

+

+

+5.3.    Response when no Command in Progress

+

+   Server implementations are permitted to send an untagged response

+   (except for EXPUNGE) while there is no command in progress.  Server

+   implementations that send such responses MUST deal with flow control

+   considerations.  Specifically, they must either (1) verify that the

+   size of the data does not exceed the underlying transport's available

+   window size, or (2) use non-blocking writes.

+

+

+

+

+

+

+

+

+

+

+Crispin                                                         [Page 8]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+5.4.    Autologout Timer

+

+   If a server has an inactivity autologout timer, that timer MUST be of

+   at least 30 minutes' duration.  The receipt of ANY command from the

+   client during that interval should suffice to reset the autologout

+   timer.

+

+

+5.5.    Multiple Commands in Progress

+

+   The client is not required to wait for the completion result response

+   of a command before sending another command, subject to flow control

+   constraints on the underlying data stream.  Similarly, a server is

+   not required to process a command to completion before beginning

+   processing of the next command, unless an ambiguity would result

+   because of a command that would affect the results of other commands.

+   If there is such an ambiguity, the server executes commands to

+   completion in the order given by the client.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                         [Page 9]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+6.      Client Commands

+

+   IMAP4 commands are described in this section.  Commands are organized

+   by the state in which the command is permitted.  Commands which are

+   permitted in multiple states are listed in the minimum permitted

+   state (for example, commands valid in authenticated and selected

+   state are listed in the authenticated state commands).

+

+   Command arguments, identified by "Arguments:" in the command

+   descriptions below, are described by function, not by syntax.  The

+   precise syntax of command arguments is described in the Formal Syntax

+   section.

+

+   Some commands cause specific server data to be returned; these are

+   identified by "Data:" in the command descriptions below.  See the

+   response descriptions in the Responses section for information on

+   these responses, and the Formal Syntax section for the precise syntax

+   of these responses.  It is possible for server data to be transmitted

+   as a result of any command; thus, commands that do not specifically

+   require server data specify "no specific data for this command"

+   instead of "none".

+

+   The "Result:" in the command description refers to the possible

+   tagged status responses to a command, and any special interpretation

+   of these status responses.

+

+

+6.1.    Client Commands - Any State

+

+   The following commands are valid in any state: CAPABILITY, NOOP, and

+   LOGOUT.

+

+6.1.1.  CAPABILITY Command

+

+   Arguments:  none

+

+   Data:       mandatory untagged response: CAPABILITY

+

+   Result:     OK - capability completed

+               BAD - command unknown or arguments invalid

+

+      The CAPABILITY command requests a listing of capabilities that the

+      server supports.  The server MUST send a single untagged

+      CAPABILITY response with "IMAP4" as the first listed capability

+      before the (tagged) OK response.  This listing of capabilities is

+      not dependent upon connection state or user.  It is therefore not

+      necessary to issue a CAPABILITY command more than once in a

+      session.

+

+

+

+Crispin                                                        [Page 10]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      Capability names other than "IMAP4" refer to extensions,

+      revisions, or amendments to this specification.  See the

+      documentation of the CAPABILITY response for additional

+      information.  No capabilities are enabled without explicit client

+      action to invoke the capability.  See the section entitled "Client

+      Commands - Experimental/Expansion" for information about the form

+      of site or implementation-specific capabilities.

+

+   Example:    C: abcd CAPABILITY

+               S: * CAPABILITY IMAP4

+               S: abcd OK CAPABILITY completed

+

+

+6.1.2.  NOOP Command

+

+   Arguments:  none

+

+   Data:       no specific data for this command (but see below)

+

+   Result:     OK - noop completed

+               BAD - command unknown or arguments invalid

+

+      The NOOP command always succeeds.  It does nothing.

+

+      Since any command can return a status update as untagged data, the

+      NOOP command can be used as a periodic poll for new messages or

+      message status updates during a period of inactivity.  The NOOP

+      command can also be used to reset any inactivity autologout timer

+      on the server.

+

+   Example:    C: a002 NOOP

+               S: a002 OK NOOP completed

+                  . . .

+               C: a047 NOOP

+               S: * 22 EXPUNGE

+               S: * 23 EXISTS

+               S: * 3 RECENT

+               S: * 14 FETCH (FLAGS (\Seen \Deleted))

+               S: a047 OK NOOP completed

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 11]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+6.1.3.  LOGOUT Command

+

+   Arguments:  none

+

+   Data:       mandatory untagged response: BYE

+

+   Result:     OK - logout completed

+               BAD - command unknown or arguments invalid

+

+      The LOGOUT command informs the server that the client is done with

+      the session.  The server must send a BYE untagged response before

+      the (tagged) OK response, and then close the network connection.

+

+   Example:    C: A023 LOGOUT

+               S: * BYE IMAP4 Server logging out

+               S: A023 OK LOGOUT completed

+               (Server and client then close the connection)

+

+

+

+6.2.    Client Commands - Non-Authenticated State

+

+   In non-authenticated state, the AUTHENTICATE or LOGIN command

+   establishes authentication and enter authenticated state.  The

+   AUTHENTICATE command provides a general mechanism for a variety of

+   authentication techniques, whereas the LOGIN command uses the

+   traditional user name and plaintext password pair.

+

+   Server implementations may allow non-authenticated access to certain

+   mailboxes.  The convention is to use a LOGIN command with the userid

+   "anonymous".  A password is required.  It is implementation-dependent

+   what requirements, if any, are placed on the password and what access

+   restrictions are placed on anonymous users.

+

+   Once authenticated (including as anonymous), it is not possible to

+   re-enter non-authenticated state.

+

+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),

+   the following commands are valid in non-authenticated state:

+   AUTHENTICATE and LOGIN.

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 12]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+6.2.1.  AUTHENTICATE Command

+

+   Arguments:  authentication mechanism name

+

+   Data:       continuation data may be requested

+

+   Result:     OK - authenticate completed, now in authenticated state

+               NO - authenticate failure: unsupported authentication

+                    mechanism, credentials rejected

+               BAD - command unknown or arguments invalid,

+                    authentication exchange cancelled

+

+      The AUTHENTICATE command indicates an authentication mechanism,

+      such as described in [IMAP-AUTH], to the server.  If the server

+      supports the requested authentication mechanism, it performs an

+      authentication protocol exchange to authenticate and identify the

+      user.  Optionally, it also negotiates a protection mechanism for

+      subsequent protocol interactions.  If the requested authentication

+      mechanism is not supported, the server should reject the

+      AUTHENTICATE command by sending a tagged NO response.

+

+      The authentication protocol exchange consists of a series of

+      server challenges and client answers that are specific to the

+      authentication mechanism.  A server challenge consists of a

+      command continuation request response with the "+" token followed

+      by a BASE64 encoded string.  The client answer consists of a line

+      consisting of a BASE64 encoded string.  If the client wishes to

+      cancel an authentication exchange, it should issue a line with a

+      single "*".  If the server receives such an answer, it must reject

+      the AUTHENTICATE command by sending a tagged BAD response.

+

+      A protection mechanism provides integrity and privacy protection

+      to the protocol session.  If a protection mechanism is negotiated,

+      it is applied to all subsequent data sent over the connection.

+      The protection mechanism takes effect immediately following the

+      CRLF that concludes the authentication exchange for the client,

+      and the CRLF of the tagged OK response for the server.  Once the

+      protection mechanism is in effect, the stream of command and

+      response octets is processed into buffers of ciphertext.  Each

+      buffer is transferred over the connection as a stream of octets

+      prepended with a four octet field in network byte order that

+      represents the length of the following data.  The maximum

+      ciphertext buffer length is defined by the protection mechanism.

+

+      The server is not required to support any particular

+      authentication mechanism, nor are authentication mechanisms

+      required to support any protection mechanisms.  If an AUTHENTICATE

+      command fails with a NO response, the client may try another

+

+

+

+Crispin                                                        [Page 13]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      authentication mechanism by issuing another AUTHENTICATE command,

+      or may attempt to authenticate by using the LOGIN command.  In

+      other words, the client may request authentication types in

+      decreasing order of preference, with the LOGIN command as a last

+      resort.

+

+   Example:    S: * OK KerberosV4 IMAP4 Server

+               C: A001 AUTHENTICATE KERBEROS_V4

+               S: + AmFYig==

+               C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT

+                  +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd

+                  WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh

+               S: + or//EoAADZI=

+               C: DiAF5A4gA+oOIALuBkAAmw==

+               S: A001 OK Kerberos V4 authentication successful

+

+        Note: the line breaks in the first client answer are for

+        editorial clarity and are not in real authenticators.

+

+

+6.2.2.  LOGIN Command

+

+   Arguments:  user name

+               password

+

+   Data:       no specific data for this command

+

+   Result:     OK - login completed, now in authenticated state

+               NO - login failure: user name or password rejected

+               BAD - command unknown or arguments invalid

+

+      The LOGIN command identifies the user to the server and carries

+      the plaintext password authenticating this user.

+

+   Example:    C: a001 LOGIN SMITH SESAME

+               S: a001 OK LOGIN completed

+

+

+

+6.3.    Client Commands - Authenticated State

+

+   In authenticated state, commands that manipulate mailboxes as atomic

+   entities are permitted.  Of these commands, the SELECT and EXAMINE

+   commands will select a mailbox for access and enter selected state.

+

+

+

+

+

+

+

+Crispin                                                        [Page 14]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),

+   the following commands are valid in authenticated state: SELECT,

+   EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,

+   and APPEND.

+

+6.3.1.  SELECT Command

+

+   Arguments:  mailbox name

+

+   Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT

+               optional OK untagged responses: UNSEEN, PERMANENTFLAGS

+

+   Result:     OK - select completed, now in selected state

+               NO - select failure, now in authenticated state: no

+                    such mailbox, can't access mailbox

+               BAD - command unknown or arguments invalid

+

+      The SELECT command selects a  mailbox  so  that  messages  in  the

+      mailbox  can  be  accessed.  Before returning an OK to the client,

+      the server MUST send the following untagged data to the client:

+

+         FLAGS       Defined flags in the mailbox

+

+         <n> EXISTS  The number of messages in the mailbox

+

+         <n> RECENT  The number of messages added to the  mailbox  since

+                     the previous time this mailbox was read

+

+         OK [UIDVALIDITY <n>]

+                     The unique  identifier  validity  value.   See  the

+                     description of the UID command for more detail.

+

+      to define the initial state of the mailbox at the client.  If it

+      is not possible to determine the messages that were added since

+      the previous time a mailbox was read, then all messages SHOULD be

+      considered recent.

+

+      The server SHOULD also send an UNSEEN response code in an OK

+      untagged response, indicating the message sequence number of the

+      first unseen message in the mailbox.

+

+      If the client can not change the permanent state of one or more of

+      the flags listed in the FLAGS untagged response, the server SHOULD

+      send a PERMANENTFLAGS response code in an OK untagged response,

+      listing the flags that the client may change permanently.

+

+      Only one mailbox may be selected at a time in a session;

+      simultaneous access to multiple mailboxes requires multiple

+

+

+

+Crispin                                                        [Page 15]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      sessions.  The SELECT command automatically deselects any

+      currently selected mailbox before attempting the new selection.

+      Consequently, if a mailbox is selected and a SELECT command that

+      fails is attempted, no mailbox is selected.

+

+      If the user is permitted to modify the mailbox, the server SHOULD

+      prefix the text of the tagged OK response with the "[READ-WRITE]"

+      response code.

+

+      If the user is not permitted to modify the mailbox but is

+      permitted read access, the mailbox is selected as read-only, and

+      the server MUST prefix the text of the tagged OK response to

+      SELECT with the "[READ-ONLY]" response code.  Read-only access

+      through SELECT differs from the EXAMINE command in that certain

+      read-only mailboxes may permit the change of permanent state on a

+      per-user (as opposed to global) basis.  Netnews messages marked in

+      a user's .newsrc file are an example of such per-user permanent

+      state that can be modified with read-only mailboxes.

+

+   Example:    C: A142 SELECT INBOX

+               S: * 172 EXISTS

+               S: * 1 RECENT

+               S: * OK [UNSEEN 12] Message 12 is first unseen

+               S: * OK [UIDVALIDITY 3857529045] UIDs valid

+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

+               S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited

+               S: A142 OK [READ-WRITE] SELECT completed

+

+

+6.3.2.  EXAMINE Command

+

+   Arguments:  mailbox name

+

+   Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT

+               optional OK untagged responses: UNSEEN, PERMANENTFLAGS

+

+   Result:     OK - examine completed, now in selected state

+               NO - examine failure, now in authenticated state: no

+                    such mailbox, can't access mailbox

+               BAD - command unknown or arguments invalid

+

+      The EXAMINE command is identical to SELECT and returns the same

+      output; however, the selected mailbox is identified as read-only.

+      No changes to the permanent state of the mailbox, including

+      per-user state, are permitted.

+

+

+

+

+

+

+Crispin                                                        [Page 16]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      The text of the tagged OK response to the EXAMINE command MUST

+      begin with the "[READ-ONLY]" response code.

+

+   Example:    C: A932 EXAMINE blurdybloop

+               S: * 17 EXISTS

+               S: * 2 RECENT

+               S: * OK [UNSEEN 8] Message 8 is first unseen

+               S: * OK [UIDVALIDITY 3857529045] UIDs valid

+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

+               S: * OK [PERMANENTFLAGS ()] No permanent flags permitted

+               S: A932 OK [READ-ONLY] EXAMINE completed

+

+

+6.3.3.  CREATE Command

+

+   Arguments:  mailbox name

+

+   Data:       no specific data for this command

+

+   Result:     OK - create completed

+               NO - create failure: can't create mailbox with that name

+               BAD - command unknown or arguments invalid

+

+      The CREATE command creates a mailbox with the given name.  An OK

+      response is returned only if a new mailbox with that name has been

+      created.  It is an error to attempt to create INBOX or a mailbox

+      with a name that refers to an extant mailbox.  Any error in

+      creation will return a tagged NO response.

+

+      If the mailbox name is suffixed with the server's hierarchy

+      separator character (as returned from the server by a LIST

+      command), this is a declaration that the client may, in the

+      future, create mailbox names under this name in the hierarchy.

+      Server implementations that do not require this declaration MUST

+      ignore it.

+

+      If a new mailbox is created with the same name as a mailbox which

+      was deleted, its unique identifiers MUST be greater than any

+      unique identifiers used in the previous incarnation of the mailbox

+      UNLESS the new incarnation has a different unique identifier

+      validity value.  See the description of the UID command for more

+      detail.

+

+   Example:    C: A003 CREATE owatagusiam/

+               S: A003 OK CREATE completed

+               C: A004 CREATE owatagusiam/blurdybloop

+               S: A004 OK CREATE completed

+

+

+

+

+Crispin                                                        [Page 17]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+        Note: the interpretation of this example depends on whether

+        "/" was returned as the hierarchy separator from LIST.  If

+        "/" is the hierarchy separator, a new level of hierarchy

+        named "owatagusiam" with a member called "blurdybloop" is

+        created.  Otherwise, two mailboxes at the same hierarchy

+        level are created.

+

+

+6.3.4.  DELETE Command

+

+   Arguments:  mailbox name

+

+   Data:       no specific data for this command

+

+   Result:     OK - delete completed

+               NO - delete failure: can't delete mailbox with that name

+               BAD - command unknown or arguments invalid

+

+      The DELETE command permanently removes the mailbox with the given

+      name.  A tagged OK response is returned only if the mailbox has

+      been deleted.  It is an error to attempt to delete INBOX or a

+      mailbox name that does not exist.  Any error in deletion will

+      return a tagged NO response.

+

+      The value of the highest-used unique indentifier of the deleted

+      mailbox MUST be preserved so that a new mailbox created with the

+      same name will not reuse the identifiers of the former

+      incarnation, UNLESS the new incarnation has a different unique

+      identifier validity value.  See the description of the UID command

+      for more detail.

+

+   Example:    C: A683 DELETE blurdybloop

+               S: A683 OK DELETE completed

+

+

+6.3.5.  RENAME Command

+

+   Arguments:  existing mailbox name

+               new mailbox name

+

+   Data:       no specific data for this command

+

+   Result:     OK - rename completed

+               NO - rename failure: can't rename mailbox with that name,

+                    can't rename to mailbox with that name

+               BAD - command unknown or arguments invalid

+

+

+

+

+

+Crispin                                                        [Page 18]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      The RENAME command changes the name of a mailbox.  A tagged OK

+      response is returned only if the mailbox has been renamed.  It is

+      an error to attempt to rename from a mailbox name that does not

+      exist or to a mailbox name that already exists.  Any error in

+      renaming will return a tagged NO response.

+

+      Renaming INBOX is permitted; a new, empty INBOX is created in its

+      place.

+

+   Example:    C: Z4S9 RENAME blurdybloop owatagusiam

+               S: Z4S9 OK RENAME completed

+

+

+6.3.6.  SUBSCRIBE Command

+

+   Arguments:  mailbox

+

+   Data:       no specific data for this command

+

+   Result:     OK - subscribe completed

+               NO - subscribe failure: can't subscribe to that name

+               BAD - command unknown or arguments invalid

+

+      The SUBSCRIBE command adds the specified mailbox name to the

+      server's set of "active" or "subscribed" mailboxes as returned by

+      the LSUB command.  This command returns a tagged OK response only

+      if the subscription is successful.

+

+   Example:    C: A002 SUBSCRIBE #news.comp.mail.mime

+               S: A002 OK SUBSCRIBE completed

+

+

+6.3.7.  UNSUBSCRIBE Command

+

+   Arguments:  mailbox name

+

+   Data:       no specific data for this command

+

+   Result:     OK - unsubscribe completed

+               NO - unsubscribe failure: can't unsubscribe that name

+               BAD - command unknown or arguments invalid

+

+      The UNSUBSCRIBE command removes the specified mailbox name from

+      the server's set of "active" or "subscribed" mailboxes as returned

+      by the LSUB command.  This command returns a tagged OK response

+      only if the unsubscription is successful.

+

+

+

+

+

+Crispin                                                        [Page 19]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime

+               S: A002 OK UNSUBSCRIBE completed

+

+

+6.3.8.  LIST Command

+

+   Arguments:  reference name

+               mailbox name with possible wildcards

+

+   Data:       untagged responses: LIST

+

+   Result:     OK - list completed

+               NO - list failure: can't list that reference or name

+               BAD - command unknown or arguments invalid

+

+      The LIST command returns a subset of names from the complete set

+      of all names available to the user.  Zero or more untagged LIST

+      replies are returned, containing the name attributes, hierarchy

+      delimiter, and name; see the description of the LIST reply for

+      more detail.

+

+      An empty ("" string) reference name argument indicates that the

+      mailbox name is interpreted as by SELECT. The returned mailbox

+      names MUST match the supplied mailbox name pattern.  A non-empty

+      reference name argument is the name of a mailbox or a level of

+      mailbox hierarchy, and indicates a context in which the mailbox

+      name is interpreted in an implementation-defined manner.

+

+      The reference and mailbox name arguments are interpreted, in an

+      implementation-dependent fashion, into a canonical form that

+      represents an unambiguous left-to-right hierarchy.  The returned

+      mailbox names will be in the interpreted form.

+

+      Any part of the reference argument that is included in the

+      interpreted form SHOULD prefix the interpreted form.  It should

+      also be in the same form as the reference name argument.  This

+      rule permits the client to determine if the returned mailbox name

+      is in the context of the reference argument, or if something about

+      the mailbox argument overrode the reference argument.  Without

+      this rule, the client would have to have knowledge of the server's

+      naming semantics including what characters are "breakouts" that

+      override a naming context.

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 20]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+           For example, here are some examples of how references

+           and mailbox names might be interpreted on a UNIX-based

+           server:

+

+               Reference     Mailbox Name  Interpretation

+               ------------  ------------  --------------

+               ~smith/Mail/  foo.*         ~smith/Mail/foo.*

+               archive/      %             archive/%

+               #news.        comp.mail.*   #news.comp.mail.*

+               ~smith/Mail/  /usr/doc/foo  /usr/doc/foo

+               archive/      ~fred/Mail/*  ~fred/Mail/*

+

+           The first three examples demonstrate interpretations in

+           the context of the reference argument.  Note that

+           "~smith/Mail" should not be transformed into something

+           like "/u2/users/smith/Mail", or it would be impossible

+           for the client to determine that the interpretation was

+           in the context of the reference.

+

+      The character "*" is a wildcard, and matches zero or more

+      characters at this position.  The character "%" is similar to "*",

+      but it does not match a hierarchy delimiter.  If the "%" wildcard

+      is the last character of a mailbox name argument, matching levels

+      of hierarchy are also returned.  If these levels of hierarchy are

+      not also selectable mailboxes, they are returned with the

+      \Noselect mailbox name attribute (see the description of the LIST

+      response for more detail).

+

+      Server implementations are permitted to "hide" otherwise

+      accessible mailboxes from the wildcard characters, by preventing

+      certain characters or names from matching a wildcard in certain

+      situations.  For example, a UNIX-based server might restrict the

+      interpretation of "*" so that an initial "/" character does not

+      match.

+

+      The special name INBOX is included in the output from LIST if it

+      matches the input arguments and INBOX is supported by this server

+      for this user.  The criteria for omitting INBOX is whether SELECT

+      INBOX will return failure; it is not relevant whether the user's

+      real INBOX resides on this or some other server.

+

+   Example:    C: A002 LIST "~/Mail/" "%"

+               S: * LIST (\Noselect) "/" ~/Mail/foo

+               S: * LIST () "/" ~/Mail/meetings

+               S: A002 OK LIST completed

+

+

+

+

+

+

+Crispin                                                        [Page 21]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+6.3.9.  LSUB Command

+

+   Arguments:  reference name

+               mailbox name with possible wildcards

+

+   Data:       untagged responses: LSUB

+

+   Result:     OK - lsub completed

+               NO - lsub failure: can't list that reference or name

+               BAD - command unknown or arguments invalid

+

+      The LSUB command returns a subset of names from the set of names

+      that the user has declared as being "active" or "subscribed".

+      Zero or more untagged LSUB replies are returned.  The arguments to

+      LSUB are in the same form as those for LIST.

+

+   Example:    C: A002 LSUB "#news." "comp.mail.*"

+               S: * LSUB () "." #news.comp.mail.mime

+               S: * LSUB () "." #news.comp.mail.misc

+               S: A002 OK LSUB completed

+

+

+6.3.10. APPEND Command

+

+   Arguments:  mailbox name

+               optional flag parenthesized list

+               optional date/time string

+               message literal

+

+   Data:       no specific data for this command

+

+   Result:     OK - append completed

+               NO - append error: can't append to that mailbox, error

+                    in flags or date/time or message text

+               BAD - command unknown or arguments invalid

+

+      The APPEND command appends the literal argument as a new message

+      in the specified destination mailbox.  This argument is in the

+      format of an [RFC-822] message.  8-bit characters are permitted in

+      the message.  A server implementation that is unable to preserve

+      8-bit data properly MUST be able to reversibly convert 8-bit

+      APPEND data to 7-bit using [MIME-1] encoding.

+

+      If a flag parenthesized list or date_time are specified, that data

+      SHOULD be set in the resulting message; otherwise, the defaults of

+      empty flags and the current date/time are used.

+

+

+

+

+

+Crispin                                                        [Page 22]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      If the append is unsuccessful for any reason, the mailbox MUST be

+      restored to its state before the APPEND attempt; no partial

+      appending is permitted.  If the mailbox is currently selected, the

+      normal new mail actions should occur.

+

+      If the destination mailbox does not exist, a server MUST return an

+      error, and MUST NOT automatically create the mailbox.  Unless it

+      is certain that the destination mailbox can not be created, the

+      server MUST send the response code "[TRYCREATE]" as the prefix of

+      the text of the tagged NO response.  This gives a hint to the

+      client that it can attempt a CREATE command and retry the APPEND

+      if the CREATE is successful.

+

+   Example:    C: A003 APPEND saved-messages (\Seen) {310}

+               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)

+               C: From: Fred Foobar <foobar@Blurdybloop.COM>

+               C: Subject: afternoon meeting

+               C: To: mooch@owatagu.siam.edu

+               C: Message-Id: <B27397-0100000@Blurdybloop.COM>

+               C: MIME-Version: 1.0

+               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

+               C:

+               C: Hello Joe, do you think we can meet at 3:30 tomorrow?

+               C:

+               S: A003 OK APPEND completed

+

+        Note: the APPEND command is not used for message delivery,

+        because it does not provide a mechanism to transfer [SMTP]

+        envelope information.

+

+

+

+6.4.    Client Commands - Selected State

+

+   In selected state, commands that manipulate messages in a mailbox are

+   permitted.

+

+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),

+   and the authenticated state commands (SELECT, EXAMINE, CREATE,

+   DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND

+   ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands

+   are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,

+   FETCH, PARTIAL, STORE, COPY, and UID.

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 23]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+6.4.1.  CHECK Command

+

+   Arguments:  none

+

+   Data:       no specific data for this command

+

+   Result:     OK - check completed

+               BAD - command unknown or arguments invalid

+

+      The CHECK command requests a checkpoint of the currently selected

+      mailbox.  A checkpoint refers to any implementation-dependent

+      housekeeping associated with the mailbox (e.g. resolving the

+      server's in-memory state of the mailbox with the state on its

+      disk) that is not normally executed as part of each command.  A

+      checkpoint may take a non-instantaneous amount of real time to

+      complete.  If a server implementation has no such housekeeping

+      considerations, CHECK is equivalent to NOOP.

+

+      There is no guarantee that an EXISTS untagged response will happen

+      as a result of CHECK.  NOOP, not CHECK, should be used for new

+      mail polling.

+

+   Example:    C: FXXZ CHECK

+               S: FXXZ OK CHECK Completed

+

+

+6.4.2.  CLOSE Command

+

+   Arguments:  none

+

+   Data:       no specific data for this command

+

+   Result:     OK - close completed, now in authenticated state

+               NO - close failure: no mailbox selected

+               BAD - command unknown or arguments invalid

+

+      The CLOSE command permanently removes from the currently selected

+      mailbox all messages that have the \Deleted flag set, and returns

+      to authenticated state from selected state.  No untagged EXPUNGE

+      responses are sent.

+

+      No messages are removed, and no error is given, if the mailbox is

+      selected by an EXAMINE command or is otherwise selected read-only.

+

+      Even when a mailbox is selected, it is not required to send a

+      CLOSE command before a SELECT, EXAMINE, or LOGOUT command.  The

+      SELECT, EXAMINE, and LOGOUT commands implicitly close the

+      currently selected mailbox without doing an expunge.  However,

+

+

+

+Crispin                                                        [Page 24]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT

+      sequence is considerably faster than an EXPUNGE-LOGOUT or

+      EXPUNGE-SELECT because no untagged EXPUNGE responses (which the

+      client would probably ignore) are sent.

+

+   Example:    C: A341 CLOSE

+               S: A341 OK CLOSE completed

+

+

+6.4.3.  EXPUNGE Command

+

+   Arguments:  none

+

+   Data:       untagged responses: EXPUNGE

+

+   Result:     OK - expunge completed

+               NO - expunge failure: can't expunge (e.g. permission

+                    denied)

+               BAD - command unknown or arguments invalid

+

+      The EXPUNGE command permanently removes from the currently

+      selected mailbox all messages that have the \Deleted flag set.

+      Before returning an OK to the client, an untagged EXPUNGE response

+      is sent for each message that is removed.

+

+   Example:    C: A202 EXPUNGE

+               S: * 3 EXPUNGE

+               S: * 3 EXPUNGE

+               S: * 5 EXPUNGE

+               S: * 8 EXPUNGE

+               S: A202 OK EXPUNGE completed

+

+        Note: in this example, messages 3, 4, 7, and 11 had the

+        \Deleted flag set.  See the description of the EXPUNGE

+        response for further explanation.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 25]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+6.4.4.  SEARCH Command

+

+   Arguments:  optional character set specification

+               searching criteria (one or more)

+

+   Data:       mandatory untagged response: SEARCH

+

+   Result:     OK - search completed

+               NO - search error: can't search that character set or

+                    criteria

+               BAD - command unknown or arguments invalid

+

+      The SEARCH command searches the mailbox for messages that match

+      the given searching criteria.  Searching criteria consist of one

+      or more search keys.  The untagged SEARCH response from the server

+      contains a listing of message sequence numbers corresponding to

+      those messages that match the searching criteria.

+

+      When multiple keys are specified, the result is the intersection

+      (AND function) of all the messages that match those keys.  For

+      example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers

+      to all deleted messages from Smith that were placed in the mailbox

+      since February 1, 1994.  A search key may also be a parenthesized

+      list of one or more search keys (e.g. for use with the OR and NOT

+      keys).

+

+      Server implementations MAY exclude [MIME-1] body parts with

+      terminal content types other than TEXT and MESSAGE from

+      consideration in SEARCH matching.

+

+      The optional character set specification consists of the word

+      "CHARSET" followed by a registered MIME character set.  It

+      indicates the character set of the strings that appear in the

+      search criteria.  [MIME-2] strings that appear in RFC 822/MIME

+      message headers, and [MIME-1] content transfer encodings, MUST be

+      decoded before matching.  Except for US-ASCII, it is not required

+      that any particular character set be supported.  If the server

+      does not support the specified character set, it MUST return a

+      tagged NO response (not a BAD).

+

+      In all search keys that use strings, a message matches the key if

+      the string is a substring of the field.  The matching is

+      case-insensitive.

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 26]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      The defined search keys are as follows.  Refer to the Formal

+      Syntax section for the precise syntactic definitions of the

+      arguments.

+

+      <message set>  Messages with message sequence numbers

+                     corresponding to the specified message sequence

+                     number set

+

+      ALL            All messages in the mailbox; the default initial

+                     key for ANDing.

+

+      ANSWERED       Messages with the \Answered flag set.

+

+      BCC <string>   Messages that contain the specified string in the

+                     envelope structure's BCC field.

+

+      BEFORE <date>  Messages whose internal date is earlier than the

+                     specified date.

+

+      BODY <string>  Messages that contain the specified string in the

+                     body of the message.

+

+      CC <string>    Messages that contain the specified string in the

+                     envelope structure's CC field.

+

+      DELETED        Messages with the \Deleted flag set.

+

+      DRAFT          Messages with the \Draft flag set.

+

+      FLAGGED        Messages with the \Flagged flag set.

+

+      FROM <string>  Messages that contain the specified string in the

+                     envelope structure's FROM field.

+

+      HEADER <field-name> <string>

+                     Messages that have a header with the specified

+                     field-name (as defined in [RFC-822]) and that

+                     contains the specified string in the [RFC-822]

+                     field-body.

+

+      KEYWORD <flag> Messages with the specified keyword set.

+

+      LARGER <n>     Messages with an RFC822.SIZE larger than the

+                     specified number of octets.

+

+      NEW            Messages that have the \Recent flag set but not the

+                     \Seen flag.  This is functionally equivalent to

+                     "(RECENT UNSEEN)".

+

+

+

+Crispin                                                        [Page 27]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      NOT <search-key>

+                     Messages that do not match the specified search

+                     key.

+

+      OLD            Messages that do not have the \Recent flag set.

+                     This is functionally equivalent to "NOT RECENT" (as

+                     opposed to "NOT NEW").

+

+      ON <date>      Messages whose internal date is within the

+                     specified date.

+

+      OR <search-key1> <search-key2>

+                     Messages that match either search key.

+

+      RECENT         Messages that have the \Recent flag set.

+

+      SEEN           Messages that have the \Seen flag set.

+

+      SENTBEFORE <date>

+                     Messages whose [RFC-822] Date: header is earlier

+                     than the specified date.

+

+      SENTON <date>  Messages whose [RFC-822] Date: header is within the

+                     specified date.

+

+      SENTSINCE <date>

+                     Messages whose [RFC-822] Date: header is within or

+                     later than the specified date.

+

+      SINCE <date>   Messages whose internal date is within or later

+                     than the specified date.

+

+      SMALLER <n>    Messages with an RFC822.SIZE smaller than the

+                     specified number of octets.

+

+      SUBJECT <string>

+                     Messages that contain the specified string in the

+                     envelope structure's SUBJECT field.

+

+      TEXT <string>  Messages that contain the specified string in the

+                     header or body of the message.

+

+      TO <string>    Messages that contain the specified string in the

+                     envelope structure's TO field.

+

+      UID <message set>

+                     Messages with unique identifiers corresponding to

+                     the specified unique identifier set.

+

+

+

+Crispin                                                        [Page 28]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      UNANSWERED     Messages that do not have the \Answered flag set.

+

+      UNDELETED      Messages that do not have the \Deleted flag set.

+

+      UNDRAFT        Messages that do not have the \Draft flag set.

+

+      UNFLAGGED      Messages that do not have the \Flagged flag set.

+

+      UNKEYWORD <flag>

+                     Messages that do not have the specified keyword

+                     set.

+

+      UNSEEN         Messages that do not have the \Seen flag set.

+

+

+   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"

+               S: * SEARCH 2 84 882

+               S: A282 OK SEARCH completed

+

+

+6.4.5.  FETCH Command

+

+   Arguments:  message set

+               message data item names

+

+   Data:       untagged responses: FETCH

+

+   Result:     OK - fetch completed

+               NO - fetch error: can't fetch that data

+               BAD - command unknown or arguments invalid

+

+      The FETCH command retrieves data associated with a message in the

+      mailbox.  The data items to be fetched may be either a single atom

+      or a parenthesized list.  The currently defined data items that

+      can be fetched are:

+

+      ALL            Macro equivalent to: (FLAGS INTERNALDATE

+                     RFC822.SIZE ENVELOPE)

+

+      BODY           Non-extensible form of BODYSTRUCTURE.

+

+      BODY[<section>]

+                     The text of a particular body section.  The section

+                     specification is a set of one or more part numbers

+                     delimited by periods.

+

+                     Single-part messages only have a part 1.

+

+

+

+

+Crispin                                                        [Page 29]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+                     Multipart messages are assigned consecutive part

+                     numbers, as they occur in the message.  If a

+                     particular part is of type message or multipart,

+                     its parts must be indicated by a period followed by

+                     the part number within that nested multipart part.

+                     It is not permitted to fetch a multipart part

+                     itself, only its individual members.

+

+                     A part of type MESSAGE and subtype RFC822 also has

+                     nested parts.  These are the parts of the MESSAGE

+                     part's body.  Nested part 0 of a part of type

+                     MESSAGE and subtype RFC822 is the [RFC-822] header

+                     of the message.

+

+                     Every message has at least one part.

+

+                          Here is an example of a complex message

+                          with its associated section

+                          specifications:

+

+                           0   ([RFC-822] header of the message)

+                               MULTIPART/MIXED

+                           1   TEXT/PLAIN

+                           2   APPLICATION/OCTET-STREAM

+                           3   MESSAGE/RFC822

+                           3.0   ([RFC-822] header of the message)

+                           3.1   TEXT/PLAIN

+                           3.2   APPLICATION/OCTET-STREAM

+                                 MULTIPART/MIXED

+                           4.1   IMAGE/GIF

+                           4.2   MESSAGE/RFC822

+                           4.2.0   ([RFC-822] header of the message)

+                           4.2.1   TEXT/PLAIN

+                                   MULTIPART/ALTERNATIVE

+                           4.2.2.1  TEXT/PLAIN

+                           4.2.2.2  TEXT/RICHTEXT

+

+                          Note that there is no section

+                          specification for the Multi-part parts

+                          (no section 4 or 4.2.2).

+

+                     The \Seen flag is implicitly set; if this causes

+                     the flags to change they should be included as part

+                     of the fetch responses.

+

+      BODY.PEEK[<section>]

+                     An alternate form of BODY[section] that does not

+                     implicitly set the \Seen flag.

+

+

+

+Crispin                                                        [Page 30]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      BODYSTRUCTURE  The [MIME-1] body structure of the message.  This

+                     is computed by the server by parsing the [MIME-1]

+                     header lines.

+

+      ENVELOPE       The envelope structure of the message.  This is

+                     computed by the server by parsing the [RFC-822]

+                     header into the component parts, defaulting various

+                     fields as necessary.

+

+      FAST           Macro equivalent to: (FLAGS INTERNALDATE

+                     RFC822.SIZE)

+

+      FLAGS          The flags that are set for this message.

+

+      FULL           Macro equivalent to: (FLAGS INTERNALDATE

+                     RFC822.SIZE ENVELOPE BODY)

+

+      INTERNALDATE   The date and time of final delivery of the message

+                     as defined by RFC 821.

+

+      RFC822         The message in [RFC-822] format.  The \Seen flag is

+                     implicitly set; if this causes the flags to change

+                     they should be included as part of the fetch

+                     responses.  This is the concatenation of

+                     RFC822.HEADER and RFC822.TEXT.

+

+      RFC822.PEEK    An alternate form of RFC822 that does not

+                     implicitly set the \Seen flag.

+

+      RFC822.HEADER  The [RFC-822] format header of the message as

+                     stored on the server including the delimiting blank

+                     line between the header and the body.

+

+      RFC822.HEADER.LINES <header_list>

+                     All header lines (including continuation lines) of

+                     the [RFC-822] format header of the message with a

+                     field-name (as defined in [RFC-822]) that matches

+                     any of the strings in header_list.  The matching is

+                     case-insensitive but otherwise exact.  The

+                     delimiting blank line between the header and the

+                     body is always included.

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 31]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      RFC822.HEADER.LINES.NOT <header_list>

+                     All header lines (including continuation lines) of

+                     the [RFC-822] format header of the message with a

+                     field-name (as defined in [RFC-822]) that does not

+                     match any of the strings in header_list.  The

+                     matching is case-insensitive but otherwise exact.

+                     The delimiting blank line between the header and

+                     the body is always included.

+

+      RFC822.SIZE    The number of octets in the message, as expressed

+                     in [RFC-822] format.

+

+      RFC822.TEXT    The text body of the message, omitting the

+                     [RFC-822] header.  The \Seen flag is implicitly

+                     set; if this causes the flags to change they should

+                     be included as part of the fetch responses.

+

+      RFC822.TEXT.PEEK

+                     An alternate form of RFC822.TEXT that does not

+                     implicitly set the \Seen flag.

+

+      UID            The unique identifier for the message.

+

+

+   Example:    C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))

+               S: * 2 FETCH ....

+               S: * 3 FETCH ....

+               S: * 4 FETCH ....

+               S: A003 OK FETCH completed

+

+

+6.4.6.  PARTIAL Command

+

+   Arguments:  message sequence number

+               message data item name

+               position of first octet

+               number of octets

+

+   Data:       untagged responses: FETCH

+

+   Result:     OK - partial completed

+               NO - partial error: can't fetch that data

+               BAD - command unknown or arguments invalid

+

+      The PARTIAL command is equivalent to the associated FETCH command,

+      with the added functionality that only the specified number of

+      octets, beginning at the specified starting octet, are returned.

+      Only a single message can be fetched at a time.  The first octet

+

+

+

+Crispin                                                        [Page 32]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      of a message, and hence the minimum for the starting octet, is

+      octet 1.

+

+      The following FETCH items are valid data for PARTIAL: RFC822,

+      RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK

+      forms of these.

+

+      Any partial fetch that attempts to read beyond the end of the text

+      is truncated as appropriate.  If the starting octet is beyond the

+      end of the text, an empty string is returned.

+

+      The data are returned with the FETCH response.  There is no

+      indication of the range of the partial data in this response.  It

+      is not possible to stream multiple PARTIAL commands of the same

+      data item without processing and synchronizing at each step, since

+      streamed commands may be executed out of order.

+

+      There is no requirement that partial fetches follow any sequence.

+      For example, if a partial fetch of octets 1 through 10000 breaks

+      in an awkward place for BASE64 decoding, it is permitted to

+      continue with a partial fetch of 9987 through 19987, etc.

+

+      The handling of the \Seen flag is the same as in the associated

+      FETCH command.

+

+   Example:    C: A005 PARTIAL 4 RFC822 1 1024

+               S: * 1 FETCH (RFC822 {1024}

+               S: Return-Path: <gray@cac.washington.edu>

+               S: ...

+               S: .........  FLAGS (\Seen))

+               S: A005 OK PARTIAL completed

+

+

+6.4.7.  STORE Command

+

+   Arguments:  message set

+               message data item name

+               value for message data item

+

+   Data:       untagged responses: FETCH

+

+   Result:     OK - store completed

+               NO - store error: can't store that data

+               BAD - command unknown or arguments invalid

+

+      The STORE command alters data associated with a message in the

+      mailbox.  Normally, STORE will return the updated value of the

+      data with an untagged FETCH response.  A suffix of ".SILENT" in

+

+

+

+Crispin                                                        [Page 33]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      the data item name prevents the untagged FETCH, and the server

+      should assume that the client has determined the updated value

+      itself or does not care about the updated value.

+

+      The currently defined data items that can be stored are:

+

+      FLAGS <flag list>

+                     Replace the flags for the message with the

+                     argument.  The new value of the flags are returned

+                     as if a FETCH of those flags was done.

+

+      FLAGS.SILENT <flag list>

+                     Equivalent to FLAGS, but without returning a new

+                     value.

+

+      +FLAGS <flag list>

+                     Add the argument to the flags for the message.  The

+                     new value of the flags are returned as if a FETCH

+                     of those flags was done.

+

+      +FLAGS.SILENT <flag list>

+                     Equivalent to +FLAGS, but without returning a new

+                     value.

+

+      -FLAGS <flag list>

+                     Remove the argument from the flags for the message.

+                     The new value of the flags are returned as if a

+                     FETCH of those flags was done.

+

+      -FLAGS.SILENT <flag list>

+                     Equivalent to -FLAGS, but without returning a new

+                     value.

+

+

+   Example:    C: A003 STORE 2:4 +FLAGS (\Deleted)

+               S: * 2 FETCH FLAGS (\Deleted \Seen)

+               S: * 3 FETCH FLAGS (\Deleted)

+               S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)

+               S: A003 OK STORE completed

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 34]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+6.4.8.  COPY Command

+

+   Arguments:  message set

+               mailbox name

+

+   Data:       no specific data for this command

+

+   Result:     OK - copy completed

+               NO - copy error: can't copy those messages or to that

+                    name

+               BAD - command unknown or arguments invalid

+

+      The COPY command copies the specified message(s) to the specified

+      destination mailbox.  The flags and internal date of the

+      message(s) SHOULD be preserved in the copy.

+

+      If the destination mailbox does not exist, a server SHOULD return

+      an error.  It SHOULD NOT automatically create the mailbox.  Unless

+      it is certain that the destination mailbox can not be created, the

+      server MUST send the response code "[TRYCREATE]" as the prefix of

+      the text of the tagged NO response.  This gives a hint to the

+      client that it can attempt a CREATE command and retry the COPY if

+      the CREATE is successful.

+

+      If the COPY command is unsuccessful for any reason, server

+      implementations MUST restore the destination mailbox to its state

+      before the COPY attempt.

+

+   Example:    C: A003 COPY 2:4 MEETING

+               S: A003 OK COPY completed

+

+

+6.4.9.  UID Command

+

+   Arguments:  command name

+               command arguments

+

+   Data:       untagged responses: FETCH, SEARCH

+

+   Result:     OK - UID command completed

+               NO - UID command error

+               BAD - command unknown or arguments invalid

+

+      The UID command has two forms.  In the first form, it takes as its

+      arguments a COPY, FETCH, or STORE command with arguments

+      appropriate for the associated command.  However, the numbers in

+      the message set argument are unique identifiers instead of message

+      sequence numbers.

+

+

+

+Crispin                                                        [Page 35]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      In the second form, the UID command takes a SEARCH command with

+      SEARCH command arguments.  The interpretation of the arguments is

+      the same as with SEARCH; however, the numbers returned in a SEARCH

+      response for a UID SEARCH command are unique identifiers instead

+      of message sequence numbers.  For example, the command UID SEARCH

+      1:100 UID 443:557 returns the unique identifiers corresponding to

+      the intersection of the message sequence number set 1:100 and the

+      UID set 443:557.

+

+      A unique identifier of a message is a number, and is guaranteed

+      not to refer to any other message in the mailbox.  Unique

+      identifiers are assigned in a strictly ascending fashion for each

+      message added to the mailbox.  Unlike message sequence numbers,

+      unique identifiers persist across sessions.  This permits a client

+      to resynchronize its state from a previous session with the server

+      (e.g.  disconnected or offline access clients); this is discussed

+      further in [IMAP-DISC].

+

+      Associated with every mailbox is a unique identifier validity

+      value, which is sent in an UIDVALIDITY response code in an OK

+      untagged response at message selection time.  If unique

+      identifiers from an earlier session fail to persist to this

+      session, the unique identifier validity value MUST be greater than

+      in the earlier session.

+

+           Note: An example of a good value to use for the unique

+           identifier validity value would be a 32-bit

+           representation of the creation date/time of the mailbox.

+           It is alright to use a constant such as 1, but only if

+           it guaranteed that unique identifers will never be

+           reused, even in the case of a mailbox being deleted and

+           a new mailbox by the same name created at some future

+           time.

+

+

+      Message set ranges are permitted; however, there is no guarantee

+      that unique identifiers be contiguous.  A non-existent unique

+      identifier within a message set range is ignored without any error

+      message generated.

+

+      The number after the "*" in an untagged FETCH response is always a

+      message sequence number, not a unique identifier, even for a UID

+      command response.  However, server implementations MUST implicitly

+      include the UID message data item as part of any FETCH response

+      caused by a UID command, regardless of whether UID was specified

+      as a message data item to the FETCH.

+

+

+

+

+

+Crispin                                                        [Page 36]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   Example:    C: A003 UID FETCH 4827313:4828442 FLAGS

+               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)

+               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)

+               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)

+               S: A999 UID FETCH completed

+

+

+

+6.5.    Client Commands - Experimental/Expansion

+

+

+6.5.1.  X<atom> Command

+

+   Arguments:  implementation defined

+

+   Data:       implementation defined

+

+   Result:     OK - command completed

+               NO - failure

+               BAD - command unknown or arguments invalid

+

+      Any command prefixed with an X is an experimental command.

+      Commands which are not part of this specification, or a standard

+      or standards-track revision of this specification, MUST use the X

+      prefix.

+

+      Any added untagged responses issued by an experimental command

+      MUST also be prefixed with an X.  Server implementations MUST NOT

+      send any such untagged responses, unless the client requested it

+      by issuing the associated experimental command.

+

+   Example:    C: a441 CAPABILITY

+               S: * CAPABILITY IMAP4 XPIG-LATIN

+               S: a441 OK CAPABILITY completed

+               C: A442 XPIG-LATIN

+               S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay

+               S: A442 OK XPIG-LATIN ompleted-cay

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 37]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+7.      Server Responses

+

+   Server responses are in three forms: status responses, server data,

+   and command continuation request.

+

+   Server response data, identified by "Data:" in the response

+   descriptions below, are described by function, not by syntax.  The

+   precise syntax of server response data is described in the Formal

+   Syntax section.

+

+   The client MUST be prepared to accept any response at all times.

+

+   Status responses that are tagged indicate the completion result of a

+   client command, and have a tag matching the command.

+

+   Some status responses, and all server data, are untagged.  An

+   untagged response is indicated by the token "*" instead of a tag.

+   Untagged status responses indicate server greeting, or server status

+   that does not indicate the completion of a command.  For historical

+   reasons, untagged server data responses are also called "unsolicited

+   data", although strictly speaking only unilateral server data is

+   truly "unsolicited".

+

+   Certain server data MUST be recorded by the client when it is

+   received; this is noted in the description of that data.  Such data

+   conveys critical information which affects the interpretation of all

+   subsequent commands and responses (e.g. updates reflecting the

+   creation or destruction of messags).

+

+   Other server data SHOULD be recorded for later reference; if the

+   client does not need to record the data, or if recording the data has

+   no obvious purpose (e.g. a SEARCH response when no SEARCH command is

+   in progress), the data SHOULD be ignored.

+

+   An example of unilateral untagged responses occurs when the IMAP

+   connection is in selected state.  In selected state, the server

+   checks the mailbox for new messages as part of the execution of each

+   command.  If new messages are found, the server sends untagged EXISTS

+   and RECENT responses reflecting the new size of the mailbox.  Server

+   implementations that offer multiple simultaneous access to the same

+   mailbox should also send appropriate unilateral untagged FETCH and

+   EXPUNGE responses if another agent changes the state of any message

+   flags or expunges any messages.

+

+   Command continuation request responses use the token "+" instead of a

+   tag.  These responses are sent by the server to indicate acceptance

+   of an incomplete client command and readiness for the remainder of

+   the command.

+

+

+

+Crispin                                                        [Page 38]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+7.1.    Server Responses - Status Responses

+

+   Status responses may include an optional response code.  A response

+   code consists of data inside square brackets in the form of an atom,

+   possibly followed by a space and arguments.  The response code

+   contains additional information or status codes for client software

+   beyond the OK/NO/BAD condition, and are defined when there is a

+   specific action that a client can take based upon the additional

+   information.

+

+   The currently defined response codes are:

+

+      ALERT          The human-readable text contains a special alert

+                     that MUST be presented to the user in a fashion

+                     that calls the user's attention to the message.

+

+      PARSE          The human-readable text represents an error in

+                     parsing the [RFC-822] or [MIME-1] headers of a

+                     message in the mailbox.

+

+      PERMANENTFLAGS Followed by a parenthesized list of flags,

+                     indicates which of the known flags that the client

+                     may change permanently.  Any flags that are in the

+                     FLAGS untagged response, but not the PERMANENTFLAGS

+                     list, can not be set permanently.  If the client

+                     attempts to STORE a flag that is not in the

+                     PERMANENTFLAGS list, the server will either reject

+                     it with a NO reply or store the state for the

+                     remainder of the current session only.  The

+                     PERMANENTFLAGS list may also include the special

+                     flag \*, which indicates that it is possible to

+                     create new keywords by attempting to store those

+                     flags in the mailbox.

+

+      READ-ONLY      The mailbox is selected read-only, or its access

+                     while selected has changed from read-write to

+                     read-only.

+

+      READ-WRITE     The mailbox is selected read-write, or its access

+                     while selected has changed from read-only to

+                     read-write.

+

+      TRYCREATE      An APPEND or COPY attempt is failing because the

+                     target mailbox does not exist (as opposed to some

+                     other reason).  This is a hint to the client that

+                     the operation may succeed if the mailbox is first

+                     created by the CREATE command.

+

+

+

+

+Crispin                                                        [Page 39]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      UIDVALIDITY    Followed by a decimal number, indicates the unique

+                     identifier validity value.  See the description of

+                     the UID command for more detail.

+

+      UNSEEN         Followed by a decimal number, indicates the number

+                     of the first message without the \Seen flag set.

+

+      Additional response codes defined by particular client or server

+      implementations should be prefixed with an "X" until they are

+      added to a revision of this protocol.  Client implementations

+      should ignore response codes that they do not recognize.

+

+

+7.1.1.  OK Response

+

+   Data:       optional response code

+               human-readable text

+

+      The OK response indicates an information message from the server.

+      When tagged, it indicates successful completion of the associated

+      command.  The human-readable text may be presented to the user as

+      an information message.  The untagged form indicates an

+      information-only message; the nature of the information may be

+      indicated by a response code.

+

+      The untagged form is also used as one of three possible greetings

+      at session startup.  It indicates that the session is not yet

+      authenticated and that a LOGIN command is needed.

+

+   Example:    S: * OK IMAP4 server ready

+               C: A001 LOGIN fred blurdybloop

+               S: * OK [ALERT] System shutdown in 10 minutes

+               S: A001 OK LOGIN Completed

+

+

+7.1.2.  NO Response

+

+   Data:       optional response code

+               human-readable text

+

+      The NO response indicates an operational error message from the

+      server.  When tagged, it indicates unsuccessful completion of the

+      associated command.  The untagged form indicates a warning; the

+      command may still complete successfully.  The human-readable text

+      describes the condition.

+

+

+

+

+

+

+Crispin                                                        [Page 40]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   Example:    C: A222 COPY 1:2 owatagusiam

+               S: * NO Disk is 98% full, please delete unnecessary data

+               S: A222 OK COPY completed

+               C: A222 COPY 3:200 blurdybloop

+               S: * NO Disk is 98% full, please delete unnecessary data

+               S: * NO Disk is 99% full, please delete unnecessary data

+               S: A222 NO COPY failed: disk is full

+

+

+7.1.3.  BAD Response

+

+   Data:       optional response code

+               human-readable text

+

+      The BAD response indicates an error message from the server.  When

+      tagged, it reports a protocol-level error in the client's command;

+      the tag indicates the command that caused the error.  The untagged

+      form indicates a protocol-level error for which the associated

+      command can not be determined; it may also indicate an internal

+      server failure.  The human-readable text describes the condition.

+

+   Example:    C: ...very long command line...

+               S: * BAD Command line too long

+               C: ...empty line...

+               S: * BAD Empty command line

+               C: A443 EXPUNGE

+               S: * BAD Disk crash, attempting salvage to a new disk!

+               S: * OK Salvage successful, no data lost

+               S: A443 OK Expunge completed

+

+

+7.1.4.  PREAUTH Response

+

+   Data:       optional response code

+               human-readable text

+

+      The PREAUTH response is always untagged, and is one of three

+      possible greetings at session startup.  It indicates that the

+      session has already been authenticated by external means and thus

+      no LOGIN command is needed.

+

+   Example:    S: * PREAUTH IMAP4 server ready and logged in as Smith

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 41]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+7.1.5.  BYE Response

+

+   Data:       optional response code

+               human-readable text

+

+      The BYE response is always untagged, and indicates that the server

+      is about to close the connection.  The human-readable text may be

+      displayed to the user in a status report by the client.  The BYE

+      response may be sent as part of a normal logout sequence, or as a

+      panic shutdown announcement by the server.  It is also used by

+      some server implementations as an announcement of an inactivity

+      autologout.

+

+      This response is also used as one of three possible greetings at

+      session startup.  It indicates that the server is not willing to

+      accept a session from this client.

+

+   Example:    S: * BYE Autologout; idle for too long

+

+

+

+7.2.    Server Responses - Server and Mailbox Status

+

+   These responses are always untagged.  This is how server data are

+   transmitted from the server to the client, often as a result of a

+   command with the same name.

+

+7.2.1.  CAPABILITY Response

+

+   Data:       capability listing

+

+      The CAPABILITY response occurs as a result of a CAPABILITY

+      command.  The capability listing contains a space-separated

+      listing of capability names that the server supports.  The first

+      name in the capability listing MUST be the atom "IMAP4".

+

+      A capability name other than IMAP4 indicates that the server

+      supports an extension, revision, or amendment to the IMAP4

+      protocol.  Server responses MUST conform to this document until

+      the client issues a command that uses the associated capability.

+

+      Capability names MUST either begin with "X" or be standard or

+      standards-track IMAP4 extensions, revisions, or amendments

+      registered with IANA.  A server MUST NOT offer unregistered or

+      non-standard capability names, unless such names are prefixed with

+      an "X".

+

+

+

+

+

+Crispin                                                        [Page 42]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      Client implementations SHOULD NOT require any capability name

+      other than "IMAP4", and MUST ignore any unknown capability names.

+

+   Example:    S: * CAPABILITY IMAP4 XPIG-LATIN

+

+

+7.2.2.  LIST Response

+

+   Data:       name attributes

+               hierarchy delimiter

+               name

+

+      The LIST response occurs as a result of a LIST command.  It

+      returns a single name that matches the LIST specification.  There

+      may be multiple LIST responses for a single LIST command.

+

+      Four name attributes are defined:

+

+      \Noinferiors   It is not possible for any child levels of

+                     hierarchy to exist under this name; no child levels

+                     exist now and none can be created in the future.

+

+      \Noselect      It is not possible to use this name as a selectable

+                     mailbox.

+

+      \Marked        The mailbox has been marked "interesting" by the

+                     server; the mailbox probably contains messages that

+                     have been added since the last time the mailbox was

+                     selected.

+

+      \Unmarked      The mailbox does not contain any additional

+                     messages since the last time the mailbox was

+                     selected.

+

+      If it is not feasible for the server to determine whether the

+      mailbox is "interesting" or not, or if the name is a \Noselect

+      name, the server should not send either \Marked or \Unmarked.

+

+      The hierarchy delimiter is a character used to delimit levels of

+      hierarchy in a mailbox name.  A client may use it to create child

+      mailboxes, and to search higher or lower levels of naming

+      hierarchy.  All children of a top-level hierarchy node must use

+      the same separator character.  A NIL hierarchy delimiter means

+      that no hierarchy exists; the name is a "flat" name.

+

+

+

+

+

+

+

+Crispin                                                        [Page 43]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      The name represents an unambiguous left-to-right hierarchy, and

+      MUST be valid for use as a reference in LIST and LSUB commands.

+      Unless \Noselect is indicated, the name must also be valid as an

+      argument for commands, such as SELECT, that accept mailbox names.

+

+   Example:    S: * LIST (\Noselect) "/" ~/Mail/foo

+

+

+7.2.3.  LSUB Response

+

+   Data:       name attributes

+               hierarchy delimiter

+               name

+

+      The LSUB response occurs as a result of an LSUB command.  It

+      returns a single name that matches the LSUB specification.  There

+      may be multiple LSUB responses for a single LSUB command.  The

+      data is identical in format to the LIST response.

+

+   Example:    S: * LSUB () "." #news.comp.mail.misc

+

+

+7.2.4.  SEARCH Response

+

+   Data:       zero or more numbers

+

+      The SEARCH response occurs as a result of a SEARCH or UID SEARCH

+      command.  The number(s) refer to those messages that match the

+      search criteria.  For SEARCH, these are message sequence numbers;

+      for UID SEARCH, these are unique identifiers.  Each number is

+      delimited by a space.

+

+   Example:    S: * SEARCH 2 3 6

+

+

+7.2.5.  FLAGS Response

+

+   Data:       flag parenthesized list

+

+      The FLAGS response occurs as a result of a SELECT or EXAMINE

+      command.  The flag parenthesized list identifies the flags (at a

+      minimum, the system-defined flags) that are applicable for this

+      mailbox.  Flags other than the system flags may also exist,

+      depending on server implementation.

+

+      The update from the FLAGS response MUST be recorded by the client.

+

+   Example:    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

+

+

+

+Crispin                                                        [Page 44]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+7.3.    Server Responses - Message Status

+

+   These responses are always untagged.  This is how message data are

+   transmitted from the server to the client, often as a result of a

+   command with the same name.  Immediately following the "*" token is a

+   number that represents either a message sequence number or a message

+   count.

+

+7.3.1.  EXISTS Response

+

+   Data:       none

+

+      The EXISTS response reports the number of messages in the mailbox.

+      This response occurs as a result of a SELECT or EXAMINE command,

+      and if the size of the mailbox changes (e.g. new mail).

+

+      The update from the EXISTS response MUST be recorded by the

+      client.

+

+   Example:    S: * 23 EXISTS

+

+

+7.3.2.  RECENT Response

+

+   Data:       none

+

+      The RECENT response reports the number of messages that have

+      arrived since the previous time a SELECT command was done on this

+      mailbox.  This response occurs as a result of a SELECT or EXAMINE

+      command, and if the size of the mailbox changes (e.g. new mail).

+

+      The update from the RECENT response MUST be recorded by the

+      client.

+

+   Example:    S: * 5 RECENT

+

+

+7.3.3.  EXPUNGE Response

+

+   Data:       none

+

+      The EXPUNGE response reports that the specified message sequence

+      number has been permanently removed from the mailbox.  The message

+      sequence number for each successive message in the mailbox is

+      immediately decremented by 1, and this decrement is reflected in

+      message sequence numbers in subsequent responses (including other

+      untagged EXPUNGE responses).

+

+

+

+

+Crispin                                                        [Page 45]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      As a result of the immediate decrement rule, message sequence

+      numbers that appear in a set of successive EXPUNGE responses

+      depend upon whether the messages are removed starting from lower

+      numbers to higher numbers, or from higher numbers to lower

+      numbers.  For example, if the last 5 messages in a 9-message

+      mailbox are expunged; a "lower to higher" server will send five

+      untagged EXPUNGE responses for message sequence number 5, whereas

+      a "higher to lower server" will send successive untagged EXPUNGE

+      responses for message sequence numbers 9, 8, 7, 6, and 5.

+

+      An EXPUNGE response MUST NOT be sent when no command is in

+      progress; nor while responding to a FETCH, STORE, or SEARCH

+      command.  This rule is necessary to prevent a loss of

+      synchronization of message sequence numbers between client and

+      server.

+

+      The update from the EXPUNGE response MUST be recorded by the

+      client.

+

+   Example:    S: * 44 EXPUNGE

+

+

+7.3.4.  FETCH Response

+

+   Data:       message data

+

+      The FETCH response returns data about a message to the client.

+      The data are pairs of data item names and their values in

+      parentheses.  This response occurs as the result of a FETCH or

+      STORE command, as well as by unilateral server decision (e.g. flag

+      updates).

+

+      The current data items are:

+

+      BODY           A form of BODYSTRUCTURE without extension data.

+

+      BODY[section]  A string expressing the body contents of the

+                     specified section.  The string should be

+                     interpreted by the client according to the content

+                     transfer encoding, body type, and subtype.

+

+                     8-bit textual data is permitted if a character set

+                     identifier is part of the body parameter

+                     parenthesized list for this section.

+

+                     Non-textual data such as binary data must be

+                     transfer encoded into a textual form such as BASE64

+                     prior to being sent to the client.  To derive the

+

+

+

+Crispin                                                        [Page 46]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+                     original binary data, the client must decode the

+                     transfer encoded string.

+

+      BODYSTRUCTURE  A parenthesized list that describes the body

+                     structure of a message.  This is computed by the

+                     server by parsing the [RFC-822] header and body

+                     into the component parts, defaulting various fields

+                     as necessary.

+

+                     Multiple parts are indicated by parenthesis

+                     nesting.  Instead of a body type as the first

+                     element of the parenthesized list there is a nested

+                     body.  The second element of the parenthesized list

+                     is the multipart subtype (mixed, digest, parallel,

+                     alternative, etc.).

+

+                     Extension data follows the multipart subtype.

+                     Extension data is never returned with the BODY

+                     fetch, but may be returned with a BODYSTRUCTURE

+                     fetch.  Extension data, if present, must be in the

+                     defined order.

+

+                     The extension data of a multipart body part are in

+                     the following order:

+

+                     body parameter parenthesized list

+                        A parenthesized list of attribute/value pairs

+                        [e.g. (foo bar baz rag) where "bar" is the value

+                        of "foo" and "rag" is the value of "baz"] as

+                        defined in [MIME-1].

+

+                     Any following extension data are not yet defined in

+                     this version of the protocol.  Such extension data

+                     may consist of zero or more NILs, strings, numbers,

+                     or potentially nested parenthesized lists of such

+                     data.  Client implementations that do a

+                     BODYSTRUCTURE fetch MUST be prepared to accept such

+                     extension data.  Server implementations MUST NOT

+                     send such extension data until it has been defined

+                     by a revision of this protocol.

+

+                     The basic fields of a non-multipart body part are

+                     in the following order:

+

+                     body type

+                        A string giving the content type name as defined

+                        in [MIME-1].

+

+

+

+

+Crispin                                                        [Page 47]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+                     body subtype

+                        A string giving the content subtype name as

+                        defined in [MIME-1].

+

+                     body parameter parenthesized list

+                        A parenthesized list of attribute/value pairs

+                        [e.g. (foo bar baz rag) where "bar" is the value

+                        of "foo" and "rag" is the value of "baz"] as

+                        defined in [MIME-1].

+

+                     body id

+                        A string giving the content id as defined in

+                        [MIME-1].

+

+                     body description

+                        A string giving the content description as

+                        defined in [MIME-1].

+

+                     body encoding

+                        A string giving the content transfer encoding as

+                        defined in [MIME-1].

+

+                     body size

+                        A number giving the size of the body in octets.

+                        Note that this size is the size in its transfer

+                        encoding and not the resulting size after any

+                        decoding.

+

+                     A body type of type MESSAGE and subtype RFC822

+                     contains, immediately after the basic fields, the

+                     envelope structure, body structure, and size in

+                     text lines of the encapsulated message.

+

+                     A body type of type TEXT contains, immediately

+                     after the basic fields, the size of the body in

+                     text lines.  Note that this size is the size in its

+                     transfer encoding and not the resulting size after

+                     any decoding.

+

+                     Extension data follows the basic fields and the

+                     type-specific fields listed above.  Extension data

+                     is never returned with the BODY fetch, but may be

+                     returned with a BODYSTRUCTURE fetch.  Extension

+                     data, if present, must be in the defined order.

+

+                     The extension data of a non-multipart body part are

+                     in the following order:

+

+

+

+

+Crispin                                                        [Page 48]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+                     body MD5

+                        A string giving the content MD5 value as defined

+                        in [MIME-1].

+

+                     Any following extension data are not yet defined in

+                     this version of the protocol, and would be as

+                     described above under multipart extension data.

+

+      ENVELOPE       A parenthesized list that describes the envelope

+                     structure of a message.  This is computed by the

+                     server by parsing the [RFC-822] header into the

+                     component parts, defaulting various fields as

+                     necessary.

+

+                     The fields of the envelope structure are in the

+                     following order: date, subject, from, sender,

+                     reply-to, to, cc, bcc, in-reply-to, and message-id.

+                     The date, subject, in-reply-to, and message-id

+                     fields are strings.  The from, sender, reply-to,

+                     to, cc, and bcc fields are parenthesized lists of

+                     address structures.

+

+                     An address structure is a parenthesized list that

+                     describes an electronic mail address.  The fields

+                     of an address structure are in the following order:

+                     personal name, [SMTP] at-domain-list (source

+                     route), mailbox name, and host name.

+

+                     [RFC-822] group syntax is indicated by a special

+                     form of address structure in which the host name

+                     field is NIL.  If the mailbox name field is also

+                     NIL, this is an end of group marker (semi-colon in

+                     RFC 822 syntax).  If the mailbox name field is

+                     non-NIL, this is a start of group marker, and the

+                     mailbox name field holds the group name phrase.

+

+                     Any field of an envelope or address structure that

+                     is not applicable is presented as NIL.  Note that

+                     the server must default the reply-to and sender

+                     fields from the from field; a client is not

+                     expected to know to do this.

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 49]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      FLAGS          A parenthesized list of flags that are set for this

+                     message.  This may include keywords as well as the

+                     following system flags:

+

+                     \Seen       Message has been read

+

+                     \Answered   Message has been answered

+

+                     \Flagged    Message is "flagged" for urgent/special

+                                 attention

+

+                     \Deleted    Message is "deleted" for removal by

+                                 later EXPUNGE

+

+                     \Draft      Message has not completed composition

+                                 (marked as a draft).

+

+                     as well as the following special flag, which may be

+                     fetched but not stored:

+

+                     \Recent     Message has arrived since the previous

+                                 time this mailbox was selected.

+

+      INTERNALDATE   A string containing the date and time of final

+                     delivery of the message as defined by [SMTP].

+

+      RFC822         A string expressing the message in [RFC-822]

+                     format.  The header portion of the message must be

+                     7-bit.  8-bit characters are permitted only in the

+                     non-header portion of the message only if there are

+                     [MIME-1] data in the message that identify the

+                     character set of the message.

+

+      RFC822.HEADER  A string expressing the [RFC-822] format header of

+                     the message, including the delimiting blank line

+                     between the header and the body.  The entire string

+                     must be 7-bit; 8-bit characters are not permitted

+                     in headers.  RFC822.HEADER is used to return data

+                     for the RFC822.HEADER, RFC822.HEADER.LINES, and

+                     RFC822.HEADER.LINES.NOT FETCH data items.  Note

+                     that a blank line is always included regardless of

+                     header line restrictions.

+

+      RFC822.SIZE    A number expressing the number of octets in the

+                     message in [RFC-822] format.

+

+

+

+

+

+

+Crispin                                                        [Page 50]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      RFC822.TEXT    A string expressing the text body of the message,

+                     omitting the [RFC-822] header.  8-bit characters

+                     are permitted only if there are [MIME-1] data in

+                     the message that identify the character set of the

+                     message.

+

+      UID            A number expressing the unique identifier of the

+                     message.

+

+

+   Example:    S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

+

+

+7.3.5.  Obsolete Responses

+

+   In addition to the responses listed in here, client implementations

+   MUST accept and implement the obsolete responses described in

+   Appendix B.

+

+

+

+7.4.    Server Responses - Command Continuation Request

+

+   The command completion request response is indicated by a "+" token

+   instead of a tag.  This form of response indicates that the server is

+   ready to accept the continuation of a command from the client.  The

+   remainder of this response is a line of text.

+

+   This response is used in the AUTHORIZATION command to transmit server

+   data to the client, and request additional client data.  This

+   response is also used if an argument to any command is a literal.

+

+   The client is not permitted to send the octets of the literal unless

+   the server indicates that it expects it.  This permits the server to

+   process commands and reject errors on a line-by-line basis.  The

+   remainder of the command, including the CRLF that terminates a

+   command, follows the octets of the literal.  If there are any

+   additional command arguments the literal octets are followed by a

+   space and those arguments.

+

+   Example:    C: A001 LOGIN {11}

+               S: + Ready for additional command text

+               C: FRED FOOBAR {7}

+               S: + Ready for additional command text

+               C: fat man

+               S: A001 OK LOGIN completed

+               C: A044 BLURDYBLOOP {102856}

+               S: A044 BAD No such command as "BLURDYBLOOP"

+

+

+

+Crispin                                                        [Page 51]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+8.      Sample IMAP4 session

+

+   The following is a transcript of an IMAP4 session.  A long line in

+   this sample is broken for editorial clarity.

+

+   S:   * OK IMAP4 Service Ready

+   C:   a001 login mrc secret

+   S:   a001 OK LOGIN completed

+   C:   a002 select inbox

+   S:   * 18 EXISTS

+   S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

+   S:   * 2 RECENT

+   S:   * OK [UNSEEN 17] Message 17 is the first unseen message

+   S:   * OK [UIDVALIDITY 3857529045] UIDs valid

+   S:   a002 OK [READ-WRITE] SELECT completed

+   C:   a003 fetch 12 full

+   S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"

+         RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"

+         "IMAP4 WG mtg summary and minutes"

+         (("Terry Gray" NIL "gray" "cac.washington.edu"))

+         (("Terry Gray" NIL "gray" "cac.washington.edu"))

+         (("Terry Gray" NIL "gray" "cac.washington.edu"))

+         ((NIL NIL "imap" "cac.washington.edu"))

+         ((NIL NIL "minutes" "CNRI.Reston.VA.US")

+         ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL

+         "<B27397-0100000@cac.washington.edu>")

+          BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))

+   S:    a003 OK FETCH completed

+   C:    a004 fetch 12 rfc822.header

+   S:    * 12 FETCH (RFC822.HEADER {346}

+   S:    Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)

+   S:    From: Terry Gray <gray@cac.washington.edu>

+   S:    Subject: IMAP4 WG mtg summary and minutes

+   S:    To: imap@cac.washington.edu

+   S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>

+   S:    Message-Id: <B27397-0100000@cac.washington.edu>

+   S:    MIME-Version: 1.0

+   S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

+   S:

+   S:    )

+   S:    a004 OK FETCH completed

+   C:    a005 store 12 +flags \deleted

+   S:    * 12 FETCH (FLAGS (\Seen \Deleted))

+   S:    a005 OK +FLAGS completed

+   C:    a006 logout

+   S:    * BYE IMAP4 server terminating connection

+   S:    a006 OK LOGOUT completed

+

+

+

+

+Crispin                                                        [Page 52]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+9.      Formal Syntax

+

+   The following syntax specification uses the augmented Backus-Naur

+   Form (BNF) notation as specified in [RFC-822] with one exception; the

+   delimiter used with the "#" construct is a single space (SPACE) and

+   not a comma.

+

+   Except as noted otherwise, all alphabetic characters are

+   case-insensitive.  The use of upper or lower case characters to

+   define token strings is for editorial clarity only.  Implementations

+   MUST accept these strings in a case-insensitive fashion.

+

+   Syntax marked as obsolete may be encountered with implementations

+   written for an earlier version of this protocol (e.g. IMAP2).  New

+   implementations SHOULD accept obsolete syntax as input, but MUST NOT

+   otherwise use such syntax.

+

+   address         ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox

+                       SPACE addr_host ")"

+

+   addr_adl        ::= nstring

+

+   addr_host       ::= nstring

+                       ;; NIL indicates [RFC-822] group syntax

+

+   addr_mailbox    ::= nstring

+                       ;; NIL indicates end of [RFC-822] group; if

+                       ;; non-NIL and addr_host is NIL, holds

+                       ;; [RFC-822] group name

+

+   addr_name       ::= nstring

+

+   alpha           ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /

+                       "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /

+                       "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /

+                       "Y" / "Z" /

+                       "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /

+                       "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /

+                       "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /

+                       "y" / "z" /

+                       ;; Case-sensitive

+

+   append          ::= "APPEND" SPACE mailbox [SPACE flag_list]

+                       [SPACE date_time] SPACE literal

+

+   astring         ::= atom / string

+

+

+

+

+

+Crispin                                                        [Page 53]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   atom            ::= 1*ATOM_CHAR

+

+   ATOM_CHAR       ::= <any CHAR except atom_specials>

+

+   atom_specials   ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards /

+                       quoted_specials

+

+   authenticate    ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)

+

+   auth_type       ::= atom

+

+   base64          ::= *(4base64_char) [base64_terminal]

+

+   base64_char     ::= alpha / digit / "+" / "/"

+

+   base64_terminal ::= (2base64_char "==") / (3base64_char "=")

+

+   body            ::= "(" body_type_1part / body_type_mpart ")"

+

+   body_extension  ::= nstring / number / "(" 1#body_extension ")"

+                       ;; Future expansion.  Client implementations

+                       ;; MUST accept body_extension fields.  Server

+                       ;; implementations MUST NOT generate

+                       ;; body_extension fields except as defined by

+                       ;; future standard or standards-track

+                       ;; revisions of this specification.

+

+   body_ext_1part  ::= body_fld_md5 [SPACE 1#body_extension]

+                       ;; MUST NOT be returned on non-extensible

+                       ;; "BODY" fetch

+

+   body_ext_mpart  ::= body_fld_param [SPACE 1#body_extension]]

+                       ;; MUST NOT be returned on non-extensible

+                       ;; "BODY" fetch

+

+   body_fields     ::= body_fld_param SPACE body_fld_id SPACE

+                       body_fld_desc SPACE body_fld_enc SPACE

+                       body_fld_octets

+

+   body_fld_desc   ::= nstring

+

+   body_fld_enc    ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/

+                       "QUOTED-PRINTABLE") <">) / string

+

+   body_fld_id     ::= nstring

+

+   body_fld_lines  ::= number

+

+

+

+

+Crispin                                                        [Page 54]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   body_fld_md5    ::= nstring

+

+   body_fld_octets ::= number

+

+   body_fld_param  ::= "(" 1#(string string) ")" / nil

+

+   body_fld_subtyp ::= string

+

+   body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)

+                       [SPACE body_ext_1part]

+

+   body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /

+                       "MESSAGE" / "VIDEO") <">) / string) SPACE

+                       body_fld_subtyp SPACE body_fields

+                       ;; MESSAGE subtype MUST NOT be "RFC822"

+

+   body_type_mpart ::= 1*body SPACE body_fld_subtyp

+                       [SPACE body_ext_mpart]

+

+   body_type_msg   ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE

+                       body_fields SPACE envelope SPACE body SPACE

+                       body_fld_lines

+

+   body_type_text  ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE

+                        body_fields SPACE body_fld_lines

+

+   capability      ::= atom

+                       ;; Must begin with "X" or be registered with

+                       ;; IANA as standard or standards-track

+

+   capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]

+

+   CHAR            ::= <any 7-bit US-ASCII character except NUL,

+                        0x01 - 0x7f>

+

+   CHAR8           ::= <any 8-bit octet except NUL, 0x01 - 0xff>

+

+   command         ::= tag SPACE (command_any / command_auth /

+                       command_nonauth / command_select) CRLF

+                       ;; Modal based on state

+

+   command_any     ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command

+                       ;; Valid in all states

+

+   command_auth    ::= append / create / delete / examine / find / list /

+                       lsub / rename / select / subscribe / unsubscribe /

+                       ;; Valid only in Authenticated or Selected state

+

+

+

+

+Crispin                                                        [Page 55]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   command_nonauth ::= login / authenticate

+                       ;; Valid only when in Non-Authenticated state

+

+   command_select  ::= "CHECK" / "CLOSE" / "EXPUNGE" /

+                        copy / fetch / partial / store / uid / search

+                       ;; Valid only when in Selected state

+

+   continue_req    ::= "+" SPACE (resp_text / base64)

+

+   copy            ::= "COPY" SPACE set SPACE mailbox

+

+   CR              ::= <ASCII CR, carriage return, 0x0C>

+

+   create          ::= "CREATE" SPACE mailbox

+                       ;; Use of INBOX gives a NO error

+

+   CRLF            ::= CR LF

+

+   CTL             ::= <any ASCII control character and DEL,

+                        0x00 - 0x1f, 0x7f>

+

+   date            ::= date_text / <"> date_text <">

+

+   date_day        ::= 1*2digit

+                       ;; Day of month

+

+   date_day_fixed  ::= (SPACE digit) / 2digit

+                       ;; Fixed-format version of date_day

+

+   date_month      ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /

+                       "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"

+

+   date_text       ::= date_day "-" date_month "-" (date_year /

+                       date_year_old)

+

+   date_year       ::= 4digit

+

+   date_year_old   ::= 2digit

+                       ;; OBSOLETE, (year - 1900)

+

+   date_time       ::= <"> (date_time_new / date_time_old) <">

+

+   date_time_new   ::= date_day_fixed "-" date_month "-" date_year

+                       SPACE time SPACE zone

+

+   date_time_old   ::= date_day_fixed "-" date_month "-" date_year_old

+                       SPACE time "-" zone_old

+                       ;; OBSOLETE

+

+

+

+Crispin                                                        [Page 56]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   delete          ::= "DELETE" SPACE mailbox

+                       ;; Use of INBOX gives a NO error

+

+   digit           ::= "0" / digit_nz

+

+   digit_nz        ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /

+                       "9"

+

+   envelope        ::= "(" env_date SPACE env_subject SPACE env_from

+                       SPACE env_sender SPACE env_reply-to SPACE env_to

+                       SPACE env_cc SPACE env_bcc SPACE env_in-reply-to

+                       SPACE env_message-id ")"

+

+   env_bcc         ::= "(" 1*address ")" / nil

+

+   env_cc          ::= "(" 1*address ")" / nil

+

+   env_date        ::= nstring

+

+   env_from        ::= "(" 1*address ")" / nil

+

+   env_in-reply-to ::= nstring

+

+   env_message-id  ::= nstring

+

+   env_reply-to    ::= "(" 1*address ")" / nil

+

+   env_sender      ::= "(" 1*address ")" / nil

+

+   env_subject     ::= nstring

+

+   env_to          ::= "(" 1*address ")" / nil

+

+   examine         ::= "EXAMINE" SPACE mailbox

+

+   fetch           ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /

+                       "FAST" / fetch_att / "(" 1#fetch_att ")")

+

+   fetch_att       ::= "BODY" / "BODYSTRUCTURE" /

+                       "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" /

+                       "FLAGS" / "INTERNALDATE" / "UID" /

+                       "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" /

+                       (".HEADER" [".LINES" [".NOT"] SPACE header_list])

+

+   find            ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE

+                       list_mailbox

+                       ;; OBSOLETE

+

+

+

+

+Crispin                                                        [Page 57]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   flag            ::= "\Answered" / "\Flagged" / "\Deleted" /

+                       "\Seen" / "\Draft" / flag_keyword  /

+                       flag_extension

+

+   flag_extension  ::= "\" atom

+                       ;; Future expansion.  Client implementations

+                       ;; MUST accept flag_extension flags.  Server

+                       ;; implementations MUST NOT generate

+                       ;; flag_extension flags except as defined by

+                       ;; future standard or standards-track

+                       ;; revisions of this specification.

+

+   flag_keyword    ::= atom

+

+   flag_list       ::= "(" #flag ")"

+

+   greeting        ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF

+

+   header_line     ::= astring

+

+   header_list     ::= "(" 1#header_line ")"

+

+   LF              ::= <ASCII LF, line feed, 0x0A>

+

+   list            ::= "LIST" SPACE mailbox SPACE list_mailbox

+

+   list_mailbox    ::= 1*(ATOM_CHAR / list_wildcards) / string

+

+   list_wildcards  ::= "%" / "*"

+

+   literal         ::= "{" number "}" CRLF *CHAR8

+                       ;; Number represents the number of CHAR8 octets

+

+   login           ::= "LOGIN" SPACE userid SPACE password

+

+   lsub            ::= "LSUB" SPACE mailbox SPACE list_mailbox

+

+   mailbox         ::= "INBOX" / astring

+                       ;; INBOX is case-insensitive; other names may be

+                       ;; case-sensitive depending on implementation.

+

+   mailbox_data    ::=  "FLAGS" SPACE flag_list /

+                        "LIST" SPACE mailbox_list /

+                        "LSUB" SPACE mailbox_list /

+                        "MAILBOX" SPACE text /

+                        "SEARCH" [SPACE 1#nz_number] /

+                        number SPACE "EXISTS" / number SPACE "RECENT"

+

+

+

+

+Crispin                                                        [Page 58]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   mailbox_list    ::= "(" #("\Marked" / "\Noinferiors" /

+                       "\Noselect" / "\Unmarked" / flag_extension) ")"

+                       SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox

+

+   message_data    ::= nz_number SPACE ("EXPUNGE" /

+                       ("FETCH" SPACE msg_fetch) / msg_obsolete)

+

+   msg_fetch       ::= "(" 1#("BODY" SPACE body /

+                       "BODYSTRUCTURE" SPACE body /

+                       "BODY[" section "]" SPACE nstring /

+                       "ENVELOPE" SPACE envelope /

+                       "FLAGS" SPACE "(" #(flag / "\Recent") ")" /

+                       "INTERNALDATE" SPACE date_time /

+                       "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /

+                       "RFC822.SIZE" SPACE number /

+                       "UID" SPACE uniqueid) ")"

+

+   msg_obsolete    ::= "COPY" / ("STORE" SPACE msg_fetch)

+                       ;; OBSOLETE untagged data responses

+

+   nil             ::= "NIL"

+

+   nstring         ::= string / nil

+

+   number          ::= 1*digit

+                       ;; Unsigned 32-bit integer

+                       ;; (0 <= n < 4,294,967,296)

+

+   nz_number       ::= digit_nz *digit

+                       ;; Non-zero unsigned 32-bit integer

+                       ;; (0 < n < 4,294,967,296)

+

+   partial         ::= "PARTIAL" SPACE nz_number SPACE

+                       ("BODY" [".PEEK"] "[" section "]" /

+                       "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER")

+                       SPACE number SPACE number

+

+   password        ::= astring

+

+   quoted          ::= <"> *QUOTED_CHAR <">

+

+   QUOTED_CHAR     ::= <any TEXT_CHAR except quoted_specials> /

+                       "\" quoted_specials

+

+   quoted_specials ::= <"> / "\"

+

+   rename          ::= "RENAME" SPACE mailbox SPACE mailbox

+                       ;; Use of INBOX as a destination gives a NO error

+

+

+

+Crispin                                                        [Page 59]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   response        ::= *response_data response_done

+

+   response_data   ::= "*" SPACE (resp_cond_state / resp_cond_bye /

+                       mailbox_data / message_data / capability_data)

+                       CRLF

+

+   response_done   ::= response_tagged / response_fatal

+

+   response_fatal  ::= "*" SPACE resp_cond_bye CRLF

+

+   response_tagged ::= tag SPACE resp_cond_state CRLF

+

+   resp_cond_auth  ::= ("OK" / "PREAUTH") SPACE resp_text

+                       ;; Authentication condition

+

+   resp_cond_bye   ::= "BYE" SPACE resp_text

+                       ;; Server will disconnect condition

+

+   resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text

+                       ;; Status condition

+

+   resp_text       ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)

+

+   resp_text_code  ::= "ALERT" / "PARSE" /

+                       "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /

+                       "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /

+                       "UIDVALIDITY" SPACE nz_number /

+                       "UNSEEN" SPACE nz_number /

+                       atom [SPACE 1*<any TEXT_CHAR except "]">]

+

+   search          ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]

+                       search_criteria

+                       ;; Character set must be registered with IANA

+                       ;; as a MIME character set

+

+   search_criteria ::= 1#search_key

+

+   search_key      ::= search_new / search_old

+

+   search_new      ::= "DRAFT" /

+                       "HEADER" SPACE header_line SPACE astring /

+                       "LARGER" SPACE number / "NOT" SPACE search_key /

+                       "OR" SPACE search_key SPACE search_key /

+                       "SENTBEFORE" SPACE date / "SENTON" SPACE date /

+                       "SENTSINCE" SPACE date / "SMALLER" SPACE number /

+                       "UID" SPACE set / "UNDRAFT" / set /

+                       "(" search_criteria ")"

+                       ;; New in IMAP4

+

+

+

+Crispin                                                        [Page 60]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   search_old      ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /

+                       "BEFORE" SPACE date / "BODY" SPACE astring /

+                       "CC" SPACE astring / "DELETED" / "FLAGGED" /

+                       "FROM" SPACE astring /

+                       "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /

+                       "ON" SPACE date / "RECENT" / "SEEN" /

+                       "SINCE" SPACE date / "SUBJECT" SPACE astring /

+                       "TEXT" SPACE astring / "TO" SPACE astring /

+                       "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /

+                       "UNKEYWORD" SPACE flag_keyword / "UNSEEN"

+                       ;; Defined in [IMAP2]

+

+   section         ::= "0" / nz_number ["." section]

+

+   select          ::= "SELECT" SPACE mailbox

+

+   sequence_num    ::= nz_number / "*"

+                       ;; * is the largest number in use.  For message

+                       ;; sequence numbers, it is the number of messages

+                       ;; in the mailbox.  For unique identifiers, it is

+                       ;; the unique identifier of the last message in

+                       ;; the mailbox.

+

+   set             ::= sequence_num / (sequence_num ":" sequence_num) /

+                       (set "," set)

+                       ;; Identifies a set of messages.  For message

+                       ;; sequence numbers, these are consecutive

+                       ;; numbers from 1 to the number of messages in

+                       ;; the mailbox

+                       ;; Comma delimits individual numbers, colon

+                       ;; delimits between two numbers inclusive.

+                       ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,

+                       ;; 14,15 for a mailbox with 15 messages.

+

+   SPACE           ::= <ASCII SP, space, 0x20>

+

+   store           ::= "STORE" SPACE set SPACE store_att_flags

+

+   store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE

+                       (flag_list / #flag)

+

+   string          ::= quoted / literal

+

+   subscribe       ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs

+

+   subscribe_obs   ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox

+                       ;;OBSOLETE

+

+

+

+

+Crispin                                                        [Page 61]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   tag             ::= 1*<any ATOM_CHAR except "+">

+

+   text            ::= 1*TEXT_CHAR

+

+   text_mime2       ::= "=?" <charset> "?" <encoding> "?"

+                        <encoded-text> "?="

+                        ;; Syntax defined in [MIME-2]

+

+   TEXT_CHAR       ::= <any CHAR except CR and LF>

+

+   time            ::= 2digit ":" 2digit ":" 2digit

+                       ;; Hours minutes seconds

+

+   uid             ::= "UID" SPACE (copy / fetch / search / store)

+                       ;; Unique identifiers used instead of message

+                       ;; sequence numbers

+

+   uniqueid        ::= nz_number

+                       ;; Strictly ascending

+

+   unsubscribe     ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs

+

+   unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox

+                       ;;OBSOLETE

+

+   userid          ::= astring

+

+   x_command       ::= "X" atom <experimental command arguments>

+

+   zone            ::= ("+" / "-") 4digit

+                       ;; Signed four-digit value of hhmm representing

+                       ;; hours and minutes west of Greenwich (that is,

+                       ;; (the amount that the given time differs from

+                       ;; Universal Time).  Subtracting the timezone

+                       ;; from the given time will give the UT form.

+                       ;; The Universal Time zone is "+0000".

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 62]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   zone_old        ::= "UT" / "GMT" / "Z" /                ;; +0000

+                       "AST" / "EDT" /                     ;; -0400

+                       "EST" / "CDT" /                     ;; -0500

+                       "CST" / "MDT" /                     ;; -0600

+                       "MST" / "PDT" /                     ;; -0700

+                       "PST" / "YDT" /                     ;; -0800

+                       "YST" / "HDT" /                     ;; -0900

+                       "HST" / "BDT" /                     ;; -1000

+                       "BST" /                             ;; -1100

+                       "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6

+                       "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12

+                       "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6

+                       "T" / "U" / "V" / "W" / "X" / "Y"   ;; -7 to -12

+                       ;; OBSOLETE

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 63]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+10.     Author's Note

+

+   This document is a revision or rewrite of earlier documents, and

+   supercedes the protocol specification in those documents: IMAP4

+   Internet drafts, the IMAP2bis Internet drafts, unpublished

+   IMAP2bis.TXT document, RFC 1176, and RFC 1064.

+

+

+11.     Security Considerations

+

+   IMAP4 protocol transactions, including electronic mail data, are sent

+   in the clear over the network unless the optional privacy protection

+   is negotiated in the AUTHENTICATE command.

+

+   A server error message for an AUTHENTICATE command which fails due to

+   invalid credentials should not detail why the credentials are

+   invalid.

+

+   Use of the LOGIN command sends passwords in the clear.  This can be

+   avoided by using the AUTHENTICATE command instead.

+

+   A server error message for a failing LOGIN command should not specify

+   that the user name, as opposed to the password, is invalid.

+

+   Additional security considerations are discussed in the section

+   discussing the AUTHENTICATE and LOGIN commands.

+

+

+12.     Author's Address

+

+   Mark R. Crispin

+   Networks and Distributed Computing, JE-30

+   University of Washington

+   Seattle, WA  98195

+

+   Phone: (206) 543-5762

+

+   EMail: MRC@CAC.Washington.EDU

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 64]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+Appendices

+

+A.      Obsolete Commands

+

+   The following commands are OBSOLETE.  It is NOT required to support

+   any of these commands in new server implementations.  These commands

+   are documented here for the benefit of implementors who may wish to

+   support them for compatibility with old client implementations.

+

+   The section headings of these commands are intended to correspond

+   with where they would be located in the main document if they were

+   not obsoleted.

+

+

+A.6.3.OBS.1.    FIND ALL.MAILBOXES Command

+

+   Arguments:  mailbox name with possible wildcards

+

+   Data:       untagged responses: MAILBOX

+

+   Result:     OK - find completed

+               NO - find failure: can't list that name

+               BAD - command unknown or arguments invalid

+

+      The FIND ALL.MAILBOXES command returns a subset of names from the

+      complete set of all names available to the user.  It returns zero

+      or more untagged MAILBOX replies.  The mailbox argument to FIND

+      ALL.MAILBOXES is similar to that for LIST with an empty reference,

+      except that the characters "%" and "?" match a single character.

+

+   Example:    C: A002 FIND ALL.MAILBOXES *

+               S: * MAILBOX blurdybloop

+               S: * MAILBOX INBOX

+               S: A002 OK FIND ALL.MAILBOXES completed

+

+

+A.6.3.OBS.2.    FIND MAILBOXES Command

+

+   Arguments:  mailbox name with possible wildcards

+

+   Data:       untagged responses: MAILBOX

+

+   Result:     OK - find completed

+               NO - find failure: can't list that name

+               BAD - command unknown or arguments invalid

+

+      The FIND MAILBOXES command returns a subset of names from the set

+      of names that the user has declared as being "active" or

+

+

+

+Crispin                                                        [Page 65]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+      "subscribed".  It returns zero or more untagged MAILBOX replies.

+      The mailbox argument to FIND MAILBOXES is similar to that for LSUB

+      with an empty reference, except that the characters "%" and "?"

+      match a single character.

+

+   Example:    C: A002 FIND MAILBOXES *

+               S: * MAILBOX blurdybloop

+               S: * MAILBOX INBOX

+               S: A002 OK FIND MAILBOXES completed

+

+

+A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command

+

+   Arguments:  mailbox name

+

+   Data:       no specific data for this command

+

+   Result:     OK - subscribe completed

+               NO - subscribe failure: can't subscribe to that name

+               BAD - command unknown or arguments invalid

+

+      The SUBSCRIBE MAILBOX command is identical in effect to the

+      SUBSCRIBE command.  A server which implements this command must be

+      able to distinguish between a SUBSCRIBE MAILBOX command and a

+      SUBSCRIBE command with a mailbox name argument of "MAILBOX".

+

+   Example:    C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime

+               S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime

+               completed

+               C: A003 SUBSCRIBE MAILBOX

+               S: A003 OK SUBSCRIBE to MAILBOX completed

+

+

+A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command

+

+   Arguments:  mailbox name

+

+   Data:       no specific data for this command

+

+   Result:     OK - unsubscribe completed

+               NO - unsubscribe failure: can't unsubscribe that name

+               BAD - command unknown or arguments invalid

+

+      The UNSUBSCRIBE MAILBOX command is identical in effect to the

+      UNSUBSCRIBE command.  A server which implements this command must

+      be able to distinguish between a UNSUBSCRIBE MAILBOX command and

+      an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".

+

+

+

+

+Crispin                                                        [Page 66]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+   Example:    C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime

+               S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime

+               completed

+               C: A003 UNSUBSCRIBE MAILBOX

+               S: A003 OK UNSUBSCRIBE from MAILBOX completed

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 67]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+B.      Obsolete Responses

+

+   The following responses are OBSOLETE.  Except as noted below, these

+   responses MUST NOT be transmitted by new server implementations.

+

+   The section headings of these responses are intended to correspond

+   with where they would be located in the main document if they were

+   not obsoleted.

+

+

+B.7.2.OBS.1.    MAILBOX Response

+

+   Data:       name

+

+      The MAILBOX response MUST NOT be transmitted by server

+      implementations except in response to the obsolete FIND MAILBOXES

+      and FIND ALL.MAILBOXES commands.  Client implementations that do

+      not use these commands MAY ignore this response.  It is documented

+      here for the benefit of implementors who may wish to support it

+      for compatibility with old client implementations.

+

+      This response occurs as a result of the FIND MAILBOXES and FIND

+      ALL.MAILBOXES commands.  It returns a single name that matches the

+      FIND specification.  There are no attributes or hierarchy

+      delimiter.

+

+   Example:    S: * MAILBOX blurdybloop

+

+

+B.7.3.OBS.1.    COPY Response

+

+   Data:       none

+

+      The COPY response MUST NOT be transmitted by new server

+      implementations.  Client implementations MUST ignore the COPY

+      response.  It is documented here for the benefit of client

+      implementors who may encounter this response from old server

+      implementations.

+

+      In some experimental versions of this protocol, this response was

+      returned in response to a COPY command to indicate on a

+      per-message basis that the message was copied successfully.

+

+   Example:    S: * 44 COPY

+

+

+

+

+

+

+

+Crispin                                                        [Page 68]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+B.7.3.OBS.2.    STORE Response

+

+   Data:       message data

+

+      The STORE response MUST NOT be transmitted by new server

+      implementations.  Client implementations MUST treat the STORE

+      response as equivalent to the FETCH response.  It is documented

+      here for the benefit of client implementors who may encounter this

+      response from old server implementations.

+

+      In some experimental versions of this protocol, this response was

+      returned instead of FETCH in response to a STORE command to report

+      the new value of the flags.

+

+   Example:    S: * 69 STORE (FLAGS (\Deleted))

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 69]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+C.      References

+

+

+   [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.

+   Carnegie-Mellon University, December 1994.

+

+   [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and

+   IMAP2bis", RFC 1732, University of Washington, December 1994.

+

+   [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected

+   IMAP4 Clients", Work in Progress.

+

+   [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in

+   IMAP4", RFC 1733, University of Washington, December 1994.

+

+   [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work

+   in Progress.

+

+   [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",

+   RFC 1176, University of Washington, August 1990.

+

+   [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in

+   Progress.

+

+   [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet

+   Mail Extensions) Part One: Mechanisms for Specifying and Describing

+   the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,

+   September 1993.

+

+   [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)

+   Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522,

+   University of Tennessee, September 1993.

+

+   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text

+   Messages", STD 11, RFC 822, University of Delaware, August 1982.

+

+   [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10,

+   RFC 821, USC/Information Sciences Institute, August 1982.

+

+

+

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 70]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+E.      IMAP4 Keyword Index

+

+

+       +FLAGS <flag list> (store command data item) ...............   34

+       +FLAGS.SILENT <flag list> (store command data item) ........   34

+       -FLAGS <flag list> (store command data item) ...............   34

+       -FLAGS.SILENT <flag list> (store command data item) ........   34

+       ALERT (response code) ......................................   39

+       ALL (fetch item) ...........................................   29

+       ALL (search key) ...........................................   27

+       ANSWERED (search key) ......................................   27

+       APPEND (command) ...........................................   22

+       AUTHENTICATE (command) .....................................   12

+       BAD (response) .............................................   41

+       BCC <string> (search key) ..................................   27

+       BEFORE <date> (search key) .................................   27

+       BODY (fetch item) ..........................................   29

+       BODY (fetch result) ........................................   46

+       BODY <string> (search key) .................................   27

+       BODY.PEEK[<section>] (fetch item) ..........................   30

+       BODYSTRUCTURE (fetch item) .................................   31

+       BODYSTRUCTURE (fetch result) ...............................   47

+       BODY[<section>] (fetch item) ...............................   29

+       BODY[section] (fetch result) ...............................   46

+       BYE (response) .............................................   41

+       CAPABILITY (command) .......................................   10

+       CAPABILITY (response) ......................................   42

+       CC <string> (search key) ...................................   27

+       CHECK (command) ............................................   23

+       CLOSE (command) ............................................   24

+       COPY (command) .............................................   34

+       COPY (response) ............................................   68

+       CREATE (command) ...........................................   17

+       DELETE (command) ...........................................   18

+       DELETED (search key) .......................................   27

+       DRAFT (search key) .........................................   27

+       ENVELOPE (fetch item) ......................................   31

+       ENVELOPE (fetch result) ....................................   49

+       EXAMINE (command) ..........................................   16

+       EXISTS (response) ..........................................   45

+       EXPUNGE (command) ..........................................   25

+       EXPUNGE (response) .........................................   45

+       FAST (fetch item) ..........................................   31

+       FETCH (command) ............................................   29

+       FETCH (response) ...........................................   46

+       FIND ALL.MAILBOXES (command) ...............................   65

+       FIND MAILBOXES (command) ...................................   65

+       FLAGGED (search key) .......................................   27

+       FLAGS (fetch item) .........................................   31

+

+

+

+Crispin                                                        [Page 71]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+

+       FLAGS (fetch result) .......................................   50

+       FLAGS (response) ...........................................   44

+       FLAGS <flag list> (store command data item) ................   34

+       FLAGS.SILENT <flag list> (store command data item) .........   34

+       FROM <string> (search key) .................................   27

+       FULL (fetch item) ..........................................   31

+       HEADER <field-name> <string> (search key) ..................   27

+       INTERNALDATE (fetch item) ..................................   31

+       INTERNALDATE (fetch result) ................................   50

+       KEYWORD <flag> (search key) ................................   27

+       LARGER <n> (search key) ....................................   27

+       LIST (command) .............................................   20

+       LIST (response) ............................................   43

+       LOGIN (command) ............................................   14

+       LOGOUT (command) ...........................................   11

+       LSUB (command) .............................................   22

+       LSUB (response) ............................................   44

+       MAILBOX (response) .........................................   68

+       NEW (search key) ...........................................   27

+       NO (response) ..............................................   40

+       NOOP (command) .............................................   11

+       NOT <search-key> (search key) ..............................   28

+       OK (response) ..............................................   40

+       OLD (search key) ...........................................   28

+       ON <date> (search key) .....................................   28

+       OR <search-key1> <search-key2> (search key) ................   28

+       PARSE (response code) ......................................   39

+       PARTIAL (command) ..........................................   32

+       PERMANENTFLAGS (response code) .............................   39

+       PREAUTH (response) .........................................   41

+       READ-ONLY (response code) ..................................   39

+       READ-WRITE (response code) .................................   39

+       RECENT (response) ..........................................   45

+       RECENT (search key) ........................................   28

+       RENAME (command) ...........................................   18

+       RFC822 (fetch item) ........................................   31

+       RFC822 (fetch result) ......................................   50

+       RFC822.HEADER (fetch item) .................................   31

+       RFC822.HEADER (fetch result) ...............................   50

+       RFC822.HEADER.LINES <header_list> (fetch item) .............   31

+       RFC822.HEADER.LINES.NOT <header_list> (fetch item) .........   32

+       RFC822.PEEK (fetch item) ...................................   31

+       RFC822.SIZE (fetch item) ...................................   32

+       RFC822.SIZE (fetch result) .................................   50

+       RFC822.TEXT (fetch item) ...................................   32

+       RFC822.TEXT (fetch result) .................................   51

+       RFC822.TEXT.PEEK (fetch item) ..............................   32

+       SEARCH (command) ...........................................   25

+

+

+

+Crispin                                                        [Page 72]

+

+RFC 1730                         IMAP4                     December 1994

+

+

+

+       SEARCH (response) ..........................................   44

+       SEEN (search key) ..........................................   28

+       SELECT (command) ...........................................   15

+       SENTBEFORE <date> (search key) .............................   28

+       SENTON <date> (search key) .................................   28

+       SENTSINCE <date> (search key) ..............................   28

+       SINCE <date> (search key) ..................................   28

+       SMALLER <n> (search key) ...................................   28

+       STORE (command) ............................................   33

+       STORE (response) ...........................................   69

+       SUBJECT <string> (search key) ..............................   28

+       SUBSCRIBE (command) ........................................   19

+       SUBSCRIBE MAILBOX (command) ................................   66

+       TEXT <string> (search key) .................................   28

+       TO <string> (search key) ...................................   28

+       TRYCREATE (response code) ..................................   39

+       UID (command) ..............................................   35

+       UID (fetch item) ...........................................   32

+       UID (fetch result) .........................................   51

+       UID <message set> (search key) .............................   28

+       UIDVALIDITY (response code) ................................   40

+       UNANSWERED (search key) ....................................   29

+       UNDELETED (search key) .....................................   29

+       UNDRAFT (search key) .......................................   29

+       UNFLAGGED (search key) .....................................   29

+       UNKEYWORD <flag> (search key) ..............................   29

+       UNSEEN (response code) .....................................   40

+       UNSEEN (search key) ........................................   29

+       UNSUBSCRIBE (command) ......................................   19

+       UNSUBSCRIBE MAILBOX (command) ..............................   66

+       X<atom> (command) ..........................................   37

+       \Answered (system flag) ....................................   50

+       \Deleted (system flag) .....................................   50

+       \Draft (system flag) .......................................   50

+       \Flagged (system flag) .....................................   50

+       \Marked (mailbox name attribute) ...........................   43

+       \Noinferiors (mailbox name attribute) ......................   43

+       \Noselect (mailbox name attribute) .........................   43

+       \Recent (system flag) ......................................   50

+       \Seen (system flag) ........................................   50

+       \Unmarked (mailbox name attribute) .........................   43

+

+

+

+

+

+

+

+

+

+

+Crispin                                                        [Page 73]

+

diff --git a/RFC/rfc1731.txt b/RFC/rfc1731.txt
new file mode 100644
index 00000000..42215dec
--- /dev/null
+++ b/RFC/rfc1731.txt
@@ -0,0 +1,339 @@
+

+

+

+

+

+

+Network Working Group                                           J. Myers

+Request for Comments: 1731                               Carnegie Mellon

+Category: Standards Track                                  December 1994

+

+

+                    IMAP4 Authentication Mechanisms

+

+Status of this Memo

+

+   This document specifies an Internet standards track protocol for the

+   Internet community, and requests discussion and suggestions for

+   improvements.  Please refer to the current edition of the "Internet

+   Official Protocol Standards" (STD 1) for the standardization state

+   and status of this protocol.  Distribution of this memo is unlimited.

+

+

+1. Introduction

+

+   The Internet Message Access Protocol, Version 4 [IMAP4] contains the

+   AUTHENTICATE command, for identifying and authenticating a user to an

+   IMAP4 server and for optionally negotiating a protection mechanism

+   for subsequent protocol interactions.  This document describes

+   several authentication mechanisms for use by the IMAP4 AUTHENTICATE

+   command.

+

+

+2. Kerberos version 4 authentication mechanism

+

+   The authentication type associated with Kerberos version 4 is

+   "KERBEROS_V4".

+

+   The data encoded in the first ready response contains a random 32-bit

+   number in network byte order.  The client should respond with a

+   Kerberos ticket and an authenticator for the principal

+   "imap.hostname@realm", where "hostname" is the first component of the

+   host name of the server with all letters in lower case and where

+   "realm" is the Kerberos realm of the server.  The encrypted checksum

+   field included within the Kerberos authenticator should contain the

+   server provided 32-bit number in network byte order.

+

+   Upon decrypting and verifying the ticket and authenticator, the

+   server should verify that the contained checksum field equals the

+   original server provided random 32-bit number.  Should the

+   verification be successful, the server must add one to the checksum

+   and construct 8 octets of data, with the first four octets containing

+   the incremented checksum in network byte order, the fifth octet

+   containing a bit-mask specifying the protection mechanisms supported

+   by the server, and the sixth through eighth octets containing, in

+

+

+

+Myers                                                           [Page 1]

+

+RFC 1731            IMAP4 Authentication Mechanisms        December 1994

+

+

+   network byte order, the maximum cipher-text buffer size the server is

+   able to receive.  The server must encrypt the 8 octets of data in the

+   session key and issue that encrypted data in a second ready response.

+   The client should consider the server authenticated if the first four

+   octets the un-encrypted data is equal to one plus the checksum it

+   previously sent.

+

+   The client must construct data with the first four octets containing

+   the original server-issued checksum in network byte order, the fifth

+   octet containing the bit-mask specifying the selected protection

+   mechanism, the sixth through eighth octets containing in network byte

+   order the maximum cipher-text buffer size the client is able to

+   receive, and the following octets containing a user name string.  The

+   client must then append from one to eight octets so that the length

+   of the data is a multiple of eight octets. The client must then PCBC

+   encrypt the data with the session key and respond to the second ready

+   response with the encrypted data.  The server decrypts the data and

+   verifies the contained checksum.  The username field identifies the

+   user for whom subsequent IMAP operations are to be performed; the

+   server must verify that the principal identified in the Kerberos

+   ticket is authorized to connect as that user.  After these

+   verifications, the authentication process is complete.

+

+   The protection mechanisms and their corresponding bit-masks are as

+   follows:

+

+      1 No protection mechanism

+      2 Integrity (krb_mk_safe) protection

+      4 Privacy (krb_mk_priv) protection

+

+

+   EXAMPLE: The following are two Kerberos version 4 login scenarios

+   (note that the line breaks in the sample authenticators are for

+   editorial clarity and are not in real authenticators)

+

+      S: * OK IMAP4 Server

+      C: A001 AUTHENTICATE KERBEROS_V4

+      S: + AmFYig==

+      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT

+         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd

+         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh

+      S: + or//EoAADZI=

+      C: DiAF5A4gA+oOIALuBkAAmw==

+      S: A001 OK Kerberos V4 authentication successful

+

+

+

+

+

+

+

+Myers                                                           [Page 2]

+

+RFC 1731            IMAP4 Authentication Mechanisms        December 1994

+

+

+      S: * OK IMAP4 Server

+      C: A001 AUTHENTICATE KERBEROS_V4

+      S: + gcfgCA==

+      C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT

+         +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd

+         WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh

+      S: A001 NO Kerberos V4 authentication failed

+

+

+3. GSSAPI authentication mechanism

+

+   The authentication type associated with all mechanisms employing the

+   GSSAPI [RFC1508] is "GSSAPI".

+

+   The first ready response issued by the server contains no data.  The

+   client should call GSS_Init_sec_context, passing in 0 for

+   input_context_handle (initially) and a targ_name equal to output_name

+   from GSS_Import_Name called with input_name_type of NULL and

+   input_name_string of "SERVICE:imap@hostname" where "hostname" is the

+   fully qualified host name of the server with all letters in lower

+   case.  The client must then respond with the resulting output_token.

+   If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client

+   should expect the server to issue a token in a subsequent ready

+   response.  The client must pass the token to another call to

+   GSS_Init_sec_context.

+

+   If GSS_Init_sec_context returns GSS_COMPLETE, then the client should

+   respond with any resulting output_token.  If there is no

+   output_token, the client should respond with no data.  The client

+   should then expect the server to issue a token in a subsequent ready

+   response.  The client should pass this token to GSS_Unseal and

+   interpret the first octet of resulting cleartext as a bit-mask

+   specifying the protection mechanisms supported by the server and the

+   second through fourth octets as the maximum size output_message to

+   send to the server.  The client should construct data, with the first

+   octet containing the bit-mask specifying the selected protection

+   mechanism, the second through fourth octets containing in network

+   byte order the maximum size output_message the client is able to

+   receive, and the remaining octets containing a user name string.  The

+   client must pass the data to GSS_Seal with conf_flag set to FALSE,

+   and respond with the generated output_message.  The client can then

+   consider the server authenticated.

+

+   The server must issue a ready response with no data and pass the

+   resulting client supplied token to GSS_Accept_sec_context as

+   input_token, setting acceptor_cred_handle to NULL (for "use default

+   credentials"), and 0 for input_context_handle (initially).  If

+   GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should

+

+

+

+Myers                                                           [Page 3]

+

+RFC 1731            IMAP4 Authentication Mechanisms        December 1994

+

+

+   return the generated output_token to the client in a ready response

+   and pass the resulting client supplied token to another call to

+   GSS_Accept_sec_context.

+

+   If GSS_Accept_sec_context returns GSS_COMPLETE, then if an

+   output_token is returned, the server should return it to the client

+   in a ready response and expect a reply from the client with no data.

+   Whether or not an output_token was returned, the server then should

+   then construct 4 octets of data, with the first octet containing a

+   bit-mask specifying the protection mechanisms supported by the server

+   and the second through fourth octets containing in network byte order

+   the maximum size output_token the server is able to receive.  The

+   server must then pass the plaintext to GSS_Seal with conf_flag set to

+   FALSE and issue the generated output_message to the client in a ready

+   response.  The server must then pass the resulting client supplied

+   token to GSS_Unseal and interpret the first octet of resulting

+   cleartext as the bit-mask for the selected protection mechanism, the

+   second through fourth octets as the maximum size output_message to

+   send to the client, and the remaining octets as the user name.  Upon

+   verifying the src_name is authorized to authenticate as the user

+   name, The server should then consider the client authenticated.

+

+   The protection mechanisms and their corresponding bit-masks are as

+   follows:

+

+      1 No protection mechanism

+      2 Integrity protection.

+        Sender calls GSS_Seal with conf_flag set to FALSE

+      4 Privacy protection.

+        Sender calls GSS_Seal with conf_flag set to TRUE

+

+

+4. S/Key authentication mechanism

+

+   The authentication type associated with S/Key [SKEY] is "SKEY".

+

+   The first ready response issued by the server contains no data.  The

+   client responds with the user name string.

+

+   The data encoded in the second ready response contains the decimal

+   sequence number followed by a single space and the seed string for

+   the indicated user.  The client responds with the one-time-password,

+   as either a 64-bit value in network byte order or encoded in the "six

+   English words" format.

+

+   Upon successful verification of the one-time-password, the server

+   should consider the client authenticated.

+

+

+

+

+Myers                                                           [Page 4]

+

+RFC 1731            IMAP4 Authentication Mechanisms        December 1994

+

+

+   S/Key authentication does not provide for any protection mechanisms.

+

+

+   EXAMPLE: The following are two S/Key login scenarios.

+

+      S: * OK IMAP4 Server

+      C: A001 AUTHENTICATE SKEY

+      S: +

+      C: bW9yZ2Fu

+      S: + OTUgUWE1ODMwOA==

+      C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==

+      S: A001 OK S/Key authentication successful

+

+

+      S: * OK IMAP4 Server

+      C: A001 AUTHENTICATE SKEY

+      S: +

+      C: c21pdGg=

+      S: + OTUgUWE1ODMwOA==

+      C: BsAY3g4gBNo=

+      S: A001 NO S/Key authentication failed

+

+

+5. References

+

+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",

+   RFC 1730, University of Washington, December 1994.

+

+   [RFC1508] Linn, J., "Generic Security Service Application Program

+   Interface", RFC 1508, Geer Zolot Associates, September 1993.

+

+   [SKEY] Haller, Neil M. "The S/Key One-Time Password System",

+   Bellcore, Morristown, New Jersey, October 1993,

+   thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Myers                                                           [Page 5]

+

+RFC 1731            IMAP4 Authentication Mechanisms        December 1994

+

+

+6. Security Considerations

+

+   Security issues are discussed throughout this memo.

+

+

+7. Author's Address

+

+   John G. Myers

+   Carnegie-Mellon University

+   5000 Forbes Ave.

+   Pittsburgh PA, 15213-3890

+

+   EMail: jgm+@cmu.edu

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Myers                                                           [Page 6]

+

diff --git a/RFC/rfc1732.txt b/RFC/rfc1732.txt
new file mode 100644
index 00000000..cfae89c0
--- /dev/null
+++ b/RFC/rfc1732.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 1732                      University of Washington
+Category: Informational                                    December 1994
+
+
+              IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Introduction
+
+   This is a summary of hints and recommendations to enable an IMAP4
+   implementation to interoperate with implementations that conform to
+   earlier specifications.  None of these hints and recommendations are
+   required by the IMAP4 specification; implementors must decide for
+   themselves whether they want their implementation to fail if it
+   encounters old software.
+
+   IMAP4 has been designed to be upwards compatible with earlier
+   specifications.  For the most part, IMAP4 facilities that were not in
+   earlier specifications should be invisible to clients unless the
+   client asks for the facility.
+
+   In some cases, older servers may support some of the capabilities
+   listed as being "new in IMAP4" as experimental extensions to the
+   IMAP2 protocol described in RFC 1176.
+
+   This information may not be complete; it reflects current knowledge
+   of server and client implementations as well as "folklore" acquired
+   in the evolution of the protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 1]
+
+RFC 1732                 IMAP4 - Compatibility             December 1994
+
+
+IMAP4 client interoperability with old servers
+
+   In general, a client should be able to discover whether an IMAP2
+   server supports a facility by trial-and-error; if an attempt to use a
+   facility generates a BAD response, the client can assume that the
+   server does not support the facility.
+
+   A quick way to check whether a server implementation supports the
+   IMAP4 specification is to try the CAPABILITY command.  An OK response
+   that includes the IMAP4 capability value indicates a server that
+   supports IMAP4; a BAD response or one without the IMAP4 capability
+   value indicates an older server.
+
+   The following is a list of facilities that are only in IMAP4, and
+   suggestions for how new clients might interoperate with old servers:
+
+   CAPABILITY command
+            A BAD response to this command indicates that the server
+            implements IMAP2 (or IMAP2bis) and not IMAP4.
+
+   AUTHENTICATE command.
+            Use the LOGIN command.
+
+   LSUB and LIST commands
+            Try the RFC 1176 FIND command.
+
+   * in a sequence
+            Use the number of messages in the mailbox from the EXISTS
+            unsolicited response.
+
+   SEARCH extensions (character set, additional criteria)
+            Reformulate the search request using only the searching
+            options listed in search_old in the IMAP4 grammar.  This may
+            entail doing multiple searches to achieve the desired
+            results.
+
+   BODYSTRUCTURE fetch data item
+            Try to fetch the non-extensible BODY data item.
+
+   body section number 0
+            Fetch the entire message and extract the header.
+
+   RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items
+            Use RFC822.HEADER and remove the unwanted information.
+
+   BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data
+            items Use the corresponding non-PEEK versions and manually
+            clear the \Seen flag as necessary.
+
+
+
+Crispin                                                         [Page 2]
+
+RFC 1732                 IMAP4 - Compatibility             December 1994
+
+
+   UID fetch data item and the UID commands
+            No equivalent capabilitity exists in older servers.
+
+   FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
+            Use the corresponding non-SILENT versions and ignore the
+            untagged FETCH responses which com eback.
+
+
+   The following IMAP4 facilities were introduced in the experimental
+   IMAP2bis revisions to RFC-1176, and may be present in a server that
+   does not support the CAPABILITY command:
+
+   CREATE, DELETE, and RENAME commands
+            To test whether these commands are present, try a CREATE
+            INBOX command.  If the response is NO, these commands are
+            supported by the server.  If the response is BAD, they are
+            not.  Older servers without the CREATE capability may sup-
+            port implicit creation of a mailbox by a COPY command with a
+            non-existant name as the destination.
+
+   APPEND command
+            To test whether this command is present, try to append a
+            zero-length stream to a mailbox name that is known not to
+            exist (or at least, highly unlikely to exist) on the remote
+            system.
+
+   SUBSCRIBE and UNSUBSCRIBE commands
+            Try the form of these commands with the optional MAILBOX
+            keyword.
+
+   EXAMINE command
+            Use the SELECT command instead.
+
+   flags and internal date argument to APPEND command
+            Try the APPEND without any flag list and internal date argu-
+            ments.
+
+   BODY, BODY[section], and FULL fetch data items
+            Use RFC822.TEXT and ALL instead.  Server does not support
+            MIME.
+
+   PARTIAL command
+            Use the appropriate FETCH command and ignore the unwanted
+            data.
+
+
+   IMAP4 client implementations must accept all responses and data for-
+   mats documented in the IMAP4 specification, including those labeled
+
+
+
+Crispin                                                         [Page 3]
+
+RFC 1732                 IMAP4 - Compatibility             December 1994
+
+
+   as obsolete.  This includes the COPY and STORE unsolicited responses
+   and the old format of dates and times.  In particular, client imple-
+   mentations must not treat a date/time as a fixed format string; nor
+   may they assume that the time begins at a particular octet.
+
+   IMAP4 client implementations must not depend upon the presence of any
+   server extensions that are not in the base IMAP4 specification.
+
+   The experimental IMAP2bis version specified that the TRYCREATE spe-
+   cial information token is sent as a separate unsolicited OK response
+   instead of inside the NO response.
+
+   The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176
+   are removed from IMAP4.  There is no equivalent to the bboard com-
+   mands, which provided a separate namespace with implicit restrictions
+   on what may be done in that namespace.
+
+   Older server implementations may automatically create the destination
+   mailbox on COPY if that mailbox does not already exist.  This was how
+   a new mailbox was created in older specifications.  If the server
+   does not support the CREATE command (see above for how to test for
+   this), it will probably create a mailbox on COPY.
+
+   Older server implementations may not preserve flags or internal dates
+   on COPY.  Some server implementations may not permit the preservation
+   of certain flags on COPY or their setting with APPEND as site policy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 4]
+
+RFC 1732                 IMAP4 - Compatibility             December 1994
+
+
+IMAP4 server interoperability with old clients
+
+   In general, there should be no interoperation problem between a
+   server conforming to the IMAP4 specification and a well-written
+   client that conforms to an earlier specification.  Known problems are
+   noted below:
+
+      Poor wording in the description of the CHECK command in earlier
+      specifications implied that a CHECK command is the way to get the
+      current number of messages in the mailbox.  This is incorrect.  A
+      CHECK command does not necessarily result in an EXISTS response.
+      Clients must remember the most recent EXISTS value sent from the
+      server, and should not generate unnecessary CHECK commands.
+
+      An incompatibility exists with COPY in IMAP4.  COPY in IMAP4
+      servers does not automatically create the destination mailbox if
+      that mailbox does not already exist.  This may cause problems with
+      old clients that expect automatic mailbox creation in COPY.
+
+      The PREAUTH unsolicited response is new in IMAP4.  It is highly
+      unlikely that an old client would ever see this response.
+
+      The format of dates and times has changed due to the impending end
+      of the century.  Clients that fail to accept a four-digit year or
+      a signed four-digit timezone value will not work properly with
+      IMAP4.
+
+      An incompatibility exists with the use of "\" in quoted strings.
+      This is best avoided by using literals instead of quoted strings
+      if "\" or <"> is embedded in the string.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address:
+
+   Mark R. Crispin
+   Networks and Distributed Computing, JE-30
+   University of Washington
+   Seattle, WA  98195
+
+   Phone: (206) 543-5762
+
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+Crispin                                                         [Page 5]
+
diff --git a/RFC/rfc1734.txt b/RFC/rfc1734.txt
new file mode 100644
index 00000000..f37f29e0
--- /dev/null
+++ b/RFC/rfc1734.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 1734                               Carnegie Mellon
+Category: Standards Track                                  December 1994
+
+
+                      POP3 AUTHentication command
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+
+1. Introduction
+
+   This document describes the optional AUTH command, for indicating an
+   authentication mechanism to the server, performing an authentication
+   protocol exchange, and optionally negotiating a protection mechanism
+   for subsequent protocol interactions.  The authentication and
+   protection mechanisms used by the POP3 AUTH command are those used by
+   IMAP4.
+
+
+2. The AUTH command
+
+   AUTH mechanism
+
+         Arguments:
+             a string identifying an IMAP4 authentication mechanism,
+             such as defined by [IMAP4-AUTH].  Any use of the string
+             "imap" used in a server authentication identity in the
+             definition of an authentication mechanism is replaced with
+             the string "pop".
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state
+
+         Discussion:
+             The AUTH command indicates an authentication mechanism to
+             the server.  If the server supports the requested
+             authentication mechanism, it performs an authentication
+             protocol exchange to authenticate and identify the user.
+             Optionally, it also negotiates a protection mechanism for
+             subsequent protocol interactions.  If the requested
+             authentication mechanism is not supported, the server
+
+
+
+Myers                                                           [Page 1]
+
+RFC 1734                       POP3 AUTH                   December 1994
+
+
+             should reject the AUTH command by sending a negative
+             response.
+
+             The authentication protocol exchange consists of a series
+             of server challenges and client answers that are specific
+             to the authentication mechanism.  A server challenge,
+             otherwise known as a ready response, is a line consisting
+             of a "+" character followed by a single space and a BASE64
+             encoded string.  The client answer consists of a line
+             containing a BASE64 encoded string.  If the client wishes
+             to cancel an authentication exchange, it should issue a
+             line with a single "*".  If the server receives such an
+             answer, it must reject the AUTH command by sending a
+             negative response.
+
+             A protection mechanism provides integrity and privacy
+             protection to the protocol session.  If a protection
+             mechanism is negotiated, it is applied to all subsequent
+             data sent over the connection.  The protection mechanism
+             takes effect immediately following the CRLF that concludes
+             the authentication exchange for the client, and the CRLF of
+             the positive response for the server.  Once the protection
+             mechanism is in effect, the stream of command and response
+             octets is processed into buffers of ciphertext.  Each
+             buffer is transferred over the connection as a stream of
+             octets prepended with a four octet field in network byte
+             order that represents the length of the following data.
+             The maximum ciphertext buffer length is defined by the
+             protection mechanism.
+
+             The server is not required to support any particular
+             authentication mechanism, nor are authentication mechanisms
+             required to support any protection mechanisms.  If an AUTH
+             command fails with a negative response, the session remains
+             in the AUTHORIZATION state and client may try another
+             authentication mechanism by issuing another AUTH command,
+             or may attempt to authenticate by using the USER/PASS or
+             APOP commands.  In other words, the client may request
+             authentication types in decreasing order of preference,
+             with the USER/PASS or APOP command as a last resort.
+
+             Should the client successfully complete the authentication
+             exchange, the POP3 server issues a positive response and
+             the POP3 session enters the TRANSACTION state.
+
+         Possible Responses:
+             +OK maildrop locked and ready
+             -ERR authentication exchange failed
+
+
+
+Myers                                                           [Page 2]
+
+RFC 1734                       POP3 AUTH                   December 1994
+
+
+
+         Examples:
+             S: +OK POP3 server ready
+             C: AUTH KERBEROS_V4
+             S: + AmFYig==
+             C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+                +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+                WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+             S: + or//EoAADZI=
+             C: DiAF5A4gA+oOIALuBkAAmw==
+             S: +OK Kerberos V4 authentication successful
+                ...
+             C: AUTH FOOBAR
+             S: -ERR Unrecognized authentication type
+
+              Note: the line breaks in the first client answer  are
+              for editorial clarity and are not in real authentica-
+              tors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                                                           [Page 3]
+
+RFC 1734                       POP3 AUTH                   December 1994
+
+
+3. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in RFC 822.
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   ATOM_CHAR       ::= <any CHAR except atom_specials>
+
+   atom_specials   ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
+                       <"> / "\"
+
+   auth            ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64)
+                       CRLF
+
+   auth_type       ::= 1*ATOM_CHAR
+
+   base64          ::= *(4base64_CHAR) [base64_terminal]
+
+   base64_char     ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
+           "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
+                       "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
+                       "Y" / "Z" /
+                       "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
+                       "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
+                       "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
+                       "y" / "z" /
+                       "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
+                       "8" / "9" / "+" / "/"
+                       ;; Case-sensitive
+
+   base64_terminal ::= (2base64_char "==") / (3base64_char "=")
+
+   CHAR            ::= <any 7-bit US-ASCII character except NUL,
+                        0x01 - 0x7f>
+
+   continue_req    ::= "+" SPACE base64 CRLF
+
+   CR              ::= <ASCII CR, carriage return, 0x0C>
+
+   CRLF            ::= CR LF
+
+   CTL             ::= <any ASCII control character and DEL,
+                        0x00 - 0x1f, 0x7f>
+
+
+
+
+Myers                                                           [Page 4]
+
+RFC 1734                       POP3 AUTH                   December 1994
+
+
+   LF              ::= <ASCII LF, line feed, 0x0A>
+
+   SPACE           ::= <ASCII SP, space, 0x20>
+
+   TAB             ::= <ASCII HT, tab, 0x09>
+
+
+
+4. References
+
+   [IMAP4-AUTH]  Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
+   Carnegie Mellon, December 1994.
+
+
+
+5. Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+
+
+6. Author's Address
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave
+   Pittsburgh, PA 15213
+
+   EMail: jgm+@cmu.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                                                           [Page 5]
+
diff --git a/RFC/rfc1870.txt b/RFC/rfc1870.txt
new file mode 100644
index 00000000..e24ccec6
--- /dev/null
+++ b/RFC/rfc1870.txt
@@ -0,0 +1,507 @@
+

+

+

+

+

+

+Network Working Group                               J. Klensin, WG Chair

+Request For Comments: 1870                                           MCI

+STD: 10                                                 N. Freed, Editor

+Obsoletes: 1653                             Innosoft International, Inc.

+Category: Standards Track                                       K. Moore

+                                                 University of Tennessee

+                                                           November 1995

+

+

+                         SMTP Service Extension

+                      for Message Size Declaration

+

+Status of this Memo

+

+   This document specifies an Internet standards track protocol for the

+   Internet community, and requests discussion and suggestions for

+   improvements.  Please refer to the current edition of the "Internet

+   Official Protocol Standards" (STD 1) for the standardization state

+   and status of this protocol.  Distribution of this memo is unlimited.

+

+1.  Abstract

+

+   This memo defines an extension to the SMTP service whereby an SMTP

+   client and server may interact to give the server an opportunity to

+   decline to accept a message (perhaps temporarily) based on the

+   client's estimate of the message size.

+

+2.  Introduction

+

+   The MIME extensions to the Internet message protocol provide for the

+   transmission of many kinds of data which were previously unsupported

+   in Internet mail.  One expected result of the use of MIME is that

+   SMTP will be expected to carry a much wider range of message sizes

+   than was previously the case.  This has an impact on the amount of

+   resources (e.g. disk space) required by a system acting as a server.

+

+   This memo uses the mechanism defined in [5] to define extensions to

+   the SMTP service whereby a client ("sender-SMTP") may declare the

+   size of a particular message to a server ("receiver-SMTP"), after

+   which the server may indicate to the client that it is or is not

+   willing to accept the message based on the declared message size and

+   whereby a server ("receiver-SMTP") may declare the maximum message

+   size it is willing to accept to a client ("sender-SMTP").

+

+

+

+

+

+

+

+

+Klensin, et al              Standards Track                     [Page 1]

+

+RFC 1870                 SMTP Size Declaration             November 1995

+

+

+3.  Framework for the Size Declaration Extension

+

+   The following service extension is therefore defined:

+

+   (1) the name of the SMTP service extension is "Message Size

+       Declaration";

+

+   (2) the EHLO keyword value associated with this extension is "SIZE";

+

+   (3) one optional parameter is allowed with this EHLO keyword value, a

+       decimal number indicating the fixed maximum message size in bytes

+       that the server will accept.  The syntax of the parameter is as

+       follows, using the augmented BNF notation of [2]:

+

+           size-param ::= [1*DIGIT]

+

+       A parameter value of 0 (zero) indicates that no fixed maximum

+       message size is in force.  If the parameter is omitted no

+       information is conveyed about the server's fixed maximum message

+       size;

+

+   (4) one optional parameter using the keyword "SIZE" is added to the

+       MAIL FROM command.  The value associated with this parameter is a

+       decimal number indicating the size of the message that is to be

+       transmitted.  The syntax of the value is as follows, using the

+       augmented BNF notation of [2]:

+

+           size-value ::= 1*20DIGIT

+

+   (5) the maximum length of a MAIL FROM command line is increased by 26

+       characters by the possible addition of the SIZE keyword and

+       value;

+

+   (6) no additional SMTP verbs are defined by this extension.

+

+   The remainder of this memo specifies how support for the extension

+   affects the behavior of an SMTP client and server.

+

+4.  The Message Size Declaration service extension

+

+   An SMTP server may have a fixed upper limit on message size.  Any

+   attempt by a client to transfer a message which is larger than this

+   fixed upper limit will fail.  In addition, a server normally has

+   limited space with which to store incoming messages.  Transfer of a

+   message may therefore also fail due to a lack of storage space, but

+   might succeed at a later time.

+

+

+

+

+

+Klensin, et al              Standards Track                     [Page 2]

+

+RFC 1870                 SMTP Size Declaration             November 1995

+

+

+   A client using the unextended SMTP protocol defined in [1], can only

+   be informed of such failures after transmitting the entire message to

+   the server (which discards the transferred message).  If, however,

+   both client and server support the Message Size Declaration service

+   extension, such conditions may be detected before any transfer is

+   attempted.

+

+   An SMTP client wishing to relay a large content may issue the EHLO

+   command to start an SMTP session, to determine if the server supports

+   any of several service extensions.  If the server responds with code

+   250 to the EHLO command, and the response includes the EHLO keyword

+   value SIZE, then the Message Size Declaration extension is supported.

+

+   If a numeric parameter follows the SIZE keyword value of the EHLO

+   response, it indicates the size of the largest message that the

+   server is willing to accept.  Any attempt by a client to transfer a

+   message which is larger than this limit will be rejected with a

+   permanent failure (552) reply code.

+

+   A server that supports the Message Size Declaration extension will

+   accept the extended version of the MAIL command described below.

+   When supported by the server, a client may use the extended MAIL

+   command (instead of the MAIL command as defined in [1]) to declare an

+   estimate of the size of a message it wishes to transfer.  The server

+   may then return an appropriate error code if it determines that an

+   attempt to transfer a message of that size would fail.

+

+5.  Definitions

+

+   The message size is defined as the number of octets, including CR-LF

+   pairs, but not the SMTP DATA command's terminating dot or doubled

+   quoting dots, to be transmitted by the SMTP client after receiving

+   reply code 354 to the DATA command.

+

+   The fixed maximum message size is defined as the message size of the

+   largest message that a server is ever willing to accept.  An attempt

+   to transfer any message larger than the fixed maximum message size

+   will always fail.  The fixed maximum message size may be an

+   implementation artifact of the SMTP server, or it may be chosen by

+   the administrator of the server.

+

+   The declared message size is defined as a client's estimate of the

+   message size for a particular message.

+

+

+

+

+

+

+

+

+Klensin, et al              Standards Track                     [Page 3]

+

+RFC 1870                 SMTP Size Declaration             November 1995

+

+

+6.  The extended MAIL command

+

+   The extended MAIL command is issued by a client when it wishes to

+   inform a server of the size of the message to be sent.  The extended

+   MAIL command is identical to the MAIL command as defined in [1],

+   except that a SIZE parameter appears after the address.

+

+   The complete syntax of this extended command is defined in [5]. The

+   esmtp-keyword is "SIZE" and the syntax for esmtp-value is given by

+   the syntax for size-value shown above.

+

+   The value associated with the SIZE parameter is a decimal

+   representation of the declared message size in octets.  This number

+   should include the message header, body, and the CR-LF sequences

+   between lines, but not the SMTP DATA command's terminating dot or

+   doubled quoting dots. Only one SIZE parameter may be specified in a

+   single MAIL command.

+

+   Ideally, the declared message size is equal to the true message size.

+   However, since exact computation of the message size may be

+   infeasable, the client may use a heuristically-derived estimate.

+   Such heuristics should be chosen so that the declared message size is

+   usually larger than the actual message size. (This has the effect of

+   making the counting or non-counting of SMTP DATA dots largely an

+   academic point.)

+

+   NOTE: Servers MUST NOT use the SIZE parameter to determine end of

+   content in the DATA command.

+

+6.1  Server action on receipt of the extended MAIL command

+

+   Upon receipt of an extended MAIL command containing a SIZE parameter,

+   a server should determine whether the declared message size exceeds

+   its fixed maximum message size.  If the declared message size is

+   smaller than the fixed maximum message size, the server may also wish

+   to determine whether sufficient resources are available to buffer a

+   message of the declared message size and to maintain it in stable

+   storage, until the message can be delivered or relayed to each of its

+   recipients.

+

+   A server may respond to the extended MAIL command with any of the

+   error codes defined in [1] for the MAIL command.  In addition, one of

+   the following error codes may be returned:

+

+   (1) If the server currently lacks sufficient resources to accept a

+       message of the indicated size, but may be able to accept the

+       message at a later time, it responds with code "452 insufficient

+       system storage".

+

+

+

+Klensin, et al              Standards Track                     [Page 4]

+

+RFC 1870                 SMTP Size Declaration             November 1995

+

+

+   (2) If the indicated size is larger than the server's fixed maximum

+       message size, the server responds with code "552 message size

+       exceeds fixed maximium message size".

+

+   A server is permitted, but not required, to accept a message which

+   is, in fact, larger than declared in the extended MAIL command, such

+   as might occur if the client employed a size-estimation heuristic

+   which was inaccurate.

+

+6.2  Client action on receiving response to extended MAIL command

+

+   The client, upon receiving the server's response to the extended MAIL

+   command, acts as follows:

+

+   (1) If the code "452 insufficient system storage" is returned, the

+       client should next send either a RSET command (if it wishes to

+       attempt to send other messages) or a QUIT command. The client

+       should then repeat the attempt to send the message to the server

+       at a later time.

+

+   (2) If the code "552 message exceeds fixed maximum message size" is

+       received, the client should immediately send either a RSET command

+       (if it wishes to attempt to send additional messages), or a QUIT

+       command.  The client should then declare the message undeliverable

+       and return appropriate notification to the sender (if a sender

+       address was present in the MAIL command).

+

+   A successful (250) reply code in response to the extended MAIL

+   command does not constitute an absolute guarantee that the message

+   transfer will succeed.  SMTP clients using the extended MAIL command

+   must still be prepared to handle both temporary and permanent error

+   reply codes (including codes 452 and 552), either immediately after

+   issuing the DATA command, or after transfer of the message.

+

+6.3  Messages larger than the declared size.

+

+   Once a server has agreed (via the extended MAIL command) to accept a

+   message of a particular size, it should not return a 552 reply code

+   after the transfer phase of the DATA command, unless the actual size

+   of the message transferred is greater than the declared message size.

+   A server may also choose to accept a message which is somewhat larger

+   than the declared message size.

+

+   A client is permitted to declare a message to be smaller than its

+   actual size.  However, in this case, a successful (250) reply code is

+   no assurance that the server will accept the message or has

+   sufficient resources to do so.  The server may reject such a message

+   after its DATA transfer.

+

+

+

+Klensin, et al              Standards Track                     [Page 5]

+

+RFC 1870                 SMTP Size Declaration             November 1995

+

+

+6.4  Per-recipient rejection based on message size.

+

+   A server that implements this extension may return a 452 or 552 reply

+   code in response to a RCPT command, based on its unwillingness to

+   accept a message of the declared size for a particular recipient.

+

+   (1) If a 452 code is returned, the client may requeue the message for

+       later delivery to the same recipient.

+

+   (2) If a 552 code is returned, the client may not requeue the message

+       for later delivery to the same recipient.

+

+7.  Minimal usage

+

+   A "minimal" client may use this extension to simply compare its

+   (perhaps estimated) size of the message that it wishes to relay, with

+   the server's fixed maximum message size (from the parameter to the

+   SIZE keyword in the EHLO response), to determine whether the server

+   will ever accept the message.  Such an implementation need not

+   declare message sizes via the extended MAIL command.  However,

+   neither will it be able to discover temporary limits on message size

+   due to server resource limitations, nor per-recipient limitations on

+   message size.

+

+   A minimal server that employs this service extension may simply use

+   the SIZE keyword value to inform the client of the size of the

+   largest message it will accept, or to inform the client that there is

+   no fixed limit on message size.  Such a server must accept the

+   extended MAIL command and return a 552 reply code if the client's

+   declared size exceeds its fixed size limit (if any), but it need not

+   detect "temporary" limitations on message size.

+

+   The numeric parameter to the EHLO SIZE keyword is optional.  If the

+   parameter is omitted entirely it indicates that the server does not

+   advertise a fixed maximum message size.  A server that returns the

+   SIZE keyword with no parameter in response to the EHLO command may

+   not issue a positive (250) response to an extended MAIL command

+   containing a SIZE specification without first checking to see if

+   sufficient resources are available to transfer a message of the

+   declared size, and to retain it in stable storage until it can be

+   relayed or delivered to its recipients.  If possible, the server

+   should actually reserve sufficient storage space to transfer the

+   message.

+

+

+

+

+

+

+

+

+Klensin, et al              Standards Track                     [Page 6]

+

+RFC 1870                 SMTP Size Declaration             November 1995

+

+

+8. Example

+

+   The following example illustrates the use of size declaration with

+   some permanent and temporary failures.

+

+   S: <wait for connection on TCP port 25>

+   C: <open connection to server>

+   S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)

+   C: EHLO ymir.claremont.edu

+   S: 250-sigurd.innosoft.com

+   S: 250-EXPN

+   S: 250-HELP

+   S: 250 SIZE 1000000

+   C: MAIL FROM:<ned@thor.innosoft.com> SIZE=500000

+   S: 250 Address Ok.

+   C: RCPT TO:<ned@innosoft.com>

+   S: 250 ned@innosoft.com OK; can accomodate 500000 byte message

+   C: RCPT TO:<ned@ymir.claremont.edu>

+   S: 552 Channel size limit exceeded: ned@YMIR.CLAREMONT.EDU

+   C: RCPT TO:<ned@hmcvax.claremont.edu>

+   S: 452 Insufficient channel storage: ned@hmcvax.CLAREMONT.EDU

+   C: DATA

+   S: 354 Send message, ending in CRLF.CRLF.

+    ...

+   C: .

+   S: 250 Some recipients OK

+   C: QUIT

+   S: 221 Goodbye

+

+9. Security Considerations

+

+   The size declaration extensions described in this memo can

+   conceivably be used to facilitate crude service denial attacks.

+   Specifically, both the information contained in the SIZE parameter

+   and use of the extended MAIL command make it somewhat quicker and

+   easier to devise an efficacious service denial attack.  However,

+   unless implementations are very weak, these extensions do not create

+   any vulnerability that has not always existed with SMTP. In addition,

+   no issues are addressed involving trusted systems and possible

+   release of information via the mechanisms described in this RFC.

+

+10.  Acknowledgements

+

+   This document was derived from an earlier Working Group work in

+   progess contribution.  Jim Conklin, Dave Crocker, Neil Katin, Eliot

+   Lear, Marshall T. Rose, and Einar Stefferud provided extensive

+   comments in response to earlier works in progress of both this and

+   the previous memo.

+

+

+

+Klensin, et al              Standards Track                     [Page 7]

+

+RFC 1870                 SMTP Size Declaration             November 1995

+

+

+11.  References

+

+   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,

+       USC/Information Sciences Institute, August 1982.

+

+   [2] Crocker, D., "Standard for the Format of ARPA Internet Text

+       Messages", STD 11, RFC 822, UDEL, August 1982.

+

+   [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail

+       Extensions", RFC 1521, Bellcore, Innosoft, September 1993.

+

+   [4] Moore, K., "Representation of Non-ASCII Text in Internet Message

+       Headers", RFC 1522, University of Tennessee, September 1993.

+

+   [5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,

+       "SMTP Service Extensions", STD 11, RFC 1869, MCI, Innosoft

+       International, Inc., Dover Beach Consulting, Inc., Network

+       Management Associates, Inc., Brandenburg Consulting, November

+       1995.

+

+   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC

+       974, BBN, January 1986.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Klensin, et al              Standards Track                     [Page 8]

+

+RFC 1870                 SMTP Size Declaration             November 1995

+

+

+12.  Chair, Editor, and Author Addresses

+

+   John Klensin, WG Chair

+   MCI

+   2100 Reston Parkway

+   Reston, VA 22091

+

+   Phone: +1 703 715-7361

+   Fax: +1 703 715-7436

+   EMail: klensin@mci.net

+

+

+   Ned Freed, Editor

+   Innosoft International, Inc.

+   1050 East Garvey Avenue South

+   West Covina, CA 91790

+   USA

+

+   Phone: +1 818 919 3600

+   Fax: +1 818 919 3614

+   EMail: ned@innosoft.com

+

+

+   Keith Moore

+   Computer Science Dept.

+   University of Tennessee

+   107 Ayres Hall

+   Knoxville, TN 37996-1301

+   USA

+

+   EMail: moore@cs.utk.edu

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Klensin, et al              Standards Track                     [Page 9]

+

diff --git a/RFC/rfc1891.txt b/RFC/rfc1891.txt
new file mode 100644
index 00000000..23b58ba9
--- /dev/null
+++ b/RFC/rfc1891.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                           K. Moore
+Request for Comments: 1891                       University of Tennessee
+Category: Standards Track                                   January 1996
+
+
+                         SMTP Service Extension
+                   for Delivery Status Notifications
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1. Abstract
+
+   This memo defines an extension to the SMTP service, which allows an
+   SMTP client to specify (a) that delivery status notifications (DSNs)
+   should be generated under certain conditions, (b) whether such
+   notifications should return the contents of the message, and (c)
+   additional information, to be returned with a DSN, that allows the
+   sender to identify both the recipient(s) for which the DSN was
+   issued, and the transaction in which the original message was sent.
+
+   Any questions, comments, and reports of defects or ambiguities in
+   this specification may be sent to the mailing list for the NOTARY
+   working group of the IETF, using the address
+   <notifications@cs.utk.edu>.  Requests to subscribe to the mailing
+   list should be addressed to <notifications-request@cs.utk.edu>.
+   Implementors of this specification are encouraged to subscribe to the
+   mailing list, so that they will quickly be informed of any problems
+   which might hinder interoperability.
+
+   NOTE: This document is a Proposed Standard.  If and when this
+   protocol is submitted for Draft Standard status, any normative text
+   (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in
+   this document will be re-evaluated in light of implementation
+   experience, and are thus subject to change.
+
+2. Introduction
+
+   The SMTP protocol [1] requires that an SMTP server provide
+   notification of delivery failure, if it determines that a message
+   cannot be delivered to one or more recipients.  Traditionally, such
+   notification consists of an ordinary Internet mail message (format
+   defined by [2]), sent to the envelope sender address (the argument of
+
+
+
+Moore                       Standards Track                     [Page 1]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   the SMTP MAIL command), containing an explanation of the error and at
+   least the headers of the failed message.
+
+   Experience with large mail distribution lists [3] indicates that such
+   messages are often insufficient to diagnose problems, or even to
+   determine at which host or for which recipients a problem occurred.
+   In addition, the lack of a standardized format for delivery
+   notifications in Internet mail makes it difficult to exchange such
+   notifications with other message handling systems.
+
+   Such experience has demonstrated a need for a delivery status
+   notification service for Internet electronic mail, which:
+
+(a) is reliable, in the sense that any DSN request will either be
+    honored at the time of final delivery, or result in a response
+    that indicates that the request cannot be honored,
+
+(b) when both success and failure notifications are requested,
+    provides an unambiguous and nonconflicting indication of whether
+    delivery of a message to a recipient succeeded or failed,
+
+(c) is stable, in that a failed attempt to deliver a DSN should never
+    result in the transmission of another DSN over the network,
+
+(d) preserves sufficient information to allow the sender to identify
+    both the mail transaction and the recipient address which caused
+    the notification, even when mail is forwarded or gatewayed to
+    foreign environments, and
+
+(e) interfaces acceptably with non-SMTP and non-822-based mail
+    systems, both so that notifications returned from foreign mail
+    systems may be useful to Internet users, and so that the
+    notification requests from foreign environments may be honored.
+    Among the requirements implied by this goal are the ability to
+    request non-return-of-content, and the ability to specify whether
+    positive delivery notifications, negative delivery notifications,
+    both, or neither, should be issued.
+
+   In an attempt to provide such a service, this memo uses the mechanism
+   defined in [4] to define an extension to the SMTP protocol.  Using
+   this mechanism, an SMTP client may request that an SMTP server issue
+   or not issue a delivery status notification (DSN) under certain
+   conditions.  The format of a DSN is defined in [5].
+
+
+
+
+
+
+
+
+Moore                       Standards Track                     [Page 2]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+3. Framework for the Delivery Status Notification Extension
+
+   The following service extension is therefore defined:
+
+(1) The name of the SMTP service extension is "Delivery Status
+    Notification";
+
+(2) the EHLO keyword value associated with this extension is "DSN",
+    the meaning of which is defined in section 4 of this memo;
+
+(3) no parameters are allowed with this EHLO keyword value;
+
+(4) two optional parameters are added to the RCPT command, and two
+    optional parameters are added to the MAIL command:
+
+    An optional parameter for the RCPT command, using the
+    esmtp-keyword "NOTIFY", (to specify the conditions under which a
+    delivery status notification should be generated), is defined in
+    section 5.1,
+
+    An optional parameter for the RCPT command, using the
+    esmtp-keyword "ORCPT", (used to convey the "original"
+    (sender-specified) recipient address), is defined in section 5.2,
+    and
+
+    An optional parameter for the MAIL command, using the
+    esmtp-keyword "RET", (to request that DSNs containing an
+    indication of delivery failure either return the entire contents
+    of a message or only the message headers), is defined in section
+    5.3,
+
+    An optional parameter for the MAIL command, using the
+    esmtp-keyword "ENVID", (used to propagate an identifier for this
+    message transmission envelope, which is also known to the sender
+    and will, if present, be returned in any DSNs issued for this
+    transmission), is defined in section 5.4;
+
+(5) no additional SMTP verbs are defined by this extension.
+
+   The remainder of this memo specifies how support for the extension
+   effects the behavior of a message transfer agent.
+
+4.  The Delivery Status Notification service extension
+
+   An SMTP client wishing to request a DSN for a message may issue the
+   EHLO command to start an SMTP session, to determine if the server
+   supports any of several service extensions.  If the server responds
+   with code 250 to the EHLO command, and the response includes the EHLO
+
+
+
+Moore                       Standards Track                     [Page 3]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   keyword DSN, then the Delivery Status Notification extension (as
+   described in this memo) is supported.
+
+   Ordinarily, when an SMTP server returns a positive (2xx) reply code
+   in response to a RCPT command, it agrees to accept responsibility for
+   either delivering the message to the named recipient, or sending a
+   notification to the sender of the message indicating that delivery
+   has failed.  However, an extended SMTP ("ESMTP") server which
+   implements this service extension will accept an optional NOTIFY
+   parameter with the RCPT command. If present, the NOTIFY parameter
+   alters the conditions for generation of delivery status notifications
+   from the default (issue notifications only on failure) specified in
+   [1].  The ESMTP client may also request (via the RET parameter)
+   whether the entire contents of the original message should be
+   returned (as opposed to just the headers of that message), along with
+   the DSN.
+
+   In general, an ESMTP server which implements this service extension
+   will propagate delivery status notification requests when relaying
+   mail to other SMTP-based MTAs which also support this extension, and
+   make a "best effort" to ensure that such requests are honored when
+   messages are passed into other environments.
+
+   In order that any delivery status notifications thus generated will
+   be meaningful to the sender, any ESMTP server which supports this
+   extension will attempt to propagate the following information to any
+   other MTAs that are used to relay the message, for use in generating
+   DSNs:
+
+(a) for each recipient, a copy of the original recipient address, as
+    used by the sender of the message.
+
+    This address need not be the same as the mailbox specified in the
+    RCPT command.  For example, if a message was originally addressed
+    to A@B.C and later forwarded to A@D.E, after such forwarding has
+    taken place, the RCPT command will specify a mailbox of A@D.E.
+    However, the original recipient address remains A@B.C.
+
+    Also, if the message originated from an environment which does not
+    use Internet-style user@domain addresses, and was gatewayed into
+    SMTP, the original recipient address will preserve the original
+    form of the recipient address.
+
+(b) for the entire SMTP transaction, an envelope identification
+    string, which may be used by the sender to associate any delivery
+    status notifications with the transaction used to send the
+    original message.
+
+
+
+
+Moore                       Standards Track                     [Page 4]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+5.  Additional parameters for RCPT and MAIL commands
+
+   The extended RCPT and MAIL commands are issued by a client when it
+   wishes to request a DSN from the server, under certain conditions,
+   for a particular recipient.  The extended RCPT and MAIL commands are
+   identical to the RCPT and MAIL commands defined in [1], except that
+   one or more of the following parameters appear after the sender or
+   recipient address, respectively.  The general syntax for extended
+   SMTP commands is defined in [4].
+
+   NOTE: Although RFC 822 ABNF is used to describe the syntax of these
+   parameters, they are not, in the language of that document,
+   "structured field bodies".  Therefore, while parentheses MAY appear
+   within an emstp-value, they are not recognized as comment delimiters.
+
+   The syntax for "esmtp-value" in [4] does not allow SP, "=", control
+   characters, or characters outside the traditional ASCII range of 1-
+   127 decimal to be transmitted in an esmtp-value.  Because the ENVID
+   and ORCPT parameters may need to convey values outside this range,
+   the esmtp-values for these parameters are encoded as "xtext".
+   "xtext" is formally defined as follows:
+
+     xtext = *( xchar / hexchar )
+
+     xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
+          except for "+" and "=".
+
+; "hexchar"s are intended to encode octets that cannot appear
+; as ASCII characters within an esmtp-value.
+
+     hexchar = ASCII "+" immediately followed by two upper case
+          hexadecimal digits
+
+When encoding an octet sequence as xtext:
+
++ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=",
+  MAY be encoded as itself.  (A CHAR in this range MAY instead be
+  encoded as a "hexchar", at the implementor's discretion.)
+
++ ASCII CHARs that fall outside the range above must be encoded as
+  "hexchar".
+
+5.1  The NOTIFY parameter of the ESMTP RCPT command
+
+   A RCPT command issued by a client may contain the optional esmtp-
+   keyword "NOTIFY", to specify the conditions under which the SMTP
+   server should generate DSNs for that recipient.  If the NOTIFY
+   esmtp-keyword is used, it MUST have an associated esmtp-value,
+
+
+
+Moore                       Standards Track                     [Page 5]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   formatted according to the following rules, using the ABNF of RFC
+   822:
+
+     notify-esmtp-value = "NEVER" / 1#notify-list-element
+
+     notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"
+
+Notes:
+
+a. Multiple notify-list-elements, separated by commas, MAY appear in a
+   NOTIFY parameter; however, the NEVER keyword MUST appear by itself.
+
+b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled
+   in any combination of upper and lower case letters.
+
+The meaning of the NOTIFY parameter values is generally as follows:
+
++ A NOTIFY parameter value of "NEVER" requests that a DSN not be
+  returned to the sender under any conditions.
+
++ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE"
+  keywords requests that a DSN be issued on successful delivery or
+  delivery failure, respectively.
+
++ A NOTIFY parameter value containing the keyword "DELAY" indicates the
+  sender's willingness to receive "delayed" DSNs.  Delayed DSNs may be
+  issued if delivery of a message has been delayed for an unusual amount
+  of time (as determined by the MTA at which the message is delayed),
+  but the final delivery status (whether successful or failure) cannot
+  be determined.  The absence of the DELAY keyword in a NOTIFY parameter
+  requests that a "delayed" DSN NOT be issued under any conditions.
+
+   The actual rules governing interpretation of the NOTIFY parameter are
+   given in section 6.
+
+   For compatibility with SMTP clients that do not use the NOTIFY
+   facility, the absence of a NOTIFY parameter in a RCPT command may be
+   interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.
+
+5.2 The ORCPT parameter to the ESMTP RCPT command
+
+   The ORCPT esmtp-keyword of the RCPT command is used to specify an
+   "original" recipient address that corresponds to the actual recipient
+   to which the message is to be delivered.  If the ORCPT esmtp-keyword
+   is used, it MUST have an associated esmtp-value, which consists of
+   the original recipient address, encoded according to the rules below.
+   The ABNF for the ORCPT parameter is:
+
+
+
+
+Moore                       Standards Track                     [Page 6]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+     orcpt-parameter = "ORCPT=" original-recipient-address
+
+     original-recipient-address = addr-type ";" xtext
+
+     addr-type = atom
+
+   The "addr-type" portion MUST be an IANA-registered electronic mail
+   address-type (as defined in [5]), while the "xtext" portion contains
+   an encoded representation of the original recipient address using the
+   rules in section 5 of this document.  The entire ORCPT parameter MAY
+   be up to 500 characters in length.
+
+   When initially submitting a message via SMTP, if the ORCPT parameter
+   is used, it MUST contain the same address as the RCPT TO address
+   (unlike the RCPT TO address, the ORCPT parameter will be encoded as
+   xtext).  Likewise, when a mailing list submits a message via SMTP to
+   be distributed to the list subscribers, if ORCPT is used, the ORCPT
+   parameter MUST match the new RCPT TO address of each recipient, not
+   the address specified by the original sender of the message.)
+
+   The "addr-type" portion of the original-recipient-address is used to
+   indicate the "type" of the address which appears in the ORCPT
+   parameter value.  However, the address associated with the ORCPT
+   keyword is NOT constrained to conform to the syntax rules for that
+   "addr-type".
+
+   Ideally, the "xtext" portion of the original-recipient-address should
+   contain, in encoded form, the same sequence of characters that the
+   sender used to specify the recipient.  However, for a message
+   gatewayed from an environment (such as X.400) in which a recipient
+   address is not a simple string of printable characters, the
+   representation of recipient address must be defined by a
+   specification for gatewaying between DSNs and that environment.
+
+5.3 The RET parameter of the ESMTP MAIL command
+
+   The RET esmtp-keyword on the extended MAIL command specifies whether
+   or not the message should be included in any failed DSN issued for
+   this message transmission.  If the RET esmtp-keyword is used, it MUST
+   have an associated esmtp-value, which is one of the following
+   keywords:
+
+   FULL  requests that the entire message be returned in any "failed"
+         delivery status notification issued for this recipient.
+
+   HDRS  requests that only the headers of the message be returned.
+
+
+
+
+
+Moore                       Standards Track                     [Page 7]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   The FULL and HDRS keywords may be spelled in any combination of upper
+   and lower case letters.
+
+   If no RET parameter is supplied, the MTA MAY return either the
+   headers of the message or the entire message for any DSN containing
+   indication of failed deliveries.
+
+   Note that the RET parameter only applies to DSNs that indicate
+   delivery failure for at least one recipient.  If a DSN contains no
+   indications of delivery failure, only the headers of the message
+   should be returned.
+
+5.4  The ENVID parameter to the ESMTP MAIL command
+
+   The ENVID esmtp-keyword of the SMTP MAIL command is used to specify
+   an "envelope identifier" to be transmitted along with the message and
+   included in any DSNs issued for any of the recipients named in this
+   SMTP transaction.  The purpose of the envelope identifier is to allow
+   the sender of a message to identify the transaction for which the DSN
+   was issued.
+
+   The ABNF for the ENVID parameter is:
+
+     envid-parameter = "ENVID=" xtext
+
+   The ENVID esmtp-keyword MUST have an associated esmtp-value.  No
+   meaning is assigned by the mail system to the presence or absence of
+   this parameter or to any esmtp-value associated with this parameter;
+   the information is used only by the sender or his user agent.  The
+   ENVID parameter MAY be up to 100 characters in length.
+
+5.5 Restrictions on the use of Delivery Status Notification parameters
+
+   The RET and ENVID parameters MUST NOT appear more than once each in
+   any single MAIL command.  If more than one of either of these
+   parameters appears in a MAIL command, the ESMTP server SHOULD respond
+   with "501 syntax error in parameters or arguments".
+
+   The NOTIFY and ORCPT parameters MUST NOT appear more than once in any
+   RCPT command.  If more than one of either of these parameters appears
+   in a RCPT command, the ESMTP server SHOULD respond with "501 syntax
+   error in parameters or arguments".
+
+6. Conformance requirements
+
+   The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer
+   Agents (MTAs) when accepting, relaying, or gatewaying mail, as well
+   as User Agents (UAs) when submitting mail to the mail transport
+
+
+
+Moore                       Standards Track                     [Page 8]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   system.  The DSN extension to SMTP may be used to allow UAs to convey
+   the sender's requests as to when DSNs should be issued.  A UA which
+   claims to conform to this specification must meet certain
+   requirements as described below.
+
+   Typically, a message transfer agent (MTA) which supports SMTP will
+   assume, at different times, both the role of a SMTP client and an
+   SMTP server, and may also provide local delivery, gatewaying to
+   foreign environments, forwarding, and mailing list expansion.  An MTA
+   which, when acting as an SMTP server, issues the DSN keyword in
+   response to the EHLO command, MUST obey the rules below for a
+   "conforming SMTP client" when acting as a client, and a "conforming
+   SMTP server" when acting as a server.  The term "conforming MTA"
+   refers to an MTA which conforms to this specification, independent of
+   its role of client or server.
+
+6.1 SMTP protocol interactions
+
+   The following rules apply to SMTP transactions in which any of the
+   ENVID, NOTIFY, RET, or ORCPT keywords are used:
+
+(a) If an SMTP client issues a MAIL command containing a valid ENVID
+    parameter and associated esmtp-value and/or a valid RET parameter
+    and associated esmtp-value, a conforming SMTP server MUST return
+    the same reply-code as it would to the same MAIL command without
+    the ENVID and/or RET parameters.  A conforming SMTP server MUST
+    NOT refuse a MAIL command based on the absence or presence of
+    valid ENVID or RET parameters, or on their associated
+    esmtp-values.
+
+    However, if the associated esmtp-value is not valid (i.e. contains
+    illegal characters), or if there is more than one ENVID or RET
+    parameter in a particular MAIL command, the server MUST issue the
+    reply-code 501 with an appropriate message (e.g.  "syntax error in
+    parameter").
+
+(b) If an SMTP client issues a RCPT command containing any valid
+    NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST
+    return the same response as it would to the same RCPT command
+    without those NOTIFY and/or ORCPT parameters.  A conforming SMTP
+    server MUST NOT refuse a RCPT command based on the presence or
+    absence of any of these parameters.
+
+    However, if any of the associated esmtp-values are not valid, or
+    if there is more than one of any of these parameters in a
+    particular RCPT command, the server SHOULD issue the response "501
+    syntax error in parameter".
+
+
+
+
+Moore                       Standards Track                     [Page 9]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+6.2 Handling of messages received via SMTP
+
+   This section describes how a conforming MTA should handle any
+   messages received via SMTP.
+
+   NOTE: A DSN MUST NOT be returned to the sender for any message for
+   which the return address from the SMTP MAIL command was NULL ("<>"),
+   even if the sender's address is available from other sources (e.g.
+   the message header).  However, the MTA which would otherwise issue a
+   DSN SHOULD inform the local postmaster of delivery failures through
+   some appropriate mechanism that will not itself result in the
+   generation of DSNs.
+
+   DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to
+   be sent with a NULL return address ("reverse-path").  This creates an
+   interesting situation when a message arrives with one or more
+   nonfunctional recipient addresses in addition to a nonfunctional
+   return address.  When delivery to one of the recipient addresses
+   fails, the MTA will attempt to send a nondelivery notification to the
+   return address, setting the return address on the notification to
+   NULL.  When the delivery of this notification fails, the MTA
+   attempting delivery of that notification sees a NULL return address.
+   If that MTA were not to inform anyone of the situation, the original
+   message would be silently lost.  Furthermore, a nonfunctional return
+   address is often indicative of a configuration problem in the
+   sender's MTA.  Reporting the condition to the local postmaster may
+   help to speed correction of such errors.
+
+6.2.1 Relay of messages to other conforming SMTP servers
+
+   The following rules govern the behavior of a conforming MTA, when
+   relaying a message which was received via the SMTP protocol, to an
+   SMTP server that supports the Delivery Status Notification service
+   extension:
+
+(a) Any ENVID parameter included in the MAIL command when a message was
+    received, MUST also appear on the MAIL command with which the
+    message is relayed, with the same associated esmtp-value.  If no
+    ENVID parameter was included in the MAIL command when the message
+    was received, the ENVID parameter MUST NOT be supplied when the
+    message is relayed.
+
+(b) Any RET parameter included in the MAIL command when a message was
+    received, MUST also appear on the MAIL command with which the
+    message is relayed, with the same associated esmtp-value.  If no RET
+    parameter was included in the MAIL command when the message was
+    received, the RET parameter MUST NOT supplied when the message is
+    relayed.
+
+
+
+Moore                       Standards Track                    [Page 10]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+(c) If the NOTIFY parameter was supplied for a recipient when the
+    message was received, the RCPT command issued when the message is
+    relayed MUST also contain the NOTIFY parameter along with its
+    associated esmtp-value.  If the NOTIFY parameter was not supplied
+    for a recipient when the message was received, the NOTIFY parameter
+    MUST NOT be supplied for that recipient when the message is relayed.
+
+(d) If any ORCPT parameter was present in the RCPT command for a
+    recipient when the message was received, an ORCPT parameter with the
+    identical original-recipient-address MUST appear in the RCPT command
+    issued for that recipient when relaying the message.  (For example,
+    the MTA therefore MUST NOT change the case of any alphabetic
+    characters in an ORCPT parameter.)
+
+    If no ORCPT parameter was present in the RCPT command when the
+    message was received, an ORCPT parameter MAY be added to the RCPT
+    command when the message is relayed.  If an ORCPT parameter is added
+    by the relaying MTA, it MUST contain the recipient address from the
+    RCPT command used when the message was received by that MTA.
+
+6.2.2  Relay of messages to non-conforming SMTP servers
+
+   The following rules govern the behavior of a conforming MTA (in the
+   role of client), when relaying a message which was received via the
+   SMTP protocol, to an SMTP server that does not support the Delivery
+   Status Notification service extension:
+
+(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when
+    relaying the message.
+
+(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp-
+    value containing the keyword SUCCESS, and the SMTP server returns a
+    success (2xx) reply-code in response to the RCPT command, the client
+    MUST issue a "relayed" DSN for that recipient.
+
+(c) If the NOTIFY parameter was supplied for a recipient with an esmtp-
+    value containing the keyword FAILURE, and the SMTP server returns a
+    permanent failure (5xx) reply-code in response to the RCPT command,
+    the client MUST issue a "failed" DSN for that recipient.
+
+(d) If the NOTIFY parameter was supplied for a recipient with an esmtp-
+    value of NEVER, the client MUST NOT issue a DSN for that recipient,
+    regardless of the reply-code returned by the SMTP server.  However,
+    if the server returned a failure (5xx) reply-code, the client MAY
+    inform the local postmaster of the delivery failure via an
+    appropriate mechanism that will not itself result in the generation
+    of DSNs.
+
+
+
+
+Moore                       Standards Track                    [Page 11]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+    When attempting to relay a message to an SMTP server that does not
+    support this extension, and if NOTIFY=NEVER was specified for some
+    recipients of that message, a conforming SMTP client MAY relay the
+    message for those recipients in a separate SMTP transaction, using
+    an empty reverse-path in the MAIL command.  This will prevent DSNs
+    from being issued for those recipients by MTAs that conform to [1].
+
+(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP
+    server returns a success (2xx) reply-code in response to a RCPT
+    command, the client MUST NOT issue any DSN for that recipient.
+
+(f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP
+    server returns a permanent failure (5xx) reply-code in response to a
+    RCPT command, the client MUST issue a "failed" DSN for that
+    recipient.
+
+6.2.3  Local delivery of messages
+
+   The following rules govern the behavior of a conforming MTA upon
+   successful delivery of a message that was received via the SMTP
+   protocol, to a local recipient's mailbox:
+
+   "Delivery" means that the message has been placed in the recipient's
+   mailbox.  For messages which are transmitted to a mailbox for later
+   retrieval via IMAP [6], POP [7] or a similar message access protocol,
+   "delivery" occurs when the message is made available to the IMAP
+   (POP, etc.) service, rather than when the message is retrieved by the
+   recipient's user agent.
+
+   Similarly, for a recipient address which corresponds to a mailing
+   list exploder, "delivery" occurs when the message is made available
+   to that list exploder, even though the list exploder might refuse to
+   deliver that message to the list recipients.
+
+(a) If the NOTIFY parameter was supplied for that recipient, with an
+    esmtp-value containing the SUCCESS keyword, the MTA MUST issue a
+    "delivered" DSN for that recipient.
+
+(b) If the NOTIFY parameter was supplied for that recipient which did
+    not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for
+    that recipient.
+
+(c) If the NOTIFY parameter was not supplied for that recipient, the MTA
+    MUST NOT issue a DSN.
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 12]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+6.2.4  Gatewaying a message into a foreign environment
+
+   The following rules govern the behavior of a conforming MTA, when
+   gatewaying a message that was received via the SMTP protocol, into a
+   foreign (non-SMTP) environment:
+
+(a) If the the foreign environment is capable of issuing appropriate
+    notifications under the conditions requested by the NOTIFY
+    parameter, and the conforming MTA can ensure that any notification
+    thus issued will be translated into a DSN and delivered to the
+    original sender, then the MTA SHOULD gateway the message into the
+    foreign environment, requesting notification under the desired
+    conditions, without itself issuing a DSN.
+
+(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the
+    destination environment cannot return an appropriate notification on
+    successful delivery, the MTA SHOULD issue a "relayed" DSN for that
+    recipient.
+
+(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a
+    DSN MUST NOT be issued.  If possible, the MTA SHOULD direct the
+    destination environment to not issue delivery notifications for that
+    recipient.
+
+(d) If the NOTIFY parameter was not supplied for a particular recipient,
+    a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD
+    attempt to ensure that appropriate notification will be provided by
+    the foreign mail environment if eventual delivery failure occurs,
+    and that no notification will be issued on successful delivery.
+
+(e) When gatewaying a message into a foreign environment, the return-of-
+    content conditions specified by any RET parameter are nonbinding;
+    however, the MTA SHOULD attempt to honor the request using whatever
+    mechanisms exist in the foreign environment.
+
+6.2.5  Delays in delivery
+
+   If a conforming MTA receives a message via the SMTP protocol, and is
+   unable to deliver or relay the message to one or more recipients for
+   an extended length of time (to be determined by the MTA), it MAY
+   issue a "delayed" DSN for those recipients, subject to the following
+   conditions:
+
+(a) If the NOTIFY parameter was supplied for a recipient and its value
+    included the DELAY keyword, a "delayed" DSN MAY be issued.
+
+(b) If the NOTIFY parameter was not supplied for a recipient, a
+    "delayed" DSN MAY be issued.
+
+
+
+Moore                       Standards Track                    [Page 13]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+(c) If the NOTIFY parameter was supplied which did not contain the DELAY
+    keyword, a "delayed" DSN MUST NOT be issued.
+
+   NOTE: Although delay notifications are common in present-day
+   electronic mail, a conforming MTA is never required to issue
+   "delayed" DSNs.  The DELAY keyword of the NOTIFY parameter is
+   provided to allow the SMTP client to specifically request (by
+   omitting the DELAY parameter) that "delayed" DSNs NOT be issued.
+
+6.2.6  Failure of a conforming MTA to deliver a message
+
+   The following rules govern the behavior of a conforming MTA which
+   received a message via the SMTP protocol, and is unable to deliver a
+   message to a recipient specified in the SMTP transaction:
+
+(a) If a NOTIFY parameter was supplied for the recipient with an esmtp-
+    keyword containing the value FAILURE, a "failed" DSN MUST be issued
+    by the MTA.
+
+(b) If a NOTIFY parameter was supplied for the recipient which did not
+    contain the value FAILURE, a DSN MUST NOT be issued for that
+    recipient.  However, the MTA MAY inform the local postmaster of the
+    delivery failure via some appropriate mechanism which does not
+    itself result in the generation of DSNs.
+
+(c) If no NOTIFY parameter was supplied for the recipient, a "failed"
+    DSN MUST be issued.
+
+   NOTE: Some MTAs are known to forward undeliverable messages to the
+   local postmaster or "dead letter" mailbox.  This is still considered
+   delivery failure, and does not diminish the requirement to issue a
+   "failed" DSN under the conditions defined elsewhere in this memo.  If
+   a DSN is issued for such a recipient, the Action value MUST be
+   "failed".
+
+6.2.7 Forwarding, aliases, and mailing lists
+
+   Delivery of a message to a local email address usually causes the
+   message to be stored in the recipient's mailbox.  However, MTAs
+   commonly provide a facility where a local email address can be
+   designated as an "alias" or "mailing list"; delivery to that address
+   then causes the message to be forwarded to each of the (local or
+   remote) recipient addresses associated with the alias or list.  It is
+   also common to allow a user to optionally "forward" her mail to one
+   or more alternate addresses.  If this feature is enabled, her mail is
+   redistributed to those addresses instead of being deposited in her
+   mailbox.
+
+
+
+
+Moore                       Standards Track                    [Page 14]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   Following the example of [9] (section 5.3.6), this document defines
+   the difference between an "alias" and "mailing list" as follows: When
+   forwarding a message to the addresses associated with an "alias", the
+   envelope return address (e.g. SMTP MAIL FROM) remains intact.
+   However, when forwarding a message to the addresses associated with a
+   "mailing list", the envelope return address is changed to that of the
+   administrator of the mailing list.  This causes DSNs and other
+   nondelivery reports resulting from delivery to the list members to be
+   sent to the list administrator rather than the sender of the original
+   message.
+
+   The DSN processing for aliases and mailing lists is as follows:
+
+6.2.7.1 mailing lists
+
+   When a message is delivered to a list submission address (i.e. placed
+   in the list's mailbox for incoming mail, or accepted by the process
+   that redistributes the message to the list subscribers), this is
+   considered final delivery for the original message.  If the NOTIFY
+   parameter for the list submission address contained the SUCCESS
+   keyword, a "delivered" DSN MUST be returned to the sender of the
+   original message.
+
+   NOTE: Some mailing lists are able to reject message submissions,
+   based on the content of the message, the sender's address, or some
+   other criteria.  While the interface between such a mailing list and
+   its MTA is not well-defined, it is important that DSNs NOT be issued
+   by both the MTA (to report successful delivery to the list), and the
+   list (to report message rejection using a "failure" DSN.)
+
+   However, even if a "delivered" DSN was issued by the MTA, a mailing
+   list which rejects a message submission MAY notify the sender that
+   the message was rejected using an ordinary message instead of a DSN.
+
+   Whenever a message is redistributed to an mailing list,
+
+(a) The envelope return address is rewritten to point to the list
+    maintainer.  This address MAY be that of a process that recognizes
+    DSNs and processes them automatically, but it MUST forward
+    unrecognized messages to the human responsible for the list.
+
+(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the
+    redistributed message MUST NOT be derived from those of the original
+    message.
+
+(c) The NOTIFY and RET parameters MAY be specified by the local
+    postmaster or the list administrator.  If ORCPT parameters are
+    supplied during redistribution to the list subscribers, they SHOULD
+
+
+
+Moore                       Standards Track                    [Page 15]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+    contain the addresses of the list subscribers in the format used by
+    the mailing list.
+
+6.2.7.2 single-recipient aliases
+
+   Under normal circumstances, when a message arrives for an "alias"
+   which has a single forwarding address, a DSN SHOULD NOT be issued.
+   Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with
+   the message as it is redistributed to the forwarding address.
+
+6.2.7.3 multiple-recipient aliases
+
+   An "alias" with multiple recipient addresses may be handled in any of
+   the following ways:
+
+(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when
+    relaying the message to any of the forwarding addresses.  If the
+    NOTIFY parameter for the alias contained the SUCCESS keyword, the
+    MTA issues a "relayed" DSN.  (In effect, the MTA treats the message
+    as if it were being relayed into an environment that does not
+    support DSNs.)
+
+(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent
+    requests if the message is gatewayed) are propagated to EXACTLY one
+    of the forwarding addresses.  No DSN is issued.  (This is
+    appropriate when aliasing is used to forward a message to a
+    "vacation" auto-responder program in addition to the local mailbox.)
+
+(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding
+    addresses associated with that alias.  The NOTIFY parameter is
+    propagated to the forwarding addresses, except that it any SUCCESS
+    keyword is removed.  If the original NOTIFY parameter for the alias
+    contained the SUCCESS keyword, an "expanded" DSN is issued for the
+    alias.  If the NOTIFY parameter for the alias did not contain the
+    SUCCESS keyword, no DSN is issued for the alias.
+
+6.2.7.4 confidential forwarding addresses
+
+   If it is desired to maintain the confidentiality of a recipient's
+   forwarding address, the forwarding may be treated as if it were a
+   mailing list.  A DSN will be issued, if appropriate, upon "delivery"
+   to the recipient address specified by the sender.  When the message
+   is forwarded it will have a new envelope return address. Any DSNs
+   which result from delivery failure of the forwarded message will not
+   be returned to the original sender of the message and thus not expose
+   the recipient's forwarding address.
+
+
+
+
+
+Moore                       Standards Track                    [Page 16]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+6.2.8 DSNs describing delivery to multiple recipients
+
+   A single DSN may describe attempts to deliver a message to multiple
+   recipients of that message.  If a DSN is issued for some recipients
+   in an SMTP transaction and not for others according to the rules
+   above, the DSN SHOULD NOT contain information for recipients for whom
+   DSNs would not otherwise have been issued.
+
+6.3 Handling of messages from other sources
+
+   For messages which originated from "local" users (whatever that
+   means), the specifications under which DSNs should be generated can
+   be communicated to the MTA via any protocol agreed on between the
+   sender's mail composer (user agent) and the MTA.  The local MTA can
+   then either relay the message, or issue appropriate delivery status
+   notifications.  However, if such requests are transmitted within the
+   message itself (for example in the message headers), the requests
+   MUST be removed from the message before it is transmitted via SMTP.
+
+   For messages gatewayed from non-SMTP sources and further relayed by
+   SMTP, the gateway SHOULD, using the SMTP extensions described here,
+   attempt to provide the delivery reporting conditions expected by the
+   source mail environment.  If appropriate, any DSNs returned to the
+   source environment SHOULD be translated into the format expected in
+   that environment.
+
+6.4  Implementation limits
+
+   A conforming MTA MUST accept ESMTP parameters of at least the
+   following sizes:
+
+   (a) ENVID parameter: 100 characters.
+
+   (b) NOTIFY parameter: 28 characters.
+
+   (c) ORCPT parameter: 500 characters.
+
+   (d) RET parameter: 8 characters.
+
+   The maximum sizes for the ENVID and ORCPT parameters are intended to
+   be adequate for the transmission of "foreign" envelope identifier and
+   original recipient addresses.  However, user agents which use SMTP as
+   a message submission protocol SHOULD NOT generate ENVID parameters
+   which are longer than 38 characters in length.
+
+   A conforming MTA MUST be able to accept SMTP command-lines which are
+   at least 1036 characters long (530 characters for the ORCPT and
+   NOTIFY parameters of the RCPT command, in addition to the 512
+
+
+
+Moore                       Standards Track                    [Page 17]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   characters required by [1]).  If other SMTP extensions are supported
+   by the MTA, the MTA MUST be able to accept a command-line large
+   enough for each SMTP command and any combination of ESMTP parameters
+   which may be used with that command.
+
+7.  Format of delivery notifications
+
+   The format of delivery status notifications is defined in [5], which
+   uses the framework defined in [8].  Delivery status notifications are
+   to be returned to the sender of the original message as outlined
+   below.
+
+7.1 SMTP Envelope to be used with delivery status notifications
+
+   The DSN sender address (in the SMTP MAIL command) MUST be a null
+   reverse-path ("<>"), as required by section 5.3.3 of [9].  The DSN
+   recipient address (in the RCPT command) is copied from the MAIL
+   command which accompanied the message for which the DSN is being
+   issued.  When transmitting a DSN via SMTP, the RET parameter MUST NOT
+   be used.  The NOTIFY parameter MAY be used, but its value MUST be
+   NEVER.  The ENVID parameter (with a newly generated envelope-id)
+   and/or ORCPT parameter MAY be used.
+
+7.2 Contents of the DSN
+
+   A DSN is transmitted as a MIME message with a top-level content-type
+   of multipart/report (as defined in [5]).
+
+   The multipart/report content-type may be used for any of several
+   kinds of reports generated by the mail system.  When multipart/report
+   is used to convey a DSN, the report-type parameter of the
+   multipart/report content-type is "delivery-status".
+
+   As described in [8], the first component of a multipart/report
+   content-type is a human readable explanation of the report.  For a
+   DSN, the second component of the multipart/report is of content-type
+   message/delivery-status (defined in [5]).  The third component of the
+   multipart/report consists of the original message or some portion
+   thereof.  When the value of the RET parameter is FULL, the full
+   message SHOULD be returned for any DSN which conveys notification of
+   delivery failure.  (However, if the length of the message is greater
+   than some implementation-specified length, the MTA MAY return only
+   the headers even if the RET parameter specified FULL.)  If a DSN
+   contains no notifications of delivery failure, the MTA SHOULD return
+   only the headers.
+
+   The third component must have an appropriate content-type label.
+   Issues concerning selection of the content-type are discussed in [8].
+
+
+
+Moore                       Standards Track                    [Page 18]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+7.3 Message/delivery-status fields
+
+   The message/delivery-status content-type defines a number of fields,
+   with general specifications for their contents.  The following
+   requirements for any DSNs generated in response to a message received
+   by the SMTP protocol by a conforming SMTP server, are in addition to
+   the requirements defined in [5] for the message/delivery-status type.
+
+   When generating a DSN for a message which was received via the SMTP
+   protocol, a conforming MTA will generate the following fields of the
+   message/delivery-status body part:
+
+(a) if an ENVID parameter was present on the MAIL command, an Original-
+    Envelope-ID field MUST be supplied, and the value associated with
+    the ENVID parameter must appear in that field.  If the message was
+    received via SMTP with no ENVID parameter, the Original-Envelope-ID
+    field MUST NOT be supplied.
+
+    Since the ENVID parameter is encoded as xtext, but the Original-
+    Envelope-ID header is NOT encoded as xtext, the MTA must decode the
+    xtext encoding when copying the ENVID value to the Original-
+    Envelope-ID field.
+
+(b) The Reporting-MTA field MUST be supplied.  If Reporting MTA can
+    determine its fully-qualified Internet domain name, the MTA-name-
+    type subfield MUST be "dns", and the field MUST contain the fully-
+    qualified domain name of the Reporting MTA. If the fully-qualified
+    Internet domain name of the Reporting MTA is not known (for example,
+    for an SMTP server which is not directly connected to the Internet),
+    the Reporting-MTA field may contain any string identifying the MTA,
+    however, in this case the MTA-name-type subfield MUST NOT be "dns".
+    A MTA-name-type subfield value of "x-local-hostname" is suggested.
+
+(c) Other per-message fields as defined in [5] MAY be supplied as
+    appropriate.
+
+(d) If the ORCPT parameter was provided for this recipient, the
+    Original-Recipient field MUST be supplied, with its value taken from
+    the ORCPT parameter.  If no ORCPT parameter was provided for this
+    recipient, the Original-Recipient field MUST NOT appear.
+
+(e) The Final-Recipient field MUST be supplied. It MUST contain the
+    recipient address from the message envelope.  If the message was
+    received via SMTP, the address-type will be "rfc822".
+
+(f) The Action field MUST be supplied.
+
+
+
+
+
+Moore                       Standards Track                    [Page 19]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+(g) The Status field MUST be supplied, using a status-code from [10].
+    If there is no specific code which suitably describes a delivery
+    failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent
+    failure) MUST be used.
+
+(h) For DSNs resulting from attempts to relay a message to one or more
+    recipients via SMTP, the Remote-MTA field MUST be supplied for each
+    of those recipients.  The mta-name-type subfields of those Remote-
+    MTA fields will be "dns".
+
+(i) For DSNs resulting from attempts to relay a message to one or more
+    recipients via SMTP, the Diagnostic-Code MUST be supplied for each
+    of those recipients.  The diagnostic-type subfield will be "smtp".
+    See section 9.2(a) of this document for a description of the "smtp"
+    diagnostic-code.
+
+(j) For DSNs resulting from attempts to relay a message to one or more
+    recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be
+    supplied for each recipient, which contains the address of that
+    recpient which was presented to the remote SMTP server.
+
+(k) Other per-recipient fields defined in [5] MAY appear, as
+    appropriate.
+
+8. Acknowledgments
+
+   The author wishes to thank Eric Allman, Harald Alvestrand, Jim
+   Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned
+   Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios
+   Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall
+   Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for
+   improvement of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 20]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+9. Appendix - Type-Name Definitions
+
+   The following type names are defined for use in DSN fields generated
+   by conforming SMTP-based MTAs:
+
+9.1 "rfc822" address-type
+
+   The "rfc822" address-type is to be used when reporting Internet
+   electronic mail address in the Original-Recipient and Final-Recipient
+   DSN fields.
+
+(a) address-type name: rfc822
+
+(b) syntax for mailbox addresses
+
+    RFC822 mailbox addresses are generally expected to be of the form
+
+    [route] addr-spec
+
+    where "route" and "addr-spec" are defined in [2], and the "domain"
+    portions of both "route" and "addr-spec" are fully-qualified domain
+    names that are registered in the DNS.  However, an MTA MUST NOT
+    modify an address obtained from the message envelope to force it to
+    conform to syntax rules.
+
+(c) If addresses of this type are not composed entirely of graphic
+characters from the US-ASCII repertoire, a specification for how they
+are to be encoded as graphic US-ASCII characters in a DSN Original-
+Recipient or Final-Recipient DSN field.
+
+    RFC822 addresses consist entirely of graphic characters from the US-
+    ASCII repertoire, so no translation is necessary.
+
+9.2 "smtp" diagnostic-type
+
+   The "smtp" diagnostic-type is to be used when reporting SMTP reply-
+   codes in Diagnostic-Code DSN fields.
+
+(a) diagnostic-type name: SMTP
+
+(b) A description of the syntax to be used for expressing diagnostic
+codes of this type as graphic characters from the US-ASCII repertoire.
+
+    An SMTP diagnostic-code is of the form
+
+    *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text
+
+
+
+
+
+Moore                       Standards Track                    [Page 21]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+    For a single-line SMTP reply to an SMTP command, the diagnostic-code
+    SHOULD be an exact transcription of the reply.  For multi-line SMTP
+    replies, it is necessary to insert a SPACE before each line after
+    the first.  For example, an SMTP reply of:
+
+    550-mailbox unavailable
+    550 user has moved with no forwarding address
+
+    could appear as follows in a Diagnostic-Code DSN field:
+
+    Diagnostic-Code: smtp ; 550-mailbox unavailable
+     550 user has moved with no forwarding address
+
+(c) A list of valid diagnostic codes of this type and the meaning of
+each code.
+
+    SMTP reply-codes are currently defined in [1], [4], and [9].
+    Additional codes may be defined by other RFCs.
+
+9.3 "dns" MTA-name-type
+
+   The "dns" MTA-name-type should be used in the Reporting-MTA field.
+   An MTA-name of type "dns" is a fully-qualified domain name.  The name
+   must be registered in the DNS, and the address Postmaster@{mta-name}
+   must be valid.
+
+(a) MTA-name-type name: dns
+
+(b) A description of the syntax of MTA names of this type, using BNF,
+regular expressions, ASN.1, or other non-ambiguous language.
+
+    MTA names of type "dns" SHOULD be valid Internet domain names.  If
+    such domain names are not available, a domain-literal containing the
+    internet protocol address is acceptable.  Such domain names
+    generally conform to the following syntax:
+
+    domain = real-domain / domain-literal
+
+    real-domain = sub-domain *("." sub-domain)
+
+    sub-domain = atom
+
+    domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
+
+    where "atom" and "DIGIT" are defined in [2].
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 22]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+(c) If MTA names of this type do not consist entirely of graphic
+characters from the US-ASCII repertoire, a specification for how an MTA
+name of this type should be expressed as a sequence of graphic US-ASCII
+characters.
+
+    MTA names of type "dns" consist entirely of graphic US-ASCII
+    characters, so no translation is needed.
+
+10. Appendix - Example
+
+   This example traces the flow of a single message addressed to
+   multiple recipients.  The message is sent by Alice@Pure-Heart.ORG to
+   Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU,
+   Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a
+   variety of per-recipient options.  The message is successfully
+   delivered to Bob, Dana (via a gateway), Eric, and Fred.  Delivery
+   fails for Carol and George.
+
+   NOTE: Formatting rules for RFCs require that no line be longer than
+   72 characters.  Therefore, in the following examples, some SMTP
+   commands longer than 72 characters are printed on two lines, with the
+   first line ending in "\".  In an actual SMTP transaction, such a
+   command would be sent as a single line (i.e. with no embedded CRLFs),
+   and without the "\" character that appears in these examples.
+
+10.1 Submission
+
+   Alice's user agent sends the message to the SMTP server at Pure-
+   Heart.ORG.  Note that while this example uses SMTP as a mail
+   submission protocol, other protocols could also be used.
+
+<<< 220 Pure-Heart.ORG SMTP server here
+>>> EHLO Pure-Heart.ORG
+<<< 250-Pure-Heart.ORG
+<<< 250-DSN
+<<< 250-EXPN
+<<< 250 SIZE
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 <Alice@Pure-Heart.ORG> sender ok
+>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
+    ORCPT=rfc822;Bob@Big-Bucks.COM
+<<< 250 <Bob@Big-Bucks.COM> recipient ok
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
+    ORCPT=rfc822;Carol@Ivory.EDU
+<<< 250 <Carol@Ivory.EDU> recipient ok
+>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
+    ORCPT=rfc822;Dana@Ivory.EDU
+<<< 250 <Dana@Ivory.EDU> recipient ok
+
+
+
+Moore                       Standards Track                    [Page 23]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+>>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
+    ORCPT=rfc822;Eric@Bombs.AF.MIL
+<<< 250 <Eric@Bombs.AF.MIL> recipient ok
+>>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
+<<< 250 <Fred@Bombs.AF.MIL> recipient ok
+>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
+    ORCPT=rfc822;George@Tax-ME.GOV
+<<< 250 <George@Tax-ME.GOV> recipient ok
+>>> DATA
+<<< 354 okay, send message
+>>> (message goes here)
+>>> .
+<<< 250 message accepted
+>>> QUIT
+<<< 221 goodbye
+
+10.2 Relay to Big-Bucks.COM
+
+   The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM.
+   (For the purpose of this example, mail.Big-Bucks.COM is the primary
+   mail exchanger for Big-Bucks.COM).
+
+<<< 220 mail.Big-Bucks.COM says hello
+>>> EHLO Pure-Heart.ORG
+<<< 250-mail.Big-Bucks.COM
+<<< 250 DSN
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 sender okay
+>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
+    ORCPT=rfc822;Bob@Big-Bucks.COM
+<<< 250 recipient okay
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message received
+>>> QUIT
+<<< 221 bcnu
+
+10.3 Relay to Ivory.EDU
+
+   The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as
+   it happens) is a gateway to a LAN-based mail system that accepts SMTP
+   mail and supports the DSN extension.
+
+<<< 220 Ivory.EDU gateway to FooMail(tm) here
+>>> EHLO Pure-Heart.ORG
+<<< 250-Ivory.EDU
+
+
+
+Moore                       Standards Track                    [Page 24]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+<<< 250 DSN
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 ok
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
+    ORCPT=rfc822;Carol@Ivory.EDU
+<<< 550 error - no such recipient
+>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
+    ORCPT=rfc822;Dana@Ivory.EDU
+<<< 250 recipient ok
+>>> DATA
+<<< 354 send message, end with '.'
+>>> (message goes here)
+>>> .
+<<< 250 message received
+>>> QUIT
+<<< 221 bye
+
+   Note that since the Ivory.EDU refused to accept mail for
+   Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the
+   sender-SMTP (in this case Pure-Heart.ORG) must generate a DSN.
+
+10.4 Relay to Bombs.AF.MIL
+
+   The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which
+   does not support the SMTP extension.  Because the sender specified
+   NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure-
+   Heart.ORG chooses to send the message for that recipient in a
+   separate transaction with a reverse-path of <>.
+
+<<< 220-Bombs.AF.MIL reporting for duty.
+<<< 220 Electronic mail is to be used for official business only.
+>>> EHLO Pure-Heart.ORG
+<<< 502 command not implemented
+>>> RSET
+<<< 250 reset
+>>> HELO Pure-Heart.ORG
+<<< 250 Bombs.AF.MIL
+>>> MAIL FROM:<Alice@Pure-Heart.ORG>
+<<< 250 ok
+>>> RCPT TO:<Eric@Bombs.AF.MIL>
+<<< 250 ok
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message accepted
+>>> MAIL FROM:<>
+<<< 250 ok
+
+
+
+Moore                       Standards Track                    [Page 25]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+>>> RCPT TO:<Fred@Bombs.AF.MIL>
+<<< 250 ok
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message accepted
+>>> QUIT
+<<< 221 Bombs.AF.MIL closing connection
+
+10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV
+
+   The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV.  (this
+   step is not shown).  MTA Tax-ME.GOV then forwards the message to
+   Sam@Boondoggle.GOV (shown below).  Both Tax-ME.GOV and Pure-Heart.ORG
+   support the SMTP DSN extension.  Note that RET, ENVID, and ORCPT all
+   retain their original values.
+
+<<< 220 BoonDoggle.GOV says hello
+>>> EHLO Pure-Heart.ORG
+<<< 250-mail.Big-Bucks.COM
+<<< 250 DSN
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 sender okay
+>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
+    ORCPT=rfc822;George@Tax-ME.GOV
+<<< 250 recipient okay
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message received
+>>> QUIT
+<<< 221 bcnu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 26]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+10.6 "Delivered" DSN for Bob@Big-Bucks.COM
+
+   MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big-
+   Bucks.COM.  Because the sender specified NOTIFY=SUCCESS, mail.Big-
+   Bucks.COM issues the following DSN, and sends it to Alice@Pure-
+   Heart.ORG.
+
+To: Alice@Pure-Heart.ORG
+From: postmaster@mail.Big-Bucks.COM
+Subject: Delivery Notification (success) for Bob@Big-Bucks.COM
+Content-Type: multipart/report; report-type=delivery-status;
+    boundary=abcde
+MIME-Version: 1.0
+
+--abcde
+Content-type: text/plain; charset=us-ascii
+
+Your message (id QQ314159) was successfully delivered to
+Bob@Big-Bucks.COM.
+
+--abcde
+Content-type: message/delivery-status
+
+Reporting-MTA: dns; mail.Big-Bucks.COM
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;Bob@Big-Bucks.COM
+Final-Recipient: rfc822;Bob@Big-Bucks.COM
+Action: delivered
+Status: 2.0.0
+
+--abcde
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--abcde--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 27]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+10.7 Failed DSN for Carol@Ivory.EDU
+
+   Because delivery to Carol failed and the sender specified
+   NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP
+   client to which the failure was reported via SMTP) issues the
+   following DSN.
+
+To: Alice@Pure-Heart.ORG
+From: postmaster@Pure-Heart.ORG
+Subject: Delivery Notification (failure) for Carol@Ivory.EDU
+Content-Type: multipart/report; report-type=delivery-status;
+              boundary=bcdef
+MIME-Version: 1.0
+
+--bcdef
+Content-type: text/plain; charset=us-ascii
+
+Your message (id QQ314159) could not be delivered to
+Carol@Ivory.EDU.
+
+A transcript of the session follows:
+
+(while talking to Ivory.EDU)
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE
+<<< 550 error - no such recipient
+
+--bcdef
+Content-type: message/delivery-status
+
+Reporting-MTA: dns; Pure-Heart.ORG
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;Carol@Ivory.EDU
+Final-Recipient: rfc822;Carol@Ivory.EDU
+SMTP-Remote-Recipient: Carol@Ivory.EDU
+Diagnostic-Code: smtp; 550 error - no such recipient
+Action: failed
+Status: 5.0.0
+
+--bcdef
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--bcdef--
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 28]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+10.8 Relayed DSN For Dana@Ivory.EDU
+
+   Although the mail gateway Ivory.EDU supports the DSN SMTP extension,
+   the LAN mail system attached to its other side does not generate
+   positive delivery confirmations.  So Ivory.EDU issues a "relayed"
+   DSN:
+
+To: Alice@Pure-Heart.ORG
+From: postmaster@Ivory.EDU
+Subject: mail relayed for Dana@Ivory.EDU
+Content-Type: multipart/report; report-type=delivery-status;
+    boundary=cdefg
+MIME-Version: 1.0
+
+--cdefg
+Content-type: text/plain; charset=us-ascii
+
+Your message (addressed to Dana@Ivory.EDU) was successfully
+relayed to:
+
+ymail!Dana
+
+by the FooMail gateway at Ivory.EDU.
+
+Unfortunately, the remote mail system does not support
+confirmation of actual delivery.  Unless delivery to ymail!Dana
+fails, this will be the only delivery status notification sent.
+
+--cdefg
+Content-type: message/delivery-status
+
+Reporting-MTA: dns; Ivory.EDU
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;Dana@Ivory.EDU
+Final-Recipient: rfc822;Dana@Ivory.EDU
+Action: relayed
+Status: 2.0.0
+
+--cdefg
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--cdefg--
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 29]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+10.9 Failure notification for Sam@Boondoggle.GOV
+
+   The message originally addressed to George@Tax-ME.GOV was forwarded
+   to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to
+   deliver the message due to a lack of disk space in Sam's mailbox.
+   After trying for several days, Boondoggle.GOV returned the following
+   DSN:
+
+To: Alice@BigHeart.ORG
+From: Postmaster@Boondoggle.GOV
+Subject: Delivery failure for Sam@Boondoggle.GOV
+Content-Type: multipart/report; report-type=delivery-status;
+              boundary=defgh
+MIME-Version: 1.0
+
+--defgh
+Your message, originally addressed to George@Tax-ME.GOV, and forwarded
+from there to Sam@Boondoggle.GOV could not be delivered, for the
+following reason:
+
+write error to mailbox, disk quota exceeded
+
+--defgh
+Content-type: message/delivery-status
+
+Reporting-MTA: Boondoggle.GOV
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;George@Tax-ME.GOV
+Final-Recipient: rfc822;Sam@Boondoggle.GOV
+Action: failed
+Status: 4.2.2 (disk quota exceeded)
+
+--defgh
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--defgh--
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 30]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+11. References
+
+   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+       USC/Information Sciences Institute, August 1982.
+
+   [2] Crocker, D., "Standard for the Format of ARPA Internet Text
+       Messages", STD 11, RFC 822, UDEL, August 1982.
+
+   [3] Westine, A., and J. Postel, "Problems with the Maintenance of
+       Large Mailing Lists.", RFC 1211, USC/Information Sciences
+       Institute, March 1991.
+
+   [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
+       "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
+       Consulting, Inc., Network Management Associates, Inc., Silicon
+       Graphics, Inc., July 1994.
+
+   [5] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+       Delivery Status Notifications", RFC 1894, University of Tennessee,
+       Octel Network Services, January 1996.
+
+   [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
+       1730, University of Washington, 20 December 1994.
+
+   [7] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
+       1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
+
+   [8] Vaudreuil, G., "The Multipart/Report Content Type for the
+       Reporting of Mail System Administrative Messages", RFC 1892, Octel
+       Network Services, January 1996.
+
+   [9] Braden, R., Editor, "Requirements for Internet Hosts - Application
+       and Support", STD 3, RFC 1123, IETF, October 1989.
+
+   [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+        Octel Network Services, January 1996.
+
+12. Author's Address
+
+   Keith Moore
+   University of Tennessee
+   107 Ayres Hall
+   Knoxville, TN 37996-1301
+   USA
+
+   EMail: moore@cs.utk.edu
+
+
+
+
+
+Moore                       Standards Track                    [Page 31]
+
diff --git a/RFC/rfc1892.txt b/RFC/rfc1892.txt
new file mode 100644
index 00000000..c4bdbd5f
--- /dev/null
+++ b/RFC/rfc1892.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                       G. Vaudreuil
+Request for Comments: 1892                        Octel Network Services
+Category: Standards Track                                   January 1996
+
+
+                   The Multipart/Report Content Type
+                          for the Reporting of
+                  Mail System Administrative Messages
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1. The Multipart/Report MIME content-type
+
+   The Multipart/Report MIME content-type is a general "family" or
+   "container" type for electronic mail reports of any kind. Although
+   this memo defines only the use of the Multipart/Report content-type
+   with respect to delivery status reports, mail processing programs
+   will benefit if a single content-type is used to for all kinds of
+   reports.
+
+   The Multipart/Report content-type is defined as follows:
+
+             MIME type name: multipart
+             MIME subtype name: report
+             Required parameters: boundary, report-type
+             Optional parameters: none
+             Encoding considerations: 7bit should always be adequate
+             Security considerations: see section 4 of this memo.
+
+   The syntax of Multipart/Report is identical to the Multipart/Mixed
+   content type defined in [MIME].  When used to send a report, the
+   Multipart/Report content-type must be the top-level MIME content type
+   for any report message.  The report-type parameter identifies the
+   type of report.  The parameter is the MIME content sub-type of the
+   second body part of the Multipart/Report.
+
+      User agents and gateways must be able to automatically determine
+      that a message is a mail system report and should be processed as
+      such.  Placing the Multipart/Report as the outermost content
+      provides a mechanism whereby an auto-processor may detect through
+      parsing the RFC 822 headers that the message is a report.
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 1]
+
+RFC 1892                    Multipart/Report                January 1996
+
+
+   The Multipart/Report content-type contains either two or three sub-
+   parts, in the following order:
+
+   (1) [required]  The first body part contains human readable message.
+       The purpose of this message is to provide an easily-understood
+       description of the condition(s) that caused the report to be
+       generated, for a human reader who may not have an user agent
+       capable of interpreting the second section of the
+       Multipart/Report.
+
+       The text in the first section may be in any MIME standards-track
+       content-type, charset, or language.  Where a description of the
+       error is desired in several languages or several media, a
+       Multipart/Alternative construct may be used.
+
+       This body part may also be used to send detailed information
+       that cannot be easily formatted into a Message/Report body part.
+
+   (2) [required]  A machine parsable body part containing an account
+       of the reported message handling event. The purpose of this body
+       part is to provide a machine-readable description of the
+       condition(s) which caused the report to be generated, along with
+       details not present in the first body part that may be useful to
+       human experts.  An initial body part, Message/delivery-status is
+       defined in [DSN]
+
+   (3) [optional]  A body part containing the returned message or a
+       portion thereof.  This information may be useful to aid human
+       experts in diagnosing problems.  (Although it may also be useful
+       to allow the sender to identify the message which the report was
+       issued, it is hoped that the envelope-id and original-recipient-
+       address returned in the Message/Report body part will replace
+       the traditional use of the returned content for this purpose.)
+
+   Return of content may be wasteful of network bandwidth and a variety
+   of implementation strategies can be used.  Generally the sender
+   should choose the appropriate strategy and inform the recipient of
+   the required level of returned content required.  In the absence of
+   an explicit request for level of return of content such as that
+   provided in [DRPT], the agent which generated the delivery service
+   report should return the full message content.
+
+   When data not encoded in 7 bits is to be returned, and the return
+   path is not guaranteed to be 8-bit capable, two options are
+   available.  The origional message MAY be reencoded into a legal 7 bit
+   MIME message or the Text/RFC822-Headers content-type MAY be used to
+   return only the origional message headers.
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 2]
+
+RFC 1892                    Multipart/Report                January 1996
+
+
+2. The Text/RFC822-Headers MIME content-type
+
+   The Text/RFC822-Headers MIME content-type provides a mechanism to
+   label and return only the RFC 822 headers of a failed message.  These
+   headers are not the complete message and should not be returned as a
+   Message/RFC822.  The returned headers are useful for identifying the
+   failed message and for diagnostics based on the received: lines.
+
+   The Text/RFC822-Headers content-type is defined as follows:
+
+          MIME type name: Text
+          MIME subtype name: RFC822-Headers
+          Required parameters: None
+          Optional parameters: none
+          Encoding considerations: 7 bit is sufficient for normal RFC822
+                 headers, however, if the headers are broken and require
+                 encoding, they may be encoded in quoted-printable.
+          Security considerations: see section 4 of this memo.
+
+   The Text/RFC822-headers body part should contain all the RFC822
+   header lines from the message which caused the report.  The RFC822
+   headers include all lines prior to the blank line in the message.
+   They include the MIME-Version and MIME Content- headers.
+
+3. References
+
+   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+       Delivery Status Notifications", RFC 1894, University of
+       Tennessee, Octel Network Services, January 1996.
+
+   [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
+       Messages", STD 11, RFC 822, UDEL, August 1982.
+
+   [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+       Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
+
+   [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
+       Notifications", RFC 1891, University of Tennessee, January 1996.
+
+4. Security Considerations
+
+   Automated use of report types without authentication presents several
+   security issues.  Forging negative reports presents the opportunity
+   for denial-of-service attacks when the reports are used for automated
+   maintenance of directories or mailing lists.  Forging positive
+   reports may cause the sender to incorrectly believe a message was
+   delivered when it was not.
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 3]
+
+RFC 1892                    Multipart/Report                January 1996
+
+
+5. Author's Address
+
+   Gregory M. Vaudreuil
+   Octel Network Services
+   17060 Dallas Parkway
+   Dallas, TX 75248-1905
+
+   Phone: +1-214-733-2722
+   EMail: Greg.Vaudreuil@Octel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 4]
+
diff --git a/RFC/rfc1893.txt b/RFC/rfc1893.txt
new file mode 100644
index 00000000..9ca4efb5
--- /dev/null
+++ b/RFC/rfc1893.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                        G. Vaudreuil
+Request for Comments: 1893                         Octel Network Services
+Category: Standards Track                                    January 1996
+
+
+                   Enhanced Mail System Status Codes
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1.   Overview
+
+   There currently is not a standard mechanism for the reporting of mail
+   system errors except for the limited set offered by SMTP and the
+   system specific text descriptions sent in mail messages.  There is a
+   pressing need for a rich machine readable status code for use in
+   delivery status notifications [DSN].  This document proposes a new
+   set of status codes for this purpose.
+
+   SMTP [SMTP] error codes have historically been used for reporting
+   mail system errors.  Because of limitations in the SMTP code design,
+   these are not suitable for use in delivery status notifications.
+   SMTP provides about 12 useful codes for delivery reports.  The
+   majority of the codes are protocol specific response codes such as
+   the 354 response to the SMTP data command.  Each of the 12 useful
+   codes are each overloaded to indicate several error conditions each.
+   SMTP suffers some scars from history, most notably the unfortunate
+   damage to the reply code extension mechanism by uncontrolled use.
+   This proposal facilitates future extensibility by requiring the
+   client to interpret unknown error codes according to the theory of
+   codes while requiring servers to register new response codes.
+
+   The SMTP theory of reply codes partitioned in the number space such a
+   manner that the remaining available codes will not provide the space
+   needed.  The most critical example is the existence of only 5
+   remaining codes for mail system errors.  The mail system
+   classification includes both host and mailbox error conditions.  The
+   remaining third digit space would be completely consumed as needed to
+   indicate MIME and media conversion errors and security system errors.
+
+   A revision to the SMTP theory of reply codes to better distribute the
+   error conditions in the number space will necessarily be incompatible
+   with SMTP.  Further, consumption of the remaining reply-code number
+
+
+
+Vaudreuil                   Standards Track                     [Page 1]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+   space for delivery notification reporting will reduce the available
+   codes for new ESMTP extensions.
+
+   The following proposal is based on the SMTP theory of reply codes.
+   It adopts the success, permanent error, and transient error semantics
+   of the first value, with a further description and classification in
+   the second.  This proposal re-distributes the classifications to
+   better distribute the error conditions, such as separating mailbox
+   from host errors.
+
+2.   Status Codes
+
+   This document defines a new set of status codes to report mail system
+   conditions.  These status codes are intended to be used for media and
+   language independent status reporting.  They are not intended for
+   system specific diagnostics.
+
+   The syntax of the new status codes is defined as:
+
+          status-code = class "." subject "." detail
+          class = "2"/"4"/"5"
+          subject = 1*3digit
+          detail = 1*3digit
+
+   White-space characters and comments are NOT allowed within a status-
+   code.  Each numeric sub-code within the status-code MUST be expressed
+   without leading zero digits.
+
+   Status codes consist of three numerical fields separated by ".". The
+   first sub-code indicates whether the delivery attempt was successful.
+   The second sub-code indicates the probable source of any delivery
+   anomalies, and the third sub-code indicates a precise error
+   condition.
+
+   The codes space defined is intended to be extensible only by
+   standards track documents.  Mail system specific status codes should
+   be mapped as close as possible to the standard status codes.  Servers
+   should send only defined, registered status codes.  System specific
+   errors and diagnostics should be carried by means other than status
+   codes.
+
+   New subject and detail codes will be added over time.  Because the
+   number space is large, it is not intended that published status codes
+   will ever be redefined or eliminated.  Clients should preserve the
+   extensibility of the code space by reporting the general error
+   described in the subject sub-code when the specific detail is
+   unrecognized.
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 2]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+   The class sub-code provides a broad classification of the status.
+   The enumerated values the class are defined as:
+
+    2.X.X   Success
+
+       Success specifies that the DSN is reporting a positive delivery
+       action.  Detail sub-codes may provide notification of
+       transformations required for delivery.
+
+    4.X.X   Persistent Transient Failure
+
+       A persistent transient failure is one in which the message as
+       sent is valid, but some temporary event prevents the successful
+       sending of the message.  Sending in the future may be successful.
+
+    5.X.X   Permanent Failure
+
+       A permanent failure is one which is not likely to be resolved by
+       resending the message in the current form.  Some change to the
+       message or the destination must be made for successful delivery.
+
+   A client must recognize and report class sub-code even where
+   subsequent subject sub-codes are unrecognized.
+
+   The subject sub-code classifies the status.  This value applies to
+   each of the three classifications.  The subject sub-code, if
+   recognized, must be reported even if the additional detail provided
+   by the detail sub-code is not recognized.  The enumerated values for
+   the subject sub-code are:
+
+       X.0.X   Other or Undefined Status
+
+          There is no additional subject information available.
+
+       X.1.X   Addressing Status
+
+          The address status reports on the originator or destination
+          address.  It may include address syntax or validity.  These
+          errors can generally be corrected by the sender and retried.
+
+       X.2.X   Mailbox Status
+
+          Mailbox status indicates that something having to do with the
+          mailbox has cause this DSN.  Mailbox issues are assumed to be
+          under the general control of the recipient.
+
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 3]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+       X.3.X   Mail System Status
+
+          Mail system status indicates that something having to do
+          with the destination system has caused this DSN.  System
+          issues are assumed to be under the general control of the
+          destination system administrator.
+
+       X.4.X   Network and Routing Status
+
+          The networking or routing codes report status about the
+          delivery system itself.  These system components include any
+          necessary infrastructure such as directory and routing
+          services.  Network issues are assumed to be under the
+          control of the destination or intermediate system
+          administrator.
+
+       X.5.X   Mail Delivery Protocol Status
+
+          The mail delivery protocol status codes report failures
+          involving the message delivery protocol.  These failures
+          include the full range of problems resulting from
+          implementation errors or an unreliable connection.  Mail
+          delivery protocol issues may be controlled by many parties
+          including the originating system, destination system, or
+          intermediate system administrators.
+
+       X.6.X   Message Content or Media Status
+
+          The message content or media status codes report failures
+          involving the content of the message.  These codes report
+          failures due to translation, transcoding, or otherwise
+          unsupported message media.  Message content or media issues
+          are under the control of both the sender and the receiver,
+          both of whom must support a common set of supported
+          content-types.
+
+       X.7.X   Security or Policy Status
+
+          The security or policy status codes report failures
+          involving policies such as per-recipient or per-host
+          filtering and cryptographic operations.  Security and policy
+          status issues are assumed to be under the control of either
+          or both the sender and recipient.  Both the sender and
+          recipient must permit the exchange of messages and arrange
+          the exchange of necessary keys and certificates for
+          cryptographic operations.
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 4]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+3.   Enumerated Status Codes
+
+   The following section defines and describes the detail sub-code. The
+   detail value provides more information about the status and is
+   defined relative to the subject of the status.
+
+   3.1 Other or Undefined Status
+
+       X.0.0   Other undefined Status
+
+          Other undefined status is the only undefined error code. It
+          should be used for all errors for which only the class of the
+          error is known.
+
+   3.2 Address Status
+
+       X.1.0   Other address status
+
+          Something about the address specified in the message caused
+          this DSN.
+
+       X.1.1   Bad destination mailbox address
+
+          The mailbox specified in the address does not exist.  For
+          Internet mail names, this means the address portion to the
+          left of the "@" sign is invalid.  This code is only useful
+          for permanent failures.
+
+       X.1.2   Bad destination system address
+
+          The destination system specified in the address does not
+          exist or is incapable of accepting mail.  For Internet mail
+          names, this means the address portion to the right of the
+          "@" is invalid for mail.  This codes is only useful for
+          permanent failures.
+
+       X.1.3   Bad destination mailbox address syntax
+
+          The destination address was syntactically invalid.  This can
+          apply to any field in the address.  This code is only useful
+          for permanent failures.
+
+       X.1.4   Destination mailbox address ambiguous
+
+          The mailbox address as specified matches one or more
+          recipients on the destination system.  This may result if a
+          heuristic address mapping algorithm is used to map the
+          specified address to a local mailbox name.
+
+
+
+Vaudreuil                   Standards Track                     [Page 5]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+       X.1.5   Destination address valid
+
+          This mailbox address as specified was valid.  This status
+          code should be used for positive delivery reports.
+
+       X.1.6   Destination mailbox has moved, No forwarding address
+
+          The mailbox address provided was at one time valid, but mail
+          is no longer being accepted for that address.  This code is
+          only useful for permanent failures.
+
+       X.1.7   Bad sender's mailbox address syntax
+
+          The sender's address was syntactically invalid.  This can
+          apply to any field in the address.
+
+       X.1.8   Bad sender's system address
+
+          The sender's system specified in the address does not exist
+          or is incapable of accepting return mail.  For domain names,
+          this means the address portion to the right of the "@" is
+          invalid for mail.
+
+   3.3 Mailbox Status
+
+       X.2.0   Other or undefined mailbox status
+
+          The mailbox exists, but something about the destination
+          mailbox has caused the sending of this DSN.
+
+       X.2.1   Mailbox disabled, not accepting messages
+
+          The mailbox exists, but is not accepting messages.  This may
+          be a permanent error if the mailbox will never be re-enabled
+          or a transient error if the mailbox is only temporarily
+          disabled.
+
+       X.2.2   Mailbox full
+
+          The mailbox is full because the user has exceeded a
+          per-mailbox administrative quota or physical capacity.  The
+          general semantics implies that the recipient can delete
+          messages to make more space available.  This code should be
+          used as a persistent transient failure.
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 6]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+       X.2.3   Message length exceeds administrative limit
+
+          A per-mailbox administrative message length limit has been
+          exceeded.  This status code should be used when the
+          per-mailbox message length limit is less than the general
+          system limit.  This code should be used as a permanent
+          failure.
+
+       X.2.4   Mailing list expansion problem
+
+          The mailbox is a mailing list address and the mailing list
+          was unable to be expanded.  This code may represent a
+          permanent failure or a persistent transient failure.
+
+   3.4 Mail system status
+
+       X.3.0   Other or undefined mail system status
+
+          The destination system exists and normally accepts mail, but
+          something about the system has caused the generation of this
+          DSN.
+
+       X.3.1   Mail system full
+
+          Mail system storage has been exceeded.  The general
+          semantics imply that the individual recipient may not be
+          able to delete material to make room for additional
+          messages.  This is useful only as a persistent transient
+          error.
+
+       X.3.2   System not accepting network messages
+
+          The host on which the mailbox is resident is not accepting
+          messages.  Examples of such conditions include an immanent
+          shutdown, excessive load, or system maintenance.  This is
+          useful for both permanent and permanent transient errors.
+
+       X.3.3   System not capable of selected features
+
+          Selected features specified for the message are not
+          supported by the destination system.  This can occur in
+          gateways when features from one domain cannot be mapped onto
+          the supported feature in another.
+
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 7]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+       X.3.4   Message too big for system
+
+          The message is larger than per-message size limit.  This
+          limit may either be for physical or administrative reasons.
+          This is useful only as a permanent error.
+
+       X.3.5 System incorrectly configured
+
+          The system is not configured in a manner which will permit
+          it to accept this message.
+
+   3.5 Network and Routing Status
+
+       X.4.0   Other or undefined network or routing status
+
+          Something went wrong with the networking, but it is not
+          clear what the problem is, or the problem cannot be well
+          expressed with any of the other provided detail codes.
+
+       X.4.1   No answer from host
+
+          The outbound connection attempt was not answered, either
+          because the remote system was busy, or otherwise unable to
+          take a call.  This is useful only as a persistent transient
+          error.
+
+       X.4.2   Bad connection
+
+          The outbound connection was established, but was otherwise
+          unable to complete the message transaction, either because
+          of time-out, or inadequate connection quality. This is
+          useful only as a persistent transient error.
+
+       X.4.3   Directory server failure
+
+          The network system was unable to forward the message,
+          because a directory server was unavailable.  This is useful
+          only as a persistent transient error.
+
+          The inability to connect to an Internet DNS server is one
+          example of the directory server failure error.
+
+       X.4.4   Unable to route
+
+          The mail system was unable to determine the next hop for the
+          message because the necessary routing information was
+          unavailable from the directory server. This is useful for
+          both permanent and persistent transient errors.
+
+
+
+Vaudreuil                   Standards Track                     [Page 8]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+          A DNS lookup returning only an SOA (Start of Administration)
+          record for a domain name is one example of the unable to
+          route error.
+
+       X.4.5   Mail system congestion
+
+          The mail system was unable to deliver the message because
+          the mail system was congested. This is useful only as a
+          persistent transient error.
+
+       X.4.6   Routing loop detected
+
+          A routing loop caused the message to be forwarded too many
+          times, either because of incorrect routing tables or a user
+          forwarding loop. This is useful only as a persistent
+          transient error.
+
+       X.4.7   Delivery time expired
+
+          The message was considered too old by the rejecting system,
+          either because it remained on that host too long or because
+          the time-to-live value specified by the sender of the
+          message was exceeded. If possible, the code for the actual
+          problem found when delivery was attempted should be returned
+          rather than this code.  This is useful only as a persistent
+          transient error.
+
+   3.6 Mail Delivery Protocol Status
+
+       X.5.0   Other or undefined protocol status
+
+          Something was wrong with the protocol necessary to deliver
+          the message to the next hop and the problem cannot be well
+          expressed with any of the other provided detail codes.
+
+       X.5.1   Invalid command
+
+          A mail transaction protocol command was issued which was
+          either out of sequence or unsupported.  This is useful only
+          as a permanent error.
+
+       X.5.2   Syntax error
+
+          A mail transaction protocol command was issued which could
+          not be interpreted, either because the syntax was wrong or
+          the command is unrecognized. This is useful only as a
+          permanent error.
+
+
+
+
+Vaudreuil                   Standards Track                     [Page 9]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+       X.5.3   Too many recipients
+
+          More recipients were specified for the message than could
+          have been delivered by the protocol.  This error should
+          normally result in the segmentation of the message into two,
+          the remainder of the recipients to be delivered on a
+          subsequent delivery attempt.  It is included in this list in
+          the event that such segmentation is not possible.
+
+       X.5.4   Invalid command arguments
+
+          A valid mail transaction protocol command was issued with
+          invalid arguments, either because the arguments were out of
+          range or represented unrecognized features. This is useful
+          only as a permanent error.
+
+       X.5.5   Wrong protocol version
+
+          A protocol version mis-match existed which could not be
+          automatically resolved by the communicating parties.
+
+   3.7 Message Content or Message Media Status
+
+       X.6.0   Other or undefined media error
+
+          Something about the content of a message caused it to be
+          considered undeliverable and the problem cannot be well
+          expressed with any of the other provided detail codes.
+
+       X.6.1   Media not supported
+
+          The media of the message is not supported by either the
+          delivery protocol or the next system in the forwarding path.
+          This is useful only as a permanent error.
+
+       X.6.2   Conversion required and prohibited
+
+          The content of the message must be converted before it can
+          be delivered and such conversion is not permitted.  Such
+          prohibitions may be the expression of the sender in the
+          message itself or the policy of the sending host.
+
+       X.6.3   Conversion required but not supported
+
+          The message content must be converted to be forwarded but
+          such conversion is not possible or is not practical by a
+          host in the forwarding path.  This condition may result when
+          an ESMTP gateway supports 8bit transport but is not able to
+
+
+
+Vaudreuil                   Standards Track                    [Page 10]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+          downgrade the message to 7 bit as required for the next hop.
+
+       X.6.4   Conversion with loss performed
+
+          This is a warning sent to the sender when message delivery
+          was successfully but when the delivery required a conversion
+          in which some data was lost.  This may also be a permanant
+          error if the sender has indicated that conversion with loss
+          is prohibited for the message.
+
+       X.6.5   Conversion Failed
+
+          A conversion was required but was unsuccessful.  This may be
+          useful as a permanent or persistent temporary notification.
+
+   3.8 Security or Policy Status
+
+       X.7.0   Other or undefined security status
+
+          Something related to security caused the message to be
+          returned, and the problem cannot be well expressed with any
+          of the other provided detail codes.  This status code may
+          also be used when the condition cannot be further described
+          because of security policies in force.
+
+       X.7.1   Delivery not authorized, message refused
+
+          The sender is not authorized to send to the destination.
+          This can be the result of per-host or per-recipient
+          filtering.  This memo does not discuss the merits of any
+          such filtering, but provides a mechanism to report such.
+          This is useful only as a permanent error.
+
+       X.7.2   Mailing list expansion prohibited
+
+          The sender is not authorized to send a message to the
+          intended mailing list. This is useful only as a permanent
+          error.
+
+       X.7.3   Security conversion required but not possible
+
+          A conversion from one secure messaging protocol to another
+          was required for delivery and such conversion was not
+          possible. This is useful only as a permanent error.
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                    [Page 11]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+       X.7.4   Security features not supported
+
+          A message contained security features such as secure
+          authentication which could not be supported on the delivery
+          protocol. This is useful only as a permanent error.
+
+       X.7.5   Cryptographic failure
+
+          A transport system otherwise authorized to validate or
+          decrypt a message in transport was unable to do so because
+          necessary information such as key was not available or such
+          information was invalid.
+
+       X.7.6   Cryptographic algorithm not supported
+
+          A transport system otherwise authorized to validate or
+          decrypt a message was unable to do so because the necessary
+          algorithm was not supported.
+
+       X.7.7   Message integrity failure
+
+          A transport system otherwise authorized to validate a
+          message was unable to do so because the message was
+          corrupted or altered.  This may be useful as a permanent,
+          transient persistent, or successful delivery code.
+
+4.   References
+
+   [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+       USC/Information Sciences Institute, August 1982.
+
+   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+       Delivery Status Notifications", RFC 1894, University of
+       Tennessee, Octel Network Services, January 1996.
+
+5.   Security Considerations
+
+   This document describes a status code system with increased
+   precision.  Use of these status codes may disclose additional
+   information about how an internal mail system is implemented beyond
+   that currently available.
+
+6.   Acknowledgments
+
+   The author wishes to offer special thanks to Harald Alvestrand, Marko
+   Kaittola, and Keith Moore for their extensive review and constructive
+   suggestions.
+
+
+
+
+Vaudreuil                   Standards Track                    [Page 12]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+7.   Author's Address
+
+   Gregory M. Vaudreuil
+   Octel Network Services
+   17060 Dallas Parkway
+   Suite 214
+   Dallas, TX 75248-1905
+
+   Voice/Fax: +1-214-733-2722
+   EMail: Greg.Vaudreuil@Octel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                    [Page 13]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+8.   Appendix - Collected Status Codes
+
+       X.1.0     Other address status
+       X.1.1     Bad destination mailbox address
+       X.1.2     Bad destination system address
+       X.1.3     Bad destination mailbox address syntax
+       X.1.4     Destination mailbox address ambiguous
+       X.1.5     Destination mailbox address valid
+       X.1.6     Mailbox has moved
+       X.1.7     Bad sender's mailbox address syntax
+       X.1.8     Bad sender's system address
+
+       X.2.0     Other or undefined mailbox status
+       X.2.1     Mailbox disabled, not accepting messages
+       X.2.2     Mailbox full
+       X.2.3     Message length exceeds administrative limit.
+       X.2.4     Mailing list expansion problem
+
+       X.3.0     Other or undefined mail system status
+       X.3.1     Mail system full
+       X.3.2     System not accepting network messages
+       X.3.3     System not capable of selected features
+       X.3.4     Message too big for system
+
+       X.4.0     Other or undefined network or routing status
+       X.4.1     No answer from host
+       X.4.2     Bad connection
+       X.4.3     Routing server failure
+       X.4.4     Unable to route
+       X.4.5     Network congestion
+       X.4.6     Routing loop detected
+       X.4.7     Delivery time expired
+
+       X.5.0     Other or undefined protocol status
+       X.5.1     Invalid command
+       X.5.2     Syntax error
+       X.5.3     Too many recipients
+       X.5.4     Invalid command arguments
+       X.5.5     Wrong protocol version
+
+       X.6.0     Other or undefined media error
+       X.6.1     Media not supported
+       X.6.2     Conversion required and prohibited
+       X.6.3     Conversion required but not supported
+       X.6.4     Conversion with loss performed
+       X.6.5     Conversion failed
+
+
+
+
+
+Vaudreuil                   Standards Track                    [Page 14]
+
+RFC 1893                Mail System Status Codes            January 1996
+
+
+       X.7.0     Other or undefined security status
+       X.7.1     Delivery not authorized, message refused
+       X.7.2     Mailing list expansion prohibited
+       X.7.3     Security conversion required but not possible
+       X.7.4     Security features not supported
+       X.7.5     Cryptographic failure
+       X.7.6     Cryptographic algorithm not supported
+       X.7.7     Message integrity failure
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil                   Standards Track                    [Page 15]
+
diff --git a/RFC/rfc1894.txt b/RFC/rfc1894.txt
new file mode 100644
index 00000000..f1fc90d4
--- /dev/null
+++ b/RFC/rfc1894.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+Network Working Group                                           K. Moore
+Request for Comments: 1894                       University of Tennessee
+Category: Standards Track                                   G. Vaudreuil
+                                                  Octel Network Services
+                                                            January 1996
+
+
+     An Extensible Message Format for Delivery Status Notifications
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo defines a MIME content-type that may be used by a message
+   transfer agent (MTA) or electronic mail gateway to report the result
+   of an attempt to deliver a message to one or more recipients.  This
+   content-type is intended as a machine-processable replacement for the
+   various types of delivery status notifications currently used in
+   Internet electronic mail.
+
+   Because many messages are sent between the Internet and other
+   messaging systems (such as X.400 or the so-called "LAN-based"
+   systems), the DSN protocol is designed to be useful in a multi-
+   protocol messaging environment.  To this end, the protocol described
+   in this memo provides for the carriage of "foreign" addresses and
+   error codes, in addition to those normally used in Internet mail.
+   Additional attributes may also be defined to support "tunneling" of
+   foreign notifications through Internet mail.
+
+   Any questions, comments, and reports of defects or ambiguities in
+   this specification may be sent to the mailing list for the NOTARY
+   working group of the IETF, using the address
+   <notifications@cs.utk.edu>.  Requests to subscribe to the mailing
+   list should be addressed to <notifications-request@cs.utk.edu>.
+   Implementors of this specification are encouraged to subscribe to the
+   mailing list, so that they will quickly be informed of any problems
+   which might hinder interoperability.
+
+   NOTE: This document is a Proposed Standard.  If and when this
+   protocol is submitted for Draft Standard status, any normative text
+   (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in
+   this document will be re-evaluated in light of implementation
+
+
+
+Moore & Vaudreuil           Standards Track                     [Page 1]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   experience, and are thus subject to change.
+
+1. Introduction
+
+   This memo defines a MIME [1] content-type for delivery status
+   notifications (DSNs).  A DSN can be used to notify the sender of a
+   message of any of several conditions:  failed delivery, delayed
+   delivery, successful delivery, or the gatewaying of a message into an
+   environment that may not support DSNs.  The "message/delivery-status"
+   content-type defined herein is intended for use within the framework
+   of the "multipart/report" content type defined in [2].
+
+   This memo defines only the format of the notifications.  An extension
+   to the Simple Message Transfer Protocol (SMTP) [3] to fully support
+   such notifications is the subject of a separate memo [4].
+
+1.1 Purposes
+
+   The DSNs defined in this memo are expected to serve several purposes:
+
+(a) Inform human beings of the status of message delivery processing, as
+    well as the reasons for any delivery problems or outright failures,
+    in a manner which is largely independent of human language;
+
+(b) Allow mail user agents to keep track of the delivery status of
+    messages sent, by associating returned DSNs with earlier message
+    transmissions;
+
+(c) Allow mailing list exploders to automatically maintain their
+    subscriber lists when delivery attempts repeatedly fail;
+
+(d) Convey delivery and non-delivery notifications resulting from
+    attempts to deliver messages to "foreign" mail systems via a
+    gateway;
+
+(e) Allow "foreign" notifications to be tunneled through a MIME-capable
+    message system and back into the original messaging system that
+    issued the original notification, or even to a third messaging
+    system;
+
+(f) Allow language-independent, yet reasonably precise, indications of
+    the reason for the failure of a message to be delivered (once status
+    codes of sufficient precision are defined); and
+
+(g) Provide sufficient information to remote MTA maintainers (via
+    "trouble tickets") so that they can understand the nature of
+    reported errors.  This feature is used in the case that failure to
+    deliver a message is due to the malfunction of a remote MTA and the
+
+
+
+Moore & Vaudreuil           Standards Track                     [Page 2]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+    sender wants to report the problem to the remote MTA administrator.
+
+1.2 Requirements
+
+    These purposes place the following constraints on the notification
+    protocol:
+
+(a) It must be readable by humans as well as being machine-parsable.
+
+(b) It must provide enough information to allow message senders (or the
+    user agents) to unambiguously associate a DSN with the message that
+    was sent and the original recipient address for which the DSN is
+    issued (if such information is available), even if the message was
+    forwarded to another recipient address.
+
+(c) It must be able to preserve the reason for the success or failure of
+    a delivery attempt in a remote messaging system, using the
+    "language" (mailbox addresses and status codes) of that remote
+    system.
+
+(d) It must also be able to describe the reason for the success or
+    failure of a delivery attempt, independent of any particular human
+    language or of the "language" of any particular mail system.
+
+(e) It must preserve enough information to allow the maintainer of a
+    remote MTA to understand (and if possible, reproduce) the conditions
+    that caused a delivery failure at that MTA.
+
+(f) For any notifications issued by foreign mail systems, which are
+    translated by a mail gateway to the DSN format, the DSN must
+    preserve the "type" of the foreign addresses and error codes, so
+    that these may be correctly interpreted by gateways.
+
+   A DSN contains a set of per-message fields which identify the message
+   and the transaction during which the message was submitted, along
+   with other fields that apply to all delivery attempts described by
+   the DSN.  The DSN also includes a set of per-recipient fields to
+   convey the result of the attempt to deliver the message to each of
+   one or more recipients.
+
+1.3 Terminology
+
+   A message may be transmitted through several message transfer agents
+   (MTAs) on its way to a recipient.  For a variety of reasons,
+   recipient addresses may be rewritten during this process, so each MTA
+   may potentially see a different recipient address.  Depending on the
+   purpose for which a DSN is used, different formats of a particular
+   recipient address will be needed.
+
+
+
+Moore & Vaudreuil           Standards Track                     [Page 3]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   Several DSN fields are defined in terms of the view from a particular
+   MTA in the transmission.  The MTAs are assigned the following names:
+
+   (a) Original MTA
+
+   The Original MTA is the one to which the message is submitted for
+   delivery by the sender of the message.
+
+   (b) Reporting MTA
+
+   For any DSN, the Reporting MTA is the one which is reporting the
+   results of delivery attempts described in the DSN.
+
+   If the delivery attempts described occurred in a "foreign" (non-
+   Internet) mail system, and the DSN was produced by translating the
+   foreign notice into DSN format, the Reporting MTA will still identify
+   the "foreign" MTA where the delivery attempts occurred.
+
+   (c) Received-From MTA
+
+   The Received-From MTA is the MTA from which the Reporting MTA
+   received the message, and accepted responsibility for delivery of the
+   message.
+
+   (d) Remote MTA
+
+   If an MTA determines that it must relay a message to one or more
+   recipients, but the message cannot be transferred to its "next hop"
+   MTA, or if the "next hop" MTA refuses to accept responsibility for
+   delivery of the message to one or more of its intended recipients,
+   the relaying MTA may need to issue a DSN on behalf of the recipients
+   for whom the message cannot be delivered.  In this case the relaying
+   MTA is the Reporting MTA, and the "next hop" MTA is known as the
+   Remote MTA.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                     [Page 4]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+Figure 1 illustrates the relationship between the various MTAs.
+
+
++-----+    +--------+           +---------+    +---------+      +------+
+|     |    |        |           |Received-|    |         |      |      |
+|     | => |Original| => ... => |  From   | => |Reporting| ===> |Remote|
+| user|    |   MTA  |           |   MTA   |    |   MTA   | <No! |  MTA |
+|agent|    +--------+           +---------+    +----v----+      +------+
+|     |                                             |
+|     | <-------------------------------------------+
++-----+      (DSN returned to sender by Reporting MTA)
+
+
+     Figure 1.  Original, Received-From, Reporting and Remote MTAs
+
+
+   Each of these MTAs may provide information which is useful in a DSN:
+
++ Ideally, the DSN will contain the address of each recipient as
+  originally specified to the Original MTA by the sender of the message.
+  This version of the address is needed (rather than a forwarding
+  address or some modified version of the original address) so that the
+  sender may compare the recipient address in the DSN with the address
+  in the sender's records (e.g. an address book for an individual, the
+  list of subscribers for a mailing list) and take appropriate action.
+
+  Similarly, the DSN might contain an "envelope identifier" that was
+  known to both the sender's user agent and the Original MTA at the time
+  of message submission, and which, if included in the DSN, can be used
+  by the sender to keep track of which messages were or were not
+  delivered.
+
++ If a message was (a) forwarded to a different address than that
+  specified by the sender, (b) gatewayed to a different mail system than
+  that used by the sender, or (c) subjected to address rewriting during
+  transmission, the "final" form of the recipient address (i.e. the one
+  seen by the Reporting MTA) will be different than the original
+  (sender-specified) recipient address.  Just as the sender's user agent
+  (or the sender) prefers the original recipient address, so the "final"
+  address is needed when reporting a problem to the postmaster of the
+  site where message delivery failed, because only the final recipient
+  address will allow her to reproduce the conditions that caused the
+  failure.
+
++ A "failed" DSN should contain the most accurate explanation for the
+  delivery failure that is available.  For ease of interpretation, this
+  information should be a format which is independent of the mail
+  transport system that issued the DSN.  However, if a foreign error
+
+
+
+Moore & Vaudreuil           Standards Track                     [Page 5]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+  code is translated into some transport-independent format, some
+  information may be lost.  It is therefore desirable to provide both a
+  transport-independent status code and a mechanism for reporting
+  transport-specific codes.  Depending on the circumstances that
+  produced delivery failure, the transport-specific code might be
+  obtained from either the Reporting MTA or the Remote MTA.
+
+   Since different values for "recipient address" and "delivery status
+   code" are needed according to the circumstance in which a DSN will be
+   used, and since the MTA that issues the DSN cannot anticipate those
+   circumstances, the DSN format described here may contain both the
+   original and final forms of a recipient address, and both a
+   transport-independent and a transport-specific indication of delivery
+   status.
+
+   Extension fields may also be added by the Reporting MTA as needed to
+   provide additional information for use in a trouble ticket or to
+   preserve information for tunneling of foreign delivery reports
+   through Internet DSNs.
+
+   The Original, Reporting, and Remote MTAs may exist in very different
+   environments and use dissimilar transport protocols, MTA names,
+   address formats, and delivery status codes.  DSNs therefore do not
+   assume any particular format for mailbox addresses, MTA names, or
+   transport-specific status codes.  Instead, the various DSN fields
+   that carry such quantities consist of a "type" subfield followed by a
+   subfield whose contents are ordinary text characters, and the format
+   of which is indicated by the "type" subfield.  This allows a DSN to
+   convey these quantities regardless of format.
+
+2. Format of a Delivery Status Notification
+
+   A DSN is a MIME message with a top-level content-type of
+   multipart/report (defined in [2]).  When a multipart/report content
+   is used to transmit a DSN:
+
+(a) The report-type parameter of the multipart/report content is
+    "delivery-status".
+
+(b) The first component of the multipart/report contains a human-
+    readable explanation of the DSN, as described in [2].
+
+(c) The second component of the multipart/report is of content-type
+    message/delivery-status, described in section 2.1 of this document.
+
+(d) If the original message or a portion of the message is to be
+    returned to the sender, it appears as the third component of the
+    multipart/report.
+
+
+
+Moore & Vaudreuil           Standards Track                     [Page 6]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+    NOTE: For delivery status notifications gatewayed from foreign
+    systems, the headers of the original message may not be available.
+    In this case the third component of the DSN may be omitted, or it
+    may contain "simulated" RFC 822 headers which contain equivalent
+    information.  In particular, it is very desirable to preserve the
+    subject, date, and message-id (or equivalent) fields from the
+    original message.
+
+   The DSN MUST be addressed (in both the message header and the
+   transport envelope) to the return address from the transport envelope
+   which accompanied the original message for which the DSN was
+   generated.  (For a message that arrived via SMTP, the envelope return
+   address appears in the MAIL FROM command.)
+
+   The From field of the message header of the DSN SHOULD contain the
+   address of a human who is responsible for maintaining the mail system
+   at the Reporting MTA site (e.g.  Postmaster), so that a reply to the
+   DSN will reach that person.  Exception: if a DSN is translated from a
+   foreign delivery report, and the gateway performing the translation
+   cannot determine the appropriate address, the From field of the DSN
+   MAY be the address of a human who is responsible for maintaining the
+   gateway.
+
+   The envelope sender address of the DSN SHOULD be chosen to ensure
+   that no delivery status reports will be issued in response to the DSN
+   itself, and MUST be chosen so that DSNs will not generate mail loops.
+   Whenever an SMTP transaction is used to send a DSN, the MAIL FROM
+   command MUST use a NULL return address, i.e. "MAIL FROM:<>".
+
+   A particular DSN describes the delivery status for exactly one
+   message.  However, an MTA MAY report on the delivery status for
+   several recipients of the same message in a single DSN.  Due to the
+   nature of the mail transport system (where responsibility for
+   delivery of a message to its recipients may be split among several
+   MTAs, and delivery to any particular recipient may be delayed),
+   multiple DSNs may be still be issued in response to a single message
+   submission.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                     [Page 7]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+2.1 The message/delivery-status content-type
+
+   The message/delivery-status content-type is defined as follows:
+
+     MIME type name:                message
+     MIME subtype name:             delivery-status
+     Optional parameters:           none
+     Encoding considerations:       "7bit" encoding is sufficient and
+                                    MUST be used to maintain readability
+                                    when viewed by non-MIME mail
+                                    readers.
+     Security considerations:       discussed in section 4 of this memo.
+
+   The message/delivery-status report type for use in the
+   multipart/report is "delivery-status".
+
+   The body of a message/delivery-status consists of one or more
+   "fields" formatted according to the ABNF of RFC 822 header "fields"
+   (see [6]).  The per-message fields appear first, followed by a blank
+   line.  Following the per-message fields are one or more groups of
+   per-recipient fields.  Each group of per-recipient fields is preceded
+   by a blank line.  Using the ABNF of RFC 822, the syntax of the
+   message/delivery-status content is as follows:
+
+     delivery-status-content =
+          per-message-fields 1*( CRLF per-recipient-fields )
+
+   The per-message fields are described in section 2.2.  The per-
+   recipient fields are described in section 2.3.
+
+
+2.1.1 General conventions for DSN fields
+
+   Since these fields are defined according to the rules of RFC 822, the
+   same conventions for continuation lines and comments apply.
+   Notification fields may be continued onto multiple lines by beginning
+   each additional line with a SPACE or HTAB.  Text which appears in
+   parentheses is considered a comment and not part of the contents of
+   that notification field.  Field names are case-insensitive, so the
+   names of notification fields may be spelled in any combination of
+   upper and lower case letters.  Comments in DSN fields may use the
+   "encoded-word" construct defined in [7].
+
+   A number of DSN fields are defined to have a portion of a field body
+   of "xtext".  "xtext" is used to allow encoding sequences of octets
+   which contain values outside the range [1-127 decimal] of traditional
+   ASCII characters, and also to allow comments to be inserted in the
+   data.  Any octet may be encoded as "+" followed by two upper case
+
+
+
+Moore & Vaudreuil           Standards Track                     [Page 8]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   hexadecimal digits.  (The "+" character MUST be encoded as "+2B".)
+   With certain exceptions, octets that correspond to ASCII characters
+   may be represented as themselves.  SPACE and HTAB characters are
+   ignored.  Comments may be included by enclosing them in parenthesis.
+   Except within comments, encoded-words such as defined in [7] may NOT
+   be used in xtext.
+
+   "xtext" is formally defined as follows:
+
+     xtext = *( xchar / hexchar / linear-white-space / comment )
+
+     xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
+          except for "+", "\" and "(".
+
+   "hexchar"s are intended to encode octets that cannot be represented
+   as plain text, either because they are reserved, or because they are
+   non-printable.  However, any octet value may be represented by a
+   "hexchar".
+
+     hexchar = ASCII "+" immediately followed by two upper case
+          hexadecimal digits
+
+   When encoding an octet sequence as xtext:
+
+   + Any ASCII CHAR between "!" and "~" inclusive, except for "+", "\",
+     and "(", MAY be encoded as itself.  (Some CHARs in this range may
+     also be encoded as "hexchar"s, at the implementor's discretion.)
+
+   + ASCII CHARs that fall outside the range above must be encoded as
+     "hexchar".
+
+   + Line breaks (CR LF SPACE) MAY be inserted as necessary to keep line
+     lengths from becoming excessive.
+
+   + Comments MAY be added to clarify the meaning for human readers.
+
+2.1.2 "*-type" subfields
+
+   Several DSN fields consist of a "-type" subfield, followed by a
+   semicolon, followed by "*text".  For these fields, the keyword used
+   in the address-type, diagnostic-type, or MTA-name-type subfield
+   indicates the expected format of the address, status-code, or MTA-
+   name which follows.
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                     [Page 9]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   The "-type" subfields are defined as follows:
+
+(a) An "address-type" specifies the format of a mailbox address.  For
+    example, Internet mail addresses use the "rfc822" address-type.
+
+         address-type = atom
+
+(b) A "diagnostic-type" specifies the format of a status code.  For
+    example, when a DSN field contains a reply code reported via the
+    Simple Mail Transfer Protocol [3], the "smtp" diagnostic-type is
+    used.
+
+         diagnostic-type = atom
+
+(c) An "MTA-name-type" specifies the format of an MTA name.  For
+    example, for an SMTP server on an Internet host, the MTA name is the
+    domain name of that host, and the "dns" MTA-name-type is used.
+
+         mta-name-type = atom
+
+   Values for address-type, diagnostic-type, and MTA-name-type are
+   case-insensitive.  Thus address-type values of "RFC822" and "rfc822"
+   are equivalent.
+
+   The Internet Assigned Numbers Authority (IANA) will maintain a
+   registry of address-types, diagnostic-types, and MTA-name-types,
+   along with descriptions of the meanings and acceptable values of
+   each, or a reference to a one or more specifications that provide
+   such descriptions.  (The "rfc822" address-type, "smtp" diagnostic-
+   type, and "dns" MTA-name-type are defined in [4].)  Registration
+   forms for address-type, diagnostic-type, and MTA-name-type appear in
+   section 8 of this document.
+
+   IANA will not accept registrations for any address-type, diagnostic-
+   type, or MTA-name-type name that begins with "X-".  These type names
+   are reserved for experimental use.
+
+2.1.3 Lexical tokens imported from RFC 822
+
+   The following lexical tokens, defined in [6], are used in the ABNF
+   grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF, linear-
+   white-space, SPACE, text.  The date-time lexical token is defined in
+   [8].
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 10]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+2.2 Per-Message DSN Fields
+
+   Some fields of a DSN apply to all of the delivery attempts described
+   by that DSN.  These fields may appear at most once in any DSN.  These
+   fields are used to correlate the DSN with the original message
+   transaction and to provide additional information which may be useful
+   to gateways.
+
+     per-message-fields =
+          [ original-envelope-id-field CRLF ]
+          reporting-mta-field CRLF
+          [ dsn-gateway-field CRLF ]
+          [ received-from-mta-field CRLF ]
+          [ arrival-date-field CRLF ]
+          *( extension-field CRLF )
+
+2.2.1 The Original-Envelope-Id field
+
+   The optional Original-Envelope-Id field contains an "envelope
+   identifier" which uniquely identifies the transaction during which
+   the message was submitted, and was either (a) specified by the sender
+   and supplied to the sender's MTA, or (b) generated by the sender's
+   MTA and made available to the sender when the message was submitted.
+   Its purpose is to allow the sender (or her user agent) to associate
+   the returned DSN with the specific transaction in which the message
+   was sent.
+
+   If such an envelope identifier was present in the envelope which
+   accompanied the message when it arrived at the Reporting MTA, it
+   SHOULD be supplied in the Original-Envelope-Id field of any DSNs
+   issued as a result of an attempt to deliver the message.  Except when
+   a DSN is issued by the sender's MTA, an MTA MUST NOT supply this
+   field unless there is an envelope-identifier field in the envelope
+   which accompanied this message on its arrival at the Reporting MTA.
+
+   The Original-Envelope-Id field is defined as follows:
+
+     original-envelope-id-field =
+          "Original-Envelope-Id" ":" envelope-id
+
+     envelope-id = *text
+
+   There may be at most one Original-Envelope-Id field per DSN.
+
+   The envelope-id is CASE-SENSITIVE.  The DSN MUST preserve the
+   original case and spelling of the envelope-id.
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 11]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   NOTE: The Original-Envelope-Id is NOT the same as the Message-Id from
+   the message header.  The Message-Id identifies the content of the
+   message, while the Original-Envelope-Id identifies the transaction in
+   which the message is sent.
+
+2.2.2 The Reporting-MTA DSN field
+
+     reporting-mta-field =
+          "Reporting-MTA" ":" mta-name-type ";" mta-name
+
+     mta-name = *text
+
+   The Reporting-MTA field is defined as follows:
+
+   A DSN describes the results of attempts to deliver, relay, or gateway
+   a message to one or more recipients.  In all cases, the Reporting-MTA
+   is the MTA which attempted to perform the delivery, relay, or gateway
+   operation described in the DSN.  This field is required.
+
+   Note that if an SMTP client attempts to relay a message to an SMTP
+   server and receives an error reply to a RCPT command, the client is
+   responsible for generating the DSN, and the client's domain name will
+   appear in the Reporting-MTA field.  (The server's domain name will
+   appear in the Remote-MTA field.)
+
+   Note that the Reporting-MTA is not necessarily the MTA which actually
+   issued the DSN.  For example, if an attempt to deliver a message
+   outside of the Internet resulted in a nondelivery notification which
+   was gatewayed back into Internet mail, the Reporting-MTA field of the
+   resulting DSN would be that of the MTA that originally reported the
+   delivery failure, not that of the gateway which converted the foreign
+   notification into a DSN.  See Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 12]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+sender's environment                            recipient's environment
+............................ ..........................................
+                           : :
+                       (1) : :                             (2)
+  +-----+  +--------+  +--------+  +---------+  +---------+   +------+
+  |     |  |        |  |        |  |Received-|  |         |   |      |
+  |     |=>|Original|=>|        |->|  From   |->|Reporting|-->|Remote|
+  | user|  |   MTA  |  |        |  |   MTA   |  |   MTA   |<No|  MTA |
+  |agent|  +--------+  |Gateway |  +---------+  +----v----+   +------+
+  |     |              |        |                    |
+  |     | <============|        |<-------------------+
+  +-----+              |        |(4)                (3)
+                       +--------+
+                           : :
+...........................: :.........................................
+
+              Figure 2.  DSNs in the presence of gateways
+
+     (1) message is gatewayed into recipient's environment
+     (2) attempt to relay message fails
+     (3) reporting-mta (in recipient's environment) returns nondelivery
+         notification
+     (4) gateway translates foreign notification into a DSN
+
+
+
+   The mta-name portion of the Reporting-MTA field is formatted
+   according to the conventions indicated by the mta-name-type subfield.
+   If an MTA functions as a gateway between dissimilar mail environments
+   and thus is known by multiple names depending on the environment, the
+   mta-name subfield SHOULD contain the name used by the environment
+   from which the message was accepted by the Reporting-MTA.
+
+   Because the exact spelling of an MTA name may be significant in a
+   particular environment, MTA names are CASE-SENSITIVE.
+
+2.2.3 The DSN-Gateway field
+
+   The DSN-Gateway field indicates the name of the gateway or MTA which
+   translated a foreign (non-Internet) delivery status notification into
+   this DSN.  This field MUST appear in any DSN which was translated by
+   a gateway from a foreign system into DSN format, and MUST NOT appear
+   otherwise.
+
+   dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 13]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   For gateways into Internet mail, the MTA-name-type will normally be
+   "smtp", and the mta-name will be the Internet domain name of the
+   gateway.
+
+2.2.4 The Received-From-MTA DSN field
+
+   The optional Received-From-MTA field indicates the name of the MTA
+   from which the message was received.
+
+     received-from-mta-field =
+          "Received-From-MTA" ":" mta-name-type ";" mta-name
+
+   If the message was received from an Internet host via SMTP, the
+   contents of the mta-name subfield SHOULD be the Internet domain name
+   supplied in the HELO or EHLO command, and the network address used by
+   the SMTP client SHOULD be included as a comment enclosed in
+   parentheses.  (In this case, the MTA-name-type will be "smtp".)
+
+   The mta-name portion of the Received-From-MTA field is formatted
+   according to the conventions indicated by the MTA-name-type subfield.
+
+   Since case is significant in some mail systems, the exact spelling,
+   including case, of the MTA name SHOULD be preserved.
+
+2.2.5 The Arrival-Date DSN field
+
+   The optional Arrival-Date field indicates the date and time at which
+   the message arrived at the Reporting MTA.  If the Last-Attempt-Date
+   field is also provided in a per-recipient field, this can be used to
+   determine the interval between when the message arrived at the
+   Reporting MTA and when the report was issued for that recipient.
+
+     arrival-date-field = "Arrival-Date" ":" date-time
+
+   The date and time are expressed in RFC 822 'date-time' format, as
+   modified by [8].  Numeric timezones ([+/-]HHMM format) MUST be used.
+
+2.3 Per-Recipient DSN fields
+
+   A DSN contains information about attempts to deliver a message to one
+   or more recipients.  The delivery information for any particular
+   recipient is contained in a group of contiguous per-recipient fields.
+   Each group of per-recipient fields is preceded by a blank line.
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 14]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   The syntax for the group of per-recipient fields is as follows:
+
+
+     per-recipient-fields =
+          [ original-recipient-field CRLF ]
+          final-recipient-field CRLF
+          action-field CRLF
+          status-field CRLF
+          [ remote-mta-field CRLF ]
+          [ diagnostic-code-field CRLF ]
+          [ last-attempt-date-field CRLF ]
+          [ will-retry-until-field CRLF ]
+          *( extension-field CRLF )
+
+2.3.1 Original-Recipient field
+
+   The Original-Recipient field indicates the original recipient address
+   as specified by the sender of the message for which the DSN is being
+   issued.
+
+     original-recipient-field =
+          "Original-Recipient" ":" address-type ";" generic-address
+
+     generic-address = *text
+
+   The address-type field indicates the type of the original recipient
+   address.  If the message originated within the Internet, the
+   address-type field field will normally be "rfc822", and the address
+   will be according to the syntax specified in [6].  The value
+   "unknown" should be used if the Reporting MTA cannot determine the
+   type of the original recipient address from the message envelope.
+
+   This field is optional.  It should be included only if the sender-
+   specified recipient address was present in the message envelope, such
+   as by the SMTP extensions defined in [4].  This address is the same
+   as that provided by the sender and can be used to automatically
+   correlate DSN reports and message transactions.
+
+2.3.2 Final-Recipient field
+
+   The Final-Recipient field indicates the recipient for which this set
+   of per-recipient fields applies.  This field MUST be present in each
+   set of per-recipient data.
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 15]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   The syntax of the field is as follows:
+
+     final-recipient-field =
+          "Final-Recipient" ":" address-type ";" generic-address
+
+   The generic-address subfield of the Final-Recipient field MUST
+   contain the mailbox address of the recipient (from the transport
+   envelope) as it was when the message was accepted for delivery by the
+   Reporting MTA.
+
+   The Final-Recipient address may differ from the address originally
+   provided by the sender, because it may have been transformed during
+   forwarding and gatewaying into an totally unrecognizable mess.
+   However, in the absence of the optional Original-Recipient field, the
+   Final-Recipient field and any returned content may be the only
+   information available with which to correlate the DSN with a
+   particular message submission.
+
+   The address-type subfield indicates the type of address expected by
+   the reporting MTA in that context.  Recipient addresses obtained via
+   SMTP will normally be of address-type "rfc822".
+
+   NOTE: The Reporting MTA is not expected to ensure that the address
+   actually conforms to the syntax conventions of the address-type.
+   Instead, it MUST report exactly the address received in the envelope,
+   unless that address contains characters such as CR or LF which may
+   not appear in a DSN field.
+
+   Since mailbox addresses (including those used in the Internet) may be
+   case sensitive, the case of alphabetic characters in the address MUST
+   be preserved.
+
+2.3.3 Action field
+
+   The Action field indicates the action performed by the Reporting-MTA
+   as a result of its attempt to deliver the message to this recipient
+   address.  This field MUST be present for each recipient named in the
+   DSN.
+
+   The syntax for the action-field is:
+
+     action-field = "Action" ":" action-value
+
+     action-value =
+          "failed" / "delayed" / "delivered" / "relayed" / "expanded"
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 16]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   The action-value may be spelled in any combination of upper and lower
+   case characters.
+
+"failed"     indicates that the message could not be delivered to the
+             recipient.  The Reporting MTA has abandoned any attempts to
+             deliver the message to this recipient.  No further
+             notifications should be expected.
+
+"delayed"    indicates that the Reporting MTA has so far been unable to
+             deliver or relay the message, but it will continue to
+             attempt to do so.  Additional notification messages may be
+             issued as the message is further delayed or successfully
+             delivered, or if delivery attempts are later abandoned.
+
+"delivered"  indicates that the message was successfully delivered to
+             the recipient address specified by the sender, which
+             includes "delivery" to a mailing list exploder.  It does
+             not indicate that the message has been read.  This is a
+             terminal state and no further DSN for this recipient should
+             be expected.
+
+"relayed"    indicates that the message has been relayed or gatewayed
+             into an environment that does not accept responsibility for
+             generating DSNs upon successful delivery.  This action-
+             value SHOULD NOT be used unless the sender has requested
+             notification of successful delivery for this recipient.
+
+"expanded"   indicates that the message has been successfully delivered
+             to the recipient address as specified by the sender, and
+             forwarded by the Reporting-MTA beyond that destination to
+             multiple additional recipient addresses.  An action-value
+             of "expanded" differs from "delivered" in that "expanded"
+             is not a terminal state. Further "failed" and/or "delayed"
+             notifications may be provided.
+
+             Using the terms "mailing list" and "alias" as defined in
+             [4], section 7.2.7:  An action-value of "expanded" is only
+             to be used when the message is delivered to a multiple-
+             recipient "alias".  An action-value of "expanded" SHOULD
+             NOT be used with a DSN issued on delivery of a message to a
+             "mailing list".
+
+   NOTE ON ACTION VS. STATUS CODES:  Although the 'action' field might
+   seem to be redundant with the 'status' field, this is not the case.
+   In particular, a "temporary failure" ("4") status code could be used
+   with an action-value of either "delayed" or "failed".  For example,
+   assume that an SMTP client repeatedly tries to relay a message to the
+   mail exchanger for a recipient, but fails because a query to a domain
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 17]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   name server timed out.  After a few hours, it might issue a "delayed"
+   DSN to inform the sender that the message had not yet been delivered.
+   After a few days, the MTA might abandon its attempt to deliver the
+   message and return a "failed" DSN.  The status code (which would
+   begin with a "4" to indicate "temporary failure") would be the same
+   for both DSNs.
+
+   Another example for which the action and status codes may appear
+   contradictory:  If an MTA or mail gateway cannot deliver a message
+   because doing so would entail conversions resulting in an
+   unacceptable loss of information, it would issue a DSN with the
+   'action' field of "failure" and a status code of 'XXX'.  If the
+   message had instead been relayed, but with some loss of information,
+   it might generate a DSN with the same XXX status-code, but with an
+   action field of "relayed".
+
+2.3.4 Status field
+
+   The per-recipient Status field contains a transport-independent
+   status code which indicates the delivery status of the message to
+   that recipient.  This field MUST be present for each delivery attempt
+   which is described by a DSN.
+
+   The syntax of the status field is:
+
+     status-field = "Status" ":" status-code
+
+     status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+          ; White-space characters and comments are NOT allowed within a
+          ; status-code, though a comment enclosed in parentheses MAY follow
+          ; the last numeric subfield of the status-code.  Each numeric
+          ; subfield within the status-code MUST be expressed without
+          ; leading zero digits.
+
+   Status codes thus consist of three numerical fields separated by ".".
+   The first sub-field indicates whether the delivery attempt was
+   successful (2 = success, 4 = persistent temporary failure, 5 =
+   permanent failure).  The second sub-field indicates the probable
+   source of any delivery anomalies, and the third sub-field denotes a
+   precise error condition, if known.
+
+   The initial set of status-codes is defined in [5].
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 18]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+2.3.5 Remote-MTA field
+
+   The value associated with the Remote-MTA DSN field is a printable
+   ASCII representation of the name of the "remote" MTA that reported
+   delivery status to the "reporting" MTA.
+
+     remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
+
+   NOTE: The Remote-MTA field preserves the "while talking to"
+   information that was provided in some pre-existing nondelivery
+   reports.
+
+   This field is optional.  It MUST NOT be included if no remote MTA was
+   involved in the attempted delivery of the message to that recipient.
+
+2.3.6 Diagnostic-Code field
+
+   For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field
+   contains the actual diagnostic code issued by the mail transport.
+   Since such codes vary from one mail transport to another, the
+   diagnostic-type subfield is needed to specify which type of
+   diagnostic code is represented.
+
+     diagnostic-code-field =
+          "Diagnostic-Code" ":" diagnostic-type ";" *text
+
+   NOTE:  The information in the Diagnostic-Code field may be somewhat
+   redundant with that from the Status field.  The Status field is
+   needed so that any DSN, regardless of origin, may be understood by
+   any user agent or gateway that parses DSNs.  Since the Status code
+   will sometimes be less precise than the actual transport diagnostic
+   code, the Diagnostic-Code field is provided to retain the latter
+   information.  Such information may be useful in a trouble ticket sent
+   to the administrator of the Reporting MTA, or when tunneling foreign
+   nondelivery reports through DSNs.
+
+   If the Diagnostic Code was obtained from a Remote MTA during an
+   attempt to relay the message to that MTA, the Remote-MTA field should
+   be present.  When interpreting a DSN, the presence of a Remote-MTA
+   field indicates that the Diagnostic Code was issued by the Remote
+   MTA.  The absence of a Remote-MTA indicates that the Diagnostic Code
+   was issued by the Reporting MTA.
+
+   In addition to the Diagnostic-Code itself, additional textual
+   description of the diagnostic, MAY appear in a comment enclosed in
+   parentheses.
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 19]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   This field is optional, because some mail systems supply no
+   additional information beyond that which is returned in the 'action'
+   and 'status' fields.  However, this field SHOULD be included if
+   transport-specific diagnostic information is available.
+
+2.3.7 Last-Attempt-Date field
+
+   The Last-Attempt-Date field gives the date and time of the last
+   attempt to relay, gateway, or deliver the message (whether successful
+   or unsuccessful) by the Reporting MTA.  This is not necessarily the
+   same as the value of the Date field from the header of the message
+   used to transmit this delivery status notification: In cases where
+   the DSN was generated by a gateway, the Date field in the message
+   header contains the time the DSN was sent by the gateway and the DSN
+   Last-Attempt-Date field contains the time the last delivery attempt
+   occurred.
+
+     last-attempt-date-field = "Last-Attempt-Date" ":" date-time
+
+   This field is optional.  It MUST NOT be included if the actual date
+   and time of the last delivery attempt are not available (which might
+   be the case if the DSN were being issued by a gateway).
+
+   The date and time are expressed in RFC 822 'date-time' format, as
+   modified by [8].  Numeric timezones ([+/-]HHMM format) MUST be used.
+
+   3.2.1.5 final-log-id field
+
+   The "final-log-id" field gives the final-log-id of the message that
+   was used by the final-mta.  This can be useful as an index to the
+   final-mta's log entry for that delivery attempt.
+
+     final-log-id-field = "Final-Log-ID" ":" *text
+
+   This field is optional.
+
+2.3.8 Will-Retry-Until field
+
+   For DSNs of type "delayed", the Will-Retry-Until field gives the date
+   after which the Reporting MTA expects to abandon all attempts to
+   deliver the message to that recipient.  The Will-Retry-Until field is
+   optional for "delay" DSNs, and MUST NOT appear in other DSNs.
+
+     will-retry-until-field = "Will-Retry-Until" ":" date-time
+
+   The date and time are expressed in RFC 822 'date-time' format, as
+   modified by [8].  Numeric timezones ([+/-]HHMM format) MUST be used.
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 20]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+2.4 Extension fields
+
+   Additional per-message or per-recipient DSN fields may be defined in
+   the future by later revisions or extensions to this specification.
+   Extension-field names beginning with "X-" will never be defined as
+   standard fields; such names are reserved for experimental use.  DSN
+   field names NOT beginning with "X-" MUST be registered with the
+   Internet Assigned Numbers Authority (IANA) and published in an RFC.
+
+   Extension DSN fields may be defined for the following reasons:
+
+   (a) To allow additional information from foreign delivery status
+       reports to be tunneled through Internet DSNs.  The names of such
+       DSN fields should begin with an indication of the foreign
+       environment name (e.g.  X400-Physical-Forwarding-Address).
+
+   (b) To allow the transmission of diagnostic information which is
+       specific to a particular mail transport protocol.  The names of
+       such DSN fields should begin with an indication of the mail
+       transport being used (e.g. SMTP-Remote-Recipient-Address).  Such
+       fields should be used for diagnostic purposes only and not by
+       user agents or mail gateways.
+
+   (c) To allow transmission of diagnostic information which is specific
+       to a particular message transfer agent (MTA).  The names of such
+       DSN fields should begin with an indication of the MTA
+       implementation which produced the DSN.  (e.g. Foomail-Queue-ID).
+
+   MTA implementors are encouraged to provide adequate information, via
+   extension fields if necessary, to allow an MTA maintainer to
+   understand the nature of correctable delivery failures and how to fix
+   them.  For example, if message delivery attempts are logged, the DSN
+   might include information which allows the MTA maintainer to easily
+   find the log entry for a failed delivery attempt.
+
+   If an MTA developer does not wish to register the meanings of such
+   extension fields, "X-" fields may be used for this purpose.  To avoid
+   name collisions, the name of the MTA implementation should follow the
+   "X-", (e.g.  "X-Foomail-Log-ID").
+
+3. Conformance and Usage Requirements
+
+   An MTA or gateway conforms to this specification if it generates DSNs
+   according to the protocol defined in this memo.  For MTAs and
+   gateways that do not support requests for positive delivery
+   notification (such as in [4]), it is sufficient that delivery failure
+   reports use this protocol.
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 21]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   A minimal implementation of this specification need generate only the
+   Reporting-MTA per-message field, and the Final-Recipient, Action, and
+   Status fields for each attempt to deliver a message to a recipient
+   described by the DSN.  Generation of the other fields, when
+   appropriate, is strongly recommended.
+
+   MTAs and gateways MUST NOT generate the Original-Recipient field of a
+   DSN unless the mail transfer protocol provides the address originally
+   specified by the sender at the time of submission. (Ordinary SMTP
+   does not make that guarantee, but the SMTP extension defined in [4]
+   permits such information to be carried in the envelope if it is
+   available.)
+
+   Each sender-specified recipient address SHOULD result in at most one
+   "delivered" or "failed" DSN for that recipient.  If a positive DSN is
+   requested (e.g. one using NOTIFY=SUCCESS in SMTP) for a recipient
+   that is forwarded to multiple recipients of an "alias" (as defined in
+   [4], section 7.2.7), the forwarding MTA SHOULD normally issue a
+   "expanded" DSN for the originally-specified recipient and not
+   propagate the request for a DSN to the forwarding addresses.
+   Alternatively, the forwarding MTA MAY relay the request for a DSN to
+   exactly one of the forwarding addresses and not propagate the request
+   to the others.
+
+   By contrast, successful submission of a message to a mailing list
+   exploder is considered final delivery of the message.  Upon delivery
+   of a message to a recipient address corresponding to a mailing list
+   exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly
+   as if the recipient address were that of an ordinary mailbox.
+
+   NOTE:  This is actually intended to make DSNs usable by mailing lists
+   themselves.  Any message sent to a mailing list subscriber should
+   have its envelope return address pointing to the list maintainer [see
+   RFC 1123, section 5.3.7(E)].  Since DSNs are sent to the envelope
+   return address, all DSNs resulting from delivery to the recipients of
+   a mailing list will be sent to the list maintainer.  The list
+   maintainer may elect to mechanically process DSNs upon receipt, and
+   thus automatically delete invalid addresses from the list.  (See
+   section 7 of this memo.)
+
+   This specification places no restrictions on the processing of DSNs
+   received by user agents or distribution lists.
+
+4. Security Considerations
+
+   The following security considerations apply when using DSNs:
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 22]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+4.1 Forgery
+
+   DSNs may be forged as easily as ordinary Internet electronic mail.
+   User agents and automatic mail handling facilities (such as mail
+   distribution list exploders) that wish to make automatic use of DSNs
+   should take appropriate precautions to minimize the potential damage
+   from denial-of-service attacks.
+
+   Security threats related to forged DSNs include the sending of:
+
+(a) A falsified delivery notification when the message is not delivered
+    to the indicated recipient,
+(b) A falsified non-delivery notification when the message was in fact
+    delivered to the indicated recipient,
+(c) A falsified Final-Recipient address,
+(d) A falsified Remote-MTA identification,
+(e) A falsified relay notification when the message is "dead ended".
+(f) Unsolicited DSNs
+
+4.2 Confidentiality
+
+   Another dimension of security is confidentiality.  There may be cases
+   in which a message recipient is autoforwarding messages but does not
+   wish to divulge the address to which the messages are autoforwarded.
+   The desire for such confidentiality will probably be heightened as
+   "wireless mailboxes", such as pagers, become more widely used as
+   autoforward addresses.
+
+   MTA authors are encouraged to provide a mechanism which enables the
+   end user to preserve the confidentiality of a forwarding address.
+   Depending on the degree of confidentiality required, and the nature
+   of the environment to which a message were being forwarded, this
+   might be accomplished by one or more of:
+
+(a) issuing a "relayed" DSN (if a positive DSN was requested) when a
+    message is forwarded to a confidential forwarding address, and
+    disabling requests for positive DSNs for the forwarded message,
+
+(b) declaring the message to be delivered, issuing a "delivered" DSN,
+    re-sending the message to the confidential forwarding address, and
+    arranging for no DSNs to be issued for the re-sent message,
+
+(c) omitting "Remote-*" or extension fields of a DSN whenever they would
+    otherwise contain confidential information (such as a confidential
+    forwarding address),
+
+(d) for messages forwarded to a confidential address, setting the
+    envelope return address (e.g. SMTP MAIL FROM address) to the NULL
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 23]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+    reverse-path ("<>") (so that no DSNs would be sent from a downstream
+    MTA to the original sender),
+
+(e) for messages forwarded to a confidential address, disabling delivery
+    notifications for the forwarded message (e.g. if the "next-hop" MTA
+    uses ESMTP and supports the DSN extension, by using the NOTIFY=NEVER
+    parameter to the RCPT command), or
+
+(f) when forwarding mail to a confidential address, having the
+    forwarding MTA rewrite the envelope return address for the forwarded
+    message and attempt delivery of that message as if the forwarding
+    MTA were the originator.  On its receipt of final delivery status,
+    the forwarding MTA would issue a DSN to the original sender.
+
+   In general, any optional DSN field may be omitted if the Reporting
+   MTA site determines that inclusion of the field would impose too
+   great a compromise of site confidentiality.  The need for such
+   confidentiality must be balanced against the utility of the omitted
+   information in trouble reports and DSNs gatewayed to foreign
+   environments.
+
+   Implementors are cautioned that many existing MTAs will send
+   nondelivery notifications to a return address in the message header
+   (rather than to the one in the envelope), in violation of SMTP and
+   other protocols.  If a message is forwarded through such an MTA, no
+   reasonable action on the part of the forwarding MTA will prevent the
+   downstream MTA from compromising the forwarding address.  Likewise,
+   if the recipient's MTA automatically responds to messages based on a
+   request in the message header (such as the nonstandard, but widely
+   used, Return-Receipt-To extension header), it will also compromise
+   the forwarding address.
+
+4.3 Non-Repudiation
+
+   Within the framework of today's internet mail, the DSNs defined in
+   this memo provide valuable information to the mail user; however,
+   even a "failed" DSN can not be relied upon as a guarantee that a
+   message was not received by the recipient.  Even if DSNs are not
+   actively forged, conditions exist under which a message can be
+   delivered despite the fact that a failure DSN was issued.
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 24]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   For example, a race condition in the SMTP protocol allows for the
+   duplication of messages if the connection is dropped following a
+   completed DATA command, but before a response is seen by the SMTP
+   client.  This will cause the SMTP client to retransmit the message,
+   even though the SMTP server has already accepted it.[9] If one of
+   those delivery attempts succeeds and the other one fails, a "failed"
+   DSN could be issued even though the message actually reached the
+   recipient.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 25]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+5. Appendix - collected grammar
+
+   NOTE:  The following lexical tokens are defined in RFC 822:  atom,
+   CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text.
+   The date-time lexical token is defined in [8].
+
+action-field = "Action" ":" action-value
+
+action-value =
+     "failed" / "delayed" / "delivered" / "relayed" / "expanded"
+
+address-type = atom
+
+arrival-date-field = "Arrival-Date" ":" date-time
+
+delivery-status-content =
+     per-message-fields 1*( CRLF per-recipient-fields )
+
+diagnostic-code-field =
+     "Diagnostic-Code" ":" diagnostic-type ";" *text
+
+diagnostic-type = atom
+
+dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
+
+envelope-id = *text
+
+extension-field = extension-field-name ":" *text
+
+extension-field-name = atom
+
+final-recipient-field =
+     "Final-Recipient" ":" address-type ";" generic-address
+
+generic-address = *text
+
+last-attempt-date-field = "Last-Attempt-Date" ":" date-time
+
+mta-name = *text
+
+mta-name-type = atom
+
+original-envelope-id-field =
+     "Original-Envelope-Id" ":" envelope-id
+
+original-recipient-field =
+     "Original-Recipient" ":" address-type ";" generic-address
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 26]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+per-message-fields =
+     [ original-envelope-id-field CRLF ]
+     reporting-mta-field CRLF
+     [ dsn-gateway-field CRLF ]
+     [ received-from-mta-field CRLF ]
+     [ arrival-date-field CRLF ]
+     *( extension-field CRLF )
+
+per-recipient-fields =
+     [ original-recipient-field CRLF ]
+     final-recipient-field CRLF
+     action-field CRLF
+     status-field CRLF
+     [ remote-mta-field CRLF ]
+     [ diagnostic-code-field CRLF ]
+     [ last-attempt-date-field CRLF ]
+     [ will-retry-until-field CRLF ]
+     *( extension-field CRLF )
+
+received-from-mta-field =
+     "Received-From-MTA" ":" mta-name-type ";" mta-name
+
+remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
+
+reporting-mta-field =
+     "Reporting-MTA" ":" mta-name-type ";" mta-name
+
+status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+     ; White-space characters and comments are NOT allowed within a
+     ; status-code, though a comment enclosed in parentheses MAY follow
+     ; the last numeric subfield of the status-code.  Each numeric
+     ; subfield within the status-code MUST be expressed without
+     ; leading zero digits.
+
+status-field = "Status" ":" status-code
+
+will-retry-until-field = "Will-Retry-Until" ":" date-time
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 27]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+6. Appendix - Guidelines for gatewaying DSNs
+
+   NOTE:  This section provides non-binding recommendations for the
+   construction of mail gateways that wish to provide semi-transparent
+   delivery reports between the Internet and another electronic mail
+   system.  Specific DSN gateway requirements for a particular pair of
+   mail systems may be defined by other documents.
+
+6.1 Gatewaying from other mail systems to DSNs
+
+   A mail gateway may issue a DSN to convey the contents of a "foreign"
+   delivery or non-delivery notification over Internet mail.  When there
+   are appropriate mappings from the foreign notification elements to
+   DSN fields, the information may be transmitted in those DSN fields.
+   Additional information (such as might be useful in a trouble ticket
+   or needed to tunnel the foreign notification through the Internet)
+   may be defined in extension DSN fields.  (Such fields should be given
+   names that identify the foreign mail protocol, e.g. X400-* for X.400
+   NDN or DN protocol elements)
+
+   The gateway must attempt to supply reasonable values for the
+   Reporting-MTA, Final-Recipient, Action, and Status fields.  These
+   will normally be obtained by translating the values from the remote
+   delivery or non-delivery notification into their Internet-style
+   equivalents.  However, some loss of information is to be expected.
+   For example, the set of status-codes defined for DSNs may not be
+   adequate to fully convey the delivery diagnostic code from the
+   foreign system.  The gateway should assign the most precise code
+   which describes the failure condition, falling back on "generic"
+   codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0
+   (permanent failure) when necessary.  The actual foreign diagnostic
+   code should be retained in the Diagnostic-Code field (with an
+   appropriate diagnostic-type value) for use in trouble tickets or
+   tunneling.
+
+   The sender-specified recipient address, and the original envelope-id,
+   if present in the foreign transport envelope, should be preserved in
+   the Original-Recipient and Original-Envelope-ID fields.
+
+   The gateway should also attempt to preserve the "final" recipient
+   addresses and MTA names from the foreign system.  Whenever possible,
+   foreign protocol elements should be encoded as meaningful printable
+   ASCII strings.
+
+   For DSNs produced from foreign delivery or nondelivery notifications,
+   the name of the gateway MUST appear in the DSN-Gateway field of the
+   DSN.
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 28]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+6.2 Gatewaying from DSNs to other mail systems
+
+   It may be possible to gateway DSNs from the Internet into a foreign
+   mail system.  The primary purpose of such gatewaying is to convey
+   delivery status information in a form that is usable by the
+   destination system.  A secondary purpose is to allow "tunneling" of
+   DSNs through foreign mail systems, in case the DSN may be gatewayed
+   back into the Internet.
+
+   In general, the recipient of the DSN (i.e., the sender of the
+   original message) will want to know, for each recipient: the closest
+   available approximation to the original recipient address, the
+   delivery status (success, failure, or temporary failure), and for
+   failed deliveries, a diagnostic code that describes the reason for
+   the failure.
+
+   If possible, the gateway should attempt to preserve the Original-
+   Recipient address and Original-Envelope-ID (if present), in the
+   resulting foreign delivery status report.
+
+   When reporting delivery failures, if the diagnostic-type subfield of
+   the Diagnostic-Code field indicates that the original diagnostic code
+   is understood by the destination environment, the information from
+   the Diagnostic-Code field should be used.  Failing that, the
+   information in the Status field should be mapped into the closest
+   available diagnostic code used in the destination environment.
+
+   If it is possible to tunnel a DSN through the destination
+   environment, the gateway specification may define a means of
+   preserving the DSN information in the delivery status reports used by
+   that environment.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 29]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+7. Appendix - Guidelines for use of DSNs by mailing list exploders
+
+   NOTE: This section pertains only to the use of DSNs by "mailing
+   lists" as defined in [4], section 7.2.7.
+
+   DSNs are designed to be used by mailing list exploders to allow them
+   to detect and automatically delete recipients for whom mail delivery
+   fails repeatedly.
+
+   When forwarding a message to list subscribers, the mailing list
+   exploder should always set the envelope return address (e.g. SMTP
+   MAIL FROM address) to point to a special address which is set up to
+   received nondelivery reports.  A "smart" mailing list exploder can
+   therefore intercept such nondelivery reports, and if they are in the
+   DSN format, automatically examine them to determine for which
+   recipients a message delivery failed or was delayed.
+
+   The Original-Recipient field should be used if available, since it
+   should exactly match the subscriber address known to the list.  If
+   the Original-Recipient field is not available, the recipient field
+   may resemble the list subscriber address.  Often, however, the list
+   subscriber will have forwarded his mail to a different address, or
+   the address may be subject to some re-writing, so heuristics may be
+   required to successfully match an address from the recipient field.
+   Care is needed in this case to minimize the possibility of false
+   matches.
+
+   The reason for delivery failure can be obtained from the Status and
+   Action fields, and from the Diagnostic-Code field (if the status-type
+   is recognized).  Reports for recipients with action values other than
+   "failed" can generally be ignored; in particular, subscribers should
+   not be removed from a list due to "delayed" reports.
+
+   In general, almost any failure status code (even a "permanent" one)
+   can result from a temporary condition.  It is therefore recommended
+   that a list exploder not delete a subscriber based on any single
+   failure DSN (regardless of the status code), but only on the
+   persistence of delivery failure over a period of time.
+
+   However, some kinds of failures are less likely than others to have
+   been caused by temporary conditions, and some kinds of failures are
+   more likely to be noticed and corrected quickly than others.  Once
+   more precise status codes are defined, it may be useful to
+   differentiate between the status codes when deciding whether to
+   delete a subscriber.  For example, on a list with a high message
+   volume, it might be desirable to temporarily suspend delivery to a
+   recipient address which causes repeated "temporary" failures, rather
+   than simply deleting the recipient.  The duration of the suspension
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 30]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   might depend on the type of error.  On the other hand, a "user
+   unknown" error which persisted for several days could be considered a
+   reliable indication that address were no longer valid.
+
+8. Appendix - IANA registration forms for DSN types
+
+   The forms below are for use when registering a new address-type,
+   diagnostic-type, or MTA-name-type with the Internet Assigned Numbers
+   Authority (IANA).  Each piece of information requested by a
+   registration form may be satisfied either by providing the
+   information on the form itself, or by including a reference to a
+   published, publicly available specification which includes the
+   necessary information.  IANA MAY reject DSN type registrations
+   because of incomplete registration forms, imprecise specifications,
+   or inappropriate type names.
+
+   To register a DSN type, complete the applicable form below and send
+   it via Internet electronic mail to <IANA@IANA.ORG>.
+
+8.1 IANA registration form for address-type
+
+   A registration for a DSN address-type MUST include the following
+   information:
+
+(a) The proposed address-type name.
+
+(b) The syntax for mailbox addresses of this type, specified using BNF,
+    regular expressions, ASN.1, or other non-ambiguous language.
+
+(c) If addresses of this type are not composed entirely of graphic
+    characters from the US-ASCII repertoire, a specification for how
+    they are to be encoded as graphic US-ASCII characters in a DSN
+    Original-Recipient or Final-Recipient DSN field.
+
+(d) [optional] A specification for how addresses of this type are to be
+    translated to and from Internet electronic mail addresses.
+
+8.2 IANA registration form for diagnostic-type
+
+   A registration for a DSN address-type MUST include the following
+   information:
+
+(a) The proposed diagnostic-type name.
+
+(b) A description of the syntax to be used for expressing diagnostic
+    codes of this type as graphic characters from the US-ASCII
+    repertoire.
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 31]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+(c) A list of valid diagnostic codes of this type and the meaning of
+    each code.
+
+(d) [optional] A specification for mapping from diagnostic codes of this
+    type to DSN status codes (as defined in [5]).
+
+8.3 IANA registration form for MTA-name-type
+
+   A registration for a DSN MTA-name-type must include the following
+   information:
+
+(a) The proposed MTA-name-type name.
+
+(b) A description of the syntax of MTA names of this type, using BNF,
+    regular expressions, ASN.1, or other non-ambiguous language.
+
+(c) If MTA names of this type do not consist entirely of graphic
+    characters from the US-ASCII repertoire, a specification for how an
+    MTA name of this type should be expressed as a sequence of graphic
+    US-ASCII characters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 32]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+9. Appendix - Examples
+
+   NOTE:  These examples are provided as illustration only, and are not
+   considered part of the DSN protocol specification.  If an example
+   conflicts with the protocol definition above, the example is wrong.
+
+   Likewise, the use of *-type subfield names or extension fields in
+   these examples is not to be construed as a definition for those type
+   names or extension fields.
+
+   These examples were manually translated from bounced messages using
+   whatever information was available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 33]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+9.1  This is a simple DSN issued after repeated attempts
+     to deliver a message failed.  In this case, the DSN is
+     issued by the same MTA from which the message was originated.
+
+
+   Date: Thu, 7 Jul 1994 17:16:05 -0400
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
+   Message-Id: <199407072116.RAA14128@CS.UTK.EDU>
+   Subject: Returned mail: Cannot send message for 5 days
+   To: <owner-info-mime@cs.utk.edu>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CS.UTK.EDU"
+
+   --RAA14128.773615765/CS.UTK.EDU
+
+   The original message was received at Sat, 2 Jul 1994 17:10:28 -0400
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <louisl@larry.slip.umd.edu>  (unrecoverable error)
+
+      ----- Transcript of session follows -----
+   <louisl@larry.slip.umd.edu>... Deferred: Connection timed out
+         with larry.slip.umd.edu.
+   Message could not be delivered for 5 days
+   Message will be deleted from queue
+
+   --RAA14128.773615765/CS.UTK.EDU
+   content-type: message/delivery-status
+
+   Reporting-MTA: dns; cs.utk.edu
+
+   Original-Recipient: rfc822;louisl@larry.slip.umd.edu
+   Final-Recipient: rfc822;louisl@larry.slip.umd.edu
+   Action: failed
+   Status: 4.0.0
+   Diagnostic-Code: smtp; 426 connection timed out
+   Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
+
+   --RAA14128.773615765/CS.UTK.EDU
+   content-type: message/rfc822
+
+   [original message goes here]
+   --RAA14128.773615765/CS.UTK.EDU--
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 34]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+9.2  This is another DSN issued by the sender's MTA, which
+     contains details of multiple delivery attempts.  Some of
+     these were detected locally, and others by a remote MTA.
+
+
+   Date: Fri, 8 Jul 1994 09:21:47 -0400
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
+   Subject: Returned mail: User unknown
+   To: <owner-ups-mib@CS.UTK.EDU>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="JAA13167.773673707/CS.UTK.EDU"
+
+   --JAA13167.773673707/CS.UTK.EDU
+   content-type: text/plain; charset=us-ascii
+
+      ----- The following addresses had delivery problems -----
+   <arathib@vnet.ibm.com>  (unrecoverable error)
+   <wsnell@sdcc13.ucsd.edu>  (unrecoverable error)
+
+   --JAA13167.773673707/CS.UTK.EDU
+   content-type: message/delivery-status
+
+   Reporting-MTA: dns; cs.utk.edu
+
+   Original-Recipient: rfc822;arathib@vnet.ibm.com
+   Final-Recipient: rfc822;arathib@vnet.ibm.com
+   Action: failed
+   Status: 5.0.0 (permanent failure)
+   Diagnostic-Code: smtp;
+    550 'arathib@vnet.IBM.COM' is not a registered gateway user
+   Remote-MTA: dns; vnet.ibm.com
+
+   Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com
+   Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com
+   Action: delayed
+   Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)
+
+   Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
+   Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
+   Action: failed
+   Status: 5.0.0
+   Diagnostic-Code: smtp; 550 user unknown
+   Remote-MTA: dns; sdcc13.ucsd.edu
+
+   --JAA13167.773673707/CS.UTK.EDU
+   content-type: message/rfc822
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 35]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   [original message goes here]
+   --JAA13167.773673707/CS.UTK.EDU--
+
+
+9.3 A delivery report generated by Message Router (MAILBUS) and
+    gatewayed by PMDF_MR to a DSN.  In this case the gateway did not
+    have sufficient information to supply an original-recipient address.
+
+
+
+   Disclose-recipients: prohibited
+   Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT)
+   From: Message Router Submission Agent <AMMGR@corp.timeplex.com>
+   Subject: Status of : Re: Battery current sense
+   To: owner-ups-mib@CS.UTK.EDU
+   Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com>
+   MIME-version: 1.0
+   content-type: multipart/report; report-type=delivery-status;
+         boundary="84229080704991.122306.SYS30"
+
+   --84229080704991.122306.SYS30
+   content-type: text/plain
+
+   Invalid address - nair_s
+   %DIR-E-NODIRMTCH, No matching Directory Entry found
+
+   --84229080704991.122306.SYS30
+   content-type: message/delivery-status
+
+   Reporting-MTA: mailbus; SYS30
+
+   Final-Recipient: unknown; nair_s
+   Status: 5.0.0 (unknown permanent failure)
+   Action: failed
+
+   --84229080704991.122306.SYS30--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 36]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+9.4 A delay report from a multiprotocol MTA.  Note that there is no
+    returned content, so no third body part appears in the DSN.
+
+   From: <postmaster@nsfnet-relay.ac.uk>
+   Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
+   Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
+             id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
+   Sun, 10 Jul 1994 00:36:51 +0100
+   To: owner-info-mime@cs.utk.edu
+   Date: Sun, 10 Jul 1994 00:36:51 +0100
+   Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
+   content-type: multipart/report; report-type=delivery-status;
+         boundary=foobar
+
+   --foobar
+   content-type: text/plain
+
+   The following message:
+
+   UA-ID:  Reliable PC (...
+   Q-ID:   sun2.nsf:77/msg.11820-0
+
+   has not been delivered to the intended recipient:
+
+   thomas@de-montfort.ac.uk
+
+   despite repeated delivery attempts over the past 24 hours.
+
+   The  usual cause of this problem is that the remote system is
+   temporarily unavailable.
+
+   Delivery will continue to be attempted up to a total elapsed
+   time of  168 hours, ie 7 days.
+
+   You  will  be  informed  if  delivery proves to be impossible
+   within this time.
+
+   Please quote the Q-ID in any queries regarding this mail.
+
+   --foobar
+   content-type: message/delivery-status
+
+   Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk
+
+   Final-Recipient: rfc822;thomas@de-montfort.ac.uk
+   Status: 4.0.0 (unknown temporary failure)
+   Action: delayed
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 37]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+   --foobar--
+
+10. Acknowledgments
+
+   The authors wish to thank the following people for their reviews of
+   earlier drafts of this document and their suggestions for
+   improvement:  Eric Allman, Harald Alvestrand, Allan Cargille, Jim
+   Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko
+   Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark
+   Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, and Gregory
+   Sheehan.
+
+11. References
+
+[1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions",
+    RFC 1521, Bellcore, Innosoft, September 1993.
+
+[2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting
+    of Mail System Administrative Messages", RFC 1892, Octal Network
+    Services, January 1996.
+
+[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+    USC/Information Sciences Institute, August 1982.
+
+[4] Moore, K., "SMTP Service Extension for Delivery Status
+    Notifications", RFC 1891, University of Tennessee, January 1996.
+
+[5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, Octal
+    Network Services, January 1996.
+
+[6] Crocker, D., "Standard for the Format of ARPA Internet Text
+    Messages", STD 11, RFC 822, UDEL, August 1982.
+
+[7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two:
+    Message Header Extensions for Non-Ascii Text", RFC 1522, University
+    of Tennessee, September 1993.
+
+[8] Braden, R. (ed.)  "Requirements for Internet Hosts - Application and
+    Support", STD 3, RFC 1123, USC/Information Sciences Institute,
+    October 1989.
+
+[9] Partridge, C., "Duplicate Messages and SMTP", RFC 1047, BBN,
+    February 1988.
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 38]
+
+RFC 1894             Delivery Status Notifications          January 1996
+
+
+11. Authors' Addresses
+
+   Keith Moore
+   University of Tennessee
+   107 Ayres Hall
+   Knoxville, TN 37996-1301
+   USA
+
+   EMail: moore@cs.utk.edu
+   Phone: +1 615 974 3126
+   Fax: +1 615 974 8296
+
+
+   Gregory M. Vaudreuil
+   Octel Network Services
+   17080 Dallas Parkway
+   Dallas, TX 75248-1905
+   USA
+
+   EMail: Greg.Vaudreuil@Octel.Com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore & Vaudreuil           Standards Track                    [Page 39]
+
diff --git a/RFC/rfc1938.txt b/RFC/rfc1938.txt
new file mode 100644
index 00000000..5d3a9002
--- /dev/null
+++ b/RFC/rfc1938.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                          N. Haller
+Request for Comments: 1938                                      Bellcore
+Category: Standards Track                                        C. Metz
+                                              Kaman Sciences Corporation
+                                                                May 1996
+
+
+                       A One-Time Password System
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1.0 ABSTRACT
+
+   This document describes a one-time password authentication system
+   (OTP). The system provides authentication for system access (login)
+   and other applications requiring authentication that is secure
+   against passive attacks based on replaying captured reusable
+   passwords. OTP evolved from the S/KEY (S/KEY is a trademark of
+   Bellcore) One-Time Password System that was released by Bellcore and
+   is described in references [3] and [5].
+
+2.0 OVERVIEW
+
+   One form of attack on networked computing systems is eavesdropping on
+   network connections to obtain authentication information such as the
+   login IDs and passwords of legitimate users. Once this information is
+   captured, it can be used at a later time to gain access to the
+   system. One-time password systems are designed to counter this type
+   of attack, called a "replay attack" [4].
+
+   The authentication system described in this document uses a secret
+   pass-phrase to generate a sequence of one-time (single use)
+   passwords.  With this system, the user's secret pass-phrase never
+   needs to cross the network at any time such as during authentication
+   or during pass-phrase changes. Thus, it is not vulnerable to replay
+   attacks.  Added security is provided by the property that no secret
+   information need be stored on any system, including the server being
+   protected.
+
+   The OTP system protects against external passive attacks against the
+   authentication subsystem. It does not prevent a network eavesdropper
+   from gaining access to private information and does not provide
+
+
+
+Haller & Metz               Standards Track                     [Page 1]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+   protection against either "social engineering" or active attacks [9].
+
+3.0 INTRODUCTION
+
+   There are two entities in the operation of the OTP one-time password
+   system. The generator must produce the appropriate one-time password
+   from the user's secret pass-phrase and from information provided in
+   the challenge from the server. The server must send a challenge that
+   includes the appropriate generation parameters to the generator, must
+   verify the one-time password received, must store the last valid
+   one-time password it received, and must store the corresponding one-
+   time password sequence number. The server must also facilitate the
+   changing of the user's secret pass-phrase in a secure manner.
+
+   The OTP system generator passes the user's secret pass-phrase, along
+   with a seed received from the server as part of the challenge,
+   through multiple iterations of a secure hash function to produce a
+   one-time password. After each successful authentication, the number
+   of secure hash function iterations is reduced by one.  Thus, a unique
+   sequence of passwords is generated.  The server verifies the one-time
+   password received from the generator by computing the secure hash
+   function once and comparing the result with the previously accepted
+   one-time password.  This technique was first suggested by Leslie
+   Lamport [1].
+
+4.0 REQUIREMENTS TERMINOLOGY
+
+   In this document, the words that are used to define the significance
+   of each particular requirement are usually capitalized.  These words
+   are:
+
+    - MUST
+
+      This word or the adjective "REQUIRED" means that the item is an
+      absolute requirement of the specification.
+
+    - SHOULD
+
+      This word or the adjective "RECOMMENDED" means that there might
+      exist valid reasons in particular circumstances to ignore this
+      item, but the full implications should be understood and the
+      case carefully weighed before taking a different course.
+
+    - MAY
+
+      This word or the adjective "OPTIONAL" means that this item is
+      truly optional.  One vendor might choose to include the item
+      because a particular marketplace requires it or because it
+
+
+
+Haller & Metz               Standards Track                     [Page 2]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+      enhances the product, for example; another vendor may omit the
+      same item.
+
+5.0 SECURE HASH FUNCTION
+
+   The security of the OTP system is based on the non-invertability of a
+   secure hash function. Such a function must be tractable to compute in
+   the forward direction, but computationally infeasible to invert.
+
+   The interfaces are currently defined for three such hash algorithms,
+   MD4 [2] and MD5 [6] by Ronald Rivest, and SHA [7] by NIST.  All
+   conforming implementations of both server and generators MUST support
+   MD5.  They SHOULD support SHA and MAY also support MD4.  Clearly, the
+   generator and server must use the same algorithm in order to
+   interoperate. Other hash algorithms may be specified for use with
+   this system by publishing the appropriate interfaces.
+
+   The secure hash algorithms listed above have the property that they
+   accept an input that is arbitrarily long and produce a fixed size
+   output. The OTP system folds this output to 64 bits using the
+   algorithms in the Appendix A. 64 bits is also the length of the one-
+   time passwords. This is believed to be long enough to be secure and
+   short enough to be entered manually (see below, Form of Output) when
+   necessary.
+
+6.0 GENERATION OF ONE-TIME PASSWORDS
+
+   This section describes the generation of the one-time passwords.
+   This process consists of an initial step in which all inputs are
+   combined, a computation step where the secure hash function is
+   applied a specified number of times, and an output function where the
+   64 bit one-time password is converted to a human readable form.
+
+   Initial Step
+
+      In principle, the user's secret pass-phrase may be of any length.
+      To reduce the risk from techniques such as exhaustive search or
+      dictionary attacks, character string pass-phrases MUST contain at
+      least 10 characters (see Form of Inputs below).  All
+      implementations MUST support a pass-phrases of at least 63
+      characters.  The secret pass-phrase is frequently, but is not
+      required to be, textual information provided by a user.
+
+      In this step, the pass phrase is concatenated with a seed that is
+      transmitted from the server in clear text. This non-secret seed
+      allows clients to use the same secret pass-phrase on multiple
+      machines (using different seeds) and to safely recycle their
+      secret pass-phrases by changing the seed.
+
+
+
+Haller & Metz               Standards Track                     [Page 3]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+      The result of the concatenation is passed through the secure hash
+      function and then is reduced to 64 bits using one of the function
+      dependent algorithms shown in Appendix A.
+
+   Computation Step
+
+      A sequence of one-time passwords is produced by applying the
+      secure hash function multiple times to the output of the initial
+      step (called S). That is, the first one-time password to be used
+      is produced by passing S through the secure hash function a number
+      of times (N) specified by the user. The next one-time password to
+      be used is generated by passing S though the secure hash function
+      N-1 times. An eavesdropper who has monitored the transmission of a
+      one- time password would not be able to generate the next required
+      password because doing so would mean inverting the hash function.
+
+   Form of Inputs
+
+      The secret pass-phrase is seen only by the OTP generator. To allow
+      interchangeability of generators, all generators MUST support a
+      secret pass-phrase of 10 to 63 characters. Implementations MAY
+      support a longer pass-phrase, but such implementations risk the
+      loss of interchangeability with implementations supporting only
+      the minimum.
+
+      The seed MUST consist of purely alphanumeric characters and MUST
+      be of one to 16 characters in length. The seed is a string of
+      characters that MUST not contain any blanks and SHOULD consist of
+      strictly alphanumeric characters from the ISO-646 Invariant Code
+      Set.  The seed MUST be case insensitive and MUST be internally
+      converted to lower case before it is processed.
+
+      The sequence number and seed together constitute a larger unit of
+      data called the challenge. The challenge gives the generator the
+      parameters it needs to calculate the correct one-time password
+      from the secret pass-phrase. The challenge MUST be in a standard
+      syntax so that automated generators can recognize the challenge in
+      context and extract these parameters. The syntax of the challenge
+      is:
+
+          otp-<algorithm identifier> <sequence integer> <seed>
+
+      The three tokens MUST be separated by a white space (defined as
+      any number of spaces and/or tabs) and the entire challenge string
+      MUST be terminated with either a space or a new line. The string
+      "otp-" MUST be in lower case.  The algorithm identifier is case
+      sensitive (the existing identifiers are all lower case), and the
+      seed is case insensitive and converted before use to lower case.
+
+
+
+Haller & Metz               Standards Track                     [Page 4]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+      If additional algorithms are defined, appropriate identifiers
+      (short, but not limited to three or four characters) must be
+      defined. The currently defined algorithm identifiers are:
+
+      md4        MD4 Message Digest
+      md5        MD5 Message Digest
+      sha1       NIST Secure Hash Algorithm Revision 1
+
+      An example of an OTP challenge is:   otp-md5 487 dog2
+
+   Form of Output
+
+      The one-time password generated by the above procedure is 64 bits
+      in length. Entering a 64 bit number is a difficult and error prone
+      process. Some generators insert this password into the input
+      stream and some others make it available for system "cut and
+      paste." Still other arrangements require the one-time password to
+      be entered manually. The OTP system is designed to facilitate this
+      manual entry without impeding automatic methods. The one-time
+      password therefore MAY be converted to, and all servers MUST be
+      capable of accepting it as, a sequence of six short (1 to 4
+      letter) easily typed words that only use characters from ISO-646
+      IVCS. Each word is chosen from a dictionary of 2048 words; at 11
+      bits per word, all one-time passwords may be encoded.
+
+      The two extra bits in this encoding are used to store a checksum.
+      The 64 bits of key are broken down into pairs of bits, then these
+      pairs are summed together. The two least significant bits of this
+      sum are encoded in the last two bits of the six word sequence with
+      the least significant bit of the sum as the last bit encoded. All
+      OTP generators MUST calculate this checksum and all OTP servers
+      MUST verify this checksum explicitly as part of the operation of
+      decoding this representation of the one-time password.
+
+      Generators that produce the six-word format MUST present the words
+      in upper case with single spaces used as separators. All servers
+      MUST accept six-word format without regard to case and white space
+      used as a separator. The two lines below represent the same one-
+      time password.  The first is valid as output from a generator and
+      as input a server, the second is valid only as human input to a
+      server.
+
+          OUST COAT FOAL MUG BEAK TOTE
+          oust coat foal  mug  beak  tote
+
+      Interoperability requires that all OTP servers and generators use
+      the same dictionary. The standard dictionary was originally
+      specified in the "S/KEY One Time Password System" that is
+
+
+
+Haller & Metz               Standards Track                     [Page 5]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+      described in RFC 1760 [5].  This dictionary is included in this
+      document as Appendix C.
+
+      To facilitate the implementation of smaller generators,
+      hexadecimal output is an acceptable alternative for the
+      presentation of the one-time password. All implementations of the
+      server software MUST accept case-insensitive hexadecimal as well
+      as six-word format. The hexadecimal digits may be separated by
+      white space so servers are REQUIRED to ignore all white space.  If
+      the representation is partitioned by white space, leading zeros
+      must be retained. Examples of hexadecimal format are:
+
+         Representation                Value
+
+         3503785b369cda8b              0x3503785b369cda8b
+         e5cc a1b8 7c13 096b           0xe5cca1b87c13096b
+         C7 48 90 F4 27 7B A1 CF       0xc74890f4277ba1cf
+         47 9 A68 28 4C 9D 0 1BC       0x479a68284c9d01bc
+
+      In addition to accepting six-word and hexadecimal encodings of the
+      64 bit one-time password, servers SHOULD accept the alternate
+      dictionary encoding described in Appendix B.  The six words in
+      this encoding MUST not overlap the set of words in the standard
+      dictionary.  To avoid ambiguity with the hexadecimal
+      representation, words in the alternate dictionary MUST not be
+      comprised solely of the letters A-F.  Decoding words thus encoded
+      does not require any knowledge of the alternative dictionary used
+      so the acceptance of any alternate dictionary implies the
+      acceptance of all alternate dictionaries.  Words in the
+      alternative dictionaries are case sensitive.  Generators and
+      servers MUST preserve the case in the processing of these words.
+
+      In summary, all conforming servers MUST accept six-word input that
+      uses the Standard Dictionary (RFC 1760 and Appendix C), MUST
+      accept hexadecimal encoding, and SHOULD accept six-word input that
+      uses the Alternative Dictionary technique (Appendix B).  As there
+      is a remote possibility that a hexadecimal encoding of a one-time
+      password will look like a valid six-word standard dictionary
+      encoding, all implementations MUST use the following scheme.  If a
+      six-word encoded one-time password is valid, it is accepted.
+      Otherwise, if the one-time password can be interpreted as
+      hexadecimal, and with that decoding it is valid, then it is
+      accepted.
+
+
+
+
+
+
+
+
+Haller & Metz               Standards Track                     [Page 6]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+7.0 VERIFICATION OF ONE-TIME PASSWORDS
+
+   An application on the server system that requires OTP authentication
+   is expected to issue an OTP challenge as described above. Given the
+   parameters from this challenge and the secret pass-phrase, the
+   generator can compute (or lookup) the one-time password that is
+   passed to the server to be verified.
+
+   The server system has a database containing, for each user, the one-
+   time password from the last successful authentication or the first
+   OTP of a newly initialized sequence. To authenticate the user, the
+   server decodes the one-time password received from the generator into
+   a 64-bit key and then runs this key through the secure hash function
+   once. If the result of this operation matches the stored previous
+   OTP, the authentication is successful and the accepted one-time
+   password is stored for future use.
+
+8.0 PASS-PHRASE CHANGES
+
+   Because the number of hash function applications executed by the
+   generator decreases by one each time, at some point the user must
+   reinitialize the system or be unable to authenticate.
+
+   Although some installations may not permit users to initialize
+   remotely, implementations MUST provide a means to do so that does not
+   reveal the user's secret pass-phrase.  One way is to provide a means
+   to reinitialize the  sequence through explicit specification of the
+   first one-time password.
+
+   When the sequence of one-time passwords is reinitialized,
+   implementations MUST verify that the seed or the pass-phrase is
+   changed.  Installations SHOULD discourage any operation that sends
+   the secret pass-phrase over a network in clear-text as such practice
+   defeats the concept of a one-time password.
+
+   Implementations MAY use the following technique for
+   [re]initialization:
+
+    o  The user picks a new seed and hash count (default values may
+       be offered).  The user provides these, along with the
+       corresponding generated one-time password, to the host system.
+
+    o  The user MAY also provide the corresponding generated one
+       time password for count-1 as an error check.
+
+    o  The user SHOULD provide the generated one-time password for
+       the old seed and old hash count to protect an idle terminal
+       or workstation (this implies that when the count is 1, the
+
+
+
+Haller & Metz               Standards Track                     [Page 7]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+       user can login but cannot then change the seed or count).
+
+   In the future a specific protocol may be defined for reinitialization
+   that will permit smooth and possibly automated interoperation of all
+   hosts and generators.
+
+9.0 PROTECTION AGAINST RACE ATTACK
+
+   All conforming server implementations MUST protect against the race
+   condition described in this section.  A defense against this attack
+   is outlined; implementations MAY use this approach or MAY select an
+   alternative defense.
+
+   It is possible for an attacker to listen to most of a one-time
+   password, guess the remainder, and then race the legitimate user to
+   complete the authentication.  Multiple guesses against the last word
+   of the six-word format are likely to succeed.
+
+   One possible defense is to prevent a user from starting multiple
+   simultaneous authentication sessions. This means that once the
+   legitimate user has initiated authentication, an attacker would be
+   blocked until the first authentication process has completed.  In
+   this approach, a timeout is necessary to thwart a denial of service
+   attack.
+
+10.0 SECURITY CONSIDERATIONS
+
+   This entire document discusses an authentication system that improves
+   security by limiting the danger of eavesdropping/replay attacks that
+   have been used against simple password systems [4].
+
+   The use of the OTP system only provides protections against passive
+   eavesdropping/replay attacks.  It does not provide for the privacy of
+   transmitted data, and it does not provide protection against active
+   attacks.  Active attacks against TCP connections are known to be
+   present in the current Internet [9].
+
+   The success of the OTP system to protect host systems is dependent on
+   the non-invertability of the secure hash functions used.  To our
+   knowledge, none of the hash algorithms have been broken, but it is
+   generally believed [6] that MD4 is not as strong as MD5.  If a server
+   supports multiple hash algorithms, it is only as secure as the
+   weakest algorithm.
+
+
+
+
+
+
+
+
+Haller & Metz               Standards Track                     [Page 8]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+11.0 ACKNOWLEDGMENTS
+
+   The idea behind OTP authentication was first proposed by Leslie
+   Lamport [1]. Bellcore's S/KEY system, from which OTP is derived, was
+   proposed by Phil Karn, who also wrote most of the Bellcore reference
+   implementation.
+
+12.0 REFERENCES
+
+  [1]  Leslie Lamport, "Password Authentication with Insecure
+       Communication", Communications of the ACM 24.11 (November
+       1981), 770-772
+
+  [2]  Rivest, R., "The MD4 Message-Digest Algorithm, RFC 1320",
+       MIT and RSA Data Security, Inc., April 1992.
+
+  [3]  Neil Haller, "The S/KEY One-Time Password System", Proceedings
+       of the ISOC Symposium on Network and Distributed System
+       Security, February 1994, San Diego, CA
+
+  [4]  Haller, N., and R. Atkinson, "On Internet Authentication",
+       RFC 1704, Bellcore and Naval Research Laboratory, October 1994.
+
+  [5]  Haller, N., "The S/KEY One-Time Password System", RFC 1760,
+       Bellcore, February 1995.
+
+  [6]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+       MIT and RSA Data Security, Inc., April 1992.
+
+  [7]  National Institute of Standards and Technology (NIST),
+       "Announcing the Secure Hash Standard", FIPS 180-1, U.S.
+       Department of Commerce, April 1995.
+
+  [8]  International Standard - Information Processing -- ISO 7-bit
+       coded character set for information interchange (Invariant Code
+       Set), ISO-646, International Standards Organization, Geneva,
+       Switzerland, 1983
+
+  [9]  Computer Emergency Response Team (CERT), "IP Spoofing and
+       Hijacked Terminal Connections", CA-95:01, January 1995.
+       Available via anonymous ftp from info.cert.org in
+       /pub/cert_advisories.
+
+
+
+
+
+
+
+
+
+Haller & Metz               Standards Track                     [Page 9]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+13.0 AUTHORS' ADDRESSES
+
+   Neil Haller
+   Bellcore
+   MCC 1C-265B
+   445 South Street
+   Morristown, NJ, 07960-6438, USA
+
+   Phone: +1 201 829-4478
+   Fax:   +1 201 829-2504
+   EMail: nmh@bellcore.com
+
+
+   Craig Metz
+   Kaman Sciences Corporation
+   For NRL Code 5544
+   4555 Overlook Avenue, S.W.
+   Washington, DC, 20375-5337, USA
+
+   Phone: +1 202 404-7122
+   Fax:   +1 202 404-7942
+   EMail: cmetz@cs.nrl.navy.mil
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haller & Metz               Standards Track                    [Page 10]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+Appendix A   -   Interfaces to Secure Hash Algorithms
+
+MD4 Message Digest (see reference [2])
+
+          strcpy(buf,seed);
+          strcat(buf,passwd);
+          MDbegin(&md)
+          MDupdate(&md,(unsigned char *)buf,8*buflen);
+
+          /* Fold result to 64 bits */
+          md.buffer[0] ^= md.buffer[2];
+          md.buffer[1] ^= md.buffer[3];
+
+
+MD5 Message Digest (see reference [6])
+
+          MD5_CTX mdCxt;
+
+          strcpy(buf,seed);
+          strcat(buf,passwd);
+
+          /* Crunch the key through MD5  */
+          MD5Init(&mdCxt);
+          MD5Update(&mdCxt,(unsigned char *)bits,strlen(bits));
+          MD5Update(&mdCxt,(unsigned char *)buf,buflen);
+          MD5Final(&mdCxt);
+
+          /* Fold result to 64 bits */
+          for( i = 0; i < 8; i++ )
+              result[i] = mdCxt.digest[i] ^ mdCxt.digest[i+8];
+
+
+SHA Secure Hash Algorithm (see reference [7])
+
+
+          /*  Fold 160 bit result to 64 bits */
+          md.buffer[0] ^= md.buffer[2];
+          md.buffer[1] ^= md.buffer[3];
+          md.buffer[0] ^= md.buffer[4];
+
+Appendix B   -   Alternative Dictionary Algorithm
+
+   The purpose of alternative dictionary encoding of the OTP one-time
+   password is to allow the use of language specific or friendly words.
+   As case translation is not always well defined, the alternative
+   dictionary encoding is case insensitive.  Servers SHOULD accept this
+   encoding in addition to the standard 6-word and hexadecimal
+   encodings.
+
+
+
+Haller & Metz               Standards Track                    [Page 11]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+GENERATOR ENCODING USING AN ALTERNATE DICTIONARY
+
+  The standard 6-word encoding uses the placement of a word in the
+  dictionary to represent an 11-bit number. The 64-bit one-time
+  password can then be represented by six words.
+
+  An alternative dictionary of 2048 words may be created such that
+  each word W and position of the word in the dictionary N obey the
+  relationship:
+
+          alg( W ) % 2048 == N
+  where
+          alg is the hash algorithm used (e.g. MD4, MD5, SHA1).
+
+  In addition, no words in the standard dictionary may be chosen.
+
+  The generator expands the 64-bit one-time password to 66 bits by
+  computing parity as with the standard 6-word encoding.  The six 11-
+  bit numbers are then converted to words using the dictionary that
+  was created such that the above relationship holds.
+
+
+SERVER DECODING OF ALTERNATE DICTIONARY ONE-TIME PASSWORDS
+
+  The server accepting alternative dictionary encoding converts each
+  word to an 11-bit number using the above encoding. These numbers are
+  then used in the same way as the decoded standard dictionary words
+  to form the 66-bit one-time password.
+
+  The server does not need to have access to the alternate dictionary
+  that was used to create the one-time password it is authenticating.
+  This is because the decoding from word to 11-bit number does not
+  make any use of the dictionary.  As a result of the independence of
+  the dictionary, a server accepting one alternate dictionary accept
+  all alternate dictionaries.
+
+Appendix C - Dictionary for Converting Between 6-Word and Binary
+Formats
+
+   This dictionary is from the module put.c in the original Bellcore
+   reference distribution.
+
+{        "A",    "ABE",   "ACE",   "ACT",   "AD",    "ADA",   "ADD",
+"AGO",   "AID",  "AIM",   "AIR",   "ALL",   "ALP",   "AM",    "AMY",
+"AN",    "ANA",  "AND",   "ANN",   "ANT",   "ANY",   "APE",   "APS",
+"APT",   "ARC",  "ARE",   "ARK",   "ARM",   "ART",   "AS",    "ASH",
+"ASK",   "AT",   "ATE",   "AUG",   "AUK",   "AVE",   "AWE",   "AWK",
+"AWL",   "AWN",  "AX",    "AYE",   "BAD",   "BAG",   "BAH",   "BAM",
+
+
+
+Haller & Metz               Standards Track                    [Page 12]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+"BAN",   "BAR",  "BAT",   "BAY",   "BE",    "BED",   "BEE",   "BEG",
+"BEN",   "BET",  "BEY",   "BIB",   "BID",   "BIG",   "BIN",   "BIT",
+"BOB",   "BOG",  "BON",   "BOO",   "BOP",   "BOW",   "BOY",   "BUB",
+"BUD",   "BUG",  "BUM",   "BUN",   "BUS",   "BUT",   "BUY",   "BY",
+"BYE",   "CAB",  "CAL",   "CAM",   "CAN",   "CAP",   "CAR",   "CAT",
+"CAW",   "COD",  "COG",   "COL",   "CON",   "COO",   "COP",   "COT",
+"COW",   "COY",  "CRY",   "CUB",   "CUE",   "CUP",   "CUR",   "CUT",
+"DAB",   "DAD",  "DAM",   "DAN",   "DAR",   "DAY",   "DEE",   "DEL",
+"DEN",   "DES",  "DEW",   "DID",   "DIE",   "DIG",   "DIN",   "DIP",
+"DO",    "DOE",  "DOG",   "DON",   "DOT",   "DOW",   "DRY",   "DUB",
+"DUD",   "DUE",  "DUG",   "DUN",   "EAR",   "EAT",   "ED",    "EEL",
+"EGG",   "EGO",  "ELI",   "ELK",   "ELM",   "ELY",   "EM",    "END",
+"EST",   "ETC",  "EVA",   "EVE",   "EWE",   "EYE",   "FAD",   "FAN",
+"FAR",   "FAT",  "FAY",   "FED",   "FEE",   "FEW",   "FIB",   "FIG",
+"FIN",   "FIR",  "FIT",   "FLO",   "FLY",   "FOE",   "FOG",   "FOR",
+"FRY",   "FUM",  "FUN",   "FUR",   "GAB",   "GAD",   "GAG",   "GAL",
+"GAM",   "GAP",  "GAS",   "GAY",   "GEE",   "GEL",   "GEM",   "GET",
+"GIG",   "GIL",  "GIN",   "GO",    "GOT",   "GUM",   "GUN",   "GUS",
+"GUT",   "GUY",  "GYM",   "GYP",   "HA",    "HAD",   "HAL",   "HAM",
+"HAN",   "HAP",  "HAS",   "HAT",   "HAW",   "HAY",   "HE",    "HEM",
+"HEN",   "HER",  "HEW",   "HEY",   "HI",    "HID",   "HIM",   "HIP",
+"HIS",   "HIT",  "HO",    "HOB",   "HOC",   "HOE",   "HOG",   "HOP",
+"HOT",   "HOW",  "HUB",   "HUE",   "HUG",   "HUH",   "HUM",   "HUT",
+"I",     "ICY",  "IDA",   "IF",    "IKE",   "ILL",   "INK",   "INN",
+"IO",    "ION",  "IQ",    "IRA",   "IRE",   "IRK",   "IS",    "IT",
+"ITS",   "IVY",  "JAB",   "JAG",   "JAM",   "JAN",   "JAR",   "JAW",
+"JAY",   "JET",  "JIG",   "JIM",   "JO",    "JOB",   "JOE",   "JOG",
+"JOT",   "JOY",  "JUG",   "JUT",   "KAY",   "KEG",   "KEN",   "KEY",
+"KID",   "KIM",  "KIN",   "KIT",   "LA",    "LAB",   "LAC",   "LAD",
+"LAG",   "LAM",  "LAP",   "LAW",   "LAY",   "LEA",   "LED",   "LEE",
+"LEG",   "LEN",  "LEO",   "LET",   "LEW",   "LID",   "LIE",   "LIN",
+"LIP",   "LIT",  "LO",    "LOB",   "LOG",   "LOP",   "LOS",   "LOT",
+"LOU",   "LOW",  "LOY",   "LUG",   "LYE",   "MA",    "MAC",   "MAD",
+"MAE",   "MAN",  "MAO",   "MAP",   "MAT",   "MAW",   "MAY",   "ME",
+"MEG",   "MEL",  "MEN",   "MET",   "MEW",   "MID",   "MIN",   "MIT",
+"MOB",   "MOD",  "MOE",   "MOO",   "MOP",   "MOS",   "MOT",   "MOW",
+"MUD",   "MUG",  "MUM",   "MY",    "NAB",   "NAG",   "NAN",   "NAP",
+"NAT",   "NAY",  "NE",    "NED",   "NEE",   "NET",   "NEW",   "NIB",
+"NIL",   "NIP",  "NIT",   "NO",    "NOB",   "NOD",   "NON",   "NOR",
+"NOT",   "NOV",  "NOW",   "NU",    "NUN",   "NUT",   "O",     "OAF",
+"OAK",   "OAR",  "OAT",   "ODD",   "ODE",   "OF",    "OFF",   "OFT",
+"OH",    "OIL",  "OK",    "OLD",   "ON",    "ONE",   "OR",    "ORB",
+"ORE",   "ORR",  "OS",    "OTT",   "OUR",   "OUT",   "OVA",   "OW",
+"OWE",   "OWL",  "OWN",   "OX",    "PA",    "PAD",   "PAL",   "PAM",
+"PAN",   "PAP",  "PAR",   "PAT",   "PAW",   "PAY",   "PEA",   "PEG",
+"PEN",   "PEP",  "PER",   "PET",   "PEW",   "PHI",   "PI",    "PIE",
+"PIN",   "PIT",  "PLY",   "PO",    "POD",   "POE",   "POP",   "POT",
+"POW",   "PRO",  "PRY",   "PUB",   "PUG",   "PUN",   "PUP",   "PUT",
+
+
+
+Haller & Metz               Standards Track                    [Page 13]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+"QUO",   "RAG",  "RAM",   "RAN",   "RAP",   "RAT",   "RAW",   "RAY",
+"REB",   "RED",  "REP",   "RET",   "RIB",   "RID",   "RIG",   "RIM",
+"RIO",   "RIP",  "ROB",   "ROD",   "ROE",   "RON",   "ROT",   "ROW",
+"ROY",   "RUB",  "RUE",   "RUG",   "RUM",   "RUN",   "RYE",   "SAC",
+"SAD",   "SAG",  "SAL",   "SAM",   "SAN",   "SAP",   "SAT",   "SAW",
+"SAY",   "SEA",  "SEC",   "SEE",   "SEN",   "SET",   "SEW",   "SHE",
+"SHY",   "SIN",  "SIP",   "SIR",   "SIS",   "SIT",   "SKI",   "SKY",
+"SLY",   "SO",   "SOB",   "SOD",   "SON",   "SOP",   "SOW",   "SOY",
+"SPA",   "SPY",  "SUB",   "SUD",   "SUE",   "SUM",   "SUN",   "SUP",
+"TAB",   "TAD",  "TAG",   "TAN",   "TAP",   "TAR",   "TEA",   "TED",
+"TEE",   "TEN",  "THE",   "THY",   "TIC",   "TIE",   "TIM",   "TIN",
+"TIP",   "TO",   "TOE",   "TOG",   "TOM",   "TON",   "TOO",   "TOP",
+"TOW",   "TOY",  "TRY",   "TUB",   "TUG",   "TUM",   "TUN",   "TWO",
+"UN",    "UP",   "US",    "USE",   "VAN",   "VAT",   "VET",   "VIE",
+"WAD",   "WAG",  "WAR",   "WAS",   "WAY",   "WE",    "WEB",   "WED",
+"WEE",   "WET",  "WHO",   "WHY",   "WIN",   "WIT",   "WOK",   "WON",
+"WOO",   "WOW",  "WRY",   "WU",    "YAM",   "YAP",   "YAW",   "YE",
+"YEA",   "YES",  "YET",   "YOU",   "ABED",  "ABEL",  "ABET",  "ABLE",
+"ABUT",  "ACHE",  "ACID", "ACME",  "ACRE",  "ACTA",  "ACTS",  "ADAM",
+"ADDS",  "ADEN",  "AFAR", "AFRO",  "AGEE",  "AHEM",  "AHOY",  "AIDA",
+"AIDE",  "AIDS",  "AIRY", "AJAR",  "AKIN",  "ALAN",  "ALEC",  "ALGA",
+"ALIA",  "ALLY",  "ALMA", "ALOE",  "ALSO",  "ALTO",  "ALUM",  "ALVA",
+"AMEN",  "AMES",  "AMID", "AMMO",  "AMOK",  "AMOS",  "AMRA",  "ANDY",
+"ANEW",  "ANNA",  "ANNE", "ANTE",  "ANTI",  "AQUA",  "ARAB",  "ARCH",
+"AREA",  "ARGO",  "ARID", "ARMY",  "ARTS",  "ARTY",  "ASIA",  "ASKS",
+"ATOM",  "AUNT",  "AURA", "AUTO",  "AVER",  "AVID",  "AVIS",  "AVON",
+"AVOW",  "AWAY",  "AWRY", "BABE",  "BABY",  "BACH",  "BACK",  "BADE",
+"BAIL",  "BAIT",  "BAKE", "BALD",  "BALE",  "BALI",  "BALK",  "BALL",
+"BALM",  "BAND",  "BANE", "BANG",  "BANK",  "BARB",  "BARD",  "BARE",
+"BARK",  "BARN",  "BARR", "BASE",  "BASH",  "BASK",  "BASS",  "BATE",
+"BATH",  "BAWD",  "BAWL", "BEAD",  "BEAK",  "BEAM",  "BEAN",  "BEAR",
+"BEAT",  "BEAU",  "BECK", "BEEF",  "BEEN",  "BEER",  "BEET",  "BELA",
+"BELL",  "BELT",  "BEND", "BENT",  "BERG",  "BERN",  "BERT",  "BESS",
+"BEST",  "BETA",  "BETH", "BHOY",  "BIAS",  "BIDE",  "BIEN",  "BILE",
+"BILK",  "BILL",  "BIND", "BING",  "BIRD",  "BITE",  "BITS",  "BLAB",
+"BLAT",  "BLED",  "BLEW", "BLOB",  "BLOC",  "BLOT",  "BLOW",  "BLUE",
+"BLUM",  "BLUR",  "BOAR", "BOAT",  "BOCA",  "BOCK",  "BODE",  "BODY",
+"BOGY",  "BOHR",  "BOIL", "BOLD",  "BOLO",  "BOLT",  "BOMB",  "BONA",
+"BOND",  "BONE",  "BONG", "BONN",  "BONY",  "BOOK",  "BOOM",  "BOON",
+"BOOT",  "BORE",  "BORG", "BORN",  "BOSE",  "BOSS",  "BOTH",  "BOUT",
+"BOWL",  "BOYD",  "BRAD", "BRAE",  "BRAG",  "BRAN",  "BRAY",  "BRED",
+"BREW",  "BRIG",  "BRIM", "BROW",  "BUCK",  "BUDD",  "BUFF",  "BULB",
+"BULK",  "BULL",  "BUNK", "BUNT",  "BUOY",  "BURG",  "BURL",  "BURN",
+"BURR",  "BURT",  "BURY", "BUSH",  "BUSS",  "BUST",  "BUSY",  "BYTE",
+"CADY",  "CAFE",  "CAGE", "CAIN",  "CAKE",  "CALF",  "CALL",  "CALM",
+"CAME",  "CANE",  "CANT", "CARD",  "CARE",  "CARL",  "CARR",  "CART",
+"CASE",  "CASH",  "CASK", "CAST",  "CAVE",  "CEIL",  "CELL",  "CENT",
+"CERN",  "CHAD",  "CHAR", "CHAT",  "CHAW",  "CHEF",  "CHEN",  "CHEW",
+
+
+
+Haller & Metz               Standards Track                    [Page 14]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+"CHIC",  "CHIN",  "CHOU", "CHOW",  "CHUB",  "CHUG",  "CHUM",  "CITE",
+"CITY",  "CLAD",  "CLAM", "CLAN",  "CLAW",  "CLAY",  "CLOD",  "CLOG",
+"CLOT",  "CLUB",  "CLUE", "COAL",  "COAT",  "COCA",  "COCK",  "COCO",
+"CODA",  "CODE",  "CODY", "COED",  "COIL",  "COIN",  "COKE",  "COLA",
+"COLD",  "COLT",  "COMA", "COMB",  "COME",  "COOK",  "COOL",  "COON",
+"COOT",  "CORD",  "CORE", "CORK",  "CORN",  "COST",  "COVE",  "COWL",
+"CRAB",  "CRAG",  "CRAM", "CRAY",  "CREW",  "CRIB",  "CROW",  "CRUD",
+"CUBA",  "CUBE",  "CUFF", "CULL",  "CULT",  "CUNY",  "CURB",  "CURD",
+"CURE",  "CURL",  "CURT", "CUTS",  "DADE",  "DALE",  "DAME",  "DANA",
+"DANE",  "DANG",  "DANK", "DARE",  "DARK",  "DARN",  "DART",  "DASH",
+"DATA",  "DATE",  "DAVE", "DAVY",  "DAWN",  "DAYS",  "DEAD",  "DEAF",
+"DEAL",  "DEAN",  "DEAR", "DEBT",  "DECK",  "DEED",  "DEEM",  "DEER",
+"DEFT",  "DEFY",  "DELL", "DENT",  "DENY",  "DESK",  "DIAL",  "DICE",
+"DIED",  "DIET",  "DIME", "DINE",  "DING",  "DINT",  "DIRE",  "DIRT",
+"DISC",  "DISH",  "DISK", "DIVE",  "DOCK",  "DOES",  "DOLE",  "DOLL",
+"DOLT",  "DOME",  "DONE", "DOOM",  "DOOR",  "DORA",  "DOSE",  "DOTE",
+"DOUG",  "DOUR",  "DOVE", "DOWN",  "DRAB",  "DRAG",  "DRAM",  "DRAW",
+"DREW",  "DRUB",  "DRUG", "DRUM",  "DUAL",  "DUCK",  "DUCT",  "DUEL",
+"DUET",  "DUKE",  "DULL", "DUMB",  "DUNE",  "DUNK",  "DUSK",  "DUST",
+"DUTY",  "EACH",  "EARL", "EARN",  "EASE",  "EAST",  "EASY",  "EBEN",
+"ECHO",  "EDDY",  "EDEN", "EDGE",  "EDGY",  "EDIT",  "EDNA",  "EGAN",
+"ELAN",  "ELBA",  "ELLA", "ELSE",  "EMIL",  "EMIT",  "EMMA",  "ENDS",
+"ERIC",  "EROS",  "EVEN", "EVER",  "EVIL",  "EYED",  "FACE",  "FACT",
+"FADE",  "FAIL",  "FAIN", "FAIR",  "FAKE",  "FALL",  "FAME",  "FANG",
+"FARM",  "FAST",  "FATE", "FAWN",  "FEAR",  "FEAT",  "FEED",  "FEEL",
+"FEET",  "FELL",  "FELT", "FEND",  "FERN",  "FEST",  "FEUD",  "FIEF",
+"FIGS",  "FILE",  "FILL", "FILM",  "FIND",  "FINE",  "FINK",  "FIRE",
+"FIRM",  "FISH",  "FISK", "FIST",  "FITS",  "FIVE",  "FLAG",  "FLAK",
+"FLAM",  "FLAT",  "FLAW", "FLEA",  "FLED",  "FLEW",  "FLIT",  "FLOC",
+"FLOG",  "FLOW",  "FLUB", "FLUE",  "FOAL",  "FOAM",  "FOGY",  "FOIL",
+"FOLD",  "FOLK",  "FOND", "FONT",  "FOOD",  "FOOL",  "FOOT",  "FORD",
+"FORE",  "FORK",  "FORM", "FORT",  "FOSS",  "FOUL",  "FOUR",  "FOWL",
+"FRAU",  "FRAY",  "FRED", "FREE",  "FRET",  "FREY",  "FROG",  "FROM",
+"FUEL",  "FULL",  "FUME", "FUND",  "FUNK",  "FURY",  "FUSE",  "FUSS",
+"GAFF",  "GAGE",  "GAIL", "GAIN",  "GAIT",  "GALA",  "GALE",  "GALL",
+"GALT",  "GAME",  "GANG", "GARB",  "GARY",  "GASH",  "GATE",  "GAUL",
+"GAUR",  "GAVE",  "GAWK", "GEAR",  "GELD",  "GENE",  "GENT",  "GERM",
+"GETS",  "GIBE",  "GIFT", "GILD",  "GILL",  "GILT",  "GINA",  "GIRD",
+"GIRL",  "GIST",  "GIVE", "GLAD",  "GLEE",  "GLEN",  "GLIB",  "GLOB",
+"GLOM",  "GLOW",  "GLUE", "GLUM",  "GLUT",  "GOAD",  "GOAL",  "GOAT",
+"GOER",  "GOES",  "GOLD", "GOLF",  "GONE",  "GONG",  "GOOD",  "GOOF",
+"GORE",  "GORY",  "GOSH", "GOUT",  "GOWN",  "GRAB",  "GRAD",  "GRAY",
+"GREG",  "GREW",  "GREY", "GRID",  "GRIM",  "GRIN",  "GRIT",  "GROW",
+"GRUB",  "GULF",  "GULL", "GUNK",  "GURU",  "GUSH",  "GUST",  "GWEN",
+"GWYN",  "HAAG",  "HAAS", "HACK",  "HAIL",  "HAIR",  "HALE",  "HALF",
+"HALL",  "HALO",  "HALT", "HAND",  "HANG",  "HANK",  "HANS",  "HARD",
+"HARK",  "HARM",  "HART", "HASH",  "HAST",  "HATE",  "HATH",  "HAUL",
+"HAVE",  "HAWK",  "HAYS", "HEAD",  "HEAL",  "HEAR",  "HEAT",  "HEBE",
+
+
+
+Haller & Metz               Standards Track                    [Page 15]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+"HECK",  "HEED",  "HEEL", "HEFT",  "HELD",  "HELL",  "HELM",  "HERB",
+"HERD",  "HERE",  "HERO", "HERS",  "HESS",  "HEWN",  "HICK",  "HIDE",
+"HIGH",  "HIKE",  "HILL", "HILT",  "HIND",  "HINT",  "HIRE",  "HISS",
+"HIVE",  "HOBO",  "HOCK", "HOFF",  "HOLD",  "HOLE",  "HOLM",  "HOLT",
+"HOME",  "HONE",  "HONK", "HOOD",  "HOOF",  "HOOK",  "HOOT",  "HORN",
+"HOSE",  "HOST",  "HOUR", "HOVE",  "HOWE",  "HOWL",  "HOYT",  "HUCK",
+"HUED",  "HUFF",  "HUGE", "HUGH",  "HUGO",  "HULK",  "HULL",  "HUNK",
+"HUNT",  "HURD",  "HURL", "HURT",  "HUSH",  "HYDE",  "HYMN",  "IBIS",
+"ICON",  "IDEA",  "IDLE", "IFFY",  "INCA",  "INCH",  "INTO",  "IONS",
+"IOTA",  "IOWA",  "IRIS", "IRMA",  "IRON",  "ISLE",  "ITCH",  "ITEM",
+"IVAN",  "JACK",  "JADE", "JAIL",  "JAKE",  "JANE",  "JAVA",  "JEAN",
+"JEFF",  "JERK",  "JESS", "JEST",  "JIBE",  "JILL",  "JILT",  "JIVE",
+"JOAN",  "JOBS",  "JOCK", "JOEL",  "JOEY",  "JOHN",  "JOIN",  "JOKE",
+"JOLT",  "JOVE",  "JUDD", "JUDE",  "JUDO",  "JUDY",  "JUJU",  "JUKE",
+"JULY",  "JUNE",  "JUNK", "JUNO",  "JURY",  "JUST",  "JUTE",  "KAHN",
+"KALE",  "KANE",  "KANT", "KARL",  "KATE",  "KEEL",  "KEEN",  "KENO",
+"KENT",  "KERN",  "KERR", "KEYS",  "KICK",  "KILL",  "KIND",  "KING",
+"KIRK",  "KISS",  "KITE", "KLAN",  "KNEE",  "KNEW",  "KNIT",  "KNOB",
+"KNOT",  "KNOW",  "KOCH", "KONG",  "KUDO",  "KURD",  "KURT",  "KYLE",
+"LACE",  "LACK",  "LACY", "LADY",  "LAID",  "LAIN",  "LAIR",  "LAKE",
+"LAMB",  "LAME",  "LAND", "LANE",  "LANG",  "LARD",  "LARK",  "LASS",
+"LAST",  "LATE",  "LAUD", "LAVA",  "LAWN",  "LAWS",  "LAYS",  "LEAD",
+"LEAF",  "LEAK",  "LEAN", "LEAR",  "LEEK",  "LEER",  "LEFT",  "LEND",
+"LENS",  "LENT",  "LEON", "LESK",  "LESS",  "LEST",  "LETS",  "LIAR",
+"LICE",  "LICK",  "LIED", "LIEN",  "LIES",  "LIEU",  "LIFE",  "LIFT",
+"LIKE",  "LILA",  "LILT", "LILY",  "LIMA",  "LIMB",  "LIME",  "LIND",
+"LINE",  "LINK",  "LINT", "LION",  "LISA",  "LIST",  "LIVE",  "LOAD",
+"LOAF",  "LOAM",  "LOAN", "LOCK",  "LOFT",  "LOGE",  "LOIS",  "LOLA",
+"LONE",  "LONG",  "LOOK", "LOON",  "LOOT",  "LORD",  "LORE",  "LOSE",
+"LOSS",  "LOST",  "LOUD", "LOVE",  "LOWE",  "LUCK",  "LUCY",  "LUGE",
+"LUKE",  "LULU",  "LUND", "LUNG",  "LURA",  "LURE",  "LURK",  "LUSH",
+"LUST",  "LYLE",  "LYNN", "LYON",  "LYRA",  "MACE",  "MADE",  "MAGI",
+"MAID",  "MAIL",  "MAIN", "MAKE",  "MALE",  "MALI",  "MALL",  "MALT",
+"MANA",  "MANN",  "MANY", "MARC",  "MARE",  "MARK",  "MARS",  "MART",
+"MARY",  "MASH",  "MASK", "MASS",  "MAST",  "MATE",  "MATH",  "MAUL",
+"MAYO",  "MEAD",  "MEAL", "MEAN",  "MEAT",  "MEEK",  "MEET",  "MELD",
+"MELT",  "MEMO",  "MEND", "MENU",  "MERT",  "MESH",  "MESS",  "MICE",
+"MIKE",  "MILD",  "MILE", "MILK",  "MILL",  "MILT",  "MIMI",  "MIND",
+"MINE",  "MINI",  "MINK", "MINT",  "MIRE",  "MISS",  "MIST",  "MITE",
+"MITT",  "MOAN",  "MOAT", "MOCK",  "MODE",  "MOLD",  "MOLE",  "MOLL",
+"MOLT",  "MONA",  "MONK", "MONT",  "MOOD",  "MOON",  "MOOR",  "MOOT",
+"MORE",  "MORN",  "MORT", "MOSS",  "MOST",  "MOTH",  "MOVE",  "MUCH",
+"MUCK",  "MUDD",  "MUFF", "MULE",  "MULL",  "MURK",  "MUSH",  "MUST",
+"MUTE",  "MUTT",  "MYRA", "MYTH",  "NAGY",  "NAIL",  "NAIR",  "NAME",
+"NARY",  "NASH",  "NAVE", "NAVY",  "NEAL",  "NEAR",  "NEAT",  "NECK",
+"NEED",  "NEIL",  "NELL", "NEON",  "NERO",  "NESS",  "NEST",  "NEWS",
+"NEWT",  "NIBS",  "NICE", "NICK",  "NILE",  "NINA",  "NINE",  "NOAH",
+"NODE",  "NOEL",  "NOLL", "NONE",  "NOOK",  "NOON",  "NORM",  "NOSE",
+
+
+
+Haller & Metz               Standards Track                    [Page 16]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+"NOTE",  "NOUN",  "NOVA", "NUDE",  "NULL",  "NUMB",  "OATH",  "OBEY",
+"OBOE",  "ODIN",  "OHIO", "OILY",  "OINT",  "OKAY",  "OLAF",  "OLDY",
+"OLGA",  "OLIN",  "OMAN", "OMEN",  "OMIT",  "ONCE",  "ONES",  "ONLY",
+"ONTO",  "ONUS",  "ORAL", "ORGY",  "OSLO",  "OTIS",  "OTTO",  "OUCH",
+"OUST",  "OUTS",  "OVAL", "OVEN",  "OVER",  "OWLY",  "OWNS",  "QUAD",
+"QUIT",  "QUOD",  "RACE", "RACK",  "RACY",  "RAFT",  "RAGE",  "RAID",
+"RAIL",  "RAIN",  "RAKE", "RANK",  "RANT",  "RARE",  "RASH",  "RATE",
+"RAVE",  "RAYS",  "READ", "REAL",  "REAM",  "REAR",  "RECK",  "REED",
+"REEF",  "REEK",  "REEL", "REID",  "REIN",  "RENA",  "REND",  "RENT",
+"REST",  "RICE",  "RICH", "RICK",  "RIDE",  "RIFT",  "RILL",  "RIME",
+"RING",  "RINK",  "RISE", "RISK",  "RITE",  "ROAD",  "ROAM",  "ROAR",
+"ROBE",  "ROCK",  "RODE", "ROIL",  "ROLL",  "ROME",  "ROOD",  "ROOF",
+"ROOK",  "ROOM",  "ROOT", "ROSA",  "ROSE",  "ROSS",  "ROSY",  "ROTH",
+"ROUT",  "ROVE",  "ROWE", "ROWS",  "RUBE",  "RUBY",  "RUDE",  "RUDY",
+"RUIN",  "RULE",  "RUNG", "RUNS",  "RUNT",  "RUSE",  "RUSH",  "RUSK",
+"RUSS",  "RUST",  "RUTH", "SACK",  "SAFE",  "SAGE",  "SAID",  "SAIL",
+"SALE",  "SALK",  "SALT", "SAME",  "SAND",  "SANE",  "SANG",  "SANK",
+"SARA",  "SAUL",  "SAVE", "SAYS",  "SCAN",  "SCAR",  "SCAT",  "SCOT",
+"SEAL",  "SEAM",  "SEAR", "SEAT",  "SEED",  "SEEK",  "SEEM",  "SEEN",
+"SEES",  "SELF",  "SELL", "SEND",  "SENT",  "SETS",  "SEWN",  "SHAG",
+"SHAM",  "SHAW",  "SHAY", "SHED",  "SHIM",  "SHIN",  "SHOD",  "SHOE",
+"SHOT",  "SHOW",  "SHUN", "SHUT",  "SICK",  "SIDE",  "SIFT",  "SIGH",
+"SIGN",  "SILK",  "SILL", "SILO",  "SILT",  "SINE",  "SING",  "SINK",
+"SIRE",  "SITE",  "SITS", "SITU",  "SKAT",  "SKEW",  "SKID",  "SKIM",
+"SKIN",  "SKIT",  "SLAB", "SLAM",  "SLAT",  "SLAY",  "SLED",  "SLEW",
+"SLID",  "SLIM",  "SLIT", "SLOB",  "SLOG",  "SLOT",  "SLOW",  "SLUG",
+"SLUM",  "SLUR",  "SMOG", "SMUG",  "SNAG",  "SNOB",  "SNOW",  "SNUB",
+"SNUG",  "SOAK",  "SOAR", "SOCK",  "SODA",  "SOFA",  "SOFT",  "SOIL",
+"SOLD",  "SOME",  "SONG", "SOON",  "SOOT",  "SORE",  "SORT",  "SOUL",
+"SOUR",  "SOWN",  "STAB", "STAG",  "STAN",  "STAR",  "STAY",  "STEM",
+"STEW",  "STIR",  "STOW", "STUB",  "STUN",  "SUCH",  "SUDS",  "SUIT",
+"SULK",  "SUMS",  "SUNG", "SUNK",  "SURE",  "SURF",  "SWAB",  "SWAG",
+"SWAM",  "SWAN",  "SWAT", "SWAY",  "SWIM",  "SWUM",  "TACK",  "TACT",
+"TAIL",  "TAKE",  "TALE", "TALK",  "TALL",  "TANK",  "TASK",  "TATE",
+"TAUT",  "TEAL",  "TEAM", "TEAR",  "TECH",  "TEEM",  "TEEN",  "TEET",
+"TELL",  "TEND",  "TENT", "TERM",  "TERN",  "TESS",  "TEST",  "THAN",
+"THAT",  "THEE",  "THEM", "THEN",  "THEY",  "THIN",  "THIS",  "THUD",
+"THUG",  "TICK",  "TIDE", "TIDY",  "TIED",  "TIER",  "TILE",  "TILL",
+"TILT",  "TIME",  "TINA", "TINE",  "TINT",  "TINY",  "TIRE",  "TOAD",
+"TOGO",  "TOIL",  "TOLD", "TOLL",  "TONE",  "TONG",  "TONY",  "TOOK",
+"TOOL",  "TOOT",  "TORE", "TORN",  "TOTE",  "TOUR",  "TOUT",  "TOWN",
+"TRAG",  "TRAM",  "TRAY", "TREE",  "TREK",  "TRIG",  "TRIM",  "TRIO",
+"TROD",  "TROT",  "TROY", "TRUE",  "TUBA",  "TUBE",  "TUCK",  "TUFT",
+"TUNA",  "TUNE",  "TUNG", "TURF",  "TURN",  "TUSK",  "TWIG",  "TWIN",
+"TWIT",  "ULAN",  "UNIT", "URGE",  "USED",  "USER",  "USES",  "UTAH",
+"VAIL",  "VAIN",  "VALE", "VARY",  "VASE",  "VAST",  "VEAL",  "VEDA",
+"VEIL",  "VEIN",  "VEND", "VENT",  "VERB",  "VERY",  "VETO",  "VICE",
+"VIEW",  "VINE",  "VISE", "VOID",  "VOLT",  "VOTE",  "WACK",  "WADE",
+
+
+
+Haller & Metz               Standards Track                    [Page 17]
+
+RFC 1938               A One-Time Password System               May 1996
+
+
+"WAGE",  "WAIL",  "WAIT", "WAKE",  "WALE",  "WALK",  "WALL",  "WALT",
+"WAND",  "WANE",  "WANG", "WANT",  "WARD",  "WARM",  "WARN",  "WART",
+"WASH",  "WAST",  "WATS", "WATT",  "WAVE",  "WAVY",  "WAYS",  "WEAK",
+"WEAL",  "WEAN",  "WEAR", "WEED",  "WEEK",  "WEIR",  "WELD",  "WELL",
+"WELT",  "WENT",  "WERE", "WERT",  "WEST",  "WHAM",  "WHAT",  "WHEE",
+"WHEN",  "WHET",  "WHOA", "WHOM",  "WICK",  "WIFE",  "WILD",  "WILL",
+"WIND",  "WINE",  "WING", "WINK",  "WINO",  "WIRE",  "WISE",  "WISH",
+"WITH",  "WOLF",  "WONT", "WOOD",  "WOOL",  "WORD",  "WORE",  "WORK",
+"WORM",  "WORN",  "WOVE", "WRIT",  "WYNN",  "YALE",  "YANG",  "YANK",
+"YARD",  "YARN",  "YAWL", "YAWN",  "YEAH",  "YEAR",  "YELL",  "YOGA",
+"YOKE"                         };
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haller & Metz               Standards Track                    [Page 18]
+
diff --git a/RFC/rfc1939.txt b/RFC/rfc1939.txt
new file mode 100644
index 00000000..b11350e9
--- /dev/null
+++ b/RFC/rfc1939.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 1939                               Carnegie Mellon
+STD: 53                                                          M. Rose
+Obsoletes: 1725                             Dover Beach Consulting, Inc.
+Category: Standards Track                                       May 1996
+
+
+                    Post Office Protocol - Version 3
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ................................................    2
+   2. A Short Digression ..........................................    2
+   3. Basic Operation .............................................    3
+   4. The AUTHORIZATION State .....................................    4
+      QUIT Command ................................................    5
+   5. The TRANSACTION State .......................................    5
+      STAT Command ................................................    6
+      LIST Command ................................................    6
+      RETR Command ................................................    8
+      DELE Command ................................................    8
+      NOOP Command ................................................    9
+      RSET Command ................................................    9
+   6. The UPDATE State ............................................   10
+      QUIT Command ................................................   10
+   7. Optional POP3 Commands ......................................   11
+      TOP Command .................................................   11
+      UIDL Command ................................................   12
+      USER Command ................................................   13
+      PASS Command ................................................   14
+      APOP Command ................................................   15
+   8. Scaling and Operational Considerations ......................   16
+   9. POP3 Command Summary ........................................   18
+   10. Example POP3 Session .......................................   19
+   11. Message Format .............................................   19
+   12. References .................................................   20
+   13. Security Considerations ....................................   20
+   14. Acknowledgements ...........................................   20
+   15. Authors' Addresses .........................................   21
+   Appendix A. Differences from RFC 1725 ..........................   22
+
+
+
+Myers & Rose                Standards Track                     [Page 1]
+
+RFC 1939                          POP3                          May 1996
+
+
+   Appendix B. Command Index ......................................   23
+
+1. Introduction
+
+   On certain types of smaller nodes in the Internet it is often
+   impractical to maintain a message transport system (MTS).  For
+   example, a workstation may not have sufficient resources (cycles,
+   disk space) in order to permit a SMTP server [RFC821] and associated
+   local mail delivery system to be kept resident and continuously
+   running.  Similarly, it may be expensive (or impossible) to keep a
+   personal computer interconnected to an IP-style network for long
+   amounts of time (the node is lacking the resource known as
+   "connectivity").
+
+   Despite this, it is often very useful to be able to manage mail on
+   these smaller nodes, and they often support a user agent (UA) to aid
+   the tasks of mail handling.  To solve this problem, a node which can
+   support an MTS entity offers a maildrop service to these less endowed
+   nodes.  The Post Office Protocol - Version 3 (POP3) is intended to
+   permit a workstation to dynamically access a maildrop on a server
+   host in a useful fashion.  Usually, this means that the POP3 protocol
+   is used to allow a workstation to retrieve mail that the server is
+   holding for it.
+
+   POP3 is not intended to provide extensive manipulation operations of
+   mail on the server; normally, mail is downloaded and then deleted.  A
+   more advanced (and complex) protocol, IMAP4, is discussed in
+   [RFC1730].
+
+   For the remainder of this memo, the term "client host" refers to a
+   host making use of the POP3 service, while the term "server host"
+   refers to a host which offers the POP3 service.
+
+2. A Short Digression
+
+   This memo does not specify how a client host enters mail into the
+   transport system, although a method consistent with the philosophy of
+   this memo is presented here:
+
+      When the user agent on a client host wishes to enter a message
+      into the transport system, it establishes an SMTP connection to
+      its relay host and sends all mail to it.  This relay host could
+      be, but need not be, the POP3 server host for the client host.  Of
+      course, the relay host must accept mail for delivery to arbitrary
+      recipient addresses, that functionality is not required of all
+      SMTP servers.
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 2]
+
+RFC 1939                          POP3                          May 1996
+
+
+3. Basic Operation
+
+   Initially, the server host starts the POP3 service by listening on
+   TCP port 110.  When a client host wishes to make use of the service,
+   it establishes a TCP connection with the server host.  When the
+   connection is established, the POP3 server sends a greeting.  The
+   client and POP3 server then exchange commands and responses
+   (respectively) until the connection is closed or aborted.
+
+   Commands in the POP3 consist of a case-insensitive keyword, possibly
+   followed by one or more arguments.  All commands are terminated by a
+   CRLF pair.  Keywords and arguments consist of printable ASCII
+   characters.  Keywords and arguments are each separated by a single
+   SPACE character.  Keywords are three or four characters long. Each
+   argument may be up to 40 characters long.
+
+   Responses in the POP3 consist of a status indicator and a keyword
+   possibly followed by additional information.  All responses are
+   terminated by a CRLF pair.  Responses may be up to 512 characters
+   long, including the terminating CRLF.  There are currently two status
+   indicators: positive ("+OK") and negative ("-ERR").  Servers MUST
+   send the "+OK" and "-ERR" in upper case.
+
+   Responses to certain commands are multi-line.  In these cases, which
+   are clearly indicated below, after sending the first line of the
+   response and a CRLF, any additional lines are sent, each terminated
+   by a CRLF pair.  When all lines of the response have been sent, a
+   final line is sent, consisting of a termination octet (decimal code
+   046, ".") and a CRLF pair.  If any line of the multi-line response
+   begins with the termination octet, the line is "byte-stuffed" by
+   pre-pending the termination octet to that line of the response.
+   Hence a multi-line response is terminated with the five octets
+   "CRLF.CRLF".  When examining a multi-line response, the client checks
+   to see if the line begins with the termination octet.  If so and if
+   octets other than CRLF follow, the first octet of the line (the
+   termination octet) is stripped away.  If so and if CRLF immediately
+   follows the termination character, then the response from the POP
+   server is ended and the line containing ".CRLF" is not considered
+   part of the multi-line response.
+
+   A POP3 session progresses through a number of states during its
+   lifetime.  Once the TCP connection has been opened and the POP3
+   server has sent the greeting, the session enters the AUTHORIZATION
+   state.  In this state, the client must identify itself to the POP3
+   server.  Once the client has successfully done this, the server
+   acquires resources associated with the client's maildrop, and the
+   session enters the TRANSACTION state.  In this state, the client
+   requests actions on the part of the POP3 server.  When the client has
+
+
+
+Myers & Rose                Standards Track                     [Page 3]
+
+RFC 1939                          POP3                          May 1996
+
+
+   issued the QUIT command, the session enters the UPDATE state.  In
+   this state, the POP3 server releases any resources acquired during
+   the TRANSACTION state and says goodbye.  The TCP connection is then
+   closed.
+
+   A server MUST respond to an unrecognized, unimplemented, or
+   syntactically invalid command by responding with a negative status
+   indicator.  A server MUST respond to a command issued when the
+   session is in an incorrect state by responding with a negative status
+   indicator.  There is no general method for a client to distinguish
+   between a server which does not implement an optional command and a
+   server which is unwilling or unable to process the command.
+
+   A POP3 server MAY have an inactivity autologout timer.  Such a timer
+   MUST be of at least 10 minutes' duration.  The receipt of any command
+   from the client during that interval should suffice to reset the
+   autologout timer.  When the timer expires, the session does NOT enter
+   the UPDATE state--the server should close the TCP connection without
+   removing any messages or sending any response to the client.
+
+4. The AUTHORIZATION State
+
+   Once the TCP connection has been opened by a POP3 client, the POP3
+   server issues a one line greeting.  This can be any positive
+   response.  An example might be:
+
+      S:  +OK POP3 server ready
+
+   The POP3 session is now in the AUTHORIZATION state.  The client must
+   now identify and authenticate itself to the POP3 server.  Two
+   possible mechanisms for doing this are described in this document,
+   the USER and PASS command combination and the APOP command.  Both
+   mechanisms are described later in this document.  Additional
+   authentication mechanisms are described in [RFC1734].  While there is
+   no single authentication mechanism that is required of all POP3
+   servers, a POP3 server must of course support at least one
+   authentication mechanism.
+
+   Once the POP3 server has determined through the use of any
+   authentication command that the client should be given access to the
+   appropriate maildrop, the POP3 server then acquires an exclusive-
+   access lock on the maildrop, as necessary to prevent messages from
+   being modified or removed before the session enters the UPDATE state.
+   If the lock is successfully acquired, the POP3 server responds with a
+   positive status indicator.  The POP3 session now enters the
+   TRANSACTION state, with no messages marked as deleted.  If the
+   maildrop cannot be opened for some reason (for example, a lock can
+   not be acquired, the client is denied access to the appropriate
+
+
+
+Myers & Rose                Standards Track                     [Page 4]
+
+RFC 1939                          POP3                          May 1996
+
+
+   maildrop, or the maildrop cannot be parsed), the POP3 server responds
+   with a negative status indicator.  (If a lock was acquired but the
+   POP3 server intends to respond with a negative status indicator, the
+   POP3 server must release the lock prior to rejecting the command.)
+   After returning a negative status indicator, the server may close the
+   connection.  If the server does not close the connection, the client
+   may either issue a new authentication command and start again, or the
+   client may issue the QUIT command.
+
+   After the POP3 server has opened the maildrop, it assigns a message-
+   number to each message, and notes the size of each message in octets.
+   The first message in the maildrop is assigned a message-number of
+   "1", the second is assigned "2", and so on, so that the nth message
+   in a maildrop is assigned a message-number of "n".  In POP3 commands
+   and responses, all message-numbers and message sizes are expressed in
+   base-10 (i.e., decimal).
+
+   Here is the summary for the QUIT command when used in the
+   AUTHORIZATION state:
+
+      QUIT
+
+         Arguments: none
+
+         Restrictions: none
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: QUIT
+             S: +OK dewey POP3 server signing off
+
+5. The TRANSACTION State
+
+   Once the client has successfully identified itself to the POP3 server
+   and the POP3 server has locked and opened the appropriate maildrop,
+   the POP3 session is now in the TRANSACTION state.  The client may now
+   issue any of the following POP3 commands repeatedly.  After each
+   command, the POP3 server issues a response.  Eventually, the client
+   issues the QUIT command and the POP3 session enters the UPDATE state.
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 5]
+
+RFC 1939                          POP3                          May 1996
+
+
+   Here are the POP3 commands valid in the TRANSACTION state:
+
+      STAT
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             The POP3 server issues a positive response with a line
+             containing information for the maildrop.  This line is
+             called a "drop listing" for that maildrop.
+
+             In order to simplify parsing, all POP3 servers are
+             required to use a certain format for drop listings.  The
+             positive response consists of "+OK" followed by a single
+             space, the number of messages in the maildrop, a single
+             space, and the size of the maildrop in octets.  This memo
+             makes no requirement on what follows the maildrop size.
+             Minimal implementations should just end that line of the
+             response with a CRLF pair.  More advanced implementations
+             may include other information.
+
+                NOTE: This memo STRONGLY discourages implementations
+                from supplying additional information in the drop
+                listing.  Other, optional, facilities are discussed
+                later on which permit the client to parse the messages
+                in the maildrop.
+
+             Note that messages marked as deleted are not counted in
+             either total.
+
+         Possible Responses:
+             +OK nn mm
+
+         Examples:
+             C: STAT
+             S: +OK 2 320
+
+
+      LIST [msg]
+
+         Arguments:
+             a message-number (optional), which, if present, may NOT
+             refer to a message marked as deleted
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 6]
+
+RFC 1939                          POP3                          May 1996
+
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If an argument was given and the POP3 server issues a
+             positive response with a line containing information for
+             that message.  This line is called a "scan listing" for
+             that message.
+
+             If no argument was given and the POP3 server issues a
+             positive response, then the response given is multi-line.
+             After the initial +OK, for each message in the maildrop,
+             the POP3 server responds with a line containing
+             information for that message.  This line is also called a
+             "scan listing" for that message.  If there are no
+             messages in the maildrop, then the POP3 server responds
+             with no scan listings--it issues a positive response
+             followed by a line containing a termination octet and a
+             CRLF pair.
+
+             In order to simplify parsing, all POP3 servers are
+             required to use a certain format for scan listings.  A
+             scan listing consists of the message-number of the
+             message, followed by a single space and the exact size of
+             the message in octets.  Methods for calculating the exact
+             size of the message are described in the "Message Format"
+             section below.  This memo makes no requirement on what
+             follows the message size in the scan listing.  Minimal
+             implementations should just end that line of the response
+             with a CRLF pair.  More advanced implementations may
+             include other information, as parsed from the message.
+
+                NOTE: This memo STRONGLY discourages implementations
+                from supplying additional information in the scan
+                listing.  Other, optional, facilities are discussed
+                later on which permit the client to parse the messages
+                in the maildrop.
+
+             Note that messages marked as deleted are not listed.
+
+         Possible Responses:
+             +OK scan listing follows
+             -ERR no such message
+
+         Examples:
+             C: LIST
+             S: +OK 2 messages (320 octets)
+             S: 1 120
+
+
+
+Myers & Rose                Standards Track                     [Page 7]
+
+RFC 1939                          POP3                          May 1996
+
+
+             S: 2 200
+             S: .
+               ...
+             C: LIST 2
+             S: +OK 2 200
+               ...
+             C: LIST 3
+             S: -ERR no such message, only 2 messages in maildrop
+
+
+      RETR msg
+
+         Arguments:
+             a message-number (required) which may NOT refer to a
+             message marked as deleted
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If the POP3 server issues a positive response, then the
+             response given is multi-line.  After the initial +OK, the
+             POP3 server sends the message corresponding to the given
+             message-number, being careful to byte-stuff the termination
+             character (as with all multi-line responses).
+
+         Possible Responses:
+             +OK message follows
+             -ERR no such message
+
+         Examples:
+             C: RETR 1
+             S: +OK 120 octets
+             S: <the POP3 server sends the entire message here>
+             S: .
+
+
+      DELE msg
+
+         Arguments:
+             a message-number (required) which may NOT refer to a
+             message marked as deleted
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+
+
+
+
+
+Myers & Rose                Standards Track                     [Page 8]
+
+RFC 1939                          POP3                          May 1996
+
+
+         Discussion:
+             The POP3 server marks the message as deleted.  Any future
+             reference to the message-number associated with the message
+             in a POP3 command generates an error.  The POP3 server does
+             not actually delete the message until the POP3 session
+             enters the UPDATE state.
+
+         Possible Responses:
+             +OK message deleted
+             -ERR no such message
+
+         Examples:
+             C: DELE 1
+             S: +OK message 1 deleted
+                ...
+             C: DELE 2
+             S: -ERR message 2 already deleted
+
+
+      NOOP
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             The POP3 server does nothing, it merely replies with a
+             positive response.
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: NOOP
+             S: +OK
+
+
+      RSET
+
+         Arguments: none
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If any messages have been marked as deleted by the POP3
+             server, they are unmarked.  The POP3 server then replies
+
+
+
+Myers & Rose                Standards Track                     [Page 9]
+
+RFC 1939                          POP3                          May 1996
+
+
+             with a positive response.
+
+         Possible Responses:
+             +OK
+
+         Examples:
+             C: RSET
+             S: +OK maildrop has 2 messages (320 octets)
+
+6. The UPDATE State
+
+   When the client issues the QUIT command from the TRANSACTION state,
+   the POP3 session enters the UPDATE state.  (Note that if the client
+   issues the QUIT command from the AUTHORIZATION state, the POP3
+   session terminates but does NOT enter the UPDATE state.)
+
+   If a session terminates for some reason other than a client-issued
+   QUIT command, the POP3 session does NOT enter the UPDATE state and
+   MUST not remove any messages from the maildrop.
+
+      QUIT
+
+         Arguments: none
+
+         Restrictions: none
+
+         Discussion:
+             The POP3 server removes all messages marked as deleted
+             from the maildrop and replies as to the status of this
+             operation.  If there is an error, such as a resource
+             shortage, encountered while removing messages, the
+             maildrop may result in having some or none of the messages
+             marked as deleted be removed.  In no case may the server
+             remove any messages not marked as deleted.
+
+             Whether the removal was successful or not, the server
+             then releases any exclusive-access lock on the maildrop
+             and closes the TCP connection.
+
+         Possible Responses:
+             +OK
+             -ERR some deleted messages not removed
+
+         Examples:
+             C: QUIT
+             S: +OK dewey POP3 server signing off (maildrop empty)
+                ...
+             C: QUIT
+
+
+
+Myers & Rose                Standards Track                    [Page 10]
+
+RFC 1939                          POP3                          May 1996
+
+
+             S: +OK dewey POP3 server signing off (2 messages left)
+                ...
+
+7. Optional POP3 Commands
+
+   The POP3 commands discussed above must be supported by all minimal
+   implementations of POP3 servers.
+
+   The optional POP3 commands described below permit a POP3 client
+   greater freedom in message handling, while preserving a simple POP3
+   server implementation.
+
+      NOTE: This memo STRONGLY encourages implementations to support
+      these commands in lieu of developing augmented drop and scan
+      listings.  In short, the philosophy of this memo is to put
+      intelligence in the part of the POP3 client and not the POP3
+      server.
+
+      TOP msg n
+
+         Arguments:
+             a message-number (required) which may NOT refer to to a
+             message marked as deleted, and a non-negative number
+             of lines (required)
+
+         Restrictions:
+             may only be given in the TRANSACTION state
+
+         Discussion:
+             If the POP3 server issues a positive response, then the
+             response given is multi-line.  After the initial +OK, the
+             POP3 server sends the headers of the message, the blank
+             line separating the headers from the body, and then the
+             number of lines of the indicated message's body, being
+             careful to byte-stuff the termination character (as with
+             all multi-line responses).
+
+             Note that if the number of lines requested by the POP3
+             client is greater than than the number of lines in the
+             body, then the POP3 server sends the entire message.
+
+         Possible Responses:
+             +OK top of message follows
+             -ERR no such message
+
+         Examples:
+             C: TOP 1 10
+             S: +OK
+
+
+
+Myers & Rose                Standards Track                    [Page 11]
+
+RFC 1939                          POP3                          May 1996
+
+
+             S: <the POP3 server sends the headers of the
+                message, a blank line, and the first 10 lines
+                of the body of the message>
+             S: .
+                ...
+             C: TOP 100 3
+             S: -ERR no such message
+
+
+      UIDL [msg]
+
+      Arguments:
+          a message-number (optional), which, if present, may NOT
+          refer to a message marked as deleted
+
+      Restrictions:
+          may only be given in the TRANSACTION state.
+
+      Discussion:
+          If an argument was given and the POP3 server issues a positive
+          response with a line containing information for that message.
+          This line is called a "unique-id listing" for that message.
+
+          If no argument was given and the POP3 server issues a positive
+          response, then the response given is multi-line.  After the
+          initial +OK, for each message in the maildrop, the POP3 server
+          responds with a line containing information for that message.
+          This line is called a "unique-id listing" for that message.
+
+          In order to simplify parsing, all POP3 servers are required to
+          use a certain format for unique-id listings.  A unique-id
+          listing consists of the message-number of the message,
+          followed by a single space and the unique-id of the message.
+          No information follows the unique-id in the unique-id listing.
+
+          The unique-id of a message is an arbitrary server-determined
+          string, consisting of one to 70 characters in the range 0x21
+          to 0x7E, which uniquely identifies a message within a
+          maildrop and which persists across sessions.  This
+          persistence is required even if a session ends without
+          entering the UPDATE state.  The server should never reuse an
+          unique-id in a given maildrop, for as long as the entity
+          using the unique-id exists.
+
+          Note that messages marked as deleted are not listed.
+
+          While it is generally preferable for server implementations
+          to store arbitrarily assigned unique-ids in the maildrop,
+
+
+
+Myers & Rose                Standards Track                    [Page 12]
+
+RFC 1939                          POP3                          May 1996
+
+
+          this specification is intended to permit unique-ids to be
+          calculated as a hash of the message.  Clients should be able
+          to handle a situation where two identical copies of a
+          message in a maildrop have the same unique-id.
+
+      Possible Responses:
+          +OK unique-id listing follows
+          -ERR no such message
+
+      Examples:
+          C: UIDL
+          S: +OK
+          S: 1 whqtswO00WBw418f9t5JxYwZ
+          S: 2 QhdPYR:00WBw1Ph7x7
+          S: .
+             ...
+          C: UIDL 2
+          S: +OK 2 QhdPYR:00WBw1Ph7x7
+             ...
+          C: UIDL 3
+          S: -ERR no such message, only 2 messages in maildrop
+
+
+      USER name
+
+         Arguments:
+             a string identifying a mailbox (required), which is of
+             significance ONLY to the server
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state after the POP3
+             greeting or after an unsuccessful USER or PASS command
+
+         Discussion:
+             To authenticate using the USER and PASS command
+             combination, the client must first issue the USER
+             command.  If the POP3 server responds with a positive
+             status indicator ("+OK"), then the client may issue
+             either the PASS command to complete the authentication,
+             or the QUIT command to terminate the POP3 session.  If
+             the POP3 server responds with a negative status indicator
+             ("-ERR") to the USER command, then the client may either
+             issue a new authentication command or may issue the QUIT
+             command.
+
+             The server may return a positive response even though no
+             such mailbox exists.  The server may return a negative
+             response if mailbox exists, but does not permit plaintext
+
+
+
+Myers & Rose                Standards Track                    [Page 13]
+
+RFC 1939                          POP3                          May 1996
+
+
+             password authentication.
+
+         Possible Responses:
+             +OK name is a valid mailbox
+             -ERR never heard of mailbox name
+
+         Examples:
+             C: USER frated
+             S: -ERR sorry, no mailbox for frated here
+                ...
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+
+
+      PASS string
+
+         Arguments:
+             a server/mailbox-specific password (required)
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state immediately
+             after a successful USER command
+
+         Discussion:
+             When the client issues the PASS command, the POP3 server
+             uses the argument pair from the USER and PASS commands to
+             determine if the client should be given access to the
+             appropriate maildrop.
+
+             Since the PASS command has exactly one argument, a POP3
+             server may treat spaces in the argument as part of the
+             password, instead of as argument separators.
+
+         Possible Responses:
+             +OK maildrop locked and ready
+             -ERR invalid password
+             -ERR unable to lock maildrop
+
+         Examples:
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+             C: PASS secret
+             S: -ERR maildrop already locked
+               ...
+             C: USER mrose
+             S: +OK mrose is a real hoopy frood
+             C: PASS secret
+             S: +OK mrose's maildrop has 2 messages (320 octets)
+
+
+
+Myers & Rose                Standards Track                    [Page 14]
+
+RFC 1939                          POP3                          May 1996
+
+
+      APOP name digest
+
+         Arguments:
+             a string identifying a mailbox and a MD5 digest string
+             (both required)
+
+         Restrictions:
+             may only be given in the AUTHORIZATION state after the POP3
+             greeting or after an unsuccessful USER or PASS command
+
+         Discussion:
+             Normally, each POP3 session starts with a USER/PASS
+             exchange.  This results in a server/user-id specific
+             password being sent in the clear on the network.  For
+             intermittent use of POP3, this may not introduce a sizable
+             risk.  However, many POP3 client implementations connect to
+             the POP3 server on a regular basis -- to check for new
+             mail.  Further the interval of session initiation may be on
+             the order of five minutes.  Hence, the risk of password
+             capture is greatly enhanced.
+
+             An alternate method of authentication is required which
+             provides for both origin authentication and replay
+             protection, but which does not involve sending a password
+             in the clear over the network.  The APOP command provides
+             this functionality.
+
+             A POP3 server which implements the APOP command will
+             include a timestamp in its banner greeting.  The syntax of
+             the timestamp corresponds to the `msg-id' in [RFC822], and
+             MUST be different each time the POP3 server issues a banner
+             greeting.  For example, on a UNIX implementation in which a
+             separate UNIX process is used for each instance of a POP3
+             server, the syntax of the timestamp might be:
+
+                <process-ID.clock@hostname>
+
+             where `process-ID' is the decimal value of the process's
+             PID, clock is the decimal value of the system clock, and
+             hostname is the fully-qualified domain-name corresponding
+             to the host where the POP3 server is running.
+
+             The POP3 client makes note of this timestamp, and then
+             issues the APOP command.  The `name' parameter has
+             identical semantics to the `name' parameter of the USER
+             command. The `digest' parameter is calculated by applying
+             the MD5 algorithm [RFC1321] to a string consisting of the
+             timestamp (including angle-brackets) followed by a shared
+
+
+
+Myers & Rose                Standards Track                    [Page 15]
+
+RFC 1939                          POP3                          May 1996
+
+
+             secret.  This shared secret is a string known only to the
+             POP3 client and server.  Great care should be taken to
+             prevent unauthorized disclosure of the secret, as knowledge
+             of the secret will allow any entity to successfully
+             masquerade as the named user.  The `digest' parameter
+             itself is a 16-octet value which is sent in hexadecimal
+             format, using lower-case ASCII characters.
+
+             When the POP3 server receives the APOP command, it verifies
+             the digest provided.  If the digest is correct, the POP3
+             server issues a positive response, and the POP3 session
+             enters the TRANSACTION state.  Otherwise, a negative
+             response is issued and the POP3 session remains in the
+             AUTHORIZATION state.
+
+             Note that as the length of the shared secret increases, so
+             does the difficulty of deriving it.  As such, shared
+             secrets should be long strings (considerably longer than
+             the 8-character example shown below).
+
+         Possible Responses:
+             +OK maildrop locked and ready
+             -ERR permission denied
+
+         Examples:
+             S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+             S: +OK maildrop has 1 message (369 octets)
+
+             In this example, the shared  secret  is  the  string  `tan-
+             staaf'.  Hence, the MD5 algorithm is applied to the string
+
+                <1896.697170952@dbc.mtview.ca.us>tanstaaf
+
+             which produces a digest value of
+
+                c4c9334bac560ecc979e58001b3e22fb
+
+8. Scaling and Operational Considerations
+
+   Since some of the optional features described above were added to the
+   POP3 protocol, experience has accumulated in using them in large-
+   scale commercial post office operations where most of the users are
+   unrelated to each other.  In these situations and others, users and
+   vendors of POP3 clients have discovered that the combination of using
+   the UIDL command and not issuing the DELE command can provide a weak
+   version of the "maildrop as semi-permanent repository" functionality
+   normally associated with IMAP.  Of course the other capabilities of
+
+
+
+Myers & Rose                Standards Track                    [Page 16]
+
+RFC 1939                          POP3                          May 1996
+
+
+   IMAP, such as polling an existing connection for newly arrived
+   messages and supporting multiple folders on the server, are not
+   present in POP3.
+
+   When these facilities are used in this way by casual users, there has
+   been a tendency for already-read messages to accumulate on the server
+   without bound.  This is clearly an undesirable behavior pattern from
+   the standpoint of the server operator.  This situation is aggravated
+   by the fact that the limited capabilities of the POP3 do not permit
+   efficient handling of maildrops which have hundreds or thousands of
+   messages.
+
+   Consequently, it is recommended that operators of large-scale multi-
+   user servers, especially ones in which the user's only access to the
+   maildrop is via POP3, consider such options as:
+
+   *  Imposing a per-user maildrop storage quota or the like.
+
+      A disadvantage to this option is that accumulation of messages may
+      result in the user's inability to receive new ones into the
+      maildrop.  Sites which choose this option should be sure to inform
+      users of impending or current exhaustion of quota, perhaps by
+      inserting an appropriate message into the user's maildrop.
+
+   *  Enforce a site policy regarding mail retention on the server.
+
+      Sites are free to establish local policy regarding the storage and
+      retention of messages on the server, both read and unread.  For
+      example, a site might delete unread messages from the server after
+      60 days and delete read messages after 7 days.  Such message
+      deletions are outside the scope of the POP3 protocol and are not
+      considered a protocol violation.
+
+      Server operators enforcing message deletion policies should take
+      care to make all users aware of the policies in force.
+
+      Clients must not assume that a site policy will automate message
+      deletions, and should continue to explicitly delete messages using
+      the DELE command when appropriate.
+
+      It should be noted that enforcing site message deletion policies
+      may be confusing to the user community, since their POP3 client
+      may contain configuration options to leave mail on the server
+      which will not in fact be supported by the server.
+
+      One special case of a site policy is that messages may only be
+      downloaded once from the server, and are deleted after this has
+      been accomplished.  This could be implemented in POP3 server
+
+
+
+Myers & Rose                Standards Track                    [Page 17]
+
+RFC 1939                          POP3                          May 1996
+
+
+      software by the following mechanism: "following a POP3 login by a
+      client which was ended by a QUIT, delete all messages downloaded
+      during the session with the RETR command".  It is important not to
+      delete messages in the event of abnormal connection termination
+      (ie, if no QUIT was received from the client) because the client
+      may not have successfully received or stored the messages.
+      Servers implementing a download-and-delete policy may also wish to
+      disable or limit the optional TOP command, since it could be used
+      as an alternate mechanism to download entire messages.
+
+9. POP3 Command Summary
+
+      Minimal POP3 Commands:
+
+         USER name               valid in the AUTHORIZATION state
+         PASS string
+         QUIT
+
+         STAT                    valid in the TRANSACTION state
+         LIST [msg]
+         RETR msg
+         DELE msg
+         NOOP
+         RSET
+         QUIT
+
+      Optional POP3 Commands:
+
+         APOP name digest        valid in the AUTHORIZATION state
+
+         TOP msg n               valid in the TRANSACTION state
+         UIDL [msg]
+
+      POP3 Replies:
+
+         +OK
+         -ERR
+
+      Note that with the exception of the STAT, LIST, and UIDL commands,
+      the reply given by the POP3 server to any command is significant
+      only to "+OK" and "-ERR".  Any text occurring after this reply
+      may be ignored by the client.
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                    [Page 18]
+
+RFC 1939                          POP3                          May 1996
+
+
+10. Example POP3 Session
+
+      S: <wait for connection on TCP port 110>
+      C: <open connection>
+      S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+      C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
+      S:    +OK mrose's maildrop has 2 messages (320 octets)
+      C:    STAT
+      S:    +OK 2 320
+      C:    LIST
+      S:    +OK 2 messages (320 octets)
+      S:    1 120
+      S:    2 200
+      S:    .
+      C:    RETR 1
+      S:    +OK 120 octets
+      S:    <the POP3 server sends message 1>
+      S:    .
+      C:    DELE 1
+      S:    +OK message 1 deleted
+      C:    RETR 2
+      S:    +OK 200 octets
+      S:    <the POP3 server sends message 2>
+      S:    .
+      C:    DELE 2
+      S:    +OK message 2 deleted
+      C:    QUIT
+      S:    +OK dewey POP3 server signing off (maildrop empty)
+      C:  <close connection>
+      S:  <wait for next connection>
+
+11. Message Format
+
+   All messages transmitted during a POP3 session are assumed to conform
+   to the standard for the format of Internet text messages [RFC822].
+
+   It is important to note that the octet count for a message on the
+   server host may differ from the octet count assigned to that message
+   due to local conventions for designating end-of-line.  Usually,
+   during the AUTHORIZATION state of the POP3 session, the POP3 server
+   can calculate the size of each message in octets when it opens the
+   maildrop.  For example, if the POP3 server host internally represents
+   end-of-line as a single character, then the POP3 server simply counts
+   each occurrence of this character in a message as two octets.  Note
+   that lines in the message which start with the termination octet need
+   not (and must not) be counted twice, since the POP3 client will
+   remove all byte-stuffed termination characters when it receives a
+   multi-line response.
+
+
+
+Myers & Rose                Standards Track                    [Page 19]
+
+RFC 1939                          POP3                          May 1996
+
+
+12. References
+
+   [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+       821, USC/Information Sciences Institute, August 1982.
+
+   [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
+       Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+   [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+       MIT Laboratory for Computer Science, April 1992.
+
+   [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
+       4", RFC 1730, University of Washington, December 1994.
+
+   [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
+       Carnegie Mellon, December 1994.
+
+13. Security Considerations
+
+   It is conjectured that use of the APOP command provides origin
+   identification and replay protection for a POP3 session.
+   Accordingly, a POP3 server which implements both the PASS and APOP
+   commands should not allow both methods of access for a given user;
+   that is, for a given mailbox name, either the USER/PASS command
+   sequence or the APOP command is allowed, but not both.
+
+   Further, note that as the length of the shared secret increases, so
+   does the difficulty of deriving it.
+
+   Servers that answer -ERR to the USER command are giving potential
+   attackers clues about which names are valid.
+
+   Use of the PASS command sends passwords in the clear over the
+   network.
+
+   Use of the RETR and TOP commands sends mail in the clear over the
+   network.
+
+   Otherwise, security issues are not discussed in this memo.
+
+14. Acknowledgements
+
+   The POP family has a long and checkered history.  Although primarily
+   a minor revision to RFC 1460, POP3 is based on the ideas presented in
+   RFCs 918, 937, and 1081.
+
+   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
+   provided significant comments on the APOP command.
+
+
+
+Myers & Rose                Standards Track                    [Page 20]
+
+RFC 1939                          POP3                          May 1996
+
+
+15. Authors' Addresses
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave
+   Pittsburgh, PA 15213
+
+   EMail: jgm+@cmu.edu
+
+
+   Marshall T. Rose
+   Dover Beach Consulting, Inc.
+   420 Whisman Court
+   Mountain View, CA  94043-2186
+
+   EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                    [Page 21]
+
+RFC 1939                          POP3                          May 1996
+
+
+Appendix A. Differences from RFC 1725
+
+   This memo is a revision to RFC 1725, a Draft Standard.  It makes the
+   following changes from that document:
+
+      - clarifies that command keywords are case insensitive.
+
+      - specifies that servers must send "+OK" and "-ERR" in
+        upper case.
+
+      - specifies that the initial greeting is a positive response,
+        instead of any string which should be a positive response.
+
+      - clarifies behavior for unimplemented commands.
+
+      - makes the USER and PASS commands optional.
+
+      - clarified the set of possible responses to the USER command.
+
+      - reverses the order of the examples in the USER and PASS
+        commands, to reduce confusion.
+
+      - clarifies that the PASS command may only be given immediately
+        after a successful USER command.
+
+      - clarified the persistence requirements of UIDs and added some
+        implementation notes.
+
+      - specifies a UID length limitation of one to 70 octets.
+
+      - specifies a status indicator length limitation
+        of 512 octets, including the CRLF.
+
+      - clarifies that LIST with no arguments on an empty mailbox
+        returns success.
+
+      - adds a reference from the LIST command to the Message Format
+        section
+
+      - clarifies the behavior of QUIT upon failure
+
+      - clarifies the security section to not imply the use of the
+        USER command with the APOP command.
+
+      - adds references to RFCs 1730 and 1734
+
+      - clarifies the method by which a UA may enter mail into the
+        transport system.
+
+
+
+Myers & Rose                Standards Track                    [Page 22]
+
+RFC 1939                          POP3                          May 1996
+
+
+      - clarifies that the second argument to the TOP command is a
+        number of lines.
+
+      - changes the suggestion in the Security Considerations section
+        for a server to not accept both PASS and APOP for a given user
+        from a "must" to a "should".
+
+      - adds a section on scaling and operational considerations
+
+Appendix B. Command Index
+
+       APOP .......................................................   15
+       DELE .......................................................    8
+       LIST .......................................................    6
+       NOOP .......................................................    9
+       PASS .......................................................   14
+       QUIT .......................................................    5
+       QUIT .......................................................   10
+       RETR .......................................................    8
+       RSET .......................................................    9
+       STAT .......................................................    6
+       TOP ........................................................   11
+       UIDL .......................................................   12
+       USER .......................................................   13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose                Standards Track                    [Page 23]
+
diff --git a/RFC/rfc1985.txt b/RFC/rfc1985.txt
new file mode 100644
index 00000000..f49afd75
--- /dev/null
+++ b/RFC/rfc1985.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                       J. De Winter
+Request for Comments: 1985                     Wildbear Consulting, Inc.
+Category: Standards Track                                    August 1996
+
+
+                         SMTP Service Extension
+                   for Remote Message Queue Starting
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo defines an extension to the SMTP service whereby an SMTP
+   client and server may interact to give the server an opportunity to
+   start the processing of its queues for messages to go to a given
+   host.  This extension is meant to be used in startup conditions as
+   well as for mail nodes that have transient connections to their
+   service providers.
+
+1.  Introduction
+
+   The TURN command was a valid attempt to address the problem of having
+   to start the processing for the mail queue on a remote machine.
+   However, the TURN command presents a large security loophole.  As
+   there is no verification of the remote host name, the TURN command
+   could be used by a rogue system to download the mail for a site other
+   than itself.
+
+   Therefore, this memo introduces the ETRN command.  This command uses
+   the mechanism defined in [4] to define extensions to the SMTP service
+   whereby a client ("sender-SMTP") may request that the server
+   ("receiver-SMTP") start the processing of its mail queues for
+   messages that are waiting at the server for the client machine.  If
+   any messages are at the server for the client, then the server should
+   create a new SMTP session and send the messages at that time.
+
+
+
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 1]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+2.  Framework for the ETRN Extension
+
+   The following service extension is therefore defined:
+
+   (1) the name of the SMTP service extension is "Remote Queue
+   Processing Declaration";
+
+   (2) the EHLO keyword value associated with this extension is "ETRN",
+   with no associated parameters;
+
+   (3) one additional verb, ETRN, with a single parameter that
+   specifies the name of the client(s) to start processing for;
+
+   (4) no additional SMTP verbs are defined by this extension.
+
+   The remainder of this memo specifies how support for the extension
+   affects the behavior of an SMTP client and server.
+
+3.  The Remote Queue Processing Declaration service extension
+
+   To save money, many small companies want to only maintain transient
+   connections to their service providers.  In addition, there are some
+   situations where the client sites depend on their mail arriving
+   quickly, so forcing the queues on the server belonging to their
+   service provider may be more desirable than waiting for the retry
+   timeout to occur.
+
+   Both of these situations could currently be fixed using the TURN
+   command defined in [1], if it were not for a large security loophole
+   in the TURN command.  As it stands, the TURN command will reverse the
+   direction of the SMTP connection and assume that the remote host is
+   being honest about what its name is.  The security loophole is that
+   there is no documented stipulation for checking the authenticity of
+   the remote host name, as given in the HELO or EHLO command.  As such,
+   most SMTP and ESMTP implementations do not implement the TURN command
+   to avoid this security loophole.
+
+   This has been addressed in the design of the ETRN command.  This
+   extended turn command was written with the points in the first
+   paragraph in mind, yet paying attention to the problems that
+   currently exist with the TURN command.  The security loophole is
+   avoided by asking the server to start a new connection aimed at the
+   specified client.
+
+   In this manner, the server has a lot more certainty that it is
+   talking to the correct SMTP client.  This mechanism can just be seen
+   as a more immediate version of the retry queues that appear in most
+   SMTP implementations.  In addition, as this command will take a
+
+
+
+De Winter                   Standards Track                     [Page 2]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+   single parameter, the name of the remote host(s) to start the queues
+   for, the server can decide whether it wishes to respect the request
+   or deny it for any local administrative reasons.
+
+4.  Definitions
+
+   Remote queue processing means that using an SMTP or ESMTP connection,
+   the client may request that the server start to process parts of its
+   messaging queue.  This processing is performed using the existing
+   SMTP infrastructure and will occur at some point after the processing
+   is initiated.
+
+      The server host is the node that is responding to the ETRN
+      command.
+
+      The client host is the node that is initiating the ETRN command.
+
+   The remote host name is defined to be a plain-text field that
+   specifies a name for the remote host(s).  This remote host name may
+   also include an alias for the specified remote host or special
+   commands to identify other types of queues.
+
+5.  The extended ETRN command
+
+   The extended ETRN command is issued by the client host when it wishes
+   to start the SMTP queue processing of a given server host.  The
+   syntax of this command is as follows:
+
+      ETRN [<option character>]<node name><CR><LF>
+
+   This command may be issued at any time once a session is established,
+   as long as there is not a transaction occuring.  Thus, this command
+   is illegal between a MAIL FROM: command and the end of the DATA
+   commands and responses.
+
+   The specified node name must be a fully qualified domain name for the
+   node, which may refer to a CNAME or MX pointer in the DNS.  If an
+   alias is used for the node, multiple ETRN commands may be needed to
+   start the processing for the node as it may be listed at the remote
+   site under multiple names.  This can also be addressed using the
+   options discussed in section 5.3.
+
+   The option character under normal circumstances is not used.
+
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 3]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+5.1  Server action on receipt of the extended ETRN command
+
+   When the server host receives the ETRN command, it should have a look
+   at the node name that is specified in the command and make a local
+   decision if it should honour the request.  If not, the appropriate
+   error codes should be returned to the client.
+
+   Otherwise, the server host should force its retry queues to start
+   sending messages to that remote site, using another SMTP connection.
+   At the moment, there is no requirement that a connection must occur,
+   or that the connection must occur within a given time frame.  This
+   should be noted in the case where there are no messages for the
+   client host at the server host and only the 250 response is used.
+
+   Since the processing of the queues may take an indeterminate amount
+   of time, this command should return immediately with a response to
+   the client host.  The valid return codes for this command are:
+
+   250 OK, queuing for node <x> started
+   251 OK, no messages waiting for node <x>
+   252 OK, pending messages for node <x> started
+   253 OK, <n> pending messages for node <x> started
+   458 Unable to queue messages for node <x>
+   459 Node <x> not allowed: <reason>
+   500 Syntax Error
+   501 Syntax Error in Parameters
+
+   The 250 response code does not indicate that messages will be sent to
+   the system in question, just that the queue has been started and some
+   action will occur.  If the server is capable of supporting it, the
+   251, 252 or 253 response codes should be used to give more
+   information to the client side.  In this case, if there are messages
+   waiting for the client side node, a check can be performed using
+   these responses codes as an indication of when there are no more
+   pending messages in the queue for that node.
+
+   The 458 and 459 result codes should be used to give more information
+   back to the client host as to why the action was not performed.  If
+   the syntax of the request is not correct, then the 500 and 501 result
+   codes should be used.
+
+5.2  Client action on receiving response to extended ETRN command
+
+   If one of the 500 level error codes (550 or 551) are sent, the client
+   should assume that the protocol is not supported in the remote host
+   or that the protocol has not been implemented correctly on either the
+   client or server host.  In this case, multiple ETRN commands (dealing
+   with the aliases for the system) should not be sent.
+
+
+
+De Winter                   Standards Track                     [Page 4]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+   If the 250 response is received, then the client host can assume that
+   the server host found its request to be satisfactory and it will send
+   any queued messages.  This process may involve going through a very
+   large retry queue, and may take some time.
+
+   If the 400 level response is received, then the client can assume
+   that the server supports the command, but for some local reason does
+   not want to accept the ETRN command as is.  In most cases, it will
+   mean that there is a list of nodes that it will accept the command
+   from and the current client is not on that list.  The 459 response
+   code is presented to allow for a more in-depth reason as to why the
+   remote queuing cannot be started.
+
+5.3  Use Of ETRN to release mail for a subdomain or queue
+
+   If the requesting server wishes to release all of the mail for a
+   given subdomain, a variation on the ETRN command can be used.  To
+   perform this request, the option character '@' should be used in
+   front of the node name.  In this manner, any domain names that are
+   formed with a suffix of the specified node name are released.
+
+   For example, if the command ETRN @foo.com was issued, then any
+   accumulated mail for fred.foo.com, a.b.c.d.e.f.g.foo.com or foo.com
+   may be released.  It should be noted that the receiving side of the
+   ETRN command should make a decision based on the client in question
+   and only allow certain combinations for each of the nodes.  This is
+   more of a security issue than anything else.
+
+   In a similar vein, it might be necessary under some circumstances to
+   release a certain queue, where that queue does not correspond to a
+   given domain name.  To this end, the option character '#' can be used
+   to force the processing of a given queue.  In this case, the node
+   name would be used as a queue name instead, and its syntactical
+   structure would be dependant on the receiving server.  An example of
+   this would be using the command ETRN #uucp to force the flush of a
+   UUCP queue.  Note that the use of this option is entirely a local
+   matter and there is no way for a client to find a list of any such
+   queues that exist.
+
+6.  Minimal usage
+
+   A "minimal" client may use this extension with its host name to start
+   the queues on the server host.  This minimal usage will not handle
+   cases where mail for 'x.y' is sent to 's.x.y'.
+
+   A minimal server may use this extensions to start the processing of
+   the queues for all remote sites.  In this case, the 458 error
+   response will not be seen, and it should always return the 250
+
+
+
+De Winter                   Standards Track                     [Page 5]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+   response as it will always try and start the processing for any
+   request.
+
+7. Example
+
+   The following example illustrates the use of remote queue processing
+   with some permanent and temporary failures.
+
+   S: <wait for connection on TCP port 25>
+   C: <open connection to server>
+   S: 220 sigurd.innosoft.com -- Server SMTP (PMDF V4.2-6 #1992)
+   C: EHLO ymir.claremont.edu
+   S: 250-sigurd.innosoft.com
+   S: 250-EXPN
+   S: 250-HELP
+   S: 250 ETRN
+   C: ETRN
+   S: 500 Syntax Error
+   C: ETRN localname
+   S: 501 Syntax Error in Parameters
+   C: ETRN uu.net
+   S: 458 Unable to queue messages for node uu.net
+   ...
+
+   C: ETRN sigurd.innosoft.com
+   S: 250 OK, queuing for node sigurd.innosoft.com started
+   C: ETRN innosoft.com
+   S: 250 OK, queuing for node innosoft.com started
+
+   OR
+
+   C: ETRN sigurd.innosoft.com
+   S: 251 OK, no messages waiting for node sigurd.innosoft.com
+   C: ETRN innosoft.com
+   S: 252 OK, pending messages for node innosoft.com started
+   C: ETRN mysoft.com
+   S: 253 OK, 14 pending messages for node mysoft.com started
+
+   ...
+   C: ETRN foo.bar
+   S: 459 Node foo.bar not allowed: Unable to resolve name.
+   ...
+   C: QUIT
+   S: 250 Goodbye
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 6]
+
+RFC 1985             SMTP Service Extension - ETRN           August 1996
+
+
+8. Security Considerations
+
+   This command does not compromise any security considerations of any
+   existing SMTP or ESMTP protocols as it merely shortens the time that
+   a client needs to wait before their messages are retried.
+
+   Precautions should be taken to make sure that any client server can
+   only use the @ and # option characters for systems that make sense.
+   Failure to implement some kind of sanity checking on the parameters
+   could lead to congestion.  This would be evident if a person asking
+   to release @com, which would release mail for any address that ended
+   with com.
+
+9.  Acknowledgements
+
+   This document was created with lots of support from the users of our
+   products, who have given some input to the functionality that they
+   would like to see in the software that they bought.
+
+10.  References
+
+   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+       821, August 1982.
+
+   [2] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
+       E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
+       Nations University, Innosoft International, Inc., Dover Beach
+       Consulting, Inc., Network Management Associates, Inc., The Branch
+       Office, February 1993.
+
+11.  Author's Address
+
+   Jack De Winter
+   Wildbear Consulting, Inc.
+   17 Brock Street
+   Kitchener, Ontario, Canada
+   N2M 1X2
+
+   Phone: +1 519 576 3873
+   EMail: jack@wildbear.on.ca
+
+
+
+
+
+
+
+
+
+
+
+De Winter                   Standards Track                     [Page 7]
+
diff --git a/RFC/rfc2033.txt b/RFC/rfc2033.txt
new file mode 100644
index 00000000..a47433e8
--- /dev/null
+++ b/RFC/rfc2033.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2033                               Carnegie Mellon
+Category: Informational                                     October 1996
+
+
+                      Local Mail Transfer Protocol
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+1.  Abstract
+
+   SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a
+   mechanism for transferring mail reliably and efficiently.  The design
+   of the SMTP protocol effectively requires the server to manage a mail
+   delivery queue.
+
+   In some limited circumstances, outside the area of mail exchange
+   between independent hosts on public networks, it is desirable to
+   implement a system where a mail receiver does not manage a queue.
+   This document describes the LMTP protocol for transporting mail into
+   such systems.
+
+   Although LMTP is an alternative protocol to ESMTP, it uses (with a
+   few changes) the syntax and semantics of ESMTP.  This design permits
+   LMTP to utilize the extensions defined for ESMTP.  LMTP should be
+   used only by specific prior arrangement and configuration, and it
+   MUST NOT be used on TCP port 25.
+
+Table of Contents
+
+   1.   Abstract ................................................    1
+   2.   Conventions Used in this Document .......................    2
+   3.   Introduction and Overview ...............................    2
+   4.   The LMTP protocol .......................................    3
+   4.1. The LHLO, HELO and EHLO commands ........................    4
+   4.2. The DATA command ........................................    4
+   4.3. The BDAT command ........................................    5
+   5.   Implementation requirements .............................    6
+   6.   Acknowledgments .........................................    6
+   7.   References ..............................................    7
+   8.   Security Considerations .................................    7
+   9.   Author's Address ........................................    7
+
+
+
+
+
+Myers                        Informational                      [Page 1]
+
+RFC 2033                          LMTP                      October 1996
+
+
+2.  Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+3.  Introduction and Overview
+
+   The design of the SMTP protocol effectively requires the server to
+   manage a mail delivery queue.  This is because a single mail
+   transaction may specify multiple recipients and the final "." of the
+   DATA command may return only one reply code, to indicate the status
+   of the entire transaction.  If, for example, a server is given a
+   transaction for two recipients, delivery to the first succeeds, and
+   delivery to the second encounters a temporary failure condition,
+   there is no mechanism to inform the client of the situation.  The
+   server must queue the message and later attempt to deliver it to the
+   second recipient.
+
+   This queuing requirement is beneficial in the situation for which
+   SMTP was originally designed: store-and-forward relay of mail between
+   networked hosts.  In some limited situations, it is desirable to have
+   a server which does not manage a queue, instead relying on the client
+   to perform queue management.  As an example, consider a hypothetical
+   host with a mail system designed as follows:
+
+
+
+                    TCP port 25 +-----------------+
+         ---------------------->|                 |  #########
+                                |      Queue      |<># Mail  #
+         TCP port 25            |     Manager     |  # Queue #
+         <----------------------|                 |  #########
+                                +-----------------+
+                            Local *  ^ Local    * Local
+                              IPC *  | IPC      * IPC
+                                  *  |          *
+                                  *  |          *
+                                  *  |          *
+                                  V  |          V
+                  Non-SMTP    +----------+     +----------+
+                  Protocol    | Gateway  |     |  Local   |  #########
+              <==============>| Delivery |     | Delivery |>># Mail  #
+                              |  Agent   |     |  Agent   |  # Spool #
+                              +----------+     +----------+  #########
+
+
+   The host's mail system has three independent, communicating
+   subsystems.  The first is a queue manager, which acts as a
+
+
+
+Myers                        Informational                      [Page 2]
+
+RFC 2033                          LMTP                      October 1996
+
+
+   traditional SMTP agent, transferring messages to and from other hosts
+   over TCP and managing a mail queue in persistent storage.  The other
+   two are agents which handle delivery for addresses in domains for
+   which the host takes responsibility.  One agent performs gatewaying
+   to and from some other mail system.  The other agent delivers the
+   message into a persistent mail spool.
+
+   It would be desirable to use SMTP over a local inter-process
+   communication channel to transfer messages from the queue manager to
+   the delivery agents.  It would, however, significantly increase the
+   complexity of the delivery agents to require them to manage their own
+   mail queues.
+
+   The common practice of invoking a delivery agent with the envelope
+   address(es) as command-line arguments, then having the delivery agent
+   communicate status with an exit code has three serious problems: the
+   agent can only return one exit code to be applied to all recipients,
+   it is difficult to extend the interface to deal with ESMTP extensions
+   such as DSN [DSN] and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES], and
+   exits performed by system libraries due to temporary conditions
+   frequently get interpreted as permanent errors.
+
+   The LMTP protocol causes the server to return, after the final "." of
+   the DATA command, one reply for each recipient.  Therefore, if the
+   queue manager is configured to use LMTP instead of SMTP when
+   transferring messages to the delivery agents, then the delivery
+   agents may attempt delivery to each recipient after the final "." and
+   individually report the status for each recipient.  Connections which
+   should use the LMTP protocol are drawn in the diagram above using
+   asterisks.
+
+   Note that it is not beneficial to use the LMTP protocol when
+   transferring messages to the queue manager, either from the network
+   or from a delivery agent.  The queue manager does implement a mail
+   queue, so it may store the message and take responsibility for later
+   delivering it.
+
+4.  The LMTP protocol
+
+   The LMTP protocol is identical to the SMTP protocol SMTP [SMTP]
+   [HOST-REQ] with its service extensions [ESMTP], except as modified by
+   this document.
+
+   A "successful" RCPT command is defined as an RCPT command which
+   returns a Positive Completion reply code.
+
+   A "Positive Completion reply code" is defined in Appendix E of STD
+   10, RFC 821 [SMTP] as a reply code which "2" as the first digit.
+
+
+
+Myers                        Informational                      [Page 3]
+
+RFC 2033                          LMTP                      October 1996
+
+
+4.1.  The LHLO, HELO and EHLO commands
+
+   The HELO and EHLO commands of ESMTP are replaced by the LHLO command.
+   This permits a misconfiguration where both parties are not using the
+   same protocol to be detected.
+
+   The LHLO command has identical semantics to the EHLO command of ESMTP
+   [ESMTP].
+
+   The HELO and EHLO commands of ESMTP are not present in LMTP.  A LMTP
+   server MUST NOT return a Postive Completion reply code to these
+   commands.  The 500 reply code is recommended.
+
+4.2.  The DATA command
+
+   In the LMTP protocol, there is one additional restriction placed on
+   the DATA command, and one change to how replies to the final "." are
+   sent.
+
+   The additional restriction is that when there have been no successful
+   RCPT commands in the mail transaction, the DATA command MUST fail
+   with a 503 reply code.
+
+   The change is that after the final ".", the server returns one reply
+   for each previously successful RCPT command in the mail transaction,
+   in the order that the RCPT commands were issued.  Even if there were
+   multiple successful RCPT commands giving the same forward-path, there
+   must be one reply for each successful RCPT command.
+
+   When one of these replies to the final "." is a Positive Completion
+   reply, the server is accepting responsibility for delivering or
+   relying the message to the corresponding recipient.  It must take
+   this responsibility seriously, i.e., it MUST NOT lose the message for
+   frivolous reasons, e.g., because the host later crashes or because of
+   a predictable resource shortage.
+
+   A multiline reply is still considered a single reply and corresponds
+   to a single RCPT command.
+
+   EXAMPLE:
+
+   S: 220 foo.edu LMTP server ready
+   C: LHLO foo.edu
+   S: 250-foo.edu
+   S: 250-PIPELINING
+   S: 250 SIZE
+   C: MAIL FROM:<chris@bar.com>
+   S: 250 OK
+
+
+
+Myers                        Informational                      [Page 4]
+
+RFC 2033                          LMTP                      October 1996
+
+
+   C: RCPT TO:<pat@foo.edu>
+   S: 250 OK
+   C: RCPT TO:<jones@foo.edu>
+   S: 550 No such user here
+   C: RCPT TO:<green@foo.edu>
+   S: 250 OK
+   C: DATA
+   S: 354 Start mail input; end with <CRLF>.<CRLF>
+   C: Blah blah blah...
+   C: ...etc. etc. etc.
+   C: .
+   S: 250 OK
+   S: 452 <green@foo.edu> is temporarily over quota
+   C: QUIT
+   S: 221 foo.edu closing connection
+
+
+NOTE: in the above example, the domain names of both the client and
+   server are identical.  This is because in the example the client and
+   server are different subsystems of the same mail domain.
+
+4.3.  The BDAT command
+
+   If the server supports the ESMTP CHUNKING extension [BINARYMIME], a
+   BDAT command containing the LAST parameter returns one reply for each
+   previously successful RCPT command in the mail transaction, in the
+   order that the RCPT commands were issued.  Even if there were
+   multiple successful RCPT commands giving the same forward-path, there
+   must be one reply for each successful RCPT command.  If there were no
+   previously successful RCPT commands in the mail transaction, then the
+   BDAT LAST command returns zero replies.
+
+   When one of these replies to the BDAT LAST command is a Positive
+   Completion reply, the server is accepting responsibility for
+   delivering or relaying the message to the corresponding recipient.
+   It must take this responsibility seriously, i.e., it MUST NOT lose
+   the message for frivolous reasons, e.g., because the host later
+   crashes or because of a predictable resource shortage.
+
+   A multiline reply is still considered a single reply and corresponds
+   to a single RCPT command.
+
+   The behavior of BDAT commands without the LAST parameter is not
+   changed; they still return exactly one reply.
+
+
+
+
+
+
+
+Myers                        Informational                      [Page 5]
+
+RFC 2033                          LMTP                      October 1996
+
+
+5.  Implementation requirements
+
+   As LMTP is a different protocol than SMTP, it MUST NOT be used on the
+   TCP service port 25.
+
+   A server implementation MUST implement the PIPELINING [PIPELINING]
+   and ENHANCEDSTATUSCODES [ENHANCEDSTATUSCODES] ESMTP extensions.  A
+   server implementation SHOULD implement the 8BITMIME [8BITMIME]
+   extension.
+
+   Use of LMTP can aggravate the situation described in [DUP-MSGS].  To
+   avoid this synchronization problem, the following requirements are
+   made of implementations:
+
+   A server implementation which is capable of quickly accepting
+   responsibility for delivering or relaying a message to multiple
+   recipients and which is capable of sending any necessary notification
+   messages SHOULD NOT implement the LMTP protocol.
+
+   The LMTP protocol SHOULD NOT be used over wide area networks.
+
+   The server SHOULD send each reply as soon as possible.  If it is
+   going to spend a nontrivial amount of time handling delivery for the
+   next recipient, it SHOULD flush any outgoing LMTP buffer, so the
+   reply may be quickly received by the client.
+
+   The client SHOULD process the replies as they come in, instead of
+   waiting for all of the replies to arrive before processing any of
+   them.  If the connection closes after replies for some, but not all,
+   recipients have arrived, the client MUST process the replies that
+   arrived and treat the rest as temporary failures.
+
+6.  Acknowledgments
+
+   This work is a refinement of the MULT extension, which was invented
+   by Jeff Michaud and was used in implementing gateways to the Mail-11
+   mail system.
+
+   Many thanks to Matt Thomas for assisting me in understanding the
+   semantics of the Mail-11 MULT extension.
+
+
+
+
+
+
+
+
+
+
+
+Myers                        Informational                      [Page 6]
+
+RFC 2033                          LMTP                      October 1996
+
+
+7.  References
+
+   [8BITMIME] Klensin, J., et. al, "SMTP Service Extension for 8bit-MIME
+       transport", RFC 1652, July 1994.
+
+   [BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission
+       of Large and Binary MIME Messages", RFC 1830, August 1995.
+
+   [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for
+       Delivery Status Notifications", RFC 1894, January 1996.
+
+   [DUP-MSGS] Partridge, C., "Duplicate messages and SMTP", RFC 1047,
+       February 1988.
+
+   [ENHANCEDSTATUSCODES] Freed, N., "SMTP Service Extension for
+       Returning Enhanced Error Codes", RFC 2034, October 1996.
+
+   [ESMTP] Rose, M., Stefferud, E., Crocker, C., Klensin, J., Freed, N.,
+       "SMTP Service Extensions", RFC 1869, November 1995.
+
+   [HOST-REQ] Braden, R., "Requirements for Internet hosts - application
+       and support", STD 3, RFC 1123 section 5, October 1989.
+
+   [PIPELINING] Freed, N., Cargille, A, "SMTP Service Extension for
+       Command Pipelining", RFC 1854, October 1995.
+
+   [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+       August 1982.
+
+
+   There are no known security issues with the issues in this memo.
+
+9.  Author's Address
+
+   John G. Myers
+   Carnegie-Mellon University
+   5000 Forbes Ave.
+   Pittsburgh PA, 15213-3890
+
+   EMail: jgm+@cmu.edu
+
+
+
+
+
+
+
+
+
+
+
+Myers                        Informational                      [Page 7]
+
diff --git a/RFC/rfc2060.txt b/RFC/rfc2060.txt
new file mode 100644
index 00000000..591dec4d
--- /dev/null
+++ b/RFC/rfc2060.txt
@@ -0,0 +1,4595 @@
+
+
+
+
+
+
+Network Working Group                                        M. Crispin
+Request for Comments: 2060                     University of Washington
+Obsoletes: 1730                                           December 1996
+Category: Standards Track
+
+
+            INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
+   allows a client to access and manipulate electronic mail messages on
+   a server.  IMAP4rev1 permits manipulation of remote message folders,
+   called "mailboxes", in a way that is functionally equivalent to local
+   mailboxes.  IMAP4rev1 also provides the capability for an offline
+   client to resynchronize with the server (see also [IMAP-DISC]).
+
+   IMAP4rev1 includes operations for creating, deleting, and renaming
+   mailboxes; checking for new messages; permanently removing messages;
+   setting and clearing flags; [RFC-822] and [MIME-IMB] parsing;
+   searching; and selective fetching of message attributes, texts, and
+   portions thereof.  Messages in IMAP4rev1 are accessed by the use of
+   numbers.  These numbers are either message sequence numbers or unique
+   identifiers.
+
+   IMAP4rev1 supports a single server.  A mechanism for accessing
+   configuration information to support multiple IMAP4rev1 servers is
+   discussed in [ACAP].
+
+   IMAP4rev1 does not specify a means of posting mail; this function is
+   handled by a mail transfer protocol such as [SMTP].
+
+   IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
+   unpublished IMAP2bis protocols.  In the course of the evolution of
+   IMAP4rev1, some aspects in the earlier protocol have become obsolete.
+   Obsolete commands, responses, and data formats which an IMAP4rev1
+   implementation may encounter when used with an earlier implementation
+   are described in [IMAP-OBSOLETE].
+
+
+
+
+
+Crispin                     Standards Track                     [Page 1]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Other compatibility issues with IMAP2bis, the most common variant of
+   the earlier protocol, are discussed in [IMAP-COMPAT].  A full
+   discussion of compatibility issues with rare (and presumed extinct)
+   variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
+   primarily of historical interest.
+
+Table of Contents
+
+IMAP4rev1 Protocol Specification ..................................    4
+1.      How to Read This Document .................................    4
+1.1.    Organization of This Document .............................    4
+1.2.    Conventions Used in This Document .........................    4
+2.      Protocol Overview .........................................    5
+2.1.    Link Level ................................................    5
+2.2.    Commands and Responses ....................................    6
+2.2.1.  Client Protocol Sender and Server Protocol Receiver .......    6
+2.2.2.  Server Protocol Sender and Client Protocol Receiver .......    7
+2.3.    Message Attributes ........................................    7
+2.3.1.  Message Numbers ...........................................    7
+2.3.1.1.        Unique Identifier (UID) Message Attribute .........    7
+2.3.1.2.        Message Sequence Number Message Attribute .........    9
+2.3.2.  Flags Message Attribute ....................................   9
+2.3.3.  Internal Date Message Attribute ...........................   10
+2.3.4.  [RFC-822] Size Message Attribute ..........................   11
+2.3.5.  Envelope Structure Message Attribute ......................   11
+2.3.6.  Body Structure Message Attribute ..........................   11
+2.4.    Message Texts .............................................   11
+3.      State and Flow Diagram ....................................   11
+3.1.    Non-Authenticated State ...................................   11
+3.2.    Authenticated State .......................................   11
+3.3.    Selected State ............................................   12
+3.4.    Logout State ..............................................   12
+4.      Data Formats ..............................................   12
+4.1.    Atom ......................................................   13
+4.2.    Number ....................................................   13
+4.3.    String .....................................................  13
+4.3.1.  8-bit and Binary Strings ..................................   13
+4.4.    Parenthesized List ........................................   14
+4.5.    NIL .......................................................   14
+5.      Operational Considerations ................................   14
+5.1.    Mailbox Naming ............................................   14
+5.1.1.  Mailbox Hierarchy Naming ..................................   14
+5.1.2.  Mailbox Namespace Naming Convention .......................   14
+5.1.3.  Mailbox International Naming Convention ...................   15
+5.2.    Mailbox Size and Message Status Updates ...................   16
+5.3.    Response when no Command in Progress ......................   16
+5.4.    Autologout Timer ..........................................   16
+5.5.    Multiple Commands in Progress .............................   17
+
+
+
+Crispin                     Standards Track                     [Page 2]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+6.      Client Commands ...........................................   17
+6.1.    Client Commands - Any State ...............................   18
+6.1.1.  CAPABILITY Command ........................................   18
+6.1.2.  NOOP Command ..............................................   19
+6.1.3.  LOGOUT Command ............................................   20
+6.2.    Client Commands - Non-Authenticated State .................   20
+6.2.1.  AUTHENTICATE Command ......................................   21
+6.2.2.  LOGIN Command .............................................   22
+6.3.    Client Commands - Authenticated State .....................   22
+6.3.1.  SELECT Command ............................................   23
+6.3.2.  EXAMINE Command ...........................................   24
+6.3.3.  CREATE Command ............................................   25
+6.3.4.  DELETE Command ............................................   26
+6.3.5.  RENAME Command ............................................   27
+6.3.6.  SUBSCRIBE Command .........................................   29
+6.3.7.  UNSUBSCRIBE Command .......................................   30
+6.3.8.  LIST Command ..............................................   30
+6.3.9.  LSUB Command ..............................................   32
+6.3.10. STATUS Command ............................................   33
+6.3.11. APPEND Command ............................................   34
+6.4.    Client Commands - Selected State ..........................   35
+6.4.1.  CHECK Command .............................................   36
+6.4.2.  CLOSE Command .............................................   36
+6.4.3.  EXPUNGE Command ...........................................   37
+6.4.4.  SEARCH Command ............................................   37
+6.4.5.  FETCH Command .............................................   41
+6.4.6.  STORE Command .............................................   45
+6.4.7.  COPY Command ..............................................   46
+6.4.8.  UID Command ...............................................   47
+6.5.    Client Commands - Experimental/Expansion ..................   48
+6.5.1.  X<atom> Command ...........................................   48
+7.      Server Responses ..........................................   48
+7.1.    Server Responses - Status Responses .......................   49
+7.1.1.  OK Response ...............................................   51
+7.1.2.  NO Response ...............................................   51
+7.1.3.  BAD Response ..............................................   52
+7.1.4.  PREAUTH Response ..........................................   52
+7.1.5.  BYE Response ..............................................   52
+7.2.    Server Responses - Server and Mailbox Status ..............   53
+7.2.1.  CAPABILITY Response .......................................   53
+7.2.2.  LIST Response ..............................................  54
+7.2.3.  LSUB Response .............................................   55
+7.2.4   STATUS Response ...........................................   55
+7.2.5.  SEARCH Response ...........................................   55
+7.2.6.  FLAGS Response ............................................   56
+7.3.    Server Responses - Mailbox Size ...........................   56
+7.3.1.  EXISTS Response ...........................................   56
+7.3.2.  RECENT Response ...........................................   57
+
+
+
+Crispin                     Standards Track                     [Page 3]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+7.4.    Server Responses - Message Status .........................   57
+7.4.1.  EXPUNGE Response ..........................................   57
+7.4.2.  FETCH Response ............................................   58
+7.5.    Server Responses - Command Continuation Request ...........   63
+8.      Sample IMAP4rev1 connection ...............................   63
+9.      Formal Syntax .............................................   64
+10.     Author's Note .............................................   74
+11.     Security Considerations ...................................   74
+12.     Author's Address ..........................................   75
+Appendices ........................................................   76
+A.      References ................................................   76
+B.      Changes from RFC 1730 .....................................   77
+C.      Key Word Index ............................................   79
+
+
+IMAP4rev1 Protocol Specification
+
+1.      How to Read This Document
+
+1.1.    Organization of This Document
+
+   This document is written from the point of view of the implementor of
+   an IMAP4rev1 client or server.  Beyond the protocol overview in
+   section 2, it is not optimized for someone trying to understand the
+   operation of the protocol.  The material in sections 3 through 5
+   provides the general context and definitions with which IMAP4rev1
+   operates.
+
+   Sections 6, 7, and 9 describe the IMAP commands, responses, and
+   syntax, respectively.  The relationships among these are such that it
+   is almost impossible to understand any of them separately.  In
+   particular, do not attempt to deduce command syntax from the command
+   section alone; instead refer to the Formal Syntax section.
+
+1.2.    Conventions Used in This Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The following terms are used in this document to signify the
+   requirements of this specification.
+
+   1) MUST, or the adjective REQUIRED, means that the definition is
+      an absolute requirement of the specification.
+
+   2) MUST NOT that the definition is an absolute prohibition of the
+      specification.
+
+
+
+
+Crispin                     Standards Track                     [Page 4]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   3) SHOULD means that there may exist valid reasons in particular
+      circumstances to ignore a particular item, but the full
+      implications MUST be understood and carefully weighed before
+      choosing a different course.
+
+   4) SHOULD NOT means that there may exist valid reasons in
+      particular circumstances when the particular behavior is
+      acceptable or even useful, but the full implications SHOULD be
+      understood and the case carefully weighed before implementing
+      any behavior described with this label.
+
+   5) MAY, or the adjective OPTIONAL, means that an item is truly
+      optional.  One vendor may choose to include the item because a
+      particular marketplace requires it or because the vendor feels
+      that it enhances the product while another vendor may omit the
+      same item.  An implementation which does not include a
+      particular option MUST be prepared to interoperate with another
+      implementation which does include the option.
+
+      "Can" is used instead of "may" when referring to a possible
+      circumstance or situation, as opposed to an optional facility of
+      the protocol.
+
+      "User" is used to refer to a human user, whereas "client" refers
+      to the software being run by the user.
+
+      "Connection" refers to the entire sequence of client/server
+      interaction from the initial establishment of the network
+      connection until its termination.  "Session" refers to the
+      sequence of client/server interaction from the time that a mailbox
+      is selected (SELECT or EXAMINE command) until the time that
+      selection ends (SELECT or EXAMINE of another mailbox, CLOSE
+      command, or connection termination).
+
+       Characters are 7-bit US-ASCII unless otherwise specified.  Other
+       character sets are indicated using a "CHARSET", as described in
+       [MIME-IMT] and defined in [CHARSET].  CHARSETs have important
+       additional semantics in addition to defining character set; refer
+       to these documents for more detail.
+
+2.      Protocol Overview
+
+2.1.    Link Level
+
+   The IMAP4rev1 protocol assumes a reliable data stream such as
+   provided by TCP.  When TCP is used, an IMAP4rev1 server listens on
+   port 143.
+
+
+
+
+Crispin                     Standards Track                     [Page 5]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+2.2.    Commands and Responses
+
+   An IMAP4rev1 connection consists of the establishment of a
+   client/server network connection, an initial greeting from the
+   server, and client/server interactions.  These client/server
+   interactions consist of a client command, server data, and a server
+   completion result response.
+
+   All interactions transmitted by client and server are in the form of
+   lines; that is, strings that end with a CRLF.  The protocol receiver
+   of an IMAP4rev1 client or server is either reading a line, or is
+   reading a sequence of octets with a known count followed by a line.
+
+2.2.1.  Client Protocol Sender and Server Protocol Receiver
+
+   The client command begins an operation.  Each client command is
+   prefixed with an identifier (typically a short alphanumeric string,
+   e.g. A0001, A0002, etc.) called a "tag".  A different tag is
+   generated by the client for each command.
+
+   There are two cases in which a line from the client does not
+   represent a complete command.  In one case, a command argument is
+   quoted with an octet count (see the description of literal in String
+   under Data Formats); in the other case, the command arguments require
+   server feedback (see the AUTHENTICATE command).  In either case, the
+   server sends a command continuation request response if it is ready
+   for the octets (if appropriate) and the remainder of the command.
+   This response is prefixed with the token "+".
+
+      Note: If, instead, the server detected an error in the command, it
+      sends a BAD completion response with tag matching the command (as
+      described below) to reject the command and prevent the client from
+      sending any more of the command.
+
+      It is also possible for the server to send a completion response
+      for some other command (if multiple commands are in progress), or
+      untagged data.  In either case, the command continuation request
+      is still pending; the client takes the appropriate action for the
+      response, and reads another response from the server.  In all
+      cases, the client MUST send a complete command (including
+      receiving all command continuation request responses and command
+      continuations for the command) before initiating a new command.
+
+   The protocol receiver of an IMAP4rev1 server reads a command line
+   from the client, parses the command and its arguments, and transmits
+   server data and a server command completion result response.
+
+
+
+
+
+Crispin                     Standards Track                     [Page 6]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+2.2.2.  Server Protocol Sender and Client Protocol Receiver
+
+   Data transmitted by the server to the client and status responses
+   that do not indicate command completion are prefixed with the token
+   "*", and are called untagged responses.
+
+   Server data MAY be sent as a result of a client command, or MAY be
+   sent unilaterally by the server.  There is no syntactic difference
+   between server data that resulted from a specific command and server
+   data that were sent unilaterally.
+
+   The server completion result response indicates the success or
+   failure of the operation.  It is tagged with the same tag as the
+   client command which began the operation.  Thus, if more than one
+   command is in progress, the tag in a server completion response
+   identifies the command to which the response applies.  There are
+   three possible server completion responses: OK (indicating success),
+   NO (indicating failure), or BAD (indicating protocol error such as
+   unrecognized command or command syntax error).
+
+   The protocol receiver of an IMAP4rev1 client reads a response line
+   from the server.  It then takes action on the response based upon the
+   first token of the response, which can be a tag, a "*", or a "+".
+
+   A client MUST be prepared to accept any server response at all times.
+   This includes server data that was not requested.  Server data SHOULD
+   be recorded, so that the client can reference its recorded copy
+   rather than sending a command to the server to request the data.  In
+   the case of certain server data, the data MUST be recorded.
+
+   This topic is discussed in greater detail in the Server Responses
+   section.
+
+2.3.    Message Attributes
+
+   In addition to message text, each message has several attributes
+   associated with it.  These attributes may be retrieved individually
+   or in conjunction with other attributes or message texts.
+
+2.3.1.  Message Numbers
+
+   Messages in IMAP4rev1 are accessed by one of two numbers; the unique
+   identifier and the message sequence number.
+
+2.3.1.1.        Unique Identifier (UID) Message Attribute
+
+   A 32-bit value assigned to each message, which when used with the
+   unique identifier validity value (see below) forms a 64-bit value
+
+
+
+Crispin                     Standards Track                     [Page 7]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   that is permanently guaranteed not to refer to any other message in
+   the mailbox.  Unique identifiers are assigned in a strictly ascending
+   fashion in the mailbox; as each message is added to the mailbox it is
+   assigned a higher UID than the message(s) which were added
+   previously.
+
+   Unlike message sequence numbers, unique identifiers are not
+   necessarily contiguous.  Unique identifiers also persist across
+   sessions.  This permits a client to resynchronize its state from a
+   previous session with the server (e.g. disconnected or offline access
+   clients); this is discussed further in [IMAP-DISC].
+
+   Associated with every mailbox is a unique identifier validity value,
+   which is sent in an UIDVALIDITY response code in an OK untagged
+   response at mailbox selection time.  If unique identifiers from an
+   earlier session fail to persist to this session, the unique
+   identifier validity value MUST be greater than the one used in the
+   earlier session.
+
+      Note: Unique identifiers MUST be strictly ascending in the mailbox
+      at all times.  If the physical message store is re-ordered by a
+      non-IMAP agent, this requires that the unique identifiers in the
+      mailbox be regenerated, since the former unique identifers are no
+      longer strictly ascending as a result of the re-ordering.  Another
+      instance in which unique identifiers are regenerated is if the
+      message store has no mechanism to store unique identifiers.
+      Although this specification recognizes that this may be
+      unavoidable in certain server environments, it STRONGLY ENCOURAGES
+      message store implementation techniques that avoid this problem.
+
+      Another cause of non-persistance is if the mailbox is deleted and
+      a new mailbox with the same name is created at a later date, Since
+      the name is the same, a client may not know that this is a new
+      mailbox unless the unique identifier validity is different.  A
+      good value to use for the unique identifier validity value is a
+      32-bit representation of the creation date/time of the mailbox.
+      It is alright to use a constant such as 1, but only if it
+      guaranteed that unique identifiers will never be reused, even in
+      the case of a mailbox being deleted (or renamed) and a new mailbox
+      by the same name created at some future time.
+
+   The unique identifier of a message MUST NOT change during the
+   session, and SHOULD NOT change between sessions.  However, if it is
+   not possible to preserve the unique identifier of a message in a
+   subsequent session, each subsequent session MUST have a new unique
+   identifier validity value that is larger than any that was used
+   previously.
+
+
+
+
+Crispin                     Standards Track                     [Page 8]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+2.3.1.2.        Message Sequence Number Message Attribute
+
+   A relative position from 1 to the number of messages in the mailbox.
+   This position MUST be ordered by ascending unique identifier.  As
+   each new message is added, it is assigned a message sequence number
+   that is 1 higher than the number of messages in the mailbox before
+   that new message was added.
+
+   Message sequence numbers can be reassigned during the session.  For
+   example, when a message is permanently removed (expunged) from the
+   mailbox, the message sequence number for all subsequent messages is
+   decremented.  Similarly, a new message can be assigned a message
+   sequence number that was once held by some other message prior to an
+   expunge.
+
+   In addition to accessing messages by relative position in the
+   mailbox, message sequence numbers can be used in mathematical
+   calculations.  For example, if an untagged "EXISTS 11" is received,
+   and previously an untagged "8 EXISTS" was received, three new
+   messages have arrived with message sequence numbers of 9, 10, and 11.
+   Another example; if message 287 in a 523 message mailbox has UID
+   12345, there are exactly 286 messages which have lesser UIDs and 236
+   messages which have greater UIDs.
+
+2.3.2.  Flags Message Attribute
+
+   A list of zero or more named tokens associated with the message.  A
+   flag is set by its addition to this list, and is cleared by its
+   removal.  There are two types of flags in IMAP4rev1.  A flag of
+   either type may be permanent or session-only.
+
+   A system flag is a flag name that is pre-defined in this
+   specification.  All system flags begin with "\".  Certain system
+   flags (\Deleted and \Seen) have special semantics described
+   elsewhere.  The currently-defined system flags are:
+
+        \Seen       Message has been read
+
+        \Answered   Message has been answered
+
+        \Flagged    Message is "flagged" for urgent/special attention
+
+        \Deleted    Message is "deleted" for removal by later EXPUNGE
+
+        \Draft      Message has not completed composition (marked as a
+                    draft).
+
+
+
+
+
+Crispin                     Standards Track                     [Page 9]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+        \Recent     Message is "recently" arrived in this mailbox.  This
+                    session is the first session to have been notified
+                    about this message; subsequent sessions will not see
+                    \Recent set for this message.  This flag can not be
+                    altered by the client.
+
+                    If it is not possible to determine whether or not
+                    this session is the first session to be notified
+                    about a message, then that message SHOULD be
+                    considered recent.
+
+                    If multiple connections have the same mailbox
+                    selected simultaneously, it is undefined which of
+                    these connections will see newly-arrives messages
+                    with \Recent set and which will see it without
+                    \Recent set.
+
+      A keyword is defined by the server implementation.  Keywords do
+      not begin with "\".  Servers MAY permit the client to define new
+      keywords in the mailbox (see the description of the
+      PERMANENTFLAGS response code for more information).
+
+      A flag may be permanent or session-only on a per-flag basis.
+      Permanent flags are those which the client can add or remove
+      from the message flags permanently; that is, subsequent sessions
+      will see any change in permanent flags.  Changes to session
+      flags are valid only in that session.
+
+      Note: The \Recent system flag is a special case of a
+      session flag.  \Recent can not be used as an argument in a
+      STORE command, and thus can not be changed at all.
+
+2.3.3.  Internal Date Message Attribute
+
+   The internal date and time of the message on the server.  This is not
+   the date and time in the [RFC-822] header, but rather a date and time
+   which reflects when the message was received.  In the case of
+   messages delivered via [SMTP], this SHOULD be the date and time of
+   final delivery of the message as defined by [SMTP].  In the case of
+   messages delivered by the IMAP4rev1 COPY command, this SHOULD be the
+   internal date and time of the source message.  In the case of
+   messages delivered by the IMAP4rev1 APPEND command, this SHOULD be
+   the date and time as specified in the APPEND command description.
+   All other cases are implementation defined.
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 10]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+2.3.4.  [RFC-822] Size Message Attribute
+
+   The number of octets in the message, as expressed in [RFC-822]
+   format.
+
+2.3.5.  Envelope Structure Message Attribute
+
+   A parsed representation of the [RFC-822] envelope information (not to
+   be confused with an [SMTP] envelope) of the message.
+
+2.3.6.  Body Structure Message Attribute
+
+   A parsed representation of the [MIME-IMB] body structure information
+   of the message.
+
+2.4.    Message Texts
+
+   In addition to being able to fetch the full [RFC-822] text of a
+   message, IMAP4rev1 permits the fetching of portions of the full
+   message text.  Specifically, it is possible to fetch the [RFC-822]
+   message header, [RFC-822] message body, a [MIME-IMB] body part, or a
+   [MIME-IMB] header.
+
+3.      State and Flow Diagram
+
+   An IMAP4rev1 server is in one of four states.  Most commands are
+   valid in only certain states.  It is a protocol error for the client
+   to attempt a command while the command is in an inappropriate state.
+   In this case, a server will respond with a BAD or NO (depending upon
+   server implementation) command completion result.
+
+3.1.    Non-Authenticated State
+
+   In non-authenticated state, the client MUST supply authentication
+   credentials before most commands will be permitted.  This state is
+   entered when a connection starts unless the connection has been pre-
+   authenticated.
+
+3.2.    Authenticated State
+
+   In authenticated state, the client is authenticated and MUST select a
+   mailbox to access before commands that affect messages will be
+   permitted.  This state is entered when a pre-authenticated connection
+   starts, when acceptable authentication credentials have been
+   provided, or after an error in selecting a mailbox.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 11]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+3.3.    Selected State
+
+   In selected state, a mailbox has been selected to access.  This state
+   is entered when a mailbox has been successfully selected.
+
+3.4.    Logout State
+
+   In logout state, the connection is being terminated, and the server
+   will close the connection.  This state can be entered as a result of
+   a client request or by unilateral server decision.
+
+            +--------------------------------------+
+            |initial connection and server greeting|
+            +--------------------------------------+
+                      || (1)       || (2)        || (3)
+                      VV           ||            ||
+            +-----------------+    ||            ||
+            |non-authenticated|    ||            ||
+            +-----------------+    ||            ||
+             || (7)   || (4)       ||            ||
+             ||       VV           VV            ||
+             ||     +----------------+           ||
+             ||     | authenticated  |<=++       ||
+             ||     +----------------+  ||       ||
+             ||       || (7)   || (5)   || (6)   ||
+             ||       ||       VV       ||       ||
+             ||       ||    +--------+  ||       ||
+             ||       ||    |selected|==++       ||
+             ||       ||    +--------+           ||
+             ||       ||       || (7)            ||
+             VV       VV       VV                VV
+            +--------------------------------------+
+            |     logout and close connection      |
+            +--------------------------------------+
+
+         (1) connection without pre-authentication (OK greeting)
+         (2) pre-authenticated connection (PREAUTH greeting)
+         (3) rejected connection (BYE greeting)
+         (4) successful LOGIN or AUTHENTICATE command
+         (5) successful SELECT or EXAMINE command
+         (6) CLOSE command, or failed SELECT or EXAMINE command
+         (7) LOGOUT command, server shutdown, or connection closed
+
+4.      Data Formats
+
+   IMAP4rev1 uses textual commands and responses.  Data in IMAP4rev1 can
+   be in one of several forms: atom, number, string, parenthesized list,
+   or NIL.
+
+
+
+Crispin                     Standards Track                    [Page 12]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+4.1.    Atom
+
+   An atom consists of one or more non-special characters.
+
+4.2.    Number
+
+   A number consists of one or more digit characters, and represents a
+   numeric value.
+
+4.3.    String
+
+   A string is in one of two forms: literal and quoted string.  The
+   literal form is the general form of string.  The quoted string form
+   is an alternative that avoids the overhead of processing a literal at
+   the cost of limitations of characters that can be used in a quoted
+   string.
+
+   A literal is a sequence of zero or more octets (including CR and LF),
+   prefix-quoted with an octet count in the form of an open brace ("{"),
+   the number of octets, close brace ("}"), and CRLF.  In the case of
+   literals transmitted from server to client, the CRLF is immediately
+   followed by the octet data.  In the case of literals transmitted from
+   client to server, the client MUST wait to receive a command
+   continuation request (described later in this document) before
+   sending the octet data (and the remainder of the command).
+
+   A quoted string is a sequence of zero or more 7-bit characters,
+   excluding CR and LF, with double quote (<">) characters at each end.
+
+   The empty string is represented as either "" (a quoted string with
+   zero characters between double quotes) or as {0} followed by CRLF (a
+   literal with an octet count of 0).
+
+      Note: Even if the octet count is 0, a client transmitting a
+      literal MUST wait to receive a command continuation request.
+
+4.3.1.  8-bit and Binary Strings
+
+   8-bit textual and binary mail is supported through the use of a
+   [MIME-IMB] content transfer encoding.  IMAP4rev1 implementations MAY
+   transmit 8-bit or multi-octet characters in literals, but SHOULD do
+   so only when the [CHARSET] is identified.
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 13]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Although a BINARY body encoding is defined, unencoded binary strings
+   are not permitted.  A "binary string" is any string with NUL
+   characters.  Implementations MUST encode binary data into a textual
+   form such as BASE64 before transmitting the data.  A string with an
+   excessive amount of CTL characters MAY also be considered to be
+   binary.
+
+4.4.    Parenthesized List
+
+   Data structures are represented as a "parenthesized list"; a sequence
+   of data items, delimited by space, and bounded at each end by
+   parentheses.  A parenthesized list can contain other parenthesized
+   lists, using multiple levels of parentheses to indicate nesting.
+
+   The empty list is represented as () -- a parenthesized list with no
+   members.
+
+4.5.    NIL
+
+   The special atom "NIL" represents the non-existence of a particular
+   data item that is represented as a string or parenthesized list, as
+   distinct from the empty string "" or the empty parenthesized list ().
+
+5.      Operational Considerations
+
+5.1.    Mailbox Naming
+
+   The interpretation of mailbox names is implementation-dependent.
+   However, the case-insensitive mailbox name INBOX is a special name
+   reserved to mean "the primary mailbox for this user on this server".
+
+5.1.1.  Mailbox Hierarchy Naming
+
+   If it is desired to export hierarchical mailbox names, mailbox names
+   MUST be left-to-right hierarchical using a single character to
+   separate levels of hierarchy.  The same hierarchy separator character
+   is used for all levels of hierarchy within a single name.
+
+5.1.2.  Mailbox Namespace Naming Convention
+
+   By convention, the first hierarchical element of any mailbox name
+   which begins with "#" identifies the "namespace" of the remainder of
+   the name.  This makes it possible to disambiguate between different
+   types of mailbox stores, each of which have their own namespaces.
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 14]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      For example, implementations which offer access to USENET
+      newsgroups MAY use the "#news" namespace to partition the USENET
+      newsgroup namespace from that of other mailboxes.  Thus, the
+      comp.mail.misc newsgroup would have an mailbox name of
+      "#news.comp.mail.misc", and the name "comp.mail.misc" could refer
+      to a different object (e.g. a user's private mailbox).
+
+5.1.3.  Mailbox International Naming Convention
+
+   By convention, international mailbox names are specified using a
+   modified version of the UTF-7 encoding described in [UTF-7].  The
+   purpose of these modifications is to correct the following problems
+   with UTF-7:
+
+      1) UTF-7 uses the "+" character for shifting; this conflicts with
+         the common use of "+" in mailbox names, in particular USENET
+         newsgroup names.
+
+      2) UTF-7's encoding is BASE64 which uses the "/" character; this
+         conflicts with the use of "/" as a popular hierarchy delimiter.
+
+      3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
+         the use of "\" as a popular hierarchy delimiter.
+
+      4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
+         the use of "~" in some servers as a home directory indicator.
+
+      5) UTF-7 permits multiple alternate forms to represent the same
+         string; in particular, printable US-ASCII chararacters can be
+         represented in encoded form.
+
+   In modified UTF-7, printable US-ASCII characters except for "&"
+   represent themselves; that is, characters with octet values 0x20-0x25
+   and 0x27-0x7e.  The character "&" (0x26) is represented by the two-
+   octet sequence "&-".
+
+   All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all
+   Unicode 16-bit octets) are represented in modified BASE64, with a
+   further modification from [UTF-7] that "," is used instead of "/".
+   Modified BASE64 MUST NOT be used to represent any printing US-ASCII
+   character which can represent itself.
+
+   "&" is used to shift to modified BASE64 and "-" to shift back to US-
+   ASCII.  All names start in US-ASCII, and MUST end in US-ASCII (that
+   is, a name that ends with a Unicode 16-bit octet MUST end with a "-
+   ").
+
+
+
+
+
+Crispin                     Standards Track                    [Page 15]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      For example, here is a mailbox name which mixes English, Japanese,
+      and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw-
+
+5.2.    Mailbox Size and Message Status Updates
+
+   At any time, a server can send data that the client did not request.
+   Sometimes, such behavior is REQUIRED.  For example, agents other than
+   the server MAY add messages to the mailbox (e.g. new mail delivery),
+   change the flags of message in the mailbox (e.g. simultaneous access
+   to the same mailbox by multiple agents), or even remove messages from
+   the mailbox.  A server MUST send mailbox size updates automatically
+   if a mailbox size change is observed during the processing of a
+   command.  A server SHOULD send message flag updates automatically,
+   without requiring the client to request such updates explicitly.
+   Special rules exist for server notification of a client about the
+   removal of messages to prevent synchronization errors; see the
+   description of the EXPUNGE response for more detail.
+
+   Regardless of what implementation decisions a client makes on
+   remembering data from the server, a client implementation MUST record
+   mailbox size updates.  It MUST NOT assume that any command after
+   initial mailbox selection will return the size of the mailbox.
+
+5.3.    Response when no Command in Progress
+
+   Server implementations are permitted to send an untagged response
+   (except for EXPUNGE) while there is no command in progress.  Server
+   implementations that send such responses MUST deal with flow control
+   considerations.  Specifically, they MUST either (1) verify that the
+   size of the data does not exceed the underlying transport's available
+   window size, or (2) use non-blocking writes.
+
+5.4.    Autologout Timer
+
+   If a server has an inactivity autologout timer, that timer MUST be of
+   at least 30 minutes' duration.  The receipt of ANY command from the
+   client during that interval SHOULD suffice to reset the autologout
+   timer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 16]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+5.5.    Multiple Commands in Progress
+
+   The client MAY send another command without waiting for the
+   completion result response of a command, subject to ambiguity rules
+   (see below) and flow control constraints on the underlying data
+   stream.  Similarly, a server MAY begin processing another command
+   before processing the current command to completion, subject to
+   ambiguity rules.  However, any command continuation request responses
+   and command continuations MUST be negotiated before any subsequent
+   command is initiated.
+
+   The exception is if an ambiguity would result because of a command
+   that would affect the results of other commands.  Clients MUST NOT
+   send multiple commands without waiting if an ambiguity would result.
+   If the server detects a possible ambiguity, it MUST execute commands
+   to completion in the order given by the client.
+
+   The most obvious example of ambiguity is when a command would affect
+   the results of another command; for example, a FETCH of a message's
+   flags and a STORE of that same message's flags.
+
+   A non-obvious ambiguity occurs with commands that permit an untagged
+   EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
+   since an untagged EXPUNGE response can invalidate sequence numbers in
+   a subsequent command.  This is not a problem for FETCH, STORE, or
+   SEARCH commands because servers are prohibited from sending EXPUNGE
+   responses while any of those commands are in progress.  Therefore, if
+   the client sends any command other than FETCH, STORE, or SEARCH, it
+   MUST wait for a response before sending a command with message
+   sequence numbers.
+
+   For example, the following non-waiting command sequences are invalid:
+
+      FETCH + NOOP + STORE
+      STORE + COPY + FETCH
+      COPY + COPY
+      CHECK + FETCH
+
+   The following are examples of valid non-waiting command sequences:
+
+      FETCH + STORE + SEARCH + CHECK
+      STORE + COPY + EXPUNGE
+
+6.      Client Commands
+
+   IMAP4rev1 commands are described in this section.  Commands are
+   organized by the state in which the command is permitted.  Commands
+   which are permitted in multiple states are listed in the minimum
+
+
+
+Crispin                     Standards Track                    [Page 17]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   permitted state (for example, commands valid in authenticated and
+   selected state are listed in the authenticated state commands).
+
+   Command arguments, identified by "Arguments:" in the command
+   descriptions below, are described by function, not by syntax.  The
+   precise syntax of command arguments is described in the Formal Syntax
+   section.
+
+   Some commands cause specific server responses to be returned; these
+   are identified by "Responses:" in the command descriptions below.
+   See the response descriptions in the Responses section for
+   information on these responses, and the Formal Syntax section for the
+   precise syntax of these responses.  It is possible for server data to
+   be transmitted as a result of any command; thus, commands that do not
+   specifically require server data specify "no specific responses for
+   this command" instead of "none".
+
+   The "Result:" in the command description refers to the possible
+   tagged status responses to a command, and any special interpretation
+   of these status responses.
+
+6.1.    Client Commands - Any State
+
+   The following commands are valid in any state: CAPABILITY, NOOP, and
+   LOGOUT.
+
+6.1.1.  CAPABILITY Command
+
+   Arguments:  none
+
+   Responses:  REQUIRED untagged response: CAPABILITY
+
+   Result:     OK - capability completed
+               BAD - command unknown or arguments invalid
+
+      The CAPABILITY command requests a listing of capabilities that the
+      server supports.  The server MUST send a single untagged
+      CAPABILITY response with "IMAP4rev1" as one of the listed
+      capabilities before the (tagged) OK response.  This listing of
+      capabilities is not dependent upon connection state or user.  It
+      is therefore not necessary to issue a CAPABILITY command more than
+      once in a connection.
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 18]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      A capability name which begins with "AUTH=" indicates that the
+      server supports that particular authentication mechanism.  All
+      such names are, by definition, part of this specification.  For
+      example, the authorization capability for an experimental
+      "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
+      "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
+
+      Other capability names refer to extensions, revisions, or
+      amendments to this specification.  See the documentation of the
+      CAPABILITY response for additional information.  No capabilities,
+      beyond the base IMAP4rev1 set defined in this specification, are
+      enabled without explicit client action to invoke the capability.
+
+      See the section entitled "Client Commands -
+      Experimental/Expansion" for information about the form of site or
+      implementation-specific capabilities.
+
+   Example:    C: abcd CAPABILITY
+               S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4
+               S: abcd OK CAPABILITY completed
+
+6.1.2.  NOOP Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command (but see below)
+
+   Result:     OK - noop completed
+               BAD - command unknown or arguments invalid
+
+      The NOOP command always succeeds.  It does nothing.
+
+      Since any command can return a status update as untagged data, the
+      NOOP command can be used as a periodic poll for new messages or
+      message status updates during a period of inactivity.  The NOOP
+      command can also be used to reset any inactivity autologout timer
+      on the server.
+
+   Example:    C: a002 NOOP
+               S: a002 OK NOOP completed
+                  . . .
+               C: a047 NOOP
+               S: * 22 EXPUNGE
+               S: * 23 EXISTS
+               S: * 3 RECENT
+               S: * 14 FETCH (FLAGS (\Seen \Deleted))
+               S: a047 OK NOOP completed
+
+
+
+
+Crispin                     Standards Track                    [Page 19]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+6.1.3.  LOGOUT Command
+
+   Arguments:  none
+
+   Responses:  REQUIRED untagged response: BYE
+
+   Result:     OK - logout completed
+               BAD - command unknown or arguments invalid
+
+      The LOGOUT command informs the server that the client is done with
+      the connection.  The server MUST send a BYE untagged response
+      before the (tagged) OK response, and then close the network
+      connection.
+
+   Example:    C: A023 LOGOUT
+               S: * BYE IMAP4rev1 Server logging out
+               S: A023 OK LOGOUT completed
+               (Server and client then close the connection)
+
+6.2.    Client Commands - Non-Authenticated State
+
+   In non-authenticated state, the AUTHENTICATE or LOGIN command
+   establishes authentication and enter authenticated state.  The
+   AUTHENTICATE command provides a general mechanism for a variety of
+   authentication techniques, whereas the LOGIN command uses the
+   traditional user name and plaintext password pair.
+
+   Server implementations MAY allow non-authenticated access to certain
+   mailboxes.  The convention is to use a LOGIN command with the userid
+   "anonymous".  A password is REQUIRED.  It is implementation-dependent
+   what requirements, if any, are placed on the password and what access
+   restrictions are placed on anonymous users.
+
+   Once authenticated (including as anonymous), it is not possible to
+   re-enter non-authenticated state.
+
+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+   the following commands are valid in non-authenticated state:
+   AUTHENTICATE and LOGIN.
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 20]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+6.2.1.  AUTHENTICATE Command
+
+   Arguments:  authentication mechanism name
+
+   Responses:  continuation data can be requested
+
+   Result:     OK - authenticate completed, now in authenticated state
+               NO - authenticate failure: unsupported authentication
+                    mechanism, credentials rejected
+              BAD - command unknown or arguments invalid,
+                    authentication exchange cancelled
+
+      The AUTHENTICATE command indicates an authentication mechanism,
+      such as described in [IMAP-AUTH], to the server.  If the server
+      supports the requested authentication mechanism, it performs an
+      authentication protocol exchange to authenticate and identify the
+      client.  It MAY also negotiate an OPTIONAL protection mechanism
+      for subsequent protocol interactions.  If the requested
+      authentication mechanism is not supported, the server SHOULD
+      reject the AUTHENTICATE command by sending a tagged NO response.
+
+      The authentication protocol exchange consists of a series of
+      server challenges and client answers that are specific to the
+      authentication mechanism.  A server challenge consists of a
+      command continuation request response with the "+" token followed
+      by a BASE64 encoded string.  The client answer consists of a line
+      consisting of a BASE64 encoded string.  If the client wishes to
+      cancel an authentication exchange, it issues a line with a single
+      "*".  If the server receives such an answer, it MUST reject the
+      AUTHENTICATE command by sending a tagged BAD response.
+
+      A protection mechanism provides integrity and privacy protection
+      to the connection.  If a protection mechanism is negotiated, it is
+      applied to all subsequent data sent over the connection.  The
+      protection mechanism takes effect immediately following the CRLF
+      that concludes the authentication exchange for the client, and the
+      CRLF of the tagged OK response for the server.  Once the
+      protection mechanism is in effect, the stream of command and
+      response octets is processed into buffers of ciphertext.  Each
+      buffer is transferred over the connection as a stream of octets
+      prepended with a four octet field in network byte order that
+      represents the length of the following data.  The maximum
+      ciphertext buffer length is defined by the protection mechanism.
+
+      Authentication mechanisms are OPTIONAL.  Protection mechanisms are
+      also OPTIONAL; an authentication mechanism MAY be implemented
+      without any protection mechanism.  If an AUTHENTICATE command
+      fails with a NO response, the client MAY try another
+
+
+
+Crispin                     Standards Track                    [Page 21]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      authentication mechanism by issuing another AUTHENTICATE command,
+      or MAY attempt to authenticate by using the LOGIN command.  In
+      other words, the client MAY request authentication types in
+      decreasing order of preference, with the LOGIN command as a last
+      resort.
+
+   Example:    S: * OK KerberosV4 IMAP4rev1 Server
+               C: A001 AUTHENTICATE KERBEROS_V4
+               S: + AmFYig==
+               C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+                  +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+                  WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+               S: + or//EoAADZI=
+               C: DiAF5A4gA+oOIALuBkAAmw==
+               S: A001 OK Kerberos V4 authentication successful
+
+      Note: the line breaks in the first client answer are for editorial
+      clarity and are not in real authenticators.
+
+6.2.2.  LOGIN Command
+
+   Arguments:  user name
+               password
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - login completed, now in authenticated state
+               NO - login failure: user name or password rejected
+               BAD - command unknown or arguments invalid
+
+      The LOGIN command identifies the client to the server and carries
+      the plaintext password authenticating this user.
+
+   Example:    C: a001 LOGIN SMITH SESAME
+               S: a001 OK LOGIN completed
+
+6.3.    Client Commands - Authenticated State
+
+   In authenticated state, commands that manipulate mailboxes as atomic
+   entities are permitted.  Of these commands, the SELECT and EXAMINE
+   commands will select a mailbox for access and enter selected state.
+
+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+   the following commands are valid in authenticated state: SELECT,
+   EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
+   STATUS, and APPEND.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 22]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+6.3.1.  SELECT Command
+
+   Arguments:  mailbox name
+
+   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
+               OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+   Result:     OK - select completed, now in selected state
+               NO - select failure, now in authenticated state: no
+                    such mailbox, can't access mailbox
+               BAD - command unknown or arguments invalid
+
+   The SELECT command selects a mailbox so that messages in the
+   mailbox can be accessed.  Before returning an OK to the client,
+   the server MUST send the following untagged data to the client:
+
+      FLAGS       Defined flags in the mailbox.  See the description
+                  of the FLAGS response for more detail.
+
+      <n> EXISTS  The number of messages in the mailbox.  See the
+                  description of the EXISTS response for more detail.
+
+      <n> RECENT  The number of messages with the \Recent flag set.
+                  See the description of the RECENT response for more
+                  detail.
+
+      OK [UIDVALIDITY <n>]
+                  The unique identifier validity value.  See the
+                  description of the UID command for more detail.
+
+   to define the initial state of the mailbox at the client.
+
+   The server SHOULD also send an UNSEEN response code in an OK
+   untagged response, indicating the message sequence number of the
+   first unseen message in the mailbox.
+
+   If the client can not change the permanent state of one or more of
+   the flags listed in the FLAGS untagged response, the server SHOULD
+   send a PERMANENTFLAGS response code in an OK untagged response,
+   listing the flags that the client can change permanently.
+
+   Only one mailbox can be selected at a time in a connection;
+   simultaneous access to multiple mailboxes requires multiple
+   connections.  The SELECT command automatically deselects any
+   currently selected mailbox before attempting the new selection.
+   Consequently, if a mailbox is selected and a SELECT command that
+   fails is attempted, no mailbox is selected.
+
+
+
+
+Crispin                     Standards Track                    [Page 23]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   If the client is permitted to modify the mailbox, the server
+   SHOULD prefix the text of the tagged OK response with the
+         "[READ-WRITE]" response code.
+
+      If the client is not permitted to modify the mailbox but is
+      permitted read access, the mailbox is selected as read-only, and
+      the server MUST prefix the text of the tagged OK response to
+      SELECT with the "[READ-ONLY]" response code.  Read-only access
+      through SELECT differs from the EXAMINE command in that certain
+      read-only mailboxes MAY permit the change of permanent state on a
+      per-user (as opposed to global) basis.  Netnews messages marked in
+      a server-based .newsrc file are an example of such per-user
+      permanent state that can be modified with read-only mailboxes.
+
+   Example:    C: A142 SELECT INBOX
+               S: * 172 EXISTS
+               S: * 1 RECENT
+               S: * OK [UNSEEN 12] Message 12 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+               S: A142 OK [READ-WRITE] SELECT completed
+
+6.3.2.  EXAMINE Command
+
+   Arguments:  mailbox name
+
+   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
+               OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+   Result:     OK - examine completed, now in selected state
+               NO - examine failure, now in authenticated state: no
+                    such mailbox, can't access mailbox
+               BAD - command unknown or arguments invalid
+
+      The EXAMINE command is identical to SELECT and returns the same
+      output; however, the selected mailbox is identified as read-only.
+      No changes to the permanent state of the mailbox, including
+      per-user state, are permitted.
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 24]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      The text of the tagged OK response to the EXAMINE command MUST
+      begin with the "[READ-ONLY]" response code.
+
+   Example:    C: A932 EXAMINE blurdybloop
+               S: * 17 EXISTS
+               S: * 2 RECENT
+               S: * OK [UNSEEN 8] Message 8 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
+               S: A932 OK [READ-ONLY] EXAMINE completed
+
+6.3.3.  CREATE Command
+
+   Arguments:  mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - create completed
+               NO - create failure: can't create mailbox with that name
+               BAD - command unknown or arguments invalid
+
+      The CREATE command creates a mailbox with the given name.  An OK
+      response is returned only if a new mailbox with that name has been
+      created.  It is an error to attempt to create INBOX or a mailbox
+      with a name that refers to an extant mailbox.  Any error in
+      creation will return a tagged NO response.
+
+      If the mailbox name is suffixed with the server's hierarchy
+      separator character (as returned from the server by a LIST
+      command), this is a declaration that the client intends to create
+      mailbox names under this name in the hierarchy.  Server
+      implementations that do not require this declaration MUST ignore
+      it.
+
+      If the server's hierarchy separator character appears elsewhere in
+      the name, the server SHOULD create any superior hierarchical names
+      that are needed for the CREATE command to complete successfully.
+      In other words, an attempt to create "foo/bar/zap" on a server in
+      which "/" is the hierarchy separator character SHOULD create foo/
+      and foo/bar/ if they do not already exist.
+
+      If a new mailbox is created with the same name as a mailbox which
+      was deleted, its unique identifiers MUST be greater than any
+      unique identifiers used in the previous incarnation of the mailbox
+      UNLESS the new incarnation has a different unique identifier
+      validity value.  See the description of the UID command for more
+      detail.
+
+
+
+Crispin                     Standards Track                    [Page 25]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Example:    C: A003 CREATE owatagusiam/
+               S: A003 OK CREATE completed
+               C: A004 CREATE owatagusiam/blurdybloop
+               S: A004 OK CREATE completed
+
+      Note: the interpretation of this example depends on whether "/"
+      was returned as the hierarchy separator from LIST.  If "/" is the
+      hierarchy separator, a new level of hierarchy named "owatagusiam"
+      with a member called "blurdybloop" is created.  Otherwise, two
+      mailboxes at the same hierarchy level are created.
+
+6.3.4.  DELETE Command
+
+   Arguments:  mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - delete completed
+               NO - delete failure: can't delete mailbox with that name
+               BAD - command unknown or arguments invalid
+
+      The DELETE command permanently removes the mailbox with the given
+      name.  A tagged OK response is returned only if the mailbox has
+      been deleted.  It is an error to attempt to delete INBOX or a
+      mailbox name that does not exist.
+
+      The DELETE command MUST NOT remove inferior hierarchical names.
+      For example, if a mailbox "foo" has an inferior "foo.bar"
+      (assuming "." is the hierarchy delimiter character), removing
+      "foo" MUST NOT remove "foo.bar".  It is an error to attempt to
+      delete a name that has inferior hierarchical names and also has
+      the \Noselect mailbox name attribute (see the description of the
+      LIST response for more details).
+
+      It is permitted to delete a name that has inferior hierarchical
+      names and does not have the \Noselect mailbox name attribute.  In
+      this case, all messages in that mailbox are removed, and the name
+      will acquire the \Noselect mailbox name attribute.
+
+      The value of the highest-used unique identifier of the deleted
+      mailbox MUST be preserved so that a new mailbox created with the
+      same name will not reuse the identifiers of the former
+      incarnation, UNLESS the new incarnation has a different unique
+      identifier validity value.  See the description of the UID command
+      for more detail.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 26]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Examples:   C: A682 LIST "" *
+               S: * LIST () "/" blurdybloop
+               S: * LIST (\Noselect) "/" foo
+               S: * LIST () "/" foo/bar
+               S: A682 OK LIST completed
+               C: A683 DELETE blurdybloop
+               S: A683 OK DELETE completed
+               C: A684 DELETE foo
+               S: A684 NO Name "foo" has inferior hierarchical names
+               C: A685 DELETE foo/bar
+               S: A685 OK DELETE Completed
+               C: A686 LIST "" *
+               S: * LIST (\Noselect) "/" foo
+               S: A686 OK LIST completed
+               C: A687 DELETE foo
+               S: A687 OK DELETE Completed
+
+
+               C: A82 LIST "" *
+               S: * LIST () "." blurdybloop
+               S: * LIST () "." foo
+               S: * LIST () "." foo.bar
+               S: A82 OK LIST completed
+               C: A83 DELETE blurdybloop
+               S: A83 OK DELETE completed
+               C: A84 DELETE foo
+               S: A84 OK DELETE Completed
+               C: A85 LIST "" *
+               S: * LIST () "." foo.bar
+               S: A85 OK LIST completed
+               C: A86 LIST "" %
+               S: * LIST (\Noselect) "." foo
+               S: A86 OK LIST completed
+
+6.3.5.  RENAME Command
+
+   Arguments:  existing mailbox name
+               new mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - rename completed
+               NO - rename failure: can't rename mailbox with that name,
+                    can't rename to mailbox with that name
+               BAD - command unknown or arguments invalid
+
+      The RENAME command changes the name of a mailbox.  A tagged OK
+      response is returned only if the mailbox has been renamed.  It is
+
+
+
+Crispin                     Standards Track                    [Page 27]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      an error to attempt to rename from a mailbox name that does not
+      exist or to a mailbox name that already exists.  Any error in
+      renaming will return a tagged NO response.
+
+      If the name has inferior hierarchical names, then the inferior
+      hierarchical names MUST also be renamed.  For example, a rename of
+      "foo" to "zap" will rename "foo/bar" (assuming "/" is the
+      hierarchy delimiter character) to "zap/bar".
+
+      The value of the highest-used unique identifier of the old mailbox
+      name MUST be preserved so that a new mailbox created with the same
+      name will not reuse the identifiers of the former incarnation,
+      UNLESS the new incarnation has a different unique identifier
+      validity value.  See the description of the UID command for more
+      detail.
+
+      Renaming INBOX is permitted, and has special behavior.  It moves
+      all messages in INBOX to a new mailbox with the given name,
+      leaving INBOX empty.  If the server implementation supports
+      inferior hierarchical names of INBOX, these are unaffected by a
+      rename of INBOX.
+
+   Examples:   C: A682 LIST "" *
+               S: * LIST () "/" blurdybloop
+               S: * LIST (\Noselect) "/" foo
+               S: * LIST () "/" foo/bar
+               S: A682 OK LIST completed
+               C: A683 RENAME blurdybloop sarasoop
+               S: A683 OK RENAME completed
+               C: A684 RENAME foo zowie
+               S: A684 OK RENAME Completed
+               C: A685 LIST "" *
+               S: * LIST () "/" sarasoop
+               S: * LIST (\Noselect) "/" zowie
+               S: * LIST () "/" zowie/bar
+               S: A685 OK LIST completed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 28]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+               C: Z432 LIST "" *
+               S: * LIST () "." INBOX
+               S: * LIST () "." INBOX.bar
+               S: Z432 OK LIST completed
+               C: Z433 RENAME INBOX old-mail
+               S: Z433 OK RENAME completed
+               C: Z434 LIST "" *
+               S: * LIST () "." INBOX
+               S: * LIST () "." INBOX.bar
+               S: * LIST () "." old-mail
+               S: Z434 OK LIST completed
+
+6.3.6.  SUBSCRIBE Command
+
+   Arguments:  mailbox
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - subscribe completed
+               NO - subscribe failure: can't subscribe to that name
+               BAD - command unknown or arguments invalid
+
+      The SUBSCRIBE command adds the specified mailbox name to the
+      server's set of "active" or "subscribed" mailboxes as returned by
+      the LSUB command.  This command returns a tagged OK response only
+      if the subscription is successful.
+
+      A server MAY validate the mailbox argument to SUBSCRIBE to verify
+      that it exists.  However, it MUST NOT unilaterally remove an
+      existing mailbox name from the subscription list even if a mailbox
+      by that name no longer exists.
+
+      Note: this requirement is because some server sites may routinely
+      remove a mailbox with a well-known name (e.g.  "system-alerts")
+      after its contents expire, with the intention of recreating it
+      when new contents are appropriate.
+
+   Example:    C: A002 SUBSCRIBE #news.comp.mail.mime
+               S: A002 OK SUBSCRIBE completed
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 29]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+6.3.7.  UNSUBSCRIBE Command
+
+   Arguments:  mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - unsubscribe completed
+               NO - unsubscribe failure: can't unsubscribe that name
+               BAD - command unknown or arguments invalid
+
+      The UNSUBSCRIBE command removes the specified mailbox name from
+      the server's set of "active" or "subscribed" mailboxes as returned
+      by the LSUB command.  This command returns a tagged OK response
+      only if the unsubscription is successful.
+
+   Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime
+               S: A002 OK UNSUBSCRIBE completed
+
+6.3..8.  LIST Command
+
+   Arguments:  reference name
+               mailbox name with possible wildcards
+
+   Responses:  untagged responses: LIST
+
+   Result:     OK - list completed
+               NO - list failure: can't list that reference or name
+               BAD - command unknown or arguments invalid
+
+      The LIST command returns a subset of names from the complete set
+      of all names available to the client.  Zero or more untagged LIST
+      replies are returned, containing the name attributes, hierarchy
+      delimiter, and name; see the description of the LIST reply for
+      more detail.
+
+      The LIST command SHOULD return its data quickly, without undue
+      delay.  For example, it SHOULD NOT go to excess trouble to
+      calculate \Marked or \Unmarked status or perform other processing;
+      if each name requires 1 second of processing, then a list of 1200
+      names would take 20 minutes!
+
+      An empty ("" string) reference name argument indicates that the
+      mailbox name is interpreted as by SELECT. The returned mailbox
+      names MUST match the supplied mailbox name pattern.  A non-empty
+      reference name argument is the name of a mailbox or a level of
+      mailbox hierarchy, and indicates a context in which the mailbox
+      name is interpreted in an implementation-defined manner.
+
+
+
+
+Crispin                     Standards Track                    [Page 30]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      An empty ("" string) mailbox name argument is a special request to
+      return the hierarchy delimiter and the root name of the name given
+      in the reference.  The value returned as the root MAY be null if
+      the reference is non-rooted or is null.  In all cases, the
+      hierarchy delimiter is returned.  This permits a client to get the
+      hierarchy delimiter even when no mailboxes by that name currently
+      exist.
+
+      The reference and mailbox name arguments are interpreted, in an
+      implementation-dependent fashion, into a canonical form that
+      represents an unambiguous left-to-right hierarchy.  The returned
+      mailbox names will be in the interpreted form.
+
+      Any part of the reference argument that is included in the
+      interpreted form SHOULD prefix the interpreted form.  It SHOULD
+      also be in the same form as the reference name argument.  This
+      rule permits the client to determine if the returned mailbox name
+      is in the context of the reference argument, or if something about
+      the mailbox argument overrode the reference argument.  Without
+      this rule, the client would have to have knowledge of the server's
+      naming semantics including what characters are "breakouts" that
+      override a naming context.
+
+      For example, here are some examples of how references and mailbox
+      names might be interpreted on a UNIX-based server:
+
+               Reference     Mailbox Name  Interpretation
+               ------------  ------------  --------------
+               ~smith/Mail/  foo.*         ~smith/Mail/foo.*
+               archive/      %             archive/%
+               #news.        comp.mail.*   #news.comp.mail.*
+               ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
+               archive/      ~fred/Mail/*  ~fred/Mail/*
+
+      The first three examples demonstrate interpretations in the
+      context of the reference argument.  Note that "~smith/Mail" SHOULD
+      NOT be transformed into something like "/u2/users/smith/Mail", or
+      it would be impossible for the client to determine that the
+      interpretation was in the context of the reference.
+
+      The character "*" is a wildcard, and matches zero or more
+      characters at this position.  The character "%" is similar to "*",
+      but it does not match a hierarchy delimiter.  If the "%" wildcard
+      is the last character of a mailbox name argument, matching levels
+      of hierarchy are also returned.  If these levels of hierarchy are
+      not also selectable mailboxes, they are returned with the
+      \Noselect mailbox name attribute (see the description of the LIST
+      response for more details).
+
+
+
+Crispin                     Standards Track                    [Page 31]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      Server implementations are permitted to "hide" otherwise
+      accessible mailboxes from the wildcard characters, by preventing
+      certain characters or names from matching a wildcard in certain
+      situations.  For example, a UNIX-based server might restrict the
+      interpretation of "*" so that an initial "/" character does not
+      match.
+
+      The special name INBOX is included in the output from LIST, if
+      INBOX is supported by this server for this user and if the
+      uppercase string "INBOX" matches the interpreted reference and
+      mailbox name arguments with wildcards as described above.  The
+      criteria for omitting INBOX is whether SELECT INBOX will return
+      failure; it is not relevant whether the user's real INBOX resides
+      on this or some other server.
+
+   Example:    C: A101 LIST "" ""
+               S: * LIST (\Noselect) "/" ""
+               S: A101 OK LIST Completed
+               C: A102 LIST #news.comp.mail.misc ""
+               S: * LIST (\Noselect) "." #news.
+               S: A102 OK LIST Completed
+               C: A103 LIST /usr/staff/jones ""
+               S: * LIST (\Noselect) "/" /
+               S: A103 OK LIST Completed
+               C: A202 LIST ~/Mail/ %
+               S: * LIST (\Noselect) "/" ~/Mail/foo
+               S: * LIST () "/" ~/Mail/meetings
+               S: A202 OK LIST completed
+
+6.3.9.  LSUB Command
+
+   Arguments:  reference name
+               mailbox name with possible wildcards
+
+   Responses:  untagged responses: LSUB
+
+   Result:     OK - lsub completed
+               NO - lsub failure: can't list that reference or name
+               BAD - command unknown or arguments invalid
+
+      The LSUB command returns a subset of names from the set of names
+      that the user has declared as being "active" or "subscribed".
+      Zero or more untagged LSUB replies are returned.  The arguments to
+      LSUB are in the same form as those for LIST.
+
+      A server MAY validate the subscribed names to see if they still
+      exist.  If a name does not exist, it SHOULD be flagged with the
+      \Noselect attribute in the LSUB response.  The server MUST NOT
+
+
+
+Crispin                     Standards Track                    [Page 32]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      unilaterally remove an existing mailbox name from the subscription
+      list even if a mailbox by that name no longer exists.
+
+   Example:    C: A002 LSUB "#news." "comp.mail.*"
+               S: * LSUB () "." #news.comp.mail.mime
+               S: * LSUB () "." #news.comp.mail.misc
+               S: A002 OK LSUB completed
+
+6.3.10. STATUS Command
+
+   Arguments:  mailbox name
+               status data item names
+
+   Responses:  untagged responses: STATUS
+
+   Result:     OK - status completed
+               NO - status failure: no status for that name
+               BAD - command unknown or arguments invalid
+
+      The STATUS command requests the status of the indicated mailbox.
+      It does not change the currently selected mailbox, nor does it
+      affect the state of any messages in the queried mailbox (in
+      particular, STATUS MUST NOT cause messages to lose the \Recent
+      flag).
+
+      The STATUS command provides an alternative to opening a second
+      IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
+      query that mailbox's status without deselecting the current
+      mailbox in the first IMAP4rev1 connection.
+
+      Unlike the LIST command, the STATUS command is not guaranteed to
+      be fast in its response.  In some implementations, the server is
+      obliged to open the mailbox read-only internally to obtain certain
+      status information.  Also unlike the LIST command, the STATUS
+      command does not accept wildcards.
+
+      The currently defined status data items that can be requested are:
+
+      MESSAGES       The number of messages in the mailbox.
+
+      RECENT         The number of messages with the \Recent flag set.
+
+      UIDNEXT        The next UID value that will be assigned to a new
+                     message in the mailbox.  It is guaranteed that this
+                     value will not change unless new messages are added
+                     to the mailbox; and that it will change when new
+                     messages are added even if those new messages are
+                     subsequently expunged.
+
+
+
+Crispin                     Standards Track                    [Page 33]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      UIDVALIDITY    The unique identifier validity value of the
+                     mailbox.
+
+      UNSEEN         The number of messages which do not have the \Seen
+                     flag set.
+
+
+      Example:    C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
+                  S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
+                  S: A042 OK STATUS completed
+
+6.3.11. APPEND Command
+
+   Arguments:  mailbox name
+               OPTIONAL flag parenthesized list
+               OPTIONAL date/time string
+               message literal
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - append completed
+               NO - append error: can't append to that mailbox, error
+                    in flags or date/time or message text
+               BAD - command unknown or arguments invalid
+
+      The APPEND command appends the literal argument as a new message
+      to the end of the specified destination mailbox.  This argument
+      SHOULD be in the format of an [RFC-822] message.  8-bit characters
+      are permitted in the message.  A server implementation that is
+      unable to preserve 8-bit data properly MUST be able to reversibly
+      convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content
+      transfer encoding.
+
+      Note: There MAY be exceptions, e.g. draft messages, in which
+      required [RFC-822] header lines are omitted in the message literal
+      argument to APPEND.  The full implications of doing so MUST be
+      understood and carefully weighed.
+
+   If a flag parenthesized list is specified, the flags SHOULD be set in
+   the resulting message; otherwise, the flag list of the resulting
+   message is set empty by default.
+
+   If a date_time is specified, the internal date SHOULD be set in the
+   resulting message; otherwise, the internal date of the resulting
+   message is set to the current date and time by default.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 34]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   If the append is unsuccessful for any reason, the mailbox MUST be
+   restored to its state before the APPEND attempt; no partial appending
+   is permitted.
+
+   If the destination mailbox does not exist, a server MUST return an
+   error, and MUST NOT automatically create the mailbox.  Unless it is
+   certain that the destination mailbox can not be created, the server
+   MUST send the response code "[TRYCREATE]" as the prefix of the text
+   of the tagged NO response.  This gives a hint to the client that it
+   can attempt a CREATE command and retry the APPEND if the CREATE is
+   successful.
+
+   If the mailbox is currently selected, the normal new mail actions
+   SHOULD occur.  Specifically, the server SHOULD notify the client
+   immediately via an untagged EXISTS response.  If the server does not
+   do so, the client MAY issue a NOOP command (or failing that, a CHECK
+   command) after one or more APPEND commands.
+
+   Example:    C: A003 APPEND saved-messages (\Seen) {310}
+               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+               C: From: Fred Foobar <foobar@Blurdybloop.COM>
+               C: Subject: afternoon meeting
+               C: To: mooch@owatagu.siam.edu
+               C: Message-Id: <B27397-0100000@Blurdybloop.COM>
+               C: MIME-Version: 1.0
+               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+               C:
+               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+               C:
+               S: A003 OK APPEND completed
+
+      Note: the APPEND command is not used for message delivery, because
+      it does not provide a mechanism to transfer [SMTP] envelope
+      information.
+
+6.4.    Client Commands - Selected State
+
+   In selected state, commands that manipulate messages in a mailbox are
+   permitted.
+
+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+   and the authenticated state commands (SELECT, EXAMINE, CREATE,
+   DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
+   APPEND), the following commands are valid in the selected state:
+   CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 35]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+6.4.1.  CHECK Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - check completed
+               BAD - command unknown or arguments invalid
+
+      The CHECK command requests a checkpoint of the currently selected
+      mailbox.  A checkpoint refers to any implementation-dependent
+      housekeeping associated with the mailbox (e.g. resolving the
+      server's in-memory state of the mailbox with the state on its
+      disk) that is not normally executed as part of each command.  A
+      checkpoint MAY take a non-instantaneous amount of real time to
+      complete.  If a server implementation has no such housekeeping
+      considerations, CHECK is equivalent to NOOP.
+
+      There is no guarantee that an EXISTS untagged response will happen
+      as a result of CHECK.  NOOP, not CHECK, SHOULD be used for new
+      mail polling.
+
+   Example:    C: FXXZ CHECK
+               S: FXXZ OK CHECK Completed
+
+6.4.2.  CLOSE Command
+
+   Arguments:  none
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - close completed, now in authenticated state
+               NO - close failure: no mailbox selected
+               BAD - command unknown or arguments invalid
+
+      The CLOSE command permanently removes from the currently selected
+      mailbox all messages that have the \Deleted flag set, and returns
+      to authenticated state from selected state.  No untagged EXPUNGE
+      responses are sent.
+
+      No messages are removed, and no error is given, if the mailbox is
+      selected by an EXAMINE command or is otherwise selected read-only.
+
+      Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
+      command MAY be issued without previously issuing a CLOSE command.
+      The SELECT, EXAMINE, and LOGOUT commands implicitly close the
+      currently selected mailbox without doing an expunge.  However,
+      when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
+
+
+
+Crispin                     Standards Track                    [Page 36]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      sequence is considerably faster than an EXPUNGE-LOGOUT or
+      EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
+      client would probably ignore) are sent.
+
+   Example:    C: A341 CLOSE
+               S: A341 OK CLOSE completed
+
+6.4.3.  EXPUNGE Command
+
+   Arguments:  none
+
+   Responses:  untagged responses: EXPUNGE
+
+   Result:     OK - expunge completed
+               NO - expunge failure: can't expunge (e.g. permission
+                    denied)
+               BAD - command unknown or arguments invalid
+
+      The EXPUNGE command permanently removes from the currently
+      selected mailbox all messages that have the \Deleted flag set.
+      Before returning an OK to the client, an untagged EXPUNGE response
+      is sent for each message that is removed.
+
+   Example:    C: A202 EXPUNGE
+               S: * 3 EXPUNGE
+               S: * 3 EXPUNGE
+               S: * 5 EXPUNGE
+               S: * 8 EXPUNGE
+               S: A202 OK EXPUNGE completed
+
+      Note: in this example, messages 3, 4, 7, and 11 had the
+      \Deleted flag set.  See the description of the EXPUNGE
+      response for further explanation.
+
+6.4.4.  SEARCH Command
+
+   Arguments:  OPTIONAL [CHARSET] specification
+               searching criteria (one or more)
+
+   Responses:  REQUIRED untagged response: SEARCH
+
+   Result:     OK - search completed
+               NO - search error: can't search that [CHARSET] or
+                    criteria
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 37]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      The SEARCH command searches the mailbox for messages that match
+      the given searching criteria.  Searching criteria consist of one
+      or more search keys.  The untagged SEARCH response from the server
+      contains a listing of message sequence numbers corresponding to
+      those messages that match the searching criteria.
+
+      When multiple keys are specified, the result is the intersection
+      (AND function) of all the messages that match those keys.  For
+      example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
+      to all deleted messages from Smith that were placed in the mailbox
+      since February 1, 1994.  A search key can also be a parenthesized
+      list of one or more search keys (e.g. for use with the OR and NOT
+      keys).
+
+      Server implementations MAY exclude [MIME-IMB] body parts with
+      terminal content media types other than TEXT and MESSAGE from
+      consideration in SEARCH matching.
+
+      The OPTIONAL [CHARSET] specification consists of the word
+      "CHARSET" followed by a registered [CHARSET].  It indicates the
+      [CHARSET] of the strings that appear in the search criteria.
+      [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
+      [RFC-822]/[MIME-IMB] headers, MUST be decoded before comparing
+      text in a [CHARSET] other than US-ASCII.  US-ASCII MUST be
+      supported; other [CHARSET]s MAY be supported.  If the server does
+      not support the specified [CHARSET], it MUST return a tagged NO
+      response (not a BAD).
+
+      In all search keys that use strings, a message matches the key if
+      the string is a substring of the field.  The matching is case-
+      insensitive.
+
+      The defined search keys are as follows.  Refer to the Formal
+      Syntax section for the precise syntactic definitions of the
+      arguments.
+
+      <message set>  Messages with message sequence numbers
+                     corresponding to the specified message sequence
+                     number set
+
+      ALL            All messages in the mailbox; the default initial
+                     key for ANDing.
+
+      ANSWERED       Messages with the \Answered flag set.
+
+      BCC <string>   Messages that contain the specified string in the
+                     envelope structure's BCC field.
+
+
+
+
+Crispin                     Standards Track                    [Page 38]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      BEFORE <date>  Messages whose internal date is earlier than the
+                     specified date.
+
+      BODY <string>  Messages that contain the specified string in the
+                     body of the message.
+
+      CC <string>    Messages that contain the specified string in the
+                     envelope structure's CC field.
+
+      DELETED        Messages with the \Deleted flag set.
+
+      DRAFT          Messages with the \Draft flag set.
+
+      FLAGGED        Messages with the \Flagged flag set.
+
+      FROM <string>  Messages that contain the specified string in the
+                     envelope structure's FROM field.
+
+      HEADER <field-name> <string>
+                     Messages that have a header with the specified
+                     field-name (as defined in [RFC-822]) and that
+                     contains the specified string in the [RFC-822]
+                     field-body.
+
+      KEYWORD <flag> Messages with the specified keyword set.
+
+      LARGER <n>     Messages with an [RFC-822] size larger than the
+                     specified number of octets.
+
+      NEW            Messages that have the \Recent flag set but not the
+                     \Seen flag.  This is functionally equivalent to
+                     "(RECENT UNSEEN)".
+
+      NOT <search-key>
+                     Messages that do not match the specified search
+                     key.
+
+      OLD            Messages that do not have the \Recent flag set.
+                     This is functionally equivalent to "NOT RECENT" (as
+                     opposed to "NOT NEW").
+
+      ON <date>      Messages whose internal date is within the
+                     specified date.
+
+      OR <search-key1> <search-key2>
+                     Messages that match either search key.
+
+      RECENT         Messages that have the \Recent flag set.
+
+
+
+Crispin                     Standards Track                    [Page 39]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      SEEN           Messages that have the \Seen flag set.
+
+      SENTBEFORE <date>
+                     Messages whose [RFC-822] Date: header is earlier
+                     than the specified date.
+
+      SENTON <date>  Messages whose [RFC-822] Date: header is within the
+                     specified date.
+
+      SENTSINCE <date>
+                     Messages whose [RFC-822] Date: header is within or
+                     later than the specified date.
+
+      SINCE <date>   Messages whose internal date is within or later
+                     than the specified date.
+
+      SMALLER <n>    Messages with an [RFC-822] size smaller than the
+                     specified number of octets.
+
+      SUBJECT <string>
+                     Messages that contain the specified string in the
+                     envelope structure's SUBJECT field.
+
+      TEXT <string>  Messages that contain the specified string in the
+                     header or body of the message.
+
+      TO <string>    Messages that contain the specified string in the
+                     envelope structure's TO field.
+
+      UID <message set>
+                     Messages with unique identifiers corresponding to
+                     the specified unique identifier set.
+
+      UNANSWERED     Messages that do not have the \Answered flag set.
+
+      UNDELETED      Messages that do not have the \Deleted flag set.
+
+      UNDRAFT        Messages that do not have the \Draft flag set.
+
+      UNFLAGGED      Messages that do not have the \Flagged flag set.
+
+      UNKEYWORD <flag>
+                     Messages that do not have the specified keyword
+                     set.
+
+      UNSEEN         Messages that do not have the \Seen flag set.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 40]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
+               S: * SEARCH 2 84 882
+               S: A282 OK SEARCH completed
+
+6.4.5.  FETCH Command
+
+   Arguments:  message set
+               message data item names
+
+   Responses:  untagged responses: FETCH
+
+   Result:     OK - fetch completed
+               NO - fetch error: can't fetch that data
+               BAD - command unknown or arguments invalid
+
+      The FETCH command retrieves data associated with a message in the
+      mailbox.  The data items to be fetched can be either a single atom
+      or a parenthesized list.
+
+      The currently defined data items that can be fetched are:
+
+      ALL            Macro equivalent to: (FLAGS INTERNALDATE
+                     RFC822.SIZE ENVELOPE)
+
+      BODY           Non-extensible form of BODYSTRUCTURE.
+
+      BODY[<section>]<<partial>>
+                     The text of a particular body section.  The section
+                     specification is a set of zero or more part
+                     specifiers delimited by periods.  A part specifier
+                     is either a part number or one of the following:
+                     HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and
+                     TEXT.  An empty section specification refers to the
+                     entire message, including the header.
+
+                     Every message has at least one part number.
+                     Non-[MIME-IMB] messages, and non-multipart
+                     [MIME-IMB] messages with no encapsulated message,
+                     only have a part 1.
+
+                     Multipart messages are assigned consecutive part
+                     numbers, as they occur in the message.  If a
+                     particular part is of type message or multipart,
+                     its parts MUST be indicated by a period followed by
+                     the part number within that nested multipart part.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 41]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+                     A part of type MESSAGE/RFC822 also has nested part
+                     numbers, referring to parts of the MESSAGE part's
+                     body.
+
+                     The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and
+                     TEXT part specifiers can be the sole part specifier
+                     or can be prefixed by one or more numeric part
+                     specifiers, provided that the numeric part
+                     specifier refers to a part of type MESSAGE/RFC822.
+                     The MIME part specifier MUST be prefixed by one or
+                     more numeric part specifiers.
+
+                     The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT
+                     part specifiers refer to the [RFC-822] header of
+                     the message or of an encapsulated [MIME-IMT]
+                     MESSAGE/RFC822 message.  HEADER.FIELDS and
+                     HEADER.FIELDS.NOT are followed by a list of
+                     field-name (as defined in [RFC-822]) names, and
+                     return a subset of the header.  The subset returned
+                     by HEADER.FIELDS contains only those header fields
+                     with a field-name that matches one of the names in
+                     the list; similarly, the subset returned by
+                     HEADER.FIELDS.NOT contains only the header fields
+                     with a non-matching field-name.  The field-matching
+                     is case-insensitive but otherwise exact.  In all
+                     cases, the delimiting blank line between the header
+                     and the body is always included.
+
+                     The MIME part specifier refers to the [MIME-IMB]
+                     header for this part.
+
+                     The TEXT part specifier refers to the text body of
+                     the message, omitting the [RFC-822] header.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 42]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+                       Here is an example of a complex message
+                       with some of its part specifiers:
+
+                        HEADER     ([RFC-822] header of the message)
+                        TEXT       MULTIPART/MIXED
+                        1          TEXT/PLAIN
+                        2          APPLICATION/OCTET-STREAM
+                        3          MESSAGE/RFC822
+                        3.HEADER   ([RFC-822] header of the message)
+                        3.TEXT     ([RFC-822] text body of the message)
+                        3.1        TEXT/PLAIN
+                        3.2        APPLICATION/OCTET-STREAM
+                        4          MULTIPART/MIXED
+                        4.1        IMAGE/GIF
+                        4.1.MIME   ([MIME-IMB] header for the IMAGE/GIF)
+                        4.2        MESSAGE/RFC822
+                        4.2.HEADER ([RFC-822] header of the message)
+                        4.2.TEXT   ([RFC-822] text body of the message)
+                        4.2.1      TEXT/PLAIN
+                        4.2.2      MULTIPART/ALTERNATIVE
+                        4.2.2.1    TEXT/PLAIN
+                        4.2.2.2    TEXT/RICHTEXT
+
+
+                     It is possible to fetch a substring of the
+                     designated text.  This is done by appending an open
+                     angle bracket ("<"), the octet position of the
+                     first desired octet, a period, the maximum number
+                     of octets desired, and a close angle bracket (">")
+                     to the part specifier.  If the starting octet is
+                     beyond the end of the text, an empty string is
+                     returned.
+
+                     Any partial fetch that attempts to read beyond the
+                     end of the text is truncated as appropriate.  A
+                     partial fetch that starts at octet 0 is returned as
+                     a partial fetch, even if this truncation happened.
+
+                          Note: this means that BODY[]<0.2048> of a
+                          1500-octet message will return BODY[]<0>
+                          with a literal of size 1500, not BODY[].
+
+                          Note: a substring fetch of a
+                          HEADER.FIELDS or HEADER.FIELDS.NOT part
+                          specifier is calculated after subsetting
+                          the header.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 43]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+                     The \Seen flag is implicitly set; if this causes
+                     the flags to change they SHOULD be included as part
+                     of the FETCH responses.
+
+      BODY.PEEK[<section>]<<partial>> An alternate form of
+                     BODY[<section>] that does not implicitly set the
+                     \Seen flag.
+
+      BODYSTRUCTURE  The [MIME-IMB] body structure of the message.  This
+                     is computed by the server by parsing the [MIME-IMB]
+                     header fields in the [RFC-822] header and
+                     [MIME-IMB] headers.
+
+      ENVELOPE       The envelope structure of the message.  This is
+                     computed by the server by parsing the [RFC-822]
+                     header into the component parts, defaulting various
+                     fields as necessary.
+
+      FAST           Macro equivalent to: (FLAGS INTERNALDATE
+                     RFC822.SIZE)
+
+      FLAGS          The flags that are set for this message.
+
+      FULL           Macro equivalent to: (FLAGS INTERNALDATE
+                     RFC822.SIZE ENVELOPE BODY)
+
+      INTERNALDATE   The internal date of the message.
+
+      RFC822         Functionally equivalent to BODY[], differing in the
+                     syntax of the resulting untagged FETCH data (RFC822
+                     is returned).
+
+      RFC822.HEADER  Functionally equivalent to BODY.PEEK[HEADER],
+                     differing in the syntax of the resulting untagged
+                     FETCH data (RFC822.HEADER is returned).
+
+      RFC822.SIZE    The [RFC-822] size of the message.
+
+      RFC822.TEXT    Functionally equivalent to BODY[TEXT], differing in
+                     the syntax of the resulting untagged FETCH data
+                     (RFC822.TEXT is returned).
+
+      UID            The unique identifier for the message.
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 44]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Example:    C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
+               S: * 2 FETCH ....
+               S: * 3 FETCH ....
+               S: * 4 FETCH ....
+               S: A654 OK FETCH completed
+
+6.4.6.  STORE Command
+
+   Arguments:  message set
+               message data item name
+               value for message data item
+
+   Responses:  untagged responses: FETCH
+
+   Result:     OK - store completed
+               NO - store error: can't store that data
+               BAD - command unknown or arguments invalid
+
+      The STORE command alters data associated with a message in the
+      mailbox.  Normally, STORE will return the updated value of the
+      data with an untagged FETCH response.  A suffix of ".SILENT" in
+      the data item name prevents the untagged FETCH, and the server
+      SHOULD assume that the client has determined the updated value
+      itself or does not care about the updated value.
+
+         Note: regardless of whether or not the ".SILENT" suffix was
+         used, the server SHOULD send an untagged FETCH response if a
+         change to a message's flags from an external source is
+         observed.  The intent is that the status of the flags is
+         determinate without a race condition.
+
+      The currently defined data items that can be stored are:
+
+      FLAGS <flag list>
+                     Replace the flags for the message with the
+                     argument.  The new value of the flags are returned
+                     as if a FETCH of those flags was done.
+
+      FLAGS.SILENT <flag list>
+                     Equivalent to FLAGS, but without returning a new
+                     value.
+
+      +FLAGS <flag list>
+                     Add the argument to the flags for the message.  The
+                     new value of the flags are returned as if a FETCH
+                     of those flags was done.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 45]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      +FLAGS.SILENT <flag list>
+                     Equivalent to +FLAGS, but without returning a new
+                     value.
+
+      -FLAGS <flag list>
+                     Remove the argument from the flags for the message.
+                     The new value of the flags are returned as if a
+                     FETCH of those flags was done.
+
+      -FLAGS.SILENT <flag list>
+                     Equivalent to -FLAGS, but without returning a new
+                     value.
+
+   Example:    C: A003 STORE 2:4 +FLAGS (\Deleted)
+               S: * 2 FETCH FLAGS (\Deleted \Seen)
+               S: * 3 FETCH FLAGS (\Deleted)
+               S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
+               S: A003 OK STORE completed
+
+6.4.7.  COPY Command
+
+   Arguments:  message set
+               mailbox name
+
+   Responses:  no specific responses for this command
+
+   Result:     OK - copy completed
+               NO - copy error: can't copy those messages or to that
+                    name
+               BAD - command unknown or arguments invalid
+
+      The COPY command copies the specified message(s) to the end of the
+      specified destination mailbox.  The flags and internal date of the
+      message(s) SHOULD be preserved in the copy.
+
+      If the destination mailbox does not exist, a server SHOULD return
+      an error.  It SHOULD NOT automatically create the mailbox.  Unless
+      it is certain that the destination mailbox can not be created, the
+      server MUST send the response code "[TRYCREATE]" as the prefix of
+      the text of the tagged NO response.  This gives a hint to the
+      client that it can attempt a CREATE command and retry the COPY if
+      the CREATE is successful.
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 46]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      If the COPY command is unsuccessful for any reason, server
+      implementations MUST restore the destination mailbox to its state
+      before the COPY attempt.
+
+   Example:    C: A003 COPY 2:4 MEETING
+               S: A003 OK COPY completed
+
+6.4.8.  UID Command
+
+   Arguments:  command name
+               command arguments
+
+   Responses:  untagged responses: FETCH, SEARCH
+
+   Result:     OK - UID command completed
+               NO - UID command error
+               BAD - command unknown or arguments invalid
+
+      The UID command has two forms.  In the first form, it takes as its
+      arguments a COPY, FETCH, or STORE command with arguments
+      appropriate for the associated command.  However, the numbers in
+      the message set argument are unique identifiers instead of message
+      sequence numbers.
+
+      In the second form, the UID command takes a SEARCH command with
+      SEARCH command arguments.  The interpretation of the arguments is
+      the same as with SEARCH; however, the numbers returned in a SEARCH
+      response for a UID SEARCH command are unique identifiers instead
+      of message sequence numbers.  For example, the command UID SEARCH
+      1:100 UID 443:557 returns the unique identifiers corresponding to
+      the intersection of the message sequence number set 1:100 and the
+      UID set 443:557.
+
+      Message set ranges are permitted; however, there is no guarantee
+      that unique identifiers be contiguous.  A non-existent unique
+      identifier within a message set range is ignored without any error
+      message generated.
+
+      The number after the "*" in an untagged FETCH response is always a
+      message sequence number, not a unique identifier, even for a UID
+      command response.  However, server implementations MUST implicitly
+      include the UID message data item as part of any FETCH response
+      caused by a UID command, regardless of whether a UID was specified
+      as a message data item to the FETCH.
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 47]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
+               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
+               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
+               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
+               S: A999 UID FETCH completed
+
+6.5.    Client Commands - Experimental/Expansion
+
+6.5.1.  X<atom> Command
+
+   Arguments:  implementation defined
+
+   Responses:  implementation defined
+
+   Result:     OK - command completed
+               NO - failure
+               BAD - command unknown or arguments invalid
+
+      Any command prefixed with an X is an experimental command.
+      Commands which are not part of this specification, a standard or
+      standards-track revision of this specification, or an IESG-
+      approved experimental protocol, MUST use the X prefix.
+
+      Any added untagged responses issued by an experimental command
+      MUST also be prefixed with an X.  Server implementations MUST NOT
+      send any such untagged responses, unless the client requested it
+      by issuing the associated experimental command.
+
+   Example:    C: a441 CAPABILITY
+               S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
+               S: a441 OK CAPABILITY completed
+               C: A442 XPIG-LATIN
+               S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
+               S: A442 OK XPIG-LATIN ompleted-cay
+
+7.      Server Responses
+
+   Server responses are in three forms: status responses, server data,
+   and command continuation request.  The information contained in a
+   server response, identified by "Contents:" in the response
+   descriptions below, is described by function, not by syntax.  The
+   precise syntax of server responses is described in the Formal Syntax
+   section.
+
+   The client MUST be prepared to accept any response at all times.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 48]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Status responses can be tagged or untagged.  Tagged status responses
+   indicate the completion result (OK, NO, or BAD status) of a client
+   command, and have a tag matching the command.
+
+   Some status responses, and all server data, are untagged.  An
+   untagged response is indicated by the token "*" instead of a tag.
+   Untagged status responses indicate server greeting, or server status
+   that does not indicate the completion of a command (for example, an
+   impending system shutdown alert).  For historical reasons, untagged
+   server data responses are also called "unsolicited data", although
+   strictly speaking only unilateral server data is truly "unsolicited".
+
+   Certain server data MUST be recorded by the client when it is
+   received; this is noted in the description of that data.  Such data
+   conveys critical information which affects the interpretation of all
+   subsequent commands and responses (e.g. updates reflecting the
+   creation or destruction of messages).
+
+   Other server data SHOULD be recorded for later reference; if the
+   client does not need to record the data, or if recording the data has
+   no obvious purpose (e.g. a SEARCH response when no SEARCH command is
+   in progress), the data SHOULD be ignored.
+
+   An example of unilateral untagged server data occurs when the IMAP
+   connection is in selected state.  In selected state, the server
+   checks the mailbox for new messages as part of command execution.
+   Normally, this is part of the execution of every command; hence, a
+   NOOP command suffices to check for new messages.  If new messages are
+   found, the server sends untagged EXISTS and RECENT responses
+   reflecting the new size of the mailbox.  Server implementations that
+   offer multiple simultaneous access to the same mailbox SHOULD also
+   send appropriate unilateral untagged FETCH and EXPUNGE responses if
+   another agent changes the state of any message flags or expunges any
+   messages.
+
+   Command continuation request responses use the token "+" instead of a
+   tag.  These responses are sent by the server to indicate acceptance
+   of an incomplete client command and readiness for the remainder of
+   the command.
+
+7.1.    Server Responses - Status Responses
+
+   Status responses are OK, NO, BAD, PREAUTH and BYE.  OK, NO, and BAD
+   may be tagged or untagged.  PREAUTH and BYE are always untagged.
+
+   Status responses MAY include an OPTIONAL "response code".  A response
+   code consists of data inside square brackets in the form of an atom,
+   possibly followed by a space and arguments.  The response code
+
+
+
+Crispin                     Standards Track                    [Page 49]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   contains additional information or status codes for client software
+   beyond the OK/NO/BAD condition, and are defined when there is a
+   specific action that a client can take based upon the additional
+   information.
+
+   The currently defined response codes are:
+
+      ALERT          The human-readable text contains a special alert
+                     that MUST be presented to the user in a fashion
+                     that calls the user's attention to the message.
+
+      NEWNAME        Followed by a mailbox name and a new mailbox name.
+                     A SELECT or EXAMINE is failing because the target
+                     mailbox name no longer exists because it was
+                     renamed to the new mailbox name.  This is a hint to
+                     the client that the operation can succeed if the
+                     SELECT or EXAMINE is reissued with the new mailbox
+                     name.
+
+      PARSE          The human-readable text represents an error in
+                     parsing the [RFC-822] header or [MIME-IMB] headers
+                     of a message in the mailbox.
+
+      PERMANENTFLAGS Followed by a parenthesized list of flags,
+                     indicates which of the known flags that the client
+                     can change permanently.  Any flags that are in the
+                     FLAGS untagged response, but not the PERMANENTFLAGS
+                     list, can not be set permanently.  If the client
+                     attempts to STORE a flag that is not in the
+                     PERMANENTFLAGS list, the server will either reject
+                     it with a NO reply or store the state for the
+                     remainder of the current session only.  The
+                     PERMANENTFLAGS list can also include the special
+                     flag \*, which indicates that it is possible to
+                     create new keywords by attempting to store those
+                     flags in the mailbox.
+
+      READ-ONLY      The mailbox is selected read-only, or its access
+                     while selected has changed from read-write to
+                     read-only.
+
+      READ-WRITE     The mailbox is selected read-write, or its access
+                     while selected has changed from read-only to
+                     read-write.
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 50]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      TRYCREATE      An APPEND or COPY attempt is failing because the
+                     target mailbox does not exist (as opposed to some
+                     other reason).  This is a hint to the client that
+                     the operation can succeed if the mailbox is first
+                     created by the CREATE command.
+
+      UIDVALIDITY    Followed by a decimal number, indicates the unique
+                     identifier validity value.
+
+      UNSEEN         Followed by a decimal number, indicates the number
+                     of the first message without the \Seen flag set.
+
+      Additional response codes defined by particular client or server
+      implementations SHOULD be prefixed with an "X" until they are
+      added to a revision of this protocol.  Client implementations
+      SHOULD ignore response codes that they do not recognize.
+
+7.1.1.  OK Response
+
+   Contents:   OPTIONAL response code
+               human-readable text
+
+      The OK response indicates an information message from the server.
+      When tagged, it indicates successful completion of the associated
+      command.  The human-readable text MAY be presented to the user as
+      an information message.  The untagged form indicates an
+      information-only message; the nature of the information MAY be
+      indicated by a response code.
+
+      The untagged form is also used as one of three possible greetings
+      at connection startup.  It indicates that the connection is not
+      yet authenticated and that a LOGIN command is needed.
+
+   Example:    S: * OK IMAP4rev1 server ready
+               C: A001 LOGIN fred blurdybloop
+               S: * OK [ALERT] System shutdown in 10 minutes
+               S: A001 OK LOGIN Completed
+
+7.1.2.  NO Response
+
+      Contents:   OPTIONAL response code
+                  human-readable text
+
+      The NO response indicates an operational error message from the
+      server.  When tagged, it indicates unsuccessful completion of the
+      associated command.  The untagged form indicates a warning; the
+      command can still complete successfully.  The human-readable text
+      describes the condition.
+
+
+
+Crispin                     Standards Track                    [Page 51]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Example:    C: A222 COPY 1:2 owatagusiam
+               S: * NO Disk is 98% full, please delete unnecessary data
+               S: A222 OK COPY completed
+               C: A223 COPY 3:200 blurdybloop
+               S: * NO Disk is 98% full, please delete unnecessary data
+               S: * NO Disk is 99% full, please delete unnecessary data
+               S: A223 NO COPY failed: disk is full
+
+7.1.3.  BAD Response
+
+   Contents:   OPTIONAL response code
+               human-readable text
+
+      The BAD response indicates an error message from the server.  When
+      tagged, it reports a protocol-level error in the client's command;
+      the tag indicates the command that caused the error.  The untagged
+      form indicates a protocol-level error for which the associated
+      command can not be determined; it can also indicate an internal
+      server failure.  The human-readable text describes the condition.
+
+   Example:    C: ...very long command line...
+               S: * BAD Command line too long
+               C: ...empty line...
+               S: * BAD Empty command line
+               C: A443 EXPUNGE
+               S: * BAD Disk crash, attempting salvage to a new disk!
+               S: * OK Salvage successful, no data lost
+               S: A443 OK Expunge completed
+
+7.1.4.  PREAUTH Response
+
+   Contents:   OPTIONAL response code
+               human-readable text
+
+      The PREAUTH response is always untagged, and is one of three
+      possible greetings at connection startup.  It indicates that the
+      connection has already been authenticated by external means and
+      thus no LOGIN command is needed.
+
+   Example:    S: * PREAUTH IMAP4rev1 server logged in as Smith
+
+7.1.5.  BYE Response
+
+   Contents:   OPTIONAL response code
+               human-readable text
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 52]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      The BYE response is always untagged, and indicates that the server
+      is about to close the connection.  The human-readable text MAY be
+      displayed to the user in a status report by the client.  The BYE
+      response is sent under one of four conditions:
+
+         1) as part of a normal logout sequence.  The server will close
+            the connection after sending the tagged OK response to the
+            LOGOUT command.
+
+         2) as a panic shutdown announcement.  The server closes the
+            connection immediately.
+
+         3) as an announcement of an inactivity autologout.  The server
+            closes the connection immediately.
+
+         4) as one of three possible greetings at connection startup,
+            indicating that the server is not willing to accept a
+            connection from this client.  The server closes the
+            connection immediately.
+
+      The difference between a BYE that occurs as part of a normal
+      LOGOUT sequence (the first case) and a BYE that occurs because of
+      a failure (the other three cases) is that the connection closes
+      immediately in the failure case.
+
+   Example:    S: * BYE Autologout; idle for too long
+
+7.2.    Server Responses - Server and Mailbox Status
+
+   These responses are always untagged.  This is how server and mailbox
+   status data are transmitted from the server to the client.  Many of
+   these responses typically result from a command with the same name.
+
+7.2.1.  CAPABILITY Response
+
+   Contents:   capability listing
+
+      The CAPABILITY response occurs as a result of a CAPABILITY
+      command.  The capability listing contains a space-separated
+      listing of capability names that the server supports.  The
+      capability listing MUST include the atom "IMAP4rev1".
+
+      A capability name which begins with "AUTH=" indicates that the
+      server supports that particular authentication mechanism.
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 53]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      Other capability names indicate that the server supports an
+      extension, revision, or amendment to the IMAP4rev1 protocol.
+      Server responses MUST conform to this document until the client
+      issues a command that uses the associated capability.
+
+      Capability names MUST either begin with "X" or be standard or
+      standards-track IMAP4rev1 extensions, revisions, or amendments
+      registered with IANA.  A server MUST NOT offer unregistered or
+      non-standard capability names, unless such names are prefixed with
+      an "X".
+
+      Client implementations SHOULD NOT require any capability name
+      other than "IMAP4rev1", and MUST ignore any unknown capability
+      names.
+
+   Example:    S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN
+
+7.2.2.  LIST Response
+
+   Contents:   name attributes
+               hierarchy delimiter
+               name
+
+      The LIST response occurs as a result of a LIST command.  It
+      returns a single name that matches the LIST specification.  There
+      can be multiple LIST responses for a single LIST command.
+
+      Four name attributes are defined:
+
+      \Noinferiors   It is not possible for any child levels of
+                     hierarchy to exist under this name; no child levels
+                     exist now and none can be created in the future.
+
+      \Noselect      It is not possible to use this name as a selectable
+                     mailbox.
+
+      \Marked        The mailbox has been marked "interesting" by the
+                     server; the mailbox probably contains messages that
+                     have been added since the last time the mailbox was
+                     selected.
+
+      \Unmarked      The mailbox does not contain any additional
+                     messages since the last time the mailbox was
+                     selected.
+
+      If it is not feasible for the server to determine whether the
+      mailbox is "interesting" or not, or if the name is a \Noselect
+      name, the server SHOULD NOT send either \Marked or \Unmarked.
+
+
+
+Crispin                     Standards Track                    [Page 54]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      The hierarchy delimiter is a character used to delimit levels of
+      hierarchy in a mailbox name.  A client can use it to create child
+      mailboxes, and to search higher or lower levels of naming
+      hierarchy.  All children of a top-level hierarchy node MUST use
+      the same separator character.  A NIL hierarchy delimiter means
+      that no hierarchy exists; the name is a "flat" name.
+
+      The name represents an unambiguous left-to-right hierarchy, and
+      MUST be valid for use as a reference in LIST and LSUB commands.
+      Unless \Noselect is indicated, the name MUST also be valid as an
+            argument for commands, such as SELECT, that accept mailbox
+      names.
+
+   Example:    S: * LIST (\Noselect) "/" ~/Mail/foo
+
+7.2.3.  LSUB Response
+
+   Contents:   name attributes
+               hierarchy delimiter
+               name
+
+      The LSUB response occurs as a result of an LSUB command.  It
+      returns a single name that matches the LSUB specification.  There
+      can be multiple LSUB responses for a single LSUB command.  The
+      data is identical in format to the LIST response.
+
+   Example:    S: * LSUB () "." #news.comp.mail.misc
+
+7.2.4   STATUS Response
+
+   Contents:   name
+               status parenthesized list
+
+      The STATUS response occurs as a result of an STATUS command.  It
+      returns the mailbox name that matches the STATUS specification and
+      the requested mailbox status information.
+
+   Example:    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
+
+7.2.5.  SEARCH Response
+
+   Contents:   zero or more numbers
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 55]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      The SEARCH response occurs as a result of a SEARCH or UID SEARCH
+      command.  The number(s) refer to those messages that match the
+      search criteria.  For SEARCH, these are message sequence numbers;
+      for UID SEARCH, these are unique identifiers.  Each number is
+      delimited by a space.
+
+   Example:    S: * SEARCH 2 3 6
+
+7.2.6.  FLAGS Response
+
+   Contents:   flag parenthesized list
+
+      The FLAGS response occurs as a result of a SELECT or EXAMINE
+      command.  The flag parenthesized list identifies the flags (at a
+      minimum, the system-defined flags) that are applicable for this
+      mailbox.  Flags other than the system flags can also exist,
+      depending on server implementation.
+
+      The update from the FLAGS response MUST be recorded by the client.
+
+   Example:    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+
+7.3.    Server Responses - Mailbox Size
+
+   These responses are always untagged.  This is how changes in the size
+   of the mailbox are trasnmitted from the server to the client.
+   Immediately following the "*" token is a number that represents a
+   message count.
+
+7.3.1.  EXISTS Response
+
+   Contents:   none
+
+      The EXISTS response reports the number of messages in the mailbox.
+      This response occurs as a result of a SELECT or EXAMINE command,
+      and if the size of the mailbox changes (e.g. new mail).
+
+      The update from the EXISTS response MUST be recorded by the
+      client.
+
+   Example:    S: * 23 EXISTS
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 56]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+7.3.2.  RECENT Response
+
+      Contents:   none
+
+      The RECENT response reports the number of messages with the
+      \Recent flag set.  This response occurs as a result of a SELECT or
+      EXAMINE command, and if the size of the mailbox changes (e.g. new
+      mail).
+
+         Note: It is not guaranteed that the message sequence numbers of
+         recent messages will be a contiguous range of the highest n
+         messages in the mailbox (where n is the value reported by the
+         RECENT response).  Examples of situations in which this is not
+         the case are: multiple clients having the same mailbox open
+         (the first session to be notified will see it as recent, others
+         will probably see it as non-recent), and when the mailbox is
+         re-ordered by a non-IMAP agent.
+
+         The only reliable way to identify recent messages is to look at
+         message flags to see which have the \Recent flag set, or to do
+         a SEARCH RECENT.
+
+         The update from the RECENT response MUST be recorded by the
+         client.
+
+   Example:    S: * 5 RECENT
+
+7.4.    Server Responses - Message Status
+
+   These responses are always untagged.  This is how message data are
+   transmitted from the server to the client, often as a result of a
+   command with the same name.  Immediately following the "*" token is a
+   number that represents a message sequence number.
+
+7.4.1.  EXPUNGE Response
+
+   Contents:   none
+
+      The EXPUNGE response reports that the specified message sequence
+      number has been permanently removed from the mailbox.  The message
+      sequence number for each successive message in the mailbox is
+      immediately decremented by 1, and this decrement is reflected in
+      message sequence numbers in subsequent responses (including other
+      untagged EXPUNGE responses).
+
+      As a result of the immediate decrement rule, message sequence
+      numbers that appear in a set of successive EXPUNGE responses
+      depend upon whether the messages are removed starting from lower
+
+
+
+Crispin                     Standards Track                    [Page 57]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      numbers to higher numbers, or from higher numbers to lower
+      numbers.  For example, if the last 5 messages in a 9-message
+      mailbox are expunged; a "lower to higher" server will send five
+      untagged EXPUNGE responses for message sequence number 5, whereas
+      a "higher to lower server" will send successive untagged EXPUNGE
+      responses for message sequence numbers 9, 8, 7, 6, and 5.
+
+      An EXPUNGE response MUST NOT be sent when no command is in
+      progress; nor while responding to a FETCH, STORE, or SEARCH
+      command.  This rule is necessary to prevent a loss of
+      synchronization of message sequence numbers between client and
+      server.
+
+      The update from the EXPUNGE response MUST be recorded by the
+      client.
+
+   Example:    S: * 44 EXPUNGE
+
+7.4.2.  FETCH Response
+
+   Contents:   message data
+
+      The FETCH response returns data about a message to the client.
+      The data are pairs of data item names and their values in
+      parentheses.  This response occurs as the result of a FETCH or
+      STORE command, as well as by unilateral server decision (e.g. flag
+      updates).
+
+      The current data items are:
+
+      BODY           A form of BODYSTRUCTURE without extension data.
+
+      BODY[<section>]<<origin_octet>>
+                     A string expressing the body contents of the
+                     specified section.  The string SHOULD be
+                     interpreted by the client according to the content
+                     transfer encoding, body type, and subtype.
+
+                     If the origin octet is specified, this string is a
+                     substring of the entire body contents, starting at
+                     that origin octet.  This means that BODY[]<0> MAY
+                     be truncated, but BODY[] is NEVER truncated.
+
+                     8-bit textual data is permitted if a [CHARSET]
+                     identifier is part of the body parameter
+                     parenthesized list for this section.  Note that
+                     headers (part specifiers HEADER or MIME, or the
+                     header portion of a MESSAGE/RFC822 part), MUST be
+
+
+
+Crispin                     Standards Track                    [Page 58]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+                     7-bit; 8-bit characters are not permitted in
+                     headers.  Note also that the blank line at the end
+                     of the header is always included in header data.
+
+                     Non-textual data such as binary data MUST be
+                     transfer encoded into a textual form such as BASE64
+                     prior to being sent to the client.  To derive the
+                     original binary data, the client MUST decode the
+                     transfer encoded string.
+
+      BODYSTRUCTURE  A parenthesized list that describes the [MIME-IMB]
+                     body structure of a message.  This is computed by
+                     the server by parsing the [MIME-IMB] header fields,
+                     defaulting various fields as necessary.
+
+                     For example, a simple text message of 48 lines and
+                     2279 octets can have a body structure of: ("TEXT"
+                     "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279
+                     48)
+
+                     Multiple parts are indicated by parenthesis
+                     nesting.  Instead of a body type as the first
+                     element of the parenthesized list there is a nested
+                     body.  The second element of the parenthesized list
+                     is the multipart subtype (mixed, digest, parallel,
+                     alternative, etc.).
+
+                     For example, a two part message consisting of a
+                     text and a BASE645-encoded text attachment can have
+                     a body structure of: (("TEXT" "PLAIN" ("CHARSET"
+                     "US-ASCII") NIL NIL "7BIT" 1152 23)("TEXT" "PLAIN"
+                     ("CHARSET" "US-ASCII" "NAME" "cc.diff")
+                     "<960723163407.20117h@cac.washington.edu>"
+                     "Compiler diff" "BASE64" 4554 73) "MIXED"))
+
+                     Extension data follows the multipart subtype.
+                     Extension data is never returned with the BODY
+                     fetch, but can be returned with a BODYSTRUCTURE
+                     fetch.  Extension data, if present, MUST be in the
+                     defined order.
+
+                     The extension data of a multipart body part are in
+                     the following order:
+
+                     body parameter parenthesized list
+                        A parenthesized list of attribute/value pairs
+                        [e.g. ("foo" "bar" "baz" "rag") where "bar" is
+                        the value of "foo" and "rag" is the value of
+
+
+
+Crispin                     Standards Track                    [Page 59]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+                        "baz"] as defined in [MIME-IMB].
+
+                     body disposition
+                        A parenthesized list, consisting of a
+                        disposition type string followed by a
+                        parenthesized list of disposition
+                        attribute/value pairs.  The disposition type and
+                        attribute names will be defined in a future
+                        standards-track revision to [DISPOSITION].
+
+                     body language
+                        A string or parenthesized list giving the body
+                        language value as defined in [LANGUAGE-TAGS].
+
+                     Any following extension data are not yet defined in
+                     this version of the protocol.  Such extension data
+                     can consist of zero or more NILs, strings, numbers,
+                     or potentially nested parenthesized lists of such
+                     data.  Client implementations that do a
+                     BODYSTRUCTURE fetch MUST be prepared to accept such
+                     extension data.  Server implementations MUST NOT
+                     send such extension data until it has been defined
+                     by a revision of this protocol.
+
+                     The basic fields of a non-multipart body part are
+                     in the following order:
+
+                     body type
+                        A string giving the content media type name as
+                        defined in [MIME-IMB].
+
+                     body subtype
+                        A string giving the content subtype name as
+                        defined in [MIME-IMB].
+
+                     body parameter parenthesized list
+                        A parenthesized list of attribute/value pairs
+                        [e.g. ("foo" "bar" "baz" "rag") where "bar" is
+                        the value of "foo" and "rag" is the value of
+                        "baz"] as defined in [MIME-IMB].
+
+                     body id
+                        A string giving the content id as defined in
+                        [MIME-IMB].
+
+                     body description
+                        A string giving the content description as
+                        defined in [MIME-IMB].
+
+
+
+Crispin                     Standards Track                    [Page 60]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+                     body encoding
+                        A string giving the content transfer encoding as
+                        defined in [MIME-IMB].
+
+                     body size
+                        A number giving the size of the body in octets.
+                        Note that this size is the size in its transfer
+                        encoding and not the resulting size after any
+                        decoding.
+
+                     A body type of type MESSAGE and subtype RFC822
+                     contains, immediately after the basic fields, the
+                     envelope structure, body structure, and size in
+                     text lines of the encapsulated message.
+
+                     A body type of type TEXT contains, immediately
+                     after the basic fields, the size of the body in
+                     text lines.  Note that this size is the size in its
+                     content transfer encoding and not the resulting
+                     size after any decoding.
+
+                     Extension data follows the basic fields and the
+                     type-specific fields listed above.  Extension data
+                     is never returned with the BODY fetch, but can be
+                     returned with a BODYSTRUCTURE fetch.  Extension
+                     data, if present, MUST be in the defined order.
+
+                     The extension data of a non-multipart body part are
+                     in the following order:
+
+                     body MD5
+                        A string giving the body MD5 value as defined in
+                        [MD5].
+
+                     body disposition
+                        A parenthesized list with the same content and
+                        function as the body disposition for a multipart
+                        body part.
+
+                     body language
+                        A string or parenthesized list giving the body
+                        language value as defined in [LANGUAGE-TAGS].
+
+                     Any following extension data are not yet defined in
+                     this version of the protocol, and would be as
+                     described above under multipart extension data.
+
+
+
+
+
+Crispin                     Standards Track                    [Page 61]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      ENVELOPE       A parenthesized list that describes the envelope
+                     structure of a message.  This is computed by the
+                     server by parsing the [RFC-822] header into the
+                     component parts, defaulting various fields as
+                     necessary.
+
+                     The fields of the envelope structure are in the
+                     following order: date, subject, from, sender,
+                     reply-to, to, cc, bcc, in-reply-to, and message-id.
+                     The date, subject, in-reply-to, and message-id
+                     fields are strings.  The from, sender, reply-to,
+                     to, cc, and bcc fields are parenthesized lists of
+                     address structures.
+
+                     An address structure is a parenthesized list that
+                     describes an electronic mail address.  The fields
+                     of an address structure are in the following order:
+                     personal name, [SMTP] at-domain-list (source
+                     route), mailbox name, and host name.
+
+                     [RFC-822] group syntax is indicated by a special
+                     form of address structure in which the host name
+                     field is NIL.  If the mailbox name field is also
+                     NIL, this is an end of group marker (semi-colon in
+                     RFC 822 syntax).  If the mailbox name field is
+                     non-NIL, this is a start of group marker, and the
+                     mailbox name field holds the group name phrase.
+
+                     Any field of an envelope or address structure that
+                     is not applicable is presented as NIL.  Note that
+                     the server MUST default the reply-to and sender
+                     fields from the from field; a client is not
+                     expected to know to do this.
+
+      FLAGS          A parenthesized list of flags that are set for this
+                     message.
+
+      INTERNALDATE   A string representing the internal date of the
+                     message.
+
+      RFC822         Equivalent to BODY[].
+
+      RFC822.HEADER  Equivalent to BODY.PEEK[HEADER].
+
+      RFC822.SIZE    A number expressing the [RFC-822] size of the
+                     message.
+
+      RFC822.TEXT    Equivalent to BODY[TEXT].
+
+
+
+Crispin                     Standards Track                    [Page 62]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+      UID            A number expressing the unique identifier of the
+                     message.
+
+
+   Example:    S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
+
+7.5.    Server Responses - Command Continuation Request
+
+   The command continuation request response is indicated by a "+" token
+   instead of a tag.  This form of response indicates that the server is
+   ready to accept the continuation of a command from the client.  The
+   remainder of this response is a line of text.
+
+   This response is used in the AUTHORIZATION command to transmit server
+   data to the client, and request additional client data.  This
+   response is also used if an argument to any command is a literal.
+
+   The client is not permitted to send the octets of the literal unless
+   the server indicates that it expects it.  This permits the server to
+   process commands and reject errors on a line-by-line basis.  The
+   remainder of the command, including the CRLF that terminates a
+   command, follows the octets of the literal.  If there are any
+   additional command arguments the literal octets are followed by a
+   space and those arguments.
+
+   Example:    C: A001 LOGIN {11}
+               S: + Ready for additional command text
+               C: FRED FOOBAR {7}
+               S: + Ready for additional command text
+               C: fat man
+               S: A001 OK LOGIN completed
+               C: A044 BLURDYBLOOP {102856}
+               S: A044 BAD No such command as "BLURDYBLOOP"
+
+8.      Sample IMAP4rev1 connection
+
+   The following is a transcript of an IMAP4rev1 connection.  A long
+   line in this sample is broken for editorial clarity.
+
+S:   * OK IMAP4rev1 Service Ready
+C:   a001 login mrc secret
+S:   a001 OK LOGIN completed
+C:   a002 select inbox
+S:   * 18 EXISTS
+S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+S:   * 2 RECENT
+S:   * OK [UNSEEN 17] Message 17 is the first unseen message
+S:   * OK [UIDVALIDITY 3857529045] UIDs valid
+
+
+
+Crispin                     Standards Track                    [Page 63]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+S:   a002 OK [READ-WRITE] SELECT completed
+C:   a003 fetch 12 full
+S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
+      RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
+      "IMAP4rev1 WG mtg summary and minutes"
+      (("Terry Gray" NIL "gray" "cac.washington.edu"))
+      (("Terry Gray" NIL "gray" "cac.washington.edu"))
+      (("Terry Gray" NIL "gray" "cac.washington.edu"))
+      ((NIL NIL "imap" "cac.washington.edu"))
+      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
+      ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
+      "<B27397-0100000@cac.washington.edu>")
+       BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
+S:    a003 OK FETCH completed
+C:    a004 fetch 12 body[header]
+S:    * 12 FETCH (BODY[HEADER] {350}
+S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
+S:    From: Terry Gray <gray@cac.washington.edu>
+S:    Subject: IMAP4rev1 WG mtg summary and minutes
+S:    To: imap@cac.washington.edu
+S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
+S:    Message-Id: <B27397-0100000@cac.washington.edu>
+S:    MIME-Version: 1.0
+S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+S:
+S:    )
+S:    a004 OK FETCH completed
+C:    a005 store 12 +flags \deleted
+S:    * 12 FETCH (FLAGS (\Seen \Deleted))
+S:    a005 OK +FLAGS completed
+C:    a006 logout
+S:    * BYE IMAP4rev1 server terminating connection
+S:    a006 OK LOGOUT completed
+
+9.      Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [RFC-822] with one exception; the
+   delimiter used with the "#" construct is a single space (SPACE) and
+   not one or more commas.
+
+   In the case of alternative or optional rules in which a later rule
+   overlaps an earlier rule, the rule which is listed earlier MUST take
+   priority.  For example, "\Seen" when parsed as a flag is the \Seen
+   flag name and not a flag_extension, even though "\Seen" could be
+   parsed as a flag_extension.  Some, but not all, instances of this
+   rule are noted below.
+
+
+
+
+Crispin                     Standards Track                    [Page 64]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+address         ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
+                    SPACE addr_host ")"
+
+addr_adl        ::= nstring
+                    ;; Holds route from [RFC-822] route-addr if
+                    ;; non-NIL
+
+addr_host       ::= nstring
+                    ;; NIL indicates [RFC-822] group syntax.
+                    ;; Otherwise, holds [RFC-822] domain name
+
+addr_mailbox    ::= nstring
+                    ;; NIL indicates end of [RFC-822] group; if
+                    ;; non-NIL and addr_host is NIL, holds
+                    ;; [RFC-822] group name.
+                    ;; Otherwise, holds [RFC-822] local-part
+
+addr_name       ::= nstring
+                    ;; Holds phrase from [RFC-822] mailbox if
+                    ;; non-NIL
+
+alpha           ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
+                    "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
+                    "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
+                    "Y" / "Z" /
+                    "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
+                    "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
+                    "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
+                    "y" / "z"
+                    ;; Case-sensitive
+
+append          ::= "APPEND" SPACE mailbox [SPACE flag_list]
+                    [SPACE date_time] SPACE literal
+
+astring         ::= atom / string
+
+atom            ::= 1*ATOM_CHAR
+
+ATOM_CHAR       ::= <any CHAR except atom_specials>
+
+atom_specials   ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards /
+                    quoted_specials
+
+
+
+
+Crispin                     Standards Track                    [Page 65]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+authenticate    ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
+
+auth_type       ::= atom
+                    ;; Defined by [IMAP-AUTH]
+
+base64          ::= *(4base64_char) [base64_terminal]
+
+base64_char     ::= alpha / digit / "+" / "/"
+
+base64_terminal ::= (2base64_char "==") / (3base64_char "=")
+
+body            ::= "(" body_type_1part / body_type_mpart ")"
+
+body_extension  ::= nstring / number / "(" 1#body_extension ")"
+                    ;; Future expansion.  Client implementations
+                    ;; MUST accept body_extension fields.  Server
+                    ;; implementations MUST NOT generate
+                    ;; body_extension fields except as defined by
+                    ;; future standard or standards-track
+                    ;; revisions of this specification.
+
+body_ext_1part  ::= body_fld_md5 [SPACE body_fld_dsp
+                    [SPACE body_fld_lang
+                    [SPACE 1#body_extension]]]
+                    ;; MUST NOT be returned on non-extensible
+                    ;; "BODY" fetch
+
+body_ext_mpart  ::= body_fld_param
+                    [SPACE body_fld_dsp SPACE body_fld_lang
+                    [SPACE 1#body_extension]]
+                    ;; MUST NOT be returned on non-extensible
+                    ;; "BODY" fetch
+
+body_fields     ::= body_fld_param SPACE body_fld_id SPACE
+                    body_fld_desc SPACE body_fld_enc SPACE
+                    body_fld_octets
+
+body_fld_desc   ::= nstring
+
+body_fld_dsp    ::= "(" string SPACE body_fld_param ")" / nil
+
+body_fld_enc    ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
+                    "QUOTED-PRINTABLE") <">) / string
+
+body_fld_id     ::= nstring
+
+body_fld_lang   ::= nstring / "(" 1#string ")"
+
+
+
+
+Crispin                     Standards Track                    [Page 66]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+body_fld_lines  ::= number
+
+body_fld_md5    ::= nstring
+
+body_fld_octets ::= number
+
+body_fld_param  ::= "(" 1#(string SPACE string) ")" / nil
+
+body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
+                    [SPACE body_ext_1part]
+
+body_type_basic ::= media_basic SPACE body_fields
+                    ;; MESSAGE subtype MUST NOT be "RFC822"
+
+body_type_mpart ::= 1*body SPACE media_subtype
+                    [SPACE body_ext_mpart]
+
+body_type_msg   ::= media_message SPACE body_fields SPACE envelope
+                    SPACE body SPACE body_fld_lines
+
+body_type_text  ::= media_text SPACE body_fields SPACE body_fld_lines
+
+capability      ::= "AUTH=" auth_type / atom
+                    ;; New capabilities MUST begin with "X" or be
+                    ;; registered with IANA as standard or
+                    ;; standards-track
+
+capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1"
+                    [SPACE 1#capability]
+                    ;; IMAP4rev1 servers which offer RFC 1730
+                    ;; compatibility MUST list "IMAP4" as the first
+                    ;; capability.
+
+CHAR            ::= <any 7-bit US-ASCII character except NUL,
+                     0x01 - 0x7f>
+
+CHAR8           ::= <any 8-bit octet except NUL, 0x01 - 0xff>
+
+command         ::= tag SPACE (command_any / command_auth /
+                    command_nonauth / command_select) CRLF
+                    ;; Modal based on state
+
+command_any     ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
+                    ;; Valid in all states
+
+command_auth    ::= append / create / delete / examine / list / lsub /
+                    rename / select / status / subscribe / unsubscribe
+                    ;; Valid only in Authenticated or Selected state
+
+
+
+Crispin                     Standards Track                    [Page 67]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+command_nonauth ::= login / authenticate
+                    ;; Valid only when in Non-Authenticated state
+
+command_select  ::= "CHECK" / "CLOSE" / "EXPUNGE" /
+                     copy / fetch / store / uid / search
+                    ;; Valid only when in Selected state
+
+continue_req    ::= "+" SPACE (resp_text / base64)
+
+copy            ::= "COPY" SPACE set SPACE mailbox
+
+CR              ::= <ASCII CR, carriage return, 0x0D>
+
+create          ::= "CREATE" SPACE mailbox
+                    ;; Use of INBOX gives a NO error
+
+CRLF            ::= CR LF
+
+CTL             ::= <any ASCII control character and DEL,
+                        0x00 - 0x1f, 0x7f>
+
+date            ::= date_text / <"> date_text <">
+
+date_day        ::= 1*2digit
+                    ;; Day of month
+
+date_day_fixed  ::= (SPACE digit) / 2digit
+                    ;; Fixed-format version of date_day
+
+date_month      ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
+                    "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
+
+date_text       ::= date_day "-" date_month "-" date_year
+
+date_year       ::= 4digit
+
+date_time       ::= <"> date_day_fixed "-" date_month "-" date_year
+                    SPACE time SPACE zone <">
+
+delete          ::= "DELETE" SPACE mailbox
+                    ;; Use of INBOX gives a NO error
+
+digit           ::= "0" / digit_nz
+
+digit_nz        ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
+                    "9"
+
+
+
+
+
+Crispin                     Standards Track                    [Page 68]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+envelope        ::= "(" env_date SPACE env_subject SPACE env_from
+                    SPACE env_sender SPACE env_reply_to SPACE env_to
+                    SPACE env_cc SPACE env_bcc SPACE env_in_reply_to
+                    SPACE env_message_id ")"
+
+env_bcc         ::= "(" 1*address ")" / nil
+
+env_cc          ::= "(" 1*address ")" / nil
+
+env_date        ::= nstring
+
+env_from        ::= "(" 1*address ")" / nil
+
+env_in_reply_to ::= nstring
+
+env_message_id  ::= nstring
+
+env_reply_to    ::= "(" 1*address ")" / nil
+
+env_sender      ::= "(" 1*address ")" / nil
+
+env_subject     ::= nstring
+
+env_to          ::= "(" 1*address ")" / nil
+
+examine         ::= "EXAMINE" SPACE mailbox
+
+fetch           ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
+                    "FAST" / fetch_att / "(" 1#fetch_att ")")
+
+fetch_att       ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
+                    "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
+                    "BODY" ["STRUCTURE"] / "UID" /
+                    "BODY" [".PEEK"] section
+                    ["<" number "." nz_number ">"]
+
+flag            ::= "\Answered" / "\Flagged" / "\Deleted" /
+                    "\Seen" / "\Draft" / flag_keyword / flag_extension
+
+flag_extension  ::= "\" atom
+                    ;; Future expansion.  Client implementations
+                    ;; MUST accept flag_extension flags.  Server
+                    ;; implementations MUST NOT generate
+                    ;; flag_extension flags except as defined by
+                    ;; future standard or standards-track
+                    ;; revisions of this specification.
+
+flag_keyword    ::= atom
+
+
+
+Crispin                     Standards Track                    [Page 69]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+flag_list       ::= "(" #flag ")"
+
+greeting        ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
+
+header_fld_name ::= astring
+
+header_list     ::= "(" 1#header_fld_name ")"
+
+LF              ::= <ASCII LF, line feed, 0x0A>
+
+list            ::= "LIST" SPACE mailbox SPACE list_mailbox
+
+list_mailbox    ::= 1*(ATOM_CHAR / list_wildcards) / string
+
+list_wildcards  ::= "%" / "*"
+
+literal         ::= "{" number "}" CRLF *CHAR8
+                    ;; Number represents the number of CHAR8 octets
+
+login           ::= "LOGIN" SPACE userid SPACE password
+
+lsub            ::= "LSUB" SPACE mailbox SPACE list_mailbox
+
+mailbox         ::= "INBOX" / astring
+                    ;; INBOX is case-insensitive.  All case variants of
+                    ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX
+                    ;; not as an astring.  Refer to section 5.1 for
+                    ;; further semantic details of mailbox names.
+
+mailbox_data    ::=  "FLAGS" SPACE flag_list /
+                     "LIST" SPACE mailbox_list /
+                     "LSUB" SPACE mailbox_list /
+                     "MAILBOX" SPACE text /
+                     "SEARCH" [SPACE 1#nz_number] /
+                     "STATUS" SPACE mailbox SPACE
+                     "(" #<status_att number ")" /
+                     number SPACE "EXISTS" / number SPACE "RECENT"
+
+mailbox_list    ::= "(" #("\Marked" / "\Noinferiors" /
+                    "\Noselect" / "\Unmarked" / flag_extension) ")"
+                    SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
+
+media_basic     ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
+                    "MESSAGE" / "VIDEO") <">) / string)
+                    SPACE media_subtype
+                    ;; Defined in [MIME-IMT]
+
+media_message   ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <">
+
+
+
+Crispin                     Standards Track                    [Page 70]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+                    ;; Defined in [MIME-IMT]
+
+media_subtype   ::= string
+                    ;; Defined in [MIME-IMT]
+
+media_text      ::= <"> "TEXT" <"> SPACE media_subtype
+                    ;; Defined in [MIME-IMT]
+
+message_data    ::= nz_number SPACE ("EXPUNGE" /
+                                    ("FETCH" SPACE msg_att))
+
+msg_att         ::= "(" 1#("ENVELOPE" SPACE envelope /
+                    "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
+                    "INTERNALDATE" SPACE date_time /
+                    "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
+                    "RFC822.SIZE" SPACE number /
+                    "BODY" ["STRUCTURE"] SPACE body /
+                    "BODY" section ["<" number ">"] SPACE nstring /
+                    "UID" SPACE uniqueid) ")"
+
+nil             ::= "NIL"
+
+nstring         ::= string / nil
+
+number          ::= 1*digit
+                    ;; Unsigned 32-bit integer
+                    ;; (0 <= n < 4,294,967,296)
+
+nz_number       ::= digit_nz *digit
+                    ;; Non-zero unsigned 32-bit integer
+                    ;; (0 < n < 4,294,967,296)
+
+password        ::= astring
+
+quoted          ::= <"> *QUOTED_CHAR <">
+
+QUOTED_CHAR     ::= <any TEXT_CHAR except quoted_specials> /
+                    "\" quoted_specials
+
+quoted_specials ::= <"> / "\"
+
+rename          ::= "RENAME" SPACE mailbox SPACE mailbox
+                    ;; Use of INBOX as a destination gives a NO error
+
+response        ::= *(continue_req / response_data) response_done
+
+response_data   ::= "*" SPACE (resp_cond_state / resp_cond_bye /
+                    mailbox_data / message_data / capability_data)
+
+
+
+Crispin                     Standards Track                    [Page 71]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+                    CRLF
+
+response_done   ::= response_tagged / response_fatal
+
+response_fatal  ::= "*" SPACE resp_cond_bye CRLF
+                    ;; Server closes connection immediately
+
+response_tagged ::= tag SPACE resp_cond_state CRLF
+
+resp_cond_auth  ::= ("OK" / "PREAUTH") SPACE resp_text
+                    ;; Authentication condition
+
+resp_cond_bye   ::= "BYE" SPACE resp_text
+
+resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
+                    ;; Status condition
+
+resp_text       ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
+                    ;; text SHOULD NOT begin with "[" or "="
+
+resp_text_code  ::= "ALERT" / "PARSE" /
+                    "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
+                    "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
+                    "UIDVALIDITY" SPACE nz_number /
+                    "UNSEEN" SPACE nz_number /
+                    atom [SPACE 1*<any TEXT_CHAR except "]">]
+
+search          ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
+                    1#search_key
+                    ;; [CHARSET] MUST be registered with IANA
+
+search_key      ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
+                    "BEFORE" SPACE date / "BODY" SPACE astring /
+                    "CC" SPACE astring / "DELETED" / "FLAGGED" /
+                    "FROM" SPACE astring /
+                    "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
+                    "ON" SPACE date / "RECENT" / "SEEN" /
+                    "SINCE" SPACE date / "SUBJECT" SPACE astring /
+                    "TEXT" SPACE astring / "TO" SPACE astring /
+                    "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
+                    "UNKEYWORD" SPACE flag_keyword / "UNSEEN" /
+                    ;; Above this line were in [IMAP2]
+                    "DRAFT" /
+                    "HEADER" SPACE header_fld_name SPACE astring /
+                    "LARGER" SPACE number / "NOT" SPACE search_key /
+                    "OR" SPACE search_key SPACE search_key /
+                    "SENTBEFORE" SPACE date / "SENTON" SPACE date /
+                    "SENTSINCE" SPACE date / "SMALLER" SPACE number /
+
+
+
+Crispin                     Standards Track                    [Page 72]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+                    "UID" SPACE set / "UNDRAFT" / set /
+                    "(" 1#search_key ")"
+
+section         ::= "[" [section_text / (nz_number *["." nz_number]
+                    ["." (section_text / "MIME")])] "]"
+
+section_text    ::= "HEADER" / "HEADER.FIELDS" [".NOT"]
+                    SPACE header_list / "TEXT"
+
+select          ::= "SELECT" SPACE mailbox
+
+sequence_num    ::= nz_number / "*"
+                    ;; * is the largest number in use.  For message
+                    ;; sequence numbers, it is the number of messages
+                    ;; in the mailbox.  For unique identifiers, it is
+                    ;; the unique identifier of the last message in
+                    ;; the mailbox.
+
+set             ::= sequence_num / (sequence_num ":" sequence_num) /
+                    (set "," set)
+                    ;; Identifies a set of messages.  For message
+                    ;; sequence numbers, these are consecutive
+                    ;; numbers from 1 to the number of messages in
+                    ;; the mailbox
+                    ;; Comma delimits individual numbers, colon
+                    ;; delimits between two numbers inclusive.
+                    ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
+                    ;; 14,15 for a mailbox with 15 messages.
+
+SPACE           ::= <ASCII SP, space, 0x20>
+
+status          ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")"
+
+status_att      ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
+                    "UNSEEN"
+
+store           ::= "STORE" SPACE set SPACE store_att_flags
+
+store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
+                    (flag_list / #flag)
+
+string          ::= quoted / literal
+
+subscribe       ::= "SUBSCRIBE" SPACE mailbox
+
+tag             ::= 1*<any ATOM_CHAR except "+">
+
+text            ::= 1*TEXT_CHAR
+
+
+
+Crispin                     Standards Track                    [Page 73]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+text_mime2       ::= "=?" <charset> "?" <encoding> "?"
+                     <encoded-text> "?="
+                     ;; Syntax defined in [MIME-HDRS]
+
+TEXT_CHAR       ::= <any CHAR except CR and LF>
+
+time            ::= 2digit ":" 2digit ":" 2digit
+                    ;; Hours minutes seconds
+
+uid             ::= "UID" SPACE (copy / fetch / search / store)
+                    ;; Unique identifiers used instead of message
+                    ;; sequence numbers
+
+uniqueid        ::= nz_number
+                    ;; Strictly ascending
+
+unsubscribe     ::= "UNSUBSCRIBE" SPACE mailbox
+
+userid          ::= astring
+
+x_command       ::= "X" atom <experimental command arguments>
+
+zone            ::= ("+" / "-") 4digit
+                    ;; Signed four-digit value of hhmm representing
+                    ;; hours and minutes west of Greenwich (that is,
+                    ;; (the amount that the given time differs from
+                    ;; Universal Time).  Subtracting the timezone
+                    ;; from the given time will give the UT form.
+                    ;; The Universal Time zone is "+0000".
+
+10.     Author's Note
+
+   This document is a revision or rewrite of earlier documents, and
+   supercedes the protocol specification in those documents: RFC 1730,
+   unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
+
+11.     Security Considerations
+
+   IMAP4rev1 protocol transactions, including electronic mail data, are
+   sent in the clear over the network unless privacy protection is
+   negotiated in the AUTHENTICATE command.
+
+   A server error message for an AUTHENTICATE command which fails due to
+   invalid credentials SHOULD NOT detail why the credentials are
+   invalid.
+
+   Use of the LOGIN command sends passwords in the clear.  This can be
+   avoided by using the AUTHENTICATE command instead.
+
+
+
+Crispin                     Standards Track                    [Page 74]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+   A server error message for a failing LOGIN command SHOULD NOT specify
+   that the user name, as opposed to the password, is invalid.
+
+   Additional security considerations are discussed in the section
+   discussing the AUTHENTICATE and LOGIN commands.
+
+12.     Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Aveneue NE
+   Seattle, WA  98105-4527
+
+   Phone: (206) 543-5762
+
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 75]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+Appendices
+
+A.      References
+
+[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol",
+Work in Progress.
+
+[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+RFC 1700, USC/Information Sciences Institute, October 1994.
+
+[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation
+Information in Internet Messages: The Content-Disposition Header",
+RFC 1806, June 1995.
+
+[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
+Carnegie-Mellon University, December 1994.
+
+[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC
+2061, University of Washington, November 1996.
+
+[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected
+IMAP4 Clients", Work in Progress.
+
+[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and
+IMAP2bis", RFC 1732, University of Washington, December 1994.
+
+[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in
+IMAP4", RFC 1733, University of Washington, December 1994.
+
+[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol -
+Obsolete Syntax", RFC 2062, University of Washington, November 1996.
+
+[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
+RFC 1176, University of Washington, August 1990.
+
+[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
+Languages", RFC 1766, March 1995.
+
+[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC
+1864, October 1995.
+
+[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet
+Mail Extensions) Part One: Format of Internet Message Bodies", RFC
+2045, November 1996.
+
+[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose
+Internet Mail Extensions) Part Two: Media Types", RFC 2046,
+November 1996.
+
+
+
+Crispin                     Standards Track                    [Page 76]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+Part Three: Message Header Extensions for Non-ASCII Text", RFC
+2047, November 1996.
+
+[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10,
+RFC 821, USC/Information Sciences Institute, August 1982.
+
+[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe
+Transformation Format of Unicode", RFC 1642, July 1994.
+
+B.      Changes from RFC 1730
+
+1) The STATUS command has been added.
+
+2) Clarify in the formal syntax that the "#" construct can never
+refer to multiple spaces.
+
+3) Obsolete syntax has been moved to a separate document.
+
+4) The PARTIAL command has been obsoleted.
+
+5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and
+RFC822.TEXT.PEEK fetch attributes have been obsoleted.
+
+6) The "<" origin "." size ">" suffix for BODY text attributes has
+been added.
+
+7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part
+specifiers have been added.
+
+8) Support for Content-Disposition and Content-Language has been
+added.
+
+9) The restriction on fetching nested MULTIPART parts has been
+removed.
+
+10) Body part number 0 has been obsoleted.
+
+11) Server-supported authenticators are now identified by
+capabilities.
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 77]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+12) The capability that identifies this protocol is now called
+"IMAP4rev1".  A server that provides backwards support for RFC 1730
+SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its
+CAPABILITY response.  Because RFC-1730 required "IMAP4" to appear as
+the first capability, it MUST listed first in the response.
+
+13) A description of the mailbox name namespace convention has been
+added.
+
+14) A description of the international mailbox name convention has
+been added.
+
+15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT
+and UIDVALIDITY.  This is a change from the IMAP STATUS
+Work in Progress and not from RFC-1730
+
+16) Add a clarification that a null mailbox name argument to the LIST
+command returns an untagged LIST response with the hierarchy
+delimiter and root of the reference argument.
+
+17) Define terms such as "MUST", "SHOULD", and "MUST NOT".
+
+18) Add a section which defines message attributes and more
+thoroughly details the semantics of message sequence numbers, UIDs,
+and flags.
+
+19) Add a clarification detailing the circumstances when a client may
+send multiple commands without waiting for a response, and the
+circumstances in which ambiguities may result.
+
+20) Add a recommendation on server behavior for DELETE and RENAME
+when inferior hierarchical names of the given name exist.
+
+21) Add a clarification that a mailbox name may not be unilaterally
+unsubscribed by the server, even if that mailbox name no longer
+exists.
+
+22) Add a clarification that LIST should return its results quickly
+without undue delay.
+
+23) Add a clarification that the date_time argument to APPEND sets
+the internal date of the message.
+
+24) Add a clarification on APPEND behavior when the target mailbox is
+the currently selected mailbox.
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 78]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+25) Add a clarification that external changes to flags should be
+always announced via an untagged FETCH even if the current command is
+a STORE with the ".SILENT" suffix.
+
+26) Add a clarification that COPY appends to the target mailbox.
+
+27) Add the NEWNAME response code.
+
+28) Rewrite the description of the untagged BYE response to clarify
+its semantics.
+
+29) Change the reference for the body MD5 to refer to the proper RFC.
+
+30) Clarify that the formal syntax contains rules which may overlap,
+and that in the event of such an overlap the rule which occurs first
+takes precedence.
+
+31) Correct the definition of body_fld_param.
+
+32) More formal syntax for capability_data.
+
+33) Clarify that any case variant of "INBOX" must be interpreted as
+INBOX.
+
+34) Clarify that the human-readable text in resp_text should not
+begin with "[" or "=".
+
+35) Change MIME references to Draft Standard documents.
+
+36) Clarify \Recent semantics.
+
+37) Additional examples.
+
+C.      Key Word Index
+
+       +FLAGS <flag list> (store command data item) ...............   45
+       +FLAGS.SILENT <flag list> (store command data item) ........   46
+       -FLAGS <flag list> (store command data item) ...............   46
+       -FLAGS.SILENT <flag list> (store command data item) ........   46
+       ALERT (response code) ......................................   50
+       ALL (fetch item) ...........................................   41
+       ALL (search key) ...........................................   38
+       ANSWERED (search key) ......................................   38
+       APPEND (command) ...........................................   34
+       AUTHENTICATE (command) .....................................   20
+       BAD (response) .............................................   52
+       BCC <string> (search key) ..................................   38
+       BEFORE <date> (search key) .................................   39
+
+
+
+Crispin                     Standards Track                    [Page 79]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+       BODY (fetch item) ..........................................   41
+       BODY (fetch result) ........................................   58
+       BODY <string> (search key) .................................   39
+       BODY.PEEK[<section>]<<partial>> (fetch item) ...............   44
+       BODYSTRUCTURE (fetch item) .................................   44
+       BODYSTRUCTURE (fetch result) ...............................   59
+       BODY[<section>]<<origin_octet>> (fetch result) .............   58
+       BODY[<section>]<<partial>> (fetch item) ....................   41
+       BYE (response) .............................................   52
+       Body Structure (message attribute) .........................   11
+       CAPABILITY (command) .......................................   18
+       CAPABILITY (response) ......................................   53
+       CC <string> (search key) ...................................   39
+       CHECK (command) ............................................   36
+       CLOSE (command) ............................................   36
+       COPY (command) .............................................   46
+       CREATE (command) ...........................................   25
+       DELETE (command) ...........................................   26
+       DELETED (search key) .......................................   39
+       DRAFT (search key) .........................................   39
+       ENVELOPE (fetch item) ......................................   44
+       ENVELOPE (fetch result) ....................................   62
+       EXAMINE (command) ..........................................   24
+       EXISTS (response) ..........................................   56
+       EXPUNGE (command) ..........................................   37
+       EXPUNGE (response) .........................................   57
+       Envelope Structure (message attribute) .....................   11
+       FAST (fetch item) ..........................................   44
+       FETCH (command) ............................................   41
+       FETCH (response) ...........................................   58
+       FLAGGED (search key) .......................................   39
+       FLAGS (fetch item) .........................................   44
+       FLAGS (fetch result) .......................................   62
+       FLAGS (response) ...........................................   56
+       FLAGS <flag list> (store command data item) ................   45
+       FLAGS.SILENT <flag list> (store command data item) .........   45
+       FROM <string> (search key) .................................   39
+       FULL (fetch item) ..........................................   44
+       Flags (message attribute) ..................................    9
+       HEADER (part specifier) ....................................   41
+       HEADER <field-name> <string> (search key) ..................   39
+       HEADER.FIELDS <header_list> (part specifier) ...............   41
+       HEADER.FIELDS.NOT <header_list> (part specifier) ...........   41
+       INTERNALDATE (fetch item) ..................................   44
+       INTERNALDATE (fetch result) ................................   62
+       Internal Date (message attribute) ..........................   10
+       KEYWORD <flag> (search key) ................................   39
+       Keyword (type of flag) .....................................   10
+
+
+
+Crispin                     Standards Track                    [Page 80]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+       LARGER <n> (search key) ....................................   39
+       LIST (command) .............................................   30
+       LIST (response) ............................................   54
+       LOGIN (command) ............................................   22
+       LOGOUT (command) ...........................................   20
+       LSUB (command) .............................................   32
+       LSUB (response) ............................................   55
+       MAY (specification requirement term) .......................    5
+       MESSAGES (status item) .....................................   33
+       MIME (part specifier) ......................................   42
+       MUST (specification requirement term) ......................    4
+       MUST NOT (specification requirement term) ..................    4
+       Message Sequence Number (message attribute) ................    9
+       NEW (search key) ...........................................   39
+       NEWNAME (response code) ....................................   50
+       NO (response) ..............................................   51
+       NOOP (command) .............................................   19
+       NOT <search-key> (search key) ..............................   39
+       OK (response) ..............................................   51
+       OLD (search key) ...........................................   39
+       ON <date> (search key) .....................................   39
+       OPTIONAL (specification requirement term) ..................    5
+       OR <search-key1> <search-key2> (search key) ................   39
+       PARSE (response code) ......................................   50
+       PERMANENTFLAGS (response code) .............................   50
+       PREAUTH (response) .........................................   52
+       Permanent Flag (class of flag) .............................   10
+       READ-ONLY (response code) ..................................   50
+       READ-WRITE (response code) .................................   50
+       RECENT (response) ..........................................   57
+       RECENT (search key) ........................................   39
+       RECENT (status item) .......................................   33
+       RENAME (command) ...........................................   27
+       REQUIRED (specification requirement term) ..................    4
+       RFC822 (fetch item) ........................................   44
+       RFC822 (fetch result) ......................................   63
+       RFC822.HEADER (fetch item) .................................   44
+       RFC822.HEADER (fetch result) ...............................   62
+       RFC822.SIZE (fetch item) ...................................   44
+       RFC822.SIZE (fetch result) .................................   62
+       RFC822.TEXT (fetch item) ...................................   44
+       RFC822.TEXT (fetch result) .................................   62
+       SEARCH (command) ...........................................   37
+       SEARCH (response) ..........................................   55
+       SEEN (search key) ..........................................   40
+       SELECT (command) ...........................................   23
+       SENTBEFORE <date> (search key) .............................   40
+       SENTON <date> (search key) .................................   40
+
+
+
+Crispin                     Standards Track                    [Page 81]
+
+RFC 2060                       IMAP4rev1                   December 1996
+
+
+       SENTSINCE <date> (search key) ..............................   40
+       SHOULD (specification requirement term) ....................    5
+       SHOULD NOT (specification requirement term) ................    5
+       SINCE <date> (search key) ..................................   40
+       SMALLER <n> (search key) ...................................   40
+       STATUS (command) ...........................................   33
+       STATUS (response) ..........................................   55
+       STORE (command) ............................................   45
+       SUBJECT <string> (search key) ..............................   40
+       SUBSCRIBE (command) ........................................   29
+       Session Flag (class of flag) ...............................   10
+       System Flag (type of flag) .................................    9
+       TEXT (part specifier) ......................................   42
+       TEXT <string> (search key) .................................   40
+       TO <string> (search key) ...................................   40
+       TRYCREATE (response code) ..................................   51
+       UID (command) ..............................................   47
+       UID (fetch item) ...........................................   44
+       UID (fetch result) .........................................   63
+       UID <message set> (search key) .............................   40
+       UIDNEXT (status item) ......................................   33
+       UIDVALIDITY (response code) ................................   51
+       UIDVALIDITY (status item) ..................................   34
+       UNANSWERED (search key) ....................................   40
+       UNDELETED (search key) .....................................   40
+       UNDRAFT (search key) .......................................   40
+       UNFLAGGED (search key) .....................................   40
+       UNKEYWORD <flag> (search key) ..............................   40
+       UNSEEN (response code) .....................................   51
+       UNSEEN (search key) ........................................   40
+       UNSEEN (status item) .......................................   34
+       UNSUBSCRIBE (command) ......................................   30
+       Unique Identifier (UID) (message attribute) ................    7
+       X<atom> (command) ..........................................   48
+       [RFC-822] Size (message attribute) .........................   11
+       \Answered (system flag) ....................................    9
+       \Deleted (system flag) .....................................    9
+       \Draft (system flag) .......................................    9
+       \Flagged (system flag) .....................................    9
+       \Marked (mailbox name attribute) ...........................   54
+       \Noinferiors (mailbox name attribute) ......................   54
+       \Noselect (mailbox name attribute) .........................   54
+       \Recent (system flag) ......................................   10
+       \Seen (system flag) ........................................    9
+       \Unmarked (mailbox name attribute) .........................   54
+
+
+
+
+
+
+Crispin                     Standards Track                    [Page 82]
+
diff --git a/RFC/rfc2061.txt b/RFC/rfc2061.txt
new file mode 100644
index 00000000..7cb02bb2
--- /dev/null
+++ b/RFC/rfc2061.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 2061                      University of Washington
+Category: Informational                                    December 1996
+
+
+                   IMAP4 COMPATIBILITY WITH IMAP2BIS
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Introduction
+
+   The Internet Message Access Protocol (IMAP) has been through several
+   revisions and variants in its 10-year history.  Many of these are
+   either extinct or extremely rare; in particular, several undocumented
+   variants and the variants described in RFC 1064, RFC 1176, and RFC
+   1203 fall into this category.
+
+   One variant, IMAP2bis, is at the time of this writing very common and
+   has been widely distributed with the Pine mailer.  Unfortunately,
+   there is no definite document describing IMAP2bis.  This document is
+   intended to be read along with RFC 1176 and the most recent IMAP4
+   specification (RFC 2060) to assist implementors in creating an IMAP4
+   implementation to interoperate with implementations that conform to
+   earlier specifications.  Nothing in this document is required by the
+   IMAP4 specification; implementors must decide for themselves whether
+   they want their implementation to fail if it encounters old software.
+
+   At the time of this writing, IMAP4 has been updated from the version
+   described in RFC 1730.  An implementor who wishes to interoperate
+   with both RFC 1730 and RFC 2060 should refer to both documents.
+
+   This information is not complete; it reflects current knowledge of
+   server and client implementations as well as "folklore" acquired in
+   the evolution of the protocol.  It is NOT a description of how to
+   interoperate with all variants of IMAP, but rather with the old
+   variant that is most likely to be encountered.  For detailed
+   information on interoperating with other old variants, refer to RFC
+   1732.
+
+IMAP4 client interoperability with IMAP2bis servers
+
+   A quick way to check whether a server implementation supports the
+   IMAP4 specification is to try the CAPABILITY command.  An OK response
+   will indicate which variant(s) of IMAP4 are supported by the server.
+
+
+
+Crispin                      Informational                      [Page 1]
+
+RFC 2061                  IMAP4 Compatibility              December 1996
+
+
+   If the client does not find any of its known variant in the response,
+   it should treat the server as IMAP2bis.  A BAD response indicates an
+   IMAP2bis or older server.
+
+   Most IMAP4 facilities are in IMAP2bis.  The following exceptions
+   exist:
+
+   CAPABILITY command
+            The absense of this command indicates IMAP2bis (or older).
+
+   AUTHENTICATE command.
+            Use the LOGIN command.
+
+   LSUB, SUBSCRIBE, and UNSUBSCRIBE commands
+            No direct functional equivalent.  IMAP2bis had a concept
+            called "bboards" which is not in IMAP4.  RFC 1176 supported
+            these with the BBOARD and FIND BBOARDS commands.  IMAP2bis
+            augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD,
+            and UNSUBSCRIBE BBOARD commands.  It is recommended that
+            none of these commands be implemented in new software,
+            including servers that support old clients.
+
+   LIST command
+            Use the command FIND ALL.MAILBOXES, which has a similar syn-
+            tax and response to the FIND MAILBOXES command described in
+            RFC 1176.  The FIND MAILBOXES command is unlikely to produce
+            useful information.
+
+   * in a sequence
+            Use the number of messages in the mailbox from the EXISTS
+            unsolicited response.
+
+   SEARCH extensions (character set, additional criteria)
+            Reformulate the search request using only the RFC 1176 syn-
+            tax.  This may entail doing multiple searches to achieve the
+            desired results.
+
+   BODYSTRUCTURE fetch data item
+            Use the non-extensible BODY data item.
+
+   body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT
+            Use body section numbers only.
+
+   BODY.PEEK[section]
+            Use BODY[section] and manually clear the \Seen flag as
+            necessary.
+
+
+
+
+
+Crispin                      Informational                      [Page 2]
+
+RFC 2061                  IMAP4 Compatibility              December 1996
+
+
+   FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
+            Use the corresponding non-SILENT versions and ignore the
+            untagged FETCH responses which come back.
+
+   UID fetch data item and the UID commands
+            No functional equivalent.
+
+   CLOSE command
+            No functional equivalent.
+
+
+   In IMAP2bis, the TRYCREATE special information token is sent as a
+   separate unsolicited OK response instead of inside the NO response.
+
+   IMAP2bis is ambiguous about whether or not flags or internal dates
+   are preserved on COPY.  It is impossible to know what behavior is
+   supported by the server.
+
+IMAP4 server interoperability with IMAP2bis clients
+
+   The only interoperability problem between an IMAP4 server and a
+   well-written IMAP2bis client is an incompatibility with the use of
+   "\" in quoted strings.  This is best avoided by using literals
+   instead of quoted strings if "\" or <"> is embedded in the string.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Aveneue NE
+   Seattle, WA  98105-4527
+
+   Phone: (206) 543-5762
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 3]
+
diff --git a/RFC/rfc2062.txt b/RFC/rfc2062.txt
new file mode 100644
index 00000000..865d1dad
--- /dev/null
+++ b/RFC/rfc2062.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 2062                      University of Washington
+Category: Informational                                    December 1996
+
+
+           Internet Message Access Protocol - Obsolete Syntax
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document describes obsolete syntax which may be encountered by
+   IMAP4 implementations which deal with older versions of the Internet
+   Mail Access Protocol.  IMAP4 implementations MAY implement this
+   syntax in order to maximize interoperability with older
+   implementations.
+
+   This document repeats information from earlier documents, most
+   notably RFC 1176 and RFC 1730.
+
+Obsolete Commands and Fetch Data Items
+
+   The following commands are OBSOLETE.  It is NOT required to support
+   any of these commands or fetch data items in new server
+   implementations.  These commands are documented here for the benefit
+   of implementors who may wish to support them for compatibility with
+   old client implementations.
+
+   The section headings of these commands are intended to correspond
+   with where they would be located in the main document if they were
+   not obsoleted.
+
+6.3.OBS.1.      FIND ALL.MAILBOXES Command
+
+   Arguments:  mailbox name with possible wildcards
+
+   Data:       untagged responses: MAILBOX
+
+   Result:     OK - find completed
+               NO - find failure: can't list that name
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+
+Crispin                      Informational                      [Page 1]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+      The FIND ALL.MAILBOXES command returns a subset of names from the
+      complete set of all names available to the user.  It returns zero
+      or more untagged MAILBOX replies.  The mailbox argument to FIND
+      ALL.MAILBOXES is similar to that for LIST with an empty reference,
+      except that the characters "%" and "?" match a single character.
+
+   Example:    C: A002 FIND ALL.MAILBOXES *
+               S: * MAILBOX blurdybloop
+               S: * MAILBOX INBOX
+               S: A002 OK FIND ALL.MAILBOXES completed
+
+6.3.OBS.2.      FIND MAILBOXES Command
+
+   Arguments:  mailbox name with possible wildcards
+
+   Data:       untagged responses: MAILBOX
+
+   Result:     OK - find completed
+               NO - find failure: can't list that name
+               BAD - command unknown or arguments invalid
+
+      The FIND MAILBOXES command returns a subset of names from the set
+      of names that the user has declared as being "active" or
+      "subscribed".  It returns zero or more untagged MAILBOX replies.
+      The mailbox argument to FIND MAILBOXES is similar to that for LSUB
+      with an empty reference, except that the characters "%" and "?"
+      match a single character.
+
+   Example:    C: A002 FIND MAILBOXES *
+               S: * MAILBOX blurdybloop
+               S: * MAILBOX INBOX
+               S: A002 OK FIND MAILBOXES completed
+
+6.3.OBS.3.      SUBSCRIBE MAILBOX Command
+
+   Arguments:  mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - subscribe completed
+               NO - subscribe failure: can't subscribe to that name
+               BAD - command unknown or arguments invalid
+
+      The SUBSCRIBE MAILBOX command is identical in effect to the
+      SUBSCRIBE command.  A server which implements this command must be
+      able to distinguish between a SUBSCRIBE MAILBOX command and a
+      SUBSCRIBE command with a mailbox name argument of "MAILBOX".
+
+
+
+
+Crispin                      Informational                      [Page 2]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+   Example:    C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
+               S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
+               completed
+               C: A003 SUBSCRIBE MAILBOX
+               S: A003 OK SUBSCRIBE to MAILBOX completed
+
+
+6.3.OBS.4.      UNSUBSCRIBE MAILBOX Command
+
+   Arguments:  mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - unsubscribe completed
+               NO - unsubscribe failure: can't unsubscribe that name
+               BAD - command unknown or arguments invalid
+
+      The UNSUBSCRIBE MAILBOX command is identical in effect to the
+      UNSUBSCRIBE command.  A server which implements this command must
+      be able to distinguish between a UNSUBSCRIBE MAILBOX command and
+      an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
+
+   Example:    C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
+               S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
+               completed
+               C: A003 UNSUBSCRIBE MAILBOX
+               S: A003 OK UNSUBSCRIBE from MAILBOX completed
+
+6.4.OBS.1       PARTIAL Command
+
+   Arguments:  message sequence number
+               message data item name
+               position of first octet
+               number of octets
+
+   Data:       untagged responses: FETCH
+
+   Result:     OK - partial completed
+               NO - partial error: can't fetch that data
+               BAD - command unknown or arguments invalid
+
+      The PARTIAL command is equivalent to the associated FETCH command,
+      with the added functionality that only the specified number of
+      octets, beginning at the specified starting octet, are returned.
+      Only a single message can be fetched at a time.  The first octet
+      of a message, and hence the minimum for the starting octet, is
+      octet 1.
+
+
+
+
+Crispin                      Informational                      [Page 3]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+      The following FETCH items are valid data for PARTIAL: RFC822,
+      RFC822.HEADER, RFC822.TEXT, BODY[<section>], as well as any .PEEK
+      forms of these.
+
+      Any partial fetch that attempts to read beyond the end of the text
+      is truncated as appropriate.  If the starting octet is beyond the
+      end of the text, an empty string is returned.
+
+      The data are returned with the FETCH response.  There is no
+      indication of the range of the partial data in this response.  It
+      is not possible to stream multiple PARTIAL commands of the same
+      data item without processing and synchronizing at each step, since
+      streamed commands may be executed out of order.
+
+      There is no requirement that partial fetches follow any sequence.
+      For example, if a partial fetch of octets 1 through 10000 breaks
+      in an awkward place for BASE64 decoding, it is permitted to
+      continue with a partial fetch of 9987 through 19987, etc.
+
+      The handling of the \Seen flag is the same as in the associated
+      FETCH command.
+
+   Example:    C: A005 PARTIAL 4 RFC822 1 1024
+               S: * 1 FETCH (RFC822 {1024}
+               S: Return-Path: <gray@cac.washington.edu>
+               S: ...
+               S: .........  FLAGS (\Seen))
+               S: A005 OK PARTIAL completed
+
+6.4.5.OBS.1     Obsolete FETCH Data Items
+
+   The following FETCH data items are obsolete:
+
+      BODY[<...>0]   A body part number of 0 is the [RFC-822] header of
+                     the message.  BODY[0] is functionally equivalent to
+                     BODY[HEADER], differing in the syntax of the
+                     resulting untagged FETCH data (BODY[0] is
+                     returned).
+
+      RFC822.HEADER.LINES <header_list>
+                     Functionally equivalent to BODY.PEEK[HEADER.LINES
+                     <header_list>], differing in the syntax of the
+                     resulting untagged FETCH data (RFC822.HEADER is
+                     returned).
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 4]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+      RFC822.HEADER.LINES.NOT <header_list>
+                     Functionally equivalent to
+                     BODY.PEEK[HEADER.LINES.NOT <header_list>],
+                     differing in the syntax of the resulting untagged
+                     FETCH data (RFC822.HEADER is returned).
+
+      RFC822.PEEK    Functionally equivalent to BODY.PEEK[], except for
+                     the syntax of the resulting untagged FETCH data
+                     (RFC822 is returned).
+
+      RFC822.TEXT.PEEK
+                     Functionally equivalent to BODY.PEEK[TEXT], except
+                     for the syntax of the resulting untagged FETCH data
+                     (RFC822.TEXT is returned).
+
+Obsolete Responses
+
+   The following responses are OBSOLETE.  Except as noted below, these
+   responses MUST NOT be transmitted by new server implementations.
+   Client implementations SHOULD accept these responses.
+
+   The section headings of these responses are intended to correspond
+   with where they would be located in the main document if they were
+   not obsoleted.
+
+7.2.OBS.1.      MAILBOX Response
+
+   Data:       name
+
+      The MAILBOX response MUST NOT be transmitted by server
+      implementations except in response to the obsolete FIND MAILBOXES
+      and FIND ALL.MAILBOXES commands.  Client implementations that do
+      not use these commands MAY ignore this response.  It is documented
+      here for the benefit of implementors who may wish to support it
+      for compatibility with old client implementations.
+
+      This response occurs as a result of the FIND MAILBOXES and FIND
+      ALL.MAILBOXES commands.  It returns a single name that matches the
+      FIND specification.  There are no attributes or hierarchy
+      delimiter.
+
+   Example:    S: * MAILBOX blurdybloop
+
+
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 5]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+7.3.OBS.1.      COPY Response
+
+   Data:       none
+
+      The COPY response MUST NOT be transmitted by new server
+      implementations.  Client implementations MUST ignore the COPY
+      response.  It is documented here for the benefit of client
+      implementors who may encounter this response from old server
+      implementations.
+
+      In some experimental versions of this protocol, this response was
+      returned in response to a COPY command to indicate on a
+      per-message basis that the message was copied successfully.
+
+   Example:    S: * 44 COPY
+
+7.3.OBS.2.      STORE Response
+
+   Data:       message data
+
+      The STORE response MUST NOT be transmitted by new server
+      implementations.  Client implementations MUST treat the STORE
+      response as equivalent to the FETCH response.  It is documented
+      here for the benefit of client implementors who may encounter this
+      response from old server implementations.
+
+      In some experimental versions of this protocol, this response was
+      returned instead of FETCH in response to a STORE command to report
+      the new value of the flags.
+
+   Example:    S: * 69 STORE (FLAGS (\Deleted))
+
+Formal Syntax of Obsolete Commands and Responses
+
+   Each obsolete syntax rule that is suffixed with "_old" is added to
+   the corresponding name in the formal syntax.  For example,
+   command_auth_old adds the FIND command to command_auth.
+
+   command_auth_old ::= find
+
+   command_select_old
+                   ::= partial
+
+   date_year_old   ::= 2digit
+                       ;; (year - 1900)
+
+   date_time_old   ::= <"> date_day_fixed "-" date_month "-" date_year
+                       SPACE time "-" zone_name <">
+
+
+
+Crispin                      Informational                      [Page 6]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+   find            ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
+                       list_mailbox
+
+   fetch_att_old   ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list /
+                       fetch_text_old
+
+   fetch_text_old  ::= "BODY" [".PEEK"] section_old /
+                       "RFC822" [".HEADER" / ".TEXT" [".PEEK"]]
+
+   msg_data_old    ::= "COPY" / ("STORE" SPACE msg_att)
+
+   partial         ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE
+                       number SPACE number
+
+   section_old     ::= "[" (number ["." number]) "]"
+
+   subscribe_old   ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+
+   unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+
+   zone_name       ::= "UT" / "GMT" / "Z" /                ;; +0000
+                       "AST" / "EDT" /                     ;; -0400
+                       "EST" / "CDT" /                     ;; -0500
+                       "CST" / "MDT" /                     ;; -0600
+                       "MST" / "PDT" /                     ;; -0700
+                       "PST" / "YDT" /                     ;; -0800
+                       "YST" / "HDT" /                     ;; -0900
+                       "HST" / "BDT" /                     ;; -1000
+                       "BST" /                             ;; -1100
+                       "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
+                       "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
+                       "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
+                       "T" / "U" / "V" / "W" / "X" / "Y"   ;; -7 to -12
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 7]
+
+RFC 2062                     IMAP4 Obsolete                December 1996
+
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Aveneue NE
+   Seattle, WA  98105-4527
+
+   Phone: (206) 543-5762
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                      Informational                      [Page 8]
+
diff --git a/RFC/rfc2177.txt b/RFC/rfc2177.txt
new file mode 100644
index 00000000..ef28fad3
--- /dev/null
+++ b/RFC/rfc2177.txt
@@ -0,0 +1,227 @@
+

+

+

+

+

+

+Network Working Group                                           B. Leiba

+Request for Comments: 2177               IBM T.J. Watson Research Center

+Category: Standards Track                                      June 1997

+

+

+                           IMAP4 IDLE command

+

+Status of this Memo

+

+   This document specifies an Internet standards track protocol for the

+   Internet community, and requests discussion and suggestions for

+   improvements.  Please refer to the current edition of the "Internet

+   Official Protocol Standards" (STD 1) for the standardization state

+   and status of this protocol.  Distribution of this memo is unlimited.

+

+1.   Abstract

+

+   The Internet Message Access Protocol [IMAP4] requires a client to

+   poll the server for changes to the selected mailbox (new mail,

+   deletions).  It's often more desirable to have the server transmit

+   updates to the client in real time.  This allows a user to see new

+   mail immediately.  It also helps some real-time applications based on

+   IMAP, which might otherwise need to poll extremely often (such as

+   every few seconds).  (While the spec actually does allow a server to

+   push EXISTS responses aysynchronously, a client can't expect this

+   behaviour and must poll.)

+

+   This document specifies the syntax of an IDLE command, which will

+   allow a client to tell the server that it's ready to accept such

+   real-time updates.

+

+2.   Conventions Used in this Document

+

+   In examples, "C:" and "S:" indicate lines sent by the client and

+   server respectively.

+

+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"

+   in this document are to be interpreted as described in RFC 2060

+   [IMAP4].

+

+3.   Specification

+

+   IDLE Command

+

+   Arguments:  none

+

+   Responses:  continuation data will be requested; the client sends

+               the continuation data "DONE" to end the command

+

+

+

+Leiba                       Standards Track                     [Page 1]

+

+RFC 2177                   IMAP4 IDLE command                  June 1997

+

+

+

+   Result:     OK - IDLE completed after client sent "DONE"

+               NO - failure: the server will not allow the IDLE

+                    command at this time

+              BAD - command unknown or arguments invalid

+

+   The IDLE command may be used with any IMAP4 server implementation

+   that returns "IDLE" as one of the supported capabilities to the

+   CAPABILITY command.  If the server does not advertise the IDLE

+   capability, the client MUST NOT use the IDLE command and must poll

+   for mailbox updates.  In particular, the client MUST continue to be

+   able to accept unsolicited untagged responses to ANY command, as

+   specified in the base IMAP specification.

+

+   The IDLE command is sent from the client to the server when the

+   client is ready to accept unsolicited mailbox update messages.  The

+   server requests a response to the IDLE command using the continuation

+   ("+") response.  The IDLE command remains active until the client

+   responds to the continuation, and as long as an IDLE command is

+   active, the server is now free to send untagged EXISTS, EXPUNGE, and

+   other messages at any time.

+

+   The IDLE command is terminated by the receipt of a "DONE"

+   continuation from the client; such response satisfies the server's

+   continuation request.  At that point, the server MAY send any

+   remaining queued untagged responses and then MUST immediately send

+   the tagged response to the IDLE command and prepare to process other

+   commands. As in the base specification, the processing of any new

+   command may cause the sending of unsolicited untagged responses,

+   subject to the ambiguity limitations.  The client MUST NOT send a

+   command while the server is waiting for the DONE, since the server

+   will not be able to distinguish a command from a continuation.

+

+   The server MAY consider a client inactive if it has an IDLE command

+   running, and if such a server has an inactivity timeout it MAY log

+   the client off implicitly at the end of its timeout period.  Because

+   of that, clients using IDLE are advised to terminate the IDLE and

+   re-issue it at least every 29 minutes to avoid being logged off.

+   This still allows a client to receive immediate mailbox updates even

+   though it need only "poll" at half hour intervals.

+

+

+

+

+

+

+

+

+

+

+

+Leiba                       Standards Track                     [Page 2]

+

+RFC 2177                   IMAP4 IDLE command                  June 1997

+

+

+   Example:    C: A001 SELECT INBOX

+               S: * FLAGS (Deleted Seen)

+               S: * 3 EXISTS

+               S: * 0 RECENT

+               S: * OK [UIDVALIDITY 1]

+               S: A001 OK SELECT completed

+               C: A002 IDLE

+               S: + idling

+               ...time passes; new mail arrives...

+               S: * 4 EXISTS

+               C: DONE

+               S: A002 OK IDLE terminated

+               ...another client expunges message 2 now...

+               C: A003 FETCH 4 ALL

+               S: * 4 FETCH (...)

+               S: A003 OK FETCH completed

+               C: A004 IDLE

+               S: * 2 EXPUNGE

+               S: * 3 EXISTS

+               S: + idling

+               ...time passes; another client expunges message 3...

+               S: * 3 EXPUNGE

+               S: * 2 EXISTS

+               ...time passes; new mail arrives...

+               S: * 3 EXISTS

+               C: DONE

+               S: A004 OK IDLE terminated

+               C: A005 FETCH 3 ALL

+               S: * 3 FETCH (...)

+               S: A005 OK FETCH completed

+               C: A006 IDLE

+

+4.   Formal Syntax

+

+   The following syntax specification uses the augmented Backus-Naur

+   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].

+   Non-terminals referenced but not defined below are as defined by

+   [IMAP4].

+

+   command_auth    ::= append / create / delete / examine / list / lsub /

+                       rename / select / status / subscribe / unsubscribe

+                       / idle

+                       ;; Valid only in Authenticated or Selected state

+

+   idle            ::= "IDLE" CRLF "DONE"

+

+

+

+

+

+

+Leiba                       Standards Track                     [Page 3]

+

+RFC 2177                   IMAP4 IDLE command                  June 1997

+

+

+5.   References

+

+   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version

+   4rev1", RFC 2060, December 1996.

+

+6.   Security Considerations

+

+   There are no known security issues with this extension.

+

+7.   Author's Address

+

+   Barry Leiba

+   IBM T.J. Watson Research Center

+   30 Saw Mill River Road

+   Hawthorne, NY  10532

+

+   Email: leiba@watson.ibm.com

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Leiba                       Standards Track                     [Page 4]

+

diff --git a/RFC/rfc2195.txt b/RFC/rfc2195.txt
new file mode 100644
index 00000000..4a2725bf
--- /dev/null
+++ b/RFC/rfc2195.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                       J. Klensin
+Request for Comments: 2195                                    R. Catoe
+Category: Standards Track                                 P. Krumviede
+Obsoletes: 2095                                                    MCI
+                                                        September 1997
+
+
+       IMAP/POP AUTHorize Extension for Simple Challenge/Response
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   While IMAP4 supports a number of strong authentication mechanisms as
+   described in RFC 1731, it lacks any mechanism that neither passes
+   cleartext, reusable passwords across the network nor requires either
+   a significant security infrastructure or that the mail server update
+   a mail-system-wide user authentication file on each mail access.
+   This specification provides a simple challenge-response
+   authentication protocol that is suitable for use with IMAP4.  Since
+   it utilizes Keyed-MD5 digests and does not require that the secret be
+   stored in the clear on the server, it may also constitute an
+   improvement on APOP for POP3 use as specified in RFC 1734.
+
+1. Introduction
+
+   Existing Proposed Standards specify an AUTHENTICATE mechanism for the
+   IMAP4 protocol [IMAP, IMAP-AUTH] and a parallel AUTH mechanism for
+   the POP3 protocol [POP3-AUTH].  The AUTHENTICATE mechanism is
+   intended to be extensible; the four methods specified in [IMAP-AUTH]
+   are all fairly powerful and require some security infrastructure to
+   support.  The base POP3 specification [POP3] also contains a
+   lightweight challenge-response mechanism called APOP.  APOP is
+   associated with most of the risks associated with such protocols: in
+   particular, it requires that both the client and server machines have
+   access to the shared secret in cleartext form. CRAM offers a method
+   for avoiding such cleartext storage while retaining the algorithmic
+   simplicity of APOP in using only MD5, though in a "keyed" method.
+
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 1]
+
+RFC 2195              IMAP/POP AUTHorize Extension        September 1997
+
+
+   At present, IMAP [IMAP] lacks any facility corresponding to APOP.
+   The only alternative to the strong mechanisms identified in [IMAP-
+   AUTH] is a presumably cleartext username and password, supported
+   through the LOGIN command in [IMAP].  This document describes a
+   simple challenge-response mechanism, similar to APOP and PPP CHAP
+   [PPP], that can be used with IMAP (and, in principle, with POP3).
+
+   This mechanism also has the advantage over some possible alternatives
+   of not requiring that the server maintain information about email
+   "logins" on a per-login basis.  While mechanisms that do require such
+   per-login history records may offer enhanced security, protocols such
+   as IMAP, which may have several connections between a given client
+   and server open more or less simultaneous, may make their
+   implementation particularly challenging.
+
+2. Challenge-Response Authentication Mechanism (CRAM)
+
+   The authentication type associated with CRAM is "CRAM-MD5".
+
+   The data encoded in the first ready response contains an
+   presumptively arbitrary string of random digits, a timestamp, and the
+   fully-qualified primary host name of the server.  The syntax of the
+   unencoded form must correspond to that of an RFC 822 'msg-id'
+   [RFC822] as described in [POP3].
+
+   The client makes note of the data and then responds with a string
+   consisting of the user name, a space, and a 'digest'.  The latter is
+   computed by applying the keyed MD5 algorithm from [KEYED-MD5] where
+   the key is a shared secret and the digested text is the timestamp
+   (including angle-brackets).
+
+   This shared secret is a string known only to the client and server.
+   The `digest' parameter itself is a 16-octet value which is sent in
+   hexadecimal format, using lower-case ASCII characters.
+
+   When the server receives this client response, it verifies the digest
+   provided.  If the digest is correct, the server should consider the
+   client authenticated and respond appropriately.
+
+   Keyed MD5 is chosen for this application because of the greater
+   security imparted to authentication of short messages. In addition,
+   the use of the techniques described in [KEYED-MD5] for precomputation
+   of intermediate results make it possible to avoid explicit cleartext
+   storage of the shared secret on the server system by instead storing
+   the intermediate results which are known as "contexts".
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 2]
+
+RFC 2195              IMAP/POP AUTHorize Extension        September 1997
+
+
+   CRAM does not support a protection mechanism.
+
+   Example:
+
+   The examples in this document show the use of the CRAM mechanism with
+   the IMAP4 AUTHENTICATE command [IMAP-AUTH].  The base64 encoding of
+   the challenges and responses is part of the IMAP4 AUTHENTICATE
+   command, not part of the CRAM specification itself.
+
+     S: * OK IMAP4 Server
+     C: A0001 AUTHENTICATE CRAM-MD5
+     S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
+     C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
+     S: A0001 OK CRAM authentication successful
+
+      In this example, the shared secret is the string
+      'tanstaaftanstaaf'.  Hence, the Keyed MD5 digest is produced by
+      calculating
+
+        MD5((tanstaaftanstaaf XOR opad),
+            MD5((tanstaaftanstaaf XOR ipad),
+            <1896.697170952@postoffice.reston.mci.net>))
+
+      where ipad and opad are as defined in the keyed-MD5 Work in
+      Progress [KEYED-MD5] and the string shown in the challenge is the
+      base64 encoding of <1896.697170952@postoffice.reston.mci.net>. The
+      shared secret is null-padded to a length of 64 bytes. If the
+      shared secret is longer than 64 bytes, the MD5 digest of the
+      shared secret is used as a 16 byte input to the keyed MD5
+      calculation.
+
+      This produces a digest value (in hexadecimal) of
+
+           b913a602c7eda7a495b4e6e7334d3890
+
+      The user name is then prepended to it, forming
+
+           tim b913a602c7eda7a495b4e6e7334d3890
+
+      Which is then base64 encoded to meet the requirements of the IMAP4
+      AUTHENTICATE command (or the similar POP3 AUTH command), yielding
+
+           dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
+
+
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 3]
+
+RFC 2195              IMAP/POP AUTHorize Extension        September 1997
+
+
+3. References
+
+   [CHAP]  Lloyd, B., and W. Simpson, "PPP Authentication Protocols",
+       RFC 1334, October 1992.
+
+   [IMAP] Crispin, M., "Internet Message Access Protocol - Version
+       4rev1", RFC 2060, University of Washington, December 1996.
+
+   [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms",
+       RFC 1731, Carnegie Mellon, December 1994.
+
+   [KEYED-MD5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
+       Message Authentication", RFC 2104, February 1997.
+
+   [MD5]  Rivest, R., "The MD5 Message Digest Algorithm",
+       RFC 1321, MIT Laboratory for Computer Science, April 1992.
+
+   [POP3] Myers, J., and M. Rose, "Post Office Protocol - Version 3",
+       STD 53, RFC 1939, Carnegie Mellon, May 1996.
+
+   [POP3-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
+       Carnegie Mellon, December, 1994.
+
+4. Security Considerations
+
+   It is conjectured that use of the CRAM authentication mechanism
+   provides origin identification and replay protection for a session.
+   Accordingly, a server that implements both a cleartext password
+   command and this authentication type should not allow both methods of
+   access for a given user.
+
+   While the saving, on the server, of "contexts" (see section 2) is
+   marginally better than saving the shared secrets in cleartext as is
+   required by CHAP [CHAP] and APOP [POP3], it is not sufficient to
+   protect the secrets if the server itself is compromised.
+   Consequently, servers that store the secrets or contexts must both be
+   protected to a level appropriate to the potential information value
+   in user mailboxes and identities.
+
+   As the length of the shared secret increases, so does the difficulty
+   of deriving it.
+
+   While there are now suggestions in the literature that the use of MD5
+   and keyed MD5 in authentication procedures probably has a limited
+   effective lifetime, the technique is now widely deployed and widely
+   understood.  It is believed that this general understanding may
+   assist with the rapid replacement, by CRAM-MD5, of the current uses
+   of permanent cleartext passwords in IMAP.   This document has been
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 4]
+
+RFC 2195              IMAP/POP AUTHorize Extension        September 1997
+
+
+   deliberately written to permit easy upgrading to use SHA (or whatever
+   alternatives emerge) when they are considered to be widely available
+   and adequately safe.
+
+   Even with the use of CRAM, users are still vulnerable to active
+   attacks.  An example of an increasingly common active attack is 'TCP
+   Session Hijacking' as described in CERT Advisory CA-95:01 [CERT95].
+
+   See section 1 above for additional discussion.
+
+5. Acknowledgements
+
+   This memo borrows ideas and some text liberally from [POP3] and
+   [RFC-1731] and thanks are due the authors of those documents.  Ran
+   Atkinson made a number of valuable technical and editorial
+   contributions to the document.
+
+6. Authors' Addresses
+
+   John C. Klensin
+   MCI Telecommunications
+   800 Boylston St, 7th floor
+   Boston, MA 02199
+   USA
+
+   EMail: klensin@mci.net
+   Phone: +1 617 960 1011
+
+   Randy Catoe
+   MCI Telecommunications
+   2100 Reston Parkway
+   Reston, VA 22091
+   USA
+
+   EMail: randy@mci.net
+   Phone: +1 703 715 7366
+
+   Paul Krumviede
+   MCI Telecommunications
+   2100 Reston Parkway
+   Reston, VA 22091
+   USA
+
+   EMail: paul@mci.net
+   Phone: +1 703 715 7251
+
+
+
+
+
+
+Klensin, Catoe & Krumviede  Standards Track                     [Page 5]
+
diff --git a/RFC/rfc2449.txt b/RFC/rfc2449.txt
new file mode 100644
index 00000000..dbea10b2
--- /dev/null
+++ b/RFC/rfc2449.txt
@@ -0,0 +1,1067 @@
+

+

+

+

+

+

+Network Working Group                                         R. Gellens

+Request for Comments: 2449                                      Qualcomm

+Updates: 1939                                                  C. Newman

+Category: Standards Track                                       Innosoft

+                                                            L. Lundblade

+                                                                Qualcomm

+                                                           November 1998

+

+

+                        POP3 Extension Mechanism

+

+Status of this Memo

+

+   This document specifies an Internet standards track protocol for the

+   Internet community, and requests discussion and suggestions for

+   improvements.  Please refer to the current edition of the "Internet

+   Official Protocol Standards" (STD 1) for the standardization state

+   and status of this protocol.  Distribution of this memo is unlimited.

+

+Copyright Notice

+

+   Copyright (C) The Internet Society (1998).  All Rights Reserved.

+

+IESG Note

+

+   This extension to the POP3 protocol is to be used by a server to

+   express policy descisions taken by the server administrator.  It is

+   not an endorsement of implementations of further POP3 extensions

+   generally.  It is the general view that the POP3 protocol should stay

+   simple, and for the simple purpose of downloading email from a mail

+   server.  If more complicated operations are needed, the IMAP protocol

+   [RFC 2060] should be used.  The first paragraph of section 7 should

+   be read very carefully.

+

+Table of Contents

+

+    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2

+    2.  Conventions Used in this Document . . . . . . . . . . . . .   3

+    3.  General Command and Response Grammar . . . . . . . . . . . .  3

+    4.  Parameter and Response Lengths  . . . . . . . . . . . . . .   4

+    5.  The CAPA Command . . . . . . . . . . . . . . . . . . . . . .  4

+    6.  Initial Set of Capabilities . . . . . . . . . . . . . . . .   5

+      6.1.  TOP capability . . . . . . . . . . . . . . . . . . . . .  6

+      6.2.  USER capability . . . . . . . . . . . . . . . . . . . .   6

+      6.3.  SASL capability  . . . . . . . . . . . . . . . . . . . .  7

+      6.4.  RESP-CODES capability . . . . . . . . . . . . . . . . .   8

+      6.5.  LOGIN-DELAY capability . . . . . . . . . . . . . . . . .  8

+      6.6.  PIPELINING capability . . . . . . . . . . . . . . . . .   9

+

+

+

+Gellens, et. al.            Standards Track                     [Page 1]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+      6.7.  EXPIRE capability  . . . . . . . . . . . . . . . . . . . 10

+      6.8.  UIDL capability . . . . . . . . . . . . . . . . . . . .  13

+      6.9.  IMPLEMENTATION capability  . . . . . . . . . . . . . . . 13

+    7.  Future Extensions to POP3 . . . . . . . . . . . . . . . . .  14

+    8.  Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14

+      8.1.  Initial POP3 response codes . . . . . . . . . . . . . .  15

+        8.1.1.  The LOGIN-DELAY response code  . . . . . . . . . . . 15

+        8.1.2.  The IN-USE response code  . . . . . . . . . . . . .  16

+    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16

+   10.  Security Considerations . . . . . . . . . . . . . . . . . .  17

+   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 17

+   12.  References  . . . . . . . . . . . . . . . . . . . . . . . .  17

+   13.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . .  18

+   14.  Full Copyright Statement . . . . . . . . . . . . . . . . . . 19

+

+1.  Introduction

+

+   The Post Office Protocol version 3 [POP3] is very widely used.

+   However, while it includes some optional commands (and some useful

+   protocol extensions have been published), it lacks a mechanism for

+   advertising support for these extensions or for behavior variations.

+

+   Currently these optional features and extensions can only be detected

+   by probing, if at all.  This is at best inefficient, and possibly

+   worse.  As a result, some clients have manual configuration options

+   for POP3 server capabilities.

+

+   Because one of the most important characteristics of POP3 is its

+   simplicity, it is desirable that extensions be few in number (see

+   section 7).  However, some extensions are necessary (such as ones

+   that provide improved security [POP-AUTH]), while others are very

+   desirable in certain situations.  In addition, a means for

+   discovering server behavior is needed.

+

+   This memo updates RFC 1939 [POP3] to define a mechanism to announce

+   support for optional commands, extensions, and unconditional server

+   behavior.  Included is an initial set of currently deployed

+   capabilities which vary between server implementations, and several

+   new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE

+   and IMPLEMENTATION).  This document also extends POP3 error messages

+   so that machine parsable codes can be provided to the client.  An

+   initial set of response codes is included.  In addition, an [ABNF]

+   specification of POP3 commands and responses is defined.

+

+   Public comments should be sent to the IETF POP3 Extensions mailing

+   list, <ietf-pop3ext@imc.org>.  To subscribe, send a message

+   containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.

+

+

+

+

+Gellens, et. al.            Standards Track                     [Page 2]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+2.  Conventions Used in this Document

+

+   The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",

+   and "MAY" in this document are to be interpreted as described in "Key

+   words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].

+

+   In examples, "C:" and "S:" indicate lines sent by the client and

+   server respectively.

+

+3.  General Command and Response Grammar

+

+   The general form of POP3 commands and responses is described using

+   [ABNF]:

+

+   POP3 commands:

+

+      command      =  keyword *(SP param) CRLF    ;255 octets maximum

+      keyword      =  3*4VCHAR

+      param        =  1*VCHAR

+

+   POP3 responses:

+

+      response     =  greeting / single-line / capa-resp / multi-line

+      capa-resp    =  single-line *capability "." CRLF

+      capa-tag     =  1*cchar

+      capability   =  capa-tag *(SP param) CRLF   ;512 octets maximum

+      cchar        =  %x21-2D / %x2F-7F

+                          ;printable ASCII, excluding "."

+      dot-stuffed  =  *CHAR CRLF                  ;must be dot-stuffed

+      gchar        =  %x21-3B / %x3D-7F

+                          ;printable ASCII, excluding "<"

+      greeting     =  "+OK" [resp-code] *gchar [timestamp] *gchar CRLF

+                          ;512 octets maximum

+      multi-line   =  single-line *dot-stuffed "." CRLF

+      rchar        =  %x21-2E / %x30-5C / %x5E-7F

+                          ;printable ASCII, excluding "/" and "]"

+      resp-code    =  "[" resp-level *("/" resp-level) "]"

+      resp-level   =  1*rchar

+      schar        =  %x21-5A / %x5C-7F

+                          ;printable ASCII, excluding "["

+      single-line  =  status [SP text] CRLF       ;512 octets maximum

+      status       =  "+OK" / "-ERR"

+      text         =  *schar / resp-code *CHAR

+      timestamp    =  "<" *VCHAR ">"

+                          ;MUST conform to RFC-822 msg-id

+

+

+

+

+

+

+Gellens, et. al.            Standards Track                     [Page 3]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+4.  Parameter and Response Lengths

+

+   This specification increases the length restrictions on commands and

+   parameters imposed by RFC 1939.

+

+   The maximum length of a command is increased from 47 characters (4

+   character command, single space, 40 character argument, CRLF) to 255

+   octets, including the terminating CRLF.

+

+   Servers which support the CAPA command MUST support commands up to

+   255 octets.  Servers MUST also support the largest maximum command

+   length specified by any supported capability.

+

+   The maximum length of the first line of a command response (including

+   the initial greeting) is unchanged at 512 octets (including the

+   terminating CRLF).

+

+5.  The CAPA Command

+

+   The POP3 CAPA command returns a list of capabilities supported by the

+   POP3 server.  It is available in both the AUTHORIZATION and

+   TRANSACTION states.

+

+   A capability description MUST document in which states the capability

+   is announced, and in which states the commands are valid.

+

+   Capabilities available in the AUTHORIZATION state MUST be announced

+   in both states.

+

+   If a capability is announced in both states, but the argument might

+   differ after authentication, this possibility MUST be stated in the

+   capability description.

+

+   (These requirements allow a client to issue only one CAPA command if

+   it does not use any TRANSACTION-only capabilities, or any

+   capabilities whose values may differ after authentication.)

+

+   If the authentication step negotiates an integrity protection layer,

+   the client SHOULD reissue the CAPA command after authenticating, to

+   check for active down-negotiation attacks.

+

+   Each capability may enable additional protocol commands, additional

+   parameters and responses for existing commands, or describe an aspect

+   of server behavior.  These details are specified in the description

+   of the capability.

+

+

+

+

+

+

+Gellens, et. al.            Standards Track                     [Page 4]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   Section 3 describes the CAPA response using [ABNF].  When a

+   capability response describes an optional command, the <capa-tag>

+   SHOULD be identical to the command keyword.  CAPA response tags are

+   case-insensitive.

+

+        CAPA

+

+        Arguments:

+            none

+

+        Restrictions:

+            none

+

+        Discussion:

+            An -ERR response indicates the capability command is not

+            implemented and the client will have to probe for

+            capabilities as before.

+

+            An +OK response is followed by a list of capabilities, one

+            per line.  Each capability name MAY be followed by a single

+            space and a space-separated list of parameters.  Each

+            capability line is limited to 512 octets (including the

+            CRLF).  The capability list is terminated by a line

+            containing a termination octet (".") and a CRLF pair.

+

+         Possible Responses:

+             +OK -ERR

+

+         Examples:

+             C: CAPA

+             S: +OK Capability list follows

+             S: TOP

+             S: USER

+             S: SASL CRAM-MD5 KERBEROS_V4

+             S: RESP-CODES

+             S: LOGIN-DELAY 900

+             S: PIPELINING

+             S: EXPIRE 60

+             S: UIDL

+             S: IMPLEMENTATION Shlemazle-Plotz-v302

+             S: .

+

+6.  Initial Set of Capabilities

+

+   This section defines an initial set of POP3 capabilities.  These

+   include the optional POP3 commands, already published POP3

+   extensions, and behavior variations between POP3 servers which can

+   impact clients.

+

+

+

+Gellens, et. al.            Standards Track                     [Page 5]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   Note that there is no APOP capability, even though APOP is an

+   optional command in [POP3].  Clients discover server support of APOP

+   by the presence in the greeting banner of an initial challenge

+   enclosed in angle brackets ("<>").  Therefore, an APOP capability

+   would introduce two ways for a server to announce the same thing.

+

+6.1.  TOP capability

+

+   CAPA tag:

+       TOP

+

+   Arguments:

+       none

+

+   Added commands:

+       TOP

+

+   Standard commands affected:

+       none

+

+   Announced states / possible differences:

+       both / no

+

+   Commands valid in states:

+       TRANSACTION

+

+   Specification reference:

+       [POP3]

+

+   Discussion:

+       The TOP capability indicates the optional TOP command is

+       available.

+

+6.2.  USER capability

+

+   CAPA tag:

+       USER

+

+   Arguments:

+       none

+

+   Added commands:

+       USER PASS

+

+   Standard commands affected:

+       none

+

+

+

+

+

+Gellens, et. al.            Standards Track                     [Page 6]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   Announced states / possible differences:

+       both / no

+

+   Commands valid in states:

+       AUTHENTICATION

+

+   Specification reference:

+       [POP3]

+

+   Discussion:

+       The USER capability indicates that the USER and PASS commands

+       are supported, although they may not be available to all users.

+

+6.3.  SASL capability

+

+   CAPA tag:

+       SASL

+

+   Arguments:

+       Supported SASL mechanisms

+

+   Added commands:

+       AUTH

+

+   Standard commands affected:

+       none

+

+   Announced states / possible differences:

+       both / no

+

+   Commands valid in states:

+       AUTHENTICATION

+

+   Specification reference:

+       [POP-AUTH, SASL]

+

+   Discussion:

+       The POP3 AUTH command [POP-AUTH] permits the use of [SASL]

+       authentication mechanisms with POP3.  The SASL capability

+       indicates that the AUTH command is available and that it supports

+       an optional base64 encoded second argument for an initial client

+       response as described in the SASL specification.  The argument to

+       the SASL capability is a space separated list of SASL mechanisms

+       which are supported.

+

+

+

+

+

+

+

+Gellens, et. al.            Standards Track                     [Page 7]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+6.4.  RESP-CODES capability

+

+   CAPA tag:

+       RESP-CODES

+

+   Arguments:

+       none

+

+   Added commands:

+       none

+

+   Standard commands affected:

+       none

+

+   Announced states / possible differences:

+       both / no

+

+   Commands valid in states:

+       n/a

+

+   Specification reference:

+       this document

+

+   Discussion:

+       The RESP-CODES capability indicates that any response text issued

+       by this server which begins with an open square bracket ("[") is

+       an extended response code (see section 8).

+

+6.5.  LOGIN-DELAY capability

+

+   CAPA tag:

+       LOGIN-DELAY

+

+   Arguments:

+       minimum seconds between logins; optionally followed by USER in

+       AUTHENTICATION state.

+

+   Added commands:

+       none

+

+   Standard commands affected:

+       USER PASS APOP AUTH

+

+   Announced states / possible differences:

+       both / yes

+

+   Commands valid in states:

+       n/a

+

+

+

+Gellens, et. al.            Standards Track                     [Page 8]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   Specification reference:

+       this document

+

+   Discussion:

+       POP3 clients often login frequently to check for new mail.

+       Unfortunately, the process of creating a connection,

+       authenticating the user, and opening the user's maildrop can be

+       very resource intensive on the server.  A number of deployed POP3

+       servers try to reduce server load by requiring a delay between

+       logins.  The LOGIN-DELAY capability includes an integer argument

+       which indicates the number of seconds after an "+OK" response to

+       a PASS, APOP, or AUTH command before another authentication will

+       be accepted.  Clients which permit the user to configure a mail

+       check interval SHOULD use this capability to determine the

+       minimum permissible interval.  Servers which advertise LOGIN-

+       DELAY SHOULD enforce it.

+

+       If the minimum login delay period could differ per user (that is,

+       the LOGIN-DELAY argument might change after authentication), the

+       server MUST announce in AUTHENTICATION state the largest value

+       which could be set for any user.  This might be the largest value

+       currently in use for any user (so only one value per server), or

+       even the largest value which the server permits to be set for any

+       user.  The server SHOULD append the token "USER" to the LOGIN-

+       DELAY parameter in AUTHENTICATION state, to inform the client

+       that a more accurate value is available after authentication.

+       The server SHOULD announce the more accurate value in TRANSACTION

+       state. (The "USER" token allows the client to decide if a second

+       CAPA command is needed or not.)

+

+       Servers enforce LOGIN-DELAY by rejecting an authentication

+       command with or without the LOGIN-DELAY error response.  See

+       section 8.1.1 for more information.

+

+6.6.  PIPELINING capability

+

+   CAPA tag:

+       PIPELINING

+

+   Arguments:

+       none

+

+   Added commands:

+       none

+

+   Standard commands affected:

+       all

+

+

+

+

+Gellens, et. al.            Standards Track                     [Page 9]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   Announced states / possible differences:

+       both / no

+

+   Commands valid in states:

+       n/a

+

+   Specification reference:

+       this document

+

+   Discussion:

+       The PIPELINING capability indicates the server is capable of

+       accepting multiple commands at a time; the client does not have

+       to wait for the response to a command before issuing a subsequent

+       command.  If a server supports PIPELINING, it MUST process each

+       command in turn.  If a client uses PIPELINING, it MUST keep track

+       of which commands it has outstanding, and match server responses

+       to commands in order.  If either the client or server uses

+       blocking writes, it MUST not exceed the window size of the

+       underlying transport layer.

+

+       Some POP3 clients have an option to indicate the server supports

+       "Overlapped POP3 commands." This capability removes the need to

+       configure this at the client.

+

+       This is roughly synonymous with the ESMTP PIPELINING extension

+       [PIPELINING], however, since SMTP [SMTP] tends to have short

+       commands and responses, the benefit is in grouping multiple

+       commands and sending them as a unit.  While there are cases of

+       this in POP (for example, USER and PASS could be batched,

+       multiple RETR and/or DELE commands could be sent as a group),

+       because POP has short commands and sometimes lengthy responses,

+       there is also an advantage is sending new commands while still

+       receiving the response to an earlier command (for example,

+       sending RETR and/or DELE commands while processing a UIDL reply).

+

+6.7.  EXPIRE capability

+

+   CAPA tag:

+       EXPIRE

+

+   Arguments:

+       server-guaranteed minimum retention days, or NEVER; optionally

+       followed by USER in AUTHENTICATION state

+

+   Added commands:

+       none

+

+

+

+

+

+Gellens, et. al.            Standards Track                    [Page 10]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   Standard commands affected:

+       none

+

+   Announced states / possible differences:

+       both / yes

+

+   Commands valid in states:

+       n/a

+

+   Specification reference:

+       this document

+

+   Discussion:

+       While POP3 allows clients to leave messages on the server, RFC

+       1939 [POP3] warns about the problems that may arise from this,

+       and allows servers to delete messages based on site policy.

+

+       The EXPIRE capability avoids the problems mentioned in RFC 1939,

+       by allowing the server to inform the client as to the policy in

+       effect.  The argument to the EXPIRE capability indicates the

+       minimum server retention period, in days, for messages on the

+       server.

+

+       EXPIRE 0 indicates the client is not permitted to leave mail on

+       the server; when the session enters the UPDATE state the server

+       MAY assume an implicit DELE for each message which was downloaded

+       with RETR.

+

+       EXPIRE NEVER asserts that the server does not delete messages.

+

+       The concept of a "retention period" is intentionally vague.

+       Servers may start counting days to expiration when a message is

+       added to a maildrop, when a client becomes aware of the existence

+       of a message through the LIST or UIDL commands, when a message

+       has been acted upon in some way (for example, TOP or RETR), or at

+       some other event.  The EXPIRE capability cannot provide a precise

+       indication as to exactly when any specific message will expire.

+       The capability is intended to make it easier for clients to

+       behave in ways which conform to site policy and user wishes.  For

+       example, a client might display a warning for attempts to

+       configure a "leave mail on server" period which is greater than

+       or equal to some percentage of the value announced by the server.

+

+       If a site uses any automatic deletion policy, it SHOULD use the

+       EXPIRE capability to announce this.

+

+

+

+

+

+

+Gellens, et. al.            Standards Track                    [Page 11]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+       The EXPIRE capability, with a parameter other than 0 or NEVER, is

+       intended to let the client know that the server does permit mail

+       to be left on the server, and to present a value which is the

+       smallest which might be in force.

+

+       Sites which permit users to retain messages indefinitely SHOULD

+       announce this with the EXPIRE NEVER response.

+

+       If the expiration policy differs per user (that is, the EXPIRE

+       argument might change after authentication), the server MUST

+       announce in AUTHENTICATION state the smallest value which could

+       be set for any user.  This might be the smallest value currently

+       in use for any user (so only one value per server), or even the

+       smallest value which the server permits to be set for any user.

+       The server SHOULD append the token "USER" to the EXPIRE parameter

+       in AUTHENTICATION state, to inform the client that a more

+       accurate value is available after authentication.  The server

+       SHOULD announce the more accurate value in TRANSACTION state.

+       (The "USER" token allows the client to decide if a second CAPA

+       command is needed or not.)

+

+       A site may have a message expiration policy which treats messages

+       differently depending on which user actions have been performed,

+       or based on other factors.  For example, a site might delete

+       unseen messages after 60 days, and completely- or partially-seen

+       messages after 15 days.

+

+       The announced EXPIRE value is the smallest retention period which

+       is or might be used by any category or condition of the current

+       site policy, for any user (in AUTHENTICATION state) or the

+       specific user (in TRANSACTION state).  That is, EXPIRE informs

+       the client of the minimum number of days messages may remain on

+       the server under any circumstances.

+

+       Examples:

+           EXPIRE 5 USER

+           EXPIRE 30

+           EXPIRE NEVER

+           EXPIRE 0

+

+       The first example indicates the server might delete messages

+       after five days, but the period differs per user, and so a more

+       accurate value can be obtained by issuing a second CAPA command

+       in TRANSACTION state.  The second example indicates the server

+       could delete messages after 30 days.  In the third example, the

+       server announces it does not delete messages.  The fourth example

+       specifies that the site does not permit messages to be left on

+       the server.

+

+

+

+Gellens, et. al.            Standards Track                    [Page 12]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+6.8.  UIDL capability

+

+   CAPA tag:

+       UIDL

+

+   Arguments:

+       none

+

+   Added commands:

+       UIDL

+

+   Standard commands affected:

+       none

+

+   Announced states / possible differences:

+       both / no

+

+   Commands valid in states:

+       TRANSACTION

+

+   Specification reference:

+       [POP3]

+

+   Discussion:

+       The UIDL capability indicates that the optional UIDL command is

+       supported.

+

+6.9.  IMPLEMENTATION capability

+

+   CAPA tag:

+       IMPLEMENTATION

+

+   Arguments:

+       string giving server implementation information

+

+   Added commands:

+       none

+

+   Standard commands affected:

+       none

+

+   Announced states / possible differences:

+       both (optionally TRANSACTION only) / no

+

+   Commands valid in states:

+       n/a

+

+

+

+

+

+Gellens, et. al.            Standards Track                    [Page 13]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   Specification reference:

+       this document

+

+   Discussion:

+       It is often useful to identify an implementation of a particular

+       server (for example, when logging).  This is commonly done in the

+       welcome banner, but one must guess if a string is an

+       implementation ID or not.

+

+       The argument to the IMPLEMENTATION capability consists of one or

+       more tokens which identify the server. (Note that since CAPA

+       response tag arguments are space-separated, it may be convenient

+       for the IMPLEMENTATION capability argument to not contain spaces,

+       so that it is a single token.)

+

+       Normally, servers announce IMPLEMENTATION in both states.

+       However, a server MAY chose to do so only in TRANSACTION state.

+

+       A server MAY include the implementation identification both in

+       the welcome banner and in the IMPLEMENTATION capability.

+

+       Clients MUST NOT modify their behavior based on the server

+       implementation.  Instead the server and client should agree on a

+       private extension.

+

+7.  Future Extensions to POP3

+

+   Future extensions to POP3 are in general discouraged, as POP3's

+   usefulness lies in its simplicity.  POP3 is intended as a download-

+   and-delete protocol; mail access capabilities are available in IMAP

+   [IMAP4].  Extensions which provide support for additional mailboxes,

+   allow uploading of messages to the server, or which deviate from

+   POP's download-and-delete model are strongly discouraged and unlikely

+   to be permitted on the IETF standards track.

+

+   Clients MUST NOT require the presence of any extension for basic

+   functionality, with the exception of the authentication commands

+   (APOP, AUTH [section 6.3] and USER/PASS).

+

+   Section 9 specifies how additional capabilities are defined.

+

+8.  Extended POP3 Response Codes

+

+   Unextended POP3 is only capable of indicating success or failure to

+   most commands.  Unfortunately, clients often need to know more

+   information about the cause of a failure in order to gracefully

+   recover.  This is especially important in response to a failed login

+

+

+

+

+Gellens, et. al.            Standards Track                    [Page 14]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   (there are widely-deployed clients which attempt to decode the error

+   text of a PASS command result, to try and distinguish between "unable

+   to get maildrop lock" and "bad login").

+

+   This specification amends the POP3 standard to permit an optional

+   response code, enclosed in square brackets, at the beginning of the

+   human readable text portion of an "+OK" or "-ERR" response.  Clients

+   supporting this extension MAY remove any information enclosed in

+   square brackets prior to displaying human readable text to the user.

+   Immediately following the open square bracket "[" character is a

+   response code which is interpreted in a case-insensitive fashion by

+   the client.

+

+   The response code is hierarchical, with a "/" separating levels of

+   detail about the error.  Clients MUST ignore unknown hierarchical

+   detail about the response code.  This is important, as it could be

+   necessary to provide further detail for response codes in the future.

+

+   Section 3 describes response codes using [ABNF].

+

+   If a server supports extended response codes, it indicates this by

+   including the RESP-CODES capability in the CAPA response.

+

+   Examples:

+           C: APOP mrose c4c9334bac560ecc979e58001b3e22fb

+           S: -ERR [IN-USE] Do you have another POP session running?

+

+8.1.  Initial POP3 response codes

+

+   This specification defines two POP3 response codes which can be used

+   to determine the reason for a failed login.  Section 9 specifies how

+   additional response codes are defined.

+

+8.1.1.  The LOGIN-DELAY response code

+

+   This occurs on an -ERR response to an AUTH, USER (see note), PASS or

+   APOP command and indicates that the user has logged in recently and

+   will not be allowed to login again until the login delay period has

+   expired.

+

+   NOTE:  Returning the LOGIN-DELAY response code to the USER command

+   avoids the work of authenticating the user but reveals to the client

+   that the specified user exists.  Unless the server is operating in an

+   environment where user names are not secret (for example, many

+   popular email clients advertise the POP server and user name in an

+   outgoing mail header), or where server access is restricted, or the

+   server can verify that the connection is to the same user, it is

+

+

+

+

+Gellens, et. al.            Standards Track                    [Page 15]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   strongly recommended that the server not issue this response code to

+   the USER command.  The server still saves the cost of opening the

+   maildrop, which in some environments is the most expensive step.

+

+8.1.2.  The IN-USE response code

+

+   This occurs on an -ERR response to an AUTH, APOP, or PASS command.

+   It indicates the authentication was successful, but the user's

+   maildrop is currently in use (probably by another POP3 client).

+

+9.  IANA Considerations

+

+   This document requests that IANA maintain two new registries:  POP3

+   capabilities and POP3 response codes.

+

+   New POP3 capabilities MUST be defined in a standards track or IESG

+   approved experimental RFC, and MUST NOT begin with the letter "X".

+

+   New POP3 capabilities MUST include the following information:

+        CAPA tag

+        Arguments

+        Added commands

+        Standard commands affected

+        Announced states / possible differences

+        Commands valid in states

+        Specification reference

+        Discussion

+

+   In addition, new limits for POP3 command and response lengths may

+   need to be included.

+

+   New POP3 response codes MUST be defined in an RFC or other permanent

+   and readily available reference, in sufficient detail so that

+   interoperability between independent implementations is possible.

+   (This is the "Specification Required" policy described in [IANA]).

+

+   New POP3 response code specifications MUST include the following

+   information: the complete response code, for which responses (+OK

+   or -ERR) and commands it is valid, and a definition of its meaning and

+   expected client behavior.

+

+

+

+

+

+

+

+

+

+

+

+Gellens, et. al.            Standards Track                    [Page 16]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+10.  Security Considerations

+

+   A capability list can reveal information about the server's

+   authentication mechanisms which can be used to determine if certain

+   attacks will be successful.  However, allowing clients to

+   automatically detect availability of stronger mechanisms and alter

+   their configurations to use them can improve overall security at a

+   site.

+

+   Section 8.1 discusses the security issues related to use of the

+   LOGIN-DELAY response code with the USER command.

+

+11.  Acknowledgments

+

+   This document has been revised in part based on comments and

+   discussions which took place on and off the IETF POP3 Extensions

+   mailing list.  The help of those who took the time to review this

+   memo and make suggestions is appreciated, especially that of Alexey

+   Melnikov, Harald Alvestrand, and Mike Gahrns.

+

+12.  References

+

+   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax

+                Specifications:  ABNF", RFC 2234, November 1997.

+

+   [IANA]       Narten, T. and H. Alvestrand, "Guidelines for Writing an

+                IANA Considerations Section in RFCs", BCP 26, RFC 2434,

+                October 1998.

+

+   [IMAP4]      Crispin, M., "Internet Message Access Protocol --

+                Version 4rev1", RFC 2060, December 1996.

+

+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate

+                Requirement Levels", BCP 14, RFC 2119, March 1997.

+

+   [PIPELINING] Freed, N., "SMTP Service Extension for Command

+                Pipelining", RFC 2197, September 1997.

+

+   [POP3]       Myers, J. and M. Rose, "Post Office Protocol -- Version

+                3", STD 53, RFC 1939, May 1996.

+

+   [POP-AUTH]   Myers, J., "POP3 AUTHentication command", RFC 1734,

+                December 1994.

+

+   [SASL]       Myers, J., "Simple Authentication and Security Layer

+                (SASL)", RFC 2222, October 1997.

+

+

+

+

+

+Gellens, et. al.            Standards Track                    [Page 17]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+   [SMTP]       Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC

+                821, August 1982.

+

+13.  Authors' Addresses

+

+   Randall Gellens

+   QUALCOMM Incorporated

+   6455 Lusk Blvd.

+   San Diego, CA  92121-2779

+   USA

+

+   Phone: +1 619 651 5115

+   Fax:   +1 619 845 7268

+   EMail: randy@qualcomm.com

+

+

+   Chris Newman

+   Innosoft International, Inc.

+   1050 Lakes Drive

+   West Covina, CA 91790

+   USA

+

+   EMail: chris.newman@innosoft.com

+

+

+   Laurence Lundblade

+   QUALCOMM Incorporated

+   6455 Lusk Blvd.

+   San Diego, Ca, 92121-2779

+   USA

+

+   Phone: +1 619 658 3584

+   Fax:   +1 619 845 7268

+   EMail: lgl@qualcomm.com

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Gellens, et. al.            Standards Track                    [Page 18]

+

+RFC 2449                POP3 Extension Mechanism           November 1998

+

+

+14.  Full Copyright Statement

+

+   Copyright (C) The Internet Society (1998).  All Rights Reserved.

+

+   This document and translations of it may be copied and furnished to

+   others, and derivative works that comment on or otherwise explain it

+   or assist in its implementation may be prepared, copied, published

+   and distributed, in whole or in part, without restriction of any

+   kind, provided that the above copyright notice and this paragraph are

+   included on all such copies and derivative works.  However, this

+   document itself may not be modified in any way, such as by removing

+   the copyright notice or references to the Internet Society or other

+   Internet organizations, except as needed for the purpose of

+   developing Internet standards in which case the procedures for

+   copyrights defined in the Internet Standards process must be

+   followed, or as required to translate it into languages other than

+   English.

+

+   The limited permissions granted above are perpetual and will not be

+   revoked by the Internet Society or its successors or assigns.

+

+   This document and the information contained herein is provided on an

+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Gellens, et. al.            Standards Track                    [Page 19]

+

diff --git a/RFC/rfc2554.txt b/RFC/rfc2554.txt
new file mode 100644
index 00000000..2922deae
--- /dev/null
+++ b/RFC/rfc2554.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                           J. Myers
+Request for Comments: 2554                       Netscape Communications
+Category: Standards Track                                     March 1999
+
+
+                         SMTP Service Extension
+                           for Authentication
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+
+1. Introduction
+
+   This document defines an SMTP service extension [ESMTP] whereby an
+   SMTP client may indicate an authentication mechanism to the server,
+   perform an authentication protocol exchange, and optionally negotiate
+   a security layer for subsequent protocol interactions.  This
+   extension is a profile of the Simple Authentication and Security
+   Layer [SASL].
+
+
+2. Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in "Key words for
+   use in RFCs to Indicate Requirement Levels" [KEYWORDS].
+
+
+3. The Authentication service extension
+
+
+   (1) the name of the SMTP service extension is "Authentication"
+
+   (2) the EHLO keyword value associated with this extension is "AUTH"
+
+
+
+
+Myers                       Standards Track                     [Page 1]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+   (3) The AUTH EHLO keyword contains as a parameter a space separated
+       list of the names of supported SASL mechanisms.
+
+   (4) a new SMTP verb "AUTH" is defined
+
+   (5) an optional parameter using the keyword "AUTH" is added to the
+       MAIL FROM command, and extends the maximum line length of the
+       MAIL FROM command by 500 characters.
+
+   (6) this extension is appropriate for the submission protocol
+       [SUBMIT].
+
+
+4. The AUTH command
+
+   AUTH mechanism [initial-response]
+
+     Arguments:
+         a string identifying a SASL authentication mechanism.
+         an optional base64-encoded response
+
+     Restrictions:
+         After an AUTH command has successfully completed, no more AUTH
+         commands may be issued in the same session.  After a successful
+         AUTH command completes, a server MUST reject any further AUTH
+         commands with a 503 reply.
+
+         The AUTH command is not permitted during a mail transaction.
+
+     Discussion:
+         The AUTH command indicates an authentication mechanism to the
+         server.  If the server supports the requested authentication
+         mechanism, it performs an authentication protocol exchange to
+         authenticate and identify the user.  Optionally, it also
+         negotiates a security layer for subsequent protocol
+         interactions.  If the requested authentication mechanism is not
+         supported, the server rejects the AUTH command with a 504
+         reply.
+
+         The authentication protocol exchange consists of a series of
+         server challenges and client answers that are specific to the
+         authentication mechanism.  A server challenge, otherwise known
+         as a ready response, is a 334 reply with the text part
+         containing a BASE64 encoded string.  The client answer consists
+         of a line containing a BASE64 encoded string.  If the client
+         wishes to cancel an authentication exchange, it issues a line
+         with a single "*".  If the server receives such an answer, it
+         MUST reject the AUTH command by sending a 501 reply.
+
+
+
+Myers                       Standards Track                     [Page 2]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+         The optional initial-response argument to the AUTH command is
+         used to save a round trip when using authentication mechanisms
+         that are defined to send no data in the initial challenge.
+         When the initial-response argument is used with such a
+         mechanism, the initial empty challenge is not sent to the
+         client and the server uses the data in the initial-response
+         argument as if it were sent in response to the empty challenge.
+         Unlike a zero-length client answer to a 334 reply, a zero-
+         length initial response is sent as a single equals sign ("=").
+         If the client uses an initial-response argument to the AUTH
+         command with a mechanism that sends data in the initial
+         challenge, the server rejects the AUTH command with a 535
+         reply.
+
+         If the server cannot BASE64 decode the argument, it rejects the
+         AUTH command with a 501 reply.  If the server rejects the
+         authentication data, it SHOULD reject the AUTH command with a
+         535 reply unless a more specific error code, such as one listed
+         in section 6, is appropriate.  Should the client successfully
+         complete the authentication exchange, the SMTP server issues a
+         235 reply.
+
+         The service name specified by this protocol's profile of SASL
+         is "smtp".
+
+         If a security layer is negotiated through the SASL
+         authentication exchange, it takes effect immediately following
+         the CRLF that concludes the authentication exchange for the
+         client, and the CRLF of the success reply for the server.  Upon
+         a security layer's taking effect, the SMTP protocol is reset to
+         the initial state (the state in SMTP after a server issues a
+         220 service ready greeting).  The server MUST discard any
+         knowledge obtained from the client, such as the argument to the
+         EHLO command, which was not obtained from the SASL negotiation
+         itself.  The client MUST discard any knowledge obtained from
+         the server, such as the list of SMTP service extensions, which
+         was not obtained from the SASL negotiation itself (with the
+         exception that a client MAY compare the list of advertised SASL
+         mechanisms before and after authentication in order to detect
+         an active down-negotiation attack).  The client SHOULD send an
+         EHLO command as the first command after a successful SASL
+         negotiation which results in the enabling of a security layer.
+
+         The server is not required to support any particular
+         authentication mechanism, nor are authentication mechanisms
+         required to support any security layers.  If an AUTH command
+         fails, the client may try another authentication mechanism by
+         issuing another AUTH command.
+
+
+
+Myers                       Standards Track                     [Page 3]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+         If an AUTH command fails, the server MUST behave the same as if
+         the client had not issued the AUTH command.
+
+         The BASE64 string may in general be arbitrarily long.  Clients
+         and servers MUST be able to support challenges and responses
+         that are as long as are generated by the authentication
+         mechanisms they support, independent of any line length
+         limitations the client or server may have in other parts of its
+         protocol implementation.
+
+     Examples:
+         S: 220 smtp.example.com ESMTP server ready
+         C: EHLO jgm.example.com
+         S: 250-smtp.example.com
+         S: 250 AUTH CRAM-MD5 DIGEST-MD5
+         C: AUTH FOOBAR
+         S: 504 Unrecognized authentication type.
+         C: AUTH CRAM-MD5
+         S: 334
+         PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
+         C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
+         S: 235 Authentication successful.
+
+
+
+5. The AUTH parameter to the MAIL FROM command
+
+   AUTH=addr-spec
+
+   Arguments:
+       An addr-spec containing the identity which submitted the message
+       to the delivery system, or the two character sequence "<>"
+       indicating such an identity is unknown or insufficiently
+       authenticated.  To comply with the restrictions imposed on ESMTP
+       parameters, the addr-spec is encoded inside an xtext.  The syntax
+       of an xtext is described in section 5 of [ESMTP-DSN].
+
+   Discussion:
+       The optional AUTH parameter to the MAIL FROM command allows
+       cooperating agents in a trusted environment to communicate the
+       authentication of individual messages.
+
+       If the server trusts the authenticated identity of the client to
+       assert that the message was originally submitted by the supplied
+       addr-spec, then the server SHOULD supply the same addr-spec in an
+       AUTH parameter when relaying the message to any server which
+       supports the AUTH extension.
+
+
+
+
+Myers                       Standards Track                     [Page 4]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+       A MAIL FROM parameter of AUTH=<> indicates that the original
+       submitter of the message is not known.  The server MUST NOT treat
+       the message as having been originally submitted by the client.
+
+       If the AUTH parameter to the MAIL FROM is not supplied, the
+       client has authenticated, and the server believes the message is
+       an original submission by the client, the server MAY supply the
+       client's identity in the addr-spec in an AUTH parameter when
+       relaying the message to any server which supports the AUTH
+       extension.
+
+       If the server does not sufficiently trust the authenticated
+       identity of the client, or if the client is not authenticated,
+       then the server MUST behave as if the AUTH=<> parameter was
+       supplied.  The server MAY, however, write the value of the AUTH
+       parameter to a log file.
+
+       If an AUTH=<> parameter was supplied, either explicitly or due to
+       the requirement in the previous paragraph, then the server MUST
+       supply the AUTH=<> parameter when relaying the message to any
+       server which it has authenticated to using the AUTH extension.
+
+       A server MAY treat expansion of a mailing list as a new
+       submission, setting the AUTH parameter to the mailing list
+       address or mailing list administration address when relaying the
+       message to list subscribers.
+
+       It is conforming for an implementation to be hard-coded to treat
+       all clients as being insufficiently trusted.  In that case, the
+       implementation does nothing more than parse and discard
+       syntactically valid AUTH parameters to the MAIL FROM command and
+       supply AUTH=<> parameters to any servers to which it
+       authenticates using the AUTH extension.
+
+   Examples:
+       C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com
+       S: 250 OK
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 5]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+6. Error Codes
+
+   The following error codes may be used to indicate various conditions
+   as described.
+
+   432 A password transition is needed
+
+   This response to the AUTH command indicates that the user needs to
+   transition to the selected authentication mechanism.  This typically
+   done by authenticating once using the PLAIN authentication mechanism.
+
+   534 Authentication mechanism is too weak
+
+   This response to the AUTH command indicates that the selected
+   authentication mechanism is weaker than server policy permits for
+   that user.
+
+   538 Encryption required for requested authentication mechanism
+
+   This response to the AUTH command indicates that the selected
+   authentication mechanism may only be used when the underlying SMTP
+   connection is encrypted.
+
+   454 Temporary authentication failure
+
+   This response to the AUTH command indicates that the authentication
+   failed due to a temporary server failure.
+
+   530 Authentication required
+
+   This response may be returned by any command other than AUTH, EHLO,
+   HELO, NOOP, RSET, or QUIT.  It indicates that server policy requires
+   authentication in order to perform the requested action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 6]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+7. Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [ABNF].
+
+   Except as noted otherwise, all alphabetic characters are case-
+   insensitive.  The use of upper or lower case characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   UPALPHA         = %x41-5A            ;; Uppercase: A-Z
+
+   LOALPHA         = %x61-7A            ;; Lowercase: a-z
+
+   ALPHA           = UPALPHA / LOALPHA  ;; case insensitive
+
+   DIGIT           = %x30-39            ;; Digits 0-9
+
+   HEXDIGIT        = %x41-46 / DIGIT    ;; hexidecimal digit (uppercase)
+
+   hexchar         = "+" HEXDIGIT HEXDIGIT
+
+   xchar           = %x21-2A / %x2C-3C / %x3E-7E
+                     ;; US-ASCII except for "+", "=", SPACE and CTL
+
+   xtext           = *(xchar / hexchar)
+
+   AUTH_CHAR       = ALPHA / DIGIT / "-" / "_"
+
+   auth_type       = 1*20AUTH_CHAR
+
+   auth_command    = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
+                     *(CRLF [base64]) CRLF
+
+   auth_param      = "AUTH=" xtext
+                       ;; The decoded form of the xtext MUST be either
+                       ;; an addr-spec or the two characters "<>"
+
+   base64          = base64_terminal /
+                     ( 1*(4base64_CHAR) [base64_terminal] )
+
+   base64_char     = UPALPHA / LOALPHA / DIGIT / "+" / "/"
+                     ;; Case-sensitive
+
+   base64_terminal = (2base64_char "==") / (3base64_char "=")
+
+   continue_req    = "334" SPACE [base64] CRLF
+
+
+
+
+Myers                       Standards Track                     [Page 7]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+   CR              = %x0C           ;; ASCII CR, carriage return
+
+   CRLF            = CR LF
+
+   CTL             = %x00-1F / %x7F ;; any ASCII control character and DEL
+
+   LF              = %x0A           ;; ASCII LF, line feed
+
+   SPACE           = %x20           ;; ASCII SP, space
+
+
+
+
+8. References
+
+   [ABNF]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [CRAM-MD5]  Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+               AUTHorize Extension for Simple Challenge/Response", RFC
+               2195, September 1997.
+
+   [ESMTP]     Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+               Crocker, "SMTP Service Extensions", RFC 1869, November
+               1995.
+
+   [ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
+               Notifications", RFC 1891, January 1996.
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [SUBMIT]    Gellens, R. and J. Klensin, "Message Submission", RFC
+               2476, December 1998.
+
+   [RFC821]    Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+               821, August 1982.
+
+   [RFC822]    Crocker, D., "Standard for the Format of ARPA Internet
+               Text Messages", STD 11, RFC 822, August 1982.
+
+
+
+
+
+
+
+
+Myers                       Standards Track                     [Page 8]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+9. Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+   If a client uses this extension to get an encrypted tunnel through an
+   insecure network to a cooperating server, it needs to be configured
+   to never send mail to that server when the connection is not mutually
+   authenticated and encrypted.  Otherwise, an attacker could steal the
+   client's mail by hijacking the SMTP connection and either pretending
+   the server does not support the Authentication extension or causing
+   all AUTH commands to fail.
+
+   Before the SASL negotiation has begun, any protocol interactions are
+   performed in the clear and may be modified by an active attacker.
+   For this reason, clients and servers MUST discard any knowledge
+   obtained prior to the start of the SASL negotiation upon completion
+   of a SASL negotiation which results in a security layer.
+
+   This mechanism does not protect the TCP port, so an active attacker
+   may redirect a relay connection attempt to the submission port
+   [SUBMIT].  The AUTH=<> parameter prevents such an attack from causing
+   an relayed message without an envelope authentication to pick up the
+   authentication of the relay client.
+
+   A message submission client may require the user to authenticate
+   whenever a suitable SASL mechanism is advertised.  Therefore, it may
+   not be desirable for a submission server [SUBMIT] to advertise a SASL
+   mechanism when use of that mechanism grants the client no benefits
+   over anonymous submission.
+
+   This extension is not intended to replace or be used instead of end-
+   to-end message signature and encryption systems such as S/MIME or
+   PGP.  This extension addresses a different problem than end-to-end
+   systems; it has the following key differences:
+
+      (1) it is generally useful only within a trusted enclave
+
+      (2) it protects the entire envelope of a message, not just the
+          message's body.
+
+      (3) it authenticates the message submission, not authorship of the
+          message content
+
+      (4) it can give the sender some assurance the message was
+          delivered to the next hop in the case where the sender
+          mutually authenticates with the next hop and negotiates an
+          appropriate security layer.
+
+
+
+
+Myers                       Standards Track                     [Page 9]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+   Additional security considerations are mentioned in the SASL
+   specification [SASL].
+
+
+
+10. Author's Address
+
+   John Gardiner Myers
+   Netscape Communications
+   501 East Middlefield Road
+   Mail Stop MV-029
+   Mountain View, CA 94043
+
+   EMail: jgmyers@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 10]
+
+RFC 2554                  SMTP Authentication                 March 1999
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers                       Standards Track                    [Page 11]
+
diff --git a/RFC/rfc2645.txt b/RFC/rfc2645.txt
new file mode 100644
index 00000000..cb99fc84
--- /dev/null
+++ b/RFC/rfc2645.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gellens
+Request for Comments: 2645                                     Qualcomm
+Category: Standards Track                                   August 1999
+
+
+                      ON-DEMAND MAIL RELAY (ODMR)
+                    SMTP with Dynamic IP Addresses
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Table of Contents
+
+    1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  1
+    2.  Conventions Used in this Document . . . . . . . . . . . . . . 2
+    3.  Comments . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+    4.  Description . . . . . . . . . . . . . . . . . . . . . . . . . 2
+    5.  States . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+      5.1.  Initial State . . . . . . . . . . . . . . . . . . . . . . 4
+        5.1.1.  EHLO . . . . . . . . . . . . . . . . . . . . . . . .  4
+        5.1.2.  AUTH  . . . . . . . . . . . . . . . . . . . . . . . . 4
+        5.1.3.  QUIT . . . . . . . . . . . . . . . . . . . . . . . .  4
+      5.2.  Authenticated State . . . . . . . . . . . . . . . . . . . 4
+        5.2.1.  ATRN (Authenticated TURN)  . . . . . . . . . . . . .  4
+      5.3.  Reversed State  . . . . . . . . . . . . . . . . . . . . . 5
+      5.4.  Other Commands . . . . . . . . . . . . . . . . . . . . .  6
+    6.  Example On-Demand Mail Relay Session: . . . . . . . . . . . . 6
+    7.  Response Codes . . . . . . . . . . . . . . . . . . . . . . .  6
+    8.  Security Considerations . . . . . . . . . . . . . . . . . . . 6
+    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  7
+   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 7
+   11.  Author's Address   . . . . . . . . . . . . . . . . . . . . .  8
+   12.  Full Copyright Statement  . . . . . . . . . . . . . . . . . . 9
+
+1.  Abstract
+
+   With the spread of low-cost computer systems and Internet
+   connectivity, the demand for local mail servers has been rising.
+   Many people now want to operate a mail server on a system which has
+
+
+
+Gellens                     Standards Track                     [Page 1]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   only an intermittent connection to a service provider.  If the system
+   has a static IP address, the ESMTP ETRN command [ETRN] can be used.
+   However, systems with dynamic IP addresses (which are very common
+   with low-cost connections) have no widely-deployed solution.
+
+   This memo proposes a new service, On-Demand Mail Relay (ODMR), which
+   is a profile of SMTP [SMTP, ESMTP], providing for a secure,
+   extensible, easy to implement approach to the problem.
+
+2.  Conventions Used in this Document
+
+   Because the client and server roles reverse during the session, to
+   avoid confusion, the terms "customer" and "provider" will be used in
+   place of "client" and "server", although of course this protocol may
+   be useful in cases other than commercial service providers and
+   customers.
+
+   In examples, "P:" is used to indicate lines sent by the provider, and
+   "C:" indicates those sent by the customer.  Line breaks within a
+   command are for editorial purposes only.
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as defined in [KEYWORDS].
+
+   Examples use 'example.net' as the provider, and 'example.org' and '
+   example.com' as the customers.
+
+3.  Comments
+
+   Private comments should be sent to the author.  Public comments may
+   be sent to the IETF Disconnected SMTP mailing list,
+   <ietf-disconn-smtp@imc.org>.  To subscribe, send a message to
+   <ietf-disconn-smtp-request@imc.org> containing the word SUBSCRIBE as
+   the body.
+
+4.  Description
+
+   On-Demand Mail Relay is a restricted profile of SMTP [SMTP, ESMTP].
+   Port 366 is reserved for On-Demand Mail Relay.  The initial client
+   and server roles are short-lived, as the point is to allow the
+   intermittently-connected host to request mail held for it by a
+   service provider.
+
+   The customer initiates a connection to the provider, authenticates,
+   and requests its mail.  The roles of client and server then reverse,
+   and normal SMTP [SMTP, ESMTP] proceeds.
+
+
+
+
+
+Gellens                     Standards Track                     [Page 2]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   The provider has an On-Demand Mail Relay process listening for
+   connections on the ODMR port.  This process does not need to be a
+   full SMTP server.  It does need to be an SMTP client with access to
+   the outgoing mail queues, and as a server implement the EHLO, AUTH,
+   ATRN, and QUIT commands.
+
+   An MTA normally has a mail client component which processes the
+   outgoing mail queues, attempting to send mail for particular domains,
+   based on time or event (such as new mail being placed in the queue,
+   or receipt of an ETRN command by the SMTP server component).  The
+   On-Demand Mail Relay service processes the outgoing queue not on a
+   timer or new mail creation, but on request.
+
+   The provider side has normal SMTP server responsibilities [SMTP],
+   including generation of delivery failure notices, etc. as needed.
+
+5.  States
+
+   The On-Demand Mail Relay service has three states: an initial state,
+   an authenticated state, and a reversed state.  The state progression
+   is illustrated in the following diagram:
+
+   ---------------------------
+   !      initial state      !
+   ---------------------------
+     !             !
+   QUIT           AUTH
+     !             !
+     !             V
+     !      -----------------------
+     !      ! authenticated state !
+     !      -----------------------
+     !       !            !
+     !      QUIT         ATRN
+     !       !            !
+     !       !            V
+     !       !      ------------------
+     !       !      ! reversed state !
+     !       !      ------------------
+     !       !         !
+     !       !        QUIT
+     !       !         !
+     V       V         V
+     ---------------------
+     !    termination    !
+     ---------------------
+
+
+
+
+
+Gellens                     Standards Track                     [Page 3]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   (Note that in the reversed state, commands are sent by the provider,
+   not the customer.)
+
+5.1.  Initial State
+
+   In the initial state, the provider is the server and the customer is
+   the client.  Three commands are valid:  EHLO, AUTH, and QUIT.
+
+5.1.1.  EHLO
+
+   The EHLO command is the same as in [ESMTP].  The response MUST
+   include AUTH and ATRN.
+
+5.1.2.  AUTH
+
+   The AUTH command is specified in [AUTH].  The AUTH command uses a
+   [SASL] mechanism to authenticate the session.  The session is not
+   considered authenticated until a success response to AUTH has been
+   sent.
+
+   For interoperability, implementations MUST support the CRAM-MD5
+   mechanism [CRAM].  Other SASL mechanisms may be supported.  A site
+   MAY disable CRAM-MD5 support if it uses more secure methods.  The
+   EXTERNAL mechanism [SASL] might be useful in some cases, for example,
+   if the provider has already authenticated the client, such as during
+   a PPP connection.
+
+5.1.3.  QUIT
+
+   The QUIT command is the same as in [SMTP].
+
+5.2.  Authenticated State
+
+   The authenticated state is entered after a successful AUTH command.
+   Two commands are valid in the authenticated state:  ATRN and QUIT.
+
+5.2.1.  ATRN (Authenticated TURN)
+
+   Unlike the TURN command in [SMTP], the ATRN command optionally takes
+   one or more domains as a parameter.  The ATRN command MUST be
+   rejected if the session has not been authenticated.  Response code
+   530 [AUTH] is used for this.
+
+   The timeout for this command MUST be at least 10 minutes to allow the
+   provider time to process its mail queue.
+
+   An ATRN command sent with no domains is equivalent to an ATRN command
+   specifying all domains to which the customer has access.
+
+
+
+Gellens                     Standards Track                     [Page 4]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   If the authentication used by the customer does not provide access to
+   all of the domains specified in ATRN, the provider MUST NOT send mail
+   for any domains to the customer; the provider MUST reject the ATRN
+   command with a 450 code.
+
+   If the customer does have access to all of the specified domains, but
+   none of them have any queued mail, the provider normally rejects the
+   ATRN command with response code 453.  The provider MAY instead issue
+   a 250 success code, and after the roles are reversed, send a QUIT
+   following the EHLO.
+
+   The provider MAY also reject the ATRN command with a 450 response to
+   indicate refusal to accept multiple requests issued within a
+   particular time interval.
+
+   If the customer has access to all of the specified domains and mail
+   exists in at least one of them, the provider issues a 250 success
+   code.
+
+   If the server is unable to verify access to the requested domains
+   (for example, a mapping database is temporarily unavailable),
+   response code 451 is sent.
+
+      [ABNF] for ATRN:
+
+      atrn          = "ATRN" [SP domain *("," domain)]
+
+      domain        = sub-domain 1*("." sub-domain)
+
+      sub-domain    = (ALPHA / DIGIT) *(ldh-str)
+
+      ldh-str       = *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)
+
+5.3.  Reversed State
+
+   After the provider has sent a success reply to the ATRN command, the
+   roles reverse, and the customer becomes the server, and the provider
+   becomes the client.
+
+   After receiving the success response to ATRN, the customer sends a
+   standard SMTP initial greeting line.  At this point normal SMTP
+   [SMTP, ESMTP] commands are used.  Typically the provider sends EHLO
+   after seeing the customer's greeting, to be followed by MAIL FROM and
+   so on.
+
+
+
+
+
+
+
+Gellens                     Standards Track                     [Page 5]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+5.4.  Other Commands
+
+   The provider MAY reject all commands other than EHLO, AUTH, ATRN, and
+   QUIT with response code 502.
+
+6.  Example On-Demand Mail Relay Session
+
+      P:  220 EXAMPLE.NET on-demand mail relay server ready
+      C:  EHLO example.org
+      P:  250-EXAMPLE.NET
+      P:  250-AUTH CRAM-MD5 EXTERNAL
+      P:  250 ATRN
+      C:  AUTH CRAM-MD5
+      P:  334 MTg5Ni42OTcxNzA5NTJASVNQLkNPTQo=
+      C:  Zm9vYmFyLm5ldCBiOTEzYTYwMmM3ZWRhN2E0OTViNGU2ZTczMzRkMzg5MAo=
+      P:  235 now authenticated as example.org
+      C:  ATRN example.org,example.com
+      P:  250 OK now reversing the connection
+      C:  220 example.org ready to receive email
+      P:  EHLO EXAMPLE.NET
+      C:  250-example.org
+      C:  250 SIZE
+      P:  MAIL FROM: <Lester.Tester@dot.foo.bar>
+      C:  250 OK
+      P:  RCPT TO: <l.eva.msg@example.com>
+      C:  250 OK, recipient accepted
+      ...
+      P:  QUIT
+      C:  221 example.org closing connection
+
+7.  Response Codes
+
+   The response codes used in this document are:
+
+   250  Requested mail action okay, completed
+   450  ATRN request refused
+   451  Unable to process ATRN request now
+   453  You have no mail
+   502  Command not implemented
+   530  Authentication required [AUTH]
+
+8.  Security Considerations
+
+   Because access to the On-Demand Mail Relay server is only useful with
+   a prior arrangement between the parties (so the provider is the
+   target of MX records for the customer's domains and thus has mail to
+   relay), it may be useful for the provider to restrict access to the
+   On-Demand Mail Relay port.  For example, the ODMR server could be
+
+
+
+Gellens                     Standards Track                     [Page 6]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+   configurable, or a TCP wrapper or firewall could be used, to block
+   access to port 366 except within the provider's network.  This might
+   be useful when the provider is the customer's ISP.  Use of such
+   mechanisms does not reduce the need for the AUTH command, however,
+   but can increase the security it provides.
+
+   Use of SASL in the AUTH command allows for substitution of more
+   secure authentication mechanisms in the future.
+
+   See sections 5.1.2 and 5.2.1 for additional security details.
+
+9.  Acknowledgments
+
+   This memo has been developed in part based on comments and
+   discussions which took place on and off the IETF-disconn-smtp mailing
+   list.  Special thanks to Chris Newman and Ned Freed for their
+   comments.
+
+10.  References
+
+   [ABNF]      Crocker, D. and P. Overell,  "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 2234, November 1997.
+
+   [AUTH]      Myers, J., "SMTP Service Extension for Authentication",
+               RFC 2554, March 1999.
+
+   [CRAM]      Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP
+               AUTHorize Extension for Simple Challenge/Response", RFC
+               2195, September 1997.
+
+   [ESMTP]     Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+               Crocker, "SMTP Service Extensions", RFC 1869, November
+               1995.
+
+   [ETRN]      De Winter, J., "SMTP Service Extension for Remote Message
+               Queue Starting", RFC 1985, August 1996.
+
+   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SASL]      Myers, J., "Simple Authentication and Security Layer
+               (SASL)", RFC 2222, October 1997.
+
+   [SMTP]      Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+               821, August 1982.
+
+
+
+
+
+
+Gellens                     Standards Track                     [Page 7]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+11.  Author's Address
+
+   Randall Gellens
+   QUALCOMM Incorporated
+   5775 Morehouse Dr.
+   San Diego, CA  92121-2779
+   U.S.A.
+
+   Phone: +1.619.651.5115
+   EMail: randy@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens                     Standards Track                     [Page 8]
+
+RFC 2645                  On-Demand Mail Relay               August 1999
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens                     Standards Track                     [Page 9]
+
diff --git a/RFC/rfc2683.txt b/RFC/rfc2683.txt
new file mode 100644
index 00000000..651447b3
--- /dev/null
+++ b/RFC/rfc2683.txt
@@ -0,0 +1,1291 @@
+

+

+

+

+

+

+Network Working Group                                           B. Leiba

+Request for Comments: 2683               IBM T.J. Watson Research Center

+Category: Informational                                   September 1999

+

+

+                  IMAP4 Implementation Recommendations

+

+Status of this Memo

+

+   This memo provides information for the Internet community.  It does

+   not specify an Internet standard of any kind.  Distribution of this

+   memo is unlimited.

+

+Copyright Notice

+

+   Copyright (C) The Internet Society (1999).  All Rights Reserved.

+

+1. Abstract

+

+   The IMAP4 specification [RFC-2060] describes a rich protocol for use

+   in building clients and servers for storage, retrieval, and

+   manipulation of electronic mail.  Because the protocol is so rich and

+   has so many implementation choices, there are often trade-offs that

+   must be made and issues that must be considered when designing such

+   clients and servers.  This document attempts to outline these issues

+   and to make recommendations in order to make the end products as

+   interoperable as possible.

+

+2. Conventions used in this document

+

+   In examples, "C:" indicates lines sent by a client that is connected

+   to a server.  "S:" indicates lines sent by the server to the client.

+

+   The words "must", "must not", "should", "should not", and "may" are

+   used with specific meaning in this document; since their meaning is

+   somewhat different from that specified in RFC 2119, we do not put

+   them in all caps here.  Their meaning is as follows:

+

+   must --       This word means that the action described is necessary

+                 to ensure interoperability.  The recommendation should

+                 not be ignored.

+   must not --   This phrase means that the action described will be

+                 almost certain to hurt interoperability.  The

+                 recommendation should not be ignored.

+

+

+

+

+

+

+

+Leiba                        Informational                      [Page 1]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   should --     This word means that the action described is strongly

+                 recommended and will enhance interoperability or

+                 usability.  The recommendation should not be ignored

+                 without careful consideration.

+   should not -- This phrase means that the action described is strongly

+                 recommended against, and might hurt interoperability or

+                 usability.  The recommendation should not be ignored

+                 without careful consideration.

+   may --        This word means that the action described is an

+                 acceptable implementation choice.  No specific

+                 recommendation is implied; this word is used to point

+                 out a choice that might not be obvious, or to let

+                 implementors know what choices have been made by

+                 existing implementations.

+

+3. Interoperability Issues and Recommendations

+

+3.1.   Accessibility

+

+   This section describes the issues related to access to servers and

+   server resources.  Concerns here include data sharing and maintenance

+   of client/server connections.

+

+3.1.1. Multiple Accesses of the Same Mailbox

+

+   One strong point of IMAP4 is that, unlike POP3, it allows for

+   multiple simultaneous access to a single mailbox.  A user can, thus,

+   read mail from a client at home while the client in the office is

+   still connected; or the help desk staff can all work out of the same

+   inbox, all seeing the same pool of questions.  An important point

+   about this capability, though is that NO SERVER IS GUARANTEED TO

+   SUPPORT THIS.  If you are selecting an IMAP server and this facility

+   is important to you, be sure that the server you choose to install,

+   in the configuration you choose to use, supports it.

+

+   If you are designing a client, you must not assume that you can

+   access the same mailbox more than once at a time.  That means

+

+   1. you must handle gracefully the failure of a SELECT command if the

+      server refuses the second SELECT,

+   2. you must handle reasonably the severing of your connection (see

+      "Severed Connections", below) if the server chooses to allow the

+      second SELECT by forcing the first off,

+   3. you must avoid making multiple connections to the same mailbox in

+      your own client (for load balancing or other such reasons), and

+   4. you must avoid using the STATUS command on a mailbox that you have

+      selected (with some server implementations the STATUS command has

+      the same problems with multiple access as do the SELECT and

+

+

+

+Leiba                        Informational                      [Page 2]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+      EXAMINE commands).

+

+   A further note about STATUS: The STATUS command is sometimes used to

+   check a non-selected mailbox for new mail.  This mechanism must not

+   be used to check for new mail in the selected mailbox; section 5.2 of

+   [RFC-2060] specifically forbids this in its last paragraph.  Further,

+   since STATUS takes a mailbox name it is an independent operation, not

+   operating on the selected mailbox.  Because of this, the information

+   it returns is not necessarily in synchronization with the selected

+   mailbox state.

+

+3.1.2. Severed Connections

+

+   The client/server connection may be severed for one of three reasons:

+   the client severs the connection, the server severs the connection,

+   or the connection is severed by outside forces beyond the control of

+   the client and the server (a telephone line drops, for example).

+   Clients and servers must both deal with these situations.

+

+   When the client wants to sever a connection, it's usually because it

+   has finished the work it needed to do on that connection.  The client

+   should send a LOGOUT command, wait for the tagged response, and then

+   close the socket.  But note that, while this is what's intended in

+   the protocol design, there isn't universal agreement here.  Some

+   contend that sending the LOGOUT and waiting for the two responses

+   (untagged BYE and tagged OK) is wasteful and unnecessary, and that

+   the client can simply close the socket.  The server should interpret

+   the closed socket as a log out by the client.  The counterargument is

+   that it's useful from the standpoint of cleanup, problem

+   determination, and the like, to have an explicit client log out,

+   because otherwise there is no way for the server to tell the

+   difference between "closed socket because of log out" and "closed

+   socket because communication was disrupted".  If there is a

+   client/server interaction problem, a client which routinely

+   terminates a session by breaking the connection without a LOGOUT will

+   make it much more difficult to determine the problem.

+

+   Because of this disagreement, server designers must be aware that

+   some clients might close the socket without sending a LOGOUT.  In any

+   case, whether or not a LOGOUT was sent, the server should not

+   implicitly expunge any messages from the selected mailbox.  If a

+   client wants the server to do so, it must send a CLOSE or EXPUNGE

+   command explicitly.

+

+   When the server wants to sever a connection it's usually due to an

+   inactivity timeout or is because a situation has arisen that has

+   changed the state of the mail store in a way that the server can not

+   communicate to the client.  The server should send an untagged BYE

+

+

+

+Leiba                        Informational                      [Page 3]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   response to the client and then close the socket.  Sending an

+   untagged BYE response before severing allows the server to send a

+   human-readable explanation of the problem to the client, which the

+   client may then log, display to the user, or both (see section 7.1.5

+   of [RFC-2060]).

+

+   Regarding inactivity timeouts, there is some controversy.  Unlike

+   POP, for which the design is for a client to connect, retrieve mail,

+   and log out, IMAP's design encourages long-lived (and mostly

+   inactive) client/server sessions.  As the number of users grows, this

+   can use up a lot of server resources, especially with clients that

+   are designed to maintain sessions for mailboxes that the user has

+   finished accessing.  To alleviate this, a server may implement an

+   inactivity timeout, unilaterally closing a session (after first

+   sending an untagged BYE, as noted above).  Some server operators have

+   reported dramatic improvements in server performance after doing

+   this.  As specified in [RFC-2060], if such a timeout is done it must

+   not be until at least 30 minutes of inactivity.  The reason for this

+   specification is to prevent clients from sending commands (such as

+   NOOP) to the server at frequent intervals simply to avert a too-early

+   timeout.  If the client knows that the server may not time out the

+   session for at least 30 minutes, then the client need not poll at

+   intervals more frequent than, say, 25 minutes.

+

+3.2.   Scaling

+

+   IMAP4 has many features that allow for scalability, as mail stores

+   become larger and more numerous.  Large numbers of users, mailboxes,

+   and messages, and very large messages require thought to handle

+   efficiently.  This document will not address the administrative

+   issues involved in large numbers of users, but we will look at the

+   other items.

+

+3.2.1. Flood Control

+

+   There are three situations when a client can make a request that will

+   result in a very large response - too large for the client reasonably

+   to deal with: there are a great many mailboxes available, there are a

+   great many messages in the selected mailbox, or there is a very large

+   message part.  The danger here is that the end user will be stuck

+   waiting while the server sends (and the client processes) an enormous

+   response.  In all of these cases there are things a client can do to

+   reduce that danger.

+

+   There is also the case where a client can flood a server, by sending

+   an arbitratily long command.  We'll discuss that issue, too, in this

+   section.

+

+

+

+

+Leiba                        Informational                      [Page 4]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+3.2.1.1.  Listing Mailboxes

+

+   Some servers present Usenet newsgroups to IMAP users.  Newsgroups,

+   and other such hierarchical mailbox structures, can be very numerous

+   but may have only a few entries at the top level of hierarchy.  Also,

+   some servers are built against mail stores that can, unbeknownst to

+   the server, have circular hierarchies - that is, it's possible for

+   "a/b/c/d" to resolve to the same file structure as "a", which would

+   then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy

+   will never end.  The LIST response in this case will be unlimited.

+

+   Clients that will have trouble with this are those that use

+

+       C: 001 LIST "" *

+

+   to determine the mailbox list.  Because of this, clients should not

+   use an unqualified "*" that way in the LIST command.  A safer

+   approach is to list each level of hierarchy individually, allowing

+   the user to traverse the tree one limb at a time, thus:

+

+       C: 001 LIST "" %

+       S: * LIST () "/" Banana

+       S: * LIST ...etc...

+       S: 001 OK done

+

+   and then

+

+       C: 002 LIST "" Banana/%

+       S: * LIST () "/" Banana/Apple

+       S: * LIST ...etc...

+       S: 002 OK done

+

+   Using this technique the client's user interface can give the user

+   full flexibility without choking on the voluminous reply to "LIST *".

+

+   Of course, it is still possible that the reply to

+

+       C: 005 LIST "" alt.fan.celebrity.%

+

+   may be thousands of entries long, and there is, unfortunately,

+   nothing the client can do to protect itself from that.  This has not

+   yet been a notable problem.

+

+   Servers that may export circular hierarchies (any server that

+   directly presents a UNIX file system, for instance) should limit the

+   hierarchy depth to prevent unlimited LIST responses.  A suggested

+   depth limit is 20 hierarchy levels.

+

+

+

+

+Leiba                        Informational                      [Page 5]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+3.2.1.2.  Fetching the List of Messages

+

+   When a client selects a mailbox, it is given a count, in the untagged

+   EXISTS response, of the messages in the mailbox.  This number can be

+   very large.  In such a case it might be unwise to use

+

+       C: 004 FETCH 1:* ALL

+

+   to populate the user's view of the mailbox.  One good method to avoid

+   problems with this is to batch the requests, thus:

+

+       C: 004 FETCH 1:50 ALL

+       S: * 1 FETCH ...etc...

+       S: 004 OK done

+       C: 005 FETCH 51:100 ALL

+       S: * 51 FETCH ...etc...

+       S: 005 OK done

+       C: 006 FETCH 101:150 ALL

+       ...etc...

+

+   Using this method, another command, such as "FETCH 6 BODY[1]" can be

+   inserted as necessary, and the client will not have its access to the

+   server blocked by a storm of FETCH replies.  (Such a method could be

+   reversed to fetch the LAST 50 messages first, then the 50 prior to

+   that, and so on.)

+

+   As a smart extension of this, a well designed client, prepared for

+   very large mailboxes, will not automatically fetch data for all

+   messages AT ALL.  Rather, the client will populate the user's view

+   only as the user sees it, possibly pre-fetching selected information,

+   and only fetching other information as the user scrolls to it.  For

+   example, to select only those messages beginning with the first

+   unseen one:

+

+       C: 003 SELECT INBOX

+       S: * 10000 EXISTS

+       S: * 80 RECENT

+       S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)

+       S: * OK [UIDVALIDITY 824708485] UID validity status

+       S: * OK [UNSEEN 9921] First unseen message

+       S: 003 OK [READ-WRITE] SELECT completed

+       C: 004 FETCH 9921:* ALL

+       ... etc...

+

+   If the server does not return an OK [UNSEEN] response, the client may

+   use SEARCH UNSEEN to obtain that value.

+

+

+

+

+

+Leiba                        Informational                      [Page 6]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   This mechanism is good as a default presentation method, but only

+   works well if the default message order is acceptable.  A client may

+   want to present various sort orders to the user (by subject, by date

+   sent, by sender, and so on) and in that case (lacking a SORT

+   extension on the server side) the client WILL have to retrieve all

+   message descriptors.  A client that provides this service should not

+   do it by default and should inform the user of the costs of choosing

+   this option for large mailboxes.

+

+3.2.1.3.  Fetching a Large Body Part

+

+   The issue here is similar to the one for a list of messages.  In the

+   BODYSTRUCTURE response the client knows the size, in bytes, of the

+   body part it plans to fetch.  Suppose this is a 70 MB video clip. The

+   client can use partial fetches to retrieve the body part in pieces,

+   avoiding the problem of an uninterruptible 70 MB literal coming back

+   from the server:

+

+       C: 022 FETCH 3 BODY[1]<0.20000>

+       S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}

+       S: ...data...)

+       S: 022 OK done

+       C: 023 FETCH 3 BODY[1]<20001.20000>

+       S: * 3 FETCH (BODY[1]<20001> {20000}

+       S: ...data...)

+       S: 023 OK done

+       C: 024 FETCH 3 BODY[1]<40001.20000>

+       ...etc...

+

+3.2.1.4.  BODYSTRUCTURE vs. Entire Messages

+

+   Because FETCH BODYSTRUCTURE is necessary in order to determine the

+   number of body parts, and, thus, whether a message has "attachments",

+   clients often use FETCH FULL as their normal method of populating the

+   user's view of a mailbox.  The benefit is that the client can display

+   a paperclip icon or some such indication along with the normal

+   message summary.  However, this comes at a significant cost with some

+   server configurations.  The parsing needed to generate the FETCH

+   BODYSTRUCTURE response may be time-consuming compared with that

+   needed for FETCH ENVELOPE.  The client developer should consider this

+   issue when deciding whether the ability to add a paperclip icon is

+   worth the tradeoff in performance, especially with large mailboxes.

+

+   Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[]

+   (or the equivalent FETCH RFC822) to retrieve the entire message.

+   They then do the MIME parsing in the client.  This may give the

+   client slightly more flexibility in some areas (access, for instance,

+   to header fields that aren't returned in the BODYSTRUCTURE and

+

+

+

+Leiba                        Informational                      [Page 7]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   ENVELOPE responses), but it can cause severe performance problems by

+   forcing the transfer of all body parts when the user might only want

+   to see some of them - a user logged on by modem and reading a small

+   text message with a large ZIP file attached may prefer to read the

+   text only and save the ZIP file for later.  Therefore, a client

+   should not normally retrieve entire messages and should retrieve

+   message body parts selectively.

+

+3.2.1.5.  Long Command Lines

+

+   A client can wind up building a very long command line in an effort to

+   try to be efficient about requesting information from a server.  This

+   can typically happen when a client builds a message set from selected

+   messages and doesn't recognise that contiguous blocks of messages may

+   be group in a range.  Suppose a user selects all 10,000 messages in a

+   large mailbox and then unselects message 287.  The client could build

+   that message set as "1:286,288:10000", but a client that doesn't

+   handle that might try to enumerate each message individually and build

+   "1,2,3,4, [and so on] ,9999,10000".  Adding that to the fetch command

+   results in a command line that's almost 49,000 octets long, and,

+   clearly, one can construct a command line that's even longer.

+

+   A client should limit the length of the command lines it generates to

+   approximately 1000 octets (including all quoted strings but not

+   including literals).  If the client is unable to group things into

+   ranges so that the command line is within that length, it should

+   split the request into multiple commands.  The client should use

+   literals instead of long quoted strings, in order to keep the command

+   length down.

+

+   For its part, a server should allow for a command line of at least

+   8000 octets.  This provides plenty of leeway for accepting reasonable

+   length commands from clients.  The server should send a BAD response

+   to a command that does not end within the server's maximum accepted

+   command length.

+

+3.2.2. Subscriptions

+

+   The client isn't the only entity that can get flooded: the end user,

+   too, may need some flood control.  The IMAP4 protocol provides such

+   control in the form of subscriptions.  Most servers support the

+   SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to

+   narrow down a large list of available mailboxes by subscribing to the

+   ones that they usually want to see.  Clients, with this in mind,

+   should give the user a way to see only subscribed mailboxes.  A

+   client that never uses the LSUB command takes a significant usability

+   feature away from the user.  Of course, the client would not want to

+   hide the LIST command completely; the user needs to have a way to

+

+

+

+Leiba                        Informational                      [Page 8]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   choose between LIST and LSUB.  The usual way to do this is to provide

+   a setting like "show which mailboxes?:  [] all  [] subscribed only".

+

+3.2.3. Searching

+

+   IMAP SEARCH commands can become particularly troublesome (that is,

+   slow) on mailboxes containing a large number of messages.  So let's

+   put a few things in perspective in that regard.

+

+   The flag searches should be fast.  The flag searches (ALL, [UN]SEEN,

+   [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)

+   are known to be used by clients for the client's own use (for

+   instance, some clients use "SEARCH UNSEEN" to find unseen mail and

+   "SEARCH DELETED" to warn the user before expunging messages).

+

+   Other searches, particularly the text searches (HEADER, TEXT, BODY)

+   are initiated by the user, rather than by the client itself, and

+   somewhat slower performance can be tolerated, since the user is aware

+   that the search is being done (and is probably aware that it might be

+   time-consuming).  A smart server might use dynamic indexing to speed

+   commonly used text searches.

+

+   The client may allow other commands to be sent to the server while a

+   SEARCH is in progress, but at the time of this writing there is

+   little or no server support for parallel processing of multiple

+   commands in the same session (and see "Multiple Accesses of the Same

+   Mailbox" above for a description of the dangers of trying to work

+   around this by doing your SEARCH in another session).

+

+   Another word about text searches: some servers, built on database

+   back-ends with indexed search capabilities, may return search results

+   that do not match the IMAP spec's "case-insensitive substring"

+   requirements.  While these servers are in violation of the protocol,

+   there is little harm in the violation as long as the search results

+   are used only in response to a user's request.  Still, developers of

+   such servers should be aware that they ARE violating the protocol,

+   should think carefully about that behaviour, and must be certain that

+   their servers respond accurately to the flag searches for the reasons

+   outlined above.

+

+   In addition, servers should support CHARSET UTF-8 [UTF-8] in

+   searches.

+

+

+

+

+

+

+

+

+

+Leiba                        Informational                      [Page 9]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+3.3    Avoiding Invalid Requests

+

+   IMAP4 provides ways for a server to tell a client in advance what is

+   and isn't permitted in some circumstances.  Clients should use these

+   features to avoid sending requests that a well designed client would

+   know to be invalid.  This section explains this in more detail.

+

+3.3.1. The CAPABILITY Command

+

+   All IMAP4 clients should use the CAPABILITY command to determine what

+   version of IMAP and what optional features a server supports.  The

+   client should not send IMAP4rev1 commands and arguments to a server

+   that does not advertize IMAP4rev1 in its CAPABILITY response.

+   Similarly, the client should not send IMAP4 commands that no longer

+   exist in IMAP4rev1 to a server that does not advertize IMAP4 in its

+   CAPABILITY response.  An IMAP4rev1 server is NOT required to support

+   obsolete IMAP4 or IMAP2bis commands (though some do; do not let this

+   fact lull you into thinking that it's valid to send such commands to

+   an IMAP4rev1 server).

+

+   A client should not send commands to probe for the existance of

+   certain extensions.  All standard and standards-track extensions

+   include CAPABILITY tokens indicating their presense.  All private and

+   experimental extensions should do the same, and clients that take

+   advantage of them should use the CAPABILITY response to determine

+   whether they may be used or not.

+

+3.3.2. Don't Do What the Server Says You Can't

+

+   In many cases, the server, in response to a command, will tell the

+   client something about what can and can't be done with a particular

+   mailbox.  The client should pay attention to this information and

+   should not try to do things that it's been told it can't do.

+

+   Examples:

+

+   *  Do not try to SELECT a mailbox that has the \Noselect flag set.

+   *  Do not try to CREATE a sub-mailbox in a mailbox that has the

+      \Noinferiors flag set.

+   *  Do not respond to a failing COPY or APPEND command by trying to

+      CREATE the target mailbox if the server does not respond with a

+      [TRYCREATE] response code.

+   *  Do not try to expunge a mailbox that has been selected with the

+      [READ-ONLY] response code.

+

+

+

+

+

+

+

+Leiba                        Informational                     [Page 10]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+3.4.   Miscellaneous Protocol Considerations

+

+   We describe here a number of important protocol-related issues, the

+   misunderstanding of which has caused significant interoperability

+   problems in IMAP4 implementations.  One general item is that every

+   implementer should be certain to take note of and to understand

+   section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec

+   [RFC-2060].

+

+3.4.1. Well Formed Protocol

+

+   We cannot stress enough the importance of adhering strictly to the

+   protocol grammar.  The specification of the protocol is quite rigid;

+   do not assume that you can insert blank space for "readability" if

+   none is called for.  Keep in mind that there are parsers out there

+   that will crash if there are protocol errors.  There are clients that

+   will report every parser burp to the user.  And in any case,

+   information that cannot be parsed is information that is lost.  Be

+   careful in your protocol generation.  And see "A Word About Testing",

+   below.

+

+   In particular, note that the string in the INTERNALDATE response is

+   NOT an RFC-822 date string - that is, it is not in the same format as

+   the first string in the ENVELOPE response.  Since most clients will,

+   in fact, accept an RFC-822 date string in the INTERNALDATE response,

+   it's easy to miss this in your interoperability testing.  But it will

+   cause a problem with some client, so be sure to generate the correct

+   string for this field.

+

+3.4.2. Special Characters

+

+   Certain characters, currently the double-quote and the backslash, may

+   not be sent as-is inside a quoted string.  These characters must be

+   preceded by the escape character if they are in a quoted string, or

+   else the string must be sent as a literal.  Both clients and servers

+   must handle this, both on output (they must send these characters

+   properly) and on input (they must be able to receive escaped

+   characters in quoted strings).  Example:

+

+       C: 001 LIST "" %

+       S: * LIST () "" INBOX

+       S: * LIST () "\\" TEST

+       S: * LIST () "\\" {12}

+       S: "My" mailbox

+       S: 001 OK done

+       C: 002 LIST "" "\"My\" mailbox\\%"

+       S: * LIST () "\\" {17}

+       S: "My" mailbox\Junk

+

+

+

+Leiba                        Informational                     [Page 11]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+       S: 002 OK done

+

+   Note that in the example the server sent the hierarchy delimiter as

+   an escaped character in the quoted string and sent the mailbox name

+   containing imbedded double-quotes as a literal.  The client used only

+   quoted strings, escaping both the backslash and the double-quote

+   characters.

+

+   The CR and LF characters may be sent ONLY in literals; they are not

+   allowed, even if escaped, inside quoted strings.

+

+   And while we're talking about special characters: the IMAP spec, in

+   the section titled "Mailbox International Naming Convention",

+   describes how to encode mailbox names in modified UTF-7 [UTF-7 and

+   RFC-2060].  Implementations must adhere to this in order to be

+   interoperable in the international market, and servers should

+   validate mailbox names sent by client and reject names that do not

+   conform.

+

+   As to special characters in userids and passwords: clients must not

+   restrict what a user may type in for a userid or a password.  The

+   formal grammar specifies that these are "astrings", and an astring

+   can be a literal.  A literal, in turn can contain any 8-bit

+   character, and clients must allow users to enter all 8-bit characters

+   here, and must pass them, unchanged, to the server (being careful to

+   send them as literals when necessary).  In particular, some server

+   configurations use "@" in user names, and some clients do not allow

+   that character to be entered; this creates a severe interoperability

+   problem.

+

+3.4.3. UIDs and UIDVALIDITY

+

+   Servers that support existing back-end mail stores often have no good

+   place to save UIDs for messages.  Often the existing mail store will

+   not have the concept of UIDs in the sense that IMAP has: strictly

+   increasing, never re-issued, 32-bit integers.  Some servers solve

+   this by storing the UIDs in a place that's accessible to end users,

+   allowing for the possibility that the users will delete them.  Others

+   solve it by re-assigning UIDs every time a mailbox is selected.

+

+   The server should maintain UIDs permanently for all messages if it

+   can.  If that's not possible, the server must change the UIDVALIDITY

+   value for the mailbox whenever any of the UIDs may have become

+   invalid.  Clients must recognize that the UIDVALIDITY has changed and

+   must respond to that condition by throwing away any information that

+   they have saved about UIDs in that mailbox.  There have been many

+   problems in this area when clients have failed to do this; in the

+   worst case it will result in loss of mail when a client deletes the

+

+

+

+Leiba                        Informational                     [Page 12]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   wrong piece of mail by using a stale UID.

+

+   It seems to be a common misunderstanding that "the UIDVALIDITY and

+   the UID, taken together, form a 64-bit identifier that uniquely

+   identifies a message on a server".  This is absolutely NOT TRUE.

+   There is no assurance that the UIDVALIDITY values of two mailboxes be

+   different, so the UIDVALIDITY in no way identifies a mailbox.  The

+   ONLY purpose of UIDVALIDITY is, as its name indicates, to give the

+   client a way to check the validity of the UIDs it has cached.  While

+   it is a valid implementation choice to put these values together to

+   make a 64-bit identifier for the message, the important concept here

+   is that UIDs are not unique between mailboxes; they are only unique

+   WITHIN a given mailbox.

+

+   Some server implementations have attempted to make UIDs unique across

+   the entire server.  This is inadvisable, in that it limits the life

+   of UIDs unnecessarily.  The UID is a 32-bit number and will run out

+   in reasonably finite time if it's global across the server.  If you

+   assign UIDs sequentially in one mailbox, you will not have to start

+   re-using them until you have had, at one time or another, 2**32

+   different messages in that mailbox.  In the global case, you will

+   have to reuse them once you have had, at one time or another, 2**32

+   different messages in the entire mail store.  Suppose your server has

+   around 8000 users registered (2**13).  That gives an average of 2**19

+   UIDs per user.  Suppose each user gets 32 messages (2**5) per day.

+   That gives you 2**14 days (16000+ days = about 45 years) before you

+   run out.  That may seem like enough, but multiply the usage just a

+   little (a lot of spam, a lot of mailing list subscriptions, more

+   users) and you limit yourself too much.

+

+   What's worse is that if you have to wrap the UIDs, and, thus, you

+   have to change UIDVALIDITY and invalidate the UIDs in the mailbox,

+   you have to do it for EVERY mailbox in the system, since they all

+   share the same UID pool.  If you assign UIDs per mailbox and you have

+   a problem, you only have to kill the UIDs for that one mailbox.

+

+   Under extreme circumstances (and this is extreme, indeed), the server

+   may have to invalidate UIDs while a mailbox is in use by a client -

+   that is, the UIDs that the client knows about in its active mailbox

+   are no longer valid.  In that case, the server must immediately

+   change the UIDVALIDITY and must communicate this to the client.  The

+   server may do this by sending an unsolicited UIDVALIDITY message, in

+   the same form as in response to the SELECT command.  Clients must be

+   prepared to handle such a message and the possibly coincident failure

+   of the command in process.  For example:

+

+

+

+

+

+

+Leiba                        Informational                     [Page 13]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+       C: 032 UID STORE 382 +Flags.silent \Deleted

+       S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!

+       S: 032 NO UID command rejected because UIDVALIDITY changed!

+       C: ...invalidates local information and re-fetches...

+       C: 033 FETCH 1:* UID

+       ...etc...

+

+   At the time of the writing of this document, the only server known to

+   do this does so only under the following condition: the client

+   selects INBOX, but there is not yet a physical INBOX file created.

+   Nonetheless, the SELECT succeeds, exporting an empty INBOX with a

+   temporary UIDVALIDITY of 1.  While the INBOX remains selected, mail

+   is delivered to the user, which creates the real INBOX file and

+   assigns a permanent UIDVALIDITY (that is likely not to be 1).  The

+   server reports the change of UIDVALIDITY, but as there were no

+   messages before, so no UIDs have actually changed, all the client

+   must do is accept the change in UIDVALIDITY.

+

+   Alternatively, a server may force the client to re-select the

+   mailbox, at which time it will obtain a new UIDVALIDITY value.  To do

+   this, the server closes this client session (see "Severed

+   Connections" above) and the client then reconnects and gets back in

+   synch.  Clients must be prepared for either of these behaviours.

+

+   We do not know of, nor do we anticipate the future existance of, a

+   server that changes UIDVALIDITY while there are existing messages,

+   but clients must be prepared to handle this eventuality.

+

+3.4.4. FETCH Responses

+

+   When a client asks for certain information in a FETCH command, the

+   server may return the requested information in any order, not

+   necessarily in the order that it was requested.  Further, the server

+   may return the information in separate FETCH responses and may also

+   return information that was not explicitly requested (to reflect to

+   the client changes in the state of the subject message).  Some

+   examples:

+

+       C: 001 FETCH 1 UID FLAGS INTERNALDATE

+       S: * 5 FETCH (FLAGS (\Deleted))

+       S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)

+       S: 001 OK done

+

+   (In this case, the responses are in a different order.  Also, the

+   server returned a flag update for message 5, which wasn't part of the

+   client's request.)

+

+

+

+

+

+Leiba                        Informational                     [Page 14]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+       C: 002 FETCH 2 UID FLAGS INTERNALDATE

+       S: * 2 FETCH (INTERNALDATE "...")

+       S: * 2 FETCH (UID 399)

+       S: * 2 FETCH (FLAGS ())

+       S: 002 OK done

+

+   (In this case, the responses are in a different order and were

+   returned in separate responses.)

+

+       C: 003 FETCH 2 BODY[1]

+       S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}

+       S: Hello world!

+       S: )

+       S: 003 OK done

+

+   (In this case, the FLAGS response was added by the server, since

+   fetching the body part caused the server to set the \Seen flag.)

+

+   Because of this characteristic a client must be ready to receive any

+   FETCH response at any time and should use that information to update

+   its local information about the message to which the FETCH response

+   refers.  A client must not assume that any FETCH responses will come

+   in any particular order, or even that any will come at all.  If after

+   receiving the tagged response for a FETCH command the client finds

+   that it did not get all of the information requested, the client

+   should send a NOOP command to the server to ensure that the server

+   has an opportunity to send any pending EXPUNGE responses to the

+   client (see [RFC-2180]).

+

+3.4.5. RFC822.SIZE

+

+   Some back-end mail stores keep the mail in a canonical form, rather

+   than retaining the original MIME format of the messages.  This means

+   that the server must reassemble the message to produce a MIME stream

+   when a client does a fetch such as RFC822 or BODY[], requesting the

+   entire message.  It also may mean that the server has no convenient

+   way to know the RFC822.SIZE of the message.  Often, such a server

+   will actually have to build the MIME stream to compute the size, only

+   to throw the stream away and report the size to the client.

+

+   When this is the case, some servers have chosen to estimate the size,

+   rather than to compute it precisely.  Such an estimate allows the

+   client to display an approximate size to the user and to use the

+   estimate in flood control considerations (q.v.), but requires that

+   the client not use the size for things such as allocation of buffers,

+   because those buffers might then be too small to hold the actual MIME

+   stream.  Instead, a client should use the size that's returned in the

+   literal when you fetch the data.

+

+

+

+Leiba                        Informational                     [Page 15]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   The protocol requires that the RFC822.SIZE value returned by the

+   server be EXACT.  Estimating the size is a protocol violation, and

+   server designers must be aware that, despite the performance savings

+   they might realize in using an estimate, this practice will cause

+   some clients to fail in various ways.  If possible, the server should

+   compute the RFC822.SIZE for a particular message once, and then save

+   it for later retrieval.  If that's not possible, the server must

+   compute the value exactly every time.  Incorrect estimates do cause

+   severe interoperability problems with some clients.

+

+3.4.6. Expunged Messages

+

+   If the server allows multiple connections to the same mailbox, it is

+   often possible for messages to be expunged in one client unbeknownst

+   to another client.  Since the server is not allowed to tell the

+   client about these expunged messages in response to a FETCH command,

+   the server may have to deal with the issue of how to return

+   information about an expunged message.  There was extensive

+   discussion about this issue, and the results of that discussion are

+   summarized in [RFC-2180].  See that reference for a detailed

+   explanation and for recommendations.

+

+3.4.7. The Namespace Issue

+

+   Namespaces are a very muddy area in IMAP4 implementation right now

+   (see [NAMESPACE] for a proposal to clear the water a bit).  Until the

+   issue is resolved, the important thing for client developers to

+   understand is that some servers provide access through IMAP to more

+   than just the user's personal mailboxes, and, in fact, the user's

+   personal mailboxes may be "hidden" somewhere in the user's default

+   hierarchy.  The client, therefore, should provide a setting wherein

+   the user can specify a prefix to be used when accessing mailboxes. If

+   the user's mailboxes are all in "~/mail/", for instance, then the

+   user can put that string in the prefix.  The client would then put

+   the prefix in front of any name pattern in the LIST and LSUB

+   commands:

+

+       C: 001 LIST "" ~/mail/%

+

+   (See also "Reference Names in the LIST Command" below.)

+

+3.4.8. Creating Special-Use Mailboxes

+

+   It may seem at first that this is part of the namespace issue; it is

+   not, and is only indirectly related to it.  A number of clients like

+   to create special-use mailboxes with particular names.  Most

+   commonly, clients with a "trash folder" model of message deletion

+   want to create a mailbox with the name "Trash" or "Deleted".  Some

+

+

+

+Leiba                        Informational                     [Page 16]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a

+   "Sent Mail" mailbox.  And so on.  There are two major

+   interoperability problems with this practice:

+

+   1. different clients may use different names for mailboxes with

+      similar functions (such as "Trash" and "Deleted"), or may manage

+      the same mailboxes in different ways, causing problems if a user

+      switches between clients and

+   2. there is no guarantee that the server will allow the creation of

+      the desired mailbox.

+

+   The client developer is, therefore, well advised to consider

+   carefully the creation of any special-use mailboxes on the server,

+   and, further, the client must not require such mailbox creation -

+   that is, if you do decide to do this, you must handle gracefully the

+   failure of the CREATE command and behave reasonably when your

+   special-use mailboxes do not exist and can not be created.

+

+   In addition, the client developer should provide a convenient way for

+   the user to select the names for any special-use mailboxes, allowing

+   the user to make these names the same in all clients used and to put

+   them where the user wants them.

+

+3.4.9. Reference Names in the LIST Command

+

+   Many implementers of both clients and servers are confused by the

+   "reference name" on the LIST command.  The reference name is intended

+   to be used in much the way a "cd" (change directory) command is used

+   on Unix, PC DOS, Windows, and OS/2 systems.  That is, the mailbox

+   name is interpreted in much the same way as a file of that name would

+   be found if one had done a "cd" command into the directory specified

+   by the reference name.  For example, in Unix we have the following:

+

+       > cd /u/jones/junk

+       > vi banana        [file is "/u/jones/junk/banana"]

+       > vi stuff/banana  [file is "/u/jones/junk/stuff/banana"]

+       > vi /etc/hosts    [file is "/etc/hosts"]

+

+   In the past, there have been several interoperability problems with

+   this.  First, while some IMAP servers are built on Unix or PC file

+   systems, many others are not, and the file system semantics do not

+   make sense in those configurations.  Second, while some IMAP servers

+   expose the underlying file system to the clients, others allow access

+   only to the user's personal mailboxes, or to some other limited set

+   of files, making such file-system-like semantics less meaningful.

+   Third, because the IMAP spec leaves the interpretation of the

+   reference name as "implementation-dependent", in the past the various

+   server implementations handled it in vastly differing ways.

+

+

+

+Leiba                        Informational                     [Page 17]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   The following recommendations are the result of significant

+   operational experience, and are intended to maximize

+   interoperability.

+

+   Server implementations must implement the reference argument in a way

+   that matches the intended "change directory" operation as closely as

+   possible.  As a minimum implementation, the reference argument may be

+   prepended to the mailbox name (while suppressing double delimiters;

+   see the next paragraph).  Even servers that do not provide a way to

+   break out of the current hierarchy (see "breakout facility" below)

+   must provide a reasonable implementation of the reference argument,

+   as described here, so that they will interoperate with clients that

+   use it.

+

+   Server implementations that prepend the reference argument to the

+   mailbox name should insert a hierarchy delimiter between them, and

+   must not insert a second if one is already present:

+

+       C: A001 LIST ABC DEF

+       S: * LIST () "/" ABC/DEF   <=== should do this

+       S: A001 OK done

+

+       C: A002 LIST ABC/ /DEF

+       S: * LIST () "/" ABC//DEF     <=== must not do this

+       S: A002 OK done

+

+   On clients, the reference argument is chiefly used to implement a

+   "breakout facility", wherein the user may directly access a mailbox

+   outside the "current directory" hierarchy.  Client implementations

+   should have an operational mode that does not use the reference

+   argument.  This is to interoperate with older servers that did not

+   implement the reference argument properly.  While it's a good idea to

+   give the user access to a breakout facility, clients that do not

+   intend to do so should not use the reference argument at all.

+

+   Client implementations should always place a trailing hierarchy

+   delimiter on the reference argument.  This is because some servers

+   prepend the reference argument to the mailbox name without inserting

+   a hierarchy delimiter, while others do insert a hierarchy delimiter

+   if one is not already present.  A client that puts the delimiter in

+   will work with both varieties of server.

+

+   Client implementations that implement a breakout facility should

+   allow the user to choose whether or not to use a leading hierarchy

+   delimiter on the mailbox argument.  This is because the handling of a

+   leading mailbox hierarchy delimiter also varies from server to

+   server, and even between different mailstores on the same server.  In

+   some cases, a leading hierarchy delimiter means "discard the

+

+

+

+Leiba                        Informational                     [Page 18]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   reference argument" (implementing the intended breakout facility),

+   thus:

+

+       C: A001 LIST ABC/ /DEF

+       S: * LIST () "/" /DEF

+       S: A001 OK done

+

+   In other cases, however, the two are catenated and the extra

+   hierarchy delimiter is discarded, thus:

+

+       C: A001 LIST ABC/ /DEF

+       S: * LIST () "/" ABC/DEF

+       S: A001 OK done

+

+   Client implementations must not assume that the server supports a

+   breakout facility, but may provide a way for the user to use one if

+   it is available.  Any breakout facility should be exported to the

+   user interface.  Note that there may be other "breakout" characters

+   besides the hierarchy delimiter (for instance, UNIX filesystem

+   servers are likely to use a leading "~" as well), and that their

+   interpretation is server-dependent.

+

+3.4.10.   Mailbox Hierarchy Delimiters

+

+   The server's selection of what to use as a mailbox hierarchy

+   delimiter is a difficult one, involving several issues: What

+   characters do users expect to see?  What characters can they enter

+   for a hierarchy delimiter if it is desired (or required) that the

+   user enter it?  What character can be used for the hierarchy

+   delimiter, noting that the chosen character can not otherwise be used

+   in the mailbox name?

+

+   Because some interfaces show users the hierarchy delimiters or allow

+   users to enter qualified mailbox names containing them, server

+   implementations should use delimiter characters that users generally

+   expect to see as name separators.  The most common characters used

+   for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows

+   file names), and "." (as in news groups).  There is little to choose

+   among these apart from what users may expect or what is dictated by

+   the underlying file system, if any.  One consideration about using

+   "\" is that it's also a special character in the IMAP protocol. While

+   the use of other hierarchy delimiter characters is permissible, A

+   DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the

+   server is intended for special purposes only.  Implementers might be

+   thinking about using characters such as "-", "_", ";", "&", "#", "@",

+   and "!", but they should be aware of the surprise to the user as well

+   as of the effect on URLs and other external specifications (since

+   some of these characters have special meanings there).  Also, a

+

+

+

+Leiba                        Informational                     [Page 19]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   server that uses "\" (and clients of such a server) must remember to

+   escape that character in quoted strings or to send literals instead.

+   Literals are recommended over escaped characters in quoted strings in

+   order to maintain compatibility with older IMAP versions that did not

+   allow escaped characters in quoted strings (but check the grammar to

+   see where literals are allowed):

+

+       C: 001 LIST "" {13}

+       S: + send literal

+       C: this\%\%\%\h*

+       S: * LIST () "\\" {27}

+       S: this\is\a\mailbox\hierarchy

+       S: 001 OK LIST complete

+

+   In any case, a server should not use normal alpha-numeric characters

+   (such as "X" or "0") as delimiters; a user would be very surprised to

+   find that "EXPENDITURES" actually represented a two-level hierarchy.

+   And a server should not use characters that are non-printable or

+   difficult or impossible to enter on a standard US keyboard.  Control

+   characters, box-drawing characters, and characters from non-US

+   alphabets fit into this category.  Their use presents

+   interoperability problems that are best avoided.

+

+   The UTF-7 encoding of mailbox names also raises questions about what

+   to do with the hierarchy delimiters in encoded names: do we encode

+   each hierarchy level and separate them with delimiters, or do we

+   encode the fully qualified name, delimiters and all?  The answer for

+   IMAP is the former: encode each hierarchy level separately, and

+   insert delimiters between.  This makes it particularly important not

+   to use as a hierarchy delimiter a character that might cause

+   confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.

+

+   To repeat: a server should use "/", "\", or "." as its hierarchy

+   delimiter.  The use of any other character is likely to cause

+   problems and is STRONGLY DISCOURAGED.

+

+3.4.11.   ALERT Response Codes

+

+   The protocol spec is very clear on the matter of what to do with

+   ALERT response codes, and yet there are many clients that violate it

+   so it needs to be said anyway: "The human-readable text contains a

+   special alert that must be presented to the user in a fashion that

+   calls the user's attention to the message."  That should be clear

+   enough, but I'll repeat it here: Clients must present ALERT text

+   clearly to the user.

+

+

+

+

+

+

+Leiba                        Informational                     [Page 20]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+3.4.12.   Deleting Mailboxes

+

+   The protocol does not guarantee that a client may delete a mailbox

+   that is not empty, though on some servers it is permissible and is,

+   in fact, much faster than the alternative or deleting all the

+   messages from the client.  If the client chooses to try to take

+   advantage of this possibility it must be prepared to use the other

+   method in the even that the more convenient one fails.  Further, a

+   client should not try to delete the mailbox that it has selected, but

+   should first close that mailbox; some servers do not permit the

+   deletion of the selected mailbox.

+

+   That said, a server should permit the deletion of a non-empty

+   mailbox; there's little reason to pass this work on to the client.

+   Moreover, forbidding this prevents the deletion of a mailbox that for

+   some reason can not be opened or expunged, leading to possible

+   denial-of-service problems.

+

+   Example:

+

+       [User tells the client to delete mailbox BANANA, which is

+       currently selected...]

+       C: 008 CLOSE

+       S: 008 OK done

+       C: 009 DELETE BANANA

+       S: 009 NO Delete failed; mailbox is not empty.

+       C: 010 SELECT BANANA

+       S: * ... untagged SELECT responses

+       S: 010 OK done

+       C: 011 STORE 1:* +FLAGS.SILENT \DELETED

+       S: 011 OK done

+       C: 012 CLOSE

+       S: 012 OK done

+       C: 013 DELETE BANANA

+       S: 013 OK done

+

+3.5.   A Word About Testing

+

+   Since the whole point of IMAP is interoperability, and since

+   interoperability can not be tested in a vacuum, the final

+   recommendation of this treatise is, "Test against EVERYTHING."  Test

+   your client against every server you can get an account on.  Test

+   your server with every client you can get your hands on.  Many

+   clients make limited test versions available on the Web for the

+   downloading.  Many server owners will give serious client developers

+   guest accounts for testing.  Contact them and ask.  NEVER assume that

+   because your client works with one or two servers, or because your

+   server does fine with one or two clients, you will interoperate well

+

+

+

+Leiba                        Informational                     [Page 21]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+   in general.

+

+   In particular, in addition to everything else, be sure to test

+   against the reference implementations: the PINE client, the

+   University of Washington server, and the Cyrus server.

+

+   See the following URLs on the web for more information here:

+

+       IMAP Products and Sources: http://www.imap.org/products.html

+       IMC MailConnect: http://www.imc.org/imc-mailconnect

+

+4. Security Considerations

+

+   This document describes behaviour of clients and servers that use the

+   IMAP4 protocol, and as such, has the same security considerations as

+   described in [RFC-2060].

+

+5. References

+

+   [RFC-2060]  Crispin, M., "Internet Message Access Protocol - Version

+               4rev1", RFC 2060, December 1996.

+

+   [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate

+               Requirement Levels", BCP 14, RFC 2119, March 1997.

+

+   [RFC-2180]  Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC

+               2180, July 1997.

+

+   [UTF-8]     Yergeau, F., " UTF-8, a transformation format of Unicode

+               and ISO 10646", RFC 2044, October 1996.

+

+   [UTF-7]     Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe

+               Transformation Format of Unicode", RFC 2152, May 1997.

+

+   [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in

+               Progress.

+

+6. Author's Address

+

+   Barry Leiba

+   IBM T.J. Watson Research Center

+   30 Saw Mill River Road

+   Hawthorne, NY  10532

+

+   Phone: 1-914-784-7941

+   EMail: leiba@watson.ibm.com

+

+

+

+

+

+Leiba                        Informational                     [Page 22]

+

+RFC 2683          IMAP4 Implementation Recommendations    September 1999

+

+

+7. Full Copyright Statement

+

+   Copyright (C) The Internet Society (1999).  All Rights Reserved.

+

+   This document and translations of it may be copied and furnished to

+   others, and derivative works that comment on or otherwise explain it

+   or assist in its implementation may be prepared, copied, published

+   and distributed, in whole or in part, without restriction of any

+   kind, provided that the above copyright notice and this paragraph are

+   included on all such copies and derivative works.  However, this

+   document itself may not be modified in any way, such as by removing

+   the copyright notice or references to the Internet Society or other

+   Internet organizations, except as needed for the purpose of

+   developing Internet standards in which case the procedures for

+   copyrights defined in the Internet Standards process must be

+   followed, or as required to translate it into languages other than

+   English.

+

+   The limited permissions granted above are perpetual and will not be

+   revoked by the Internet Society or its successors or assigns.

+

+   This document and the information contained herein is provided on an

+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

+

+Acknowledgement

+

+   Funding for the RFC Editor function is currently provided by the

+   Internet Society.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Leiba                        Informational                     [Page 23]

+

diff --git a/RFC/rfc821.txt b/RFC/rfc821.txt
new file mode 100644
index 00000000..d877b72c
--- /dev/null
+++ b/RFC/rfc821.txt
@@ -0,0 +1,4050 @@
+
+                                                                        
+
+   RFC 821
+                                    
+                                    
+                                    
+                                    
+                                    
+                     SIMPLE MAIL TRANSFER PROTOCOL
+                                    
+                                    
+                                    
+                           Jonathan B. Postel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              August 1982
+                                    
+                                    
+                                    
+                     Information Sciences Institute
+                   University of Southern California
+                           4676 Admiralty Way
+                   Marina del Rey, California  90291
+
+                             (213) 822-1511
+
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+                           TABLE OF CONTENTS
+
+   1.  INTRODUCTION .................................................. 1
+
+   2.  THE SMTP MODEL ................................................ 2
+
+   3.  THE SMTP PROCEDURE ............................................ 4
+
+      3.1.  Mail ..................................................... 4
+      3.2.  Forwarding ............................................... 7
+      3.3.  Verifying and Expanding .................................. 8
+      3.4.  Sending and Mailing ..................................... 11
+      3.5.  Opening and Closing ..................................... 13
+      3.6.  Relaying ................................................ 14
+      3.7.  Domains ................................................. 17
+      3.8.  Changing Roles .......................................... 18
+
+   4.  THE SMTP SPECIFICATIONS ...................................... 19
+
+      4.1.  SMTP Commands ........................................... 19
+      4.1.1.  Command Semantics ..................................... 19
+      4.1.2.  Command Syntax ........................................ 27
+      4.2.  SMTP Replies ............................................ 34
+      4.2.1.  Reply Codes by Function Group ......................... 35
+      4.2.2.  Reply Codes in Numeric Order .......................... 36
+      4.3.  Sequencing of Commands and Replies ...................... 37
+      4.4.  State Diagrams .......................................... 39
+      4.5.  Details ................................................. 41
+      4.5.1.  Minimum Implementation ................................ 41
+      4.5.2.  Transparency .......................................... 41
+      4.5.3.  Sizes ................................................. 42
+
+   APPENDIX A:  TCP ................................................. 44
+   APPENDIX B:  NCP ................................................. 45
+   APPENDIX C:  NITS ................................................ 46
+   APPENDIX D:  X.25 ................................................ 47
+   APPENDIX E:  Theory of Reply Codes ............................... 48
+   APPENDIX F:  Scenarios ........................................... 51
+
+   GLOSSARY ......................................................... 64
+
+   REFERENCES ....................................................... 67
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: DRAFT                                          ISI
+Replaces: RFC 788, 780, 772                                  August 1982
+
+                     SIMPLE MAIL TRANSFER PROTOCOL
+
+
+1.  INTRODUCTION
+
+   The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
+   mail reliably and efficiently.
+
+   SMTP is independent of the particular transmission subsystem and
+   requires only a reliable ordered data stream channel.  Appendices A,
+   B, C, and D describe the use of SMTP with various transport services.
+   A Glossary provides the definitions of terms as used in this
+   document.
+
+   An important feature of SMTP is its capability to relay mail across
+   transport service environments.  A transport service provides an
+   interprocess communication environment (IPCE).  An IPCE may cover one
+   network, several networks, or a subset of a network.  It is important
+   to realize that transport systems (or IPCEs) are not one-to-one with
+   networks.  A process can communicate directly with another process
+   through any mutually known IPCE.  Mail is an application or use of
+   interprocess communication.  Mail can be communicated between
+   processes in different IPCEs by relaying through a process connected
+   to two (or more) IPCEs.  More specifically, mail can be relayed
+   between hosts on different transport systems by a host on both
+   transport systems.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                          [Page 1]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+2.  THE SMTP MODEL
+
+   The SMTP design is based on the following model of communication:  as
+   the result of a user mail request, the sender-SMTP establishes a
+   two-way transmission channel to a receiver-SMTP.  The receiver-SMTP
+   may be either the ultimate destination or an intermediate.  SMTP
+   commands are generated by the sender-SMTP and sent to the
+   receiver-SMTP.  SMTP replies are sent from the receiver-SMTP to the
+   sender-SMTP in response to the commands.
+
+   Once the transmission channel is established, the SMTP-sender sends a
+   MAIL command indicating the sender of the mail.  If the SMTP-receiver
+   can accept mail it responds with an OK reply.  The SMTP-sender then
+   sends a RCPT command identifying a recipient of the mail.  If the
+   SMTP-receiver can accept mail for that recipient it responds with an
+   OK reply; if not, it responds with a reply rejecting that recipient
+   (but not the whole mail transaction).  The SMTP-sender and
+   SMTP-receiver may negotiate several recipients.  When the recipients
+   have been negotiated the SMTP-sender sends the mail data, terminating
+   with a special sequence.  If the SMTP-receiver successfully processes
+   the mail data it responds with an OK reply.  The dialog is purposely
+   lock-step, one-at-a-time.
+
+     -------------------------------------------------------------
+
+   
+               +----------+                +----------+
+   +------+    |          |                |          |
+   | User |<-->|          |      SMTP      |          |
+   +------+    |  Sender- |Commands/Replies| Receiver-|
+   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
+   | File |<-->|          |    and Mail    |          |<-->| File |
+   |System|    |          |                |          |    |System|
+   +------+    +----------+                +----------+    +------+
+   
+
+                Sender-SMTP                Receiver-SMTP
+
+                           Model for SMTP Use
+
+                                Figure 1
+
+     -------------------------------------------------------------
+
+   The SMTP provides mechanisms for the transmission of mail; directly
+   from the sending user's host to the receiving user's host when the
+
+
+
+[Page 2]                                                          Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   two host are connected to the same transport service, or via one or
+   more relay SMTP-servers when the source and destination hosts are not
+   connected to the same transport service.
+
+   To be able to provide the relay capability the SMTP-server must be
+   supplied with the name of the ultimate destination host as well as
+   the destination mailbox name.
+
+   The argument to the MAIL command is a reverse-path, which specifies
+   who the mail is from.  The argument to the RCPT command is a
+   forward-path, which specifies who the mail is to.  The forward-path
+   is a source route, while the reverse-path is a return route (which
+   may be used to return a message to the sender when an error occurs
+   with a relayed message).
+
+   When the same message is sent to multiple recipients the SMTP
+   encourages the transmission of only one copy of the data for all the
+   recipients at the same destination host.
+
+   The mail commands and replies have a rigid syntax.  Replies also have
+   a numeric code.  In the following, examples appear which use actual
+   commands and replies.  The complete lists of commands and replies
+   appears in Section 4 on specifications.
+
+   Commands and replies are not case sensitive.  That is, a command or
+   reply word may be upper case, lower case, or any mixture of upper and
+   lower case.  Note that this is not true of mailbox user names.  For
+   some hosts the user name is case sensitive, and SMTP implementations
+   must take case to preserve the case of user names as they appear in
+   mailbox arguments.  Host names are not case sensitive.
+
+   Commands and replies are composed of characters from the ASCII
+   character set [1].  When the transport service provides an 8-bit byte
+   (octet) transmission channel, each 7-bit character is transmitted
+   right justified in an octet with the high order bit cleared to zero.
+
+   When specifying the general form of a command or reply, an argument
+   (or special symbol) will be denoted by a meta-linguistic variable (or
+   constant), for example, "<string>" or "<reverse-path>".  Here the
+   angle brackets indicate these are meta-linguistic variables.
+   However, some arguments use the angle brackets literally.  For
+   example, an actual reverse-path is enclosed in angle brackets, i.e.,
+   "<John.Smith@USC-ISI.ARPA>" is an instance of <reverse-path> (the
+   angle brackets are actually transmitted in the command or reply).
+
+
+
+
+
+Postel                                                          [Page 3]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+3.  THE SMTP PROCEDURES
+
+   This section presents the procedures used in SMTP in several parts.
+   First comes the basic mail procedure defined as a mail transaction.
+   Following this are descriptions of forwarding mail, verifying mailbox
+   names and expanding mailing lists, sending to terminals instead of or
+   in combination with mailboxes, and the opening and closing exchanges.
+   At the end of this section are comments on relaying, a note on mail
+   domains, and a discussion of changing roles.  Throughout this section
+   are examples of partial command and reply sequences, several complete
+   scenarios are presented in Appendix F.
+
+   3.1.  MAIL
+
+      There are three steps to SMTP mail transactions.  The transaction
+      is started with a MAIL command which gives the sender
+      identification.  A series of one or more RCPT commands follows
+      giving the receiver information.  Then a DATA command gives the
+      mail data.  And finally, the end of mail data indicator confirms
+      the transaction.
+
+         The first step in the procedure is the MAIL command.  The
+         <reverse-path> contains the source mailbox.
+
+            MAIL <SP> FROM:<reverse-path> <CRLF>
+
+         This command tells the SMTP-receiver that a new mail
+         transaction is starting and to reset all its state tables and
+         buffers, including any recipients or mail data.  It gives the
+         reverse-path which can be used to report errors.  If accepted,
+         the receiver-SMTP returns a 250 OK reply.
+
+         The <reverse-path> can contain more than just a mailbox.  The
+         <reverse-path> is a reverse source routing list of hosts and
+         source mailbox.  The first host in the <reverse-path> should be
+         the host sending this command.
+
+         The second step in the procedure is the RCPT command.
+
+            RCPT <SP> TO:<forward-path> <CRLF>
+
+         This command gives a forward-path identifying one recipient.
+         If accepted, the receiver-SMTP returns a 250 OK reply, and
+         stores the forward-path.  If the recipient is unknown the
+         receiver-SMTP returns a 550 Failure reply.  This second step of
+         the procedure can be repeated any number of times.
+
+
+
+[Page 4]                                                          Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+         The <forward-path> can contain more than just a mailbox.  The
+         <forward-path> is a source routing list of hosts and the
+         destination mailbox.  The first host in the <forward-path>
+         should be the host receiving this command.
+
+         The third step in the procedure is the DATA command.
+
+            DATA <CRLF>
+
+         If accepted, the receiver-SMTP returns a 354 Intermediate reply
+         and considers all succeeding lines to be the message text.
+         When the end of text is received and stored the SMTP-receiver
+         sends a 250 OK reply.
+
+         Since the mail data is sent on the transmission channel the end
+         of the mail data must be indicated so that the command and
+         reply dialog can be resumed.  SMTP indicates the end of the
+         mail data by sending a line containing only a period.  A
+         transparency procedure is used to prevent this from interfering
+         with the user's text (see Section 4.5.2).
+
+            Please note that the mail data includes the memo header
+            items such as Date, Subject, To, Cc, From [2].
+
+         The end of mail data indicator also confirms the mail
+         transaction and tells the receiver-SMTP to now process the
+         stored recipients and mail data.  If accepted, the
+         receiver-SMTP returns a 250 OK reply.  The DATA command should
+         fail only if the mail transaction was incomplete (for example,
+         no recipients), or if resources are not available.
+
+      The above procedure is an example of a mail transaction.  These
+      commands must be used only in the order discussed above.
+      Example 1 (below) illustrates the use of these commands in a mail
+      transaction.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                          [Page 5]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      -------------------------------------------------------------
+
+                     Example of the SMTP Procedure
+
+         This SMTP example shows mail sent by Smith at host Alpha.ARPA,
+         to Jones, Green, and Brown at host Beta.ARPA.  Here we assume
+         that host Alpha contacts host Beta directly.
+
+            S: MAIL FROM:<Smith@Alpha.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<Jones@Beta.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<Green@Beta.ARPA>
+            R: 550 No such user here
+
+            S: RCPT TO:<Brown@Beta.ARPA>
+            R: 250 OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Blah blah blah...
+            S: ...etc. etc. etc.
+            S: <CRLF>.<CRLF>
+            R: 250 OK
+
+         The mail has now been accepted for Jones and Brown.  Green did
+         not have a mailbox at host Beta.
+
+                               Example 1
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 6]                                                          Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   3.2.  FORWARDING
+
+      There are some cases where the destination information in the
+      <forward-path> is incorrect, but the receiver-SMTP knows the
+      correct destination.  In such cases, one of the following replies
+      should be used to allow the sender to contact the correct
+      destination.
+
+         251 User not local; will forward to <forward-path>
+
+            This reply indicates that the receiver-SMTP knows the user's
+            mailbox is on another host and indicates the correct
+            forward-path to use in the future.  Note that either the
+            host or user or both may be different.  The receiver takes
+            responsibility for delivering the message.
+
+         551 User not local; please try <forward-path>
+
+            This reply indicates that the receiver-SMTP knows the user's
+            mailbox is on another host and indicates the correct
+            forward-path to use.  Note that either the host or user or
+            both may be different.  The receiver refuses to accept mail
+            for this user, and the sender must either redirect the mail
+            according to the information provided or return an error
+            response to the originating user.
+
+      Example 2 illustrates the use of these responses.
+
+      -------------------------------------------------------------
+
+                         Example of Forwarding
+
+      Either
+
+      S: RCPT TO:<Postel@USC-ISI.ARPA>
+      R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>
+
+      Or
+
+      S: RCPT TO:<Paul@USC-ISIB.ARPA>
+      R: 551 User not local; please try <Mockapetris@USC-ISIF.ARPA>
+
+                               Example 2
+
+      -------------------------------------------------------------
+
+
+
+
+Postel                                                          [Page 7]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   3.3.  VERIFYING AND EXPANDING
+
+      SMTP provides as additional features, commands to verify a user
+      name or expand a mailing list.  This is done with the VRFY and
+      EXPN commands, which have character string arguments.  For the
+      VRFY command, the string is a user name, and the response may
+      include the full name of the user and must include the mailbox of
+      the user.  For the EXPN command, the string identifies a mailing
+      list, and the multiline response may include the full name of the
+      users and must give the mailboxes on the mailing list.
+
+      "User name" is a fuzzy term and used purposely.  If a host
+      implements the VRFY or EXPN commands then at least local mailboxes
+      must be recognized as "user names".  If a host chooses to
+      recognize other strings as "user names" that is allowed.
+
+      In some hosts the distinction between a mailing list and an alias
+      for a single mailbox is a bit fuzzy, since a common data structure
+      may hold both types of entries, and it is possible to have mailing
+      lists of one mailbox.  If a request is made to verify a mailing
+      list a positive response can be given if on receipt of a message
+      so addressed it will be delivered to everyone on the list,
+      otherwise an error should be reported (e.g., "550 That is a
+      mailing list, not a user").  If a request is made to expand a user
+      name a positive response can be formed by returning a list
+      containing one name, or an error can be reported (e.g., "550 That
+      is a user name, not a mailing list").
+
+      In the case of a multiline reply (normal for EXPN) exactly one
+      mailbox is to be specified on each line of the reply.  In the case
+      of an ambiguous request, for example, "VRFY Smith", where there
+      are two Smith's the response must be "553 User ambiguous".
+
+      The case of verifying a user name is straightforward as shown in
+      example 3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 8]                                                          Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+      -------------------------------------------------------------
+
+                    Example of Verifying a User Name
+
+         Either
+
+            S: VRFY Smith
+            R: 250 Fred Smith <Smith@USC-ISIF.ARPA>
+
+         Or
+
+            S: VRFY Smith
+            R: 251 User not local; will forward to <Smith@USC-ISIQ.ARPA>
+
+         Or
+
+            S: VRFY Jones
+            R: 550 String does not match anything.
+
+         Or
+
+            S: VRFY Jones
+            R: 551 User not local; please try <Jones@USC-ISIQ.ARPA>
+
+         Or
+
+            S: VRFY Gourzenkyinplatz
+            R: 553 User ambiguous.
+
+                               Example 3
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                          [Page 9]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      The case of expanding a mailbox list requires a multiline reply as
+      shown in example 4.
+
+      -------------------------------------------------------------
+
+                  Example of Expanding a Mailing List
+
+         Either
+
+            S: EXPN Example-People
+            R: 250-Jon Postel <Postel@USC-ISIF.ARPA>
+            R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+            R: 250-Sam Q. Smith <SQSmith@USC-ISIQ.ARPA>
+            R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+            R: 250-<joe@foo-unix.ARPA>
+            R: 250 <xyz@bar-unix.ARPA>
+
+         Or
+
+            S: EXPN Executive-Washroom-List
+            R: 550 Access Denied to You.
+
+                               Example 4
+
+      -------------------------------------------------------------
+
+      The character string arguments of the VRFY and EXPN commands
+      cannot be further restricted due to the variety of implementations
+      of the user name and mailbox list concepts.  On some systems it
+      may be appropriate for the argument of the EXPN command to be a
+      file name for a file containing a mailing list, but again there is
+      a variety of file naming conventions in the Internet.
+
+      The VRFY and EXPN commands are not included in the minimum
+      implementation (Section 4.5.1), and are not required to work
+      across relays when they are implemented.
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 10]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   3.4.  SENDING AND MAILING
+
+      The main purpose of SMTP is to deliver messages to user's
+      mailboxes.  A very similar service provided by some hosts is to
+      deliver messages to user's terminals (provided the user is active
+      on the host).  The delivery to the user's mailbox is called
+      "mailing", the delivery to the user's terminal is called
+      "sending".  Because in many hosts the implementation of sending is
+      nearly identical to the implementation of mailing these two
+      functions are combined in SMTP.  However the sending commands are
+      not included in the required minimum implementation
+      (Section 4.5.1).  Users should have the ability to control the
+      writing of messages on their terminals.  Most hosts permit the
+      users to accept or refuse such messages.
+
+      The following three command are defined to support the sending
+      options.  These are used in the mail transaction instead of the
+      MAIL command and inform the receiver-SMTP of the special semantics
+      of this transaction:
+
+         SEND <SP> FROM:<reverse-path> <CRLF>
+
+            The SEND command requires that the mail data be delivered to
+            the user's terminal.  If the user is not active (or not
+            accepting terminal messages) on the host a 450 reply may
+            returned to a RCPT command.  The mail transaction is
+            successful if the message is delivered the terminal.
+
+         SOML <SP> FROM:<reverse-path> <CRLF>
+
+            The Send Or MaiL command requires that the mail data be
+            delivered to the user's terminal if the user is active (and
+            accepting terminal messages) on the host.  If the user is
+            not active (or not accepting terminal messages) then the
+            mail data is entered into the user's mailbox.  The mail
+            transaction is successful if the message is delivered either
+            to the terminal or the mailbox.
+
+         SAML <SP> FROM:<reverse-path> <CRLF>
+
+            The Send And MaiL command requires that the mail data be
+            delivered to the user's terminal if the user is active (and
+            accepting terminal messages) on the host.  In any case the
+            mail data is entered into the user's mailbox.  The mail
+            transaction is successful if the message is delivered the
+            mailbox.
+
+
+
+Postel                                                         [Page 11]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      The same reply codes that are used for the MAIL commands are used
+      for these commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 12]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   3.5.  OPENING AND CLOSING
+
+      At the time the transmission channel is opened there is an
+      exchange to ensure that the hosts are communicating with the hosts
+      they think they are.
+
+      The following two commands are used in transmission channel
+      opening and closing:
+
+         HELO <SP> <domain> <CRLF>
+
+         QUIT <CRLF>
+
+      In the HELO command the host sending the command identifies
+      itself; the command may be interpreted as saying "Hello, I am
+      <domain>".
+
+      -------------------------------------------------------------
+
+                     Example of Connection Opening
+
+         R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+         S: HELO USC-ISIF.ARPA
+         R: 250 BBN-UNIX.ARPA
+
+                               Example 5
+
+      -------------------------------------------------------------
+
+      -------------------------------------------------------------
+
+                     Example of Connection Closing
+
+         S: QUIT
+         R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+                               Example 6
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 13]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   3.6.  RELAYING
+
+      The forward-path may be a source route of the form
+      "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts.  This
+      form is used to emphasize the distinction between an address and a
+      route.  The mailbox is an absolute address, and the route is
+      information about how to get there.  The two concepts should not
+      be confused.
+
+      Conceptually the elements of the forward-path are moved to the
+      reverse-path as the message is relayed from one server-SMTP to
+      another.  The reverse-path is a reverse source route, (i.e., a
+      source route from the current location of the message to the
+      originator of the message).  When a server-SMTP deletes its
+      identifier from the forward-path and inserts it into the
+      reverse-path, it must use the name it is known by in the
+      environment it is sending into, not the environment the mail came
+      from, in case the server-SMTP is known by different names in
+      different environments.
+
+      If when the message arrives at an SMTP the first element of the
+      forward-path is not the identifier of that SMTP the element is not
+      deleted from the forward-path and is used to determine the next
+      SMTP to send the message to.  In any case, the SMTP adds its own
+      identifier to the reverse-path.
+
+      Using source routing the receiver-SMTP receives mail to be relayed
+      to another server-SMTP  The receiver-SMTP may accept or reject the
+      task of relaying the mail in the same way it accepts or rejects
+      mail for a local user.  The receiver-SMTP transforms the command
+      arguments by moving its own identifier from the forward-path to
+      the beginning of the reverse-path.  The receiver-SMTP then becomes
+      a sender-SMTP, establishes a transmission channel to the next SMTP
+      in the forward-path, and sends it the mail.
+
+      The first host in the reverse-path should be the host sending the
+      SMTP commands, and the first host in the forward-path should be
+      the host receiving the SMTP commands.
+
+      Notice that the forward-path and reverse-path appear in the SMTP
+      commands and replies, but not necessarily in the message.  That
+      is, there is no need for these paths and especially this syntax to
+      appear in the "To:" , "From:", "CC:", etc. fields of the message
+      header.
+
+      If a server-SMTP has accepted the task of relaying the mail and
+
+
+
+[Page 14]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+      later finds that the forward-path is incorrect or that the mail
+      cannot be delivered for whatever reason, then it must construct an
+      "undeliverable mail" notification message and send it to the
+      originator of the undeliverable mail (as indicated by the
+      reverse-path).
+
+      This notification message must be from the server-SMTP at this
+      host.  Of course, server-SMTPs should not send notification
+      messages about problems with notification messages.  One way to
+      prevent loops in error reporting is to specify a null reverse-path
+      in the MAIL command of a notification message.  When such a
+      message is relayed it is permissible to leave the reverse-path
+      null.  A MAIL command with a null reverse-path appears as follows:
+
+         MAIL FROM:<>
+
+      An undeliverable mail notification message is shown in example 7.
+      This notification is in response to a message originated by JOE at
+      HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
+      to HOSTZ.  What we see in the example is the transaction between
+      HOSTY and HOSTX, which is the first step in the return of the
+      notification message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 15]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      -------------------------------------------------------------
+
+            Example Undeliverable Mail Notification Message
+
+         S: MAIL FROM:<>
+         R: 250 ok
+         S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA>
+         R: 250 ok
+         S: DATA
+         R: 354 send the mail data, end with .
+         S: Date: 23 Oct 81 11:22:33
+         S: From: SMTP@HOSTY.ARPA
+         S: To: JOE@HOSTW.ARPA
+         S: Subject: Mail System Problem
+         S:
+         S:   Sorry JOE, your message to SAM@HOSTZ.ARPA lost.
+         S:   HOSTZ.ARPA said this:
+         S:    "550 No Such User"
+         S: .
+         R: 250 ok
+
+                               Example 7
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 16]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   3.7.  DOMAINS
+
+      Domains are a recently introduced concept in the ARPA Internet
+      mail system.  The use of domains changes the address space from a
+      flat global space of simple character string host names to a
+      hierarchically structured rooted tree of global addresses.  The
+      host name is replaced by a domain and host designator which is a
+      sequence of domain element strings separated by periods with the
+      understanding that the domain elements are ordered from the most
+      specific to the most general.
+
+      For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
+      "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
+
+      Whenever domain names are used in SMTP only the official names are
+      used, the use of nicknames or aliases is not allowed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 17]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   3.8.  CHANGING ROLES
+
+      The TURN command may be used to reverse the roles of the two
+      programs communicating over the transmission channel.
+
+      If program-A is currently the sender-SMTP and it sends the TURN
+      command and receives an ok reply (250) then program-A becomes the
+      receiver-SMTP.
+
+      If program-B is currently the receiver-SMTP and it receives the
+      TURN command and sends an ok reply (250) then program-B becomes
+      the sender-SMTP.
+
+      To refuse to change roles the receiver sends the 502 reply.
+
+      Please note that this command is optional.  It would not normally
+      be used in situations where the transmission channel is TCP.
+      However, when the cost of establishing the transmission channel is
+      high, this command may be quite useful.  For example, this command
+      may be useful in supporting be mail exchange using the public
+      switched telephone system as a transmission channel, especially if
+      some hosts poll other hosts for mail exchanges.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 18]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+4.  THE SMTP SPECIFICATIONS
+
+   4.1.  SMTP COMMANDS
+
+      4.1.1.  COMMAND SEMANTICS
+
+         The SMTP commands define the mail transfer or the mail system
+         function requested by the user.  SMTP commands are character
+         strings terminated by <CRLF>.  The command codes themselves are
+         alphabetic characters terminated by <SP> if parameters follow
+         and <CRLF> otherwise.  The syntax of mailboxes must conform to
+         receiver site conventions.  The SMTP commands are discussed
+         below.  The SMTP replies are discussed in the Section 4.2.
+
+         A mail transaction involves several data objects which are
+         communicated as arguments to different commands.  The
+         reverse-path is the argument of the MAIL command, the
+         forward-path is the argument of the RCPT command, and the mail
+         data is the argument of the DATA command.  These arguments or
+         data objects must be transmitted and held pending the
+         confirmation communicated by the end of mail data indication
+         which finalizes the transaction.  The model for this is that
+         distinct buffers are provided to hold the types of data
+         objects, that is, there is a reverse-path buffer, a
+         forward-path buffer, and a mail data buffer.  Specific commands
+         cause information to be appended to a specific buffer, or cause
+         one or more buffers to be cleared.
+
+         HELLO (HELO)
+
+            This command is used to identify the sender-SMTP to the
+            receiver-SMTP.  The argument field contains the host name of
+            the sender-SMTP.
+
+            The receiver-SMTP identifies itself to the sender-SMTP in
+            the connection greeting reply, and in the response to this
+            command.
+
+            This command and an OK reply to it confirm that both the
+            sender-SMTP and the receiver-SMTP are in the initial state,
+            that is, there is no transaction in progress and all state
+            tables and buffers are cleared.
+
+
+
+
+
+
+
+Postel                                                         [Page 19]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         MAIL (MAIL)
+
+            This command is used to initiate a mail transaction in which
+            the mail data is delivered to one or more mailboxes.  The
+            argument field contains a reverse-path.
+
+            The reverse-path consists of an optional list of hosts and
+            the sender mailbox.  When the list of hosts is present, it
+            is a "reverse" source route and indicates that the mail was
+            relayed through each host on the list (the first host in the
+            list was the most recent relay).  This list is used as a
+            source route to return non-delivery notices to the sender.
+            As each relay host adds itself to the beginning of the list,
+            it must use its name as known in the IPCE to which it is
+            relaying the mail rather than the IPCE from which the mail
+            came (if they are different).  In some types of error
+            reporting messages (for example, undeliverable mail
+            notifications) the reverse-path may be null (see Example 7).
+
+            This command clears the reverse-path buffer, the
+            forward-path buffer, and the mail data buffer; and inserts
+            the reverse-path information from this command into the
+            reverse-path buffer.
+
+         RECIPIENT (RCPT)
+
+            This command is used to identify an individual recipient of
+            the mail data; multiple recipients are specified by multiple
+            use of this command.
+
+            The forward-path consists of an optional list of hosts and a
+            required destination mailbox.  When the list of hosts is
+            present, it is a source route and indicates that the mail
+            must be relayed to the next host on the list.  If the
+            receiver-SMTP does not implement the relay function it may
+            user the same reply it would for an unknown local user
+            (550).
+
+            When mail is relayed, the relay host must remove itself from
+            the beginning forward-path and put itself at the beginning
+            of the reverse-path.  When mail reaches its ultimate
+            destination (the forward-path contains only a destination
+            mailbox), the receiver-SMTP inserts it into the destination
+            mailbox in accordance with its host mail conventions.
+
+
+
+
+
+[Page 20]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+               For example, mail received at relay host A with arguments
+
+                  FROM:<USERX@HOSTY.ARPA>
+                  TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA>
+
+               will be relayed on to host B with arguments
+
+                  FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA>
+                  TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>.
+
+            This command causes its forward-path argument to be appended
+            to the forward-path buffer.
+
+         DATA (DATA)
+
+            The receiver treats the lines following the command as mail
+            data from the sender.  This command causes the mail data
+            from this command to be appended to the mail data buffer.
+            The mail data may contain any of the 128 ASCII character
+            codes.
+
+            The mail data is terminated by a line containing only a
+            period, that is the character sequence "<CRLF>.<CRLF>" (see
+            Section 4.5.2 on Transparency).  This is the end of mail
+            data indication.
+
+            The end of mail data indication requires that the receiver
+            must now process the stored mail transaction information.
+            This processing consumes the information in the reverse-path
+            buffer, the forward-path buffer, and the mail data buffer,
+            and on the completion of this command these buffers are
+            cleared.  If the processing is successful the receiver must
+            send an OK reply.  If the processing fails completely the
+            receiver must send a failure reply.
+
+            When the receiver-SMTP accepts a message either for relaying
+            or for final delivery it inserts at the beginning of the
+            mail data a time stamp line.  The time stamp line indicates
+            the identity of the host that sent the message, and the
+            identity of the host that received the message (and is
+            inserting this time stamp), and the date and time the
+            message was received.  Relayed messages will have multiple
+            time stamp lines.
+
+            When the receiver-SMTP makes the "final delivery" of a
+            message it inserts at the beginning of the mail data a
+
+
+
+Postel                                                         [Page 21]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+            return path line.  The return path line preserves the
+            information in the <reverse-path> from the MAIL command.
+            Here, final delivery means the message leaves the SMTP
+            world.  Normally, this would mean it has been delivered to
+            the destination user, but in some cases it may be further
+            processed and transmitted by another mail system.
+
+               It is possible for the mailbox in the return path be
+               different from the actual sender's mailbox, for example,
+               if error responses are to be delivered a special error
+               handling mailbox rather than the message senders.
+
+            The preceding two paragraphs imply that the final mail data
+            will begin with a  return path line, followed by one or more
+            time stamp lines.  These lines will be followed by the mail
+            data header and body [2].  See Example 8.
+
+            Special mention is needed of the response and further action
+            required when the processing following the end of mail data
+            indication is partially successful.  This could arise if
+            after accepting several recipients and the mail data, the
+            receiver-SMTP finds that the mail data can be successfully
+            delivered to some of the recipients, but it cannot be to
+            others (for example, due to mailbox space allocation
+            problems).  In such a situation, the response to the DATA
+            command must be an OK reply.  But, the receiver-SMTP must
+            compose and send an "undeliverable mail" notification
+            message to the originator of the message.  Either a single
+            notification which lists all of the recipients that failed
+            to get the message, or separate notification messages must
+            be sent for each failed recipient (see Example 7).  All
+            undeliverable mail notification messages are sent using the
+            MAIL command (even if they result from processing a SEND,
+            SOML, or SAML command).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 22]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+     -------------------------------------------------------------
+
+            Example of Return Path and Received Time Stamps
+
+      Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA>   
+      Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
+      Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
+      Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
+      Date: 27 Oct 81 15:01:01 PST                                
+      From: JOE@ABC.ARPA                                          
+      Subject: Improved Mailing System Installed                  
+      To: SAM@JKL.ARPA                                            
+                                    
+      This is to inform you that ...                              
+
+                               Example 8
+
+     -------------------------------------------------------------
+
+         SEND (SEND)
+
+            This command is used to initiate a mail transaction in which
+            the mail data is delivered to one or more terminals.  The
+            argument field contains a reverse-path.  This command is
+            successful if the message is delivered to a terminal.
+
+            The reverse-path consists of an optional list of hosts and
+            the sender mailbox.  When the list of hosts is present, it
+            is a "reverse" source route and indicates that the mail was
+            relayed through each host on the list (the first host in the
+            list was the most recent relay).  This list is used as a
+            source route to return non-delivery notices to the sender.
+            As each relay host adds itself to the beginning of the list,
+            it must use its name as known in the IPCE to which it is
+            relaying the mail rather than the IPCE from which the mail
+            came (if they are different).
+
+            This command clears the reverse-path buffer, the
+            forward-path buffer, and the mail data buffer; and inserts
+            the reverse-path information from this command into the
+            reverse-path buffer.
+
+         SEND OR MAIL (SOML)
+
+            This command is used to initiate a mail transaction in which
+            the mail data is delivered to one or more terminals or
+
+
+
+Postel                                                         [Page 23]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+            mailboxes. For each recipient the mail data is delivered to
+            the recipient's terminal if the recipient is active on the
+            host (and accepting terminal messages), otherwise to the
+            recipient's mailbox.  The argument field contains a
+            reverse-path.  This command is successful if the message is
+            delivered to a terminal or the mailbox.
+
+            The reverse-path consists of an optional list of hosts and
+            the sender mailbox.  When the list of hosts is present, it
+            is a "reverse" source route and indicates that the mail was
+            relayed through each host on the list (the first host in the
+            list was the most recent relay).  This list is used as a
+            source route to return non-delivery notices to the sender.
+            As each relay host adds itself to the beginning of the list,
+            it must use its name as known in the IPCE to which it is
+            relaying the mail rather than the IPCE from which the mail
+            came (if they are different).
+
+            This command clears the reverse-path buffer, the
+            forward-path buffer, and the mail data buffer; and inserts
+            the reverse-path information from this command into the
+            reverse-path buffer.
+
+         SEND AND MAIL (SAML)
+
+            This command is used to initiate a mail transaction in which
+            the mail data is delivered to one or more terminals and
+            mailboxes. For each recipient the mail data is delivered to
+            the recipient's terminal if the recipient is active on the
+            host (and accepting terminal messages), and for all
+            recipients to the recipient's mailbox.  The argument field
+            contains a reverse-path.  This command is successful if the
+            message is delivered to the mailbox.
+
+            The reverse-path consists of an optional list of hosts and
+            the sender mailbox.  When the list of hosts is present, it
+            is a "reverse" source route and indicates that the mail was
+            relayed through each host on the list (the first host in the
+            list was the most recent relay).  This list is used as a
+            source route to return non-delivery notices to the sender.
+            As each relay host adds itself to the beginning of the list,
+            it must use its name as known in the IPCE to which it is
+            relaying the mail rather than the IPCE from which the mail
+            came (if they are different).
+
+            This command clears the reverse-path buffer, the
+
+
+
+[Page 24]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+            forward-path buffer, and the mail data buffer; and inserts
+            the reverse-path information from this command into the
+            reverse-path buffer.
+
+         RESET (RSET)
+
+            This command specifies that the current mail transaction is
+            to be aborted.  Any stored sender, recipients, and mail data
+            must be discarded, and all buffers and state tables cleared.
+            The receiver must send an OK reply.
+
+         VERIFY (VRFY)
+
+            This command asks the receiver to confirm that the argument
+            identifies a user.  If it is a user name, the full name of
+            the user (if known) and the fully specified mailbox are
+            returned.
+
+            This command has no effect on any of the reverse-path
+            buffer, the forward-path buffer, or the mail data buffer.
+
+         EXPAND (EXPN)
+
+            This command asks the receiver to confirm that the argument
+            identifies a mailing list, and if so, to return the
+            membership of that list.  The full name of the users (if
+            known) and the fully specified mailboxes are returned in a
+            multiline reply.
+
+            This command has no effect on any of the reverse-path
+            buffer, the forward-path buffer, or the mail data buffer.
+
+         HELP (HELP)
+
+            This command causes the receiver to send helpful information
+            to the sender of the HELP command.  The command may take an
+            argument (e.g., any command name) and return more specific
+            information as a response.
+
+            This command has no effect on any of the reverse-path
+            buffer, the forward-path buffer, or the mail data buffer.
+
+
+
+
+
+
+
+
+Postel                                                         [Page 25]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         NOOP (NOOP)
+
+            This command does not affect any parameters or previously
+            entered commands.  It specifies no action other than that
+            the receiver send an OK reply.
+
+            This command has no effect on any of the reverse-path
+            buffer, the forward-path buffer, or the mail data buffer.
+
+         QUIT (QUIT)
+
+            This command specifies that the receiver must send an OK
+            reply, and then close the transmission channel.
+
+            The receiver should not close the transmission channel until
+            it receives and replies to a QUIT command (even if there was
+            an error).  The sender should not close the transmission
+            channel until it send a QUIT command and receives the reply
+            (even if there was an error response to a previous command).
+            If the connection is closed prematurely the receiver should
+            act as if a RSET command had been received (canceling any
+            pending transaction, but not undoing any previously
+            completed transaction), the sender should act as if the
+            command or transaction in progress had received a temporary
+            error (4xx).
+
+         TURN (TURN)
+
+            This command specifies that the receiver must either (1)
+            send an OK reply and then take on the role of the
+            sender-SMTP, or (2) send a refusal reply and retain the role
+            of the receiver-SMTP.
+
+            If program-A is currently the sender-SMTP and it sends the
+            TURN command and receives an OK reply (250) then program-A
+            becomes the receiver-SMTP.  Program-A is then in the initial
+            state as if the transmission channel just opened, and it
+            then sends the 220 service ready greeting.
+
+            If program-B is currently the receiver-SMTP and it receives
+            the TURN command and sends an OK reply (250) then program-B
+            becomes the sender-SMTP.  Program-B is then in the initial
+            state as if the transmission channel just opened, and it
+            then expects to receive the 220 service ready greeting.
+
+            To refuse to change roles the receiver sends the 502 reply.
+
+
+
+[Page 26]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+         There are restrictions on the order in which these command may
+         be used.
+
+            The first command in a session must be the HELO command.
+            The HELO command may be used later in a session as well.  If
+            the HELO command argument is not acceptable a 501 failure
+            reply must be returned and the receiver-SMTP must stay in
+            the same state.
+
+            The NOOP, HELP, EXPN, and VRFY commands can be used at any
+            time during a session.
+
+            The MAIL, SEND, SOML, or SAML commands begin a mail
+            transaction.  Once started a mail transaction consists of
+            one of the transaction beginning commands, one or more RCPT
+            commands, and a DATA command, in that order.  A mail
+            transaction may be aborted by the RSET command.  There may
+            be zero or more transactions in a session.
+
+            If the transaction beginning command argument is not
+            acceptable a 501 failure reply must be returned and the
+            receiver-SMTP must stay in the same state.  If the commands
+            in a transaction are out of order a 503 failure reply must
+            be returned and the receiver-SMTP must stay in the same
+            state.
+
+            The last command in a session must be the QUIT command.  The
+            QUIT command can not be used at any other time in a session.
+
+      4.1.2.  COMMAND SYNTAX
+
+         The commands consist of a command code followed by an argument
+         field.  Command codes are four alphabetic characters.  Upper
+         and lower case alphabetic characters are to be treated
+         identically.  Thus, any of the following may represent the mail
+         command:
+
+            MAIL    Mail    mail    MaIl    mAIl
+
+         This also applies to any symbols representing parameter values,
+         such as "TO" or "to" for the forward-path.  Command codes and
+         the argument fields are separated by one or more spaces.
+         However, within the reverse-path and forward-path arguments
+         case is important.  In particular, in some hosts the user
+         "smith" is different from the user "Smith".
+
+
+
+
+Postel                                                         [Page 27]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         The argument field consists of a variable length character
+         string ending with the character sequence <CRLF>.  The receiver
+         is to take no action until this sequence is received.
+
+         Square brackets denote an optional argument field.  If the
+         option is not taken, the appropriate default is implied.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 28]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+         The following are the SMTP commands:
+
+            HELO <SP> <domain> <CRLF>
+
+            MAIL <SP> FROM:<reverse-path> <CRLF>
+
+            RCPT <SP> TO:<forward-path> <CRLF>
+
+            DATA <CRLF>
+
+            RSET <CRLF>
+
+            SEND <SP> FROM:<reverse-path> <CRLF>
+
+            SOML <SP> FROM:<reverse-path> <CRLF>
+
+            SAML <SP> FROM:<reverse-path> <CRLF>
+
+            VRFY <SP> <string> <CRLF>
+
+            EXPN <SP> <string> <CRLF>
+
+            HELP [<SP> <string>] <CRLF>
+
+            NOOP <CRLF>
+
+            QUIT <CRLF>
+
+            TURN <CRLF>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 29]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         The syntax of the above argument fields (using BNF notation
+         where applicable) is given below.  The "..." notation indicates
+         that a field may be repeated one or more times.
+
+            <reverse-path> ::= <path>
+
+            <forward-path> ::= <path>
+
+            <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
+
+            <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
+
+            <at-domain> ::= "@" <domain>
+
+            <domain> ::=  <element> | <element> "." <domain>
+
+            <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
+
+            <mailbox> ::= <local-part> "@" <domain>
+
+            <local-part> ::= <dot-string> | <quoted-string>
+
+            <name> ::= <a> <ldh-str> <let-dig>
+
+            <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+            <let-dig> ::= <a> | <d>
+
+            <let-dig-hyp> ::= <a> | <d> | "-"
+
+            <dot-string> ::= <string> | <string> "." <dot-string>
+
+            <string> ::= <char> | <char> <string>
+
+            <quoted-string> ::=  """ <qtext> """
+
+            <qtext> ::=  "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
+
+            <char> ::= <c> | "\" <x>
+
+            <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
+
+            <number> ::= <d> | <d> <number>
+
+            <CRLF> ::= <CR> <LF>
+
+
+
+
+[Page 30]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+            <CR> ::= the carriage return character (ASCII code 13)
+
+            <LF> ::= the line feed character (ASCII code 10)
+
+            <SP> ::= the space character (ASCII code 32)
+
+            <snum> ::= one, two, or three digits representing a decimal
+                      integer value in the range 0 through 255
+
+            <a> ::= any one of the 52 alphabetic characters A through Z
+                      in upper case and a through z in lower case
+
+            <c> ::= any one of the 128 ASCII characters, but not any
+                      <special> or <SP>
+
+            <d> ::= any one of the ten digits 0 through 9
+
+            <q> ::= any one of the 128 ASCII characters except <CR>,
+                      <LF>, quote ("), or backslash (\)
+
+            <x> ::= any one of the 128 ASCII characters (no exceptions)
+
+            <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
+                      | "," | ";" | ":" | "@"  """ | the control
+                      characters (ASCII codes 0 through 31 inclusive and
+                      127)
+
+         Note that the backslash, "\", is a quote character, which is
+         used to indicate that the next character is to be used
+         literally (instead of its normal interpretation).  For example,
+         "Joe\,Smith" could be used to indicate a single nine character
+         user field with comma being the fourth character of the field.
+
+         Hosts are generally known by names which are translated to
+         addresses in each host.  Note that the name elements of domains
+         are the official names -- no use of nicknames or aliases is
+         allowed.
+
+         Sometimes a host is not known to the translation function and
+         communication is blocked.  To bypass this barrier two numeric
+         forms are also allowed for host "names".  One form is a decimal
+         integer prefixed by a pound sign, "#", which indicates the
+         number is the address of the host.  Another form is four small
+         decimal integers separated by dots and enclosed by brackets,
+         e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
+         Address in four 8-bit fields.
+
+
+
+Postel                                                         [Page 31]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         The time stamp line and the return path line are formally
+         defined as follows:
+
+         <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
+
+         <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
+
+            <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
+                      <daytime>
+
+            <from-domain> ::= "FROM" <SP> <domain> <SP>
+
+            <by-domain> ::= "BY" <SP> <domain> <SP>
+
+            <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
+
+            <via> ::= "VIA" <SP> <link> <SP>
+
+            <with> ::= "WITH" <SP> <protocol> <SP>
+
+            <id> ::= "ID" <SP> <string> <SP>
+
+            <for> ::= "FOR" <SP> <path> <SP>
+
+            <link> ::= The standard names for links are registered with
+                      the Network Information Center.
+
+            <protocol> ::= The standard names for protocols are
+                      registered with the Network Information Center.
+
+            <daytime> ::= <SP> <date> <SP> <time>
+
+            <date> ::= <dd> <SP> <mon> <SP> <yy>
+
+            <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
+
+            <dd> ::= the one or two decimal integer day of the month in
+                      the range 1 to 31.
+
+            <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+                      "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+
+            <yy> ::= the two decimal integer year of the century in the
+                      range 00 to 99.
+
+
+
+
+
+[Page 32]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+            <hh> ::= the two decimal integer hour of the day in the
+                      range 00 to 24.
+
+            <mm> ::= the two decimal integer minute of the hour in the
+                      range 00 to 59.
+
+            <ss> ::= the two decimal integer second of the minute in the
+                      range 00 to 59.
+
+            <zone> ::= "UT" for Universal Time (the default) or other
+                      time zone designator (as in [2]).
+
+            
+
+     -------------------------------------------------------------
+
+                          Return Path Example
+
+         Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA>
+
+                               Example 9
+
+     -------------------------------------------------------------
+
+     -------------------------------------------------------------
+
+                        Time Stamp Line Example
+
+      Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
+
+         Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
+                   id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT
+
+                               Example 10
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 33]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   4.2.  SMTP REPLIES
+
+      Replies to SMTP commands are devised to ensure the synchronization
+      of requests and actions in the process of mail transfer, and to
+      guarantee that the sender-SMTP always knows the state of the
+      receiver-SMTP.  Every command must generate exactly one reply.
+
+         The details of the command-reply sequence are made explicit in
+         Section 5.3 on Sequencing and Section 5.4 State Diagrams.
+
+      An SMTP reply consists of a three digit number (transmitted as
+      three alphanumeric characters) followed by some text.  The number
+      is intended for use by automata to determine what state to enter
+      next; the text is meant for the human user.  It is intended that
+      the three digits contain enough encoded information that the
+      sender-SMTP need not examine the text and may either discard it or
+      pass it on to the user, as appropriate.  In particular, the text
+      may be receiver-dependent and context dependent, so there are
+      likely to be varying texts for each reply code.  A discussion of
+      the theory of reply codes is given in Appendix E.  Formally, a
+      reply is defined to be the sequence:  a three-digit code, <SP>,
+      one line of text, and <CRLF>, or a multiline reply (as defined in
+      Appendix E).  Only the EXPN and HELP commands are expected to
+      result in multiline replies in normal circumstances, however
+      multiline replies are allowed for any command.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 34]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+      4.2.1.  REPLY CODES BY FUNCTION GROUPS
+
+         500 Syntax error, command unrecognized
+            [This may include errors such as command line too long]
+         501 Syntax error in parameters or arguments
+         502 Command not implemented
+         503 Bad sequence of commands
+         504 Command parameter not implemented
+          
+         211 System status, or system help reply
+         214 Help message
+            [Information on how to use the receiver or the meaning of a
+            particular non-standard command; this reply is useful only
+            to the human user]
+          
+         220 <domain> Service ready
+         221 <domain> Service closing transmission channel
+         421 <domain> Service not available,
+             closing transmission channel
+            [This may be a reply to any command if the service knows it
+            must shut down]
+          
+         250 Requested mail action okay, completed
+         251 User not local; will forward to <forward-path>
+         450 Requested mail action not taken: mailbox unavailable
+            [E.g., mailbox busy]
+         550 Requested action not taken: mailbox unavailable
+            [E.g., mailbox not found, no access]
+         451 Requested action aborted: error in processing
+         551 User not local; please try <forward-path>
+         452 Requested action not taken: insufficient system storage
+         552 Requested mail action aborted: exceeded storage allocation
+         553 Requested action not taken: mailbox name not allowed
+            [E.g., mailbox syntax incorrect]
+         354 Start mail input; end with <CRLF>.<CRLF>
+         554 Transaction failed
+         
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 35]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      4.2.2.  NUMERIC ORDER LIST OF REPLY CODES
+
+         211 System status, or system help reply
+         214 Help message
+            [Information on how to use the receiver or the meaning of a
+            particular non-standard command; this reply is useful only
+            to the human user]
+         220 <domain> Service ready
+         221 <domain> Service closing transmission channel
+         250 Requested mail action okay, completed
+         251 User not local; will forward to <forward-path>
+          
+         354 Start mail input; end with <CRLF>.<CRLF>
+          
+         421 <domain> Service not available,
+             closing transmission channel
+            [This may be a reply to any command if the service knows it
+            must shut down]
+         450 Requested mail action not taken: mailbox unavailable
+            [E.g., mailbox busy]
+         451 Requested action aborted: local error in processing
+         452 Requested action not taken: insufficient system storage
+          
+         500 Syntax error, command unrecognized
+            [This may include errors such as command line too long]
+         501 Syntax error in parameters or arguments
+         502 Command not implemented
+         503 Bad sequence of commands
+         504 Command parameter not implemented
+         550 Requested action not taken: mailbox unavailable
+            [E.g., mailbox not found, no access]
+         551 User not local; please try <forward-path>
+         552 Requested mail action aborted: exceeded storage allocation
+         553 Requested action not taken: mailbox name not allowed
+            [E.g., mailbox syntax incorrect]
+         554 Transaction failed
+         
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 36]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   4.3.  SEQUENCING OF COMMANDS AND REPLIES
+
+      The communication between the sender and receiver is intended to
+      be an alternating dialogue, controlled by the sender.  As such,
+      the sender issues a command and the receiver responds with a
+      reply.  The sender must wait for this response before sending
+      further commands.
+
+      One important reply is the connection greeting.  Normally, a
+      receiver will send a 220 "Service ready" reply when the connection
+      is completed.  The sender should wait for this greeting message
+      before sending any commands.
+
+         Note: all the greeting type replies have the official name of
+         the server host as the first word following the reply code.
+
+            For example,
+
+               220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
+
+      The table below lists alternative success and failure replies for
+      each command.  These must be strictly adhered to; a receiver may
+      substitute text in the replies, but the meaning and action implied
+      by the code numbers and by the specific command reply sequence
+      cannot be altered.
+
+      COMMAND-REPLY SEQUENCES
+
+         Each command is listed with its possible replies.  The prefixes
+         used before the possible replies are "P" for preliminary (not
+         used in SMTP), "I" for intermediate, "S" for success, "F" for
+         failure, and "E" for error.  The 421 reply (service not
+         available, closing transmission channel) may be given to any
+         command if the SMTP-receiver knows it must shut down.  This
+         listing forms the basis for the State Diagrams in Section 4.4.
+
+            CONNECTION ESTABLISHMENT
+               S: 220
+               F: 421
+            HELO
+               S: 250
+               E: 500, 501, 504, 421
+            MAIL
+               S: 250
+               F: 552, 451, 452
+               E: 500, 501, 421
+
+
+
+Postel                                                         [Page 37]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+            RCPT
+               S: 250, 251
+               F: 550, 551, 552, 553, 450, 451, 452
+               E: 500, 501, 503, 421
+            DATA
+               I: 354 -> data -> S: 250
+                                 F: 552, 554, 451, 452
+               F: 451, 554
+               E: 500, 501, 503, 421
+            RSET
+               S: 250
+               E: 500, 501, 504, 421
+            SEND
+               S: 250
+               F: 552, 451, 452
+               E: 500, 501, 502, 421
+            SOML
+               S: 250
+               F: 552, 451, 452
+               E: 500, 501, 502, 421
+            SAML
+               S: 250
+               F: 552, 451, 452
+               E: 500, 501, 502, 421
+            VRFY
+               S: 250, 251
+               F: 550, 551, 553
+               E: 500, 501, 502, 504, 421
+            EXPN
+               S: 250
+               F: 550
+               E: 500, 501, 502, 504, 421
+            HELP
+               S: 211, 214
+               E: 500, 501, 502, 504, 421
+            NOOP
+               S: 250
+               E: 500, 421
+            QUIT
+               S: 221
+               E: 500
+            TURN
+               S: 250
+               F: 502
+               E: 500, 503
+
+
+
+
+[Page 38]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   4.4.  STATE DIAGRAMS
+
+      Following are state diagrams for a simple-minded SMTP
+      implementation.  Only the first digit of the reply codes is used.
+      There is one state diagram for each group of SMTP commands.  The
+      command groupings were determined by constructing a model for each
+      command and then collecting together the commands with
+      structurally identical models.
+
+      For each command there are three possible outcomes:  "success"
+      (S), "failure" (F), and "error" (E). In the state diagrams below
+      we use the symbol B for "begin", and the symbol W for "wait for
+      reply".
+
+      First, the diagram that represents most of the SMTP commands:
+
+         
+                                  1,3    +---+
+                             ----------->| E |
+                            |            +---+
+                            |
+         +---+    cmd    +---+    2      +---+
+         | B |---------->| W |---------->| S |
+         +---+           +---+           +---+
+                            |
+                            |     4,5    +---+
+                             ----------->| F |
+                                         +---+
+         
+
+         This diagram models the commands:
+
+            HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
+            NOOP, QUIT, TURN.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 39]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      A more complex diagram models the DATA command:
+
+         
+         +---+   DATA    +---+ 1,2                 +---+
+         | B |---------->| W |-------------------->| E |
+         +---+           +---+        ------------>+---+
+                         3| |4,5     |
+                          | |        |
+            --------------   -----   |
+           |                      |  |             +---+
+           |               ----------     -------->| S |
+           |              |       |      |         +---+
+           |              |  ------------
+           |              | |     |
+           V           1,3| |2    |
+         +---+   data    +---+     --------------->+---+
+         |   |---------->| W |                     | F |
+         +---+           +---+-------------------->+---+
+                              4,5
+
+
+         Note that the "data" here is a series of lines sent from the
+         sender to the receiver with no response expected until the last
+         line is sent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 40]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   4.5.  DETAILS
+
+      4.5.1.  MINIMUM IMPLEMENTATION
+
+         In order to make SMTP workable, the following minimum
+         implementation is required for all receivers:
+
+            COMMANDS -- HELO
+                        MAIL
+                        RCPT
+                        DATA
+                        RSET
+                        NOOP
+                        QUIT
+
+      4.5.2.  TRANSPARENCY
+
+         Without some provision for data transparency the character
+         sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
+         by the user.  In general, users are not aware of such
+         "forbidden" sequences.  To allow all user composed text to be
+         transmitted transparently the following procedures are used.
+
+            1. Before sending a line of mail text the sender-SMTP checks
+            the first character of the line.  If it is a period, one
+            additional period is inserted at the beginning of the line.
+
+            2. When a line of mail text is received by the receiver-SMTP
+            it checks the line.  If the line is composed of a single
+            period it is the end of mail.  If the first character is a
+            period and there are other characters on the line, the first
+            character is deleted.
+
+         The mail data may contain any of the 128 ASCII characters.  All
+         characters are to be delivered to the recipient's mailbox
+         including format effectors and other control characters.  If
+         the transmission channel provides an 8-bit byte (octets) data
+         stream, the 7-bit ASCII codes are transmitted right justified
+         in the octets with the high order bits cleared to zero.
+
+            In some systems it may be necessary to transform the data as
+            it is received and stored.  This may be necessary for hosts
+            that use a different character set than ASCII as their local
+            character set, or that store data in records rather than
+
+
+
+
+
+Postel                                                         [Page 41]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+            strings.  If such transforms are necessary, they must be
+            reversible -- especially if such transforms are applied to
+            mail being relayed.
+
+      4.5.3.  SIZES
+
+         There are several objects that have required minimum maximum
+         sizes.  That is, every implementation must be able to receive
+         objects of at least these sizes, but must not send objects
+         larger than these sizes.
+
+                                    
+          ****************************************************
+          *                                                  *
+          *  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
+          *  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+          *  OF THESE OBJECTS SHOULD BE USED.                *
+          *                                                  *
+          ****************************************************
+
+            user
+
+               The maximum total length of a user name is 64 characters.
+
+            domain
+
+               The maximum total length of a domain name or number is 64
+               characters.
+
+            path
+
+               The maximum total length of a reverse-path or
+               forward-path is 256 characters (including the punctuation
+               and element separators).
+
+            command line
+
+               The maximum total length of a command line including the
+               command word and the <CRLF> is 512 characters.
+
+            reply line
+
+               The maximum total length of a reply line including the
+               reply code and the <CRLF> is 512 characters.
+
+
+
+
+
+[Page 42]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+            text line
+
+               The maximum total length of a text line including the
+               <CRLF> is 1000 characters (but not counting the leading
+               dot duplicated for transparency).
+
+            recipients buffer
+
+               The maximum total number of recipients that must be
+               buffered is 100 recipients.
+
+                                    
+          ****************************************************
+          *                                                  *
+          *  TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION  *
+          *  TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+          *  OF THESE OBJECTS SHOULD BE USED.                *
+          *                                                  *
+          ****************************************************
+
+         Errors due to exceeding these limits may be reported by using
+         the reply codes, for example:
+
+            500 Line too long.
+
+            501 Path too long
+
+            552 Too many recipients.
+
+            552 Too much mail data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 43]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+APPENDIX A
+
+   TCP Transport service
+
+      The Transmission Control Protocol [3] is used in the ARPA
+      Internet, and in any network following the US DoD standards for
+      internetwork protocols.
+
+      Connection Establishment
+
+         The SMTP transmission channel is a TCP connection established
+         between the sender process port U and the receiver process port
+         L.  This single full duplex connection is used as the
+         transmission channel.  This protocol is assigned the service
+         port 25 (31 octal), that is L=25.
+
+      Data Transfer
+
+         The TCP connection supports the transmission of 8-bit bytes.
+         The SMTP data is 7-bit ASCII characters.  Each character is
+         transmitted as an 8-bit byte with the high-order bit cleared to
+         zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 44]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+APPENDIX B
+
+   NCP Transport service
+
+      The ARPANET Host-to-Host Protocol [4] (implemented by the Network
+      Control Program) may be used in the ARPANET.
+
+      Connection Establishment
+
+         The SMTP transmission channel is established via NCP between
+         the sender process socket U and receiver process socket L.  The
+         Initial Connection Protocol [5] is followed resulting in a pair
+         of simplex connections.  This pair of connections is used as
+         the transmission channel.  This protocol is assigned the
+         contact socket 25 (31 octal), that is L=25.
+
+      Data Transfer
+
+         The NCP data connections are established in 8-bit byte mode.
+         The SMTP data is 7-bit ASCII characters.  Each character is
+         transmitted as an 8-bit byte with the high-order bit cleared to
+         zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 45]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+APPENDIX C
+
+   NITS
+
+      The Network Independent Transport Service [6] may be used.
+
+      Connection Establishment
+
+         The SMTP transmission channel is established via NITS between
+         the sender process and receiver process.  The sender process
+         executes the CONNECT primitive, and the waiting receiver
+         process executes the ACCEPT primitive.
+
+      Data Transfer
+
+         The NITS connection supports the transmission of 8-bit bytes.
+         The SMTP data is 7-bit ASCII characters.  Each character is
+         transmitted as an 8-bit byte with the high-order bit cleared to
+         zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 46]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+APPENDIX D
+
+   X.25 Transport service
+
+      It may be possible to use the X.25 service [7] as provided by the
+      Public Data Networks directly, however, it is suggested that a
+      reliable end-to-end protocol such as TCP be used on top of X.25
+      connections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 47]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+APPENDIX E
+
+   Theory of Reply Codes
+
+      The three digits of the reply each have a special significance.
+      The first digit denotes whether the response is good, bad or
+      incomplete.  An unsophisticated sender-SMTP will be able to
+      determine its next action (proceed as planned, redo, retrench,
+      etc.) by simply examining this first digit.  A sender-SMTP that
+      wants to know approximately what kind of error occurred (e.g.,
+      mail system error, command syntax error) may examine the second
+      digit, reserving the third digit for the finest gradation of
+      information.
+
+         There are five values for the first digit of the reply code:
+
+            1yz   Positive Preliminary reply
+
+               The command has been accepted, but the requested action
+               is being held in abeyance, pending confirmation of the
+               information in this reply.  The sender-SMTP should send
+               another command specifying whether to continue or abort
+               the action.
+
+                  [Note: SMTP does not have any commands that allow this
+                  type of reply, and so does not have the continue or
+                  abort commands.]
+
+            2yz   Positive Completion reply
+
+               The requested action has been successfully completed.  A
+               new request may be initiated.
+
+            3yz   Positive Intermediate reply
+
+               The command has been accepted, but the requested action
+               is being held in abeyance, pending receipt of further
+               information.  The sender-SMTP should send another command
+               specifying this information.  This reply is used in
+               command sequence groups.
+
+            4yz   Transient Negative Completion reply
+
+               The command was not accepted and the requested action did
+               not occur.  However, the error condition is temporary and
+               the action may be requested again.  The sender should
+
+
+
+[Page 48]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+               return to the beginning of the command sequence (if any).
+               It is difficult to assign a meaning to "transient" when
+               two different sites (receiver- and sender- SMTPs) must
+               agree on the interpretation.  Each reply in this category
+               might have a different time value, but the sender-SMTP is
+               encouraged to try again.  A rule of thumb to determine if
+               a reply fits into the 4yz or the 5yz category (see below)
+               is that replies are 4yz if they can be repeated without
+               any change in command form or in properties of the sender
+               or receiver.  (E.g., the command is repeated identically
+               and the receiver does not put up a new implementation.)
+
+            5yz   Permanent Negative Completion reply
+
+               The command was not accepted and the requested action did
+               not occur.  The sender-SMTP is discouraged from repeating
+               the exact request (in the same sequence).  Even some
+               "permanent" error conditions can be corrected, so the
+               human user may want to direct the sender-SMTP to
+               reinitiate the command sequence by direct action at some
+               point in the future (e.g., after the spelling has been
+               changed, or the user has altered the account status).
+
+         The second digit encodes responses in specific categories:
+
+            x0z   Syntax -- These replies refer to syntax errors,
+                  syntactically correct commands that don't fit any
+                  functional category, and unimplemented or superfluous
+                  commands.
+
+            x1z   Information --  These are replies to requests for
+                  information, such as status or help.
+
+            x2z   Connections -- These are replies referring to the
+                  transmission channel.
+
+            x3z   Unspecified as yet.
+
+            x4z   Unspecified as yet.
+
+            x5z   Mail system -- These replies indicate the status of
+                  the receiver mail system vis-a-vis the requested
+                  transfer or other mail system action.
+
+         The third digit gives a finer gradation of meaning in each
+         category specified by the second digit.  The list of replies
+
+
+
+Postel                                                         [Page 49]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         illustrates this.  Each reply text is recommended rather than
+         mandatory, and may even change according to the command with
+         which it is associated.  On the other hand, the reply codes
+         must strictly follow the specifications in this section.
+         Receiver implementations should not invent new codes for
+         slightly different situations from the ones described here, but
+         rather adapt codes already defined.
+
+         For example, a command such as NOOP whose successful execution
+         does not offer the sender-SMTP any new information will return
+         a 250 reply.  The response is 502 when the command requests an
+         unimplemented non-site-specific action.  A refinement of that
+         is the 504 reply for a command that is implemented, but that
+         requests an unimplemented parameter.
+
+      The reply text may be longer than a single line; in these cases
+      the complete text must be marked so the sender-SMTP knows when it
+      can stop reading the reply.  This requires a special format to
+      indicate a multiple line reply.
+
+         The format for multiline replies requires that every line,
+         except the last, begin with the reply code, followed
+         immediately by a hyphen, "-" (also known as minus), followed by
+         text.  The last line will begin with the reply code, followed
+         immediately by <SP>, optionally some text, and <CRLF>.
+
+            For example:
+                                123-First line
+                                123-Second line
+                                123-234 text beginning with numbers
+                                123 The last line
+
+         In many cases the sender-SMTP then simply needs to search for
+         the reply code followed by <SP> at the beginning of a line, and
+         ignore all preceding lines.  In a few cases, there is important
+         data for the sender in the reply "text".  The sender will know
+         these cases from the current context.
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 50]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+APPENDIX F
+
+   Scenarios
+
+      This section presents complete scenarios of several types of SMTP
+      sessions.
+
+   A Typical SMTP Transaction Scenario
+
+      This SMTP example shows mail sent by Smith at host USC-ISIF, to
+      Jones, Green, and Brown at host BBN-UNIX.  Here we assume that
+      host USC-ISIF contacts host BBN-UNIX directly.  The mail is
+      accepted for Jones and Brown.  Green does not have a mailbox at
+      host BBN-UNIX.
+
+      -------------------------------------------------------------
+
+         R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+         S: HELO USC-ISIF.ARPA
+         R: 250 BBN-UNIX.ARPA
+
+         S: MAIL FROM:<Smith@USC-ISIF.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Jones@BBN-UNIX.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Green@BBN-UNIX.ARPA>
+         R: 550 No such user here
+
+         S: RCPT TO:<Brown@BBN-UNIX.ARPA>
+         R: 250 OK
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+                               Scenario 1
+
+      -------------------------------------------------------------
+
+
+
+Postel                                                         [Page 51]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   Aborted SMTP Transaction Scenario
+
+      -------------------------------------------------------------
+
+         R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
+         S: HELO ISI-VAXA.ARPA
+         R: 250 MIT-Multics.ARPA
+
+         S: MAIL FROM:<Smith@ISI-VAXA.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Jones@MIT-Multics.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Green@MIT-Multics.ARPA>
+         R: 550 No such user here
+
+         S: RSET
+         R: 250 OK
+
+         S: QUIT
+         R: 221 MIT-Multics.ARPA Service closing transmission channel
+
+                               Scenario 2
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 52]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   Relayed Mail Scenario
+
+      -------------------------------------------------------------
+
+         Step 1  --  Source Host to Relay Host
+
+            R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+            S: HELO MIT-AI.ARPA
+            R: 250 USC-ISIE.ARPA
+
+            S: MAIL FROM:<JQP@MIT-AI.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA>
+            R: 250 OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Date: 2 Nov 81 22:33:44
+            S: From: John Q. Public <JQP@MIT-AI.ARPA>
+            S: Subject:  The Next Meeting of the Board
+            S: To: Jones@BBN-Vax.ARPA
+            S:
+            S: Bill:
+            S: The next meeting of the board of directors will be
+            S: on Tuesday.
+            S:                                              John.
+            S: .
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 53]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         Step 2  --  Relay Host to Destination Host
+
+            R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
+            S: HELO USC-ISIE.ARPA
+            R: 250 BBN-VAX.ARPA
+
+            S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<Jones@BBN-VAX.ARPA>
+            R: 250 OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
+               2 Nov 81 22:40:10 UT
+            S: Date: 2 Nov 81 22:33:44
+            S: From: John Q. Public <JQP@MIT-AI.ARPA>
+            S: Subject:  The Next Meeting of the Board
+            S: To: Jones@BBN-Vax.ARPA
+            S:
+            S: Bill:
+            S: The next meeting of the board of directors will be
+            S: on Tuesday.
+            S:                                              John.
+            S: .
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+                               Scenario 3
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 54]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   Verifying and Sending Scenario
+
+      -------------------------------------------------------------
+
+         R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+         S: HELO MIT-MC.ARPA
+         R: 250 SU-SCORE.ARPA
+
+         S: VRFY Crispin
+         R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+         S: SEND FROM:<EAK@MIT-MC.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+         R: 250 OK
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+                               Scenario 4
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 55]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   Sending and Mailing Scenarios
+
+      First the user's name is verified, then  an attempt is made to
+      send to the user's terminal.  When that fails, the messages is
+      mailed to the user's mailbox.
+
+      -------------------------------------------------------------
+
+         R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+         S: HELO MIT-MC.ARPA
+         R: 250 SU-SCORE.ARPA
+
+         S: VRFY Crispin
+         R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+         S: SEND FROM:<EAK@MIT-MC.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+         R: 450 User not active now
+
+         S: RSET
+         R: 250 OK
+
+         S: MAIL FROM:<EAK@MIT-MC.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+         R: 250 OK
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+                               Scenario 5
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+[Page 56]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+      Doing the preceding scenario more efficiently.
+
+      -------------------------------------------------------------
+
+         R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+         S: HELO MIT-MC.ARPA
+         R: 250 SU-SCORE.ARPA
+
+         S: VRFY Crispin
+         R: 250 Mark Crispin <Admin.MRC@SU-SCORE.ARPA>
+
+         S: SOML FROM:<EAK@MIT-MC.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<Admin.MRC@SU-SCORE.ARPA>
+         R: 250 User not active now, so will do mail.
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+                               Scenario 6
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 57]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   Mailing List Scenario
+
+      First each of two mailing lists are expanded in separate sessions
+      with different hosts.  Then the message is sent to everyone that
+      appeared on either list (but no duplicates) via a relay host.
+
+      -------------------------------------------------------------
+
+         Step 1  --  Expanding the First List
+
+            R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
+            S: HELO SU-SCORE.ARPA
+            R: 250 MIT-AI.ARPA
+
+            S: EXPN Example-People
+            R: 250-<ABC@MIT-MC.ARPA>
+            R: 250-Fred Fonebone <Fonebone@USC-ISIQ.ARPA>
+            R: 250-Xenon Y. Zither <XYZ@MIT-AI.ARPA>
+            R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+            R: 250-<joe@foo-unix.ARPA>
+            R: 250 <xyz@bar-unix.ARPA>
+
+            S: QUIT
+            R: 221 MIT-AI.ARPA Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 58]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+         Step 2  --  Expanding the Second List
+
+            R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
+            S: HELO SU-SCORE.ARPA
+            R: 250 MIT-MC.ARPA
+
+            S: EXPN Interested-Parties
+            R: 250-Al Calico <ABC@MIT-MC.ARPA>
+            R: 250-<XYZ@MIT-AI.ARPA>
+            R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+            R: 250-<fred@BBN-UNIX.ARPA>
+            R: 250 <xyz@bar-unix.ARPA>
+
+            S: QUIT
+            R: 221 MIT-MC.ARPA Service closing transmission channel
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 59]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+         Step 3  --  Mailing to All via a Relay Host
+
+            R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+            S: HELO SU-SCORE.ARPA
+            R: 250 USC-ISIE.ARPA
+
+            S: MAIL FROM:<Account.Person@SU-SCORE.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA>
+            R: 250 OK
+            S: RCPT
+                TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA>
+            R: 250 OK
+            S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA>
+            R: 250 OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Blah blah blah...
+            S: ...etc. etc. etc.
+            S: .
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+                               Scenario 7
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 60]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   Forwarding Scenarios
+
+      -------------------------------------------------------------
+
+         R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
+         S: HELO LBL-UNIX.ARPA
+         R: 250 USC-ISIF.ARPA
+
+         S: MAIL FROM:<mo@LBL-UNIX.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<fred@USC-ISIF.ARPA>
+         R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 USC-ISIF.ARPA Service closing transmission channel
+
+                               Scenario 8
+
+      -------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel                                                         [Page 61]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+      -------------------------------------------------------------
+
+         Step 1  --  Trying the Mailbox at the First Host
+
+            R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
+            S: HELO LBL-UNIX.ARPA
+            R: 250 USC-ISIF.ARPA
+
+            S: MAIL FROM:<mo@LBL-UNIX.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<fred@USC-ISIF.ARPA>
+            R: 251 User not local; will forward to <Jones@USC-ISI.ARPA>
+
+            S: RSET
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISIF.ARPA Service closing transmission channel
+
+         Step 2  --  Delivering the Mail at the Second Host
+
+            R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
+            S: HELO LBL-UNIX.ARPA
+            R: 250 USC-ISI.ARPA
+
+            S: MAIL FROM:<mo@LBL-UNIX.ARPA>
+            R: 250 OK
+
+            S: RCPT TO:<Jones@USC-ISI.ARPA>
+            R: OK
+
+            S: DATA
+            R: 354 Start mail input; end with <CRLF>.<CRLF>
+            S: Blah blah blah...
+            S: ...etc. etc. etc.
+            S: .
+            R: 250 OK
+
+            S: QUIT
+            R: 221 USC-ISI.ARPA Service closing transmission channel
+
+                               Scenario 9
+
+      -------------------------------------------------------------
+
+
+
+
+[Page 62]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   Too Many Recipients Scenario
+
+      -------------------------------------------------------------
+
+         R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
+         S: HELO USC-ISIF.ARPA
+         R: 250 BERKELEY.ARPA
+
+         S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<fabry@BERKELEY.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<eric@BERKELEY.ARPA>
+         R: 552 Recipient storage full, try again in another transaction
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: MAIL FROM:<Postel@USC-ISIF.ARPA>
+         R: 250 OK
+
+         S: RCPT TO:<eric@BERKELEY.ARPA>
+         R: 250 OK
+
+         S: DATA
+         R: 354 Start mail input; end with <CRLF>.<CRLF>
+         S: Blah blah blah...
+         S: ...etc. etc. etc.
+         S: .
+         R: 250 OK
+
+         S: QUIT
+         R: 221 BERKELEY.ARPA Service closing transmission channel
+
+                              Scenario 10
+
+      -------------------------------------------------------------
+
+      Note that a real implementation must handle many recipients as
+      specified in Section 4.5.3.
+
+
+
+Postel                                                         [Page 63]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+GLOSSARY
+
+   ASCII
+
+      American Standard Code for Information Interchange [1].
+
+   command
+
+      A request for a mail service action sent by the sender-SMTP to the
+      receiver-SMTP.
+
+   domain
+
+      The hierarchially structured global character string address of a
+      host computer in the mail system.
+
+   end of mail data indication
+
+      A special sequence of characters that indicates the end of the
+      mail data.  In particular, the five characters carriage return,
+      line feed, period, carriage return, line feed, in that order.
+
+   host
+
+      A computer in the internetwork environment on which mailboxes or
+      SMTP processes reside.
+
+   line
+
+      A a sequence of ASCII characters ending with a <CRLF>.
+
+   mail data
+
+      A sequence of ASCII characters of arbitrary length, which conforms
+      to the standard set in the Standard for the Format of ARPA
+      Internet Text Messages (RFC 822 [2]).
+
+   mailbox
+
+      A character string (address) which identifies a user to whom mail
+      is to be sent.  Mailbox normally consists of the host and user
+      specifications.  The standard mailbox naming convention is defined
+      to be "user@domain".  Additionally, the "container" in which mail
+      is stored.
+
+
+
+
+
+[Page 64]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+   receiver-SMTP process
+
+      A process which transfers mail in cooperation with a sender-SMTP
+      process.  It waits for a connection to be established via the
+      transport service.  It receives SMTP commands from the
+      sender-SMTP, sends replies, and performs the specified operations.
+
+   reply
+
+      A reply is an acknowledgment (positive or negative) sent from
+      receiver to sender via the transmission channel in response to a
+      command.  The general form of a reply is a completion code
+      (including error codes) followed by a text string.  The codes are
+      for use by programs and the text is usually intended for human
+      users.
+
+   sender-SMTP process
+
+      A process which transfers mail in cooperation with a receiver-SMTP
+      process.  A local language may be used in the user interface
+      command/reply dialogue.  The sender-SMTP initiates the transport
+      service connection.  It initiates SMTP commands, receives replies,
+      and governs the transfer of mail.
+
+   session
+
+      The set of exchanges that occur while the transmission channel is
+      open.
+
+   transaction
+
+      The set of exchanges required for one message to be transmitted
+      for one or more recipients.
+
+   transmission channel
+
+      A full-duplex communication path between a sender-SMTP and a
+      receiver-SMTP for the exchange of commands, replies, and mail
+      text.
+
+   transport service
+
+      Any reliable stream-oriented data communication services.  For
+      example, NCP, TCP, NITS.
+
+
+
+
+
+Postel                                                         [Page 65]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   user
+
+      A human being (or a process on behalf of a human being) wishing to
+      obtain mail transfer service.  In addition, a recipient of
+      computer mail.
+
+   word
+
+      A sequence of printing characters.
+
+   <CRLF>
+
+      The characters carriage return and line feed (in that order).
+
+   <SP>
+
+      The space character.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 66]                                                         Postel
+
+
+                                                                        
+RFC 821                                                      August 1982
+                                           Simple Mail Transfer Protocol
+
+
+
+REFERENCES
+
+   [1]  ASCII
+
+      ASCII, "USA Code for Information Interchange", United States of
+      America Standards Institute, X3.4, 1968.  Also in:  Feinler, E.
+      and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
+      the Defense Communications Agency by SRI International, Menlo
+      Park, California, Revised January 1978.
+
+   [2]  RFC 822
+
+      Crocker, D., "Standard for the Format of ARPA Internet Text
+      Messages," RFC 822, Department of Electrical Engineering,
+      University of Delaware, August 1982.
+
+   [3]  TCP
+
+      Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+      Program Protocol Specification", RFC 793, USC/Information Sciences
+      Institute, NTIS AD Number A111091, September 1981.  Also in:
+      Feinler, E. and J. Postel, eds., "Internet Protocol Transition
+      Workbook", SRI International, Menlo Park, California, March 1982.
+
+   [4]  NCP
+
+      McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
+      January 1972.  Also in:  Feinler, E. and J. Postel, eds., "ARPANET
+      Protocol Handbook", NIC 7104, for the Defense Communications
+      Agency by SRI International, Menlo Park, California, Revised
+      January 1978.
+
+   [5]  Initial Connection Protocol
+
+      Postel, J., "Official Initial Connection Protocol", NIC 7101,
+      11 June 1971.  Also in:  Feinler, E. and J. Postel, eds., "ARPANET
+      Protocol Handbook", NIC 7104, for the Defense Communications
+      Agency by SRI International, Menlo Park, California, Revised
+      January 1978.
+
+   [6]  NITS
+
+      PSS/SG3, "A Network Independent Transport Service", Study Group 3,
+      The Post Office PSS Users Group, February 1980.  Available from
+      the DCPU, National Physical Laboratory, Teddington, UK.
+
+
+
+
+Postel                                                         [Page 67]
+
+
+                                                                        
+August 1982                                                      RFC 821
+Simple Mail Transfer Protocol                                           
+
+
+
+   [7]  X.25
+
+      CCITT, "Recommendation X.25 - Interface Between Data Terminal
+      Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
+      Terminals Operating in the Packet Mode on Public Data Networks,"
+      CCITT Orange Book, Vol. VIII.2, International Telephone and
+      Telegraph Consultative Committee, Geneva, 1976.
+
+         
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+[Page 68]                                                         Postel
+
diff --git a/RFC/rfc822.txt b/RFC/rfc822.txt
new file mode 100644
index 00000000..35b09a3c
--- /dev/null
+++ b/RFC/rfc822.txt
@@ -0,0 +1,2901 @@
+
+ 
+
+
+
+
+     RFC #  822
+
+     Obsoletes:  RFC #733  (NIC #41952)
+
+
+
+
+
+
+
+
+
+
+
+
+                        STANDARD FOR THE FORMAT OF
+
+                        ARPA INTERNET TEXT MESSAGES
+
+
+
+
+
+
+                              August 13, 1982
+
+
+
+
+
+
+                                Revised by
+
+                             David H. Crocker
+
+
+                      Dept. of Electrical Engineering
+                 University of Delaware, Newark, DE  19711
+                      Network:  DCrocker @ UDel-Relay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+                             TABLE OF CONTENTS
+
+
+     PREFACE ....................................................   ii
+
+     1.  INTRODUCTION ...........................................    1
+
+         1.1.  Scope ............................................    1
+         1.2.  Communication Framework ..........................    2
+
+     2.  NOTATIONAL CONVENTIONS .................................    3
+
+     3.  LEXICAL ANALYSIS OF MESSAGES ...........................    5
+
+         3.1.  General Description ..............................    5
+         3.2.  Header Field Definitions .........................    9
+         3.3.  Lexical Tokens ...................................   10
+         3.4.  Clarifications ...................................   11
+
+     4.  MESSAGE SPECIFICATION ..................................   17
+
+         4.1.  Syntax ...........................................   17
+         4.2.  Forwarding .......................................   19
+         4.3.  Trace Fields .....................................   20
+         4.4.  Originator Fields ................................   21
+         4.5.  Receiver Fields ..................................   23
+         4.6.  Reference Fields .................................   23
+         4.7.  Other Fields .....................................   24
+
+     5.  DATE AND TIME SPECIFICATION ............................   26
+
+         5.1.  Syntax ...........................................   26
+         5.2.  Semantics ........................................   26
+
+     6.  ADDRESS SPECIFICATION ..................................   27
+
+         6.1.  Syntax ...........................................   27
+         6.2.  Semantics ........................................   27
+         6.3.  Reserved Address .................................   33
+
+     7.  BIBLIOGRAPHY ...........................................   34
+
+
+                             APPENDIX
+
+     A.  EXAMPLES ...............................................   36
+     B.  SIMPLE FIELD PARSING ...................................   40
+     C.  DIFFERENCES FROM RFC #733 ..............................   41
+     D.  ALPHABETICAL LISTING OF SYNTAX RULES ...................   44
+
+
+     August 13, 1982               - i -                      RFC #822
+
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+                                  PREFACE
+
+
+          By 1977, the Arpanet employed several informal standards for
+     the  text  messages (mail) sent among its host computers.  It was
+     felt necessary to codify these practices and  provide  for  those
+     features  that  seemed  imminent.   The result of that effort was
+     Request for Comments (RFC) #733, "Standard for the Format of ARPA
+     Network Text Message", by Crocker, Vittal, Pogran, and Henderson.
+     The specification attempted to avoid major  changes  in  existing
+     software, while permitting several new features.
+
+          This document revises the specifications  in  RFC  #733,  in
+     order  to  serve  the  needs  of the larger and more complex ARPA
+     Internet.  Some of RFC #733's features failed  to  gain  adequate
+     acceptance.   In  order to simplify the standard and the software
+     that follows it, these features have been removed.   A  different
+     addressing  scheme  is  used, to handle the case of inter-network
+     mail; and the concept of re-transmission has been introduced.
+
+          This specification is intended for use in the ARPA Internet.
+     However, an attempt has been made to free it of any dependence on
+     that environment, so that it can be applied to other network text
+     message systems.
+
+          The specification of RFC #733 took place over the course  of
+     one  year, using the ARPANET mail environment, itself, to provide
+     an on-going forum for discussing the capabilities to be included.
+     More  than  twenty individuals, from across the country, partici-
+     pated in  the  original  discussion.   The  development  of  this
+     revised specification has, similarly, utilized network mail-based
+     group discussion.  Both specification efforts  greatly  benefited
+     from the comments and ideas of the participants.
+
+          The syntax of the standard,  in  RFC  #733,  was  originally
+     specified  in  the  Backus-Naur Form (BNF) meta-language.  Ken L.
+     Harrenstien, of SRI International, was responsible for  re-coding
+     the  BNF  into  an  augmented  BNF  that makes the representation
+     smaller and easier to understand.
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - ii -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     1.  INTRODUCTION
+
+     1.1.  SCOPE
+
+          This standard specifies a syntax for text messages that  are
+     sent  among  computer  users, within the framework of "electronic
+     mail".  The standard supersedes  the  one  specified  in  ARPANET
+     Request  for Comments #733, "Standard for the Format of ARPA Net-
+     work Text Messages".
+
+          In this context, messages are viewed as having  an  envelope
+     and  contents.   The  envelope  contains  whatever information is
+     needed to accomplish transmission  and  delivery.   The  contents
+     compose  the object to be delivered to the recipient.  This stan-
+     dard applies only to the format and some of the semantics of mes-
+     sage  contents.   It contains no specification of the information
+     in the envelope.
+
+          However, some message systems may use information  from  the
+     contents  to create the envelope.  It is intended that this stan-
+     dard facilitate the acquisition of such information by programs.
+
+          Some message systems may  store  messages  in  formats  that
+     differ  from the one specified in this standard.  This specifica-
+     tion is intended strictly as a definition of what message content
+     format is to be passed BETWEEN hosts.
+
+     Note:  This standard is NOT intended to dictate the internal for-
+            mats  used  by sites, the specific message system features
+            that they are expected to support, or any of  the  charac-
+            teristics  of  user interface programs that create or read
+            messages.
+
+          A distinction should be made between what the  specification
+     REQUIRES  and  what  it ALLOWS.  Messages can be made complex and
+     rich with formally-structured components of information or can be
+     kept small and simple, with a minimum of such information.  Also,
+     the standard simplifies the interpretation  of  differing  visual
+     formats  in  messages;  only  the  visual  aspect of a message is
+     affected and not the interpretation  of  information  within  it.
+     Implementors may choose to retain such visual distinctions.
+
+          The formal definition is divided into four levels.  The bot-
+     tom level describes the meta-notation used in this document.  The
+     second level describes basic lexical analyzers that  feed  tokens
+     to  higher-level  parsers.   Next is an overall specification for
+     messages; it permits distinguishing individual fields.   Finally,
+     there is definition of the contents of several structured fields.
+
+
+
+     August 13, 1982               - 1 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     1.2.  COMMUNICATION FRAMEWORK
+
+          Messages consist of lines of text.   No  special  provisions
+     are  made for encoding drawings, facsimile, speech, or structured
+     text.  No significant consideration has been given  to  questions
+     of  data  compression  or to transmission and storage efficiency,
+     and the standard tends to be free with the number  of  bits  con-
+     sumed.   For  example,  field  names  are specified as free text,
+     rather than special terse codes.
+
+          A general "memo" framework is used.  That is, a message con-
+     sists of some information in a rigid format, followed by the main
+     part of the message, with a format that is not specified in  this
+     document.   The  syntax of several fields of the rigidly-formated
+     ("headers") section is defined in  this  specification;  some  of
+     these fields must be included in all messages.
+
+          The syntax  that  distinguishes  between  header  fields  is
+     specified  separately  from  the  internal  syntax for particular
+     fields.  This separation is intended to allow simple  parsers  to
+     operate on the general structure of messages, without concern for
+     the detailed structure of individual header fields.   Appendix  B
+     is provided to facilitate construction of these parsers.
+
+          In addition to the fields specified in this document, it  is
+     expected  that  other fields will gain common use.  As necessary,
+     the specifications for these "extension-fields" will be published
+     through  the same mechanism used to publish this document.  Users
+     may also  wish  to  extend  the  set  of  fields  that  they  use
+     privately.  Such "user-defined fields" are permitted.
+
+          The framework severely constrains document tone and  appear-
+     ance and is primarily useful for most intra-organization communi-
+     cations and  well-structured   inter-organization  communication.
+     It  also  can  be used for some types of inter-process communica-
+     tion, such as simple file transfer and remote job entry.  A  more
+     robust  framework might allow for multi-font, multi-color, multi-
+     dimension encoding of information.  A  less  robust  one,  as  is
+     present  in  most  single-machine  message  systems,  would  more
+     severely constrain the ability to add fields and the decision  to
+     include specific fields.  In contrast with paper-based communica-
+     tion, it is interesting to note that the RECEIVER  of  a  message
+     can   exercise  an  extraordinary  amount  of  control  over  the
+     message's appearance.  The amount of actual control available  to
+     message  receivers  is  contingent upon the capabilities of their
+     individual message systems.
+
+
+
+
+
+     August 13, 1982               - 2 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     2.  NOTATIONAL CONVENTIONS
+
+          This specification uses an augmented Backus-Naur Form  (BNF)
+     notation.  The differences from standard BNF involve naming rules
+     and indicating repetition and "local" alternatives.
+
+     2.1.  RULE NAMING
+
+          Angle brackets ("<", ">") are not  used,  in  general.   The
+     name  of  a rule is simply the name itself, rather than "<name>".
+     Quotation-marks enclose literal text (which may be  upper  and/or
+     lower  case).   Certain  basic  rules  are  in uppercase, such as
+     SPACE, TAB, CRLF, DIGIT, ALPHA, etc.  Angle brackets are used  in
+     rule  definitions,  and  in  the rest of this  document, whenever
+     their presence will facilitate discerning the use of rule names.
+
+     2.2.  RULE1 / RULE2:  ALTERNATIVES
+
+          Elements separated by slash ("/") are alternatives.   There-
+     fore "foo / bar" will accept foo or bar.
+
+     2.3.  (RULE1 RULE2):  LOCAL ALTERNATIVES
+
+          Elements enclosed in parentheses are  treated  as  a  single
+     element.   Thus,  "(elem  (foo  /  bar)  elem)"  allows the token
+     sequences "elem foo elem" and "elem bar elem".
+
+     2.4.  *RULE:  REPETITION
+
+          The character "*" preceding an element indicates repetition.
+     The full form is:
+
+                              <l>*<m>element
+
+     indicating at least <l> and at most <m> occurrences  of  element.
+     Default values are 0 and infinity so that "*(element)" allows any
+     number, including zero; "1*element" requires at  least  one;  and
+     "1*2element" allows one or two.
+
+     2.5.  [RULE]:  OPTIONAL
+
+          Square brackets enclose optional elements; "[foo  bar]"   is
+     equivalent to "*1(foo bar)".
+
+     2.6.  NRULE:  SPECIFIC REPETITION
+
+          "<n>(element)" is equivalent to "<n>*<n>(element)"; that is,
+     exactly  <n>  occurrences  of (element). Thus 2DIGIT is a 2-digit
+     number, and 3ALPHA is a string of three alphabetic characters.
+
+
+     August 13, 1982               - 3 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     2.7.  #RULE:  LISTS
+
+          A construct "#" is defined, similar to "*", as follows:
+
+                              <l>#<m>element
+
+     indicating at least <l> and at most <m> elements, each  separated
+     by  one  or more commas (","). This makes the usual form of lists
+     very easy; a rule such as '(element *("," element))' can be shown
+     as  "1#element".   Wherever this construct is used, null elements
+     are allowed, but do not  contribute  to  the  count  of  elements
+     present.   That  is,  "(element),,(element)"  is  permitted,  but
+     counts as only two elements.  Therefore, where at least one  ele-
+     ment  is required, at least one non-null element must be present.
+     Default values are 0 and infinity so that "#(element)" allows any
+     number,  including  zero;  "1#element" requires at least one; and
+     "1#2element" allows one or two.
+
+     2.8.  ; COMMENTS
+
+          A semi-colon, set off some distance to  the  right  of  rule
+     text,  starts  a comment that continues to the end of line.  This
+     is a simple way of including useful notes in  parallel  with  the
+     specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982               - 4 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.  LEXICAL ANALYSIS OF MESSAGES
+
+     3.1.  GENERAL DESCRIPTION
+
+          A message consists of header fields and, optionally, a body.
+     The  body  is simply a sequence of lines containing ASCII charac-
+     ters.  It is separated from the headers by a null line  (i.e.,  a
+     line with nothing preceding the CRLF).
+
+     3.1.1.  LONG HEADER FIELDS
+
+        Each header field can be viewed as a single, logical  line  of
+        ASCII  characters,  comprising  a field-name and a field-body.
+        For convenience, the field-body  portion  of  this  conceptual
+        entity  can be split into a multiple-line representation; this
+        is called "folding".  The general rule is that wherever  there
+        may  be  linear-white-space  (NOT  simply  LWSP-chars), a CRLF
+        immediately followed by AT LEAST one LWSP-char may instead  be
+        inserted.  Thus, the single line
+
+            To:  "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
+
+        can be represented as:
+
+            To:  "Joe & J. Harvey" <ddd @ Org>,
+                    JJV@BBN
+
+        and
+
+            To:  "Joe & J. Harvey"
+                            <ddd@ Org>, JJV
+             @BBN
+
+        and
+
+            To:  "Joe &
+             J. Harvey" <ddd @ Org>, JJV @ BBN
+
+             The process of moving  from  this  folded   multiple-line
+        representation  of a header field to its single line represen-
+        tation is called "unfolding".  Unfolding  is  accomplished  by
+        regarding   CRLF   immediately  followed  by  a  LWSP-char  as
+        equivalent to the LWSP-char.
+
+        Note:  While the standard  permits  folding  wherever  linear-
+               white-space is permitted, it is recommended that struc-
+               tured fields, such as those containing addresses, limit
+               folding  to higher-level syntactic breaks.  For address
+               fields, it  is  recommended  that  such  folding  occur
+
+
+     August 13, 1982               - 5 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+               between addresses, after the separating comma.
+
+     3.1.2.  STRUCTURE OF HEADER FIELDS
+
+        Once a field has been unfolded, it may be viewed as being com-
+        posed of a field-name followed by a colon (":"), followed by a
+        field-body, and  terminated  by  a  carriage-return/line-feed.
+        The  field-name must be composed of printable ASCII characters
+        (i.e., characters that  have  values  between  33.  and  126.,
+        decimal, except colon).  The field-body may be composed of any
+        ASCII characters, except CR or LF.  (While CR and/or LF may be
+        present  in the actual text, they are removed by the action of
+        unfolding the field.)
+
+        Certain field-bodies of headers may be  interpreted  according
+        to  an  internal  syntax  that some systems may wish to parse.
+        These  fields  are  called  "structured   fields".    Examples
+        include  fields containing dates and addresses.  Other fields,
+        such as "Subject"  and  "Comments",  are  regarded  simply  as
+        strings of text.
+
+        Note:  Any field which has a field-body  that  is  defined  as
+               other  than  simply <text> is to be treated as a struc-
+               tured field.
+
+               Field-names, unstructured field bodies  and  structured
+               field bodies each are scanned by their own, independent
+               "lexical" analyzers.
+
+     3.1.3.  UNSTRUCTURED FIELD BODIES
+
+        For some fields, such as "Subject" and "Comments",  no  struc-
+        turing  is assumed, and they are treated simply as <text>s, as
+        in the message body.  Rules of folding apply to these  fields,
+        so  that  such  field  bodies  which occupy several lines must
+        therefore have the second and successive lines indented by  at
+        least one LWSP-char.
+
+     3.1.4.  STRUCTURED FIELD BODIES
+
+        To aid in the creation and reading of structured  fields,  the
+        free  insertion   of linear-white-space (which permits folding
+        by inclusion of CRLFs)  is  allowed  between  lexical  tokens.
+        Rather  than  obscuring  the  syntax  specifications for these
+        structured fields with explicit syntax for this  linear-white-
+        space, the existence of another "lexical" analyzer is assumed.
+        This analyzer does not apply  for  unstructured  field  bodies
+        that  are  simply  strings  of  text, as described above.  The
+        analyzer provides  an  interpretation  of  the  unfolded  text
+
+
+     August 13, 1982               - 6 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        composing  the body of the field as a sequence of lexical sym-
+        bols.
+
+        These symbols are:
+
+                     -  individual special characters
+                     -  quoted-strings
+                     -  domain-literals
+                     -  comments
+                     -  atoms
+
+        The first four of these symbols  are  self-delimiting.   Atoms
+        are not; they are delimited by the self-delimiting symbols and
+        by  linear-white-space.   For  the  purposes  of  regenerating
+        sequences  of  atoms  and quoted-strings, exactly one SPACE is
+        assumed to exist, and should be used, between them.  (Also, in
+        the "Clarifications" section on "White Space", below, note the
+        rules about treatment of multiple contiguous LWSP-chars.)
+
+        So, for example, the folded body of an address field
+
+            ":sysmail"@  Some-Group. Some-Org,
+            Muhammed.(I am  the greatest) Ali @(the)Vegas.WBA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982               - 7 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        is analyzed into the following lexical symbols and types:
+
+                    :sysmail              quoted string
+                    @                     special
+                    Some-Group            atom
+                    .                     special
+                    Some-Org              atom
+                    ,                     special
+                    Muhammed              atom
+                    .                     special
+                    (I am  the greatest)  comment
+                    Ali                   atom
+                    @                     atom
+                    (the)                 comment
+                    Vegas                 atom
+                    .                     special
+                    WBA                   atom
+
+        The canonical representations for the data in these  addresses
+        are the following strings:
+
+                        ":sysmail"@Some-Group.Some-Org
+
+        and
+
+                            Muhammed.Ali@Vegas.WBA
+
+        Note:  For purposes of display, and when passing  such  struc-
+               tured information to other systems, such as mail proto-
+               col  services,  there  must  be  NO  linear-white-space
+               between  <word>s  that are separated by period (".") or
+               at-sign ("@") and exactly one SPACE between  all  other
+               <word>s.  Also, headers should be in a folded form.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982               - 8 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.2.  HEADER FIELD DEFINITIONS
+
+          These rules show a field meta-syntax, without regard for the
+     particular  type  or internal syntax.  Their purpose is to permit
+     detection of fields; also, they present to  higher-level  parsers
+     an image of each field as fitting on one line.
+
+     field       =  field-name ":" [ field-body ] CRLF
+
+     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+
+     field-body  =  field-body-contents
+                    [CRLF LWSP-char field-body]
+
+     field-body-contents =
+                   <the ASCII characters making up the field-body, as
+                    defined in the following sections, and consisting
+                    of combinations of atom, quoted-string, and
+                    specials tokens, or else consisting of texts>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982               - 9 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.3.  LEXICAL TOKENS
+
+          The following rules are used to define an underlying lexical
+     analyzer,  which  feeds  tokens to higher level parsers.  See the
+     ANSI references, in the Bibliography.
+
+                                                 ; (  Octal, Decimal.)
+     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
+     ALPHA       =  <any ASCII alphabetic character>
+                                                 ; (101-132, 65.- 90.)
+                                                 ; (141-172, 97.-122.)
+     DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
+     CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
+                     character and DEL>          ; (    177,     127.)
+     CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
+     LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
+     SPACE       =  <ASCII SP, space>            ; (     40,      32.)
+     HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
+     <">         =  <ASCII quote mark>           ; (     42,      34.)
+     CRLF        =  CR LF
+
+     LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
+
+     linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
+                                                 ; CRLF => folding
+
+     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
+                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
+                 /  "." / "[" / "]"              ;  within a word.
+
+     delimiters  =  specials / linear-white-space / comment
+
+     text        =  <any CHAR, including bare    ; => atoms, specials,
+                     CR & bare LF, but NOT       ;  comments and
+                     including CRLF>             ;  quoted-strings are
+                                                 ;  NOT recognized.
+
+     atom        =  1*<any CHAR except specials, SPACE and CTLs>
+
+     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
+                                                 ;   quoted chars.
+
+     qtext       =  <any CHAR excepting <">,     ; => may be folded
+                     "\" & CR, and including
+                     linear-white-space>
+
+     domain-literal =  "[" *(dtext / quoted-pair) "]"
+
+
+
+
+     August 13, 1982              - 10 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     dtext       =  <any CHAR excluding "[",     ; => may be folded
+                     "]", "\" & CR, & including
+                     linear-white-space>
+
+     comment     =  "(" *(ctext / quoted-pair / comment) ")"
+
+     ctext       =  <any CHAR excluding "(",     ; => may be folded
+                     ")", "\" & CR, & including
+                     linear-white-space>
+
+     quoted-pair =  "\" CHAR                     ; may quote any char
+
+     phrase      =  1*word                       ; Sequence of words
+
+     word        =  atom / quoted-string
+
+
+     3.4.  CLARIFICATIONS
+
+     3.4.1.  QUOTING
+
+        Some characters are reserved for special interpretation,  such
+        as  delimiting lexical tokens.  To permit use of these charac-
+        ters as uninterpreted data, a quoting mechanism  is  provided.
+        To quote a character, precede it with a backslash ("\").
+
+        This mechanism is not fully general.  Characters may be quoted
+        only  within  a subset of the lexical constructs.  In particu-
+        lar, quoting is limited to use within:
+
+                             -  quoted-string
+                             -  domain-literal
+                             -  comment
+
+        Within these constructs, quoting is REQUIRED for  CR  and  "\"
+        and for the character(s) that delimit the token (e.g., "(" and
+        ")" for a comment).  However, quoting  is  PERMITTED  for  any
+        character.
+
+        Note:  In particular, quoting is NOT permitted  within  atoms.
+               For  example  when  the local-part of an addr-spec must
+               contain a special character, a quoted  string  must  be
+               used.  Therefore, a specification such as:
+
+                            Full\ Name@Domain
+
+               is not legal and must be specified as:
+
+                            "Full Name"@Domain
+
+
+     August 13, 1982              - 11 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.4.2.  WHITE SPACE
+
+        Note:  In structured field bodies, multiple linear space ASCII
+               characters  (namely  HTABs  and  SPACEs) are treated as
+               single spaces and may freely surround any  symbol.   In
+               all header fields, the only place in which at least one
+               LWSP-char is REQUIRED is at the beginning of  continua-
+               tion lines in a folded field.
+
+        When passing text to processes  that  do  not  interpret  text
+        according to this standard (e.g., mail protocol servers), then
+        NO linear-white-space characters should occur between a period
+        (".") or at-sign ("@") and a <word>.  Exactly ONE SPACE should
+        be used in place of arbitrary linear-white-space  and  comment
+        sequences.
+
+        Note:  Within systems conforming to this standard, wherever  a
+               member of the list of delimiters is allowed, LWSP-chars
+               may also occur before and/or after it.
+
+        Writers of  mail-sending  (i.e.,  header-generating)  programs
+        should realize that there is no network-wide definition of the
+        effect of ASCII HT (horizontal-tab) characters on the  appear-
+        ance  of  text  at another network host; therefore, the use of
+        tabs in message headers, though permitted, is discouraged.
+
+     3.4.3.  COMMENTS
+
+        A comment is a set of ASCII characters, which is  enclosed  in
+        matching  parentheses  and which is not within a quoted-string
+        The comment construct permits message originators to add  text
+        which  will  be  useful  for  human readers, but which will be
+        ignored by the formal semantics.  Comments should be  retained
+        while  the  message  is subject to interpretation according to
+        this standard.  However, comments  must  NOT  be  included  in
+        other  cases,  such  as  during  protocol  exchanges with mail
+        servers.
+
+        Comments nest, so that if an unquoted left parenthesis  occurs
+        in  a  comment  string,  there  must  also be a matching right
+        parenthesis.  When a comment acts as the delimiter  between  a
+        sequence of two lexical symbols, such as two atoms, it is lex-
+        ically equivalent with a single SPACE,  for  the  purposes  of
+        regenerating  the  sequence, such as when passing the sequence
+        onto a mail protocol server.  Comments are  detected  as  such
+        only within field-bodies of structured fields.
+
+        If a comment is to be "folded" onto multiple lines,  then  the
+        syntax  for  folding  must  be  adhered to.  (See the "Lexical
+
+
+     August 13, 1982              - 12 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        Analysis of Messages" section on "Folding Long Header  Fields"
+        above,  and  the  section on "Case Independence" below.)  Note
+        that  the  official  semantics  therefore  do  not  "see"  any
+        unquoted CRLFs that are in comments, although particular pars-
+        ing programs may wish to note their presence.  For these  pro-
+        grams,  it would be reasonable to interpret a "CRLF LWSP-char"
+        as being a CRLF that is part of the comment; i.e., the CRLF is
+        kept  and  the  LWSP-char is discarded.  Quoted CRLFs (i.e., a
+        backslash followed by a CR followed by a  LF)  still  must  be
+        followed by at least one LWSP-char.
+
+     3.4.4.  DELIMITING AND QUOTING CHARACTERS
+
+        The quote character (backslash) and  characters  that  delimit
+        syntactic  units  are not, generally, to be taken as data that
+        are part of the delimited or quoted unit(s).   In  particular,
+        the   quotation-marks   that   define   a  quoted-string,  the
+        parentheses that define  a  comment  and  the  backslash  that
+        quotes  a  following  character  are  NOT  part of the quoted-
+        string, comment or quoted character.  A quotation-mark that is
+        to  be  part  of  a quoted-string, a parenthesis that is to be
+        part of a comment and a backslash that is to be part of either
+        must  each be preceded by the quote-character backslash ("\").
+        Note that the syntax allows any character to be quoted  within
+        a  quoted-string  or  comment; however only certain characters
+        MUST be quoted to be included as data.  These  characters  are
+        the  ones that are not part of the alternate text group (i.e.,
+        ctext or qtext).
+
+        The one exception to this rule  is  that  a  single  SPACE  is
+        assumed  to  exist  between  contiguous words in a phrase, and
+        this interpretation is independent of  the  actual  number  of
+        LWSP-chars  that  the  creator  places  between the words.  To
+        include more than one SPACE, the creator must make  the  LWSP-
+        chars be part of a quoted-string.
+
+        Quotation marks that delimit a quoted string  and  backslashes
+        that  quote  the  following character should NOT accompany the
+        quoted-string when the string is passed to processes  that  do
+        not interpret data according to this specification (e.g., mail
+        protocol servers).
+
+     3.4.5.  QUOTED-STRINGS
+
+        Where permitted (i.e., in words in structured fields)  quoted-
+        strings  are  treated  as a single symbol.  That is, a quoted-
+        string is equivalent to an atom, syntactically.  If a  quoted-
+        string  is to be "folded" onto multiple lines, then the syntax
+        for folding must be adhered to.  (See the "Lexical Analysis of
+
+
+     August 13, 1982              - 13 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        Messages"  section  on "Folding Long Header Fields" above, and
+        the section on "Case  Independence"  below.)   Therefore,  the
+        official  semantics  do  not  "see" any bare CRLFs that are in
+        quoted-strings; however particular parsing programs  may  wish
+        to  note  their presence.  For such programs, it would be rea-
+        sonable to interpret a "CRLF LWSP-char" as being a CRLF  which
+        is  part  of the quoted-string; i.e., the CRLF is kept and the
+        LWSP-char is discarded.  Quoted CRLFs (i.e., a backslash  fol-
+        lowed  by  a CR followed by a LF) are also subject to rules of
+        folding, but the presence of the quoting character (backslash)
+        explicitly  indicates  that  the  CRLF  is  data to the quoted
+        string.  Stripping off the first following LWSP-char  is  also
+        appropriate when parsing quoted CRLFs.
+
+     3.4.6.  BRACKETING CHARACTERS
+
+        There is one type of bracket which must occur in matched pairs
+        and may have pairs nested within each other:
+
+            o   Parentheses ("(" and ")") are used  to  indicate  com-
+                ments.
+
+        There are three types of brackets which must occur in  matched
+        pairs, and which may NOT be nested:
+
+            o   Colon/semi-colon (":" and ";") are   used  in  address
+                specifications  to  indicate that the included list of
+                addresses are to be treated as a group.
+
+            o   Angle brackets ("<" and ">")  are  generally  used  to
+                indicate  the  presence of a one machine-usable refer-
+                ence (e.g., delimiting mailboxes), possibly  including
+                source-routing to the machine.
+
+            o   Square brackets ("[" and "]") are used to indicate the
+                presence  of  a  domain-literal, which the appropriate
+                name-domain  is  to  use  directly,  bypassing  normal
+                name-resolution mechanisms.
+
+     3.4.7.  CASE INDEPENDENCE
+
+        Except as noted, alphabetic strings may be represented in  any
+        combination of upper and lower case.  The only syntactic units
+
+
+
+
+
+
+
+
+     August 13, 1982              - 14 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        which requires preservation of case information are:
+
+                    -  text
+                    -  qtext
+                    -  dtext
+                    -  ctext
+                    -  quoted-pair
+                    -  local-part, except "Postmaster"
+
+        When matching any other syntactic unit, case is to be ignored.
+        For  example, the field-names "From", "FROM", "from", and even
+        "FroM" are semantically equal and should all be treated ident-
+        ically.
+
+        When generating these units, any mix of upper and  lower  case
+        alphabetic  characters  may  be  used.  The case shown in this
+        specification is suggested for message-creating processes.
+
+        Note:  The reserved local-part address unit, "Postmaster",  is
+               an  exception.   When  the  value "Postmaster" is being
+               interpreted, it must be  accepted  in  any  mixture  of
+               case, including "POSTMASTER", and "postmaster".
+
+     3.4.8.  FOLDING LONG HEADER FIELDS
+
+        Each header field may be represented on exactly one line  con-
+        sisting  of the name of the field and its body, and terminated
+        by a CRLF; this is what the parser sees.  For readability, the
+        field-body  portion of long header fields may be "folded" onto
+        multiple lines of the actual field.  "Long" is commonly inter-
+        preted  to  mean greater than 65 or 72 characters.  The former
+        length serves as a limit, when the message is to be viewed  on
+        most  simple terminals which use simple display software; how-
+        ever, the limit is not imposed by this standard.
+
+        Note:  Some display software often can selectively fold lines,
+               to  suit  the display terminal.  In such cases, sender-
+               provided  folding  can  interfere  with   the   display
+               software.
+
+     3.4.9.  BACKSPACE CHARACTERS
+
+        ASCII BS characters (Backspace, decimal 8) may be included  in
+        texts and quoted-strings to effect overstriking.  However, any
+        use of backspaces which effects an overstrike to the  left  of
+        the beginning of the text or quoted-string is prohibited.
+
+
+
+
+
+     August 13, 1982              - 15 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     3.4.10.  NETWORK-SPECIFIC TRANSFORMATIONS
+
+        During transmission through heterogeneous networks, it may  be
+        necessary  to  force data to conform to a network's local con-
+        ventions.  For example, it may be required that a CR  be  fol-
+        lowed  either by LF, making a CRLF, or by <null>, if the CR is
+        to stand alone).  Such transformations are reversed, when  the
+        message exits that network.
+
+        When  crossing  network  boundaries,  the  message  should  be
+        treated  as  passing  through  two modules.  It will enter the
+        first module containing whatever network-specific  transforma-
+        tions  that  were  necessary  to  permit migration through the
+        "current" network.  It then passes through the modules:
+
+            o   Transformation Reversal
+
+                The "current" network's idiosyncracies are removed and
+                the  message  is returned to the canonical form speci-
+                fied in this standard.
+
+            o   Transformation
+
+                The "next" network's local idiosyncracies are  imposed
+                on the message.
+
+                                ------------------
+                    From   ==>  | Remove Net-A   |
+                    Net-A       | idiosyncracies |
+                                ------------------
+                                       ||
+                                       \/
+                                  Conformance
+                                  with standard
+                                       ||
+                                       \/
+                                ------------------
+                                | Impose Net-B   |  ==>  To
+                                | idiosyncracies |       Net-B
+                                ------------------
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 16 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     4.  MESSAGE SPECIFICATION
+
+     4.1.  SYNTAX
+
+     Note:  Due to an artifact of the notational conventions, the syn-
+            tax  indicates that, when present, some fields, must be in
+            a particular order.  Header fields  are  NOT  required  to
+            occur  in  any  particular  order, except that the message
+            body must occur AFTER  the  headers.   It  is  recommended
+            that,  if  present,  headers be sent in the order "Return-
+            Path", "Received", "Date",  "From",  "Subject",  "Sender",
+            "To", "cc", etc.
+
+            This specification permits multiple  occurrences  of  most
+            fields.   Except  as  noted,  their  interpretation is not
+            specified here, and their use is discouraged.
+
+          The following syntax for the bodies of various fields should
+     be  thought  of  as  describing  each field body as a single long
+     string (or line).  The "Lexical Analysis of Message"  section  on
+     "Long  Header Fields", above, indicates how such long strings can
+     be represented on more than one line in  the  actual  transmitted
+     message.
+
+     message     =  fields *( CRLF *text )       ; Everything after
+                                                 ;  first null line
+                                                 ;  is message body
+
+     fields      =    dates                      ; Creation time,
+                      source                     ;  author id & one
+                    1*destination                ;  address required
+                     *optional-field             ;  others optional
+
+     source      = [  trace ]                    ; net traversals
+                      originator                 ; original mail
+                   [  resent ]                   ; forwarded
+
+     trace       =    return                     ; path to sender
+                    1*received                   ; receipt tags
+
+     return      =  "Return-path" ":" route-addr ; return address
+
+     received    =  "Received"    ":"            ; one per relay
+                       ["from" domain]           ; sending host
+                       ["by"   domain]           ; receiving host
+                       ["via"  atom]             ; physical path
+                      *("with" atom)             ; link/mail protocol
+                       ["id"   msg-id]           ; receiver msg id
+                       ["for"  addr-spec]        ; initial form
+
+
+     August 13, 1982              - 17 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+                        ";"    date-time         ; time received
+
+     originator  =   authentic                   ; authenticated addr
+                   [ "Reply-To"   ":" 1#address] )
+
+     authentic   =   "From"       ":"   mailbox  ; Single author
+                 / ( "Sender"     ":"   mailbox  ; Actual submittor
+                     "From"       ":" 1#mailbox) ; Multiple authors
+                                                 ;  or not sender
+
+     resent      =   resent-authentic
+                   [ "Resent-Reply-To"  ":" 1#address] )
+
+     resent-authentic =
+                 =   "Resent-From"      ":"   mailbox
+                 / ( "Resent-Sender"    ":"   mailbox
+                     "Resent-From"      ":" 1#mailbox  )
+
+     dates       =   orig-date                   ; Original
+                   [ resent-date ]               ; Forwarded
+
+     orig-date   =  "Date"        ":"   date-time
+
+     resent-date =  "Resent-Date" ":"   date-time
+
+     destination =  "To"          ":" 1#address  ; Primary
+                 /  "Resent-To"   ":" 1#address
+                 /  "cc"          ":" 1#address  ; Secondary
+                 /  "Resent-cc"   ":" 1#address
+                 /  "bcc"         ":"  #address  ; Blind carbon
+                 /  "Resent-bcc"  ":"  #address
+
+     optional-field =
+                 /  "Message-ID"        ":"   msg-id
+                 /  "Resent-Message-ID" ":"   msg-id
+                 /  "In-Reply-To"       ":"  *(phrase / msg-id)
+                 /  "References"        ":"  *(phrase / msg-id)
+                 /  "Keywords"          ":"  #phrase
+                 /  "Subject"           ":"  *text
+                 /  "Comments"          ":"  *text
+                 /  "Encrypted"         ":" 1#2word
+                 /  extension-field              ; To be defined
+                 /  user-defined-field           ; May be pre-empted
+
+     msg-id      =  "<" addr-spec ">"            ; Unique message id
+
+
+
+
+
+
+     August 13, 1982              - 18 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     extension-field =
+                   <Any field which is defined in a document
+                    published as a formal extension to this
+                    specification; none will have names beginning
+                    with the string "X-">
+
+     user-defined-field =
+                   <Any field which has not been defined
+                    in this specification or published as an
+                    extension to this specification; names for
+                    such fields must be unique and may be
+                    pre-empted by published extensions>
+
+     4.2.  FORWARDING
+
+          Some systems permit mail recipients to  forward  a  message,
+     retaining  the original headers, by adding some new fields.  This
+     standard supports such a service, through the "Resent-" prefix to
+     field names.
+
+          Whenever the string "Resent-" begins a field name, the field
+     has  the  same  semantics as a field whose name does not have the
+     prefix.  However, the message is assumed to have  been  forwarded
+     by  an original recipient who attached the "Resent-" field.  This
+     new field is treated as being more recent  than  the  equivalent,
+     original  field.   For  example, the "Resent-From", indicates the
+     person that forwarded the message, whereas the "From" field indi-
+     cates the original author.
+
+          Use of such precedence  information  depends  upon  partici-
+     pants'  communication needs.  For example, this standard does not
+     dictate when a "Resent-From:" address should receive replies,  in
+     lieu of sending them to the "From:" address.
+
+     Note:  In general, the "Resent-" fields should be treated as con-
+            taining  a  set  of information that is independent of the
+            set of original fields.  Information for  one  set  should
+            not  automatically be taken from the other.  The interpre-
+            tation of multiple "Resent-" fields, of the same type,  is
+            undefined.
+
+          In the remainder of this specification, occurrence of  legal
+     "Resent-"  fields  are treated identically with the occurrence of
+
+
+
+
+
+
+
+
+     August 13, 1982              - 19 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     fields whose names do not contain this prefix.
+
+     4.3.  TRACE FIELDS
+
+          Trace information is used to provide an audit trail of  mes-
+     sage  handling.   In  addition,  it indicates a route back to the
+     sender of the message.
+
+          The list of known "via" and  "with"  values  are  registered
+     with  the  Network  Information  Center, SRI International, Menlo
+     Park, California.
+
+     4.3.1.  RETURN-PATH
+
+        This field  is  added  by  the  final  transport  system  that
+        delivers  the message to its recipient.  The field is intended
+        to contain definitive information about the address and  route
+        back to the message's originator.
+
+        Note:  The "Reply-To" field is added  by  the  originator  and
+               serves  to  direct  replies,  whereas the "Return-Path"
+               field is used to identify a path back to  the  origina-
+               tor.
+
+        While the syntax  indicates  that  a  route  specification  is
+        optional,  every attempt should be made to provide that infor-
+        mation in this field.
+
+     4.3.2.  RECEIVED
+
+        A copy of this field is added by each transport  service  that
+        relays the message.  The information in the field can be quite
+        useful for tracing transport problems.
+
+        The names of the sending  and  receiving  hosts  and  time-of-
+        receipt may be specified.  The "via" parameter may be used, to
+        indicate what physical mechanism the message  was  sent  over,
+        such  as  Arpanet or Phonenet, and the "with" parameter may be
+        used to indicate the mail-,  or  connection-,  level  protocol
+        that  was  used, such as the SMTP mail protocol, or X.25 tran-
+        sport protocol.
+
+        Note:  Several "with" parameters may  be  included,  to  fully
+               specify the set of protocols that were used.
+
+        Some transport services queue mail; the internal message iden-
+        tifier that is assigned to the message may be noted, using the
+        "id" parameter.  When the  sending  host  uses  a  destination
+        address specification that the receiving host reinterprets, by
+
+
+     August 13, 1982              - 20 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        expansion or transformation, the receiving host  may  wish  to
+        record  the original specification, using the "for" parameter.
+        For example, when a copy of mail is sent to the  member  of  a
+        distribution  list,  this  parameter may be used to record the
+        original address that was used to specify the list.
+
+     4.4.  ORIGINATOR FIELDS
+
+          The standard allows only a subset of the combinations possi-
+     ble  with the From, Sender, Reply-To, Resent-From, Resent-Sender,
+     and Resent-Reply-To fields.  The limitation is intentional.
+
+     4.4.1.  FROM / RESENT-FROM
+
+        This field contains the identity of the person(s)  who  wished
+        this  message to be sent.  The message-creation process should
+        default this field  to  be  a  single,  authenticated  machine
+        address,  indicating  the  AGENT  (person,  system or process)
+        entering the message.  If this is not done, the "Sender" field
+        MUST  be  present.  If the "From" field IS defaulted this way,
+        the "Sender" field is  optional  and  is  redundant  with  the
+        "From"  field.   In  all  cases, addresses in the "From" field
+        must be machine-usable (addr-specs) and may not contain  named
+        lists (groups).
+
+     4.4.2.  SENDER / RESENT-SENDER
+
+        This field contains the authenticated identity  of  the  AGENT
+        (person,  system  or  process)  that sends the message.  It is
+        intended for use when the sender is not the author of the mes-
+        sage,  or  to  indicate  who among a group of authors actually
+        sent the message.  If the contents of the "Sender" field would
+        be  completely  redundant  with  the  "From"  field,  then the
+        "Sender" field need not be present and its use is  discouraged
+        (though  still legal).  In particular, the "Sender" field MUST
+        be present if it is NOT the same as the "From" Field.
+
+        The Sender mailbox  specification  includes  a  word  sequence
+        which  must correspond to a specific agent (i.e., a human user
+        or a computer program) rather than a standard  address.   This
+        indicates  the  expectation  that  the field will identify the
+        single AGENT (person,  system,  or  process)  responsible  for
+        sending  the mail and not simply include the name of a mailbox
+        from which the mail was sent.  For example in the  case  of  a
+        shared login name, the name, by itself, would not be adequate.
+        The local-part address unit, which refers to  this  agent,  is
+        expected to be a computer system term, and not (for example) a
+        generalized person reference which can  be  used  outside  the
+        network text message context.
+
+
+     August 13, 1982              - 21 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        Since the critical function served by the  "Sender"  field  is
+        identification  of  the agent responsible for sending mail and
+        since computer programs cannot be held accountable  for  their
+        behavior, it is strongly recommended that when a computer pro-
+        gram generates a message, the HUMAN  who  is  responsible  for
+        that program be referenced as part of the "Sender" field mail-
+        box specification.
+
+     4.4.3.  REPLY-TO / RESENT-REPLY-TO
+
+        This field provides a general  mechanism  for  indicating  any
+        mailbox(es)  to which responses are to be sent.  Three typical
+        uses for this feature can  be  distinguished.   In  the  first
+        case,  the  author(s) may not have regular machine-based mail-
+        boxes and therefore wish(es) to indicate an alternate  machine
+        address.   In  the  second case, an author may wish additional
+        persons to be made aware of, or responsible for,  replies.   A
+        somewhat  different  use  may be of some help to "text message
+        teleconferencing" groups equipped with automatic  distribution
+        services:   include the address of that service in the "Reply-
+        To" field of all messages  submitted  to  the  teleconference;
+        then  participants  can  "reply"  to conference submissions to
+        guarantee the correct distribution of any submission of  their
+        own.
+
+        Note:  The "Return-Path" field is added by the mail  transport
+               service,  at the time of final deliver.  It is intended
+               to identify a path back to the orginator  of  the  mes-
+               sage.   The  "Reply-To"  field  is added by the message
+               originator and is intended to direct replies.
+
+     4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
+
+        For systems which automatically  generate  address  lists  for
+        replies to messages, the following recommendations are made:
+
+            o   The "Sender" field mailbox should be sent  notices  of
+                any  problems in transport or delivery of the original
+                messages.  If there is no  "Sender"  field,  then  the
+                "From" field mailbox should be used.
+
+            o   The  "Sender"  field  mailbox  should  NEVER  be  used
+                automatically, in a recipient's reply message.
+
+            o   If the "Reply-To" field exists, then the reply  should
+                go to the addresses indicated in that field and not to
+                the address(es) indicated in the "From" field.
+
+
+
+
+     August 13, 1982              - 22 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+            o   If there is a "From" field, but no  "Reply-To"  field,
+                the  reply should be sent to the address(es) indicated
+                in the "From" field.
+
+        Sometimes, a recipient may actually wish to  communicate  with
+        the  person  that  initiated  the  message  transfer.  In such
+        cases, it is reasonable to use the "Sender" address.
+
+        This recommendation is intended  only  for  automated  use  of
+        originator-fields  and is not intended to suggest that replies
+        may not also be sent to other recipients of messages.   It  is
+        up  to  the  respective  mail-handling programs to decide what
+        additional facilities will be provided.
+
+        Examples are provided in Appendix A.
+
+     4.5.  RECEIVER FIELDS
+
+     4.5.1.  TO / RESENT-TO
+
+        This field contains the identity of the primary recipients  of
+        the message.
+
+     4.5.2.  CC / RESENT-CC
+
+        This field contains the identity of  the  secondary  (informa-
+        tional) recipients of the message.
+
+     4.5.3.  BCC / RESENT-BCC
+
+        This field contains the identity of additional  recipients  of
+        the  message.   The contents of this field are not included in
+        copies of the message sent to the primary and secondary  reci-
+        pients.   Some  systems  may choose to include the text of the
+        "Bcc" field only in the author(s)'s  copy,  while  others  may
+        also include it in the text sent to all those indicated in the
+        "Bcc" list.
+
+     4.6.  REFERENCE FIELDS
+
+     4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID
+
+             This field contains a unique identifier  (the  local-part
+        address  unit)  which  refers to THIS version of THIS message.
+        The uniqueness of the message identifier is guaranteed by  the
+        host  which  generates  it.  This identifier is intended to be
+        machine readable and not necessarily meaningful to humans.   A
+        message  identifier pertains to exactly one instantiation of a
+        particular message; subsequent revisions to the message should
+
+
+     August 13, 1982              - 23 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        each receive new message identifiers.
+
+     4.6.2.  IN-REPLY-TO
+
+             The contents of this field identify  previous  correspon-
+        dence  which this message answers.  Note that if message iden-
+        tifiers are used in this  field,  they  must  use  the  msg-id
+        specification format.
+
+     4.6.3.  REFERENCES
+
+             The contents of this field identify other  correspondence
+        which  this message references.  Note that if message identif-
+        iers are used, they must use the msg-id specification format.
+
+     4.6.4.  KEYWORDS
+
+             This field contains keywords  or  phrases,  separated  by
+        commas.
+
+     4.7.  OTHER FIELDS
+
+     4.7.1.  SUBJECT
+
+             This is intended to provide a summary,  or  indicate  the
+        nature, of the message.
+
+     4.7.2.  COMMENTS
+
+             Permits adding text comments  onto  the  message  without
+        disturbing the contents of the message's body.
+
+     4.7.3.  ENCRYPTED
+
+             Sometimes,  data  encryption  is  used  to  increase  the
+        privacy  of  message  contents.   If the body of a message has
+        been encrypted, to keep its contents private, the  "Encrypted"
+        field  can be used to note the fact and to indicate the nature
+        of the encryption.  The first <word> parameter  indicates  the
+        software  used  to  encrypt the body, and the second, optional
+        <word> is intended to  aid  the  recipient  in  selecting  the
+        proper  decryption  key.   This  code word may be viewed as an
+        index to a table of keys held by the recipient.
+
+        Note:  Unfortunately, headers must contain envelope,  as  well
+               as  contents,  information.  Consequently, it is neces-
+               sary that they remain unencrypted, so that  mail  tran-
+               sport   services   may   access   them.   Since  names,
+               addresses, and "Subject"  field  contents  may  contain
+
+
+     August 13, 1982              - 24 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+               sensitive  information,  this  requirement limits total
+               message privacy.
+
+             Names of encryption software are registered with the Net-
+        work  Information Center, SRI International, Menlo Park, Cali-
+        fornia.
+
+     4.7.4.  EXTENSION-FIELD
+
+             A limited number of common fields have  been  defined  in
+        this  document.   As  network mail requirements dictate, addi-
+        tional fields may be standardized.   To  provide  user-defined
+        fields  with  a  measure  of  safety,  in name selection, such
+        extension-fields will never have names  that  begin  with  the
+        string "X-".
+
+             Names of Extension-fields are registered with the Network
+        Information Center, SRI International, Menlo Park, California.
+
+     4.7.5.  USER-DEFINED-FIELD
+
+             Individual users of network mail are free to  define  and
+        use  additional  header  fields.   Such fields must have names
+        which are not already used in the current specification or  in
+        any definitions of extension-fields, and the overall syntax of
+        these user-defined-fields must conform to this specification's
+        rules   for   delimiting  and  folding  fields.   Due  to  the
+        extension-field  publishing  process,  the  name  of  a  user-
+        defined-field may be pre-empted
+
+        Note:  The prefatory string "X-" will never  be  used  in  the
+               names  of Extension-fields.  This provides user-defined
+               fields with a protected set of names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 25 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     5.  DATE AND TIME SPECIFICATION
+
+     5.1.  SYNTAX
+
+     date-time   =  [ day "," ] date time        ; dd mm yy
+                                                 ;  hh:mm:ss zzz
+
+     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
+                 /  "Fri"  / "Sat" /  "Sun"
+
+     date        =  1*2DIGIT month 2DIGIT        ; day month year
+                                                 ;  e.g. 20 Jun 82
+
+     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
+                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
+                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
+
+     time        =  hour zone                    ; ANSI and Military
+
+     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
+                                                 ; 00:00:00 - 23:59:59
+
+     zone        =  "UT"  / "GMT"                ; Universal Time
+                                                 ; North American : UT
+                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
+                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
+                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
+                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
+                 /  1ALPHA                       ; Military: Z = UT;
+                                                 ;  A:-1; (J not used)
+                                                 ;  M:-12; N:+1; Y:+12
+                 / ( ("+" / "-") 4DIGIT )        ; Local differential
+                                                 ;  hours+min. (HHMM)
+
+     5.2.  SEMANTICS
+
+          If included, day-of-week must be the day implied by the date
+     specification.
+
+          Time zone may be indicated in several ways.  "UT" is Univer-
+     sal  Time  (formerly called "Greenwich Mean Time"); "GMT" is per-
+     mitted as a reference to Universal Time.  The  military  standard
+     uses  a  single  character for each zone.  "Z" is Universal Time.
+     "A" indicates one hour earlier, and "M" indicates 12  hours  ear-
+     lier;  "N"  is  one  hour  later, and "Y" is 12 hours later.  The
+     letter "J" is not used.  The other remaining two forms are  taken
+     from ANSI standard X3.51-1975.  One allows explicit indication of
+     the amount of offset from UT; the other uses  common  3-character
+     strings for indicating time zones in North America.
+
+
+     August 13, 1982              - 26 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     6.  ADDRESS SPECIFICATION
+
+     6.1.  SYNTAX
+
+     address     =  mailbox                      ; one addressee
+                 /  group                        ; named list
+
+     group       =  phrase ":" [#mailbox] ";"
+
+     mailbox     =  addr-spec                    ; simple address
+                 /  phrase route-addr            ; name & addr-spec
+
+     route-addr  =  "<" [route] addr-spec ">"
+
+     route       =  1#("@" domain) ":"           ; path-relative
+
+     addr-spec   =  local-part "@" domain        ; global address
+
+     local-part  =  word *("." word)             ; uninterpreted
+                                                 ; case-preserved
+
+     domain      =  sub-domain *("." sub-domain)
+
+     sub-domain  =  domain-ref / domain-literal
+
+     domain-ref  =  atom                         ; symbolic reference
+
+     6.2.  SEMANTICS
+
+          A mailbox receives mail.  It is a  conceptual  entity  which
+     does  not necessarily pertain to file storage.  For example, some
+     sites may choose to print mail on their line printer and  deliver
+     the output to the addressee's desk.
+
+          A mailbox specification comprises a person, system  or  pro-
+     cess name reference, a domain-dependent string, and a name-domain
+     reference.  The name reference is optional and is usually used to
+     indicate  the  human name of a recipient.  The name-domain refer-
+     ence specifies a sequence of sub-domains.   The  domain-dependent
+     string is uninterpreted, except by the final sub-domain; the rest
+     of the mail service merely transmits it as a literal string.
+
+     6.2.1.  DOMAINS
+
+        A name-domain is a set of registered (mail)  names.   A  name-
+        domain  specification  resolves  to  a subordinate name-domain
+        specification  or  to  a  terminal  domain-dependent   string.
+        Hence,  domain  specification  is  extensible,  permitting any
+        number of registration levels.
+
+
+     August 13, 1982              - 27 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        Name-domains model a global, logical, hierarchical  addressing
+        scheme.   The  model is logical, in that an address specifica-
+        tion is related to name registration and  is  not  necessarily
+        tied  to  transmission  path.   The  model's  hierarchy  is  a
+        directed graph, called an in-tree, such that there is a single
+        path  from  the root of the tree to any node in the hierarchy.
+        If more than one path actually exists, they are considered  to
+        be different addresses.
+
+        The root node is common to all addresses; consequently, it  is
+        not  referenced.   Its  children  constitute "top-level" name-
+        domains.  Usually, a service has access to its own full domain
+        specification and to the names of all top-level name-domains.
+
+        The "top" of the domain addressing hierarchy -- a child of the
+        root  --  is  indicated  by  the right-most field, in a domain
+        specification.  Its child is specified to the left, its  child
+        to the left, and so on.
+
+        Some groups provide formal registration services;  these  con-
+        stitute   name-domains   that  are  independent  logically  of
+        specific machines.  In addition, networks and machines  impli-
+        citly  compose name-domains, since their membership usually is
+        registered in name tables.
+
+        In the case of formal registration, an organization implements
+        a  (distributed)  data base which provides an address-to-route
+        mapping service for addresses of the form:
+
+                         person@registry.organization
+
+        Note that "organization" is a logical  entity,  separate  from
+        any particular communication network.
+
+        A mechanism for accessing "organization" is universally avail-
+        able.   That mechanism, in turn, seeks an instantiation of the
+        registry; its location is not indicated in the address specif-
+        ication.   It  is assumed that the system which operates under
+        the name "organization" knows how to find a subordinate regis-
+        try.  The registry will then use the "person" string to deter-
+        mine where to send the mail specification.
+
+        The latter,  network-oriented  case  permits  simple,  direct,
+        attachment-related address specification, such as:
+
+                              user@host.network
+
+        Once the network is accessed, it is expected  that  a  message
+        will  go  directly  to the host and that the host will resolve
+
+
+     August 13, 1982              - 28 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        the user name, placing the message in the user's mailbox.
+
+     6.2.2.  ABBREVIATED DOMAIN SPECIFICATION
+
+        Since any number of  levels  is  possible  within  the  domain
+        hierarchy,  specification  of  a  fully  qualified address can
+        become inconvenient.  This standard permits abbreviated domain
+        specification, in a special case:
+
+            For the address of  the  sender,  call  the  left-most
+            sub-domain  Level  N.   In a header address, if all of
+            the sub-domains above (i.e., to the right of) Level  N
+            are  the same as those of the sender, then they do not
+            have to appear in the specification.   Otherwise,  the
+            address must be fully qualified.
+
+            This feature is subject  to  approval  by  local  sub-
+            domains.   Individual  sub-domains  may  require their
+            member systems, which originate mail, to provide  full
+            domain  specification only.  When permitted, abbrevia-
+            tions may be present  only  while  the  message  stays
+            within the sub-domain of the sender.
+
+            Use of this mechanism requires the sender's sub-domain
+            to reserve the names of all top-level domains, so that
+            full specifications can be distinguished from abbrevi-
+            ated specifications.
+
+        For example, if a sender's address is:
+
+                 sender@registry-A.registry-1.organization-X
+
+        and one recipient's address is:
+
+                recipient@registry-B.registry-1.organization-X
+
+        and another's is:
+
+                recipient@registry-C.registry-2.organization-X
+
+        then ".registry-1.organization-X" need not be specified in the
+        the  message,  but  "registry-C.registry-2"  DOES  have  to be
+        specified.  That is, the first two addresses may  be  abbrevi-
+        ated, but the third address must be fully specified.
+
+        When a message crosses a domain boundary, all  addresses  must
+        be  specified  in  the  full format, ending with the top-level
+        name-domain in the right-most field.  It is the responsibility
+        of  mail  forwarding services to ensure that addresses conform
+
+
+     August 13, 1982              - 29 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        with this requirement.  In the case of abbreviated  addresses,
+        the  relaying  service must make the necessary expansions.  It
+        should be noted that it often is difficult for such a  service
+        to locate all occurrences of address abbreviations.  For exam-
+        ple, it will not be possible to find such abbreviations within
+        the  body  of  the  message.   The "Return-Path" field can aid
+        recipients in recovering from these errors.
+
+        Note:  When passing any portion of an addr-spec onto a process
+               which  does  not interpret data according to this stan-
+               dard (e.g., mail protocol servers).  There must  be  NO
+               LWSP-chars  preceding  or  following the at-sign or any
+               delimiting period ("."), such as  shown  in  the  above
+               examples,   and   only  ONE  SPACE  between  contiguous
+               <word>s.
+
+     6.2.3.  DOMAIN TERMS
+
+        A domain-ref must be THE official name of a registry, network,
+        or  host.   It  is  a  symbolic  reference, within a name sub-
+        domain.  At times, it is necessary to bypass standard  mechan-
+        isms  for  resolving  such  references,  using  more primitive
+        information, such as a network host address  rather  than  its
+        associated host name.
+
+        To permit such references, this standard provides the  domain-
+        literal  construct.   Its contents must conform with the needs
+        of the sub-domain in which it is interpreted.
+
+        Domain-literals which refer to domains within the ARPA  Inter-
+        net  specify  32-bit  Internet addresses, in four 8-bit fields
+        noted in decimal, as described in Request for  Comments  #820,
+        "Assigned Numbers."  For example:
+
+                                 [10.0.3.19]
+
+        Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
+               is  permitted  only  as  a means of bypassing temporary
+               system limitations, such as name tables which  are  not
+               complete.
+
+        The names of "top-level" domains, and  the  names  of  domains
+        under  in  the  ARPA Internet, are registered with the Network
+        Information Center, SRI International, Menlo Park, California.
+
+     6.2.4.  DOMAIN-DEPENDENT LOCAL STRING
+
+        The local-part of an  addr-spec  in  a  mailbox  specification
+        (i.e.,  the  host's  name for the mailbox) is understood to be
+
+
+     August 13, 1982              - 30 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        whatever the receiving mail protocol server allows.  For exam-
+        ple,  some systems do not understand mailbox references of the
+        form "P. D. Q. Bach", but others do.
+
+        This specification treats periods (".") as lexical separators.
+        Hence,  their  presence  in  local-parts which are not quoted-
+        strings, is detected.   However,  such  occurrences  carry  NO
+        semantics.  That is, if a local-part has periods within it, an
+        address parser will divide the local-part into several tokens,
+        but  the  sequence  of  tokens will be treated as one uninter-
+        preted unit.  The sequence  will  be  re-assembled,  when  the
+        address is passed outside of the system such as to a mail pro-
+        tocol service.
+
+        For example, the address:
+
+                           First.Last@Registry.Org
+
+        is legal and does not require the local-part to be  surrounded
+        with  quotation-marks.   (However,  "First  Last" DOES require
+        quoting.)  The local-part of the address, when passed  outside
+        of  the  mail  system,  within  the  Registry.Org  domain,  is
+        "First.Last", again without quotation marks.
+
+     6.2.5.  BALANCING LOCAL-PART AND DOMAIN
+
+        In some cases, the boundary between local-part and domain  can
+        be  flexible.  The local-part may be a simple string, which is
+        used for the final determination of the  recipient's  mailbox.
+        All  other  levels  of  reference  are, therefore, part of the
+        domain.
+
+        For some systems, in the case of abbreviated reference to  the
+        local  and  subordinate  sub-domains,  it  may  be possible to
+        specify only one reference within the domain  part  and  place
+        the  other,  subordinate  name-domain  references  within  the
+        local-part.  This would appear as:
+
+                        mailbox.sub1.sub2@this-domain
+
+        Such a specification would be acceptable  to  address  parsers
+        which  conform  to  RFC  #733,  but  do not support this newer
+        Internet standard.  While contrary to the intent of this stan-
+        dard, the form is legal.
+
+        Also, some sub-domains have a specification syntax which  does
+        not conform to this standard.  For example:
+
+                      sub-net.mailbox@sub-domain.domain
+
+
+     August 13, 1982              - 31 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        uses a different parsing  sequence  for  local-part  than  for
+        domain.
+
+        Note:  As a rule,  the  domain  specification  should  contain
+               fields  which  are  encoded  according to the syntax of
+               this standard and which contain  generally-standardized
+               information.   The local-part specification should con-
+               tain only that portion of the  address  which  deviates
+               from the form or intention of the domain field.
+
+     6.2.6.  MULTIPLE MAILBOXES
+
+        An individual may have several mailboxes and wish  to  receive
+        mail  at  whatever  mailbox  is  convenient  for the sender to
+        access.  This standard does not provide a means of  specifying
+        "any member of" a list of mailboxes.
+
+        A set of individuals may wish to receive mail as a single unit
+        (i.e.,  a  distribution  list).  The <group> construct permits
+        specification of such a list.  Recipient mailboxes are  speci-
+        fied  within  the  bracketed  part (":" - ";").  A copy of the
+        transmitted message is to be  sent  to  each  mailbox  listed.
+        This  standard  does  not  permit  recursive  specification of
+        groups within groups.
+
+        While a list must be named, it is not required that  the  con-
+        tents  of  the  list be included.  In this case, the <address>
+        serves only as an indication of group distribution  and  would
+        appear in the form:
+
+                                    name:;
+
+        Some mail  services  may  provide  a  group-list  distribution
+        facility,  accepting  a single mailbox reference, expanding it
+        to the full distribution list, and relaying the  mail  to  the
+        list's  members.   This standard provides no additional syntax
+        for indicating such a  service.   Using  the  <group>  address
+        alternative,  while listing one mailbox in it, can mean either
+        that the mailbox reference will be expanded to a list or  that
+        there is a group with one member.
+
+     6.2.7.  EXPLICIT PATH SPECIFICATION
+
+        At times, a  message  originator  may  wish  to  indicate  the
+        transmission  path  that  a  message  should  follow.  This is
+        called source routing.  The normal addressing scheme, used  in
+        an  addr-spec,  is  carefully separated from such information;
+        the <route> portion of a route-addr is provided for such occa-
+        sions.  It specifies the sequence of hosts and/or transmission
+
+
+     August 13, 1982              - 32 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        services that are  to  be  traversed.   Both  domain-refs  and
+        domain-literals may be used.
+
+        Note:  The use of source routing is discouraged.   Unless  the
+               sender has special need of path restriction, the choice
+               of transmission route should be left to the mail  tran-
+               sport service.
+
+     6.3.  RESERVED ADDRESS
+
+          It often is necessary to send mail to a site, without  know-
+     ing  any  of its valid addresses.  For example, there may be mail
+     system dysfunctions, or a user may wish to find  out  a  person's
+     correct address, at that site.
+
+          This standard specifies a single, reserved  mailbox  address
+     (local-part)  which  is  to  be valid at each site.  Mail sent to
+     that address is to be routed to  a  person  responsible  for  the
+     site's mail system or to a person with responsibility for general
+     site operation.  The name of the reserved local-part address is:
+
+                                Postmaster
+
+     so that "Postmaster@domain" is required to be valid.
+
+     Note:  This reserved local-part must be  matched  without  sensi-
+            tivity to alphabetic case, so that "POSTMASTER", "postmas-
+            ter", and even "poStmASteR" is to be accepted.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 33 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     7.  BIBLIOGRAPHY
+
+
+     ANSI.  "USA Standard Code  for  Information  Interchange,"  X3.4.
+        American  National Standards Institute: New York (1968).  Also
+        in:  Feinler, E.  and J. Postel, eds., "ARPANET Protocol Hand-
+        book", NIC 7104.
+
+     ANSI.  "Representations of Universal Time, Local  Time  Differen-
+        tials,  and United States Time Zone References for Information
+        Interchange," X3.51-1975.  American National Standards  Insti-
+        tute:  New York (1975).
+
+     Bemer, R.W., "Time and the Computer."  In:  Interface  Age  (Feb.
+        1979).
+
+     Bennett, C.J.  "JNT Mail Protocol".  Joint Network Team,  Ruther-
+        ford and Appleton Laboratory:  Didcot, England.
+
+     Bhushan, A.K., Pogran, K.T., Tomlinson,  R.S.,  and  White,  J.E.
+        "Standardizing  Network  Mail  Headers,"   ARPANET Request for
+        Comments No. 561, Network Information Center  No.  18516;  SRI
+        International:  Menlo Park (September 1973).
+
+     Birrell, A.D., Levin, R.,  Needham,  R.M.,  and  Schroeder,  M.D.
+        "Grapevine:  An Exercise in Distributed Computing," Communica-
+        tions of the ACM 25, 4 (April 1982), 260-274.
+
+     Crocker,  D.H.,  Vittal,  J.J.,  Pogran,  K.T.,  Henderson,  D.A.
+        "Standard  for  the  Format  of  ARPA  Network  Text Message,"
+        ARPANET Request for  Comments  No.  733,  Network  Information
+        Center  No.  41952.   SRI International:  Menlo Park (November
+        1977).
+
+     Feinler, E.J. and Postel, J.B.  ARPANET Protocol  Handbook,  Net-
+        work  Information  Center  No.  7104   (NTIS AD A003890).  SRI
+        International:  Menlo Park (April 1976).
+
+     Harary, F.   "Graph  Theory".   Addison-Wesley:   Reading,  Mass.
+        (1969).
+
+     Levin, R. and Schroeder, M.  "Transport  of  Electronic  Messages
+        through  a  Network,"   TeleInformatics  79, pp. 29-33.  North
+        Holland (1979).  Also  as  Xerox  Palo  Alto  Research  Center
+        Technical Report CSL-79-4.
+
+     Myer, T.H. and Henderson, D.A.  "Message Transmission  Protocol,"
+        ARPANET  Request  for  Comments,  No. 680, Network Information
+        Center No. 32116.  SRI International:  Menlo Park (1975).
+
+
+     August 13, 1982              - 34 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     NBS.  "Specification of Message Format for Computer Based Message
+        Systems, Recommended Federal Information Processing Standard."
+        National  Bureau   of   Standards:    Gaithersburg,   Maryland
+        (October 1981).
+
+     NIC.  Internet Protocol Transition Workbook.  Network Information
+        Center,   SRI-International,  Menlo  Park,  California  (March
+        1982).
+
+     Oppen, D.C. and Dalal, Y.K.  "The Clearinghouse:  A Decentralized
+        Agent  for  Locating  Named  Objects in a Distributed Environ-
+        ment," OPD-T8103.  Xerox Office Products Division:  Palo Alto,
+        CA. (October 1981).
+
+     Postel, J.B.  "Assigned Numbers,"  ARPANET Request for  Comments,
+        No. 820.  SRI International:  Menlo Park (August 1982).
+
+     Postel, J.B.  "Simple Mail Transfer  Protocol,"  ARPANET  Request
+        for Comments, No. 821.  SRI International:  Menlo Park (August
+        1982).
+
+     Shoch, J.F.  "Internetwork naming, addressing  and  routing,"  in
+        Proc. 17th IEEE Computer Society International Conference, pp.
+        72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C.
+
+     Su, Z. and Postel, J.  "The Domain Naming Convention for Internet
+        User  Applications,"  ARPANET  Request  for Comments, No. 819.
+        SRI International:  Menlo Park (August 1982).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 35 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+                                 APPENDIX
+
+
+     A.  EXAMPLES
+
+     A.1.  ADDRESSES
+
+     A.1.1.  Alfred Neuman <Neuman@BBN-TENEXA>
+
+     A.1.2.  Neuman@BBN-TENEXA
+
+             These two "Alfred Neuman" examples have identical  seman-
+        tics, as far as the operation of the local host's mail sending
+        (distribution) program (also sometimes  called  its  "mailer")
+        and  the remote host's mail protocol server are concerned.  In
+        the first example, the  "Alfred  Neuman"  is  ignored  by  the
+        mailer,  as "Neuman@BBN-TENEXA" completely specifies the reci-
+        pient.  The second example contains  no  superfluous  informa-
+        tion,  and,  again,  "Neuman@BBN-TENEXA" is the intended reci-
+        pient.
+
+        Note:  When the message crosses name-domain  boundaries,  then
+               these specifications must be changed, so as to indicate
+               the remainder of the hierarchy, starting with  the  top
+               level.
+
+     A.1.3.  "George, Ted" <Shared@Group.Arpanet>
+
+             This form might be used to indicate that a single mailbox
+        is  shared  by several users.  The quoted string is ignored by
+        the originating host's mailer, because  "Shared@Group.Arpanet"
+        completely specifies the destination mailbox.
+
+     A.1.4.  Wilt . (the  Stilt) Chamberlain@NBA.US
+
+             The "(the  Stilt)" is a comment, which is NOT included in
+        the  destination  mailbox  address  handed  to the originating
+        system's mailer.  The local-part of the address is the  string
+        "Wilt.Chamberlain", with NO space between the first and second
+        words.
+
+     A.1.5.  Address Lists
+
+     Gourmets:  Pompous Person <WhoZiWhatZit@Cordon-Bleu>,
+                Childs@WGBH.Boston, Galloping Gourmet@
+                ANT.Down-Under (Australian National Television),
+                Cheapie@Discount-Liquors;,
+       Cruisers:  Port@Portugal, Jones@SEA;,
+         Another@Somewhere.SomeOrg
+
+
+     August 13, 1982              - 36 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        This group list example points out the use of comments and the
+        mixing of addresses and groups.
+
+     A.2.  ORIGINATOR ITEMS
+
+     A.2.1.  Author-sent
+
+             George Jones logs into his host  as  "Jones".   He  sends
+        mail himself.
+
+            From:  Jones@Group.Org
+
+        or
+
+            From:  George Jones <Jones@Group.Org>
+
+     A.2.2.  Secretary-sent
+
+             George Jones logs in as Jones on his  host.   His  secre-
+        tary,  who logs in as Secy sends mail for him.  Replies to the
+        mail should go to George.
+
+            From:    George Jones <Jones@Group>
+            Sender:  Secy@Other-Group
+
+     A.2.3.  Secretary-sent, for user of shared directory
+
+             George Jones' secretary sends mail  for  George.  Replies
+        should go to George.
+
+            From:     George Jones<Shared@Group.Org>
+            Sender:   Secy@Other-Group
+
+        Note that there need not be a space between  "Jones"  and  the
+        "<",  but  adding a space enhances readability (as is the case
+        in other examples.
+
+     A.2.4.  Committee activity, with one author
+
+             George is a member of a committee.  He wishes to have any
+        replies to his message go to all committee members.
+
+            From:     George Jones <Jones@Host.Net>
+            Sender:   Jones@Host
+            Reply-To: The Committee: Jones@Host.Net,
+                                     Smith@Other.Org,
+                                     Doe@Somewhere-Else;
+
+        Note  that  if  George  had  not  included  himself   in   the
+
+
+     August 13, 1982              - 37 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+        enumeration  of  The  Committee,  he  would not have gotten an
+        implicit reply; the presence of the  "Reply-to"  field  SUPER-
+        SEDES the sending of a reply to the person named in the "From"
+        field.
+
+     A.2.5.  Secretary acting as full agent of author
+
+             George Jones asks his secretary  (Secy@Host)  to  send  a
+        message for him in his capacity as Group.  He wants his secre-
+        tary to handle all replies.
+
+            From:     George Jones <Group@Host>
+            Sender:   Secy@Host
+            Reply-To: Secy@Host
+
+     A.2.6.  Agent for user without online mailbox
+
+             A friend  of  George's,  Sarah,  is  visiting.   George's
+        secretary  sends  some  mail to a friend of Sarah in computer-
+        land.  Replies should go to George, whose mailbox is Jones  at
+        Registry.
+
+            From:     Sarah Friendly <Secy@Registry>
+            Sender:   Secy-Name <Secy@Registry>
+            Reply-To: Jones@Registry.
+
+     A.2.7.  Agent for member of a committee
+
+             George's secretary sends out a message which was authored
+        jointly by all the members of a committee.  Note that the name
+        of the committee cannot be specified, since <group> names  are
+        not permitted in the From field.
+
+            From:   Jones@Host,
+                    Smith@Other-Host,
+                    Doe@Somewhere-Else
+            Sender: Secy@SHost
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 38 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     A.3.  COMPLETE HEADERS
+
+     A.3.1.  Minimum required
+
+     Date:     26 Aug 76 1429 EDT        Date:     26 Aug 76 1429 EDT
+     From:     Jones@Registry.Org   or   From:     Jones@Registry.Org
+     Bcc:                                To:       Smith@Registry.Org
+
+        Note that the "Bcc" field may be empty, while the  "To"  field
+        is required to have at least one address.
+
+     A.3.2.  Using some of the additional fields
+
+     Date:     26 Aug 76 1430 EDT
+     From:     George Jones<Group@Host>
+     Sender:   Secy@SHOST
+     To:       "Al Neuman"@Mad-Host,
+               Sam.Irving@Other-Host
+     Message-ID:  <some.string@SHOST>
+
+     A.3.3.  About as complex as you're going to get
+
+     Date     :  27 Aug 76 0932 PDT
+     From     :  Ken Davis <KDavis@This-Host.This-net>
+     Subject  :  Re: The Syntax in the RFC
+     Sender   :  KSecy@Other-Host
+     Reply-To :  Sam.Irving@Reg.Organization
+     To       :  George Jones <Group@Some-Reg.An-Org>,
+                 Al.Neuman@MAD.Publisher
+     cc       :  Important folk:
+                   Tom Softwood <Balsa@Tree.Root>,
+                   "Sam Irving"@Other-Host;,
+                 Standard Distribution:
+                   /main/davis/people/standard@Other-Host,
+                   "<Jones>standard.dist.3"@Tops-20-Host>;
+     Comment  :  Sam is away on business. He asked me to handle
+                 his mail for him.  He'll be able to provide  a
+                 more  accurate  explanation  when  he  returns
+                 next week.
+     In-Reply-To: <some.string@DBM.Group>, George's message
+     X-Special-action:  This is a sample of user-defined field-
+                 names.  There could also be a field-name
+                 "Special-action", but its name might later be
+                 preempted
+     Message-ID: <4231.629.XYzi-What@Other-Host>
+
+
+
+
+
+
+     August 13, 1982              - 39 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     B.  SIMPLE FIELD PARSING
+
+          Some mail-reading software systems may wish to perform  only
+     minimal  processing,  ignoring  the internal syntax of structured
+     field-bodies and treating them the  same  as  unstructured-field-
+     bodies.  Such software will need only to distinguish:
+
+         o   Header fields from the message body,
+
+         o   Beginnings of fields from lines which continue fields,
+
+         o   Field-names from field-contents.
+
+          The abbreviated set of syntactic rules  which  follows  will
+     suffice  for  this  purpose.  It describes a limited view of mes-
+     sages and is a subset of the syntactic rules provided in the main
+     part of this specification.  One small exception is that the con-
+     tents of field-bodies consist only of text:
+
+     B.1.  SYNTAX
+
+
+     message         =   *field *(CRLF *text)
+
+     field           =    field-name ":" [field-body] CRLF
+
+     field-name      =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+
+     field-body      =   *text [CRLF LWSP-char field-body]
+
+
+     B.2.  SEMANTICS
+
+          Headers occur before the message body and are terminated  by
+     a null line (i.e., two contiguous CRLFs).
+
+          A line which continues a header field begins with a SPACE or
+     HTAB  character,  while  a  line  beginning a field starts with a
+     printable character which is not a colon.
+
+          A field-name consists of one or  more  printable  characters
+     (excluding  colon,  space, and control-characters).  A field-name
+     MUST be contained on one line.  Upper and lower case are not dis-
+     tinguished when comparing field-names.
+
+
+
+
+
+
+
+     August 13, 1982              - 40 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     C.  DIFFERENCES FROM RFC #733
+
+          The following summarizes the differences between this  stan-
+     dard  and the one specified in Arpanet Request for Comments #733,
+     "Standard for the Format of ARPA  Network  Text  Messages".   The
+     differences  are  listed  in the order of their occurrence in the
+     current specification.
+
+     C.1.  FIELD DEFINITIONS
+
+     C.1.1.  FIELD NAMES
+
+        These now must be a sequence of  printable  characters.   They
+        may not contain any LWSP-chars.
+
+     C.2.  LEXICAL TOKENS
+
+     C.2.1.  SPECIALS
+
+        The characters period ("."), left-square  bracket  ("["),  and
+        right-square  bracket ("]") have been added.  For presentation
+        purposes, and when passing a specification to  a  system  that
+        does  not conform to this standard, periods are to be contigu-
+        ous with their surrounding lexical tokens.   No  linear-white-
+        space  is  permitted  between them.  The presence of one LWSP-
+        char between other tokens is still directed.
+
+     C.2.2.  ATOM
+
+        Atoms may not contain SPACE.
+
+     C.2.3.  SPECIAL TEXT
+
+        ctext and qtext have had backslash ("\") added to the list  of
+        prohibited characters.
+
+     C.2.4.  DOMAINS
+
+        The lexical tokens  <domain-literal>  and  <dtext>  have  been
+        added.
+
+     C.3.  MESSAGE SPECIFICATION
+
+     C.3.1.  TRACE
+
+        The "Return-path:" and "Received:" fields have been specified.
+
+
+
+
+
+     August 13, 1982              - 41 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     C.3.2.  FROM
+
+        The "From" field must contain machine-usable addresses  (addr-
+        spec).   Multiple  addresses may be specified, but named-lists
+        (groups) may not.
+
+     C.3.3.  RESENT
+
+        The meta-construct of prefacing field names  with  the  string
+        "Resent-"  has been added, to indicate that a message has been
+        forwarded by an intermediate recipient.
+
+     C.3.4.  DESTINATION
+
+        A message must contain at least one destination address field.
+        "To" and "CC" are required to contain at least one address.
+
+     C.3.5.  IN-REPLY-TO
+
+        The field-body is no longer a comma-separated list, although a
+        sequence is still permitted.
+
+     C.3.6.  REFERENCE
+
+        The field-body is no longer a comma-separated list, although a
+        sequence is still permitted.
+
+     C.3.7.  ENCRYPTED
+
+        A field has been specified that permits  senders  to  indicate
+        that the body of a message has been encrypted.
+
+     C.3.8.  EXTENSION-FIELD
+
+        Extension fields are prohibited from beginning with the  char-
+        acters "X-".
+
+     C.4.  DATE AND TIME SPECIFICATION
+
+     C.4.1.  SIMPLIFICATION
+
+        Fewer optional forms are permitted  and  the  list  of  three-
+        letter time zones has been shortened.
+
+     C.5.  ADDRESS SPECIFICATION
+
+
+
+
+
+
+     August 13, 1982              - 42 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     C.5.1.  ADDRESS
+
+        The use of quoted-string, and the ":"-atom-":" construct, have
+        been  removed.   An  address  now  is  either a single mailbox
+        reference or is a named list of addresses.  The  latter  indi-
+        cates a group distribution.
+
+     C.5.2.  GROUPS
+
+        Group lists are now required to to have a name.   Group  lists
+        may not be nested.
+
+     C.5.3.  MAILBOX
+
+        A mailbox specification  may  indicate  a  person's  name,  as
+        before.   Such  a  named  list  no longer may specify multiple
+        mailboxes and may not be nested.
+
+     C.5.4.  ROUTE ADDRESSING
+
+        Addresses now are taken to be absolute, global specifications,
+        independent  of transmission paths.  The <route> construct has
+        been provided, to permit explicit specification  of  transmis-
+        sion  path.   RFC  #733's  use  of multiple at-signs ("@") was
+        intended as a general syntax  for  indicating  routing  and/or
+        hierarchical addressing.  The current standard separates these
+        specifications and only one at-sign is permitted.
+
+     C.5.5.  AT-SIGN
+
+        The string " at " no longer is used as an  address  delimiter.
+        Only at-sign ("@") serves the function.
+
+     C.5.6.  DOMAINS
+
+        Hierarchical, logical name-domains have been added.
+
+     C.6.  RESERVED ADDRESS
+
+     The local-part "Postmaster" has been reserved, so that users  can
+     be guaranteed at least one valid address at a site.
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 43 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     D.  ALPHABETICAL LISTING OF SYNTAX RULES
+
+     address     =  mailbox                      ; one addressee
+                 /  group                        ; named list
+     addr-spec   =  local-part "@" domain        ; global address
+     ALPHA       =  <any ASCII alphabetic character>
+                                                 ; (101-132, 65.- 90.)
+                                                 ; (141-172, 97.-122.)
+     atom        =  1*<any CHAR except specials, SPACE and CTLs>
+     authentic   =   "From"       ":"   mailbox  ; Single author
+                 / ( "Sender"     ":"   mailbox  ; Actual submittor
+                     "From"       ":" 1#mailbox) ; Multiple authors
+                                                 ;  or not sender
+     CHAR        =  <any ASCII character>        ; (  0-177,  0.-127.)
+     comment     =  "(" *(ctext / quoted-pair / comment) ")"
+     CR          =  <ASCII CR, carriage return>  ; (     15,      13.)
+     CRLF        =  CR LF
+     ctext       =  <any CHAR excluding "(",     ; => may be folded
+                     ")", "\" & CR, & including
+                     linear-white-space>
+     CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
+                     character and DEL>          ; (    177,     127.)
+     date        =  1*2DIGIT month 2DIGIT        ; day month year
+                                                 ;  e.g. 20 Jun 82
+     dates       =   orig-date                   ; Original
+                   [ resent-date ]               ; Forwarded
+     date-time   =  [ day "," ] date time        ; dd mm yy
+                                                 ;  hh:mm:ss zzz
+     day         =  "Mon"  / "Tue" /  "Wed"  / "Thu"
+                 /  "Fri"  / "Sat" /  "Sun"
+     delimiters  =  specials / linear-white-space / comment
+     destination =  "To"          ":" 1#address  ; Primary
+                 /  "Resent-To"   ":" 1#address
+                 /  "cc"          ":" 1#address  ; Secondary
+                 /  "Resent-cc"   ":" 1#address
+                 /  "bcc"         ":"  #address  ; Blind carbon
+                 /  "Resent-bcc"  ":"  #address
+     DIGIT       =  <any ASCII decimal digit>    ; ( 60- 71, 48.- 57.)
+     domain      =  sub-domain *("." sub-domain)
+     domain-literal =  "[" *(dtext / quoted-pair) "]"
+     domain-ref  =  atom                         ; symbolic reference
+     dtext       =  <any CHAR excluding "[",     ; => may be folded
+                     "]", "\" & CR, & including
+                     linear-white-space>
+     extension-field =
+                   <Any field which is defined in a document
+                    published as a formal extension to this
+                    specification; none will have names beginning
+                    with the string "X-">
+
+
+     August 13, 1982              - 44 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     field       =  field-name ":" [ field-body ] CRLF
+     fields      =    dates                      ; Creation time,
+                      source                     ;  author id & one
+                    1*destination                ;  address required
+                     *optional-field             ;  others optional
+     field-body  =  field-body-contents
+                    [CRLF LWSP-char field-body]
+     field-body-contents =
+                   <the ASCII characters making up the field-body, as
+                    defined in the following sections, and consisting
+                    of combinations of atom, quoted-string, and
+                    specials tokens, or else consisting of texts>
+     field-name  =  1*<any CHAR, excluding CTLs, SPACE, and ":">
+     group       =  phrase ":" [#mailbox] ";"
+     hour        =  2DIGIT ":" 2DIGIT [":" 2DIGIT]
+                                                 ; 00:00:00 - 23:59:59
+     HTAB        =  <ASCII HT, horizontal-tab>   ; (     11,       9.)
+     LF          =  <ASCII LF, linefeed>         ; (     12,      10.)
+     linear-white-space =  1*([CRLF] LWSP-char)  ; semantics = SPACE
+                                                 ; CRLF => folding
+     local-part  =  word *("." word)             ; uninterpreted
+                                                 ; case-preserved
+     LWSP-char   =  SPACE / HTAB                 ; semantics = SPACE
+     mailbox     =  addr-spec                    ; simple address
+                 /  phrase route-addr            ; name & addr-spec
+     message     =  fields *( CRLF *text )       ; Everything after
+                                                 ;  first null line
+                                                 ;  is message body
+     month       =  "Jan"  /  "Feb" /  "Mar"  /  "Apr"
+                 /  "May"  /  "Jun" /  "Jul"  /  "Aug"
+                 /  "Sep"  /  "Oct" /  "Nov"  /  "Dec"
+     msg-id      =  "<" addr-spec ">"            ; Unique message id
+     optional-field =
+                 /  "Message-ID"        ":"   msg-id
+                 /  "Resent-Message-ID" ":"   msg-id
+                 /  "In-Reply-To"       ":"  *(phrase / msg-id)
+                 /  "References"        ":"  *(phrase / msg-id)
+                 /  "Keywords"          ":"  #phrase
+                 /  "Subject"           ":"  *text
+                 /  "Comments"          ":"  *text
+                 /  "Encrypted"         ":" 1#2word
+                 /  extension-field              ; To be defined
+                 /  user-defined-field           ; May be pre-empted
+     orig-date   =  "Date"        ":"   date-time
+     originator  =   authentic                   ; authenticated addr
+                   [ "Reply-To"   ":" 1#address] )
+     phrase      =  1*word                       ; Sequence of words
+
+
+
+
+     August 13, 1982              - 45 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     qtext       =  <any CHAR excepting <">,     ; => may be folded
+                     "\" & CR, and including
+                     linear-white-space>
+     quoted-pair =  "\" CHAR                     ; may quote any char
+     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
+                                                 ;   quoted chars.
+     received    =  "Received"    ":"            ; one per relay
+                       ["from" domain]           ; sending host
+                       ["by"   domain]           ; receiving host
+                       ["via"  atom]             ; physical path
+                      *("with" atom)             ; link/mail protocol
+                       ["id"   msg-id]           ; receiver msg id
+                       ["for"  addr-spec]        ; initial form
+                        ";"    date-time         ; time received
+
+     resent      =   resent-authentic
+                   [ "Resent-Reply-To"  ":" 1#address] )
+     resent-authentic =
+                 =   "Resent-From"      ":"   mailbox
+                 / ( "Resent-Sender"    ":"   mailbox
+                     "Resent-From"      ":" 1#mailbox  )
+     resent-date =  "Resent-Date" ":"   date-time
+     return      =  "Return-path" ":" route-addr ; return address
+     route       =  1#("@" domain) ":"           ; path-relative
+     route-addr  =  "<" [route] addr-spec ">"
+     source      = [  trace ]                    ; net traversals
+                      originator                 ; original mail
+                   [  resent ]                   ; forwarded
+     SPACE       =  <ASCII SP, space>            ; (     40,      32.)
+     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
+                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
+                 /  "." / "[" / "]"              ;  within a word.
+     sub-domain  =  domain-ref / domain-literal
+     text        =  <any CHAR, including bare    ; => atoms, specials,
+                     CR & bare LF, but NOT       ;  comments and
+                     including CRLF>             ;  quoted-strings are
+                                                 ;  NOT recognized.
+     time        =  hour zone                    ; ANSI and Military
+     trace       =    return                     ; path to sender
+                    1*received                   ; receipt tags
+     user-defined-field =
+                   <Any field which has not been defined
+                    in this specification or published as an
+                    extension to this specification; names for
+                    such fields must be unique and may be
+                    pre-empted by published extensions>
+     word        =  atom / quoted-string
+
+
+
+
+     August 13, 1982              - 46 -                      RFC #822
+
+
+ 
+     Standard for ARPA Internet Text Messages
+
+
+     zone        =  "UT"  / "GMT"                ; Universal Time
+                                                 ; North American : UT
+                 /  "EST" / "EDT"                ;  Eastern:  - 5/ - 4
+                 /  "CST" / "CDT"                ;  Central:  - 6/ - 5
+                 /  "MST" / "MDT"                ;  Mountain: - 7/ - 6
+                 /  "PST" / "PDT"                ;  Pacific:  - 8/ - 7
+                 /  1ALPHA                       ; Military: Z = UT;
+     <">         =  <ASCII quote mark>           ; (     42,      34.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+     August 13, 1982              - 47 -                      RFC #822
+
diff --git a/RFC/rfc937.txt b/RFC/rfc937.txt
new file mode 100644
index 00000000..ae154ea8
--- /dev/null
+++ b/RFC/rfc937.txt
@@ -0,0 +1,1392 @@
+
+
+Network Working Group                                          M. Butler
+Request for Comments: 937                                      J. Postel
+                                                                D. Chase
+                                                           J. Goldberger
+                                                          J. K. Reynolds
+Obsoletes: RFC 918                                                   ISI
+                                                           February 1985
+
+
+                    POST OFFICE PROTOCOL - VERSION 2
+
+
+Status of this Memo
+
+   This RFC suggests a simple method for workstations to dynamically
+   access mail from a mailbox server.  This RFC specifies a proposed
+   protocol for the ARPA-Internet community, and requests discussion and
+   suggestions for improvement.  This memo is a revision of RFC 918.
+   Distribution of this memo is unlimited.
+
+Introduction
+
+   The intent of the Post Office Protocol Version 2 (POP2) is to allow a
+   user's workstation to access mail from a mailbox server.  It is
+   expected that mail will be posted from the workstation to the mailbox
+   server via the Simple Mail Transfer Protocol (SMTP).  For further
+   information see RFC-821 [1] and RFC-822 [2].
+
+   This protocol assumes a reliable data stream such as provided by TCP
+   or any similar protocol.  When TCP is used, the POP2 server listens
+   on port 109 [4].
+
+System Model and Philosophy
+
+   While we view the workstation as an Internet host in the sense that
+   it implements IP, we do not expect the workstation to contain the
+   user's mailbox.  We expect the mailbox to be on a server machine.
+
+   We believe it is important for the mailbox to be on an "always up"
+   machine and that a workstation may be frequently powered down, or
+   otherwise unavailable as an SMTP server.
+
+   POP2 is designed for an environment of workstations and servers on a
+   low-delay, high-throughput, local networks (such as Ethernets).  POP2
+   may be useful in other environments as well, but if the environment
+   is substantially different, a different division of labor between the
+   client and server may be appropriate, and a different protocol
+   required.
+
+   Suppose the user's real name is John Smith, the user's machine is
+   called FIDO, and that the mailbox server is called DOG-HOUSE.  Then
+
+
+
+Butler, et. al.                                                 [Page 1]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   we expect the user's mail to be addressed to JSmith@DOG-HOUSE.ARPA
+   (not JSmith@FIDO.ARPA).
+
+   That is, the destination of the mail is the mailbox on the server
+   machine.  The POP2 protocol and the workstation are merely a
+   mechanism for viewing the messages in the mailbox.
+
+   The user is not tied to any particular workstation for accessing his
+   mail.  The workstation does not appear as any part of the mailbox
+   address.
+
+   This is a very simple protocol.  This is not a user interface.  We
+   expect that there is a program in the workstation that is friendly to
+   the user.  This protocol is not "user friendly".  One basic rule of
+   this protocol is "if anything goes wrong close the connection".
+   Another basic rule is to have few options.
+
+   POP2 does not parse messages in any way.  It does not analyze message
+   headers (Date:, From:, To:, Cc:, or Subject:).  POP2 simply transmits
+   whole messages from a mailbox server to a client workstation.
+
+The Protocol
+
+   The POP2 protocol is a sequence of commands and replies.  The design
+   draws from many previous protocols of the ARPA-Internet community.
+
+      The server must be listening for a connection.  When a connection
+      is opened the server sends a greeting message and waits for
+      commands.  When commands are received the server acts on them and
+      responds with replies.
+
+      The client opens a connection, waits for the greeting, then sends
+      the HELO command with the user name and password arguments to
+      establish authorization to access mailboxes.  The server returns
+      the number of messages in the default mailbox.
+
+      The client may read the default mailbox associated with the user
+      name or may select another mailbox by using the FOLD command.  The
+      server returns the number of messages in the mailbox selected.
+
+      The client begins a message reading transaction with a READ
+      command.  The read command may optionally indicate which message
+      number to read, the default is the current message (incremented
+      when a message is read and set to one when a new folder is
+      selected).  The server returns the number of characters in the
+      message.
+
+
+
+
+Butler, et. al.                                                 [Page 2]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+      The client asks for the content of the message to be sent with the
+      RETR command.  The server sends the message data.
+
+      When all the data has been received the client sends an
+      acknowledgment command.  This is one of ACKS, ACKD, and NACK.
+
+         ACKS means "I've received the message successfully and please
+         keep it in the mailbox".
+
+         ACKD means "I've received the message successfully and please
+         delete it from the mailbox".
+
+         NACK means "I did not receive the message and please keep it in
+         the mailbox".
+
+      In the case of ACKS or ACKD the server increments the current
+      message indicator.  In the case of NACK the current message
+      indicator stays the same.
+
+      In all cases the server returns the number of characters in the
+      (now) current message.
+
+      The client terminates the session with the QUIT command.  The
+      server returns an ok.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                 [Page 3]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   The Normal Scenario
+
+           Client                    Server
+           ------                    ------
+                                Wait for Connection
+      Open Connection  -->
+                           <--  + POP2 Server Ready
+                                Wait for Command
+      HELO Fred Secret -->
+                           <--  #13 messages for you
+                                Wait for Command
+      READ 13          -->   
+                           <--  =537 characters in that message
+                                Wait for Command
+      RETR             -->   
+                           <--  (send the message data)
+                                Wait for Command
+      ACKS             -->   
+                           <--  =0 no more messages
+                                Wait for Command
+      QUIT             -->
+                           <--  + OK
+      Close connection --> <--  Close connection
+                                Wait for Connection (go back to start)
+
+Conventions
+
+   Arguments
+
+      These arguments have system specific definitions.
+
+         user - A login account name.
+
+         password - The password for the login account.
+
+         mailbox - A mailbox name (also called a mail folder).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                 [Page 4]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Default Mailboxes
+
+      TOPS-20
+
+         MAIL.TXT.1 - from login directory
+
+      UNIX
+
+         both
+            /usr/spool/mail/user
+         and
+            /usr/user/Mail/inbox/*
+
+            where "user" is the user value supplied in the HELO command.
+
+   End of Line
+
+      End of Line is Carriage Return (CR) followed by Line Feed (LF).
+      This sequence is indicated by "CRLF" in this document.  This end
+      of line convention must be used for commands and replies.
+
+   Message Length
+
+      The reply to the READ command or an acknowledgment command (ACKS,
+      ACKD, NACK) is the length (a character count) of the next message
+      to be transmitted.  This includes all the characters in the data
+      transmitted.  CRLF counts as two characters.  A length of zero
+      means the message does not exist or is empty.  A request to
+      transmit a message of zero length will result in the server
+      closing the connection.  The message is transmitted in the
+      standard internet format described in RFC-822 [2] and NVT-ASCII.
+      This may be different from the storage format and may make
+      computing the message length from the stored message non-trivial.
+
+   Message Numbers
+
+      The reply to the HELO and FOLD commands is a count of the number
+      of messages in a the selected mailbox.  The READ command has a
+      message number as an optional argument.  These numbers are
+      decimal, start at one, and computed with respect to the current
+      mailbox.  That is, the first message in a mailbox is message
+      number 1.
+
+   Numbers
+
+      All numbers in this memo and protocol are decimal.
+
+
+
+
+Butler, et. al.                                                 [Page 5]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Quoting
+
+      In a few cases, there may be a need to have a special character in
+      an argument (user, password, or mailbox) that is not allowed by
+      the syntax.  For example, a space in a password. To allow for
+      this, a quoting convention is defined.  Unfortunately, such
+      quoting conventions "use up" another otherwise uninteresting
+      character.  In this protocol the back slash "\" is used as the
+      quote character.  To include a space in an argument the two
+      character sequence "back-slash, space" is transmitted.  To include
+      a back-slash in an argument the two character sequence
+      "back-slash, back-slash" is transmitted.  This quoting convention
+      is used in the command arguments only, it is not used in the mail
+      data transmitted in response to a RETR command.
+
+   Reply Strings
+
+      The first character is required to be as specified (i.e.,
+      "+", "-", "=", "#").  The optional strings that follow can be
+      whatever the implementer thinks is appropriate.
+
+Definitions of Commands and Replies
+
+   Summary of Commands and Replies
+
+      Commands                          Replies
+      --------                          -------
+      HELO user password                + OK
+      FOLD mailbox                      - Error
+      READ [n]                          #xxx
+      RETR                              =yyy
+      ACKS
+      ACKD
+      NACK
+      QUIT
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                 [Page 6]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Commands
+
+      HELO user password
+
+         The Hello command identifies the user to the server and carries
+         the password authenticating this user.  This information is
+         used by the server to control access to the mailboxes.  The
+         Hello command is the "HELO" keyword, followed by the user
+         argument, followed by the password argument, followed by CRLF.
+
+            Possible responses:
+
+               "#nnn"
+
+                  where nnn is the number of messages in the default
+                  mailbox,"
+
+               "- error report" and Close the connection.
+
+      FOLD mailbox
+
+         The Folder command selects another mailbox or mail folder.  The
+         server must check that the user is permitted read access to
+         this mailbox.  If the mailbox is empty or does not exist, the
+         number of messages reported is zero.  The Folder command is the
+         "FOLD" keyword, followed by the mailbox argument, followed by
+         CRLF.
+
+            Possible responses:
+
+               "#nnn"
+
+                  where nnn is the number of messages in this mailbox.
+
+      READ [nnn]
+
+         The Read command begins a message reading transaction.  If the
+         Read command is given without an argument the current message
+         is  implied (the current message indicator is incremented  by
+         the ACKS or ACKD commands).  If an argument is used with the
+         Read command it is the message number to be read, and this
+         command sets the current message indicator to that value.  The
+         server returns the count of characters in the message to be
+         transmitted.  If there is no message to be read, the count of
+         zero is returned.  If the message was previously deleted with
+         the ACKD command, the count of zero is returned.  The Read
+         command is followed by the RETR command, the READ command, the
+         FOLD command, or the QUIT command.  Do not attempt to RETR a
+
+
+Butler, et. al.                                                 [Page 7]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+         message of zero characters.  The Read command is the "READ"
+         keyword, optionally followed by the message number argument,
+         followed by CRLF.
+
+            Possible responses:
+
+               "=ccc"
+
+                  where ccc is the number of characters in this message.
+
+      RETR
+
+         The Retrieve command confirms that the client is ready to
+         receive the mail data.  It must be followed by an
+         acknowledgment command.  The server will close the connection
+         if asked to transmit a message of zero characters (i.e.,
+         transmit a non-existent message).  The message is transmitted
+         according to the Internet mail format standard RFC-822 [2] in
+         NVT-ASCII.  The Retrieve command is the "RETR" keyword,
+         followed by CRLF.
+
+            Possible responses:
+
+               the message data
+
+               Close the connection
+
+      ACKS
+
+         The Acknowledge and Save command confirms that the client has
+         received and accepted the message.  The ACKS command ends the
+         message reading transaction.  The message is kept in the
+         mailbox.  The current message indicator is incremented.  The
+         server returns the count of characters in the now current
+         message to be transmitted.  If there is no message to be read
+         or the message is marked deleted, the count of zero is
+         returned.  The Acknowledge and Save command is the "ACKS"
+         keyword, followed by CRLF.
+
+            Possible responses:
+
+               "=ccc"
+
+                  where ccc is the number of characters in the next
+                  message.
+
+
+
+
+
+Butler, et. al.                                                 [Page 8]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+      ACKD
+
+         The Acknowledge and Delete command confirms that the client has
+         received and accepted the message.  The ACKD command ends the
+         message reading transaction.  If the user is authorized to have
+         write access to the mailbox, the message is deleted from the
+         mailbox.  Actually, the message is only marked for deletion.
+         The actual change is made  when the mailbox is released at the
+         end of the session or when the client selects another mailbox
+         with the FOLD command.  The messages are not renumbered until
+         the mailbox is released.  If the user does not have write
+         access to the mailbox no change is made to the mailbox.  The
+         response is the same whether or not the message was actually
+         deleted.  The current message indicator is incremented.  The
+         server returns the count of characters in the now current
+         message to be transmitted.  If there is no message to be read
+         or the message is marked deleted, the count of zero is
+         returned.  The Acknowledge and Delete command is the "ACKD"
+         keyword, followed by CRLF.
+
+            Possible responses:
+
+               "=ccc"
+
+                  where ccc is the number of characters in the next
+                  message.
+
+      NACK
+
+         The Negative Acknowledge command reports that the client did
+         not receive the message.  The NACK command ends the message
+         reading transaction.  The message is kept in the mailbox.  The
+         current message indicator remains the same.  The server returns
+         the count of characters in the current message.  Since the
+         count to be returned is for the message just transmitted it the
+         message must exist and not be marked deleted, and the count
+         must be positive (non-zero).  The Negative Acknowledge command
+         is the "NACK" keyword, followed by CRLF.
+
+            Possible responses:
+
+               "=ccc"
+
+                  where ccc is the number of characters in this message.
+
+
+
+
+
+
+Butler, et. al.                                                 [Page 9]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+      QUIT
+
+         The Quit command indicates the client is done with the session.
+         The server sends an OK response and then closes the connection.
+         The Quit command is the "QUIT" keyword, followed by CRLF.
+
+            Possible responses:
+
+               "+ OK" and Close the connection
+
+   Replies
+
+      Greeting
+
+         The greeting is sent by the server as soon as the connection is
+         established.  The greeting is a plus sign, followed by the
+         protocol name ("POP2"), followed by the server host name,
+         optionally followed by text, and ending with a CRLF.
+
+      +
+
+         The success or plus sign response indicates successful
+         completion of the operation specified in the command.  The
+         success response is a plus sign, optionally followed by text,
+         and ending with a CRLF.
+
+      -
+
+         The failure or minus sign response indicates the failure of the
+         operation specified in the command.  The failure response is a
+         minus sign, optionally followed by text, and ending with a
+         CRLF.
+
+      =
+
+         The length or equal sign response tells the length in
+         characters of the message referenced by the command.  The
+         length response is a equal sign, followed by a number,
+         optionally followed by text, and ending with a CRLF.
+
+      #
+
+         The count or number sign response tells the number of messages
+         in a folder or mailbox referenced by the command.  The count
+         response is a number sign, followed by a number, optionally
+         followed by text, and ending with a CRLF.
+
+
+
+
+Butler, et. al.                                                [Page 10]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Timeouts
+
+      In any protocol of this type there have to be timeouts.  Neither
+      side wants to get stuck waiting forever for the other side
+      (particularly is the other side has gone crazy or crashed).
+
+      The client expects a reply to a command fairly quickly and so
+      should have a short timeout for this.  This timeout is called T1.
+
+         For some servers, it may take some processing to compute the
+         number of messages in a mailbox, or the length of a message, or
+         to reformat a stored message for transmission, so this time out
+         has to allow for such processing time.  Also care must be taken
+         not to timeout waiting for the completion of a RETR reply while
+         a long message is in fact being transfered.
+
+      The server expects the session to progress with some but not
+      excessive delay between commands and so should have a long timeout
+      waiting for the next command.  This time out is T2.
+
+         One model of use of this protocol is that any number of
+         different types of clients can be built with different ways of
+         interacting with the human user and the server, but still
+         expecting the client to open the connection to the server,
+         present a sequence of commands, and close the connection,
+         without waiting for intervention by the human user.  With such
+         client implementations, it is reasonable for the server to have
+         a fairly small value for timeout T2.
+
+         On the other hand, one could easily have the client be very
+         human user directed with the user making decisions between
+         commands.  This would cause arbitrary delays between client
+         commands to the server, and require the value of timeout T2 to
+         be quite large.
+
+Implementation Discussion
+
+   Comments on a Server on TOPS-20
+
+      On TOPS-20, a mailbox is a single file.  New messages are appended
+      to the file.  There is a separator line between messages.
+
+      The tricky part of implementing a POP2 server on TOPS-20 is to
+      provide for deleting messages.  This only has to be done for the
+      mailboxes (files) for which the user has write access.  The
+      problem is to avoid both (1) preventing other users from accessing
+      or updating the mailbox for long periods, and (2) accidentally
+      deleting a message the user has not seen.
+
+
+Butler, et. al.                                                [Page 11]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+      One suggestion is as follows:
+
+         When a mailbox is first selected, if the user has write access,
+         rename the mailbox file to some temporary name.  Thus new
+         messages will be placed in a new instance of the mailbox file.
+         Conduct all POP2 operation on the temporary mailbox file
+         (including deleting messages).  When the POP2 session is over
+         or another mailbox is selected, prepend any messages left
+         undeleted in the temporary file to the new instance of the
+         mailbox file.
+
+   Sizes
+
+      The maximum length of a command line is 512 characters (including
+      the command word and the CRLF).
+
+      The maximum length of a reply line is 512 characters (including
+      the success indicator (+, -, =, #) and the CRLF).
+
+      The maximum length of a text line is 1000 characters (including
+      CRLF).
+
+   ISI has developed a POP2 server for TOPS-20 and for Berkeley 4.2
+   Unix, and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix.
+
+Extensions Not Supported
+
+   POP2 does not examine the internal data of messages.  In particular,
+   the server does not parse message headers.
+
+   The server doesn't have any state information (i.e., it doesn't know
+   from one session to the next what has happened).  For example, the
+   server doesn't know which messages were received since the last time
+   the user used POP2, so it can't send just the "new" messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 12]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Examples
+
+   Example 1:
+
+           Client                    Server
+           ------                    ------
+                                Wait for connection
+      Open connection  -->
+                           <--  + POP2 USC-ISIF.ARPA Server
+      HELO POSTEL SECRET -->
+                           <--  #2 messages in your mailbox
+      READ             -->   
+                           <--  =537 characters in message 1
+      RETR             -->   
+                           <--  [data of message 1]
+      ACKD             -->   
+                           <--  =234 characters in message 2
+      RETR             -->   
+                           <--  [data of message 2]
+      ACKD             -->   
+                           <--  =0 no more messages
+      QUIT             -->
+                           <--  + OK, bye, bye
+      Close connection --> <--  Close connection
+                                Go back to start
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 13]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Example 2:
+
+           Client                    Server
+           ------                    ------
+                                Wait for connection
+      Open connection  -->
+                           <--  + POP2 ISI-VAXA.ARPA server here
+      HELO smith secret -->
+                           <--  #35 messages
+      FOLD /usr/spool/mail/smith -->
+                           <--  #27 messages
+      READ  27         -->   
+                           <--  =10123 characters in that message
+      RETR             -->   
+                           <--  [data of message 27]
+      ACKS             -->   
+                           <--  =0 no more messages
+      QUIT             -->
+                           <--  + bye, call again sometime.
+      Close connection --> <--  Close connection
+                                Go back to start
+
+   Example 3:
+
+           Client                    Server
+           ------                    ------
+                                Wait for connection
+      Open connection  -->
+                           <--  + POP2 ISI-VAXA.ARPA server here
+      HELO Jones secret -->
+                           <--  #0 messages
+      READ             -->   
+                           <--  Close connection
+      Close connection -->
+                                Go back to start
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 14]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Formal Syntax
+
+   <digit>    = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
+
+   <letter>   = A | B | C | ... | Z
+                a | b | c | ... | z
+
+   <punct>    = ! | " | # | $ | % | & | ' | ( | ) | * |
+                + | , | - | / | : | < | = | > | ? | @ |
+                [ | ] | ^ | _ | ` | { | | | } | ~
+
+   <quote>    = \
+
+   <any>      = any one of the 128 ASCII codes
+
+   <CR>       = carriage return, code 10
+
+   <LF>       = line feed, code 13
+
+   <SP>       = space, code 32
+
+   <CRLF>     = <CR> <LF>
+
+   <print>    = <letter> | <digit> | <punct> | <quote> <any>
+
+   <char>     = <print> | <SP>
+
+   <word>     = <print> | <print> <word>
+
+   <string>   = <char> | <char> <string>
+
+   <ld>       = <letter> | <digit>
+
+   <ldh>      = <letter> | <digit> | -
+
+   <ldhs>     = <ldh> | <ldh> <ldhs>
+
+   <name>     = <letter> [ [ <ldhs> ] <ld> ]
+
+   <host>     =  <name> | <name> . <host>
+
+   <user>     = <word>
+
+   <password> = <word>
+
+   <mailbox>  = <string>
+
+   <number>   = <digit> | <digit> <number>
+
+
+Butler, et. al.                                                [Page 15]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   <helo>     = HELO <SP> <user> <SP> <password> <CRLF>
+
+   <fold>     = FOLD <SP> <mailbox> <CRLF>
+
+   <read>     = READ [<SP> <number>] <CRLF>
+
+   <retr>     = RETR <CRLF>
+
+   <acks>     = ACKS <CRLF>
+
+   <ackd>     = ACKD <CRLF>
+
+   <nack>     = NACK <CRLF>
+
+   <quit>     = QUIT <CRLF>
+
+   <ok>       = + [<SP> <string>] <CRLF>
+
+   <err>      = - [<SP> <string>] <CRLF>
+
+   <count>    = # <number> [<SP> <string>] <CRLF>
+
+   <greet>    = + <SP> POP2 <SP> <host> [<SP> <string>] <CRLF>
+
+   <length>   = = <number> [<SP> <string>] <CRLF>
+
+   <command>  = <helo> | <fold> | <read> | <retr> |
+                <acks> | <ackd> | <nack> | <quit>
+
+   <reply>    = <ok> | <err> | <count> | <length> | <greet>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 16]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Client State Diagram
+
+   
+                          |                    ^  + BYE  
+                          |  Open              |  -----  
+                          |           Greet    |  Close  
+                          V           -----    |         
+                      +-------+       QUIT    +-------+  
+                      | CALL  |-------------->| EXIT  |  
+                      +-------+               +-------+  
+                          |                       ^      
+                          |  Greet                |      
+                          |  -----                |      
+                          |  HELO                 |      
+              +---->+     |                       |      
+        #NNN  ^     |     |        #NNN           |      
+        ----  |     V     V        ----           |      
+        FOLD  |    +-------+       QUIT           |      
+              +<---| NMBR  |--------------------->+      
+                   +-------+                      ^      
+                    ^     |                       |      
+                    |     |  #NNN                 |      
+                    |     |  ----                 |      
+              =CCC  |     |  READ                 |      
+              ----  |     |                       |      
+              FOLD  |     |        =CCC           |      
+                    |     V        ----           |      
+        =CCC  +--->+-------+       QUIT           |      
+        ----  ^    | SIZE  |--------------------->+      
+        READ  +<---+-------+                             
+                    ^     |                              
+                    |     |  =CCC                        
+              data  |     |  ----                        
+              ----  |     |  RETR                        
+              ack   |     |                              
+                    |     V                              
+                   +-------+                             
+                   | XFER  |                             
+                   +-------+                             
+   
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 17]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Server State Diagram
+
+   
+                       +<----------------------+  Close  
+                       |                       |  -----  
+               Listen  |                       |  Close  
+                       V                       |         
+                   +-------+                  +-------+  
+                   | LSTN  |                  | DONE  |  
+                   +-------+                  +-------+  
+                       |                          ^      
+                       |  Open                    |      
+                       |  -----                   |      
+                       |  Greet                   |      
+                       |                          |      
+                       |           QUIT           |      
+                       V           -----          |      
+                   +-------+       + BYE          |      
+                   | AUTH  |--------------------->+      
+                   +-------+                      ^      
+                       |                          |      
+                       |  HELO                    |      
+                       |  ----                    |      
+                       |  #NNN                    |      
+                       |                          |      
+                       |           QUIT           |      
+                       V           -----          |      
+        FOLD  +--->+-------+       + BYE          |      
+        ----  ^    | MBOX  |--------------------->+      
+        #NNN  +<---+-------+                      ^      
+                    ^     |                       |      
+                    |     |  READ                 |      
+              FOLD  |     |  ----                 |      
+              ----  |     |  =CCC                 |      
+              #NNN  |     |        QUIT           |      
+                    |     V        -----          |      
+        READ  +--->+-------+       + BYE          |      
+        ----  ^    | ITEM  |--------------------->+      
+        =CCC  +<---+-------+                             
+                    ^     |                              
+                    |     |  RETR                        
+              ack   |     |  ----                        
+              ----  |     |  data                        
+              =CCC  |     |                              
+                    |     V                              
+                   +-------+                             
+                   | NEXT  |                             
+                   +-------+                             
+
+
+Butler, et. al.                                                [Page 18]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Combined Flow Diagram
+
+   
+   +----+                                                              
+   |CALL|<------------------------------------------------------------+
+   |LSTN|                                                             ^
+   +----+                                                             |
+    | Greet                                                           |
+    |                                                                 |
+    |  +----------------------------------------------------->+       |
+    |  ^ QUIT                                                 |       |
+    V  |                                                      V       |
+   +----+        +----+                                      +----+   |
+   |CALL| HELO   |NMBR|                                      |EXIT|   |
+   |AUTH|------->|AUTH|                                      |AUTH|   |
+   +----+        +----+                                      +----+   |
+                  | #NNN                                   + Bye |    |
+                  |                                              |    |
+                  |  +------------------------------------>+     |    |
+                  |  ^ QUIT                                |     |    |
+                  V  |                                     V     |    |
+            +--->+----+        +----+                     +----+ |    |
+       FOLD ^    |NMBR| READ   |SIZE|                     |EXIT| |    |
+       ---- |    |MBOX|------->|MBOX|                     |MBOX| |    |
+       #NNN +<---+----+        +----+                     +----+ |    |
+                     ^           | =CCC                 + Bye |  |    |
+                     |           |                            |  |    |
+                FOLD +<--------+ | +------------------->+     |  |    |
+                ----           ^ | ^ QUIT               |     |  |    |
+                #NNN           | V |                    V     |  |    |
+                         +--->+-----+        +----+    +----+ |  |    |
+                    READ ^    |SIZE | RETR   |XFER|    |EXIT| |  |    |
+                    ---- |    | ITEM|------->|ITEM|    |ITEM| |  |    |
+                    =CCC +<---+-----+        +----+    +----+ |  |    |
+                                 ^             | data      |  |  |    |
+                                 |             |           |  |  |    |
+                            =CCC |             V     + Bye |  |  |    |
+                               +----+        +----+        |  |  |    |
+                               |SIZE|    Ack |XFER|        |  |  |    |
+                               |NEXT|<-------|NEXT|        |  |  |    |
+                               +----+        +----+        |  |  |    |
+                                                           |  |  |    |
+                                                           |  |  |    |
+                                                           V  V  V    |
+                                                          +-------+   |
+                                                          | EXIT  |-->+
+                                                          | DONE  |    
+                                                          +-------+    
+
+
+Butler, et. al.                                                [Page 19]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Client Decision Table
+
+   
+          |            STATE                 |
+   -------+----------------------------------|
+   INPUT  | CALL | NMBR | SIZE | XFER | EXIT |
+   -------+----------------------------------|
+   Greet  |  2   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   #NNN   |  1   |  3   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   =CCC   |  1   |  1   |  4   |  1   |  6   |
+   -------+----------------------------------|
+   data   |  1   |  1   |  1   |  5   |  6   |
+   -------+----------------------------------|
+   + Bye  |  1   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   Close  |  1   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   other  |  1   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   Timeout|  1   |  1   |  1   |  1   |  6   |
+   -------+----------------------------------|
+   
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 20]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Actions:
+
+      1.  This is garbage.  Send "QUIT", and go to EXIT state.
+
+      2.  (a) If the greeting is right then send "HELO"
+              and go to NMBR state,
+          (b) Else send "QUIT" and go to EXIT state.
+
+      3.  (a) If user wants this folder and NNN > 0
+              then send "READ" and go to SIZE state,
+          (b) If user wants a this folder and NNN = 0
+              then send "QUIT" and go to EXIT state,
+          (c) If user wants a different folder
+              then send "FOLD" and go to NMBR state.
+
+      4.  (a) If user wants this message and CCC > 0
+              then send "RETR" and go to XFER state,
+          (b) If user wants a this message and CCC = 0
+              then send "QUIT" and go to EXIT state,
+          (c) If user wants a different message
+              then send "READ" and go to SIZE state.
+
+      5.  (a) If user wants this message kept
+              then send "ACKS" and go to SIZE state,
+          (b) If user wants a this message deleted
+              then send "ACKD" and go to SIZE state,
+          (c) If user wants a this message again
+              then send "NACK" and go to SIZE state.
+
+      6.  Close the connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 21]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Server Decision Table
+
+   
+          |              STATE                       
+   -------+----------------------------------------- 
+   INPUT  | LSTN | AUTH | MBOX | ITEM | NEXT | DONE |
+   -------+-----------------------------------------|
+   Open   |  2   |  1   |  1   |  1   |  1   |  1   |
+   -------+-----------------------------------------|
+   HELO   |  1   |  3   |  1   |  1   |  1   |  1   |
+   -------+-----------------------------------------|
+   FOLD   |  1   |  1   |  5   |  5   |  1   |  1   |
+   -------+-----------------------------------------|
+   READ   |  1   |  1   |  6   |  6   |  1   |  1   |
+   -------+-----------------------------------------|
+   RETR   |  1   |  1   |  1   |  7   |  1   |  1   |
+   -------+-----------------------------------------|
+   ACKS   |  1   |  1   |  1   |  1   |  8   |  1   |
+   -------+-----------------------------------------|
+   ACKD   |  1   |  1   |  1   |  1   |  8   |  1   |
+   -------+-----------------------------------------|
+   NACK   |  1   |  1   |  1   |  1   |  8   |  1   |
+   -------+-----------------------------------------|
+   QUIT   |  1   |  4   |  4   |  4   |  1   |  1   |
+   -------+-----------------------------------------|
+   Close  |  1   |  1   |  1   |  1   |  1   |  9   |
+   -------+-----------------------------------------|
+   other  |  1   |  1   |  1   |  1   |  1   |  1   |
+   -------+-----------------------------------------|
+   Timeout|      |  1   |  1   |  1   |  1   |  1   |
+   -------+-----------------------------------------|
+   
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 22]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+   Actions:
+
+      1.  This is garbage.  Send "- error", and Close the connection.
+
+      2.  Send the greeting. Go to AUTH state.
+
+      3.  (a) If authorized user then send "#NNN" and go tp MBOX state,
+          (b) Else send "- error" and Close the connection.
+
+      4.  Send "+ Bye" and go to DONE state.
+
+      5.  Send "+NNN" and go to MBOX state.
+
+      6.  Send "=CCC" and go to ITEM state.
+
+      7.  If message exists then send the data and got to NEXT state,
+          Else Close the connection.
+
+      8.  Do what ACKS/ACKD/NACK require and go to ITEM state.
+
+      9.  Close the connection.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 23]
+
+
+
+RFC 937                                                    February 1985
+Post Office Protocol
+
+
+Acknowledgment
+
+   We would like to acknowledge the helpful comments that we received on
+   the first version of POP described in RFC 918, and the draft of POP2
+   distributed to interested parties.
+
+References
+
+   [1]  Postel, J., "Simple Mail Transfer Protocol", RFC 821,
+   USC/Information Sciences Institute, August 1982.
+
+   [2]  Crocker, D., "Standard for the Format of ARPA-Internet Text
+   Messages", RFC 822, University of Delaware, August 1982.
+
+   [3]  Reynolds, J.K., "Post Office Protocol", RFC 918, USC/Information
+   Sciences Institute, October 1984.
+
+   [4]  Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 923,
+   USC/Information Sciences Institute, October 1984.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Butler, et. al.                                                [Page 24]
+
diff --git a/RFC/rfc977.txt b/RFC/rfc977.txt
new file mode 100644
index 00000000..0f965c48
--- /dev/null
+++ b/RFC/rfc977.txt
@@ -0,0 +1,1539 @@
+

+

+Network Working Group                      Brian Kantor (U.C. San Diego)

+Request for Comments: 977                   Phil Lapsley (U.C. Berkeley)

+                                                           February 1986

+

+                     Network News Transfer Protocol

+                                    

+                A Proposed Standard for the Stream-Based

+                          Transmission of News

+

+Status of This Memo

+

+   NNTP specifies a protocol for the distribution, inquiry, retrieval,

+   and posting of news articles using a reliable stream-based

+   transmission of news among the ARPA-Internet community.  NNTP is

+   designed so that news articles are stored in a central database

+   allowing a subscriber to select only those items he wishes to read.

+   Indexing, cross-referencing, and expiration of aged messages are also

+   provided. This RFC suggests a proposed protocol for the ARPA-Internet

+   community, and requests discussion and suggestions for improvements.

+   Distribution of this memo is unlimited.

+

+1.  Introduction

+

+   For many years, the ARPA-Internet community has supported the

+   distribution of bulletins, information, and data in a timely fashion

+   to thousands of participants.  We collectively refer to such items of

+   information as "news".  Such news provides for the rapid

+   dissemination of items of interest such as software bug fixes, new

+   product reviews, technical tips, and programming pointers, as well as

+   rapid-fire discussions of matters of concern to the working computer

+   professional. News is very popular among its readers.

+

+   There are popularly two methods of distributing such news: the

+   Internet method of direct mailing, and the USENET news system.

+

+1.1.  Internet Mailing Lists

+

+   The Internet community distributes news by the use of mailing lists.

+   These are lists of subscriber's mailbox addresses and remailing

+   sublists of all intended recipients.  These mailing lists operate by

+   remailing a copy of the information to be distributed to each

+   subscriber on the mailing list.  Such remailing is inefficient when a

+   mailing list grows beyond a dozen or so people, since sending a

+   separate copy to each of the subscribers occupies large quantities of

+   network bandwidth, CPU resources, and significant amounts of disk

+   storage at the destination host.  There is also a significant problem

+   in maintenance of the list itself: as subscribers move from one job

+   to another; as new subscribers join and old ones leave; and as hosts

+   come in and out of service.

+

+

+

+

+Kantor & Lapsley                                                [Page 1]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+1.2.  The USENET News System

+

+   Clearly, a worthwhile reduction of the amount of these resources used

+   can be achieved if articles are stored in a central database on the

+   receiving host instead of in each subscriber's mailbox. The USENET

+   news system provides a method of doing just this.  There is a central

+   repository of the news articles in one place (customarily a spool

+   directory of some sort), and a set of programs that allow a

+   subscriber to select those items he wishes to read.  Indexing,

+   cross-referencing, and expiration of aged messages are also provided.

+

+1.3.  Central Storage of News

+

+   For clusters of hosts connected together by fast local area networks

+   (such as Ethernet), it makes even more sense to consolidate news

+   distribution onto one (or a very few) hosts, and to allow access to

+   these news articles using a server and client model.  Subscribers may

+   then request only the articles they wish to see, without having to

+   wastefully duplicate the storage of a copy of each item on each host.

+

+1.4.  A Central News Server

+

+   A way to achieve these economies is to have a central computer system

+   that can provide news service to the other systems on the local area

+   network.  Such a server would manage the collection of news articles

+   and index files, with each person who desires to read news bulletins

+   doing so over the LAN.  For a large cluster of computer systems, the

+   savings in total disk space is clearly worthwhile.  Also, this allows

+   workstations with limited disk storage space to participate in the

+   news without incoming items consuming oppressive amounts of the

+   workstation's disk storage.

+

+   We have heard rumors of somewhat successful attempts to provide

+   centralized news service using IBIS and other shared or distributed

+   file systems.  While it is possible that such a distributed file

+   system implementation might work well with a group of similar

+   computers running nearly identical operating systems, such a scheme

+   is not general enough to offer service to a wide range of client

+   systems, especially when many diverse operating systems may be in use

+   among a group of clients.  There are few (if any) shared or networked

+   file systems that can offer the generality of service that stream

+   connections using Internet TCP provide, particularly when a wide

+   range of host hardware and operating systems are considered.

+

+   NNTP specifies a protocol for the distribution, inquiry, retrieval,

+   and posting of news articles using a reliable stream (such as TCP)

+   server-client model. NNTP is designed so that news articles need only

+

+

+Kantor & Lapsley                                                [Page 2]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   be stored on one (presumably central) host, and subscribers on other

+   hosts attached to the LAN may read news articles using stream

+   connections to the news host.

+

+   NNTP is modelled upon the news article specifications in RFC 850,

+   which describes the USENET news system.  However, NNTP makes few

+   demands upon the structure, content, or storage of news articles, and

+   thus we believe it easily can be adapted to other non-USENET news

+   systems.

+

+   Typically, the NNTP server runs as a background process on one host,

+   and would accept connections from other hosts on the LAN.  This works

+   well when there are a number of small computer systems (such as

+   workstations, with only one or at most a few users each), and a large

+   central server.

+

+1.5.  Intermediate News Servers

+

+   For clusters of machines with many users (as might be the case in a

+   university or large industrial environment), an intermediate server

+   might be used.  This intermediate or "slave" server runs on each

+   computer system, and is responsible for mediating news reading

+   requests and performing local caching of recently-retrieved news

+   articles.

+

+   Typically, a client attempting to obtain news service would first

+   attempt to connect to the news service port on the local machine.  If

+   this attempt were unsuccessful, indicating a failed server, an

+   installation might choose to either deny news access, or to permit

+   connection to the central "master" news server.

+

+   For workstations or other small systems, direct connection to the

+   master server would probably be the normal manner of operation.

+

+   This specification does not cover the operation of slave NNTP

+   servers.  We merely suggest that slave servers are a logical addition

+   to NNTP server usage which would enhance operation on large local

+   area networks.

+

+1.6.  News Distribution

+

+   NNTP has commands which provide a straightforward method of

+   exchanging articles between cooperating hosts. Hosts which are well

+   connected on a local area or other fast network and who wish to

+   actually obtain copies of news articles for local storage might well

+   find NNTP to be a more efficient way to distribute news than more

+   traditional transfer methods (such as UUCP).

+

+

+Kantor & Lapsley                                                [Page 3]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   In the traditional method of distributing news articles, news is

+   propagated from host to host by flooding - that is, each host will

+   send all its new news articles on to each host that it feeds.  These

+   hosts will then in turn send these new articles on to other hosts

+   that they feed.  Clearly, sending articles that a host already has

+   obtained a copy of from another feed (many hosts that receive news

+   are redundantly fed) again is a waste of time and communications

+   resources, but for transport mechanisms that are single-transaction

+   based rather than interactive (such as UUCP in the UNIX-world <1>),

+   distribution time is diminished by sending all articles and having

+   the receiving host simply discard the duplicates.  This is an

+   especially true when communications sessions are limited to once a

+   day.

+

+   Using NNTP, hosts exchanging news articles have an interactive

+   mechanism for deciding which articles are to be transmitted.  A host

+   desiring new news, or which has new news to send, will typically

+   contact one or more of its neighbors using NNTP.  First it will

+   inquire if any new news groups have been created on the serving host

+   by means of the NEWGROUPS command.  If so, and those are appropriate

+   or desired (as established by local site-dependent rules), those new

+   newsgroups can be created.

+

+   The client host will then inquire as to which new articles have

+   arrived in all or some of the newsgroups that it desires to receive,

+   using the NEWNEWS command.  It will receive a list of new articles

+   from the server, and can request transmission of those articles that

+   it desires and does not already have.

+

+   Finally, the client can advise the server of those new articles which

+   the client has recently received.  The server will indicate those

+   articles that it has already obtained copies of, and which articles

+   should be sent to add to its collection.

+

+   In this manner, only those articles which are not duplicates and

+   which are desired are transferred.

+

+

+

+

+

+

+

+

+

+

+

+

+

+Kantor & Lapsley                                                [Page 4]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+2.  The NNTP Specification

+

+2.1.  Overview

+

+   The news server specified by this document uses a stream connection

+   (such as TCP) and SMTP-like commands and responses.  It is designed

+   to accept connections from hosts, and to provide a simple interface

+   to the news database.

+

+   This server is only an interface between programs and the news

+   databases. It does not perform any user interaction or presentation-

+   level functions. These "user-friendly" functions are better left to

+   the client programs, which have a better understanding of the

+   environment in which they are operating.

+

+   When used via Internet TCP, the contact port assigned for this

+   service is 119.

+

+2.2.  Character Codes

+

+   Commands and replies are composed of characters from the ASCII

+   character set.  When the transport service provides an 8-bit byte

+   (octet) transmission channel, each 7-bit character is transmitted

+   right justified in an octet with the high order bit cleared to zero.

+

+2.3.  Commands

+

+   Commands consist of a command word, which in some cases may be

+   followed by a parameter.  Commands with parameters must separate the

+   parameters from each other and from the command by one or more space

+   or tab characters.  Command lines must be complete with all required

+   parameters, and may not contain more than one command.

+

+   Commands and command parameters are not case sensitive. That is, a

+   command or parameter word may be upper case, lower case, or any

+   mixture of upper and lower case.

+

+   Each command line must be terminated by a CR-LF (Carriage Return -

+   Line Feed) pair.

+

+   Command lines shall not exceed 512 characters in length, counting all

+   characters including spaces, separators, punctuation, and the

+   trailing CR-LF (thus there are 510 characters maximum allowed for the

+   command and its parameters).  There is no provision for continuation

+   command lines.

+

+

+

+

+Kantor & Lapsley                                                [Page 5]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+2.4.  Responses

+

+   Responses are of two kinds, textual and status.

+

+2.4.1.  Text Responses

+

+   Text is sent only after a numeric status response line has been sent

+   that indicates that text will follow.  Text is sent as a series of

+   successive lines of textual matter, each terminated with CR-LF pair.

+   A single line containing only a period (.) is sent to indicate the

+   end of the text (i.e., the server will send a CR-LF pair at the end

+   of the last line of text, a period, and another CR-LF pair).

+

+   If the text contained a period as the first character of the text

+   line in the original, that first period is doubled.  Therefore, the

+   client must examine the first character of each line received, and

+   for those beginning with a period, determine either that this is the

+   end of the text or whether to collapse the doubled period to a single

+   one.

+

+   The intention is that text messages will usually be displayed on the

+   user's terminal whereas command/status responses will be interpreted

+   by the client program before any possible display is done.

+

+2.4.2.  Status Responses

+

+   These are status reports from the server and indicate the response to

+   the last command received from the client.

+

+   Status response lines begin with a 3 digit numeric code which is

+   sufficient to distinguish all responses.  Some of these may herald

+   the subsequent transmission of text.

+

+   The first digit of the response broadly indicates the success,

+   failure, or progress of the previous command.

+

+      1xx - Informative message

+      2xx - Command ok

+      3xx - Command ok so far, send the rest of it.

+      4xx - Command was correct, but couldn't be performed for

+            some reason.

+      5xx - Command unimplemented, or incorrect, or a serious

+            program error occurred.

+

+

+

+

+

+

+Kantor & Lapsley                                                [Page 6]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   The next digit in the code indicates the function response category.

+

+      x0x - Connection, setup, and miscellaneous messages

+      x1x - Newsgroup selection

+      x2x - Article selection

+      x3x - Distribution functions

+      x4x - Posting

+      x8x - Nonstandard (private implementation) extensions

+      x9x - Debugging output

+

+   The exact response codes that should be expected from each command

+   are detailed in the description of that command.  In addition, below

+   is listed a general set of response codes that may be received at any

+   time.

+

+   Certain status responses contain parameters such as numbers and

+   names. The number and type of such parameters is fixed for each

+   response code to simplify interpretation of the response.

+

+   Parameters are separated from the numeric response code and from each

+   other by a single space. All numeric parameters are decimal, and may

+   have leading zeros. All string parameters begin after the separating

+   space, and end before the following separating space or the CR-LF

+   pair at the end of the line. (String parameters may not, therefore,

+   contain spaces.) All text, if any, in the response which is not a

+   parameter of the response must follow and be separated from the last

+   parameter by a space.  Also, note that the text following a response

+   number may vary in different implementations of the server. The

+   3-digit numeric code should be used to determine what response was

+   sent.

+

+   Response codes not specified in this standard may be used for any

+   installation-specific additional commands also not specified. These

+   should be chosen to fit the pattern of x8x specified above.  (Note

+   that debugging is provided for explicitly in the x9x response codes.)

+   The use of unspecified response codes for standard commands is

+   prohibited.

+

+   We have provided a response pattern x9x for debugging.  Since much

+   debugging output may be classed as "informative messages", we would

+   expect, therefore, that responses 190 through 199 would be used for

+   various debugging outputs.  There is no requirement in this

+   specification for debugging output, but if such is provided over the

+   connected stream, it must use these response codes.  If appropriate

+   to a specific implementation, other x9x codes may be used for

+   debugging.  (An example might be to use e.g., 290 to acknowledge a

+   remote debugging request.)

+

+

+Kantor & Lapsley                                                [Page 7]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+2.4.3.  General Responses

+

+   The following is a list of general response codes that may be sent by

+   the NNTP server.  These are not specific to any one command, but may

+   be returned as the result of a connection, a failure, or some unusual

+   condition.

+

+   In general, 1xx codes may be ignored or displayed as desired;  code

+   200 or 201 is sent upon initial connection to the NNTP server

+   depending upon posting permission; code 400 will be sent when the

+   NNTP server discontinues service (by operator request, for example);

+   and 5xx codes indicate that the command could not be performed for

+   some unusual reason.

+

+      100 help text

+      190

+        through

+      199 debug output

+

+      200 server ready - posting allowed

+      201 server ready - no posting allowed

+

+      400 service discontinued

+

+      500 command not recognized

+      501 command syntax error

+      502 access restriction or permission denied

+      503 program fault - command not performed

+

+3.  Command and Response Details

+

+   On the following pages are descriptions of each command recognized by

+   the NNTP server and the responses which will be returned by those

+   commands.

+

+   Each command is shown in upper case for clarity, although case is

+   ignored in the interpretation of commands by the NNTP server.  Any

+   parameters are shown in lower case.  A parameter shown in [square

+   brackets] is optional.  For example, [GMT] indicates that the

+   triglyph GMT may present or omitted.

+

+   Every command described in this section must be implemented by all

+   NNTP servers.

+

+

+

+

+

+

+Kantor & Lapsley                                                [Page 8]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   There is no prohibition against additional commands being added;

+   however, it is recommended that any such unspecified command begin

+   with the letter "X" to avoid conflict with later revisions of this

+   specification.

+

+   Implementors are reminded that such additional commands may not

+   redefine specified status response codes.  Using additional

+   unspecified responses for standard commands is also prohibited.

+

+3.1.  The ARTICLE, BODY, HEAD, and STAT commands

+

+   There are two forms to the ARTICLE command (and the related BODY,

+   HEAD, and STAT commands), each using a different method of specifying

+   which article is to be retrieved.  When the ARTICLE command is

+   followed by a message-id in angle brackets ("<" and ">"), the first

+   form of the command is used; when a numeric parameter or no parameter

+   is supplied, the second form is invoked.

+

+   The text of the article is returned as a textual response, as

+   described earlier in this document.

+

+   The HEAD and BODY commands are identical to the ARTICLE command

+   except that they respectively return only the header lines or text

+   body of the article.

+

+   The STAT command is similar to the ARTICLE command except that no

+   text is returned.  When selecting by message number within a group,

+   the STAT command serves to set the current article pointer without

+   sending text. The returned acknowledgement response will contain the

+   message-id, which may be of some value.  Using the STAT command to

+   select by message-id is valid but of questionable value, since a

+   selection by message-id does NOT alter the "current article pointer".

+

+3.1.1.  ARTICLE (selection by message-id)

+

+   ARTICLE <message-id>

+

+   Display the header, a blank line, then the body (text) of the

+   specified article.  Message-id is the message id of an article as

+   shown in that article's header.  It is anticipated that the client

+   will obtain the message-id from a list provided by the NEWNEWS

+   command, from references contained within another article, or from

+   the message-id provided in the response to some other commands.

+

+   Please note that the internally-maintained "current article pointer"

+   is NOT ALTERED by this command. This is both to facilitate the

+   presentation of articles that may be referenced within an article

+

+

+Kantor & Lapsley                                                [Page 9]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   being read, and because of the semantic difficulties of determining

+   the proper sequence and membership of an article which may have been

+   posted to more than one newsgroup.

+

+3.1.2.  ARTICLE (selection by number)

+

+   ARTICLE [nnn]

+

+   Displays the header, a blank line, then the body (text) of the

+   current or specified article.  The optional parameter nnn is the

+

+   numeric id of an article in the current newsgroup and must be chosen

+   from the range of articles provided when the newsgroup was selected.

+   If it is omitted, the current article is assumed.

+

+   The internally-maintained "current article pointer" is set by this

+   command if a valid article number is specified.

+

+   [the following applies to both forms of the article command.] A

+   response indicating the current article number, a message-id string,

+   and that text is to follow will be returned.

+

+   The message-id string returned is an identification string contained

+   within angle brackets ("<" and ">"), which is derived from the header

+   of the article itself.  The Message-ID header line (required by

+   RFC850) from the article must be used to supply this information. If

+   the message-id header line is missing from the article, a single

+   digit "0" (zero) should be supplied within the angle brackets.

+

+   Since the message-id field is unique with each article, it may be

+   used by a news reading program to skip duplicate displays of articles

+   that have been posted more than once, or to more than one newsgroup.

+

+3.1.3.  Responses

+

+   220 n <a> article retrieved - head and body follow

+           (n = article number, <a> = message-id)

+   221 n <a> article retrieved - head follows

+   222 n <a> article retrieved - body follows

+   223 n <a> article retrieved - request text separately

+   412 no newsgroup has been selected

+   420 no current article has been selected

+   423 no such article number in this group

+   430 no such article found

+

+

+

+

+

+Kantor & Lapsley                                               [Page 10]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+3.2.  The GROUP command

+

+3.2.1.  GROUP

+

+   GROUP ggg

+

+   The required parameter ggg is the name of the newsgroup to be

+   selected (e.g. "net.news").  A list of valid newsgroups may be

+   obtained from the LIST command.

+

+   The successful selection response will return the article numbers of

+   the first and last articles in the group, and an estimate of the

+   number of articles on file in the group.  It is not necessary that

+   the estimate be correct, although that is helpful; it must only be

+   equal to or larger than the actual number of articles on file.  (Some

+   implementations will actually count the number of articles on file.

+   Others will just subtract first article number from last to get an

+   estimate.)

+

+   When a valid group is selected by means of this command, the

+   internally maintained "current article pointer" is set to the first

+   article in the group.  If an invalid group is specified, the

+   previously selected group and article remain selected.  If an empty

+   newsgroup is selected, the "current article pointer" is in an

+   indeterminate state and should not be used.

+

+   Note that the name of the newsgroup is not case-dependent.  It must

+   otherwise match a newsgroup obtained from the LIST command or an

+   error will result.

+

+3.2.2.  Responses

+

+   211 n f l s group selected

+           (n = estimated number of articles in group,

+           f = first article number in the group,

+           l = last article number in the group,

+           s = name of the group.)

+   411 no such news group

+

+

+

+

+

+

+

+

+

+

+

+Kantor & Lapsley                                               [Page 11]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+3.3.  The HELP command

+

+3.3.1.  HELP

+

+   HELP

+

+   Provides a short summary of commands that are understood by this

+   implementation of the server. The help text will be presented as a

+   textual response, terminated by a single period on a line by itself.

+

+   3.3.2.  Responses

+

+   100 help text follows

+

+3.4.  The IHAVE command

+

+3.4.1.  IHAVE

+

+   IHAVE <messageid>

+

+   The IHAVE command informs the server that the client has an article

+   whose id is <messageid>.  If the server desires a copy of that

+   article, it will return a response instructing the client to send the

+   entire article.  If the server does not want the article (if, for

+   example, the server already has a copy of it), a response indicating

+   that the article is not wanted will be returned.

+

+   If transmission of the article is requested, the client should send

+   the entire article, including header and body, in the manner

+   specified for text transmission from the server. A response code

+   indicating success or failure of the transferral of the article will

+   be returned.

+

+   This function differs from the POST command in that it is intended

+   for use in transferring already-posted articles between hosts.

+   Normally it will not be used when the client is a personal

+   newsreading program.  In particular, this function will invoke the

+   server's news posting program with the appropriate settings (flags,

+   options, etc) to indicate that the forthcoming article is being

+   forwarded from another host.

+

+   The server may, however, elect not to post or forward the article if

+   after further examination of the article it deems it inappropriate to

+   do so.  The 436 or 437 error codes may be returned as appropriate to

+   the situation.

+

+   Reasons for such subsequent rejection of an article may include such

+

+

+Kantor & Lapsley                                               [Page 12]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   problems as inappropriate newsgroups or distributions, disk space

+   limitations, article lengths, garbled headers, and the like.  These

+   are typically restrictions enforced by the server host's news

+   software and not necessarily the NNTP server itself.

+

+3.4.2.  Responses

+

+   235 article transferred ok

+   335 send article to be transferred.  End with <CR-LF>.<CR-LF>

+   435 article not wanted - do not send it

+   436 transfer failed - try again later

+   437 article rejected - do not try again

+

+   An implementation note:

+

+   Because some host news posting software may not be able to decide

+   immediately that an article is inappropriate for posting or

+   forwarding, it is acceptable to acknowledge the successful transfer

+   of the article and to later silently discard it.  Thus it is

+   permitted to return the 235 acknowledgement code and later discard

+   the received article.  This is not a fully satisfactory solution to

+   the problem.  Perhaps some implementations will wish to send mail to

+   the author of the article in certain of these cases.

+

+3.5.  The LAST command

+

+3.5.1.  LAST

+

+   LAST

+

+   The internally maintained "current article pointer" is set to the

+   previous article in the current newsgroup.  If already positioned at

+   the first article of the newsgroup, an error message is returned and

+   the current article remains selected.

+

+   The internally-maintained "current article pointer" is set by this

+   command.

+

+   A response indicating the current article number, and a message-id

+   string will be returned.  No text is sent in response to this

+   command.

+

+3.5.2.  Responses

+

+   223 n a article retrieved - request text separately

+           (n = article number, a = unique article id)

+

+

+

+Kantor & Lapsley                                               [Page 13]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   412 no newsgroup selected

+   420 no current article has been selected

+   422 no previous article in this group

+

+3.6.  The LIST command

+

+3.6.1.  LIST

+

+   LIST

+

+   Returns a list of valid newsgroups and associated information.  Each

+   newsgroup is sent as a line of text in the following format:

+

+      group last first p

+

+   where <group> is the name of the newsgroup, <last> is the number of

+   the last known article currently in that newsgroup, <first> is the

+   number of the first article currently in the newsgroup, and <p> is

+   either 'y' or 'n' indicating whether posting to this newsgroup is

+   allowed ('y') or prohibited ('n').

+

+   The <first> and <last> fields will always be numeric.  They may have

+   leading zeros.  If the <last> field evaluates to less than the

+   <first> field, there are no articles currently on file in the

+   newsgroup.

+

+   Note that posting may still be prohibited to a client even though the

+   LIST command indicates that posting is permitted to a particular

+   newsgroup. See the POST command for an explanation of client

+   prohibitions.  The posting flag exists for each newsgroup because

+   some newsgroups are moderated or are digests, and therefore cannot be

+   posted to; that is, articles posted to them must be mailed to a

+   moderator who will post them for the submitter.  This is independent

+   of the posting permission granted to a client by the NNTP server.

+

+   Please note that an empty list (i.e., the text body returned by this

+   command consists only of the terminating period) is a possible valid

+   response, and indicates that there are currently no valid newsgroups.

+

+3.6.2.  Responses

+

+   215 list of newsgroups follows

+

+

+

+

+

+

+

+Kantor & Lapsley                                               [Page 14]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+3.7.  The NEWGROUPS command

+

+3.7.1.  NEWGROUPS

+

+   NEWGROUPS date time [GMT] [<distributions>]

+

+   A list of newsgroups created since <date and time> will be listed in

+   the same format as the LIST command.

+

+   The date is sent as 6 digits in the format YYMMDD, where YY is the

+   last two digits of the year, MM is the two digits of the month (with

+   leading zero, if appropriate), and DD is the day of the month (with

+   leading zero, if appropriate).  The closest century is assumed as

+   part of the year (i.e., 86 specifies 1986, 30 specifies 2030, 99 is

+   1999, 00 is 2000).

+

+   Time must also be specified.  It must be as 6 digits HHMMSS with HH

+   being hours on the 24-hour clock, MM minutes 00-59, and SS seconds

+   00-59.  The time is assumed to be in the server's timezone unless the

+   token "GMT" appears, in which case both time and date are evaluated

+   at the 0 meridian.

+

+   The optional parameter "distributions" is a list of distribution

+   groups, enclosed in angle brackets.  If specified, the distribution

+   portion of a new newsgroup (e.g, 'net' in 'net.wombat') will be

+   examined for a match with the distribution categories listed, and

+   only those new newsgroups which match will be listed.  If more than

+   one distribution group is to be listed, they must be separated by

+   commas within the angle brackets.

+

+   Please note that an empty list (i.e., the text body returned by this

+   command consists only of the terminating period) is a possible valid

+   response, and indicates that there are currently no new newsgroups.

+

+3.7.2.  Responses

+

+   231 list of new newsgroups follows

+

+

+

+

+

+

+

+

+

+

+

+

+Kantor & Lapsley                                               [Page 15]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+3.8.  The NEWNEWS command

+

+3.8.1.  NEWNEWS

+

+   NEWNEWS newsgroups date time [GMT] [<distribution>]

+

+   A list of message-ids of articles posted or received to the specified

+   newsgroup since "date" will be listed. The format of the listing will

+   be one message-id per line, as though text were being sent.  A single

+   line consisting solely of one period followed by CR-LF will terminate

+   the list.

+

+   Date and time are in the same format as the NEWGROUPS command.

+

+   A newsgroup name containing a "*" (an asterisk) may be specified to

+   broaden the article search to some or all newsgroups.  The asterisk

+   will be extended to match any part of a newsgroup name (e.g.,

+   net.micro* will match net.micro.wombat, net.micro.apple, etc). Thus

+   if only an asterisk is given as the newsgroup name, all newsgroups

+   will be searched for new news.

+

+   (Please note that the asterisk "*" expansion is a general

+   replacement; in particular, the specification of e.g., net.*.unix

+   should be correctly expanded to embrace names such as net.wombat.unix

+   and net.whocares.unix.)

+

+   Conversely, if no asterisk appears in a given newsgroup name, only

+   the specified newsgroup will be searched for new articles. Newsgroup

+   names must be chosen from those returned in the listing of available

+   groups.  Multiple newsgroup names (including a "*") may be specified

+   in this command, separated by a comma.  No comma shall appear after

+   the last newsgroup in the list.  [Implementors are cautioned to keep

+   the 512 character command length limit in mind.]

+

+   The exclamation point ("!") may be used to negate a match. This can

+   be used to selectively omit certain newsgroups from an otherwise

+   larger list.  For example, a newsgroups specification of

+   "net.*,mod.*,!mod.map.*" would specify that all net.<anything> and

+   all mod.<anything> EXCEPT mod.map.<anything> newsgroup names would be

+   matched.  If used, the exclamation point must appear as the first

+   character of the given newsgroup name or pattern.

+

+   The optional parameter "distributions" is a list of distribution

+   groups, enclosed in angle brackets.  If specified, the distribution

+   portion of an article's newsgroup (e.g, 'net' in 'net.wombat') will

+   be examined for a match with the distribution categories listed, and

+   only those articles which have at least one newsgroup belonging to

+

+

+Kantor & Lapsley                                               [Page 16]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   the list of distributions will be listed.  If more than one

+   distribution group is to be supplied, they must be separated by

+   commas within the angle brackets.

+

+   The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute

+   news is discussed in an earlier part of this document.

+

+   Please note that an empty list (i.e., the text body returned by this

+   command consists only of the terminating period) is a possible valid

+   response, and indicates that there is currently no new news.

+

+3.8.2.  Responses

+

+   230 list of new articles by message-id follows

+

+3.9.  The NEXT command

+

+3.9.1.  NEXT

+

+   NEXT

+

+   The internally maintained "current article pointer" is advanced to

+   the next article in the current newsgroup.  If no more articles

+   remain in the current group, an error message is returned and the

+   current article remains selected.

+

+   The internally-maintained "current article pointer" is set by this

+   command.

+

+   A response indicating the current article number, and the message-id

+   string will be returned.  No text is sent in response to this

+   command.

+

+3.9.2.  Responses

+

+   223 n a article retrieved - request text separately

+           (n = article number, a = unique article id)

+   412 no newsgroup selected

+   420 no current article has been selected

+   421 no next article in this group

+

+

+

+

+

+

+

+

+

+Kantor & Lapsley                                               [Page 17]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+3.10.  The POST command

+

+3.10.1.  POST

+

+   POST

+

+   If posting is allowed, response code 340 is returned to indicate that

+   the article to be posted should be sent. Response code 440 indicates

+   that posting is prohibited for some installation-dependent reason.

+

+   If posting is permitted, the article should be presented in the

+   format specified by RFC850, and should include all required header

+   lines. After the article's header and body have been completely sent

+   by the client to the server, a further response code will be returned

+   to indicate success or failure of the posting attempt.

+

+   The text forming the header and body of the message to be posted

+   should be sent by the client using the conventions for text received

+   from the news server:  A single period (".") on a line indicates the

+   end of the text, with lines starting with a period in the original

+   text having that period doubled during transmission.

+

+   No attempt shall be made by the server to filter characters, fold or

+   limit lines, or otherwise process incoming text.  It is our intent

+   that the server just pass the incoming message to be posted to the

+   server installation's news posting software, which is separate from

+   this specification.  See RFC850 for more details.

+

+   Since most installations will want the client news program to allow

+   the user to prepare his message using some sort of text editor, and

+   transmit it to the server for posting only after it is composed, the

+   client program should take note of the herald message that greeted it

+   when the connection was first established. This message indicates

+   whether postings from that client are permitted or not, and can be

+   used to caution the user that his access is read-only if that is the

+   case. This will prevent the user from wasting a good deal of time

+   composing a message only to find posting of the message was denied.

+   The method and determination of which clients and hosts may post is

+   installation dependent and is not covered by this specification.

+

+3.10.2.  Responses

+

+   240 article posted ok

+   340 send article to be posted. End with <CR-LF>.<CR-LF>

+   440 posting not allowed

+   441 posting failed

+

+

+

+Kantor & Lapsley                                               [Page 18]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   (for reference, one of the following codes will be sent upon initial

+   connection; the client program should determine whether posting is

+   generally permitted from these:) 200 server ready - posting allowed

+   201 server ready - no posting allowed

+

+3.11.  The QUIT command

+

+3.11.1.  QUIT

+

+   QUIT

+

+   The server process acknowledges the QUIT command and then closes the

+   connection to the client.  This is the preferred method for a client

+   to indicate that it has finished all its transactions with the NNTP

+   server.

+

+   If a client simply disconnects (or the connection times out, or some

+   other fault occurs), the server should gracefully cease its attempts

+   to service the client.

+

+3.11.2.  Responses

+

+   205 closing connection - goodbye!

+

+3.12.  The SLAVE command

+

+3.12.1.  SLAVE

+

+   SLAVE

+

+   Indicates to the server that this client connection is to a slave

+   server, rather than a user.

+

+   This command is intended for use in separating connections to single

+   users from those to subsidiary ("slave") servers.  It may be used to

+   indicate that priority should therefore be given to requests from

+   this client, as it is presumably serving more than one person.  It

+   might also be used to determine which connections to close when

+   system load levels are exceeded, perhaps giving preference to slave

+   servers.  The actual use this command is put to is entirely

+   implementation dependent, and may vary from one host to another.  In

+   NNTP servers which do not give priority to slave servers, this

+   command must nonetheless be recognized and acknowledged.

+

+3.12.2.  Responses

+

+   202 slave status noted

+

+

+Kantor & Lapsley                                               [Page 19]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+4.  Sample Conversations

+

+   These are samples of the conversations that might be expected with

+   the news server in hypothetical sessions.  The notation C: indicates

+   commands sent to the news server from the client program; S: indicate

+   responses received from the server by the client.

+

+4.1.  Example 1 - relative access with NEXT

+

+   S:      (listens at TCP port 119)

+

+   C:      (requests connection on TCP port 119)

+   S:      200 wombatvax news server ready - posting ok

+

+   (client asks for a current newsgroup list)

+   C:      LIST

+   S:      215 list of newsgroups follows

+   S:      net.wombats 00543 00501 y

+   S:      net.unix-wizards 10125 10011 y

+           (more information here)

+   S:      net.idiots 00100 00001 n

+   S:      .

+

+   (client selects a newsgroup)

+   C:      GROUP net.unix-wizards

+   S:      211 104 10011 10125 net.unix-wizards group selected

+           (there are 104 articles on file, from 10011 to 10125)

+

+   (client selects an article to read)

+   C:      STAT 10110

+   S:      223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics

+           only (article 10110 selected, its message-id is

+           <23445@sdcsvax.ARPA>)

+

+   (client examines the header)

+   C:      HEAD

+   S:      221 10110 <23445@sdcsvax.ARPA> article retrieved - head

+           follows (text of the header appears here)

+   S:      .

+

+   (client wants to see the text body of the article)

+   C:      BODY

+   S:      222 10110 <23445@sdcsvax.ARPA> article retrieved - body

+           follows (body text here)

+   S:      .

+

+   (client selects next article in group)

+

+

+Kantor & Lapsley                                               [Page 20]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   C:      NEXT

+   S:      223 10113 <21495@nudebch.uucp> article retrieved - statistics

+           only (article 10113 was next in group)

+

+   (client finishes session)

+   C:      QUIT

+   S:      205 goodbye.

+

+4.2.  Example 2 - absolute article access with ARTICLE

+

+   S:      (listens at TCP port 119)

+

+   C:      (requests connection on TCP port 119)

+   S:      201 UCB-VAX netnews server ready -- no posting allowed

+

+   C:      GROUP msgs

+   S:      211 103 402 504 msgs Your new group is msgs

+           (there are 103 articles, from 402 to 504)

+

+   C:      ARTICLE 401

+   S:      423 No such article in this newsgroup

+

+   C:      ARTICLE 402

+   S:      220 402 <4105@ucbvax.ARPA> Article retrieved, text follows

+   S:      (article header and body follow)

+   S:      .

+

+   C:      HEAD 403

+   S:      221 403 <3108@mcvax.UUCP> Article retrieved, header follows

+   S:      (article header follows)

+   S:      .

+

+   C:      QUIT

+   S:      205 UCB-VAX news server closing connection.  Goodbye.

+

+4.3.  Example 3 - NEWGROUPS command

+

+   S:      (listens at TCP port 119)

+

+   C:      (requests connection on TCP port 119)

+   S:      200 Imaginary Institute News Server ready (posting ok)

+

+   (client asks for new newsgroups since April 3, 1985)

+   C:      NEWGROUPS 850403 020000

+

+   S:      231 New newsgroups since 03/04/85 02:00:00 follow

+

+

+

+Kantor & Lapsley                                               [Page 21]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   S:      net.music.gdead

+   S:      net.games.sources

+   S:      .

+

+   C:      GROUP net.music.gdead

+   S:      211 0 1 1 net.music.gdead Newsgroup selected

+           (there are no articles in that newsgroup, and

+           the first and last article numbers should be ignored)

+

+   C:      QUIT

+   S:      205 Imaginary Institute news server ceasing service.  Bye!

+

+4.4.  Example 4 - posting a news article

+

+   S:      (listens at TCP port 119)

+

+   C:      (requests connection on TCP port 119)

+   S:      200 BANZAIVAX news server ready, posting allowed.

+

+   C:      POST

+   S:      340 Continue posting; Period on a line by itself to end

+   C:      (transmits news article in RFC850 format)

+   C:      .

+   S:      240 Article posted successfully.

+

+   C:      QUIT

+   S:      205 BANZAIVAX closing connection.  Goodbye.

+

+4.5.  Example 5 - interruption due to operator request

+

+   S:      (listens at TCP port 119)

+

+   C:      (requests connection on TCP port 119)

+   S:      201 genericvax news server ready, no posting allowed.

+

+           (assume normal conversation for some time, and

+           that a newsgroup has been selected)

+

+   C:      NEXT

+   S:      223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.

+

+   C:      HEAD

+   C:      221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.

+

+   S:      (sends head of article, but halfway through is

+           interrupted by an operator request.  The following

+           then occurs, without client intervention.)

+

+

+Kantor & Lapsley                                               [Page 22]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   S:      (ends current line with a CR-LF pair)

+   S:      .

+   S:      400 Connection closed by operator.  Goodbye.

+   S:      (closes connection)

+

+4.6.  Example 6 - Using the news server to distribute news between

+      systems.

+

+   S:      (listens at TCP port 119)

+

+   C:      (requests connection on TCP port 119)

+   S:      201 Foobar NNTP server ready (no posting)

+

+   (client asks for new newsgroups since 2 am, May 15, 1985)

+   C:      NEWGROUPS 850515 020000

+   S:      235 New newsgroups since 850515 follow

+   S:      net.fluff

+   S:      net.lint

+   S:      .

+

+   (client asks for new news articles since 2 am, May 15, 1985)

+   C:      NEWNEWS * 850515 020000

+   S:      230 New news since 850515 020000 follows

+   S:      <1772@foo.UUCP>

+   S:      <87623@baz.UUCP>

+   S:      <17872@GOLD.CSNET>

+   S:      .

+

+   (client asks for article <1772@foo.UUCP>)

+   C:      ARTICLE <1772@foo.UUCP>

+   S:      220 <1772@foo.UUCP> All of article follows

+   S:      (sends entire message)

+   S:      .

+

+   (client asks for article <87623@baz.UUCP>

+   C:      ARTICLE <87623@baz.UUCP>

+   S:      220 <87623@baz.UUCP> All of article follows

+   S:      (sends entire message)

+   S:      .

+

+   (client asks for article <17872@GOLD.CSNET>

+   C:      ARTICLE <17872@GOLD.CSNET>

+   S:      220 <17872@GOLD.CSNET> All of article follows

+   S:      (sends entire message)

+   S:      .

+

+

+

+

+Kantor & Lapsley                                               [Page 23]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   (client offers an article it has received recently)

+   C:      IHAVE <4105@ucbvax.ARPA>

+   S:      435 Already seen that one, where you been?

+

+   (client offers another article)

+   C:      IHAVE <4106@ucbvax.ARPA>

+   S:      335 News to me!  <CRLF.CRLF> to end.

+   C:      (sends article)

+   C:      .

+   S:      235 Article transferred successfully.  Thanks.

+

+   (or)

+

+   S:      436 Transfer failed.

+

+   (client is all through with the session)

+   C:      QUIT

+   S:      205 Foobar NNTP server bids you farewell.

+

+4.7.  Summary of commands and responses.

+

+   The following are the commands recognized and responses returned by

+   the NNTP server.

+

+4.7.1.  Commands

+

+   ARTICLE

+   BODY

+   GROUP

+   HEAD

+   HELP

+   IHAVE

+   LAST

+   LIST

+   NEWGROUPS

+   NEWNEWS

+   NEXT

+   POST

+   QUIT

+   SLAVE

+   STAT

+

+4.7.2.  Responses

+

+   100 help text follows

+   199 debug output

+

+

+

+Kantor & Lapsley                                               [Page 24]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   200 server ready - posting allowed

+   201 server ready - no posting allowed

+   202 slave status noted

+   205 closing connection - goodbye!

+   211 n f l s group selected

+   215 list of newsgroups follows

+   220 n <a> article retrieved - head and body follow 221 n <a> article

+   retrieved - head follows

+   222 n <a> article retrieved - body follows

+   223 n <a> article retrieved - request text separately 230 list of new

+   articles by message-id follows

+   231 list of new newsgroups follows

+   235 article transferred ok

+   240 article posted ok

+

+   335 send article to be transferred.  End with <CR-LF>.<CR-LF>

+   340 send article to be posted. End with <CR-LF>.<CR-LF>

+

+   400 service discontinued

+   411 no such news group

+   412 no newsgroup has been selected

+   420 no current article has been selected

+   421 no next article in this group

+   422 no previous article in this group

+   423 no such article number in this group

+   430 no such article found

+   435 article not wanted - do not send it

+   436 transfer failed - try again later

+   437 article rejected - do not try again.

+   440 posting not allowed

+   441 posting failed

+

+   500 command not recognized

+   501 command syntax error

+   502 access restriction or permission denied

+   503 program fault - command not performed

+

+4.8.  A Brief Word about the USENET News System

+

+   In the UNIX world, which traditionally has been linked by 1200 baud

+   dial-up telephone lines, the USENET News system has evolved to handle

+   central storage, indexing, retrieval, and distribution of news.  With

+   the exception of its underlying transport mechanism (UUCP), USENET

+   News is an efficient means of providing news and bulletin service to

+   subscribers on UNIX and other hosts worldwide.  The USENET News

+

+

+

+

+Kantor & Lapsley                                               [Page 25]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+   system is discussed in detail in RFC 850.  It runs on most versions

+   of UNIX and on many other operating systems, and is customarily

+   distributed without charge.

+

+   USENET uses a spooling area on the UNIX host to store news articles,

+   one per file. Each article consists of a series of heading text,

+   which contain the sender's identification and organizational

+   affiliation, timestamps, electronic mail reply paths, subject,

+   newsgroup (subject category), and the like.  A complete news article

+   is reproduced in its entirety below.  Please consult RFC 850 for more

+   details.

+

+      Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site

+      sdcsvax.UUCP

+      Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp

+      Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek

+      !honman

+      From: honman@unitek.uucp (Man Wong)

+      Newsgroups: net.unix-wizards

+      Subject: foreground -> background ?

+      Message-ID: <167@unitek.uucp>

+      Date: 25 Sep 85 23:51:52 GMT

+      Date-Received: 29 Sep 85 09:54:48 GMT

+      Reply-To: honman@unitek.UUCP (Hon-Man Wong)

+      Distribution: net.all

+      Organization: Unitek Technologies Corporation

+      Lines: 12

+

+      I have a process (C program) which generates a child and waits for

+      it to return.  What I would like to do is to be able to run the

+      child process interactively for a while before kicking itself into

+      the background so I can return to the parent process (while the

+      child process is RUNNING in the background).  Can it be done?  And

+      if it can, how?

+

+      Please reply by E-mail.  Thanks in advance.

+

+      Hon-Man Wong

+

+

+

+

+

+

+

+

+

+

+

+Kantor & Lapsley                                               [Page 26]

+

+

+

+RFC 977                                                    February 1986

+Network News Transfer Protocol

+

+

+5.  References

+

+   [1]  Crocker, D., "Standard for the Format of ARPA Internet Text

+        Messages", RFC-822, Department of Electrical Engineering,

+        University of Delaware, August, 1982.

+

+   [2]  Horton, M., "Standard for Interchange of USENET Messages",

+        RFC-850, USENET Project, June, 1983.

+

+   [3]  Postel, J., "Transmission Control Protocol- DARPA Internet

+        Program Protocol Specification", RFC-793, USC/Information

+        Sciences Institute, September, 1981.

+

+   [4]  Postel, J., "Simple Mail Transfer Protocol", RFC-821,

+        USC/Information Sciences Institute, August, 1982.

+

+6.  Acknowledgements

+

+   The authors wish to express their heartfelt thanks to those many

+   people who contributed to this specification, and especially to Erik

+   Fair and Chuq von Rospach, without whose inspiration this whole thing

+   would not have been necessary.

+

+7.  Notes

+

+   <1> UNIX is a trademark of Bell Laboratories.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+Kantor & Lapsley                                               [Page 27]

+

diff --git a/beos/beos_nameser.h b/beos/beos_nameser.h
new file mode 100644
index 00000000..c20d35bd
--- /dev/null
+++ b/beos/beos_nameser.h
@@ -0,0 +1,597 @@
+/*
+ * Copyright (c) 1983, 1989, 1993
+ *    The Regents of the University of California.  All rights reserved.
+ * 
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ * 	This product includes software developed by the University of
+ * 	California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * 
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * Copyright (c) 1996-1999 by Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM DISCLAIMS
+ * ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL INTERNET SOFTWARE
+ * CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
+ * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
+ * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
+ * ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
+ * SOFTWARE.
+ *//* Copyright (c) 1983, 1989
+ *    The Regents of the University of California.  All rights reserved.
+ * 
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ * 	This product includes software developed by the University of
+ * 	California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * 
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ *	$Id: beos_nameser.h,v 1.1 2004/06/08 03:59:00 rfunk Exp $
+ */
+
+#ifndef _ARPA_NAMESER_H_
+#define _ARPA_NAMESER_H_
+
+#define BIND_4_COMPAT
+
+#include <sys/param.h>
+#include <sys/types.h>
+#include <inttypes.h>
+
+#ifdef	__cplusplus
+# define __BEGIN_DECLS	extern "C" {
+# define __END_DECLS	}
+#else
+# define __BEGIN_DECLS
+# define __END_DECLS
+#endif
+
+/*
+ * revision information.  this is the release date in YYYYMMDD format.
+ * it can change every day so the right thing to do with it is use it
+ * in preprocessor commands such as "#if (__NAMESER > 19931104)".  do not
+ * compare for equality; rather, use it to determine whether your libnameser.a
+ * is new enough to contain a certain feature.
+ */
+
+/* XXXRTH I made this bigger than __BIND in 4.9.5 T6B */
+#define __NAMESER	19961001	/* New interface version stamp. */
+
+/*
+ * Define constants based on RFC 883, RFC 1034, RFC 1035
+ */
+#define NS_PACKETSZ	512	/* maximum packet size */
+#define NS_MAXDNAME	1025	/* maximum domain name */
+#define NS_MAXCDNAME	255	/* maximum compressed domain name */
+#define NS_MAXLABEL	63	/* maximum length of domain label */
+#define NS_HFIXEDSZ	12	/* #/bytes of fixed data in header */
+#define NS_QFIXEDSZ	4	/* #/bytes of fixed data in query */
+#define NS_RRFIXEDSZ	10	/* #/bytes of fixed data in r record */
+#define NS_INT32SZ	4	/* #/bytes of data in a u_int32_t */
+#define NS_INT16SZ	2	/* #/bytes of data in a u_int16_t */
+#define NS_INT8SZ	1	/* #/bytes of data in a u_int8_t */
+#define NS_INADDRSZ	4	/* IPv4 T_A */
+#define NS_IN6ADDRSZ	16	/* IPv6 T_AAAA */
+#define NS_CMPRSFLGS	0xc0	/* Flag bits indicating name compression. */
+#define NS_DEFAULTPORT	53	/* For both TCP and UDP. */
+
+/*
+ * These can be expanded with synonyms, just keep ns_parse.c:ns_parserecord()
+ * in synch with it.
+ */
+typedef enum __ns_sect {
+	ns_s_qd = 0,		/* Query: Question. */
+	ns_s_zn = 0,		/* Update: Zone. */
+	ns_s_an = 1,		/* Query: Answer. */
+	ns_s_pr = 1,		/* Update: Prerequisites. */
+	ns_s_ns = 2,		/* Query: Name servers. */
+	ns_s_ud = 2,		/* Update: Update. */
+	ns_s_ar = 3,		/* Query|Update: Additional records. */
+	ns_s_max = 4
+} ns_sect;
+
+/*
+ * This is a message handle.  It is caller allocated and has no dynamic data.
+ * This structure is intended to be opaque to all but ns_parse.c, thus the
+ * leading _'s on the member names.  Use the accessor functions, not the _'s.
+ */
+typedef struct __ns_msg {
+	const u_char	*_msg, *_eom;
+	u_int16_t	_id, _flags, _counts[ns_s_max];
+	const u_char	*_sections[ns_s_max];
+	ns_sect		_sect;
+	int		_rrnum;
+	const u_char	*_ptr;
+} ns_msg;
+
+/* Private data structure - do not use from outside library. */
+struct _ns_flagdata {  int mask, shift;  };
+extern struct _ns_flagdata _ns_flagdata[];
+
+/* Accessor macros - this is part of the public interface. */
+#define ns_msg_getflag(handle, flag) ( \
+			((handle)._flags & _ns_flagdata[flag].mask) \
+			 >> _ns_flagdata[flag].shift \
+			)
+#define ns_msg_id(handle) ((handle)._id + 0)
+#define ns_msg_base(handle) ((handle)._msg + 0)
+#define ns_msg_end(handle) ((handle)._eom + 0)
+#define ns_msg_size(handle) ((handle)._eom - (handle)._msg)
+#define ns_msg_count(handle, section) ((handle)._counts[section] + 0)
+
+/*
+ * This is a parsed record.  It is caller allocated and has no dynamic data.
+ */
+typedef	struct __ns_rr {
+	char		name[NS_MAXDNAME];	/* XXX need to malloc */
+	u_int16_t	type;
+	u_int16_t	class;
+	u_int32_t	ttl;
+	u_int16_t	rdlength;
+	const u_char	*rdata;
+} ns_rr;
+
+/* Accessor macros - this is part of the public interface. */
+#define ns_rr_name(rr)	(((rr).name[0] != '\0') ? (rr).name : ".")
+#define ns_rr_type(rr)	((rr).type + 0)
+#define ns_rr_class(rr)	((rr).class + 0)
+#define ns_rr_ttl(rr)	((rr).ttl + 0)
+#define ns_rr_rdlen(rr)	((rr).rdlength + 0)
+#define ns_rr_rdata(rr)	((rr).rdata + 0)
+
+/*
+ * These don't have to be in the same order as in the packet flags word,
+ * and they can even overlap in some cases, but they will need to be kept
+ * in synch with ns_parse.c:ns_flagdata[].
+ */
+typedef enum __ns_flag {
+	ns_f_qr,		/* Question/Response. */
+	ns_f_opcode,		/* Operation code. */
+	ns_f_aa,		/* Authoritative Answer. */
+	ns_f_tc,		/* Truncation occurred. */
+	ns_f_rd,		/* Recursion Desired. */
+	ns_f_ra,		/* Recursion Available. */
+	ns_f_z,			/* MBZ. */
+	ns_f_ad,		/* Authentic Data (DNSSEC). */
+	ns_f_cd,		/* Checking Disabled (DNSSEC). */
+	ns_f_rcode,		/* Response code. */
+	ns_f_max
+} ns_flag;
+
+/*
+ * Currently defined opcodes.
+ */
+typedef enum __ns_opcode {
+	ns_o_query = 0,		/* Standard query. */
+	ns_o_iquery = 1,	/* Inverse query (deprecated/unsupported). */
+	ns_o_status = 2,	/* Name server status query (unsupported). */
+				/* Opcode 3 is undefined/reserved. */
+	ns_o_notify = 4,	/* Zone change notification. */
+	ns_o_update = 5,	/* Zone update message. */
+	ns_o_max = 6
+} ns_opcode;
+
+/*
+ * Currently defined response codes.
+ */
+typedef	enum __ns_rcode {
+	ns_r_noerror = 0,	/* No error occurred. */
+	ns_r_formerr = 1,	/* Format error. */
+	ns_r_servfail = 2,	/* Server failure. */
+	ns_r_nxdomain = 3,	/* Name error. */
+	ns_r_notimpl = 4,	/* Unimplemented. */
+	ns_r_refused = 5,	/* Operation refused. */
+	/* these are for BIND_UPDATE */
+	ns_r_yxdomain = 6,	/* Name exists */
+	ns_r_yxrrset = 7,	/* RRset exists */
+	ns_r_nxrrset = 8,	/* RRset does not exist */
+	ns_r_notauth = 9,	/* Not authoritative for zone */
+	ns_r_notzone = 10,	/* Zone of record different from zone section */
+	ns_r_max = 11,
+	/* The following are TSIG extended errors */
+	ns_r_badsig = 16,
+	ns_r_badkey = 17,
+	ns_r_badtime = 18,
+	ns_r_badid = 19
+} ns_rcode;
+
+/* BIND_UPDATE */
+typedef enum __ns_update_operation {
+	ns_uop_delete = 0,
+	ns_uop_add = 1,
+	ns_uop_max = 2
+} ns_update_operation;
+
+/*
+ * This RR-like structure is particular to UPDATE.
+ */
+struct ns_updrec {
+	struct ns_updrec *r_prev;	/* prev record */
+	struct ns_updrec *r_next;	/* next record */
+	u_int8_t	r_section;	/* ZONE/PREREQUISITE/UPDATE */
+	char *		r_dname;	/* owner of the RR */
+	u_int16_t	r_class;	/* class number */
+	u_int16_t	r_type;		/* type number */
+	u_int32_t	r_ttl;		/* time to live */
+	u_char *	r_data;		/* rdata fields as text string */
+	u_int16_t	r_size;		/* size of r_data field */
+	int		r_opcode;	/* type of operation */
+	/* following fields for private use by the resolver/server routines */
+	struct ns_updrec *r_grpnext;	/* next record when grouped */
+	struct databuf *r_dp;		/* databuf to process */
+	struct databuf *r_deldp;	/* databuf's deleted/overwritten */
+	u_int16_t	r_zone;		/* zone number on server */
+};
+typedef struct ns_updrec ns_updrec;
+
+/*
+ * This structure is used for TSIG authenticated messages
+ */
+struct ns_tsig_key {
+        char name[NS_MAXDNAME], alg[NS_MAXDNAME];
+        unsigned char *data;
+        int len;
+};
+typedef struct ns_tsig_key ns_tsig_key;
+
+/*
+ * This structure is used for TSIG authenticated TCP messages
+ */
+struct ns_tcp_tsig_state {
+	int counter;
+	struct dst_key *key;
+	void *ctx;
+	unsigned char sig[NS_PACKETSZ];
+	int siglen;
+};
+typedef struct ns_tcp_tsig_state ns_tcp_tsig_state;
+
+#define NS_TSIG_FUDGE 300
+#define NS_TSIG_TCP_COUNT 100
+#define NS_TSIG_ALG_HMAC_MD5 "HMAC-MD5.SIG-ALG.REG.INT"
+
+#define NS_TSIG_ERROR_NO_TSIG -10
+#define NS_TSIG_ERROR_NO_SPACE -11
+#define NS_TSIG_ERROR_FORMERR -12
+
+/*
+ * Currently defined type values for resources and queries.
+ */
+typedef enum __ns_type {
+	ns_t_invalid = 0,	/* Cookie. */
+	ns_t_a = 1,		/* Host address. */
+	ns_t_ns = 2,		/* Authoritative server. */
+	ns_t_md = 3,		/* Mail destination. */
+	ns_t_mf = 4,		/* Mail forwarder. */
+	ns_t_cname = 5,		/* Canonical name. */
+	ns_t_soa = 6,		/* Start of authority zone. */
+	ns_t_mb = 7,		/* Mailbox domain name. */
+	ns_t_mg = 8,		/* Mail group member. */
+	ns_t_mr = 9,		/* Mail rename name. */
+	ns_t_null = 10,		/* Null resource record. */
+	ns_t_wks = 11,		/* Well known service. */
+	ns_t_ptr = 12,		/* Domain name pointer. */
+	ns_t_hinfo = 13,	/* Host information. */
+	ns_t_minfo = 14,	/* Mailbox information. */
+	ns_t_mx = 15,		/* Mail routing information. */
+	ns_t_txt = 16,		/* Text strings. */
+	ns_t_rp = 17,		/* Responsible person. */
+	ns_t_afsdb = 18,	/* AFS cell database. */
+	ns_t_x25 = 19,		/* X_25 calling address. */
+	ns_t_isdn = 20,		/* ISDN calling address. */
+	ns_t_rt = 21,		/* Router. */
+	ns_t_nsap = 22,		/* NSAP address. */
+	ns_t_nsap_ptr = 23,	/* Reverse NSAP lookup (deprecated). */
+	ns_t_sig = 24,		/* Security signature. */
+	ns_t_key = 25,		/* Security key. */
+	ns_t_px = 26,		/* X.400 mail mapping. */
+	ns_t_gpos = 27,		/* Geographical position (withdrawn). */
+	ns_t_aaaa = 28,		/* Ip6 Address. */
+	ns_t_loc = 29,		/* Location Information. */
+	ns_t_nxt = 30,		/* Next domain (security). */
+	ns_t_eid = 31,		/* Endpoint identifier. */
+	ns_t_nimloc = 32,	/* Nimrod Locator. */
+	ns_t_srv = 33,		/* Server Selection. */
+	ns_t_atma = 34,		/* ATM Address */
+	ns_t_naptr = 35,	/* Naming Authority PoinTeR */
+	ns_t_kx = 36,		/* Key Exchange */
+	ns_t_cert = 37,		/* Certification record */
+	/* Query type values which do not appear in resource records. */
+	ns_t_tsig = 250,	/* Transaction signature. */
+	ns_t_ixfr = 251,	/* Incremental zone transfer. */
+	ns_t_axfr = 252,	/* Transfer zone of authority. */
+	ns_t_mailb = 253,	/* Transfer mailbox records. */
+	ns_t_maila = 254,	/* Transfer mail agent records. */
+	ns_t_any = 255,		/* Wildcard match. */
+	ns_t_zxfr = 256,	/* BIND-specific, nonstandard. */
+	ns_t_max = 65536
+} ns_type;
+
+#define ns_t_rr_p(t) ((t) < 128) /* Can this type appear in an RR? */
+#define ns_t_udp_p(t) ((t) != ns_t_axfr && (t) != ns_t_zxfr)
+#define ns_t_xfr_p(t) ((t) == ns_t_axfr || (t) == ns_t_ixfr || \
+		       (t) == ns_t_zxfr)
+
+/*
+ * Values for class field
+ */
+typedef enum __ns_class {
+	ns_c_invalid = 0,	/* Cookie. */
+	ns_c_in = 1,		/* Internet. */
+	ns_c_2 = 2,		/* unallocated/unsupported. */
+	ns_c_chaos = 3,		/* MIT Chaos-net. */
+	ns_c_hs = 4,		/* MIT Hesiod. */
+	/* Query class values which do not appear in resource records */
+	ns_c_none = 254,	/* for prereq. sections in update requests */
+	ns_c_any = 255,		/* Wildcard match. */
+	ns_c_max = 65536
+} ns_class;
+
+typedef enum __ns_key_types {
+	ns_kt_rsa = 1,		/* key type RSA/MD5 */
+	ns_kt_dh  = 2,		/* Diffie Hellman */
+	ns_kt_dsa = 3,		/* Digital Signature Standard (MANDETORY) */
+	ns_kt_private = 254	/* Private key type starts with OID */
+} ns_key_types;
+
+typedef enum __ns_cert_types {
+	cert_t_pkix = 1,	/* PKIX (X.509v3) */
+	cert_t_spki = 2,	/* SPKI */
+	cert_t_pgp  = 3,	/* PGP */
+	cert_t_url  = 253,	/* URL private type */
+	cert_t_oid  = 254	/* OID private type */
+} ns_cert_types;
+
+/*
+ * Flags field of the KEY RR rdata
+ */
+#define	NS_KEY_TYPEMASK		0xC000	/* Mask for "type" bits */
+#define	NS_KEY_TYPE_AUTH_CONF	0x0000	/* Key usable for both */
+#define	NS_KEY_TYPE_CONF_ONLY	0x8000	/* Key usable for confidentiality */
+#define	NS_KEY_TYPE_AUTH_ONLY	0x4000	/* Key usable for authentication */
+#define	NS_KEY_TYPE_NO_KEY	0xC000	/* No key usable for either; no key */
+/* The type bits can also be interpreted independently, as single bits: */
+#define	NS_KEY_NO_AUTH		0x8000	/* Key unusable for authentication */
+#define	NS_KEY_NO_CONF		0x4000	/* Key unusable for confidentiality */
+#define	NS_KEY_RESERVED2	0x2000	/* Security is *mandatory* if bit=0 */
+#define	NS_KEY_EXTENDED_FLAGS	0x1000	/* reserved - must be zero */
+#define	NS_KEY_RESERVED4	0x0800  /* reserved - must be zero */
+#define	NS_KEY_RESERVED5	0x0400  /* reserved - must be zero */
+#define	NS_KEY_NAME_TYPE	0x0300	/* these bits determine the type */
+#define	NS_KEY_NAME_USER	0x0000	/* key is assoc. with user */
+#define	NS_KEY_NAME_ENTITY	0x0200	/* key is assoc. with entity eg host */
+#define	NS_KEY_NAME_ZONE	0x0100	/* key is zone key */
+#define	NS_KEY_NAME_RESERVED	0x0300	/* reserved meaning */
+#define	NS_KEY_RESERVED8	0x0080  /* reserved - must be zero */
+#define	NS_KEY_RESERVED9	0x0040  /* reserved - must be zero */
+#define	NS_KEY_RESERVED10	0x0020  /* reserved - must be zero */
+#define	NS_KEY_RESERVED11	0x0010  /* reserved - must be zero */
+#define	NS_KEY_SIGNATORYMASK	0x000F	/* key can sign RR's of same name */
+
+#define	NS_KEY_RESERVED_BITMASK ( NS_KEY_RESERVED2 | \
+				  NS_KEY_RESERVED4 | \
+				  NS_KEY_RESERVED5 | \
+				  NS_KEY_RESERVED8 | \
+				  NS_KEY_RESERVED9 | \
+				  NS_KEY_RESERVED10 | \
+				  NS_KEY_RESERVED11 )
+
+#define NS_KEY_RESERVED_BITMASK2 0xFFFF /* no bits defined here */
+
+/* The Algorithm field of the KEY and SIG RR's is an integer, {1..254} */
+#define	NS_ALG_MD5RSA		1	/* MD5 with RSA */
+#define	NS_ALG_DH               2	/* Diffie Hellman KEY */
+#define	NS_ALG_DSA              3	/* DSA KEY */
+#define	NS_ALG_DSS              NS_ALG_DSA
+#define	NS_ALG_EXPIRE_ONLY	253	/* No alg, no security */
+#define	NS_ALG_PRIVATE_OID	254	/* Key begins with OID giving alg */
+
+/* Protocol values  */
+/* value 0 is reserved */
+#define NS_KEY_PROT_TLS         1
+#define NS_KEY_PROT_EMAIL       2
+#define NS_KEY_PROT_DNSSEC      3
+#define NS_KEY_PROT_IPSEC       4
+#define NS_KEY_PROT_ANY		255
+
+/* Signatures */
+#define	NS_MD5RSA_MIN_BITS	 512	/* Size of a mod or exp in bits */
+#define	NS_MD5RSA_MAX_BITS	2552
+	/* Total of binary mod and exp */
+#define	NS_MD5RSA_MAX_BYTES	((NS_MD5RSA_MAX_BITS+7/8)*2+3)
+	/* Max length of text sig block */
+#define	NS_MD5RSA_MAX_BASE64	(((NS_MD5RSA_MAX_BYTES+2)/3)*4)
+#define NS_MD5RSA_MIN_SIZE	((NS_MD5RSA_MIN_BITS+7)/8)
+#define NS_MD5RSA_MAX_SIZE	((NS_MD5RSA_MAX_BITS+7)/8)
+
+#define NS_DSA_SIG_SIZE         41
+#define NS_DSA_MIN_SIZE         213
+#define NS_DSA_MAX_BYTES        405
+
+/* Offsets into SIG record rdata to find various values */
+#define	NS_SIG_TYPE	0	/* Type flags */
+#define	NS_SIG_ALG	2	/* Algorithm */
+#define	NS_SIG_LABELS	3	/* How many labels in name */
+#define	NS_SIG_OTTL	4	/* Original TTL */
+#define	NS_SIG_EXPIR	8	/* Expiration time */
+#define	NS_SIG_SIGNED	12	/* Signature time */
+#define	NS_SIG_FOOT	16	/* Key footprint */
+#define	NS_SIG_SIGNER	18	/* Domain name of who signed it */
+
+/* How RR types are represented as bit-flags in NXT records */
+#define	NS_NXT_BITS 8
+#define	NS_NXT_BIT_SET(  n,p) (p[(n)/NS_NXT_BITS] |=  (0x80>>((n)%NS_NXT_BITS)))
+#define	NS_NXT_BIT_CLEAR(n,p) (p[(n)/NS_NXT_BITS] &= ~(0x80>>((n)%NS_NXT_BITS)))
+#define	NS_NXT_BIT_ISSET(n,p) (p[(n)/NS_NXT_BITS] &   (0x80>>((n)%NS_NXT_BITS)))
+#define NS_NXT_MAX 127
+
+/*
+ * Inline versions of get/put short/long.  Pointer is advanced.
+ */
+#define NS_GET16(s, cp) { \
+	register u_char *t_cp = (u_char *)(cp); \
+	(s) = ((u_int16_t)t_cp[0] << 8) \
+	    | ((u_int16_t)t_cp[1]) \
+	    ; \
+	(cp) += NS_INT16SZ; \
+}
+
+#define NS_GET32(l, cp) { \
+	register u_char *t_cp = (u_char *)(cp); \
+	(l) = ((u_int32_t)t_cp[0] << 24) \
+	    | ((u_int32_t)t_cp[1] << 16) \
+	    | ((u_int32_t)t_cp[2] << 8) \
+	    | ((u_int32_t)t_cp[3]) \
+	    ; \
+	(cp) += NS_INT32SZ; \
+}
+
+#define NS_PUT16(s, cp) { \
+	register u_int16_t t_s = (u_int16_t)(s); \
+	register u_char *t_cp = (u_char *)(cp); \
+	*t_cp++ = t_s >> 8; \
+	*t_cp   = t_s; \
+	(cp) += NS_INT16SZ; \
+}
+
+#define NS_PUT32(l, cp) { \
+	register u_int32_t t_l = (u_int32_t)(l); \
+	register u_char *t_cp = (u_char *)(cp); \
+	*t_cp++ = t_l >> 24; \
+	*t_cp++ = t_l >> 16; \
+	*t_cp++ = t_l >> 8; \
+	*t_cp   = t_l; \
+	(cp) += NS_INT32SZ; \
+}
+
+/*
+ * ANSI C identifier hiding.
+ */
+#define ns_get16		__ns_get16
+#define ns_get32		__ns_get32
+#define ns_put16		__ns_put16
+#define ns_put32		__ns_put32
+#define ns_initparse		__ns_initparse
+#define ns_skiprr		__ns_skiprr
+#define ns_parserr		__ns_parserr
+#define	ns_sprintrr		__ns_sprintrr
+#define	ns_sprintrrf		__ns_sprintrrf
+#define	ns_format_ttl		__ns_format_ttl
+#define	ns_parse_ttl		__ns_parse_ttl
+#define	ns_name_ntol		__ns_name_ntol
+#define	ns_name_ntop		__ns_name_ntop
+#define	ns_name_pton		__ns_name_pton
+#define	ns_name_unpack		__ns_name_unpack
+#define	ns_name_pack		__ns_name_pack
+#define	ns_name_compress	__ns_name_compress
+#define	ns_name_uncompress	__ns_name_uncompress
+#define	ns_name_skip		__ns_name_skip
+#define	ns_sign			__ns_sign
+#define	ns_sign_tcp		__ns_sign_tcp
+#define	ns_sign_tcp_init	__ns_sign_tcp_init
+#define ns_find_tsig		__ns_find_tsig
+#define	ns_verify		__ns_verify
+#define	ns_verify_tcp		__ns_verify_tcp
+#define	ns_verify_tcp_init	__ns_verify_tcp_init
+
+__BEGIN_DECLS
+u_int		ns_get16 __P((const u_char *));
+u_long		ns_get32 __P((const u_char *));
+void		ns_put16 __P((u_int, u_char *));
+void		ns_put32 __P((u_long, u_char *));
+int		ns_initparse __P((const u_char *, int, ns_msg *));
+int		ns_skiprr __P((const u_char *, const u_char *, ns_sect, int));
+int		ns_parserr __P((ns_msg *, ns_sect, int, ns_rr *));
+int		ns_sprintrr __P((const ns_msg *, const ns_rr *,
+				 const char *, const char *, char *, size_t));
+int		ns_sprintrrf __P((const u_char *, size_t, const char *,
+				  ns_class, ns_type, u_long, const u_char *,
+				  size_t, const char *, const char *,
+				  char *, size_t));
+int		ns_format_ttl __P((u_long, char *, size_t));
+int		ns_parse_ttl __P((const char *, u_long *));
+int		ns_name_ntol __P((const u_char *, u_char *, size_t));
+int		ns_name_ntop __P((const u_char *, char *, size_t));
+int		ns_name_pton __P((const char *, u_char *, size_t));
+int		ns_name_unpack __P((const u_char *, const u_char *,
+				    const u_char *, u_char *, size_t));
+int		ns_name_pack __P((const u_char *, u_char *, int,
+				  const u_char **, const u_char **));
+int		ns_name_uncompress __P((const u_char *, const u_char *,
+					const u_char *, char *, size_t));
+int		ns_name_compress __P((const char *, u_char *, size_t,
+				      const u_char **, const u_char **));
+int		ns_name_skip __P((const u_char **, const u_char *));
+int		ns_sign __P((u_char *, int *, int, int, void *,
+			     const u_char *, int, u_char *, int *, time_t));
+int		ns_sign_tcp __P((u_char *, int *, int, int,
+				 ns_tcp_tsig_state *, int));
+int		ns_sign_tcp_init __P((void *, const u_char *, int,
+					ns_tcp_tsig_state *));
+u_char		*ns_find_tsig __P((u_char *, u_char *));
+int		ns_verify __P((u_char *, int *, void *,
+			       const u_char *, int, u_char *, int *,
+			       time_t *, int));
+int		ns_verify_tcp __P((u_char *, int *, ns_tcp_tsig_state *, int));
+int		ns_verify_tcp_init __P((void *, const u_char *, int,
+					ns_tcp_tsig_state *));
+__END_DECLS
+
+#ifdef BIND_4_COMPAT
+#include "beos_nameser_compat.h"
+#endif
+
+#endif /* !_ARPA_NAMESER_H_ */
diff --git a/beos/beos_nameser_compat.h b/beos/beos_nameser_compat.h
new file mode 100644
index 00000000..375b4b02
--- /dev/null
+++ b/beos/beos_nameser_compat.h
@@ -0,0 +1,229 @@
+/* Copyright (c) 1983, 1989
+ *    The Regents of the University of California.  All rights reserved.
+ * 
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ * 	This product includes software developed by the University of
+ * 	California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * 
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ *      from nameser.h	8.1 (Berkeley) 6/2/93
+ *	$Id: beos_nameser_compat.h,v 1.1 2004/06/08 03:59:00 rfunk Exp $
+ */
+
+#ifndef _ARPA_NAMESER_COMPAT_
+#define	_ARPA_NAMESER_COMPAT_
+
+#define	__BIND		19950621	/* (DEAD) interface version stamp. */
+
+#ifndef BYTE_ORDER
+#if (BSD >= 199103)
+# include <machine/endian.h>
+#else
+#ifdef linux
+# include <endian.h>
+#else
+#define	LITTLE_ENDIAN	1234	/* least-significant byte first (vax, pc) */
+#define	BIG_ENDIAN	4321	/* most-significant byte first (IBM, net) */
+#define	PDP_ENDIAN	3412	/* LSB first in word, MSW first in long (pdp)*/
+
+#if defined(vax) || defined(ns32000) || defined(sun386) || defined(i386) || \
+    defined(MIPSEL) || defined(_MIPSEL) || defined(BIT_ZERO_ON_RIGHT) || \
+    defined(__alpha__) || defined(__alpha) || \
+    (defined(__Lynx__) && defined(__x86__))
+#define BYTE_ORDER	LITTLE_ENDIAN
+#endif
+
+#if defined(sel) || defined(pyr) || defined(mc68000) || defined(sparc) || \
+    defined(is68k) || defined(tahoe) || defined(ibm032) || defined(ibm370) || \
+    defined(MIPSEB) || defined(_MIPSEB) || defined(_IBMR2) || defined(DGUX) ||\
+    defined(apollo) || defined(__convex__) || defined(_CRAY) || \
+    defined(__hppa) || defined(__hp9000) || \
+    defined(__hp9000s300) || defined(__hp9000s700) || \
+    defined (BIT_ZERO_ON_LEFT) || defined(m68k) || \
+    (defined(__Lynx__) && \
+     (defined(__68k__) || defined(__sparc__) || defined(__powerpc__)))
+#define BYTE_ORDER	BIG_ENDIAN
+#endif
+#endif /* linux */
+#endif /* BSD */
+#endif /* BYTE_ORDER */
+
+#if !defined(BYTE_ORDER) || \
+    (BYTE_ORDER != BIG_ENDIAN && BYTE_ORDER != LITTLE_ENDIAN && \
+    BYTE_ORDER != PDP_ENDIAN)
+	/* you must determine what the correct bit order is for
+	 * your compiler - the next line is an intentional error
+	 * which will force your compiles to bomb until you fix
+	 * the above macros.
+	 */
+  error "Undefined or invalid BYTE_ORDER";
+#endif
+
+/*
+ * Structure for query header.  The order of the fields is machine- and
+ * compiler-dependent, depending on the byte/bit order and the layout
+ * of bit fields.  We use bit fields only in int variables, as this
+ * is all ANSI requires.  This requires a somewhat confusing rearrangement.
+ */
+
+typedef struct {
+	unsigned	id :16;		/* query identification number */
+#if BYTE_ORDER == BIG_ENDIAN
+			/* fields in third byte */
+	unsigned	qr: 1;		/* response flag */
+	unsigned	opcode: 4;	/* purpose of message */
+	unsigned	aa: 1;		/* authoritive answer */
+	unsigned	tc: 1;		/* truncated message */
+	unsigned	rd: 1;		/* recursion desired */
+			/* fields in fourth byte */
+	unsigned	ra: 1;		/* recursion available */
+	unsigned	unused :1;	/* unused bits (MBZ as of 4.9.3a3) */
+	unsigned	ad: 1;		/* authentic data from named */
+	unsigned	cd: 1;		/* checking disabled by resolver */
+	unsigned	rcode :4;	/* response code */
+#endif
+#if BYTE_ORDER == LITTLE_ENDIAN || BYTE_ORDER == PDP_ENDIAN
+			/* fields in third byte */
+	unsigned	rd :1;		/* recursion desired */
+	unsigned	tc :1;		/* truncated message */
+	unsigned	aa :1;		/* authoritive answer */
+	unsigned	opcode :4;	/* purpose of message */
+	unsigned	qr :1;		/* response flag */
+			/* fields in fourth byte */
+	unsigned	rcode :4;	/* response code */
+	unsigned	cd: 1;		/* checking disabled by resolver */
+	unsigned	ad: 1;		/* authentic data from named */
+	unsigned	unused :1;	/* unused bits (MBZ as of 4.9.3a3) */
+	unsigned	ra :1;		/* recursion available */
+#endif
+			/* remaining bytes */
+	unsigned	qdcount :16;	/* number of question entries */
+	unsigned	ancount :16;	/* number of answer entries */
+	unsigned	nscount :16;	/* number of authority entries */
+	unsigned	arcount :16;	/* number of resource entries */
+} HEADER;
+
+#define PACKETSZ	NS_PACKETSZ
+#define MAXDNAME	NS_MAXDNAME
+#define MAXCDNAME	NS_MAXCDNAME
+#define MAXLABEL	NS_MAXLABEL
+#define	HFIXEDSZ	NS_HFIXEDSZ
+#define QFIXEDSZ	NS_QFIXEDSZ
+#define RRFIXEDSZ	NS_RRFIXEDSZ
+#define	INT32SZ		NS_INT32SZ
+#define	INT16SZ		NS_INT16SZ
+#define	INADDRSZ	NS_INADDRSZ
+#define	IN6ADDRSZ	NS_IN6ADDRSZ
+#define	INDIR_MASK	NS_CMPRSFLGS
+#define NAMESERVER_PORT	NS_DEFAULTPORT
+
+#define S_ZONE		ns_s_zn
+#define S_PREREQ	ns_s_pr
+#define S_UPDATE	ns_s_ud
+#define S_ADDT		ns_s_ar
+
+#define QUERY		ns_o_query
+#define IQUERY		ns_o_iquery
+#define STATUS		ns_o_status
+#define	NS_NOTIFY_OP	ns_o_notify
+#define	NS_UPDATE_OP	ns_o_update
+
+#define NOERROR		ns_r_noerror
+#define FORMERR		ns_r_formerr
+#define SERVFAIL	ns_r_servfail
+#define NXDOMAIN	ns_r_nxdomain
+#define NOTIMP		ns_r_notimpl
+#define REFUSED		ns_r_refused
+#define YXDOMAIN	ns_r_yxdomain
+#define YXRRSET		ns_r_yxrrset
+#define NXRRSET		ns_r_nxrrset
+#define NOTAUTH		ns_r_notauth
+#define NOTZONE		ns_r_notzone
+/*#define BADSIG		ns_r_badsig*/
+/*#define BADKEY		ns_r_badkey*/
+/*#define BADTIME		ns_r_badtime*/
+
+
+#define DELETE		ns_uop_delete
+#define ADD		ns_uop_add
+
+#define T_A		ns_t_a
+#define T_NS		ns_t_ns
+#define T_MD		ns_t_md
+#define T_MF		ns_t_mf
+#define T_CNAME		ns_t_cname
+#define T_SOA		ns_t_soa
+#define T_MB		ns_t_mb
+#define T_MG		ns_t_mg
+#define T_MR		ns_t_mr
+#define T_NULL		ns_t_null
+#define T_WKS		ns_t_wks
+#define T_PTR		ns_t_ptr
+#define T_HINFO		ns_t_hinfo
+#define T_MINFO		ns_t_minfo
+#define T_MX		ns_t_mx
+#define T_TXT		ns_t_txt
+#define	T_RP		ns_t_rp
+#define T_AFSDB		ns_t_afsdb
+#define T_X25		ns_t_x25
+#define T_ISDN		ns_t_isdn
+#define T_RT		ns_t_rt
+#define T_NSAP		ns_t_nsap
+#define T_NSAP_PTR	ns_t_nsap_ptr
+#define	T_SIG		ns_t_sig
+#define	T_KEY		ns_t_key
+#define	T_PX		ns_t_px
+#define	T_GPOS		ns_t_gpos
+#define	T_AAAA		ns_t_aaaa
+#define	T_LOC		ns_t_loc
+#define	T_NXT		ns_t_nxt
+#define	T_EID		ns_t_eid
+#define	T_NIMLOC	ns_t_nimloc
+#define	T_SRV		ns_t_srv
+#define T_ATMA		ns_t_atma
+#define T_NAPTR		ns_t_naptr
+#define	T_TSIG		ns_t_tsig
+#define	T_IXFR		ns_t_ixfr
+#define T_AXFR		ns_t_axfr
+#define T_MAILB		ns_t_mailb
+#define T_MAILA		ns_t_maila
+#define T_ANY		ns_t_any
+
+#define C_IN		ns_c_in
+#define C_CHAOS		ns_c_chaos
+#define C_HS		ns_c_hs
+/* BIND_UPDATE */
+#define C_NONE		ns_c_none
+#define C_ANY		ns_c_any
+
+#define	GETSHORT		NS_GET16
+#define	GETLONG			NS_GET32
+#define	PUTSHORT		NS_PUT16
+#define	PUTLONG			NS_PUT32
+
+#endif /* _ARPA_NAMESER_COMPAT_ */
diff --git a/bighand.png b/bighand.png
new file mode 100644
index 00000000..14a6f5ca
--- /dev/null
+++ b/bighand.png
diff --git a/config.sub b/config.sub
new file mode 100755
index 00000000..c8e77851
--- /dev/null
+++ b/config.sub
@@ -0,0 +1,1268 @@
+#! /bin/sh
+# Configuration validation subroutine script, version 1.1.
+#   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000
+#   Free Software Foundation, Inc.
+#
+# This file is (in principle) common to ALL GNU software.
+# The presence of a machine in this file suggests that SOME GNU software
+# can handle that machine.  It does not imply ALL GNU software can.
+#
+# This file is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330,
+# Boston, MA 02111-1307, USA.
+
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+# Written by Per Bothner <bothner@cygnus.com>.
+# Please send patches to <config-patches@gnu.org>.
+#
+# Configuration subroutine to validate and canonicalize a configuration type.
+# Supply the specified configuration type as an argument.
+# If it is invalid, we print an error message on stderr and exit with code 1.
+# Otherwise, we print the canonical config type on stdout and succeed.
+
+# This file is supposed to be the same for all GNU packages
+# and recognize all the CPU types, system types and aliases
+# that are meaningful with *any* GNU software.
+# Each package is responsible for reporting which valid configurations
+# it does not support.  The user should be able to distinguish
+# a failure to support a valid configuration from a meaningless
+# configuration.
+
+# The goal of this file is to map all the various variations of a given
+# machine specification into a single specification in the form:
+#	CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
+# or in some cases, the newer four-part form:
+#	CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
+# It is wrong to echo any other type of specification.
+
+if [ x$1 = x ]
+then
+	echo Configuration name missing. 1>&2
+	echo "Usage: $0 CPU-MFR-OPSYS" 1>&2
+	echo "or     $0 ALIAS" 1>&2
+	echo where ALIAS is a recognized configuration type. 1>&2
+	exit 1
+fi
+
+# First pass through any local machine types.
+case $1 in
+	*local*)
+		echo $1
+		exit 0
+		;;
+	*)
+	;;
+esac
+
+# Separate what the user gave into CPU-COMPANY and OS or KERNEL-OS (if any).
+# Here we must recognize all the valid KERNEL-OS combinations.
+maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
+case $maybe_os in
+  nto-qnx* | linux-gnu*)
+    os=-$maybe_os
+    basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
+    ;;
+  *)
+    basic_machine=`echo $1 | sed 's/-[^-]*$//'`
+    if [ $basic_machine != $1 ]
+    then os=`echo $1 | sed 's/.*-/-/'`
+    else os=; fi
+    ;;
+esac
+
+### Let's recognize common machines as not being operating systems so
+### that things like config.sub decstation-3100 work.  We also
+### recognize some manufacturers as not being operating systems, so we
+### can provide default operating systems below.
+case $os in
+	-sun*os*)
+		# Prevent following clause from handling this invalid input.
+		;;
+	-dec* | -mips* | -sequent* | -encore* | -pc532* | -sgi* | -sony* | \
+	-att* | -7300* | -3300* | -delta* | -motorola* | -sun[234]* | \
+	-unicom* | -ibm* | -next | -hp | -isi* | -apollo | -altos* | \
+	-convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\
+	-c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
+	-harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \
+	-apple)
+		os=
+		basic_machine=$1
+		;;
+	-sim | -cisco | -oki | -wec | -winbond)
+		os=
+		basic_machine=$1
+		;;
+	-scout)
+		;;
+	-wrs)
+		os=-vxworks
+		basic_machine=$1
+		;;
+	-hiux*)
+		os=-hiuxwe2
+		;;
+	-sco5)
+		os=-sco3.2v5
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-sco4)
+		os=-sco3.2v4
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-sco3.2.[4-9]*)
+		os=`echo $os | sed -e 's/sco3.2./sco3.2v/'`
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-sco3.2v[4-9]*)
+		# Don't forget version if it is 3.2v4 or newer.
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-sco*)
+		os=-sco3.2v2
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-udk*)
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-isc)
+		os=-isc2.2
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-clix*)
+		basic_machine=clipper-intergraph
+		;;
+	-isc*)
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
+		;;
+	-lynx*)
+		os=-lynxos
+		;;
+	-ptx*)
+		basic_machine=`echo $1 | sed -e 's/86-.*/86-sequent/'`
+		;;
+	-windowsnt*)
+		os=`echo $os | sed -e 's/windowsnt/winnt/'`
+		;;
+	-psos*)
+		os=-psos
+		;;
+	-mint | -mint[0-9]*)
+		basic_machine=m68k-atari
+		os=-mint
+		;;
+esac
+
+# Decode aliases for certain CPU-COMPANY combinations.
+case $basic_machine in
+	# Recognize the basic CPU types without company name.
+	# Some are omitted here because they have special meanings below.
+	tahoe | i860 | ia64 | m32r | m68k | m68000 | m88k | ns32k | arc | arm \
+		| arme[lb] | pyramid | mn10200 | mn10300 | tron | a29k \
+		| 580 | i960 | h8300 \
+		| x86 | ppcbe | mipsbe | mipsle | shbe | shle | armbe | armle \
+		| hppa | hppa1.0 | hppa1.1 | hppa2.0 | hppa2.0w | hppa2.0n \
+		| hppa64 \
+		| alpha | alphaev[4-8] | alphaev56 | alphapca5[67] \
+		| alphaev6[78] \
+		| we32k | ns16k | clipper | i370 | sh | powerpc | powerpcle \
+		| 1750a | dsp16xx | pdp11 | mips16 | mips64 | mipsel | mips64el \
+		| mips64orion | mips64orionel | mipstx39 | mipstx39el \
+		| mips64vr4300 | mips64vr4300el | mips64vr4100 | mips64vr4100el \
+		| mips64vr5000 | miprs64vr5000el | mcore \
+		| sparc | sparclet | sparclite | sparc64 | sparcv9 | v850 | c4x \
+		| thumb | d10v | fr30 | avr)
+		basic_machine=$basic_machine-unknown
+		;;
+	m88110 | m680[12346]0 | m683?2 | m68360 | m5200 | z8k | v70 | h8500 | w65 | pj | pjl)
+		;;
+
+	# We use `pc' rather than `unknown'
+	# because (1) that's what they normally are, and
+	# (2) the word "unknown" tends to confuse beginning users.
+	i[34567]86)
+	  basic_machine=$basic_machine-pc
+	  ;;
+	# Object if more than one company name word.
+	*-*-*)
+		echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
+		exit 1
+		;;
+	# Recognize the basic CPU types with company name.
+	# FIXME: clean up the formatting here.
+	vax-* | tahoe-* | i[34567]86-* | i860-* | ia64-* | m32r-* | m68k-* | m68000-* \
+	      | m88k-* | sparc-* | ns32k-* | fx80-* | arc-* | arm-* | c[123]* \
+	      | mips-* | pyramid-* | tron-* | a29k-* | romp-* | rs6000-* \
+	      | power-* | none-* | 580-* | cray2-* | h8300-* | h8500-* | i960-* \
+	      | xmp-* | ymp-* \
+	      | x86-* | ppcbe-* | mipsbe-* | mipsle-* | shbe-* | shle-* | armbe-* | armle-* \
+	      | hppa-* | hppa1.0-* | hppa1.1-* | hppa2.0-* | hppa2.0w-* \
+	      | hppa2.0n-* | hppa64-* \
+	      | alpha-* | alphaev[4-8]-* | alphaev56-* | alphapca5[67]-* \
+	      | alphaev6[78]-* \
+	      | we32k-* | cydra-* | ns16k-* | pn-* | np1-* | xps100-* \
+	      | clipper-* | orion-* \
+	      | sparclite-* | pdp11-* | sh-* | powerpc-* | powerpcle-* \
+	      | sparc64-* | sparcv9-* | sparc86x-* | mips16-* | mips64-* | mipsel-* \
+	      | mips64el-* | mips64orion-* | mips64orionel-* \
+	      | mips64vr4100-* | mips64vr4100el-* | mips64vr4300-* | mips64vr4300el-* \
+	      | mipstx39-* | mipstx39el-* | mcore-* \
+	      | f301-* | armv*-* | s390-* | sv1-* | t3e-* \
+	      | m88110-* | m680[01234]0-* | m683?2-* | m68360-* | z8k-* | d10v-* \
+	      | thumb-* | v850-* | d30v-* | tic30-* | c30-* | fr30-* \
+	      | bs2000-*)
+		;;
+	# Recognize the various machine names and aliases which stand
+	# for a CPU type and a company and sometimes even an OS.
+	386bsd)
+		basic_machine=i386-unknown
+		os=-bsd
+		;;
+	3b1 | 7300 | 7300-att | att-7300 | pc7300 | safari | unixpc)
+		basic_machine=m68000-att
+		;;
+	3b*)
+		basic_machine=we32k-att
+		;;
+	a29khif)
+		basic_machine=a29k-amd
+		os=-udi
+		;;
+	adobe68k)
+		basic_machine=m68010-adobe
+		os=-scout
+		;;
+	alliant | fx80)
+		basic_machine=fx80-alliant
+		;;
+	altos | altos3068)
+		basic_machine=m68k-altos
+		;;
+	am29k)
+		basic_machine=a29k-none
+		os=-bsd
+		;;
+	amdahl)
+		basic_machine=580-amdahl
+		os=-sysv
+		;;
+	amiga | amiga-*)
+		basic_machine=m68k-cbm
+		;;
+	amigaos | amigados)
+		basic_machine=m68k-cbm
+		os=-amigaos
+		;;
+	amigaunix | amix)
+		basic_machine=m68k-cbm
+		os=-sysv4
+		;;
+	apollo68)
+		basic_machine=m68k-apollo
+		os=-sysv
+		;;
+	apollo68bsd)
+		basic_machine=m68k-apollo
+		os=-bsd
+		;;
+	aux)
+		basic_machine=m68k-apple
+		os=-aux
+		;;
+	balance)
+		basic_machine=ns32k-sequent
+		os=-dynix
+		;;
+	convex-c1)
+		basic_machine=c1-convex
+		os=-bsd
+		;;
+	convex-c2)
+		basic_machine=c2-convex
+		os=-bsd
+		;;
+	convex-c32)
+		basic_machine=c32-convex
+		os=-bsd
+		;;
+	convex-c34)
+		basic_machine=c34-convex
+		os=-bsd
+		;;
+	convex-c38)
+		basic_machine=c38-convex
+		os=-bsd
+		;;
+	cray | ymp)
+		basic_machine=ymp-cray
+		os=-unicos
+		;;
+	cray2)
+		basic_machine=cray2-cray
+		os=-unicos
+		;;
+	[ctj]90-cray)
+		basic_machine=c90-cray
+		os=-unicos
+		;;
+	crds | unos)
+		basic_machine=m68k-crds
+		;;
+	da30 | da30-*)
+		basic_machine=m68k-da30
+		;;
+	decstation | decstation-3100 | pmax | pmax-* | pmin | dec3100 | decstatn)
+		basic_machine=mips-dec
+		;;
+	delta | 3300 | motorola-3300 | motorola-delta \
+	      | 3300-motorola | delta-motorola)
+		basic_machine=m68k-motorola
+		;;
+	delta88)
+		basic_machine=m88k-motorola
+		os=-sysv3
+		;;
+	dpx20 | dpx20-*)
+		basic_machine=rs6000-bull
+		os=-bosx
+		;;
+	dpx2* | dpx2*-bull)
+		basic_machine=m68k-bull
+		os=-sysv3
+		;;
+	ebmon29k)
+		basic_machine=a29k-amd
+		os=-ebmon
+		;;
+	elxsi)
+		basic_machine=elxsi-elxsi
+		os=-bsd
+		;;
+	encore | umax | mmax)
+		basic_machine=ns32k-encore
+		;;
+	es1800 | OSE68k | ose68k | ose | OSE)
+		basic_machine=m68k-ericsson
+		os=-ose
+		;;
+	fx2800)
+		basic_machine=i860-alliant
+		;;
+	genix)
+		basic_machine=ns32k-ns
+		;;
+	gmicro)
+		basic_machine=tron-gmicro
+		os=-sysv
+		;;
+	h3050r* | hiux*)
+		basic_machine=hppa1.1-hitachi
+		os=-hiuxwe2
+		;;
+	h8300hms)
+		basic_machine=h8300-hitachi
+		os=-hms
+		;;
+	h8300xray)
+		basic_machine=h8300-hitachi
+		os=-xray
+		;;
+	h8500hms)
+		basic_machine=h8500-hitachi
+		os=-hms
+		;;
+	harris)
+		basic_machine=m88k-harris
+		os=-sysv3
+		;;
+	hp300-*)
+		basic_machine=m68k-hp
+		;;
+	hp300bsd)
+		basic_machine=m68k-hp
+		os=-bsd
+		;;
+	hp300hpux)
+		basic_machine=m68k-hp
+		os=-hpux
+		;;
+	hp3k9[0-9][0-9] | hp9[0-9][0-9])
+		basic_machine=hppa1.0-hp
+		;;
+	hp9k2[0-9][0-9] | hp9k31[0-9])
+		basic_machine=m68000-hp
+		;;
+	hp9k3[2-9][0-9])
+		basic_machine=m68k-hp
+		;;
+	hp9k6[0-9][0-9] | hp6[0-9][0-9])
+		basic_machine=hppa1.0-hp
+		;;
+	hp9k7[0-79][0-9] | hp7[0-79][0-9])
+		basic_machine=hppa1.1-hp
+		;;
+	hp9k78[0-9] | hp78[0-9])
+		# FIXME: really hppa2.0-hp
+		basic_machine=hppa1.1-hp
+		;;
+	hp9k8[67]1 | hp8[67]1 | hp9k80[24] | hp80[24] | hp9k8[78]9 | hp8[78]9 | hp9k893 | hp893)
+		# FIXME: really hppa2.0-hp
+		basic_machine=hppa1.1-hp
+		;;
+	hp9k8[0-9][13679] | hp8[0-9][13679])
+		basic_machine=hppa1.1-hp
+		;;
+	hp9k8[0-9][0-9] | hp8[0-9][0-9])
+		basic_machine=hppa1.0-hp
+		;;
+	hppa-next)
+		os=-nextstep3
+		;;
+	hppaosf)
+		basic_machine=hppa1.1-hp
+		os=-osf
+		;;
+	hppro)
+		basic_machine=hppa1.1-hp
+		os=-proelf
+		;;
+	i370-ibm* | ibm*)
+		basic_machine=i370-ibm
+		;;
+# I'm not sure what "Sysv32" means.  Should this be sysv3.2?
+	i[34567]86v32)
+		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
+		os=-sysv32
+		;;
+	i[34567]86v4*)
+		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
+		os=-sysv4
+		;;
+	i[34567]86v)
+		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
+		os=-sysv
+		;;
+	i[34567]86sol2)
+		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
+		os=-solaris2
+		;;
+	i386mach)
+		basic_machine=i386-mach
+		os=-mach
+		;;
+	i386-vsta | vsta)
+		basic_machine=i386-unknown
+		os=-vsta
+		;;
+	i386-go32 | go32)
+		basic_machine=i386-unknown
+		os=-go32
+		;;
+	i386-mingw32 | mingw32)
+		basic_machine=i386-unknown
+		os=-mingw32
+		;;
+	iris | iris4d)
+		basic_machine=mips-sgi
+		case $os in
+		    -irix*)
+			;;
+		    *)
+			os=-irix4
+			;;
+		esac
+		;;
+	isi68 | isi)
+		basic_machine=m68k-isi
+		os=-sysv
+		;;
+	m88k-omron*)
+		basic_machine=m88k-omron
+		;;
+	magnum | m3230)
+		basic_machine=mips-mips
+		os=-sysv
+		;;
+	merlin)
+		basic_machine=ns32k-utek
+		os=-sysv
+		;;
+	miniframe)
+		basic_machine=m68000-convergent
+		;;
+	*mint | -mint[0-9]* | *MiNT | *MiNT[0-9]*)
+		basic_machine=m68k-atari
+		os=-mint
+		;;
+	mipsel*-linux*)
+		basic_machine=mipsel-unknown
+		os=-linux-gnu
+		;;
+	mips*-linux*)
+		basic_machine=mips-unknown
+		os=-linux-gnu
+		;;
+	mips3*-*)
+		basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`
+		;;
+	mips3*)
+		basic_machine=`echo $basic_machine | sed -e 's/mips3/mips64/'`-unknown
+		;;
+	mmix*)
+		basic_machine=mmix-knuth
+		os=-mmixware
+		;;
+	monitor)
+		basic_machine=m68k-rom68k
+		os=-coff
+		;;
+	msdos)
+		basic_machine=i386-unknown
+		os=-msdos
+		;;
+	mvs)
+		basic_machine=i370-ibm
+		os=-mvs
+		;;
+	ncr3000)
+		basic_machine=i486-ncr
+		os=-sysv4
+		;;
+	netbsd386)
+		basic_machine=i386-unknown
+		os=-netbsd
+		;;
+	netwinder)
+		basic_machine=armv4l-rebel
+		os=-linux
+		;;
+	news | news700 | news800 | news900)
+		basic_machine=m68k-sony
+		os=-newsos
+		;;
+	news1000)
+		basic_machine=m68030-sony
+		os=-newsos
+		;;
+	news-3600 | risc-news)
+		basic_machine=mips-sony
+		os=-newsos
+		;;
+	necv70)
+		basic_machine=v70-nec
+		os=-sysv
+		;;
+	next | m*-next )
+		basic_machine=m68k-next
+		case $os in
+		    -nextstep* )
+			;;
+		    -ns2*)
+		      os=-nextstep2
+			;;
+		    *)
+		      os=-nextstep3
+			;;
+		esac
+		;;
+	nh3000)
+		basic_machine=m68k-harris
+		os=-cxux
+		;;
+	nh[45]000)
+		basic_machine=m88k-harris
+		os=-cxux
+		;;
+	nindy960)
+		basic_machine=i960-intel
+		os=-nindy
+		;;
+	mon960)
+		basic_machine=i960-intel
+		os=-mon960
+		;;
+	np1)
+		basic_machine=np1-gould
+		;;
+	nsr-tandem)
+		basic_machine=nsr-tandem
+		;;
+	op50n-* | op60c-*)
+		basic_machine=hppa1.1-oki
+		os=-proelf
+		;;
+	OSE68000 | ose68000)
+		basic_machine=m68000-ericsson
+		os=-ose
+		;;
+	os68k)
+		basic_machine=m68k-none
+		os=-os68k
+		;;
+	pa-hitachi)
+		basic_machine=hppa1.1-hitachi
+		os=-hiuxwe2
+		;;
+	paragon)
+		basic_machine=i860-intel
+		os=-osf
+		;;
+	pbd)
+		basic_machine=sparc-tti
+		;;
+	pbb)
+		basic_machine=m68k-tti
+		;;
+        pc532 | pc532-*)
+		basic_machine=ns32k-pc532
+		;;
+	pentium | p5 | k5 | k6 | nexen)
+		basic_machine=i586-pc
+		;;
+	pentiumpro | p6 | 6x86)
+		basic_machine=i686-pc
+		;;
+	pentiumii | pentium2)
+		basic_machine=i786-pc
+		;;
+	pentium-* | p5-* | k5-* | k6-* | nexen-*)
+		basic_machine=i586-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	pentiumpro-* | p6-* | 6x86-*)
+		basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	pentiumii-* | pentium2-*)
+		basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	pn)
+		basic_machine=pn-gould
+		;;
+	power)	basic_machine=rs6000-ibm
+		;;
+	ppc)	basic_machine=powerpc-unknown
+	        ;;
+	ppc-*)	basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	ppcle | powerpclittle | ppc-le | powerpc-little)
+		basic_machine=powerpcle-unknown
+	        ;;
+	ppcle-* | powerpclittle-*)
+		basic_machine=powerpcle-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
+	ps2)
+		basic_machine=i386-ibm
+		;;
+	rom68k)
+		basic_machine=m68k-rom68k
+		os=-coff
+		;;
+	rm[46]00)
+		basic_machine=mips-siemens
+		;;
+	rtpc | rtpc-*)
+		basic_machine=romp-ibm
+		;;
+	sa29200)
+		basic_machine=a29k-amd
+		os=-udi
+		;;
+	sequent)
+		basic_machine=i386-sequent
+		;;
+	sh)
+		basic_machine=sh-hitachi
+		os=-hms
+		;;
+	sparclite-wrs)
+		basic_machine=sparclite-wrs
+		os=-vxworks
+		;;
+	sps7)
+		basic_machine=m68k-bull
+		os=-sysv2
+		;;
+	spur)
+		basic_machine=spur-unknown
+		;;
+	st2000)
+		basic_machine=m68k-tandem
+		;;
+	stratus)
+		basic_machine=i860-stratus
+		os=-sysv4
+		;;
+	sun2)
+		basic_machine=m68000-sun
+		;;
+	sun2os3)
+		basic_machine=m68000-sun
+		os=-sunos3
+		;;
+	sun2os4)
+		basic_machine=m68000-sun
+		os=-sunos4
+		;;
+	sun3os3)
+		basic_machine=m68k-sun
+		os=-sunos3
+		;;
+	sun3os4)
+		basic_machine=m68k-sun
+		os=-sunos4
+		;;
+	sun4os3)
+		basic_machine=sparc-sun
+		os=-sunos3
+		;;
+	sun4os4)
+		basic_machine=sparc-sun
+		os=-sunos4
+		;;
+	sun4sol2)
+		basic_machine=sparc-sun
+		os=-solaris2
+		;;
+	sun3 | sun3-*)
+		basic_machine=m68k-sun
+		;;
+	sun4)
+		basic_machine=sparc-sun
+		;;
+	sun386 | sun386i | roadrunner)
+		basic_machine=i386-sun
+		;;
+	sv1)
+		basic_machine=sv1-cray
+		os=-unicos
+		;;
+	symmetry)
+		basic_machine=i386-sequent
+		os=-dynix
+		;;
+	t3e)
+		basic_machine=t3e-cray
+		os=-unicos
+		;;
+	tx39)
+		basic_machine=mipstx39-unknown
+		;;
+	tx39el)
+		basic_machine=mipstx39el-unknown
+		;;
+	tower | tower-32)
+		basic_machine=m68k-ncr
+		;;
+	udi29k)
+		basic_machine=a29k-amd
+		os=-udi
+		;;
+	ultra3)
+		basic_machine=a29k-nyu
+		os=-sym1
+		;;
+	v810 | necv810)
+		basic_machine=v810-nec
+		os=-none
+		;;
+	vaxv)
+		basic_machine=vax-dec
+		os=-sysv
+		;;
+	vms)
+		basic_machine=vax-dec
+		os=-vms
+		;;
+	vpp*|vx|vx-*)
+               basic_machine=f301-fujitsu
+               ;;
+	vxworks960)
+		basic_machine=i960-wrs
+		os=-vxworks
+		;;
+	vxworks68)
+		basic_machine=m68k-wrs
+		os=-vxworks
+		;;
+	vxworks29k)
+		basic_machine=a29k-wrs
+		os=-vxworks
+		;;
+	w65*)
+		basic_machine=w65-wdc
+		os=-none
+		;;
+	w89k-*)
+		basic_machine=hppa1.1-winbond
+		os=-proelf
+		;;
+	xmp)
+		basic_machine=xmp-cray
+		os=-unicos
+		;;
+        xps | xps100)
+		basic_machine=xps100-honeywell
+		;;
+	z8k-*-coff)
+		basic_machine=z8k-unknown
+		os=-sim
+		;;
+	none)
+		basic_machine=none-none
+		os=-none
+		;;
+
+# Here we handle the default manufacturer of certain CPU types.  It is in
+# some cases the only manufacturer, in others, it is the most popular.
+	w89k)
+		basic_machine=hppa1.1-winbond
+		;;
+	op50n)
+		basic_machine=hppa1.1-oki
+		;;
+	op60c)
+		basic_machine=hppa1.1-oki
+		;;
+	mips)
+		if [ x$os = x-linux-gnu ]; then
+			basic_machine=mips-unknown
+		else
+			basic_machine=mips-mips
+		fi
+		;;
+	romp)
+		basic_machine=romp-ibm
+		;;
+	rs6000)
+		basic_machine=rs6000-ibm
+		;;
+	vax)
+		basic_machine=vax-dec
+		;;
+	pdp11)
+		basic_machine=pdp11-dec
+		;;
+	we32k)
+		basic_machine=we32k-att
+		;;
+	sparc | sparcv9)
+		basic_machine=sparc-sun
+		;;
+        cydra)
+		basic_machine=cydra-cydrome
+		;;
+	orion)
+		basic_machine=orion-highlevel
+		;;
+	orion105)
+		basic_machine=clipper-highlevel
+		;;
+	mac | mpw | mac-mpw)
+		basic_machine=m68k-apple
+		;;
+	pmac | pmac-mpw)
+		basic_machine=powerpc-apple
+		;;
+	c4x*)
+		basic_machine=c4x-none
+		os=-coff
+		;;
+	*)
+		echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2
+		exit 1
+		;;
+esac
+
+# Here we canonicalize certain aliases for manufacturers.
+case $basic_machine in
+	*-digital*)
+		basic_machine=`echo $basic_machine | sed 's/digital.*/dec/'`
+		;;
+	*-commodore*)
+		basic_machine=`echo $basic_machine | sed 's/commodore.*/cbm/'`
+		;;
+	*)
+		;;
+esac
+
+# Decode manufacturer-specific aliases for certain operating systems.
+
+if [ x"$os" != x"" ]
+then
+case $os in
+        # First match some system type aliases
+        # that might get confused with valid system types.
+	# -solaris* is a basic system type, with this one exception.
+	-solaris1 | -solaris1.*)
+		os=`echo $os | sed -e 's|solaris1|sunos4|'`
+		;;
+	-solaris)
+		os=-solaris2
+		;;
+	-svr4*)
+		os=-sysv4
+		;;
+	-unixware*)
+		os=-sysv4.2uw
+		;;
+	-gnu/linux*)
+		os=`echo $os | sed -e 's|gnu/linux|linux-gnu|'`
+		;;
+	# First accept the basic system types.
+	# The portable systems comes first.
+	# Each alternative MUST END IN A *, to match a version number.
+	# -sysv* is not here because it comes later, after sysvr4.
+	-gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
+	      | -*vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[34]*\
+	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \
+	      | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \
+	      | -aos* \
+	      | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \
+	      | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \
+	      | -hiux* | -386bsd* | -netbsd* | -openbsd* | -freebsd* | -riscix* \
+	      | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
+	      | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
+	      | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
+	      | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
+	      | -mingw32* | -linux-gnu* | -uxpv* | -beos* | -mpeix* | -udk* \
+	      | -interix* | -uwin* | -rhapsody* | -darwin* | -opened* \
+	      | -openstep* | -oskit*)
+	# Remember, each alternative MUST END IN *, to match a version number.
+		;;
+	-qnx*)
+		case $basic_machine in
+		    x86-* | i[34567]86-*)
+			;;
+		    *)
+			os=-nto$os
+			;;
+		esac
+		;;
+	-nto*)
+		os=-nto-qnx
+		;;
+	-sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \
+	      | -windows* | -osx | -abug | -netware* | -os9* | -beos* \
+	      | -macos* | -mpw* | -magic* | -mmixware* | -mon960* | -lnews*)
+		;;
+	-mac*)
+		os=`echo $os | sed -e 's|mac|macos|'`
+		;;
+	-linux*)
+		os=`echo $os | sed -e 's|linux|linux-gnu|'`
+		;;
+	-sunos5*)
+		os=`echo $os | sed -e 's|sunos5|solaris2|'`
+		;;
+	-sunos6*)
+		os=`echo $os | sed -e 's|sunos6|solaris3|'`
+		;;
+	-opened*)
+		os=-openedition
+		;;
+	-wince*)
+		os=-wince
+		;;
+	-osfrose*)
+		os=-osfrose
+		;;
+	-osf*)
+		os=-osf
+		;;
+	-utek*)
+		os=-bsd
+		;;
+	-dynix*)
+		os=-bsd
+		;;
+	-acis*)
+		os=-aos
+		;;
+	-386bsd)
+		os=-bsd
+		;;
+	-ctix* | -uts*)
+		os=-sysv
+		;;
+	-ns2 )
+	        os=-nextstep2
+		;;
+	-nsk)
+		os=-nsk
+		;;
+	# Preserve the version number of sinix5.
+	-sinix5.*)
+		os=`echo $os | sed -e 's|sinix|sysv|'`
+		;;
+	-sinix*)
+		os=-sysv4
+		;;
+	-triton*)
+		os=-sysv3
+		;;
+	-oss*)
+		os=-sysv3
+		;;
+	-svr4)
+		os=-sysv4
+		;;
+	-svr3)
+		os=-sysv3
+		;;
+	-sysvr4)
+		os=-sysv4
+		;;
+	# This must come after -sysvr4.
+	-sysv*)
+		;;
+	-ose*)
+		os=-ose
+		;;
+	-es1800*)
+		os=-ose
+		;;
+	-xenix)
+		os=-xenix
+		;;
+        -*mint | -*MiNT)
+	        os=-mint
+		;;
+	-none)
+		;;
+	*)
+		# Get rid of the `-' at the beginning of $os.
+		os=`echo $os | sed 's/[^-]*-//'`
+		echo Invalid configuration \`$1\': system \`$os\' not recognized 1>&2
+		exit 1
+		;;
+esac
+else
+
+# Here we handle the default operating systems that come with various machines.
+# The value should be what the vendor currently ships out the door with their
+# machine or put another way, the most popular os provided with the machine.
+
+# Note that if you're going to try to match "-MANUFACTURER" here (say,
+# "-sun"), then you have to tell the case statement up towards the top
+# that MANUFACTURER isn't an operating system.  Otherwise, code above
+# will signal an error saying that MANUFACTURER isn't an operating
+# system, and we'll never get to this point.
+
+case $basic_machine in
+	*-acorn)
+		os=-riscix1.2
+		;;
+	arm*-rebel)
+		os=-linux
+		;;
+	arm*-semi)
+		os=-aout
+		;;
+        pdp11-*)
+		os=-none
+		;;
+	*-dec | vax-*)
+		os=-ultrix4.2
+		;;
+	m68*-apollo)
+		os=-domain
+		;;
+	i386-sun)
+		os=-sunos4.0.2
+		;;
+	m68000-sun)
+		os=-sunos3
+		# This also exists in the configure program, but was not the
+		# default.
+		# os=-sunos4
+		;;
+	m68*-cisco)
+		os=-aout
+		;;
+	mips*-cisco)
+		os=-elf
+		;;
+	mips*-*)
+		os=-elf
+		;;
+	*-tti)	# must be before sparc entry or we get the wrong os.
+		os=-sysv3
+		;;
+	sparc-* | *-sun)
+		os=-sunos4.1.1
+		;;
+	*-be)
+		os=-beos
+		;;
+	*-ibm)
+		os=-aix
+		;;
+	*-wec)
+		os=-proelf
+		;;
+	*-winbond)
+		os=-proelf
+		;;
+	*-oki)
+		os=-proelf
+		;;
+	*-hp)
+		os=-hpux
+		;;
+	*-hitachi)
+		os=-hiux
+		;;
+	i860-* | *-att | *-ncr | *-altos | *-motorola | *-convergent)
+		os=-sysv
+		;;
+	*-cbm)
+		os=-amigaos
+		;;
+	*-dg)
+		os=-dgux
+		;;
+	*-dolphin)
+		os=-sysv3
+		;;
+	m68k-ccur)
+		os=-rtu
+		;;
+	m88k-omron*)
+		os=-luna
+		;;
+	*-next )
+		os=-nextstep
+		;;
+	*-sequent)
+		os=-ptx
+		;;
+	*-crds)
+		os=-unos
+		;;
+	*-ns)
+		os=-genix
+		;;
+	i370-*)
+		os=-mvs
+		;;
+	*-next)
+		os=-nextstep3
+		;;
+        *-gould)
+		os=-sysv
+		;;
+        *-highlevel)
+		os=-bsd
+		;;
+	*-encore)
+		os=-bsd
+		;;
+        *-sgi)
+		os=-irix
+		;;
+        *-siemens)
+		os=-sysv4
+		;;
+	*-masscomp)
+		os=-rtu
+		;;
+	f301-fujitsu)
+		os=-uxpv
+		;;
+	*-rom68k)
+		os=-coff
+		;;
+	*-*bug)
+		os=-coff
+		;;
+	*-apple)
+		os=-macos
+		;;
+	*-atari*)
+		os=-mint
+		;;
+	*)
+		os=-none
+		;;
+esac
+fi
+
+# Here we handle the case where we know the os, and the CPU type, but not the
+# manufacturer.  We pick the logical manufacturer.
+vendor=unknown
+case $basic_machine in
+	*-unknown)
+		case $os in
+			-riscix*)
+				vendor=acorn
+				;;
+			-sunos*)
+				vendor=sun
+				;;
+			-aix*)
+				vendor=ibm
+				;;
+			-beos*)
+				vendor=be
+				;;
+			-hpux*)
+				vendor=hp
+				;;
+			-mpeix*)
+				vendor=hp
+				;;
+			-hiux*)
+				vendor=hitachi
+				;;
+			-unos*)
+				vendor=crds
+				;;
+			-dgux*)
+				vendor=dg
+				;;
+			-luna*)
+				vendor=omron
+				;;
+			-genix*)
+				vendor=ns
+				;;
+			-mvs* | -opened*)
+				vendor=ibm
+				;;
+			-ptx*)
+				vendor=sequent
+				;;
+			-vxsim* | -vxworks*)
+				vendor=wrs
+				;;
+			-aux*)
+				vendor=apple
+				;;
+			-hms*)
+				vendor=hitachi
+				;;
+			-mpw* | -macos*)
+				vendor=apple
+				;;
+			-*mint | -*MiNT)
+				vendor=atari
+				;;
+		esac
+		basic_machine=`echo $basic_machine | sed "s/unknown/$vendor/"`
+		;;
+esac
+
+echo $basic_machine$os
diff --git a/contrib/README b/contrib/README
new file mode 100644
index 00000000..d81ebbf2
--- /dev/null
+++ b/contrib/README
@@ -0,0 +1,179 @@
+These are scripts to help you running fetchmail in special situations. 
+Note: you're on your own using these -- I don't really understand them,
+I'm just passing them along.
+								--esr
+
+maildaemon:
+
+Larry Fahnoe wrote this for driving fetchmail from cron.  It may be useful if
+you want to force a PPP link up and then poll for mail at specified times.
+I have rearranged it slightly to make it easier to configure.
+
+novell:
+
+Some mail from Dan Newcombe describing how to write a procmail rule that
+will domainify Novell server names.
+
+login & logout:
+
+These are intended to help if you typically have multiple logins active.
+Here's the script composer's original README:
+
+	Please find attached 2 files, ~/.bash_login & ~/.bash_logout
+	What these do is try to keep track of WHO is the process/tty
+	that ran fetchmail in daemon mode.  I tried to use the bash
+	Variable PPID, but when using xterm the PPID is set to the
+	xterm's pid not the bash shell's pid so....
+
+	They have been lightly tested.
+
+	Any comments...
+
+ 				Hth, JimL <babydr@nwrain.net>
+
+Doug Carter <dougc@canus.com> suggests this instead:
+
+Add the following to your login script. (.ie .bash_profile, .profile, etc)
+
+LOGINS=`who | grep $USER | wc -l`
+if [ $LOGINS = 1 ]; then
+    /usr/bin/fetchmail > /dev/null 2>&1
+fi
+
+Then add the following to your logout script. (.ie .bash_logout, etc)
+
+LOGINS=`who | grep $USER | wc -l`
+if [ $LOGINS = 1 ]; then
+    /usr/bin/fetchmail -q > /dev/null 2>&1
+fi
+
+ip-up:
+
+A note from James Stevens about using fetchmail in an ip-up script without
+disabling timeouts.
+
+runfetchmail:
+
+A shellscript front end for fetchmail that mails you various statistics on
+the downloaded mail and the state of your folders.  A good example of what
+you can do with your own front end.
+
+fetchspool:
+
+If you find that the speed of forwarding to port 25 is limited by the
+SMTP listener's speed, it may make sense to locally spool all the mail
+first and feed it to sendmail after you hang up the network link.
+This shellscript aims to do exactly that.  It would be smarter to
+figure out why sendmail is slow, however.
+
+fetchsetup:
+
+This is a shell script for creating a $HOME/.fetchmailrc file, it will ask
+you some questions and based on your answers it will create a .fetchmailrc
+file, fetchsetup is linux specific so it may not work on another operating
+system.
+
+mailqueue.pl:
+
+This script will connect to your isp (if not already connected),
+send any outgoing mail and retrieve any incoming mail.  If this
+program made the connection, it will also break the connection
+when it is done.  By Bill Adams, <bill@evil.inetarena.com>.  The
+latest version is carried at <http://evil.inetarena.com/>.
+
+redhat_rc:
+
+A fetchmail boot-time init file compatible with RedHat 5.1.  It leaves
+fetchmail in background to get messages when you connect to your ISP.
+The invoked fetchmail expects to find its configuration in
+/etc/fetchmailrc, and must include the proper "interface" directive.
+
+debian_rc:
+
+A fetchmail boot-time init file compatible with Debian.  It leaves
+fetchmail in background to get messages when you connect to your ISP.
+The invoked fetchmail expects to find its configuration in
+/root/.fetchmailrc, and must include the proper "interface" directive.
+
+start_dynamic_ppp:
+
+An admittedly scratchy ip-up script that Ryan Murray wrote to cope with
+dynamic PPP addressing.  Will need some customizing.
+
+	http://www.inetarena.com/~badams/linux/programs/mailqueue.pl
+
+getfetchmail:
+
+Here's a script that gets Eric's most recent fetchmail source rpm,
+downloads it and (if the rpm's not broken) rebuilds it.
+
+With fairly simple changes it can be used to download the latest i386 rpm
+or tar.gz.
+ 
+Those who are addicted to having the latest of everything could filter mail
+from fetchmail announce through it and get new versions as they're
+announced. However, if we all did that, Eric's ftp server might feel a
+little stressed.
+
+The script as written works on bash 2.  By John Summerfield
+<summer@os2.ami.com.au>.
+
+zsh-completion:
+
+These commands set up command completion for fetchmail under zsh.
+Jay Kominek <jay.kominek@colorado.edu>.
+
+getmail/gotmail:
+
+These scripts are front ends for fetchmail in daemon mode that can gather
+log statistics and generate text or HTML reports.  See README.getmail for
+details.  Scripts by Thomas Nesges <ThomaNesges@TNT-Computer.de>.
+
+fetchmaildistrib:
+
+This script resolves the issue where the sysadmin polls for mail with fetchmail
+only at set intervals, but where a user wishes to see his email right
+away. The duplication in /etc/fetchmailrc and ~/.fetchmailrc files is
+automated with this script; whenever /etc/fetchmailrc is changed, this
+script is run to distribute the stuff into all user's ~/.fetchmailrc
+files.
+
+multidrop:
+
+Martijn Lievaart's sendmail hacks to make multidrop reliable.
+
+domino:
+
+Gustavo Chaves <gustavo@cpqd.com.br> wrote this script to deal with 
+the boundary-mismatch bug in Domino (see FAQ item X5).  If you use
+this with --mda, the broken boundaries will be fixed and the result
+passed to procmail.
+
+toprocmail:
+
+John Lim Eng Hooi <jleh@mail.com> wrote this script, yet another 
+mda plugin, to be used with fetchmail in foreground mode.  It displays
+some header lines to stdout in color, passing them (and the rest of the
+message content) to procmail.
+
+preauth-harness:
+
+Emmanuel Dreyfus's Perl test script for exercising IMAP PREAUTH
+connections.  You'll have to patch in your username and password.
+
+sm-hybrid:
+
+Peter 'Rattacresh' Backes sent this patch to improve the behavior of 
+sendmail 8.11.0 with multidrop.
+
+fetchmailnochda.pl
+
+Watchdog script to check whether fetchmail is working in daemon mode.
+
+mold-remover.py
+
+A short python script to remove old read mail from a pop3 mailserver.
+Dovetails with fetchmail with keep option.
+Run it as a cron job...
+
+
diff --git a/contrib/README.getmail b/contrib/README.getmail
new file mode 100644
index 00000000..237889cd
--- /dev/null
+++ b/contrib/README.getmail
@@ -0,0 +1,64 @@
+-------------------------------------------------------------------------------
+
+                         - GetMail - GotMail -
+
+             1999 by Thomas Nesges <ThomaNesges@TNT-Computer.de>
+
+-------------------------------------------------------------------------------
+
+-------------------------------------------------------------------------------
+Installation:
+-------------------------------------------------------------------------------
+The Installation is as simple as it could be.  Just create the directory
+/usr/local/gotmail and copy all files to it. Ready.
+
+If you decide to choose an other directory to copy the files to, don't forget
+to change the path in the scripts.
+
+-------------------------------------------------------------------------------
+Usage:
+-------------------------------------------------------------------------------
+GetMail starts with: getmail <option>
+
+options:
+ clear  - stops fetchmail and kills the logfile
+ fetch  - starts fetchmail
+ got    - starts gotmail
+ goth   - starts gotmail html
+ send   - sends all mail from the mailqueue
+ status - tails the logfile
+ start  - starts fetchmail and tails the logfile
+ stop   - stops fetchmail
+ -v     - prints GetMails version number
+
+GotMail can be startet without any parameters. It then prints a statistic
+on the console. The only parameters so far are:
+
+ html   - prints the output to an html file specified in gotmail.conf
+ -v     - prints GotMails version number
+
+-------------------------------------------------------------------------------
+Configuration
+-------------------------------------------------------------------------------
+GotMail is configured by a file named gotmail.conf either in the user's home
+dir, in /etc or in /usr/local/gotmail. gotmail.conf itself is a shell script.
+It just exports some variables to the environment. So it's syntax is like this:
+
+ export <OPTION>=<VALUE>
+
+Remember not to put spaces between <OPTION>=<VALUE> !!
+You have the folllowing options:
+ 
+  GOTM_ERR	yes|no		print error messages?
+  GOTM_MSG	yes|no		print mail stats?
+  GOTM_TIM	yes|no		print start/stop stats?
+  GOTM_HED	yes|no		print a header?
+
+ Special HTML options:
+  GOTM_BGCOL	hex color	backgroundcolor
+  GOTM_TXCOL	hex color	textcolor
+  GOTM_ERRCOL	hex color	color of error messages
+  GOTM_TIMCOL	hex color	color of start/stop stats
+  GOTM_MSGCOL	hex color	color of mail stats
+  GOTM_HTMLFILE	filename	filename for html output
+-------------------------------------------------------------------------------
diff --git a/contrib/debian_rc b/contrib/debian_rc
new file mode 100755
index 00000000..7bbdbdc8
--- /dev/null
+++ b/contrib/debian_rc
@@ -0,0 +1,40 @@
+#!/bin/sh
+#
+# To start fetchmail as a system service, copy this file to
+# /etc/init.d/fetchmail and run "update-rc.d fetchmail
+# defaults".  A fetchmailrc file containg hosts and
+# passwords for all local users should be placed in /root
+# and should contain a line of the form "set daemon <nnn>".
+#
+# To remove the service, delete /etc/init.d/fetchmail and run
+# "update-rc.d fetchmail remove".
+
+DAEMON=/usr/bin/fetchmail
+
+set -e
+test -f $DAEMON || exit 0
+
+case "$1" in
+  start)
+        echo -n "Starting mail retrieval agent: "
+        if start-stop-daemon --start --quiet --exec $DAEMON; then echo "fetchmail."
+        else echo "fetchmail already running."; fi
+        ;;
+  stop)
+        echo -n "Stopping mail retrieval agent: "
+        start-stop-daemon --stop --quiet --exec $DAEMON
+        echo "fetchmail."
+        ;;
+  force-reload|restart)
+        echo -n "Restarting mail retrieval agent: "
+        start-stop-daemon --stop --quiet --exec $DAEMON
+        start-stop-daemon --start --quiet --exec $DAEMON
+        echo "fetchmail."
+        ;;
+  *)
+        echo "Usage: /etc/init.d/fetchmail {start|stop|restart}"
+        exit 1
+        ;;
+esac
+
+exit 0
diff --git a/contrib/domino b/contrib/domino
new file mode 100644
index 00000000..a5802718
--- /dev/null
+++ b/contrib/domino
@@ -0,0 +1,84 @@
+#!/usr/bin/perl -w
+# correct-domino-mime-conversion - does it!
+# $Id: domino,v 1.1 2004/06/08 03:59:00 rfunk Exp $
+
+use strict;
+
+# Any arguments are expected to be an mda invocation.
+if (@ARGV) {
+    my $mda = join(' ', @ARGV);
+    open(MDA, "| $mda") or die "Can't exec $mda: $!\n";
+    select(MDA);
+}
+
+# Look for a Boundary declaration in the message header
+my $decltag;
+while (<STDIN>) {
+    print;
+    if (/boundary=\"(.*)\"$/i) {
+	$decltag = $1;
+    } elsif (/^$/) {
+	# An empty line marks the end of the headers.
+	last;
+    }
+}
+
+# If we didn't find a Boundary declaration just pipe the rest of the
+# message unchanged.
+if (!defined $decltag) {
+    while (<STDIN>) {
+	print;
+    }
+    exit 0;
+}
+
+# Substitute $decltag for every ocurrence of an outer-level boundary
+# string found in the body of the message.
+my $usedtag;
+while (<STDIN>) {
+    if (/^--(.*)$/) {
+	$usedtag = $1 unless defined $usedtag;
+	if ($1 eq $usedtag) {
+	    $_ =  "--$decltag\n";
+	} elsif ($1 eq "$usedtag--") {
+	    $_ = "--$decltag--\n";
+	}
+    }
+    print;
+}
+
+=pod
+
+This script can be used to bypass a bug in the Domino-5.0.2b IMAP
+service that manifests itself when you use fetchmail as the IMAP
+client.  The problem is that fetchmail (differently from other IMAP
+clients) fetches messages in two parts, first the headers and then the
+body.  It seems that Domino converts the messages from its internal
+format into MIME twice.  In doing so, it declared a boundary string in
+the messages Content-type header and uses another one to separate the
+parts in the body.
+
+This script should be used as a mda option for fetchmail.  As
+arguments to it, pass the former mda you used.  I, for example, use the following entry in my .fetchmailrc:
+
+	poll server ... mda "/usr/bin/procmail -d %T";
+
+To use this filter, I changed the above into the following:
+
+	poll server ... mda "/home/gustavo/bin/correct-domino-mime-conversion /usr/bin/procmail -d %T";
+
+If you do not use a mda normally, you can try the following to call sendmail directly:
+
+	poll server ... mda "/home/gustavo/bin/correct-domino-mime-conversion //wherever/is/your/sendmail -oem -f %F %T";
+
+Without argumets this script is a filter that reads from its stdin and
+outputs the result into its stdout.
+
+I should mention that this bug seems to be solved in Domino 5.0.3
+(http://www.notes.net/46dom.nsf/434e319a66960d8385256857005cd97b/4499e0db6e43732b852568b2006ef7e9?OpenDocument)
+but I have not checked it.
+
+Gustavo.
+<gustavo@cpqd.com.br>
+
+=cut
diff --git a/contrib/fetchmail-mode.el b/contrib/fetchmail-mode.el
new file mode 100644
index 00000000..d22ebcaf
--- /dev/null
+++ b/contrib/fetchmail-mode.el
@@ -0,0 +1,142 @@
+;; fetchmail-mode.el        -*- Emacs-Lisp -*-
+;;
+;; Mode for editing .fetchmailrc files
+;;
+;; Created:    <Mon Oct 30 20:13:15 EST 2000>
+;; Time-stamp: <17.02.2001 17:59:43>
+;; Version:    0.1
+;; Keywords:   fetchmail,config
+;; Author:     Alex Shinn <foof@debian.org>
+;;
+;; This program is free software; you can redistribute it and/or
+;; modify it under the terms of the GNU General Public License as
+;; published by the Free Software Foundation; either version 2 of
+;; the License, or (at your option) any later version.
+;;
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+;;
+;; You should have received a copy of the GNU General Public
+;; License along with this program; if not, write to the Free
+;; Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+;; MA 02111-1307 USA
+
+;; Commentary:
+;;
+;; This file provides a major mode for editing .fetchmailrc files.
+;; It offers syntax highlighting and indentation.
+;;
+;; To use it, put the following in your .emacs:
+;;
+;; (autoload 'fetchmail-mode "fetchmail-mode.el" "Mode for editing .fetchmailrc files" t)
+;;
+;; You may also want something like:
+;;
+;; (setq auto-mode-alist
+;;       (append '(("\..fetchmailrc$" . fetchmail-mode))
+;;               auto-mode-alist))
+
+;; Create mode-specific tables.
+(defvar fetchmail-mode-syntax-table nil
+  "Syntax table used while in fetchmail-mode" )
+(if fetchmail-mode-syntax-table
+    ()              ; Do not change the table if it is already set up.
+  (setq fetchmail-mode-syntax-table (make-syntax-table))
+  (modify-syntax-entry ?\\ "\\   " fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\,  "." fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\:  "." fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\;  "." fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\"  "\"" fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\'  "\"" fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\n  "> " fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\#  "< " fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\( "()   " fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\) ")(   " fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\[ "(]   " fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\] ")[   " fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\{ "(}   " fetchmail-mode-syntax-table)
+  (modify-syntax-entry ?\} "){   " fetchmail-mode-syntax-table)
+  )
+
+(defvar fetchmail-mode-map nil
+  "Keymap used in fetchmail-mode" )
+
+(if fetchmail-mode-map nil
+  (setq fetchmail-mode-map (make-sparse-keymap))
+  (define-key fetchmail-mode-map "\t" 'fetchmail-complete)
+  (define-key fetchmail-mode-map "\C-c\C-c" 'comment-region) )
+(defvar fetchmail-mode-hook nil
+  "Hooks to run in fetchmail-mode" )
+
+(defvar fetchmail-keywords nil
+  "Keywords used for fetchmail-mode" )
+
+(unless fetchmail-keywords
+   (setq fetchmail-keywords
+          '("poll" "skip" "via" "in" "proto" "protocol" "uidl" "no" "port" "auth" "authenticate" "timeout" "envelope" "qvirtual" "envelope" "aka" "localdomains" "interface" "monitor" "dns" "user" "username" "is" "folder" "pass" "password" "smtp" "smtphost" "smtpaddress" "antispam" "mda" "pre" "preconnect" "post" "postconnect" "keep" "flush" "fetchall" "rewrite" "forcecr" "stripcr" "pass8bits" "dropstatus" "limit" "fetchlimit" "batchlimit" "expunge" "pop2" "POP2" "pop3" "POP3" "imap" "IMAP" "imap-k4" "IMAP-K4" "apop" "APOP" "rpop" "RPOP" "kpop" "KPOP" "etrn" "ETRN" "login" "kerberos" "kerberos_v5" "logfile" "daemon" "syslog" "invisible" "and" "with" "has" "wants" "options" "here" "there" "aka" "set")))
+
+(defvar fetchmail-keyword-table nil
+  "Completion table for fetchmail-mode" )
+(unless fetchmail-keyword-table
+  (setq fetchmail-keyword-table (make-vector 8 0))
+  (mapcar (lambda (x) (intern x fetchmail-keyword-table))
+          fetchmail-keywords))
+
+(defvar fetchmail-font-lock-keywords nil
+  "Default expressions to highlight in fetchmail-mode" )
+
+(unless fetchmail-font-lock-keywords
+  (setq fetchmail-font-lock-keywords
+        (list (list (concat "\\b" (regexp-opt
+                                   fetchmail-keywords t) "\\b")
+                    0 'font-lock-keyword-face ))))
+
+(defun fetchmail-complete ()
+  "Tab completion for fetchmail-mode"
+  (interactive)
+  (let* ((end (point))
+	 (beg (save-excursion
+		(skip-syntax-backward "w")
+		(point)))
+	 (pattern (buffer-substring beg end))
+	 (table fetchmail-keyword-table)
+	 (completion (try-completion pattern table)))
+    (cond ((eq completion t))
+	  ((null completion)
+	   (error "Can't find completion for \"%s\"" pattern))
+	  ((not (string-equal pattern completion))
+	   (delete-region beg end)
+	   (insert completion))
+	  (t
+	   (message "Making completion list...")
+	   (let ((list (all-completions pattern table)))
+	     (if (fboundp 'prettify)
+		 (setq list (funcall 'prettify list)))
+	     (with-output-to-temp-buffer "*Help*"
+	       (display-completion-list list)))
+	   (message "Making completion list...%s" "done")))))
+
+
+(defun fetchmail-mode ()
+  "Mode for editing .fetchmailrc files"
+  (interactive)
+  (kill-all-local-variables)
+  (use-local-map fetchmail-mode-map)    ; This provides the local keymap.
+  (setq mode-name "Fetchmail")          ; This name goes into the modeline.
+  (setq major-mode 'fetchmail-mode)     ; Used by `describe-mode'
+  (run-hooks 'fetchmail-mode-hook)      ; Run each time mode is called
+  (set-syntax-table fetchmail-mode-syntax-table)
+
+  ;; -cc-
+  ;; Font lock support
+  (make-local-variable 'font-lock-defaults)
+  (setq font-lock-defaults '(fetchmail-font-lock-keywords nil t))
+
+  (setq comment-start "#")
+  )
+
+
+
+(provide 'fetchmail-mode)
diff --git a/contrib/fetchmaildistrib b/contrib/fetchmaildistrib
new file mode 100644
index 00000000..00cc1910
--- /dev/null
+++ b/contrib/fetchmaildistrib
@@ -0,0 +1,29 @@
+#/bin/bash
+#
+# fetchmaildistrib --- Distribute central fetchmail knowledge.
+#
+# The central fetchmail database, /etc/fetchmail, contains all accounts that
+# are to be fetched by the root's daemon. Often, a user desires quicker
+# access (e.g., when testing some email path). In such cases, the destination
+# user (marked as is USER here in the poll lines) should set up a ~/.fetchmailrc
+# for himself. This scripts generates such lines from the central file.
+#
+# By Rick van Rein.
+
+# From stdin, select poll lines for user $1
+function selectuser () {
+	grep ^poll | grep "is $1 here"
+}
+
+
+for i in `cut -d: -f1 </etc/passwd`
+do	homedir=`grep ^$i: /etc/passwd | cut -d: -f6`
+	fetchfile=`selectuser $i </etc/fetchmailrc`
+	if [ -z "$fetchfile" ]
+	then	rm -f $homedir/.fetchmailrc
+	else	cp /dev/null $homedir/.fetchmailrc
+		chmod go-rwx $homedir/.fetchmailrc
+		grep ^defaults /etc/fetchmailrc >>$homedir/.fetchmailrc
+		selectuser $i </etc/fetchmailrc >>$homedir/.fetchmailrc
+	fi
+done
diff --git a/contrib/fetchmailnochda.pl b/contrib/fetchmailnochda.pl
new file mode 100755
index 00000000..b0a89609
--- /dev/null
+++ b/contrib/fetchmailnochda.pl
@@ -0,0 +1,131 @@
+#!/usr/bin/perl
+
+# User contribution to fetchmail by Torsten Mueller torsten@archesoft.de
+# v1.1 22/may/2001
+
+# the reason for this script is to check, if fetchmail (in daemon mode) works
+# you should have perl and the perlmodule File::Compare installed
+# File::Compare you can find at http://www.cpan.org/
+
+# installation:
+# edit the config part of this script
+# create a cronjob , the time it should run should be higher than the pollintervall !!
+
+# possible problems:
+# you have set the cron intervall to short
+# the script doesn't have permissions to write to directories or to execute fetchmail
+# you didn't start fetchmail in daemon mode but use cron to fetch mail
+# you can't read my english
+
+# how does it work
+# really simple, the script checks, if there was a change to the logfile of fetchmail
+# to find this out, the script makes a backup of the original logfile and compares 
+# the size of the original and the backup logfile
+# i know it's a dirty way, but hey, it works ...
+ 
+use File::Compare;
+
+# config
+# where lives fetchmail on your system
+$fetchmail = '/usr/bin/fetchmail';
+# where should be the logfile for fetchmail
+$fetchmaillog = '/var/log/fetchmail.log';
+# where could the script write the backup of the logfile
+$fetchmailwatch = '/var/log/fetchmailwatch';
+# after how many seconds fetchmail should get mail, the poll intervall
+$fetchmailtime = '3600';
+# which config file should fetchmail use for retrieval
+$fetchmailconf = '/root/.fetchmailrc';
+# where lives your cp program 
+$copycp = 'cp';
+#end config
+
+if (!(-e "$fetchmaillog")) {
+# es existiert keine logdatei von fetchmail
+# there isn't a logfile of fetchmail
+print "There seems to be a problem with the fetchmail daemon\n
+I couldn't find a logfile of fetchmail.\n
+I try to stop and to start fetchmail in daemon mode.\n
+If you get this mail more then once, then check your system !\n
+------------------------------------------------------------\n
+Es ist ein Fehler aufgetreten bei der Ueberwachung des fetchmail Daemons\n
+Es existiert keine Logdatei. Ich versuche jetzt fetchmail zu stoppen und neu zu \n
+starten. Sollte das Problem nochmal auftreten, dann genaue Systeminspektion !\n
+------------------------------------------------------------\n
+Das fetchmail Ueberwachungsscript Copyright 2001 by T. Mueller torsten\@archesoft.de\n\n";
+
+system "$fetchmail -q";
+sleep 3 ;
+system "$fetchmail -f $fetchmailconf -d $fetchmailtime -L $fetchmaillog";
+sleep 2 ;
+
+}
+
+if (!(-e "$fetchmailwatch")) {
+# die kopie der logdatei existiert nicht
+# the copy of the original logfile doesn't exists
+print "There seems to be a problem with the fetchmail daemon\n
+I couldn't find the copy of the original logfile of fetchmail.\n
+If this is this the first run of this script, then this is no problem!\n
+If you get this mail more then once, then check your system !\n
+------------------------------------------------------------\n
+Es ist ein Fehler aufgetreten bei der Ueberwachung des fetchmail Daemons\n
+Es existiert keine Kopie der Logdatei. Wenn das Script das erste Mal aufgerufen wurde,\n
+dann ist dies kein Problem. Sollte dieses Problem nochmal auftreten, dann genaue Systeminspektion !\n
+------------------------------------------------------------\n
+Das fetchmail Ueberwachungsscript Copyright 2001 by T. Mueller torsten\@archesoft.de\n\n";
+&copylog;
+exit; }
+
+
+$vergleich = compare("$fetchmaillog","$fetchmailwatch");
+
+if ($vergleich == -1) {
+# irgendein fehler ist aufgetreten
+# unknown error
+print "There seems to be a problem with the fetchmail daemon or this script\n
+I don't know, why this error happens.
+Please check the script and your system
+------------------------------------------------------------\n
+Es ist ein Fehler aufgetreten bei der Ueberwachung des fetchmail Daemons\n
+Bitte die notwendigen Schritte unternehmen, z.B. Festplattenspeicherplatz pruefen\n
+noch eine kommt.\n
+------------------------------------------------------------\n
+Das fetchmail Ueberwachungsscript Copyright 2001 by T. Mueller torsten\@archesoft.de\n\n";
+}
+
+
+if ($vergleich == 0) {
+# dateien sind gleich also also eine aktion starten
+# the copy and the original logfile have the same size
+print "There seems to be a problem with the fetchmail daemon\n
+The logfile seems the be the same as the last logfile i have seen.
+That could mean, that fetchmail hangs, or permissionproblems or disk full.
+I try to stop and to start fetchmail in daemon mode.\n
+If you get this mail more then once, then check your system !\n
+------------------------------------------------------------\n
+Scheinbar gab es ein Problem mit dem Programm fetchmail\n
+Die Logdatei war identisch mit der Logdatei beim  letzten Lauf diese Scriptes\n
+Daraus schlussfolgere ich, dass nichts mehr geloggt wurde -> fetchmail hat ein Problem\n
+Ich habe fetchmail versucht zu stoppen, und wieder neu zu starten.\n
+Sollte diese Mail heute noch mehrfach erscheinen, dann ist eine genauere Inspektion\n
+der Umstaende notwendig. Ist dies die erste Mail, dann einfach mal abwarten, ob\n
+noch eine kommt.\n
+------------------------------------------------------------\n
+Das fetchmail Ueberwachungsscript Copyright 2001 by T. Mueller torsten\@archesoft.de\n\n";
+
+system "$fetchmail -q";
+sleep 3 ;
+system "$fetchmail -f $fetchmailconf -d $fetchmailtime -L $fetchmaillog";
+sleep 2 ;
+
+}
+
+
+&copylog;
+
+sub copylog {
+system "$copycp $fetchmaillog $fetchmailwatch";
+}
+
+
diff --git a/contrib/fetchspool b/contrib/fetchspool
new file mode 100644
index 00000000..cd6c2c81
--- /dev/null
+++ b/contrib/fetchspool
@@ -0,0 +1,58 @@
+#!/bin/sh -
+#
+# Quick hack for fetchmail to locally spool messages.
+#
+# To spool:
+#     fetchmail --mda "fetchspool -t %T %F"
+# To de-spool
+#     fetchspool -f
+#
+# Robert de Bath  <robert@mayday.cix.co.uk>
+# updated by william boughton <bill@xencat.demon.co.uk>
+# 4th/10/1998 and tested
+#
+# William Boughton comments:
+# Still has some potential problems, with using inline from address.
+# The use of _ is bad because fetchmails uses this if it notices
+# shell escapes.
+# 10th/11/1998
+# Changed to using 3 _@@s to delimit the message, i hope this is ok.
+# Whilst i have tested and used this script, with my demon account and
+# SDPS, it may still have serious problems, that i've not noticed etc.
+
+MAILSPOOL=/tmp/spool
+
+if [ "$1" != "-f" ]
+then
+   if [ "$1" = "-t" ]
+   then 
+	ADDR="$2"
+	FROM="$3"
+   else 
+	ADDR="$1"
+	FROM="$2"
+   fi
+
+   cat - > $MAILSPOOL/tmp.$$ 				   || exit 1
+   mv $MAILSPOOL/tmp.$$ "$MAILSPOOL/msg.`date +%j%H%M%S`$$.to.${ADDR}_@@${FROM}"  || exit 1
+
+   exit 0
+else
+   for i in $MAILSPOOL/msg.*.to.*
+   do
+      [ -f "$i" ] || continue
+     # TO="`echo \"$i\" | sed 's/^msg.[^.]*.to.//'`"
+	TO=$(basename $i | sed -e 's/^msg.[^.]*.to.//' -e 's/_@@.*$//')
+	FROM=$(basename $i | sed 's/^msg.[^.]*.to.*_@@//')
+# need the \<\> so for bounces to have a proper from addr
+echo the to was \<$TO\>  and the from \<$FROM\>
+      /usr/lib/sendmail -f \<${FROM}\> -oem "$TO" < "$i" ||
+      {
+         echo "Sendmail failed on `basename \"$i\"`"
+	 continue
+      }
+      rm -f "$i"
+   done
+   exit 0
+fi
+
diff --git a/contrib/getfetchmail b/contrib/getfetchmail
new file mode 100644
index 00000000..bcac9d3e
--- /dev/null
+++ b/contrib/getfetchmail
@@ -0,0 +1,31 @@
+#!/bin/bash 
+RH=ftp.ccil.org
+p=`\
+echo dir /pub/esr/fetchmail/f\*src.rpm \
+   | ftp $RH \
+   | grep /pub/esr/fetchmail/fetchmail-[45] \
+   | tail -1`
+#p='-rw-r--r-- 1 23 wheel 478424 Dec 18 03:54 /pub/esr/fetchmail/fetchmail-4.7.1-1.src.rpm'
+#echo $p | sed -e "s=^.^/pub=pub="
+p1=`echo $p | sed -e "s=^.*/pub=pub="`
+#echo $p1
+#basename  $p1
+#dirname $p1
+d=`dirname $p1`
+f=`basename $p1`
+cd /work/incoming
+email=$LOGNAME\@`hostname`
+ftp -n <<ZZ
+open $RH
+user anonymous $email
+cd /$d
+get $f
+bye
+ZZ
+rpm -K $f >/dev/null 2>&1 \
+   || {
+         rpm -K $f 2>&1 | mail $email -s "error getting $f"
+         exit 
+      }
+rpm --rebuild  $f 2>&1 |\
+   mail $email -s "Rebuilding $f"
diff --git a/contrib/getfetchmail.pl b/contrib/getfetchmail.pl
new file mode 100644
index 00000000..45bd3c65
--- /dev/null
+++ b/contrib/getfetchmail.pl
@@ -0,0 +1,61 @@
+#!/usr/bin/perl -w
+# Copyright 2001 John Summerfield, summer@summer.ami.com.au
+# GPL 2 applies.
+#
+($flags, $links, $owner, $gowner, $size, $month, $day, $timeOrDate, $name, $junk, $junk2, $junk1) ='';
+$RemoteHost="ftp.ccil.org";
+$LocalDir="/home/u03/incoming/";
+$FilePattern="/pub/esr/fetchmail/fetchmail\*src.rpm";
+$GrepArgs="fetchmail-[5-9]";
+$no=0;
+$TempFile=`mktemp /var/tmp/getfetchmail.XXXXXX`;
+@files=`echo dir $FilePattern | ftp $RemoteHost  | egrep $GrepArgs`;
+chomp @files;
+open(FTP, "| ftp -d -v $RemoteHost | egrep '^213|MDTM'  >$TempFile");
+foreach $L (@files)
+{
+	++$no;
+	$L =~ s/  */,/g;
+	($flags, $links, $owner, $gowner, $size, $month, $day, $timeOrDate, $name, $junk) = split /,/,$L;
+	next unless substr($timeOrDate,2,1) eq ':';
+	print FTP "modtime $name\n";
+#	last if $no > 4;
+}
+close FTP;
+
+$SavedTime=0;
+$time=1;
+$SavedName='';
+open (FILES,$TempFile);
+while ($rec = <FILES>)
+{
+	chomp $rec;
+	($junk1, $junk2, $filename) = split / /,$rec if substr($rec,0,4) eq '--->';
+	$time = substr($rec,4) if substr($rec,0,3) eq '213';
+	if (($time > $SavedTime) && (substr($rec,0,3) eq '213'))
+	{
+		$SavedTime=$time;
+		$SavedName=$filename;
+	}
+}
+close FILES;
+$LocalName = $SavedName; $LocalName =~ s=.*/==;
+$LocalName = $LocalDir . $LocalName;
+$Y=substr($SavedTime,0,4);
+$M=substr($SavedTime,4,2);
+$D=substr($SavedTime,6,2);
+$h=substr($SavedTime,8,2);
+$m=substr($SavedTime,10,2);
+$s=substr($SavedTime,12,2);
+print "I should get $SavedName and store it in $LocalName\n";
+open(SH,"|/bin/bash");
+print SH <<zz
+set -x
+echo get $SavedName $LocalName \| ftp $RemoteHost 
+rpm -K $LocalName \|\| exit $?
+touch -t $Y$M$D$h$m.$s  $LocalName
+rpm --rebuild $LocalName
+zz
+;
+close SH;
+
diff --git a/contrib/getmail b/contrib/getmail
new file mode 100755
index 00000000..eec5c6fb
--- /dev/null
+++ b/contrib/getmail
@@ -0,0 +1,73 @@
+#------------------------------------------------------------------------------
+#
+#               GetMail - Fetchmail Daemon Controlling Script
+#
+#             1999 by Thomas Nesges <ThomaNesges@TNT-Computer.de>
+#
+#------------------------------------------------------------------------------
+
+#------------------------------------------------------------------------------
+# GetMail starts/stops fetchmail in daemon mode and logs all actions to
+# /var/log/fetchmail.log. Output is done by tailing the logfile.
+#
+# Sendmail/Fetchmail has to be installed, and your fetchmailrc has to be
+# correctly configured. The option 'got' and 'goth' require a correctly
+# installed GotMail. If you didn't install it in /usr/local/gotmail you 
+# must change the path given.
+#
+# If you have any changes/corrections in the script, please send me email.
+#------------------------------------------------------------------------------
+
+#!/bin/sh
+
+case "$1" in
+  start)
+   sendmail -q
+   date +%d.%m.%Y\ %H:%M:%S\ fetchmail\ started >> /var/log/fetchmail.log
+   fetchmail -d 1 -L /var/log/fetchmail.log &
+   tail -f /var/log/fetchmail.log
+   ;;
+  stop)
+   fetchmail -q
+   date +%d.%m.%Y\ %H:%M:%S\ fetchmail\ stoped >> /var/log/fetchmail.log
+   ;;
+  fetch)
+   date +%d.%m.%Y\ %H:%M:%S\ fetchmail\ started >> /var/log/fetchmail.log
+   fetchmail -d 1 -L /var/log/fetchmail.log &
+   tail -f /var/log/fetchmail.log
+   ;;
+  status)
+   tail -f /var/log/fetchmail.log
+   ;;
+  got)
+   /usr/local/gotmail/gotmail
+   ;;
+  goth)
+   /usr/local/gotmail/gotmail html
+   ;;
+  send)
+   /sendmail -q
+   ;;
+  clear)
+   fetchmail -q
+   rm /var/log/fetchmail.log
+   ;;
+  -v)
+   echo 'getmail version: 0.0.1'
+   ;;
+  *)
+   echo
+   echo 'Usage: getmail option'
+   echo
+   echo 'options:'
+   echo ' clear  - stops fetchmail and kills the logfile' 
+   echo ' fetch  - starts fetchmail'
+   echo ' got    - starts gotmail'
+   echo ' goth   - starts gotmail html'
+   echo ' send   - sends all mail from the mailqueue'
+   echo ' status - tails the logfile'
+   echo ' start  - starts fetchmail and tails the logfile'
+   echo ' stop   - stops fetchmail'
+   echo ' -v     - print the version number'
+   echo	
+esac
diff --git a/contrib/gotmail b/contrib/gotmail
new file mode 100755
index 00000000..8580da6d
--- /dev/null
+++ b/contrib/gotmail
@@ -0,0 +1,69 @@
+#------------------------------------------------------------------------------
+#
+#               GotMail - Statistics Printing Script for GetMail
+#
+#             1999 by Thomas Nesges <ThomaNesges@TNT-Computer.de>
+#
+#------------------------------------------------------------------------------
+
+#------------------------------------------------------------------------------
+# GotMail reads a GetMail logfile (/var/log/fetchmail.log) and prints
+# statistics from all sessions logged in it, either as normal text on the
+# Console, or as an html-file. The parsing is done with the awk-scripts
+# gotmail.awk and gotmail.html.awk.
+# You can configure its output with a file gotmail.conf either in your home,
+# /etc, or in /usr/local/gotmail.
+#
+# GetMail has to be properly installed. For HTML output the htmllib has to be
+# installed in /usr/local/htmllib.
+#
+# If you have any changes/corrections in the script, please send me email.
+#------------------------------------------------------------------------------
+
+
+#!/bin/sh
+
+# Gotmail
+# 1999 by Thomas Nesges <ThomasNesges@TNT-Computer.de>
+
+# read the configuration
+# the configuration can either be
+#  ~/.gotmail.conf
+#  /etc/gotmail.conf
+#  /usr/local/gotmail/gotmail.conf
+if { test -e ~/.gotmail.conf; };
+    then { source ~/.gotmail.conf; };
+    else { if { test -e /etc/gotmail.conf; }; 
+          then { source /etc/gotmail.conf; };
+          else { if { test -e /usr/local/gotmail/gotmail.conf; };
+          then { source /usr/local/gotmail/gotmail.conf; };
+                 else { echo 'Error: gotmail.conf could not be read';
+			echo 'gotmail exits now..';
+			exit; };
+                 fi; };
+          fi; };
+fi;
+
+
+# grep the fetchmail.log for relevant messages and save them in
+# gotmails tempfile
+cat /var/log/fetchmail.log | grep 'message' >> /tmp/gotmail.log.tmp
+cat /var/log/fetchmail.log | grep 'Authorization' >> /tmp/gotmail.log.tmp
+cat /var/log/fetchmail.log | grep 'fetchmail st' >> /tmp/gotmail.log.tmp
+
+
+# parse the gotmail tempfile and prints a statistiks-screen
+case "$1" in
+  html)
+    awk -f /usr/local/htmllib/htmllib.awk -f /usr/local/gotmail/gotmail.html.awk /tmp/gotmail.log.tmp > /dev/null
+    ;;
+  -v)
+    echo 'gotmail version: 0.0.1'
+    ;;
+  *)
+    awk -f /usr/local/gotmail/gotmail.awk /tmp/gotmail.log.tmp
+    ;;
+esac
+
+# remove the gotmail tempfile
+rm /tmp/gotmail.log.tmp
diff --git a/contrib/gotmail.awk b/contrib/gotmail.awk
new file mode 100644
index 00000000..9c967ade
--- /dev/null
+++ b/contrib/gotmail.awk
@@ -0,0 +1,62 @@
+#-----------------------------------------------------------------------------
+#
+#                           Gotmail - gotmail.awk
+#
+#             1999 by Thomas Nesges <ThomasNesges@TNT-Computer.de>
+#
+#-----------------------------------------------------------------------------
+
+#-----------------------------------------------------------------------------
+# This script is part of GotMail. It gives back normal text to the console
+#-----------------------------------------------------------------------------
+
+{
+  if($2!="reading")
+  {
+	if(($3=="message") || ($3=="messages"))
+	{	
+		Mails = Mails sprintf(" %- 40s ",substr($5,1,40))
+		Mails = Mails sprintf(" %- 5s ",substr($2,1,5))
+		Mails = Mails sprintf(" %- 30s\n",substr($7,1,30))
+	}
+	else if($3=="fetchmail")
+	{
+		Started = Started " " $0 "\n"
+	}
+	else
+	{
+		Errors = Errors $0 "\n"
+	}
+  }
+}
+
+END	{
+		Separator = "-------------------------------------------------------------------------------"
+		if(ENVIRON["GOTM_HED"]=="yes")
+		{
+			print "\n\t\t---------------------------------------"
+			print "\t\t| ** GotMail - Stats for fetchmail ** |"
+			print "\t\t---------------------------------------"
+		}
+		if(ENVIRON["GOTM_MSG"]=="yes")
+		{
+			print Separator 
+			print "|    Fetched Mails:"
+			print Separator 
+			print Mails
+		}
+		if(ENVIRON["GOTM_ERR"]=="yes")
+		{
+			print Separator 
+			print "|    Error Messages:"
+			print Separator 
+			print Errors
+		}
+		if(ENVIRON["GOTM_TIM"]=="yes")
+		{
+			print Separator
+			print "|    Fetchmail started/stoped:"
+			print Separator
+			print Started
+		}
+	}
diff --git a/contrib/gotmail.conf b/contrib/gotmail.conf
new file mode 100644
index 00000000..08087936
--- /dev/null
+++ b/contrib/gotmail.conf
@@ -0,0 +1,25 @@
+#!/bin/sh
+
+# Print Statistiks for Error-Messages
+  export GOTM_ERR="yes"
+# Print Statistiks for fetched Messages
+  export GOTM_MSG="yes"
+# Print Statistiks for Start/Stop-Messages
+  export GOTM_TIM="yes"
+# Print Statistiks with Header
+  export GOTM_HED="yes"
+
+# Special HTML Options
+
+# Background Color
+  export GOTM_BGCOL="#FFFFFF"
+# Text Color
+  export GOTM_TXCOL="#000000"
+# Error-Messages Color
+  export GOTM_ERRCOL="#DD3030"
+# Start/Stop-Messages Color
+  export GOTM_TIMCOL="#30FF30"
+# Normal Messages Color
+  export GOTM_MSGCOL="#FDFCCC"
+# Ouput File
+  export GOTM_HTMLFILE="/usr/local/gotmail/gotmail.html"
diff --git a/contrib/gotmail.html.awk b/contrib/gotmail.html.awk
new file mode 100644
index 00000000..ba111a64
--- /dev/null
+++ b/contrib/gotmail.html.awk
@@ -0,0 +1,99 @@
+#-----------------------------------------------------------------------------
+#
+#                           Gotmail - gotmail.awk
+#
+#             1999 by Thomas Nesges <ThomasNesges@TNT-Computer.de>
+#
+#-----------------------------------------------------------------------------
+
+#-----------------------------------------------------------------------------
+# This script is part of GotMail.  It emits html to a specified File
+# The AWK-Library htmllib has to be properly installed.
+#-----------------------------------------------------------------------------
+
+#-----------------------------------------------------------------------------
+function init_environ()
+{
+	TextColor = ENVIRON["GOTM_TXCOL"]
+	BackColor = ENVIRON["GOTM_BGCOL"] 
+	MsgColor  = ENVIRON["GOTM_MSGCOL"]
+	ErrColor  = ENVIRON["GOTM_ERRCOL"]
+	TimColor  = ENVIRON["GOTM_TIMCOL"]
+	OutFile   = ENVIRON["GOTM_HTMLFILE"]
+	PrintMsg  = toupper(ENVIRON["GOTM_MSG"])
+	PrintErr  = toupper(ENVIRON["GOTM_ERR"])
+	PrintTim  = toupper(ENVIRON["GOTM_TIM"])
+	PrintHed  = toupper(ENVIRON["GOTM_HED"])
+	
+}
+#-----------------------------------------------------------------------------
+
+#-----------------------------------------------------------------------------
+{
+  init_environ()
+  if($2!="reading")
+  {
+	if($3=="messages")
+	{
+		Mails = Mails TableRow("start", MsgColor)	
+		Mails = Mails TableItem($5) TableItem($7)
+		Mails = Mails TableItem(Align($2,0)) 
+		Mails = Mails TableRow("stop")
+	}
+	else if($3=="fetchmail")
+	{
+		Times = Times TableRow("start", TimColor)
+		Times = Times TableItem($0)
+		Times = Times TableRow("stop")
+	}
+	else
+	{
+		Errors = Errors TableRow("start", ErrColor)	
+		Errors = Errors TableItem($0)
+		Errors = Errors TableRow("stop")	
+	}
+  }
+}
+#-----------------------------------------------------------------------------
+END	{
+	Stats = StartPage(Title("Gotmail Stats") Body(BackColor, TextColor))
+	if(PrintHed == "YES")
+	{
+		Stats = Stats Align(Headline("Gotmail Stats",1),0) 
+		Stats = Stats Divider Newline
+	}
+	if(PrintMsg == "YES")
+	{
+		Stats = Stats TableStart(1)
+		Stats = Stats TableRow("start", MsgColor)
+		Stats = Stats TableItem(Bold("Account"))
+		Stats = Stats TableItem(Bold("Server"))
+		Stats = Stats TableItem(Bold("Mails fetched"))
+		Stats = Stats TableRow("stop")
+		Stats = Stats Mails TableEnd Newline Divider Newline
+	}
+
+	if(PrintErr == "YES")
+	{
+		Stats = Stats TableStart(1) 
+		Stats = Stats TableRow("start", ErrColor)
+		Stats = Stats TableItem(Bold("Error Messages"))
+		Stats = Stats TableRow("stop")
+		Stats = Stats Errors TableEnd Newline Divider 
+	}
+
+	if(PrintTim == "YES")
+	{
+		Stats = Stats TableStart(1)
+		Stats = Stats TableRow("start", TimColor)
+		Stats = Stats TableItem(Bold("Start/Stop Times"))
+		Stats = Stats TableRow("stop")
+		Stats = Stats Times TableEnd Newline Divider
+	}
+
+	Stats = Stats Center("start") "GotMail - 1999 by Thomas Nesges " 
+	Stats = Stats "<ThomasNesges@TNT-Computer.de>" Center("stop") EndPage
+
+	print Stats > OutFile
+	}
+#-----------------------------------------------------------------------------
diff --git a/contrib/ip-up b/contrib/ip-up
new file mode 100644
index 00000000..542448d9
--- /dev/null
+++ b/contrib/ip-up
@@ -0,0 +1,70 @@
+From James.Stevens@jrcs.co.uk  Mon Aug 25 18:11:36 1997
+Return-Path: <James.Stevens@jrcs.co.uk>
+Received: from locke.ccil.org (snark [10.0.2.15])
+	by snark.thyrsus.com (8.8.5/8.8.5) with ESMTP id SAA10394
+	for <esr@snark.thyrsus.com>; Mon, 25 Aug 1997 18:11:34 -0400
+Received: (from slist@localhost)
+	by locke.ccil.org (8.8.5/8.8.5) id GAA17071
+	for esr; Mon, 18 Aug 1997 06:17:07 -0500 (EST)
+Resent-Date: Mon, 18 Aug 1997 06:17:07 -0500 (EST)
+X-Authentication-Warning: locke.ccil.org: slist set sender to fetchmail-friends-request@ccil.org using -f
+X-NiNLog: [James.Stevens@jrcs.co.uk] [<fetchmail-friends@locke.ccil.org>] [199708180955.KAA04988]
+Message-ID: <33F81C2D.AB822BBB@jrcs.co.uk>
+Date: Mon, 18 Aug 1997 10:55:57 +0100
+From: James Stevens <James.Stevens@jrcs.co.uk>
+Reply-To: James.Stevens@jrcs.co.uk
+Organization: JRCS Ltd
+X-Mailer: Mozilla 4.01 [en] (Win95; I)
+MIME-Version: 1.0
+To: "fetchmail-friends@locke.ccil.org" <fetchmail-friends@locke.ccil.org>
+Subject: A Little Tip...
+X-Priority: 3 (Normal)
+Content-Type: text/plain; charset=us-ascii
+Content-Transfer-Encoding: 7bit
+Resent-Message-ID: <"lhVgRB.A.FFE.bxC-z"@locke.ccil.org>
+Resent-From: fetchmail-friends@ccil.org
+X-Mailing-List: <fetchmail-friends@ccil.org> archive/latest/725
+X-Loop: fetchmail-friends@ccil.org
+Precedence: list
+Resent-Sender: fetchmail-friends-request@ccil.org
+Status: RO
+
+Seeing Eric tip us that we could run a "fetchmail -quit" in the
+"ip-down" script, I thougt it would be neat to run a fetchmail
+collection in the "ip-up" script. That way mail is collected
+automatically every time I am connecting to Internet for whatever reason
+(I use "diald" to automatically manage my connection).
+
+However, it did not work. It hung right after the POP3 login. I tracked
+this down to the fact that the "pppd" masks a wide range of signals and
+this means a time-out does not kick in. As I run the "ip-up" script in
+"bash" this masking is inheritied by "fetchmail".
+
+So, I wrote a silly little "C" program that unmasks all signals and then
+runs a command of you choice (in this case fetchmail). This is the code
+for that program :-
+
+#include <stdio.h>
+#include <signal.h>
+
+main(int argc,char * argv[])
+{
+sigset_t set;
+
+    if (argc>1)
+        {
+        sigfillset(&set);
+        sigprocmask(SIG_UNBLOCK,&set,NULL);
+        system(argv[1]);
+        }
+}
+
+I call it "allsigs". So, now in my "ip-up" I have the line :-
+
+allsigs "fetchmail -f /etc/fetahmail"
+
+Note the quotes as "allsigs" only looks at argv[1]. I guess this
+unmasking of all signals could be added into "fetchmail" ?
+
+James
+
diff --git a/contrib/login b/contrib/login
new file mode 100755
index 00000000..952594af
--- /dev/null
+++ b/contrib/login
@@ -0,0 +1,16 @@
+#	~/.bash_login
+#
+
+#	Start Fetchmail up when I Login.
+#
+#	TDEV=my PRESENT terminal device IE: ttyp2, tty5, ....
+#
+export TDEV=`tty | sed -n -e "s#/dev/##p"`
+#
+if [ ! -s ~/.fetchmail ]; then
+    /usr/local/bin/fetchmail -d 300
+    echo "owner" >.fetchmail.$TDEV
+else
+    echo "notowner" >.fetchmail.$TDEV
+fi
+# END of Fetchmail startup
diff --git a/contrib/logout b/contrib/logout
new file mode 100755
index 00000000..96c9111d
--- /dev/null
+++ b/contrib/logout
@@ -0,0 +1,30 @@
+#	~/.bash_logout
+#	Clean things up when I Exit.
+
+# Below is for Fetchmail clean up
+#
+#	TDEV=my PRESENT terminal device IE: ttyp0, tty5, .....
+#
+export TDEV=`tty | sed -n -e "s#/dev/##p"`
+#
+if [ -s ~/.fetchmail ]; then
+#
+    if [ -s ~/.fetchmail.$TDEV ]; then
+	TEST=`/usr/bin/grep 'notowner' ~/.fetchmail.$TDEV`
+#
+        if [ ! -z $TEST ]; then
+	    /bin/rm -rf ~/.fetchmail.$TDEV
+	elif [ -z $TEST ]; then
+	    /bin/rm -rf ~/.fetchmail.$TDEV
+	    /usr/local/bin/fetchmail -q >/dev/null 2>&1
+	fi
+#
+    else
+	echo "WARNING: A process either did not record a ~/.fetchmail.$TDEV" >> ~/.fetchmail.warning.$TDEV
+	echo "WARNING: Or removed the file manually ." >> ~/.fetchmail.warning.$TDEV
+    fi
+#
+else
+    echo "WARNING: parent process has exit'ed & removed primary ~/.fetchmail.$TDEV " >> ~/.fetchmail.warning.$TDEV
+fi
+# END of Fetchmail clean up
diff --git a/contrib/maildaemon b/contrib/maildaemon
new file mode 100755
index 00000000..3728c333
--- /dev/null
+++ b/contrib/maildaemon
@@ -0,0 +1,75 @@
+#!/bin/sh
+#
+# maildaemon, fetchmail driver intended to be invoked hourly by cron.
+#
+# Script by Larry Fahnoe <fahnoe@kegworks.mn.org>, who writes:
+#
+# This is intended to support a standalone system (NeXTSTEP in this case) 
+# which makes manual, on-demand PPP connections to the outside world.  The
+# script is run as the target user from cron on an hourly basis.  If it
+# finds a PPP link is up (it sees routes on a PPP interface), fetchmail is
+# invoked.  If the link is not up, and the hour is in the list of hours that
+# connections should be made, the link is brought up and fetchmail is
+# invoked.  The program or script used to bring up the link should return an
+# exit status which reflects whether the link actually came up. 
+# 
+# I wrote this because I wanted to be able to have control over the amount
+# of time spent connected to an ISP and yet still be able to poll for mail
+# at intervals that made sense to me.  One limitation of this script is that
+# it does not take into account that an existing PPP link might be going to
+# a different ISP or network.
+#
+
+# You'll have to configure these
+USER=fahnoe			# your name
+HOME=/Users/fahnoe		# home directory (for the logfile)
+FORCEHOURS="05 09 13 17"	# when to bring the link up if it's not already
+SERVER=mailserver.isp.com	# mailserver host name
+
+# Link initialization and wrapup scripts (you may have to configure these)
+PPPUP="/usr/local/bin/pppup $SERVER"
+PPPDOWN=/usr/local/bin/pppdown
+
+PATH=/usr/local/bin:/bin:/usr/ucb:/usr/bin:/usr/etc
+export PATH USER HOME
+
+LOG=$HOME/log/maildaemon.log
+
+# get the mail, depends on $HOME/.fetchmailrc and $USER
+FETCHMAIL( ) {
+    ( echo "`date` $SERVER"
+      fetchmail $SERVER
+      if [ $? -gt 1 ]
+      then
+          echo "`date` $SERVER (evil things happened in fetchmail)"
+      fi
+    ) >> $LOG 2>&1
+}
+
+# if the link is already up, check for mail.
+# if the hour is in FORCEHOURS, force the link up and check for mail.
+(netstat -rn | awk '{ print $6 }' | grep ppp[0-9] > /dev/null)
+if [ $? -eq 0 ]
+then
+    FETCHMAIL
+else
+    hour=`date | sed -e 's/:/ /g' | awk '{ print $4 }'`
+    for x in $FORCEHOURS
+    do
+        if [ $hour = $x ]
+        then
+            $PPPUP
+            if [ $? -eq 0 ]
+            then
+                FETCHMAIL
+                $PPPDOWN
+            else
+                echo "`date` $SERVER (link establishment failure)" >> $LOG
+                exit 1
+            fi
+        fi
+    done
+fi
+
+exit
+
diff --git a/contrib/mailqueue.pl b/contrib/mailqueue.pl
new file mode 100644
index 00000000..50acb831
--- /dev/null
+++ b/contrib/mailqueue.pl
@@ -0,0 +1,420 @@
+#!/usr/bin/perl
+# This is script will connect to your isp (if not already connected),
+#   send any outgoing mail and retrieve any incoming mail.  If this
+#   program made the connection, it will also break the connection
+#   when it is done.
+#
+# Bill Adams
+# bill@evil.inetarena.com
+#
+# Revision History
+# 1.0.1   05 Sep 1998  baa  Massive updates to work with fetchmail.
+# 
+# Get the latest version from my home-page:
+#  http://www.inetarena.com/~badams/computerstuff.html
+#  following the 'Stuff I Have Written' link.
+#
+# License: GNU, but tell me of any improvements or changes.
+#
+use strict;
+
+my $suck;
+my $rdate;
+my ($my_syslog, $debug, $verbose);
+
+my $start_time = time;
+my $mailhost = 'mail';
+my $sendmail_queue_dir = '/var/spool/mqueue/';	#Need trailing slash!
+my $interface = 'ppp0';         #Watch this interface
+my $max_tries = 1;		#How many times to try and re-dial
+my $retry_delay = 300;	        #How long to wait to retry (in seconds)
+my $connect_timeout = 45;	#How long to wait for connection
+
+#For the log file, be sure to put the >, >>, or | depending on
+#  what you want it to do.  I have also written a little program
+#  called simple_syslog that you can pipe the data to.
+my $log_file = '>/dev/null';    #Where to put the data.
+$log_file = '>>/var/log/mailqueue.pl';
+#$log_file = '>/dev/console';
+
+my $this_hour = +[localtime()]->[2];
+
+#Define this to get mail between midnight and 5 am
+#$suck = '/var/spool/suck/get.news.inn';
+
+#Define this to set the time to a remote server
+#$rdate = '/usr/bin/rdate -s clock1.unc.edu';
+
+#Where are the programs are located.  You can specify the full path if needed.
+my $pppd = 'pppd';
+my $fetchmail = 'fetchmail'; #'etrn.pl';
+my $sendmail = 'sendmail';
+
+#Where is the etrn/fetchmail pid
+my $fetchmail_pid = '/var/run/fetchmail.pid';
+
+
+#Set the path to where we think everything will live.
+$ENV{'PATH'} = ":/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:";
+my $lockfile = "/var/run/mailqueue.lock";	#lockfile for this program
+my $space = ' ';			#Never know when you might need space
+my $program_name = $0;
+$program_name = substr ($program_name, (rindex ($program_name, '/') + 1));
+open SYSLOG, $log_file or die "Could not open $log_file\n\t";
+
+sys_log ("Started by UID $<");
+#$< = 0;					#suid root
+
+#Other global vars
+my $pppd_pid;
+
+#Make sure we are root.  This has to be the case for everything
+#  to work properly.
+if ($< != 0) {
+    sys_log ("Not root...exit");
+    print STDERR "You are not root...sorry cannot run.\n";
+    exit (1);
+}
+
+sub sys_log {
+    #Writes a message to the log file.
+    my ($message) = @_;
+    print SYSLOG join(' ', 
+		      $program_name,
+		      ''.localtime(), #The '' puts it in a scaler context.
+		      $message)."\n";
+    print STDERR $message, "\n" if $debug;
+}
+
+#Get the command line args.
+$verbose = 1;
+for (my $i = 0; $i <= $#ARGV; $i++) {
+    if ($ARGV[$i] eq '-v' || $ARGV[$i] eq '-verbose') {
+	$verbose++;
+	print "Running in verbose mode level ($verbose).\n";
+    } elsif ($ARGV[$i] eq '-d' || $ARGV[$i] eq '-debug') {
+	$debug++;
+	$verbose = 10;	#Some high value so everything gets printed
+	print STDERR "Running in debug mode.\n";
+    } elsif ($ARGV[$i] eq '-q' || $ARGV[$i] eq '-quiet') {
+	$debug = 0;
+	$verbose = 0; 
+    } elsif ($ARGV[$i] eq '-max_tries') {
+	if (not defined $ARGV[$i + 1]) {
+	    printf STDERR "$0: Error: option -max_tries requires a value.\n";
+	    &usage;
+	} else {
+	    $max_tries = $ARGV[$i + 1];
+	}
+    } elsif ($ARGV[$i] eq '-retry_delay') {
+	if (not defined $ARGV[$i + 1]) {
+	    printf STDERR "$0: Error: option -retry_delay requires a value.\n";
+	    &usage;
+	} else {
+	    $max_tries = $ARGV[$i + 1];
+	}
+    } elsif ($ARGV[$i] eq '-interface') {
+	if (not defined $ARGV[$i + 1]) {
+	    printf STDERR "$0: Error: option -interface requires a value.\n";
+	    &usage;
+	} else {
+	    $max_tries = $ARGV[$i + 1];
+	}
+    } elsif ($ARGV[$i] eq '-mailhost') {
+	if (not defined $ARGV[$i + 1]) {
+	    printf STDERR "$0: Error: option -mailhost requires a value.\n";
+	    &usage;
+	} else {
+	    $mailhost = $ARGV[$i + 1];
+	}
+    } else {
+	print STDERR "Unknown command line option: [". $ARGV[$i]."]\n";
+	&usage;
+    }
+}
+
+
+$| = 1 if $verbose;			#Output un-buffered if we are verbose
+
+
+#Do some checking for programs
+&check_program ($my_syslog) || die "$0 -> Error: $my_syslog is required\n";
+($fetchmail = &check_program ($fetchmail)) 
+    || die "$0 -> Error: Could not find fetchmail/etrn\n";
+($pppd = &check_program ($pppd))
+    || die "$0 -> Error: Could not find pppd\n";
+(-d $sendmail_queue_dir) || die "$0 -> Error: The sendmail queue directory\n\t[$sendmail_queue_dir] does not exist or is not a directory.\n";
+($sendmail = &check_program ($sendmail)) 
+    || die "$0 -> Error: Could not find $sendmail\n";
+
+
+#Do some process locking.  This kills any already running processes.
+if (-s $lockfile) {
+    my $pid = `cat $lockfile`; chop $pid;
+    if (not &process_is_dead ($pid)) {
+	print STDERR "$0 -> Process locked by pid $pid killing it.\n" 
+	    if $verbose;
+	kill 15, $pid;
+	waitpid ($pid, 0); #This has no effect.
+    }
+    sys_log ("Removing stale lock for pid $pid") if $verbose;
+    unlink ($lockfile) || die $!;
+}
+open (LOCK, '>'.$lockfile) || die "$0: Could not create lockfile $lockfile\n";
+print LOCK $$, "\n";
+close LOCK;
+
+#print out some info if needed.
+if ($debug) {
+    print STDERR "             Max tries: $max_tries\n";
+    print STDERR "      Dial Retry Delay: $retry_delay seconds.\n";
+    print STDERR "Interface set to watch: $interface\n";
+    print STDERR " Mailhost set to watch: $mailhost\n";
+    print STDERR "    Connection timeout: $connect_timeout\n";
+    print STDERR "              Sendmail: $sendmail\n";
+    print STDERR "                  pppd: $pppd\n";
+    print STDERR "     fetchmail/etrn.pl: $fetchmail\n";
+    print STDERR "\n\n";
+}
+((-x $pppd) && (-x $sendmail) && (-x $fetchmail)) 
+	|| die "Still some problem with programs.\n\tRun with -d to see if the path is specified for sendmail,\n\tpppd and fetchmail/etrn.pl";
+
+while ($max_tries--) {
+    my $child_pid;
+    unless ($child_pid = fork)  {
+	#This is the child process that waits for a connection to be made
+	#  and then sends the local mail queue and then sends a request to
+	#  get the remote mail queue
+	my $count = $connect_timeout;
+	while (&interface_is_down ($interface) && $count--) {sleep (1)}
+	if ($count < 1) {exit (1)}
+	
+	#Send any queued mail.  I had another routine that would
+	#  fork and watch sendmail with a timeout, but that is kinda
+	#  flaky depending on how big your queue size is. So
+	#  now just call it and wait for it to return.  If you have bad
+	#  messages in your queue, this can hang.
+	sys_log ("Have connection->sending any local mail.") if $verbose;
+	system("$sendmail -q");
+
+	sys_log ("Checking remote queue on ($mailhost)");
+
+	my $result;
+	my $daemon = 0;
+	my $pid;
+	#In case we have a pid, read it and find out if it is
+	#  still valid or not.
+	if (defined $fetchmail_pid and -f $fetchmail_pid) {
+	    if (not open PID, $fetchmail_pid) {
+		sys_log("Could not open $fetchmail_pid");
+		die}
+	    $pid = <PID>;
+	    if ($pid =~ m|([0-9]+)\s+([0-9]*)|) {
+		$pid = $1;
+		$daemon = $2;
+	    }
+	    close PID;
+	    sys_log("Have PID file ($fetchmail_pid) with PID $pid $daemon");
+	    #In the case of fetchmail, we need to see if it is
+	    #  still running in case there is a stale lock file.
+	    if (&process_is_dead($pid)) {
+		sys_log("  It is no longer running");
+		$daemon = 0; $pid = 0}
+	}
+	if (not $pid or ($pid and $daemon)) {
+	    #Either it is not running or it is running and a daemon.
+	    sys_log("Running $fetchmail [$daemon]");
+	    my $result = (system ($fetchmail))/256;
+	    sys_log($fetchmail.' exited with status '.$result) if $debug;
+	} else {
+	    sys_log("$fetchmail already running...");
+	}
+
+	#Watch the directory for n seconds of inactivity.
+	sys_log("Fetchmail done...watching $sendmail_queue_dir");
+	&watch_dir ($sendmail_queue_dir, 10);
+	sys_log ("Done polling for mail");
+	
+	if (-f $fetchmail_pid and not $daemon) {
+	    #In case something went wrong and the fetchmail is still 
+	    # running (and not a daemon)....
+	    my $result = `$fetchmail -q`; chop $result;
+	    sys_log($result);
+	}
+	exit (0);
+    }
+    #If a connection is needed, make it.
+    if (&interface_is_down ($interface) && $pppd_pid == 0) {
+	sys_log ("Try to connect with pppd") if $debug;
+	# Fork pppd with a pid we can track.
+	unless ($pppd_pid = fork) {
+		exec ($pppd.' -detach');
+	}
+    }
+    #Wait for the child to exit and check for errors
+    waitpid ($child_pid, 0);
+    my $child_status = ($? / 256);
+    my $child_kill = $? % 256;
+    if ($child_status == 0) {
+	if ($this_hour <= 4 and defined $suck) {
+	    sys_log ("Calling suck...");
+	    print `$suck`;
+	}
+	if (defined $rdate) {
+	   sys_log ("Calling rtime...");
+	   print `$rdate`;
+	}
+	if ($pppd_pid) { 	#If we ran pppd, kill it
+	    sys_log ("Killing pppd (pid $pppd_pid)");
+	    kill 15, $pppd_pid;
+	    waitpid ($pppd_pid, 0);	#Wait for clean exit of child
+	}
+	sys_log ("Finished with cycle.");
+	unlink ($lockfile);
+	sys_log ("Total time: ".(time-$start_time)." seconds") if $debug;
+	exit (0);
+    }
+    # Reset to pppp_pid to zero if pppd is not running.
+    if ($pppd_pid && &process_is_dead ($pppd_pid)) {$pppd_pid = 0}
+    sys_log (join ('', "Warn: Did not connect -> Try ",
+		   $max_tries, " more times...after ",
+		   $retry_delay, " seconds"));
+    if (not $max_tries) {
+	sys_log ("Giving up...");
+	exit (1);
+    }
+    sleep ($retry_delay);
+    sys_log ("ok...trying again.");
+}
+
+sub check_program {
+    #See if a program is in the path
+    my ($program) = @_;
+    my $exists = 0;
+    my $path_specified = 0;
+    my $path;
+    
+    #catch the case where there is already a slash in the argument.
+
+    if ($program =~ /\//) {
+	$path_specified = 1;
+	if (-x $program) {$exists = $program}
+    }
+
+    my $exists;
+    foreach $path (split(/:/, $ENV{'PATH'})) {
+	next if length ($path) < 3;		#skip bogus path entries
+	#be sure the there is a trailing slash
+	if (substr ($path, -1, 1) ne '/') {$path .= '/'}
+	#Check to see if it exists and is executable
+	if (-x $path.$program) {$exists = $path.$program; last}
+    }
+    if (not $exists) {
+	if ($path_specified) {
+	    print STDERR "$0 -> Warn: ". $program. 
+		" is not executable or does not exist.\n";
+	} else {
+	    print STDERR "$0 -> Warn: [$program] was not found in path\n\t".
+		$ENV{'PATH'}."\n";
+	}
+    }
+    return ($exists);
+}
+
+
+sub process_is_dead {
+    #This is a cheap way to check for running processes.  I could use
+    #  the /proc file-system in Linux but that would not be very 
+    #  friendly to other OS's.
+    #
+    #return 1 if pid is not in process list
+    # This expects ps to return a header line and then another line if
+    #  the process is running.  Also check for zombies
+    my ($pid) = @_;
+    my @results = split (/\n/, `ps $pid 2>/dev/null`);
+    if (not defined $results[1]) {return  1}
+    if ($results[1] =~ /zombie/i) {return 1}
+    return 0;
+}
+
+
+sub interface_is_down {
+    # return 1 (true) if the ip is down
+    my ($interface) = @_;
+    if (`ifconfig $interface` =~ /UP/) {
+	return 0;
+    } else {
+	return 1;
+    }
+}
+
+sub watch_dir {
+    #Watch the mailqueue directory for incoming files.
+    #  The 'xf' files are the transfer (xfer) files on my system.
+    #  If you find this is not the case, please email me.  To be safe,
+    #  I check the latest mod time as long as xf files exist.  If no
+    #  data has made it over in n seconds, we will assume that an
+    #  error has occured and give up.
+
+    my $files_like = '^(xf.*)'; #Regexp
+    my $dir_to_watch = shift;
+    my $delay = shift;
+    my $timeout = 120;  #Give it 120 seconds to get data.
+    my $loop_delay = 1; #How long between each loop. Do not make 0!
+
+    #Make sure there is a trailing slash.
+    if ($dir_to_watch !~ m|/$|) {$dir_to_watch .= '/'}
+
+    #How long to wait for transfer of data.  This gets reset
+    #  each time the mod time falls below a certain time.
+    my $flag = $delay;	
+    my $last_total = 0;
+    
+    while (($flag -= $loop_delay) > 0) {
+	sleep $loop_delay;
+	opendir (DIR, $dir_to_watch);
+	my $file_count = 0;
+	my $last_data_dl = 500000; #Big Number
+	foreach my $file (readdir (DIR)) {
+	    next if not -f $dir_to_watch.$file; #Only files.
+	    my @stats = stat($dir_to_watch.$file);
+	    my $m_time = time - $stats[9];
+	    #Here, if we have a recent file, reset the timeout.
+	    if ($m_time < $last_data_dl) {$last_data_dl = $m_time}
+	    
+	    #If we have an xfer file, up the delay.
+	    if ($file =~ m|$files_like|) {
+		sys_log("$file is like $files_like");
+		$flag = $delay;
+	    }
+	}
+	closedir (DIR);
+	sys_log ("Watch_dir: $flag ($last_data_dl)") if $debug;
+
+	#In the case of now data downloaded...
+	if ($last_data_dl > $timeout and $flag == $delay) {
+	    sys_log("Watch_dir: Timed out after $timeout seconds.");
+	    $flag = 0;
+	}
+    }
+    sys_log ("Watch_dir: Done.");
+}
+
+sub usage {
+    #print the usage
+    print join ("\n",
+		'mailqueue.pl -- A program to send and receive mail form a sendmail spooler.',
+		'  Requires that you ISP is running sendmail, at lease version 8.6.?.',
+		'  Also requires that you have fetchmail or etrn.pl installed on this system.',
+		'', 'Command line args (Default in parrens):',
+		'  -v -verbose         Run in verbose mode.  Can use this arg multiple times.',
+		'  -d -debug           Run in debug mode.  Sets verbose level to 10',
+		'  -max_tries N	       Sets the maximum number of connect retries to N.  ('.$max_tries.')',
+		'  -retry_delay N      Sets the delay between retrying to N seconds.  ('. $retry_delay.')',
+	        "  -connect_timeout N  Sets the connection timeout to N seconds. (". $connect_timeout. ')',
+		'  -interface STR      Sets the default interface to STR.  ('. $interface. ')',
+		'  -mailhost STR       Sets the mailhost to STR. ('. $mailhost.')',
+		'');
+    exit (1);
+}
+
diff --git a/contrib/mold_remover.py b/contrib/mold_remover.py
new file mode 100644
index 00000000..1ccba7c3
--- /dev/null
+++ b/contrib/mold_remover.py
@@ -0,0 +1,92 @@
+# Mold Remover
+# A short python script to remove old read mail from a pop3 mailserver.
+# Dovetails with fetchmail with keep option.
+# Run it as a cron job...
+# Version 0.1 by James Stone (stone1@btinternet.com)
+# please submit bug reports and code optimisations as you see fit!
+
+import string
+import poplib
+import time
+
+#user editable section
+mailserver=["mail.server1","mail.server2"] #list of mailservers
+login=["login1","login2"] #list of logins for corresponding mailserver
+password=["pass1","pass2"] #list of passwords (note: chmod 700 for this script)
+days=2 #number of days to keep on server.
+localuidlcache="/var/mail/.fetchmail-UIDL-cache" #fetchmail's UIDL cache
+localuidldate="/var/mail/.UIDLDate" #mold remover's UIDL datefile
+#end of user editable section
+
+readfile=open(localuidlcache, 'r')
+datefile=open(localuidldate, 'a+')
+tempfile=open("/tmp/uidltmp", 'w+')
+popuidllist=[] #list of undeleted uidls on all servers
+totnum=0 #number of undeleted messages on all servers
+connectedto=-1
+
+#connect to each mailserver get all the new message UIDLs and delete any
+#expired messages.
+
+for a in range(len(mailserver)):
+    connect=poplib.POP3(mailserver[a])
+    connect.user(login[a])
+    connect.pass_(password[a])
+    connectedto=a
+    number,size=connect.stat()
+    totnum+=number
+    for mesnum in range(number):
+        messagedeleted=0
+        datefile.seek(0)
+        for uidldate in datefile:
+            uidldatesplit=uidldate.split(' ')
+            if(connectedto==int(uidldatesplit[2])):
+                if (time.time()-float(uidldatesplit[1]))>(86400*days):
+                    try:
+                        recheckuidl=connect.uidl(mesnum+1)
+                        recheckuidlsplit=recheckuidl.split(' ')
+                        if (recheckuidlsplit[2]==uidldatesplit[0]):
+                            print('deleting'+recheckuidlsplit[1])
+                            print(connect.dele(recheckuidlsplit[1]))
+                            messagedeleted=1
+                            totnum-=1
+                    except poplib.error_proto:
+                        pass #skip over messages that have already been deleted.
+        if not(messagedeleted):
+            popuidllist.append(connect.uidl(mesnum+1)+' '+str(a))
+    connect.quit()        
+
+
+#get rid of lines in uidldate file corresponding to the messages that have been
+#expired (and hopefully been deleted)
+
+datefile.seek(0)
+for uidldate in datefile:
+    uidldatesplit=uidldate.split(' ')
+    if not(time.time()-float(uidldatesplit[1]))>(86400*days):
+        tempfile.write(uidldate)
+datefile.close()
+datefile=open(localuidldate,'w+')
+tempfile.seek(0)
+for line in tempfile:
+        datefile.write(line)
+datefile.close()
+datefile=open(localuidldate,'a+')
+
+#add date to uidl for any messages still on the server which have been read 
+#(check in readfile) and store in local datefile.
+
+for mesnum in range(totnum):    
+            popuidl=popuidllist[mesnum]
+            popuidlsplit=popuidl.split(' ')
+            readfile.seek(0)
+            for localuidl in readfile:
+                if(localuidl.find(popuidlsplit[2])<>-1):
+                    foundindatefile=0
+                    datefile.seek(0)
+                    for stored in datefile:
+                        if (stored.find(popuidlsplit[2])<>-1):
+                            foundindatefile=1
+                    if not(foundindatefile):
+                        datefile.write(popuidlsplit[2]+' '+str(time.time())+' '
+                            +popuidlsplit[3]+'\n')
diff --git a/contrib/multidrop b/contrib/multidrop
new file mode 100644
index 00000000..37f87b4c
--- /dev/null
+++ b/contrib/multidrop
@@ -0,0 +1,236 @@
+From mlievaart@orion.nl  Mon Jan 10 10:46:33 2000
+From: Martijn Lievaart <mlievaart@orion.nl>
+To: Eric S. Raymond <esr@thyrsus.com>
+Date: zondag 9 januari 2000 0:38
+Subject: Re: Thanks for fetchmail and a solution to the multidrop problem (I
+Status: O
+Content-Length: 8086
+Lines: 226
+
+think)
+
+Hello Eric,
+
+Let me first state that I'm no sendmail nor unix guru, so although this
+seems to work, I certainly would not say this is the "best" solution. In
+fact I would welcome all comments to make this better. In particular, it
+seems that that the mailertable feature was made just for this, but I'm
+still studying that.
+
+Also, This mail will have lines wrapped. I will put up this on a website
+asap, so people can download the relevant portions. In the meantime, I'm
+using (stuck on) Outlook, so I won't even attempt to format this mail.
+Accept my apoligies and try to mentally reconnect the lines.
+
+Finally, this mail is a bit lengthy, but I guess it is better to get all
+information in, so please bear with me.
+
+After some very frustrating attempts to get multidrop to work reliably, it
+suddenly hit me. When sendmail has translated the recipient to the mailbox,
+the recipient is gone (in the cases we're talking about). So the solution is
+not to let sendmail do this translation (completely).
+
+The trick is to let a custom MDA be called with both the mailbox and the
+full recipient name. This MDA then just stuffs it in the correct mailbox
+after adding the appropriate headers. Luckily I hit on the formail utility.
+It reformats a mailmessage and does just what I wanted. Specifically my
+script uses it to:
+- add a custom header (default: "Delivered-To:") with the recipient
+- rewrite the message-ID, so fetchmail will download the same message
+multiple times.
+- add another header, just for fun.
+
+The rewriting of the message-ID is needed because fetchmail will suppress
+multiple messages with the same ID, normally a good idea, but now it gets in
+the way. A switch on fetchmail to suppress this behaviour would be great.
+
+At first I hardcoded the domains in the sendmail.cf, but I quickly set out
+to do one better and came up with the following solution. In sendmail.cf,
+add the following line somewhere at the top.
+
+Kmultidroptable hash -o /etc/mail/multidroptable
+
+this defines a table for all domains we want to use multidrop for. The
+format of this file is multiple lines of the format:
+<domain>    <mailbox>
+
+e.g:
+mailtest.orion.nl       mailtest
+mailtest2.orion.nl      mailtest
+mailtest3.orion.nl      mailtest
+bvh-communicatie.nl     b.bvh
+krakatau.nl             b.bvh
+personeelzaak.nl        b.bvh
+maslowassociates.nl     b.bvh
+rtij.nl                 rtij
+
+Of course, create a .db file with makemap. Also, the domains must be added
+to class w, so they should be added to your sendmail.cw or RelayTo file, or
+whatever you use.
+
+Now add to sendmail.cf:
+
+R$+ < @ $* . >                          $: <MULTIDROP> $(multidroptable $2
+$: <NO> $) <?> $1 < @ $2 . >
+R<MULTIDROP> <NO> <?> $*                $: $1
+R<MULTIDROP> $+ <?> $+ < @ $* . >       $#drop $@ $2 @ $3 $: $1
+
+These lines should be above the existing lines that read:
+
+# short circuit local delivery so forwarded email works
+R$=L < @ $=w . >        $#local $: @ $1         special local names
+R$+ < @ $=w . >         $#local $: $1                   regular local name
+
+This works as follows (in fact these comments are above my modification in
+our sendmail.cf).
+#
+# MLI. Any drop host gets passed to the drop script
+#
+# The first rule looks up the domain in the multidrop table.
+# The input at this point is always:
+#       user@<dom.ain.>
+#  If found, the resulting line looks like this:
+#       <MULTIDROP> mailbox <?> user@<dom.ain.>
+# if not found, the resulting line will be:
+#       <MULTIDROP> <NO> <?> user@<dom.ain.>
+# The second line restores the "not found" case back to user@<dom.ain.>
+# So if this domain was found in the multidroptable, we still have a line
+starting with <MULTIDROP>
+# as shown above. The third line hands this to the drop script.
+#
+# Note that the user ($:) is the mailbox this message should be stuffed in,
+the host ($@) is the full
+# user@<dom.ain>. This is how the dropscript expects it.
+#
+
+I guess sendmail guru's are now laughing their pants off, and I hope someone
+will show me a better way to achieve this. For now, it works.
+
+Next, we need to define mailer drop (somewhere in the sendmail.cf)
+
+#
+# multidrop pop3 support.
+#
+
+Mdrop,          P=/usr/local/bin/dropmail, F=lFS,
+                T=X-Unix,
+                A=dropmail $u $h
+
+The S flag here is crucial, otherwise the dropmail script won't run as root,
+and under linux (==bash) suid scripts are not permited. I gather most unices
+now disalow suid scripts, so this would be necessary on most unices. There
+probably are other flags that would make this better, but this works, so I
+decided to divert my attention to other tasks at hand (busy, busy, busy....
+;^>).
+
+Now we only need the dropmail script, /usr/local/bin/dropmail, mode 700. It
+looks big, but effectively one pipeline does the real work. The rest is
+configuration, error checking and locking the mailbox.
+
+#!/bin/bash
+
+#
+# Script to force a mail message in a format that fetchmail will recognise.
+# use as a MDA from sendmail. Must be executed with F=S.
+#
+
+#
+# Configuration:
+#
+maildir=/var/spool/mail
+envelope=Delivered-To:
+
+#
+# set PATH to a known value to avoid some security issues
+#
+export PATH=/bin:/usr/bin
+
+#
+#
+#
+to=$2
+user=$1
+mbox=$maildir/$user
+
+#
+# If the mailbox does not exist, create it. Note that we act pretty
+paranoid, this is hopefully
+# resistant to symlink attacks
+#
+if [ ! -f $mbox ]
+then
+        oldumask=`umask`
+        umask 077
+        touch $mbox
+        chmod 660 $mbox || exit 1
+        chown $user $mbox || exit 1
+        chgrp mail $mbox || exit 1
+        umask $oldumask
+fi
+
+# First lock the mailbox, if this doesn't succeed in 64 seconds, give up and
+send
+# mail to postmaster.
+# If this period is to short, increase the retries (-r flag to lockfile)
+#
+# Then run the message through formail to get it into the right mailbox
+format with the
+# right headers added.
+#
+# Delivered-To will make fetchmail propagate this mail to the correct user
+when
+# run with '-E "Delivered-To"'. Set this in the advanced settings of the
+TeamInternet f.i.
+# (if you changed the envelope at the start of this script, adapt this
+accordingly)
+#
+# We also muck up the messageid, so fetchmail will never skip a message on
+the basis of
+# duplicate messageIDs. The -i "Message-ID" will rename the old message ID,
+the -a will
+# add a new one.
+#
+# Lastly, we add a header indicating which host did the rewriting.
+#
+
+if lockfile -r 8 $mbox.lock >/dev/null 2>&1
+then
+        cat - | formail -i "$envelope <$to>" -i "Message-ID:" -a
+"Message-ID:" -i "X-Multidrop-Processing: <`hostname`>" >>$mbox
+        rm -f $mbox.lock
+else
+        (echo "Subject: Cannot lock mailbox for $user" & cat -) |
+/usr/lib/sendmail postmaster
+fi
+
+#
+# EOF
+#
+
+This obviously is very Linux (even RedHat?) dependant, locking mailboxes,
+creating mailboxes with the right permissions, probably even bash dependent.
+I would say that it should be fairly easy to port to other systems, but
+alas, my unix knowledge is lacking for that. I'll also rewrite it someday,
+a.o. that umask handling can be done much better and the location of the
+sendmail binairy should not be fixed.
+
+Now the only thing left to do is to retrieve the mail with fetchmail, using
+'envelope "Delivered-To:"' in the poll line. The above script has added this
+line, so this is all that fetchmail needs.
+
+All parts of this solution need carefull examination. In particular I think
+the new rule lines may not catch all cases, although they worked for
+everything I threw at them and work satisfactorily in production. I'm also
+wondering if there is a more standard way to drop something in a mailbox. I
+yet have to investigate procmail, but all other MDA's mucked with the
+message and effectively undid my carefully added header. I'll experiment
+some more and rethink it all as I learn more.
+
+I'm still wondering, if I can get formail to include another received
+line.... "Received from localhost by dropmail for <user>...." to make it
+work without the envelope flag. Well I'll have to experiment. Do you know if
+there is a header I can add so fetchmail works out-of-the-box?
+
+Regards,
+Martijn Lievaart
+
diff --git a/contrib/novell b/contrib/novell
new file mode 100644
index 00000000..1e549aed
--- /dev/null
+++ b/contrib/novell
@@ -0,0 +1,57 @@
+From newcombe@mordor.clayton.edu  Thu Jun 12 15:56:44 1997
+Return-Path: <newcombe@mordor.clayton.edu>
+Received: from imap.ccil.org (snark [10.0.2.15])
+	by snark.thyrsus.com (8.8.5/8.8.5) with ESMTP id PAA11433
+	for <esr>; Thu, 12 Jun 1997 15:56:43 -0400
+Received: from thrush.clayton.edu (thrush.clayton.edu [168.28.242.117])
+	by locke.ccil.org (8.8.5/8.8.5) with ESMTP id LAA17702
+	for <esr@snark.thyrsus.com>; Thu, 12 Jun 1997 11:29:02 -0400 (EDT)
+Received: from mordor.clayton.edu (root@mordor.clayton.edu [168.28.241.16]) by thrush.clayton.edu (8.8.5/8.7.6) with SMTP id LAA22880 for <esr@snark.thyrsus.com>; Thu, 12 Jun 1997 11:11:51 -0400 (EDT)
+Date: Thu, 12 Jun 1997 11:28:05 -0400 (EDT)
+From: Dan Newcombe <newcombe@mordor.clayton.edu>
+X-Sender: root@mordor.clayton.edu
+Reply-To: newcombe@mordor.clayton.edu
+To: esr@snark.thyrsus.com
+Subject: Novell Procmail recipie/problem
+Message-ID: <Pine.LNX.3.96.970612112225.14988A-100000@mordor.clayton.edu>
+MIME-Version: 1.0
+Content-Type: TEXT/PLAIN; charset=US-ASCII
+Status: RO
+
+Eric,
+
+  As per your request, here is my recipie for dealing with e-mail popped
+off of a Novell server and told to be domanified.
+And example of the problem I used to have when I popped mail off of
+aa.clayton.edu   From: User <AA/USER@aa.clayton.edu>
+Sendmail did not like that.  Now it converts the above to
+From: User <USER@AA.clayton.edu>
+
+However, the To: and CC: lines still can get messed up
+To: aa/user2,@aa.clayton.edu aa/newcombe
+
+I'm not going to worry about that!!!
+
+I fixed it with this recipie in my .procmailrc
+:0
+* ^From:.*<.*/.*@
+{
+:0 fhw
+|sed -e 's/^From:\(.*\)<\(.*\)\/\(.*\)@.*/From:\1<\3@\2.clayton.edu>/'
+}
+
+It may not be the best, prettiest, or most efficient, but it works.
+
+Also, you'd asked me to send you the sometimes error message I get
+from fetchmail.  I don't see one in my Mail/From file, so it must not
+have happened for a while.  It looked something like
+Subject: Cron <root@mordor> /usr/local/bin/fetchmail: 29483
+
+Hope your flight back was good.
+	-Dan
+
+--
+Dan Newcombe                                      newcombe@mordor.clayton.edu
+"The fool who escaped from paradise will look over his shoulders and cry...So
+I'll hold my peace forever when you wear your bridal gown."   -Marillion
+
diff --git a/contrib/poptest b/contrib/poptest
new file mode 100644
index 00000000..3f74cffa
--- /dev/null
+++ b/contrib/poptest
@@ -0,0 +1,84 @@
+#!/usr/bin/perl
+# Copyright 2000 john Summerfield ,summer@os2.ami.com.au>
+# Your choice of licence: GPL 2 or later, or same licence as Perl.
+#
+# Warranty? 					None
+# If it breaks? 				The pieces are yours
+# If it breaks something?	You drove it.
+# Bugs?							At least one.
+
+# now we've cleared the air;
+#	This supposed to allow one to talk pop-3 to a mail server. If you're lucky (and know how)
+#		you might also be able to talk a few other Internet protocols with it.
+#	Typically, it's run thus:
+#		pop2test.1 <mailserver> [<mailport>]
+#	mailport's optional; default is 110 (pop-3).
+#	
+#	Having started, you type away much as you would with telnet.
+#	
+#	
+#	
+#	It has this great advantage over telnet: it reads its input from stdin and writes to stdout;
+#		you can prepare the entire sequence in a file, then run it this:
+#			pop2test.1 <thefileyoujustcreated >theresultsyouwanttoperuse host port
+#	
+#	
+#	uses:
+#		1	Debugging POP3 (and maybe imap does anyone know?) mail problems
+#		2	Deleting the occasional piece of mail that's too big or stuffs fetchmail.
+#		3	Talking to sendmail
+#	
+use Socket;
+sub hx;
+sub getreply;
+$timeout=1;
+$RemoteHost = $ARGV[0];shift;
+$RemotePort = $ARGV[0] || 110;shift;
+($PRname,$PRaliases,$PRport,$PRproto) = getservbyname($RemotePort,'tcp');
+$PRport=$RemotePort unless $PRport;
+$proto=getprotobyname($PRproto);  
+$RemoteIP = inet_aton $RemoteHost or die "Can't resolve $RemoteHost";
+$that = pack 'Sna4x8',AF_INET, $PRport, $RemoteIP;
+socket(REMOTESITE,AF_INET,SOCK_STREAM,$proto)
+        or die "Can't create socket to $RemoteHost: $!\n";;
+connect(REMOTESITE, $that) or die "Can't connect: $!\n";
+select(REMOTESITE);$|=1;select STDOUT;
+$rin = $win = $ein = '';
+vec($rin,fileno(REMOTESITE),1) = 1;
+#vec($win,fileno(REMOTESITE),1) = 1;
+$ein = $rin | $win;
+getreply;
+while ($L=<STDIN>)
+{
+	chomp $L;
+	print REMOTESITE $L . "\r\n";
+	print "send: " . $L . "\n";
+	getreply;
+}
+print REMOTESITE "Quit\r\n";
+getreply;
+#print <REMOTESITE>;
+close REMOTESITE;
+exit;
+# P
+sub hx
+{
+	$N=$_[0];shift;
+	$S=$_[0];shift;
+	return "$N(" . unpack("h", $S) . ") "; 
+}
+sub getreply
+{
+	while ('x')
+	{
+		($nfound,$timeleft) = select($rout=$rin, undef, $eout=$ein, $timeout);
+		last if $nfound == 0;
+#		print "nf($nfound) tl($timeleft) " . hx("rin",$rin) . hx("rout", $rout) . hx("ein",$ein) . hx("eout",$eout) . "\n";
+		$Reply= <REMOTESITE>;
+		print "recv: " . $Reply;
+		last if $Reply eq '';
+		$Reply =~ s/[\r\n]*//;
+		last if $Reply eq '.';
+	}
+}
+
diff --git a/contrib/preauth-harness b/contrib/preauth-harness
new file mode 100755
index 00000000..0bd0d842
--- /dev/null
+++ b/contrib/preauth-harness
@@ -0,0 +1,53 @@
+#!/usr/bin/perl
+
+BEGIN { $SIG{'__WARN__'} = sub {};};
+
+$hostname = "criens.u-psud.fr";
+$username = "p99dreyf";
+$passwd = "xxxxxxxx";
+$command = "exec ~/bin/imapd";
+
+use Net::Telnet ();
+$host = new Net::Telnet (Timeout => 10,
+                         Port => 23,
+                         Prompt => '/p99dreyf>\s?$/',
+                         Cmd_remove_mode => 1);
+
+$host->option_accept(Dont => &Net::Telnet::TELOPT_ECHO,
+                     Wont => &Net::Telnet::TELOPT_ECHO);
+                     open (FILE,">log");
+$host->dump_log("log2");
+$host->input_log("log3");
+## Issue some commands.
+$host->open($hostname);
+#$host->login($username, $passwd);
+$host->waitfor('/login:\s?$/');
+$host->print("$username");
+$host->waitfor('/Password:\s?$/');
+$host->print("$passwd");
+$host->waitfor('/p99dreyf>\s?$/');
+
+$host->print("$command");
+$strip=1;
+while ($strip) {
+        $greeting=$host->getline();
+   if ($greeting=~/^\* PREAUTH.*$/) { print "$greeting"; $strip=0;};
+}
+    do {
+      do {
+        $cmd=<STDIN>;
+        chop $cmd;
+      } while ($cmd !~/[A-Za-z0-9]/);
+      $host->print("$cmd");
+      print FILE ">>$cmd<<\n";
+      do {
+        $line=$host->getline();
+        chop($line);
+        print "$line\n";
+        print FILE "<<$line<<\n";
+      } while (($line!~/^[A-Za-z0-9]+ (OK|BAD|Expunge).*$/) &&
+                ($line!~/^\* BAD.*$/));
+      print FILE "--next cmd\n";
+    } while ($line!~/^[A-Za-z0-9]+ OK LOGOUT.*$/);
+
+exit;
diff --git a/contrib/redhat_rc b/contrib/redhat_rc
new file mode 100644
index 00000000..d94f95c8
--- /dev/null
+++ b/contrib/redhat_rc
@@ -0,0 +1,60 @@
+#!/bin/sh
+#
+# fetchmail	This shell script takes care of starting and stopping
+#		fetchmail.
+#
+# chkconfig: 2345 81 45
+# description: The Fetchmail daemons allows to retrieve mail using various
+#	       mail protocols and route them to the local MTA just as if
+#	       the mail was sent directly to the local MTA. This is
+#	       specially useful on intermittent dial-up connections.
+# processname: fetchmail
+# config: /etc/fetchmailrc
+# author[s]:
+#	Andrea Sterbini	<a.sterbini@itelcad.it>
+#	ObiTuarY <obituary@freshmeat.net>
+
+. /etc/rc.d/init.d/functions
+
+# Source networking configuration.
+. /etc/sysconfig/network
+
+# Check that networking is up.
+if [ ${NETWORKING} = "no" ]
+then
+	exit 0
+fi 
+    
+# See how we were called.
+case "$1" in
+  start)
+	if [ -s /etc/fetchmailrc ]; then
+		echo -n "Loading fetchmail: "
+		daemon /usr/bin/fetchmail -f /etc/fetchmailrc
+		echo
+		touch /var/lock/subsys/fetchmail
+	else
+		exit 1
+	fi
+	;;
+  stop)	
+	echo -n "Shutting down fetchmail: "
+	/usr/bin/fetchmail -q >/dev/null 2>&1 && echo fetchmail
+#	killproc fetchmail
+	rm -f /var/lock/subsys/fetchmail
+	;;
+  status)
+        status fetchmail
+        ;;
+  restart|reload)
+        $0 stop
+        $0 start
+        ;; 
+	*)
+	echo "Usage: fetchmail {start|stop|status|restart|reload}"
+	exit 1
+esac
+
+exit 0
+
+# === End of File ===
diff --git a/contrib/runfetchmail b/contrib/runfetchmail
new file mode 100644
index 00000000..2b40f511
--- /dev/null
+++ b/contrib/runfetchmail
@@ -0,0 +1,182 @@
+#!/bin/sh
+# Runfetchmail 1.1
+#
+# Copyright (c) 1997 Doug Muth, Wescosville, Pennsylvania USA
+# All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to deal
+# in the Software without restriction, including without limitation the rights
+# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+# copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
+# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+# THE SOFTWARE.
+#
+# Please send bug reports, suggestions, and flames to: dmuth@ot.com
+#
+# This shell script is used as a "frontend" for running fetchmail.  It will
+#	start up fetchmail and save the session to disk, generate statistics
+#	of the e-mail that you downloaded, and tell you how many messages
+#	you have in various folders.  A copy of these results are also
+#	e-mailed to you.
+#
+# An rc file is also supported.  If the file $HOME/.runfetchmailrc 
+#	exists, it will be sourced.  This way, you can place runfetchmail
+#	into /usr/local/bin, and individual users can have their own settings.
+#
+# Pre-requisites: You must have procmail, or at least `mailstat', a 
+#	utility that comes with procmail, running on your system.  You must 
+#	also have `timer', a shell script written by me, if you would like the 
+#	total time that the transfer took to be displayed.
+#
+# Syntax: runfetchmail [-every]
+#	-every Downloads all messages from the mailserver, regardless of
+#		their size and whether they have been previously downloaded.
+#
+# Changes in version 1.1: The argument "-every" is supported.  I removed the
+#	$EXIT_CODE variable since I had problems assigning the exit code from 
+#	fetchmail to it.
+
+# Command line to run fetchmail
+FETCHMAIL="/usr/local/bin/fetchmail"
+
+# Your procmail logfile
+LOG=$HOME/procmail/log
+
+# Do we want to use timer?  Set to 0 to disable.
+TIMER=1
+
+# Our path to sendmail with parameters
+SENDMAIL="/usr/bin/sendmail -oi -t"
+
+# Who am I?
+SELF="dmuth@ot.com"
+
+# The folders that I should check for the number of messages
+FOLDERS="$MAIL $HOME/mail/lists"
+
+# Number of seconds to "sleep" for while procmail finishes up, increase
+# 	this if you have a really slow system
+LATENT=10
+
+# Do we want to use mailstat?  Set to 0 to disable
+MAILSTAT=1
+
+# Do we want to e-mail the output to myself?  Set to 0 to disable.
+# I strongly suggest doing this so that if you lose your connection to
+#	the net part of the way through a download, you can see how much 
+#	progess was made
+E_MAIL=1
+
+###
+# End of user defined variables
+###
+
+# The temp file, and ensure my privacy!
+TMP=/tmp/fetchmail.sh.$$
+
+# The version of this program
+VERSION="Runfetchmail 1.1"
+
+# Trap errors
+trap "rm -f $TMP; echo ""Exiting at user request"" ; \
+test $TIMER -eq 1 &amp;&amp; timer -stop -id $$ &gt;/dev/null; exit 1" \
+2 3 4 15
+
+# Source the user's rc file if it exists
+test -e $HOME/.runfetchmailrc &amp;&amp; . $HOME/.runfetchmailrc
+
+num_mail()
+{ # This procedure tells me how many messages there are in each folder
+for D in $* 
+do
+	if test -f $D
+	then
+		echo "There are `frm $D |wc -l` messages in $D"
+	fi
+done
+}
+
+getmail()
+{ # Fetch the mail!
+
+test $TIMER -eq 1 &amp;&amp; timer -start -id $$ -quiet
+
+$FETCHMAIL $@
+
+# pause for a short while
+echo "Now sleeping for $LATENT seconds..."
+echo -n "Zzz...Zzz...Zzz..."
+sleep $LATENT
+echo "wakeup time! &lt;yawn&gt;"
+}
+
+stats()
+{ # Prepare the statistics
+
+# Ensure we have a log file
+test ! -e $LOG &amp;&amp; touch $LOG  
+
+echo -e "\n\t\t\t   $VERSION Statistics"
+test $MAILSTAT -eq 1 &amp;&amp; mailstat -k &lt;$LOG
+echo ""
+num_mail $FOLDERS
+test $TIMER -eq 1 &amp;&amp; echo -e "\n`timer -stop -id $$ -quiet` have elapsed."
+}
+
+prepmail()
+{ # Let's prepare our e-mail
+cat &lt;&lt;EOF &gt;$TMP
+From: $LOGNAME ($VERSION)
+To: $LOGNAME
+X-Loop: $SELF
+Subject: Mail stats from `date "+%D %X"`
+
+EOF
+}
+
+### Main Program
+
+# Let's have some initial cleanup
+rm -f $LOG
+clear
+
+# Create and secure the temporary file
+test $E_MAIL -eq 1 &amp;&amp; { cat /dev/null &gt;$TMP; chmod 600 $TMP }
+
+# Prepare the e-mail before the logs are added to it
+test $E_MAIL -eq 1 &amp;&amp; prepmail
+
+# See if we are downloading every message or not
+if test "$1" = "-every"
+then
+	FETCHMAIL="$FETCHMAIL -a -l 0"
+	shift
+fi
+
+# Fetch the mail and have the output written to stdout and (optionally) $TMP
+test $E_MAIL -eq 1 &amp;&amp; getmail $@ 2&gt;&amp;1 |tee -a $TMP || getmail $@
+
+clear
+
+# Do the same thing with the statistics
+test $E_MAIL -eq 1 &amp;&amp; stats $@ 2&gt;&amp;1 |tee -a $TMP || stats $@
+
+# Now send $TMP to myself and clean up the mess
+test $E_MAIL -eq 1 &amp;&amp; { cat $TMP |$SENDMAIL; rm -f $TMP }
+
+# cleanup the log file for next time
+rm -f $LOG
+
+# The End
+
diff --git a/contrib/sm-hybrid b/contrib/sm-hybrid
new file mode 100644
index 00000000..ceecfeee
--- /dev/null
+++ b/contrib/sm-hybrid
@@ -0,0 +1,539 @@
+From: Peter 'Rattacresh' Backes <rtc@helen.PLASMA.Xg8.DE>
+Subject: Sendmail-8.11.0+hybrid
+
+Hello,
+
+This is the hybrid patch against sendmail-8.11.0.  To make the binary
+RPMs, type:
+
+cd /usr/src
+tar xzvf /path/to/sendmail+hybrid.tgz
+cd redhat/SOURCES
+wget ftp://your.favourite.mirror/path/to/sendmail.8.11.0.tar.gz
+cd ../SPECS
+rpm -bb sendmail.spec
+
+This patch includes MySQL support so you need the libraries to 
+compile.  If you don't have them you need to change two lines in 
+sendmail.spec before running rpm:
+
+  Change
+Patch8: sendmail-8.11.0-mysqlmap.patch
+  to
+#Patch8: sendmail-8.11.0-mysqlmap.patch
+  and 
+%patch8 -p1 -b .mysqlmap
+  to
+#%patch8 -p1 -b .mysqlmap
+
+----------------------------------------------------------------
+begin 644 sendmail+hybrid.tgz
+M'XL(`$&=TCD``^Q<2W,;5W9NVR,[Z'%2D\K#=L6+:Q()`1MLXD&`,J*A"0(M
+M$1%(8/"0K,@JJH%N$#UL=,/]($3/3%:I2K+/(E5)JF:732K99)-=%EDF55G,
+M#YA]*KLLLL@BW[FW&VB0!"6-1/H1=GF&W?=QSKGGG'M>]T*NH8\T?T.ZRB>;
+MW<QN%8OXRY^S?\7[5K:XE=\JY0MY*9O+EK8V)5:\4JK")_!\S65,<AW'OVR<
+M=^I=!SG7_;A"_KN]>J-V55KP8O+/E3:+N>(FEW^N6,C>R/\ZGE#^[=9^Y\J,
+MP`O*?[-8+.7RI2S)'ZIP(__K>.+R-PNW2U>A!"^S_XNY3<@_G]N\L?_7\L3E
+M;SN:.QB]?@UX0?D7"WGL_WR!Y`]MN)'_=3P+^[_T=>[_>/R7S]W8_^MY0OEW
+MFKUV5;VB$.`E['\I7^3RS^:*-_*_CN>,_#7+U#SC-:\4^5RV!(>^1/ZY0@%]
+MI=)6,8?_2CF)6DJ0?_;UDG'Q\_]<_JOR:F(GM9H.!9^XK>19:M=PCPW+.$VS
+MPD9QX]--&:,8JX@AS+29/S(]-C0M@TU-RV('S2[K&\QX-M%LW=#%"(.-#$TW
+M7#9TG3'-W]=,*\/Z@<\>UAL-FG!B>F8?0)P3#+,-?^JXQQYSQ!2VT3?MC3$F
+M*80_L3U[$ET`G[C.D:N-V8IM3$/B5]@8TB3`;F`S;>@;+I]']*D,\^9DXV\P
+MT34?Q`Z!3[-/V6"DV4=8GN\L(O-&SA3+<9W@:(1.YAFV'E&%9>UJGCE@T`[?
+M&+.0$+:^3@SP#+;?ZW#63%Q\V;XB[U?J#;6]7JNH^\V#<F+B>/Y8\XC2^6LY
+M0<I(P.\9MN%J%L,N-5UCX)N.[7&")YX1Z`[3!@,GL'U/D<&K<D+,TS5C[,R^
+MCK2QX44?IGWDSK]LI^_HI]&76$+TY3N.&[T'P6`2O8.HAX9EK1_;SM2.UJO(
+M8\W6CF:4Z\%X8LRF.WC7?">V+-_5)DPW!HYN$$<'FC\8@:^#P#7]4Z;YOC8X
+M]F0Q((:X9;B>8[/I"$(8.8&ELR/#9]2[YC$2B;Q*'Y@Q1B`KRU_WWOHV/&?L
+M_V!D#(X56,37B>-2^Y\KBO=%^U_*YF[L_W4\;;52VU<5+O>KPL$8@_@9_<T7
+MLO07@N9_Z4&JCP^,R.9+6:0`>1J>0TC`KHJ>FV?^=&<N<>#8OF;"OWC&"7<Z
+M*WN5ZOT5X6\BI\=N*[?)9+O&C^&.F+%.C9[,_;4WT<9CF&AX4YW&P.>=P.?Q
+M4$#K!_"&SI"=.H$+6ST8F39:,588;M>PM%-%EBLV11$6O`GY.G@&F[SG$$Y.
+MAU\HRW=Z[4:9C7Q_4M[8F$ZGBFF#O#%&'RN!;:X?FX:EZ,;&[V^I`VW#(-BA
+M31OY8XMMRS+%#K0PH':-LLP[#[D_'V\F4D2EAE!DBH`$7/!`1#HV)H]!L<_"
+M_-,=3'P.07?L-9\1'!YM4&0Q=ESCHW1L8.%YN&C0YB+P8NR3,VOQDY-"$M"=
+ML1>]DS3H'9@.S4GT9E-$$'WPR;Y#GS+)#4PAXG62S="Q+&?JE>6<EF;S53.B
+MW&.0$N(\4AVA(F/RX@@PTF69^)N*"$C//XFVM+SK^`BDM&.LWF;.A`0-;=/<
+MHV!,ZI(B?>$:"1T"IK3"9:8;0RVP?-[#5\!)M4R/8KB^`4*A/AS3G-*T+.?Z
+M<=+S(>V(_+0^C]0NHCPVGB`,XA`*(00HV]`$Y@@2`F&L*BZ0YX`N`'1^QE<N
+M\'",D%9Z_L&7&_L.999>6"^'0##[<9@LY2!,"K4KP]4R/OR5,:;%AAJ:+@)O
+MQS8H#CME(^V$5'NB(4`W$-"2)"$_VO(D7().MB`F:+DOU`XRS`_B"RB^,HG%
+M*Z!1+J3CLLXL")ZPD4(@F0$ZZY29W.S-,5*TF_(,LHK(?!A,6IJ2'IA6I02!
+MN5!G'Q1!\>-+(=AIV7'/-9(FR1T'])*AB=M/;%W:NW)=$##5R!H[,2T8\Y0,
+MB01?)M_N4-8R:P6^_)Q=?'ZKP1IPZZZ,!YQE"H%AFJXCY:`M`VY.YZG#S%ND
+MA!.9#\S(P$">*!TEDMH$V=[$-9&OA0;G<6@.GI1GAB[Q>,/P!SQAW.B(MB>)
+MR"02N+,#:J(9@\A*7,ZD_.5<6K`8C[E/'9%SLSSG0B.7X:`BDX;11R9<96C&
+MGEP7*V>V*\;-'P?V<>*QWD?Z/6,6M1&7^"[BWA8DBZ&*@,_^J'=P/Y+$3H@^
+MZNNT*OO[:ENNN@9AY2N/,*>0.&(['L-33V8T#D8.XHT0%79;JU-FCR`:B@8T
+M),$G$1@*,%Q`J;>8Y3C'P42$'B-#/D%FJE,RR243;>2[[>9^Q!S6/Y7%?D\]
+M/:RW#AO-YOU>ZW`MDTOKMC7OJAUT'E0:]=JL!Y,GE(J?&!9%+"VB+NYAB(2X
+MOPBW_4H?2:V.K'J%M`N)NS%!SDV[=BY6\B$.!,VG0\6(Z+'"N#Z%H5"T?IT/
+M+L_IK%2K:JM[V&GNJX=K:;D6N4N8DP6.0W*,Q+ONQ"0<DJ/:OFN2?:0R"J?;
+M#T5>IF!A)ME$\WZH6/3&7:3,B:2`AYUH4"]L(C!]80--1X8K(+;W.I%(('>9
+MBC$4<E!Q!:PUAZ>T:0S7!>V\1I":CDS83(SC]I0/%KHB^\8S/\UY/IM"3<KE
+MV[GPHMNY\)W9SNO:#FW2\]LZ%;HG'H[:B,W@"V>@PNW.2V2BB^C/\"W+O`#R
+MQ%0YDAI1))@S0_=1^E*[L:*2R-:K)&7QVH7T5I:9DF7#?V73HC[3QA.+\H#3
+MON&"EV-'&2"762ENY5C'<5WX=O(5F*!GF.V$&8\H4'*9PMD.#&5%'B&R.-WQ
+MIH;A8PO-@>Q1>X;&KKED!\*59=@1=&F*.'[E&V[@\I<%$!1@7;27:E`(R`A;
+MGBL-*0DF1W.%)(AN,D^6,\!>"G-"(IN6:P=C"(1%<1]I(-;#H[)8^*>P`\@_
+M0[7$,^@$K6+'$E6,ATH4Q47I[0PA5`,L,[G:^K02J`@'(:PB94*"Q-3`TL#7
+M*0*SFC%!1DPFV@GWMF=8HD";81-L;F[99_$C19[^R#6BU-.T0<B"2<@(&V9!
+M([P9CX".1ZS*R\;`%<NZ^@PKRCC(EIVU15#/(#HJ"&.V<IB&)N)Q6(,86V_!
+M#,W6<Z[[@%K#$>$*XV/:U-1U>!CWZ:=;Z]G">JY4CJ<Y?%_!M`JK%18B!#&<
+MZ_.D6*[[4!2^I;T8A`(YK]`#>3Z=>&@G0*W1V87)9>R28Y4U.I5`XUAD@SR/
+M,*91^D5Y`Y*;>$Z_Q&%RJC/0(0X"]MYW`U'\ET7*`%;##PI_ZC@@>Z["&6;Z
+MPENQIU'(L5:F1KX//+$12'-I<\AD*G528L)DV-CSSL00YBVR(RGAS2!+.KS@
+M-J:<YJSBF3!5<"8LQ:&G2:-HN##%PED)S8Y\F"PX22E8(/:9RTM`V$`N'0-Q
+MRL-RT(+C8)Y)IGHA$`G]0H(CET,7%36&K958CD?FYEQZ&(569V(02%,WAT/P
+M&**A)?JGX$QHKX2Q&&EVW/.798YQYF\KC4;SH5J+QUG4_^3J7&Z$D;QNX5*[
+M+=+6YP=!8=IY94$0S9F9^Z61D/SZLY>:\KGR2/EC()>K]$HON\KG]*="_Y<:
+M!E8\]&+"^%<S;#=#PJG0@26,[Z\<>A0NRSE%8O_"`KK*,/6J)/3-"4@C51#1
+M)<\?5D*E6&@B]5AHJ"Q^7KG*1#D6]7D4"LVF:V$*108NGN:`WP@A9MYH%N=`
+MBG.9`G+5L0=60%ZJ+,O[<5ZRP-8QQB<C/AV!8]1&1\_XIE??X+$-]XS!<"CW
+MC:$3S:1TDP(8QAVC+GQ8%'A])->9*)8?!3#0MF\8T5F\3R73CZ+=(1)H^Q0D
+M'1T!&_E!\-89DT[CS;!AAP>&^)+A(H@AE@&C;3#24EJ>I04>JW@>N&PG[@RT
+MG8O/#;;E!H5<XFI`F8EXXO9Z;DO^KN9_(X0(&PN'(*__C.GR\S^VF=_,B_._
+MS5)I:[.`IJW-7.'F_.\Z'AV:ZOJI]5R:7_*I.I-3USP:(4D8I$G_2VQA[[#+
+M]@X!0"3JC1S7+_.M2Y$5;`79#<JZYLXNM$BF)RX$"3O0M\BFC6$9"%)WK]YA
+MG>;=[L-*6V5X;[6;#^HU1#>[C]"ILDJON]=LL\I!C56;!]UV?;?7;;8[[.G3
+M2@?CU]:H"X`J!X^8^GFKK78Z#./K^ZU&'5``METYZ-;53H;5#ZJ-7JU^<`^F
+MNM?E]YD:]?UZ%\.ZS0QAHZ6=F\B:=]F^VJ[NX;.R6V_4NX\X.7?KW0/"=I?(
+M8ZU*NUNO]AJ5-FOUVJUFAX#1FFKU3K51J>^K-86!!*!EZ@/UH,LZ>PCDXFO$
+M?PM+W%5!7V6W09`X$BRQ5F^KU2ZM9?Y6!;]`6B/#.BVU6J<7]7,5ZZBT'V5"
+MJ!WU1ST,0B>`U2K[E7M86.HY'($LJKVVND_4@@F=WFZG6^_VNBJ[UVS6.H`$
+MX!VU_:!>53M_R!K-#F=6KZ-F@*-;X<@!!)Q"-]YW>YTZYUG]H*NVV[U6M]X\
+M@$ZR/02T#U106L'D&F=O\X`O&/QIMA\16.(%YWZ&/=Q3T=XF=G*.58@1'7"N
+MV@6PV$#@!"N[L96R`_5>HWY//:BJU-LD.`_K'34-8=4[-*`N$#^L/*(%]OC2
+M24J@3+S&-#;#9<GJ=UFE]J!.I(>#H0"=>J@LS;L`U.E5]T+&TYVR<$=FTS*6
+MW0$7ZK744[JBMWA4G5-R++6P-],LRG^SGZXAR@D!Y=-RHUFM-`[;O8;:4;L=
+MN3.'-"L#59O[),PUI(]#M*6>'H9E^\XAVI[2_U;7TKP^M$IU,'[NSQ;/_5,\
+M-8.+4N"C$.8(D$_7VG>2/_Q)>"3SL^U$<E74:9,[K*AL81G),ELI%G/LH1$:
+M@K#P0@Z*(U)66"(LERV!JKP^L#&H5P%3>46@%(XMBHP+I9W\.)$`H.1V@25S
+M"?[`^CHV9;+MY#HZ=YAS+#H2HIZ%Z-)_C@+4FOM+%("D'F7X\95^?&<G^7&X
+MWO"$#=(!=4N7S:/:L,"+MSY4V="7\/$BZ*\&?`D_5Z-36\/F99Y9.<X-*-V8
+M.3?3"[OYX82!#<S9.CO*T9@2Q6IW?[1WP#Z3Q2+6SU&=4VX3U42T:?/RKH#$
+M:Y[)?")AT[4;B(T:@"8L"".,GQ5JHG(Q<H@)K_!$5:K/R))RQ(^3GSSAJ*$J
+M.7:'[;#D8_88\-D3EGS"MEFR(.1;.^A@[;Y[^IE8'+&1+LBZ3N!]%$&#+/ZD
+M=68EF]%*-K&2P`9ECG7"F11?3K(0'IJ+R'C@V$/S*'!Y845)Q(R@+/TF;0?/
+M6_>"\5AS3Y6))4F_E*3?_3=)NO5WTH?2KWM?!J:^;CE''O4I$_2A_^UMZ;>E
+M[PV0C$CH0]O_2-*;OY#>E[[O!79^;(X-#DEZ[P<86Z'V6#!#[4E)^MX[@/%.
+MY=ZN,M&'U'9;DM[*$MS]P/<ET;:'^;\E_4!Z<S25?'SK^/Y;T/4N!>1#2@'\
+M9V@GNM[[*?K^`KA^S1]8.:5O]B7>]][/0=L74E+ZG6B.;FITO5F9>,K15Y+T
+M!L;\$\;\%W"_/<K[1/H4;?^!MCYP_0;2@`&9"G>P/CF:2`KZP(-;^T27EI,&
+M^/Y??'>)7P;&F/9ZX/J&>2;^SU]%`O"<^+^4AZ+,XO]BB>+_8O8F_K^6Y[GQ
+M?X:"BILDX"8)N$D"OGE)0)Y^K7-A$G![/5M$$M#J=?9J=<#HIDII.8KLJ!!T
+M6%/O@MFUP[;:J#Q:RV1`1/P>,,4/O)YYM@A%U:IYR+]8<$R7`>4YUX!6J13*
+M0]OH?.@,D(7;=!SBN9M&',8\\C$68,SGQ6K\,&U1E7^5A75^;$#Z<Y\38PX-
+MRS-2AY7VO<,PWCU_CD"M?`18.SM`7^`F'9'10;H\Y_;"S9R,?#^,[A>ABT8(
+MK-D2\KHD?UN-'9['&+D1247N4.L\1(S"7WM6(@R#T$^V1=:0S.$CQ4$A,DMO
+M\QC0>&9ZOO<98DX_<&TQ@Y8JYNS0'/&9GV.*(M$70Y7;0=B)IDM1AFH3PSIK
+M(<3C$PJ[F1?TYZM$5LIKLNXITX[0%H7<"OWW213]YN_L(-K=#DE!?T%);FXG
+MBP"*G,#!`L;:44C^=GP-F)C,*<G"=G)37LBE5T,7)J3#?P`F(TO]>"?YP^GV
+M+/_BGG$0^)1BZ(8F<N@.N4;LD<$HL/RO,&N;9W-WDC9%Z"G=^#)P?(.MK+#D
+M'_QD8)F(S/F1]<]8,LVVEZG::I1)\ML(GA],D%2(,KV@ZQ.05;Y#@DB%(^<2
+M$4.:]T/*T^=3S%E^&:&O[JG5^X="6P7Z\(R&BM2.IUD7+Y9GITA&GKO2[4PL
+ME4V+/.5JLJU+DI-E&>/R1#I^^>9L)OV26=QB*OPXU&GZ[^*L3N%:K22+L_2N
+MQ):GO`-$?^&](X].,L+[*X+&2/Y`D/PIT'#VT[V:L3,[[_=I$._FR:$RIXG:
+M:./P7;,ZOR2Y<`JV.'MQ<KA1!8S%@9%5>KDB0$9XNH$OA"Q*(IH^-NUX>6`!
+M4<P6+<5%][CHWLS+(%DEAOMT;.8@^#;I:(E?H&$I_B-6)C8:III?B9L'_5->
+MA_`,GQ72<QK%]LR]O(;&[H"=5=#SR3];*$2<*\Z\GH(`EA9,E%@<=)/_7T?^
+M7_@:\O^M[#S_W\IF\_S\KW3S^[]K>6[R_YO\_R;__[;F_P6E\*W)_Y?=W7_%
+M>L#E<%^\1K`<3/PFV$7]\VMA%_56EO9=6G>X^+K.ZZP_A(C/]C_-X7]+?B"$
+MGK._,[KVBL5%]8HEI0.DKSPUB`H'R;SX?K%ZQ675BI='&*9)"[6*Y26*,,\^
+M4YOX9E<;1+KP^@H.!"RZKLBI?J2YK&L>C\S3Y<`6A'2V@+%8IJ![[#.RD5@<
+M1]H0);I4]J$L-[IP>0J[^`R`PE^`W]GF62R2(>2]3//#&_0ZLO0VIG(*D0TI
+M,R+SE+B&J,2O"/@/!\KB9VN*HO!Y'/>R2H5E&4=(O&;W\+'@S%RY0`-=?O2C
+M9%R`Y'2`"D'#]DT=YSM3Q_DV%6Q6Q3^%4`[M97A#-OX;3W?$0PNZ_[P(=N>R
+M^@ZO&W][JR>KXA\":-^MLEPN7\AXT3_R553H;(>X3F^YVV=5YG476I8M>A:'
+MCI6A]J5T+$GO[TC2K;^F&@:YH;XS[DN^8:+]"TEZ^_>H[A&U*WV-_DTA!7T3
+M]+U'=1->N:`YTOM_*DG?M]%V2]&UT5CB;7\I26_\.:]9Y*41OO\>N'J$2[F[
+MGR]]FBM)'.;[_XKV_T1[['>;G+9?2M);;U$]9/:OM-FFYUF<AO\&[#^C^@DV
+MIG-L2)8D??`NX/P#X"3$KE"\D61Z:/\0]/X-Z'C#EP!9^B`K26^VJ!;DC7.B
+MG"-]0'6?GQ-M@&=.:*J8"S[<^F?"HSD6M:+]`ZS_UC]2FS^8F!.3MV']"8UX
+M0C_3DD3;7TG2NUO4IMO>8=@&'L@?$I\\7S=MB;?]BR2]\^^"GX27M_T"\+Z@
+M-NW_V+OVKK:1+)]_K3.?8,_9/163;AZVC"1;-G%")@9#0C>O!;(S<R8S(&P9
+MU)$EKR1#Z)G,)]X/L??>*CTLRP](8IIIJ3O85KVK[N-WZW'+N_+%N_^#M/^%
+M_30P/;M"KB>>0=A_0+#TGS27%,__"!<VWWZ.8<;\3U57JO'\CUJC^1_T__[M
+M:Y(_Z2??_YU/_>13/T]HZB=T-*96E*RIG[JLJK)6Q?W?,S>`8U8`?TJ%U,[A
+MQ+[A,"S"\PCN5CEZ3^PH#EPZC$Q8ZH<02O$3]T80F/T!QYD`9]<XJETCLV@L
+M2HF';MY6WF1E'P(NZ&\^;75VA#,6\/]2N`M:Y(![A,7!<-H;SK,:]03`S:\I
+MN`Z+V1L'^PD@-M8](^8.6@)H[B12*'&W)2(A0E1&_>S)E_[H_G%Q4OY+A6^$
+M"+N&##%JQ[UA*S;OL'6P,[[!>^X6A@9=,L4H9<3U2^+7L#UTM/_+O=HS0@/;
+MQV=1Y0$&#SS+"58N\'0L*\8T7H0A_]^AY9E^>.H?>CHZ]+^\NBQLXLF+NK=H
+M*P%R#Y@_'`Q`O46GZ(N2]*3Y/X7_'F/_+P"_Q/J?IN3[?Q?XS,)_^=)?CO]R
+M_/<;PW\:W_N;J0#X`4!UG@.`A/^^!VQ8XBZ/FN2?G4.%L<U"\P$+,7,9IPNG
+MZB+(X+C)$IJ,.\I'KYL.SO)T$[4";!+-](G4W#V>*_RWXM0SK7FV#T]Q\GP4
+MLMR.)8ZPRAS`-(E(4QEQ;SN(3<VNN$G@8<,R#:QFC4FXX'%O1#LV+,K8N#P0
+MWD:3L>.=O%!`R.?*A7,U6OOPK:Z9GBQ&DTF+%V#X]KZ!X07HD.0.+Z(P!^CK
+MHVO?B14,-&TH-5E;.'T]#^V(4X^Q13.:Q9)83\)5-_*=P6RS%X2+)FOC:TH"
+MVXY"6X*T4C[_^WN>_WV,_7_56DU/X'_R_Z%K^?SO0IX<_^?X/\?_3PS_5Z>?
+M_9O7`0CA_^\"G]*X++07I(F6P3T-@C$[8*89D('^IX/_L6G*46":!=HSS80(
+MP+(5].1I&EW<YA#GNRIE=TN\&^E>F#R&XG//,T_#WS'\CEQ_?%M8G`U_9X+>
+MFE2>B*A%3:=AXM*],/&_,?Y/X;_:8\S_:FIB_;]*YS_TW/_;8IX<_^7X+\=_
+M3PS_U3C^JTT\^Z%MC.*_Z*Q`#,8(#(*2`21UL?Q/_$-HZF)Y?CQUL2PG$T=I
+M9^$JB`W_$"AE)8X`1Q1Q%(1%:4:3C$*QY<?'O#09^R20W02D[IB?,X$ZSZ<T
+M-UK7I#392:O?SA(8S_N^.'4"`LU`=2%X%/@+<^!QSGD<?N:C@LXL,M.CE^=1
+M5+BZ.!`[J9VGR2;$M198<T:]IP'TT99E===H8W/[[Q&D1`K_ZX^`__5&58OQ
+M?TW,_^HY_E_$D^/_'/_G^/^)X7]]N@-H@?]'SWXOT4U.J'HRK^41%QPAPZ)N
+MX%?R!->>.[RZQJ/40T_LF^7W'=WAS0.FX8W>"B3]S'?83C[3/.%*G.2YYLSS
+MQ+D!,W*&.HP;WZITRB\[NM\):CY:,TXTBR%[$Y]I#M_<]QRU*&Z^@]13BWW0
+M:>JP^+'CU&03+HU>(<-O'0&I[M-8E@E(;^VW#G_VG\?HZ1;!><?M\[NPR="X
+MM7P3J22W,7\/-F;`K;OP1*4X4?&TC,Q1!XWL-57OC3"AL>?H[*\X$S)VS62X
+M=3X^]UM-]VH/3P@L$9^@9S1+P#]0-44AR(I"7DT]C1PR</I$L?LI=5XX%!0A
+M'5)3!B;>C+<<W2X7GSH1#0XI]]_%G)Y/_R?M/[IT[Q'V_^AT_T^UIFGUAMZ@
+M]9^ZJN;VWR*>W/[+[;_<_GM*]I^0TE/V_^NR-J?O+^XM*G?]_4U<?PM':NJ\
+M3K'(YQ75)78>DS2@EO@@Q&W%8[>1GQB.7H6'J$KH(48@+7[O)%XW.2L-^5#)
+M3K\U,_V4Q*WIB3-21M88P:O0VH7^P4.]W!I(.9>!G@%D+8+WCK./;SHNX_?'
+M).YLWSLN1@6@:Y30)D@4P[W7H*?O-R$VF^IF.%4,^7W!K(O2;]O^2^._[[$!
+M?!;^JS<(_^D-//:I-Q#_-93<_^M"GAS_Y?@OQW]/$?]5)^*_.C__^=O!?[GK
+MUT6X?LWQYV/B3^&G,-M)H?8`N#G=[:$F?4/\AVP+/.5_%^]O,_&?IBD-O`6P
+M5E=TM<[]_ZNU'/\MY,G]O^7X+\=_3P+_):3T;.]/";Z.X4+B1F=U?'](&@*&
+MF`Q`WZUIV_(GQ[UU(OPG[8Y<PIP%9F(`DXB9O=4CQW^/A/\B_8]C^ECZ7]5)
+M_^OU:DVI<?VOY^>_%O+D^C_7_[G^?S+Z7TCIK]#_0*]SZO^)4T"3T0!\G0,)
+M0*QL%)#K_\?1_WRUZ3MI_SGT/Y[YX/9_M5:K8_2ZFI__6,B3Z_]<_^?Z_TGH
+M_TA*/U#[1Q/&:NH\A=B>,`<D`)WJ#/N7N/Q#5_5TKB&7Y-D1J&-\5@1`0;@Q
+M?#HH$+$FG`+)]?\B]#_M,?D^$&"F_M>U6/_K=/]+56GD^G\13Z[_<_V?Z_\G
+MH_]#*?T5$"`\??5P%$"5N`\`$"<?9V,`BC@!!N3Z_[OJ?^J6P'V$\S^:VE#"
+M^?]J@^O_>B/W_[N0)]?_N?[/]?^3T?^QE/X*!!"?5IU;V=^:T;5IH-2C>RRF
+M:G01*UN=Y_K_MZ'_'UO_Y$_^Y,_C/;G^?U+Z/[?_<_V?V__Y\\V>W/[/[?]<
+M_S\9_9_;_[G^_Z;ZWS.[()S73X\^G`"GKH>>_>2-BJI4%-FP+0/ZK^V>BLL#
+M'_(HJJ(``'BF\"?]J:I:]9G24.IJHUZOJ_!=;50;C6=,^<:Z+O,9^H'A,?;,
+M<]U@6CS_SE]$=1;]2&?79NS/<:/RLE)E--)-29)E.0J**`,ITJET_N4"3"B<
+M&@'["70\>\E4O5E5FVH59=!+J50J34Q:^)/998?N#:!`B-Q4:DT`AY3J[5LF
+MO]RHE>NLA!_J!GO[5F*%PM#W3,];*1Z;7M_R?<L%5&$ZEMDMKK["<.`&RU_9
+M;>VC>MGY,P@YD*44]$4J%:P>6SD:'"`/;FZR@_;YWN$>Z,0]0`D__@CAB$%/
+M3,/^8'79\TVF9+X]\X!0S"[^BH*?W[I>UW+HP/$*Q?5-#T58F2T'RZNK$.T?
+M\(\JL.]>[0,$LMD;IF)`H>#WSX&F;/=J9?_HW7EK'YBU#'KVO_?:90J'(HH@
+M\CWV0S?T50C]%K@@B"^'EMTE3XS$GV"'#8I1(E%I:'YI5M>5IO1="3L/>A`K
+M?V">N>XJ]O26;3B?=AQHB#LP*^9YSS:N?/;/3;:S>WZP<W9T]$J2'IND\^<>
+MSPSYCSYQ@;H`77RM_*]/E/^*KFBA_->UAH;ROU97<_F_B"<IX\6@KXM!#S\K
+M&Q7QS2GL>A;[:6@S,.,5K4DR?US@3\RG<'8]9`?8W:`OJDVUWM0WF`840)*_
+MII15C97@HTYR?V!X($L#TP/K2&)GZ'2\#PCTTI18Y>Q8D@$K27)[ZX!Q:Q2E
+MH(]1Y3-TOA6YTD(Q*<D.Q%ZIKL(WV[KT#.^N(LF8"[L,/!-RW)+/X#.=%1O/
+MRC%OV9;I?3)MJ$][BSUQ<3>#__V^YU_+P/K7_L,%P'3^5S4*$_A/K^G(__5:
+M->?_13Q9_$^#OGZRTVH?[%3H1^%L:++6P&-:@VE:4ZLW564RWR?3IUA>4S%E
+MQ/+U<H.5\`_RN^4$D!%ZM4<GS?YP,+#-/OHR`<R#G+<-"`E,NAO+=[T[MMV2
+M7Z((J40WO=\,;<?TC$O+MH*[LD3^C452W^T%MP:Z<:>Z53IE=NM9`*H<=GD'
+MEIG582W;1BTG@8202FL,X*+5`YB$X2?P\1ZDPJG(A8.PGFUV`@:Q>J:'M>1,
+MPM8D+JQX22L;JVS@N5<@R=!]^F@3/7-@&QW>1K1/UR\M9]V_1B<\4&DI2HBM
+M`QQ(5I\5((1#/TRBV5`"2"J24[S'N07?-?V.9UV:/A>M];*J@VBE#^QK^D]N
+M@6P#LB\SO)C(P'NFL,Y8_CK@QG60E.9GLP/9?_!Q*@![<HN@)^8]")I2:48.
+M/K1H2G*H1`$=X@B#?HE!4AY#9(>5W(6>@9$9&G;XUL`^:(X7B04D*RZ5'I`6
+MJRR)VR*`SLI\JK*/UH.NJD0?HW7NWXA<1HI.1>I<0PZ8P4@LSBD`W*=D2/4I
+M3<W-)[JAK/C`XI`WB+<:(7.A<\I!8%S2Y$X?^J3K5S@1_`7G9/$>`_3%#W^X
+MD='QT#4Y=4O4%[PTH]N'PBI0)G'8P!T,H5=-J72?C'!J@S=R)(_(-SQ&%^2/
+M:A>8CQQW^A9DU3--&]C',_DU&-2FY*T$$A:+W3L,3"`^SAMQV?##_#RPK8Z%
+MMX'X`[/#&5T0@0_E=*`F'1QQRA:K"8(#FG)M.%><DD=R[(,.`5B"?8PN[M&Z
+MHE;0.&SH90U0#?_@K!=U%-TQ`95%7_#`1?B5+J&`>O@FTAS4K$,42X,EMWJ`
+MAGB/A@R5'I($X9H677S7<0=W(_T)7)N13SPB\V01"M9$7.@JTT<*LR`/VW(^
+M^6&D>)BB(44GJ9*<JCP,UC9V,:<6$F.#R&SU:0B(%'CWQ,V)Z_[`'&B=`EW[
+M7X:]S@6_XSHR#0S:X0@(]WJTA(&+G-3",OWTK]VAW968Z=#M(6$)#(`%>N2*
+M&HTDBZ7P(K!#B`7/7-Y#O(>)%3QV8_"!7U%C!0(UBL;,H`J$JB+=D\EQB6O8
+M3';5I"AC\JW331/9F#CJ)L@G+=)MA\D^SV'8N5P/VQ4U4(BLB+J%+)B#OL,%
+M)KKIT75ZUA7T?DC<Z6PFMGL\AW@Z#.@7AQHS`/@?`$S`*1C_VK1M((93XEX(
+MZPP]0@`1$NGT)$%\GH57";E\R.^P-A8H2]+^`V_8)=P`U3&&V!45(;I554?9
+MS3^XR-@#G>]U3<HKJNE8186HPF:13.*E4AT/D(BD)(8(Y5U<::IS&<F,(Y.H
+M\P0N$;)2C)M,@GI<G56D4AP2JR8B]1;>.@'BU^@#MFN&S=6J9;4&[>6?V&"J
+M;;EPO"F*+H,8W]VT_?;N@3D\AE^GFZI29B>;&OQM;4+=Y`Y[,<0B^%8$3LW(
+MSR2T214U)3G.=ZS:\Q91&LTC;N#<=8R?OX\]U$DP;C"X5R:@60"FP.>F,'R;
+M4<\DNT84FNX(5*Q9W?`JZH8)_9"57RF5)-GL">5#0X@38]*/Z'`N,K1ZP"2@
+M)WXU'4XF-96X@CX(TD`BPX/!=GL\"V!0Y\I'B>D.@\$PB`)"-H%*D^6?9B@.
+M40RR[7F)$9,1K5-E`)K$<P$@*%-B,NS)]<3E2+^F)66B[Y*QH#Z'(((\4T9C
+M-!BM-'08^A4'@=.*6`=;=HT:P\7E=8(C*$D-%MP-++P+AE\B!O@%%8O?E":;
+M>9PY-Q)VWD]#AX&9H"A-76FJ+V?9>2*#<4.OEC#TJALX=O07AV[+L\!^0B.M
+MLL>$VK"MOA7X"=1'N$B01R2TQU1=.:G4T.K#%H?4)KH!8N,L=P"CR<5QY]IU
+MA6#W3:*3#'R<,B%1ZC.<>0>E$L5A%Q?(.LNX.@??K`"_82KX!84L+P.Q[050
+M*1]-QE^@#2@![^+T$=H%!O4,T"\>M]ATO0R&<HE_$+4[@#`N+D*UN;Q,385Z
+M!V#=`)`%J`JV*597DB\N4IVT'B<#\7QQ$??82`BK'!]+[#2CT_RD*`$H97HW
+MD`KTGW&)U^/%VG8<U"7'1\+5"=]UJ)^-;I=$``$CI(23"!0P8.(R?X7D3WQ`
+MKVC28*.L0=?`A\H1]8H_!"E@^"*!Z5'D52E"1R%L258DHJ@*,E\0P39$]J[I
+MBYN>N-*G`:*=;3U!!T!&5`ZW9'U)#L58"J6PE6%D^UY<+#U?7@::=`+C,ZZP
+MA&9G!C:9E@XED6^!&+B#^#[1NR_L'3$W8'B75H"3G!$WX6SGZ7NV?71PO+??
+MPKT5DKP-QHK%#>+$Z$*#;RR0(/"R#Z)+L!!F@&8+ZJ'0LL,.^2BWCUMG[S<_
+MFL6/O3V<`OG8.X8?D@P1C.XOB$*(?\V>,;2#4&)C1$E>$6^)UX$HH>>:1#W1
+M%T",R\NKD@S$OPY=#J5M'[2W]@Y%>=!=B>(Z,?(/BPN1<T)\I`L=I58H#=D`
+MNFIW#R]Z&P/6'^7$(*%YF`"&61;)?`FHQ-.='=;:/SV2DG,[,R5WATMNC43W
+M$="J5L<INMK+ICYE:GXDA[3HWFA6&['H3DTD2&Q]+6E-.P)Q&?PF1"[5"'U"
+M0RVPH=?6);9D]1SH=P:CU]X[D>0EC@!,\:)0**;ZN2B5,N)$O5J$+*%%H)6A
+M,L]%#"J)JA?+THA#$@8^,7!1[A2!3ZZ&-/L&*<E6KV%3Z6_<U''*'6D2DG^B
+M0?@3JYI)R\E6949,M0OCB%:%Q9V?'W_3%8<I\_]J12G1S7+77>\K5O]F[_]H
+MJ/"]H=;J]:K64!HX_P\H+Y__7\2#\]=,'GJ'+#7TZYW>>K\&?Z]-HUOIU]+A
+M$6FD(XY)K(S,:`L(KB."!E<WFK5JLU;G$B<MK*:51+FTAE=,A<35IJ(W:VHL
+MM]!0J"?M!5`D+-PY%6^%.J_2OJMPD]1XI.VCP]V]=XE(=8Q4&HWT?J?5WCDY
+M3<12%;RM)YD=7K:P<\*W:^VA"DY&;V24?+ASEBP]W/25V,:%EPJIJV&)(UE\
+M^+!]?'IP1DYU3EC[:']E;96]9F_1@WT%`]D;\;:`'ZH(U,1KZHE9Q`'ZB_8B
+MSAJQ,-X4T@BCQ)3Q$L>T!D9(8V[*&,DD01@-H+#$HI-"A($?G#"6V/L_VG\\
+M,3LF=&17;H,QV&0O+B5X?0"OH=!`/@`3S+@RY;UND[U^$51>6&]?_/*&1YD0
+M5AHZ([3`1DB%A/H?X-\W>1ZL$V;(_W[7<P=?)?R?S93_2EW74?[KFH[^?W#_
+M1[W6T'/YOXAG,HM'N_9P*J32&>,](HUTK$P.3\7ANP:1Q77<_U>M-?4IPC^S
+MF,(!F"?(X-H&K4?K33W!X*I:)<D/'YS!"_]@1=S2C(QLF\Y5<%TL%PKOSUO;
+M[W>V?X:OAQ_V]PM?RCRF/[Q$0QVC0)R=P^VC-FZU3T?[+!M#P)-.("9$93"_
+M<<<TI'M_OGL$[)1(4<(47=-&>0`B)G!Y!=+1&&6-O[#P@H)_>9C$OKSZ'EM-
+M9O"_AS\:7RD`9O"_IFF$__1&35<;&O&_7LWW_R[DF<S_-/3\;P;W<\(8C93)
+M_",QQ/PBL/X&XC[@6Z4ZF?6SRJ`<3LT!(<=&4P?PV$ABOI>TT8$^^5)"P;=^
+M-<\#UAL`Y[--II3A:Q!]AR^X3]CM]<YQ'K#GFP'^1NN?K?4&KR2Y@-8D6\.S
+M!`-(0\S)UOB,+GP9P+\@CH8+F^=H));%=Z";\"NN(KX"43`EP_BWR+>4SC>.
+M$6:?>D-[AODK;(DHS+OR_PIL^#<\;]7[JZ;4-N"K'7W'F'[@#3M@Z`8@GOU+
+M?&-^!AO:83P+=X#KF8G7%AC.\-)RNJ](<'7-2Y#(T*O8&U%SBH@UBZ\*!;!H
+MV\*6+O+08H6,V\+M-:Z5K:QTL'%79@"9KD!1G3(:Z#=E5FPWSXJKJ[@-&P^S
+M@(C$K<C^K05"B4&J53[V]09)_7J]'.X;+UQZIO&)UZ[`6,?P3;;<7F[25FG<
+MV"QJ^9QW%_OQ1Q9W*G_']VH7$GW-T]"^\[B5<><D"J5:-72J52-1JR&BQ16^
+M=?U+8I-ZF%NBY'MT(V2$G<;DS7A4\,T-*\5OJ$H;&BVD;.ABHR453FE?,^K?
+M1`UA*).DE^B'+&+#^:T5SD5$".P5B\8+*OX.7N/DN#.TY0#7Y9UP:P@N<E$S
+M'EL>_MZ>Z?I?-H,..8"7#XQ/)J[+/:2,6?B_5L7]GP#Z=:6NJ8U\__<"'TDR
+M;+O);BPO0%ZF%;!*]U)<9HS?N)")`OAFQ#@>/R"&7S]*A>0.""D.:H;1I()C
+MWH;?I1\HZ`>I(#:(LVO#O\9K[EZS%Z\QN-.#X$J_`S%NF-S#H!=O*Z[=A1<U
+MB,/>X"M)&@ZZ:+.'T:):]#L5;]#W<9]&XIU4\/H8;0T#H3Z2U+%-PVG&[Z$Q
+M:__Z?1QDF<'_UW>7GM7]OO@?#'\MY/^&WE`0_]=!).3\OX`G"[)WS9O`=6U_
+M_=0*S'7<<UGAVR$J_5J%4P0M&2$,!P-<T9J*VJQI$X'\U`Q'<E*;.ECS+V-`
+MKY050"IBH3>:<\7$!ZWC]LXNSF[*[<.]T^24+`;O'/Z/"'ZQ<G)\<'YT?':^
+MN]]Z=[K*Y/:?VSM;']YM*NE$^WM;-"<KVXYOCP6V(0\>[*?##EJ'1W\ZQ#`D
+MHXS0=R?'4T(/CMH[&`Q,DA&JGIYL8ZB:$::+,#TC;$.$;:3#3K?VP@KA*&4%
+M1S5JZ)CUU%F=KF'V7:?2"4DC/",$!IA2;ZJU9G5C,FF,Y9*F!Z6IZS$]:/H&
+M[0(2GWR5#J$E;K3T3!]A,=D4:%G]:*%]H_P-[1''-GO_S]ZS=K=M([M?I;,_
+M`G'<6(KU]#.5FS2R1,=J9$G5HXEOVD/+$FVSEDB%CSANT_WM=QX`7Z*4M-MD
+M[[D;MB<6@<%@,``&`W!F@#HI[@;M*X$YHBBJN,&*9^4P*\]YX=;$A'Q0ZZ<Y
+MV,S!SHR*P([DF:@$^NT"]6SSLQS2?,;G(_)_?N^^G:'OUN?[_K>SL[M_*.5_
+MM5K=/T#];P>6A*_R_PL\:V<V=ORD1)[>D4E=?0)3LE9=_5DF@2`S\"V>T7OX
+M-:9Z6-L]B'C][>Z2PS?]W:NPL1.==T:_A;>;]1Y(?)S;V__,;C^DV\S%V?G@
+MQS8D8X(UF?E30WQ'([9,_Y9NGF6WH7!V6SP69_<`BXY]XLJW\+QVC&Y"9)$Q
+M"-W?D7P"[]D.VR9A'!PD5K2NYS!0>N,9M.[2<*[%=R:F//]U:LZ-J3DN6;-G
+M5)3^:4V-L?!LCVRS''.Q,*:T8Q8_0,W>S=@2YV-G:ECBNU_OZ<?SRYEO7#MC
+M4+HMPXM@0A^6(.(.VO=8W)8"*.VPE(H;SUO4RN6[N[L2MWIBS[$@%2;?!YJ[
+M!7&)=L:N08:,EH=U>88T0,--.0#BM=]3K`"WY,9[TR6++L3#ALQWMG.+]D6*
+M804LA.9@YA2/M=%R>*X<&L9XWNV8;"9&.+#TAI"GZ\JL+N#]S)P8%ML\&<X<
+MS1W#6EK6I(3F&Y;M$280]`NH-?#\(*LM=-@H!0W'D"SUH3@'N29@:1;]UN`E
+MX.QT5?@>"AR#T5Q>MCK-:'BADNBUM?I`(S3H4D516UJ=P;`_:M!G6PJY$XWY
+MTJL/&Z?B6(-TC<+.U`&P\X+B!B&6,(K/0.LT\3LP!>=A>@:C7@\#T43)>=5J
+MMS'(CZ*)L!R?)XLC'2$!LO$X1<)AC]$`T,W%)+-1O@#<O87QR#>\61,V/`]*
+M\EF?H)&D(Z!.9=P<9RQ`5_@=H(7`!=;UG,F-DUL4MC:V*&2`0$/9W"(O&`;!
+MMK>/@M_I1<)2`3">B-$/Q_!\QQ(+2/X#FV62HYWC&CI3"(//@M$DJ1-X(LL_
+M'Y//1D$$!Z@PAF%NW4U#`+3,+43RIY<8ZX8;B/7PEZ(C?IG8(#6BOW?DBXG6
+M<7SJJ9CGS1?J!3&^>8(J"+^_&\,LCR9,KJ[Q[.O-SOX^I@$YR*'%?4YFH&==
+MGC.@2T],F*C%"8G!#%03,C0`WRH27S&7N$F'>X_I#4\6MT!WQ=[!`!:(H/A4
+M8$OP]3$CW/JYLG4$W,\0PS/,!:X(?JN*)$UTX$?\X/,^_OF=XAV_;V]SE42*
+M:C#E_$(D/94D`0`RD\FF4U$F@>F2!=?72PB2U7)_R3["!*G5F:Z[&$\,XDZ>
+M#WH5UV)0XYGESR64(E0R5='/I\3RY)=*9ZCKN6IH)G'W*%9'1E$6:7"R%'=&
+MAE'"`!C`C,0*>03$6_;GJ$]I?)Q^'JI_N@')8M0"FL[4@`;&8,+Y3G"X?O!%
+MDMP>`.C8PL!(21RM":14J22&W6970B#I..3GBYQ%D58H1LI&'CNBHMKW6!Y+
+M2[&0AV5_-K,G.:GA8VH>YJD<T41)7FR+:IX;)6?@8Y8@G,T-%!BP22S3P*(E
+M206G`AU_K7HEKSZ%`)1ER>HQ[2]73L+QDZIFL9FLG%/_<O5</(T`Q@_:.(6U
+M&5D\?%B[PZ\<H+U\X_YL;11D44'P<AVI2DPPS@@9C2EZ18%";]EM"5M1:\ZE
+M;<_D@@CJHT[+#WY/RY%"BBJE6E/P>Y7+"XAC7(/ZA+Z3O&X")S#S:"GG?30)
+M%Y2I+85<6:IOY(F*7JN@MCI&J$[FO'D^PZM]Y@H4-,N[@JX!I0L&[49`J8[5
+M"O(K`:Y(L0VYQ6<(,@\"^)R=Z,/^>86^@WV0;U7^KB/%[=%1$-$H%"[NQ#1A
+MJ.;QVUD@4I1`46)"35Q@PX.GM$)1MA(W#*"^YSW>WEY0/O<T?[3KR(]V*RC'
+M&'Z*UA2@1T_%OR+M.TJ1=EQ-=U4U(8;J>@SV>D*[%->PO@;!U7H$G>Y)M]UL
+M@'ZZ&L5\/8HS5!:[G?;Y:@SU]1CJO1XHHJN+OUU?_*6F]7X<=8?:8#4*[V-L
+M:&HG6G]U^?%2^?$")R$,KM6%ADN%O-6ERKS1&)#'EO0T8S&D_"114_5*8H2;
+M*K(\1XG(,LI%'U!,ZX&<?0'[&<(%-5(PL0([H^!G$5=Z8<#>B'96<R/4U0.Z
+M)TMTWQKW$WMFS6.T8TN6%?M%?C5#W*V:B#X@DER#XEZ@E8"A;.?C=8/@_<MU
+M@W#.4"TL#);E,Y&'LB36KP\BG\P3'6X9=["HQ,"E$(QA\5:B\=+Q>"L0!9Q7
+MR,3OY$8P]L:XO19RQR*]%27WTOHM6:'*8I9A\87D8CI(=+U4RR4H5SQ$$U0@
+M=[^A.'+PAT/)!4AI1,J?O"B'4Y(V3$2/7#0ICMQ1H+G'.!.,BSAG5@RHM.&4
+M9(G*6L.2&,A:EBS1\5F8DOF$Q=JPIL%2+5$,^R--Z2-2\'07AB7&DOCD\$(U
+M*/0@BR1RAX?G)'W"[U(%J-R1]Y1"=@="RH9J\%#(X69(3]C)C7UK3$LLAQ(*
+M$I:(ZD:HU&#\%%:,Z,Q.G3"$>V:IK,K%52;&K$M48J!5QY.GEV$2UNB@VA1L
+MG'O(W=2Y1W!0-.U486EB%<0CWA0\4LKY(U:4'TTO\[!/R\@QST@?A`JQ&FT4
+M!);J0@*X[Y07DBMJ4G45*R9]^B0CF@/QBG[5.9I>$>'$$,&TBU+4&%OHZHC%
+MHJ-=K![JGS[]RW*41L8?\1QI>L#D@MR/\!N3"GPP(\]O%)^GEP4TUV-#MTH^
+MO1$X\L)&R`GP\P8P=6-MBQ*3]]/Y+^+:]/2RBKO.>O^X-^SKPWPPR$.0A3EE
+M(S?XD<O+C?&58Q@Y;"\ET!OR('QC+H3O.-JB>Y44\="8H8?S&OD@)^\[&R@*
+M)^\$BX6SE^=LNL0*P&.["S4%XBT.FRQ[3DXTJBTG94(^RLC\QP1F6'TH+Z,,
+M(*2@[/;T=K?[<M03Q:*8V?:M\!?`%F"(/\<SY3$#8F,#H5CG<*L<CV>!(2M,
+M:V+/<33!@)!'%WQP+OG[UC?0DSA^[&XX>&K/>AX!+$<;"HZ_^7LX1PU!5^]M
+M%G]<F"N4.N:5Z:!SI7U'I_8P.OVYI;1)I!:[FDN4N#'HKDQA?!QT%`X+<4`:
+M\]JRG4"4)PZ`D<?(,W^1LMGEJ:).3\?O6-(_IA5TD2[LN4_ZVH`/\?V9A_MS
+MF=I]A12&$MTEGJEWET[&SNJO\?X2/#$(CE`!$7[G363)$USYR_+GV/JC],TR
+MQNP-A*\2:E')&AF7P9+2F!E0.=1\A7ZF)-?FQMPUO)S+G,&3KX+ZJDQI>1K4
+M$HK)3H!Q8CX\\>V^@U&$P8'H.(RK8>-E>802(1>G'>8]$Y(7I,@RM$R1$Q3*
+M6GC.(BGE?P$P@NC!I>DAF;$]9U12TG8L+W7E6P-];!W9S(#Z.I[]H(TG#W]F
+M5DHCEM4UZ$:9%Z#,\("`4N_Y3$D2'+"=LA5#52:64_TM`99J*PA922:^9.I4
+M0"U+7#P?7=:AB;RBL\Z:6(Z8W(0`#M8E7&67%0Q9272Y40<.?XB,XNN/A/D.
+MM=3N2ZG'L/%#L,OR8%;KG,@-B/8MIZ<W(FP]G</*POG$P=MRJ_C4MI;0'D+-
+M*04G;_X2S4P_Z(N(6;FBDW:*;!Z+@=;6&D/.W0@Z:@7V<%F10B'@&;SKF)"3
+M[`D9IB#1/IH)2_8-8P16HJ$LRV"T%^$/S+XZ:D2IK6J[,F"'B_5%JF/E$8%2
+M=35F`H.CB34>"L(Z=;^1/EX"\N5,`L1O*K_$#FKCF&%EFDT!!!'_9CBV_(RS
+M$GTF*DN4/.-:"B)>J9J+4G!:N`J'#6'IR6P!_4:-VPACUFD!O$+%MDW4[%""
+M!4=>*P28;!HF.P9&!C5RM-*Q8(Q*6E9!B20<I>L**X;$&5&`E3)05?"_T,A!
+MF3.0!=,_08W!=57T3DDWP<1/<*YC:XV(Q46E4ML]#!RCUUIK*/>\>.%O,090
+M:*ZQ3[YU^$=&7X$59HH1PE4_%-"\GU4'$D+H19!JR"%2[#@R;-:7VZ#!L!$H
+M_!S=/NT4OI#8>1:2RNQ2T95DRJZ`3A&2L-XI*I#01D76XB9*$UI]W23)D2E,
+MBWR1A/QI8TOJS)4&DO^6J>4.7;P0]9>O%';%-OS+9G5KC`G%>F/"I>R$,2&,
+M>3Y`1HXJN\MF"[WG+XKM((X6=1B")X"5X>=%L:G&30H4FW)>%&>$9C(S8:T$
+ML/^TN=7_N6>U_=^3TF&1G>[^3??OC_M_'^S_`_XYW*_"_P=5\O_>.?AJ__<E
+MGH1(@DZ/^UN6Z"_Y6Y\8EQ0A:*^V6Y$7O3Q)RJ"E\LLE]W:X))GS[I(K&OY1
+MKFALS$">:^X;<WL;;0AT#(2C*^.G(U0B9"!I6?.6&\;RF9FN)QT+HS@VBK9A
+M2`<Z96,`TIHB5.&.U7>I4#%9:/I6%@*=&PT6O(*\K<YS[BG^'CMUI]=HRK(M
+MVF2+K=(66M>-.:;CY;U`!65V%?COT6FXQW:"*G2=16&B/!NT:-0CIW^SD]RJ
+M^2\=/^:3OZ&.]?._"BO0?N#_L4O^'_M[E:_Q'[[($[DD#D.4T,&5J0Z3)HX=
+M.YBB\0=CGD*3*M=-CLH5<?Q"/`A>4N&2PS"T)N.Y3P;`=HPH2L*01$MA:7W+
+M"N)OQ\CS;AS;O^9(BO,]0K!P#!DZTW9JF$*I\IGO)2J83\2SU*90J4AH<^;`
+MC8K]&TP8H'`QGMR.KPT57!XM?I5QJF<3'C2!+66EK7+NXOES%&S/GW-4(]#0
+MMF*7_L5BH@(FCG9CNZC(-.O:6;<C[0D&N0O+M@Q([@Z&YSTM=P$"QG^_Q7UZ
+MHM6'HSXD4N@T4(H2$5P!+`")^0$"*'GD%>W(771QB$C1B&-@:L%H?H(PWY\L
+MV,TPM:3OR\RP-A!;%((N3,';$2=W.HZO,)&]&/7I99AT.8->PC4"-FL3<X%Z
+MH1OF$HMU%7,R3)^/Z5!A/#5T-L/1F:1X50M/]RW8]MFS=]A,">.F`+WUQS,Z
+M"-:QDPTG2@+&086,L,I(^=G=^-[5Q]/I4OT64`Z#`"9:-$V7X>OTN3MFII_5
+M!S^.M'Z]J>GU02Z?U5[CC:1-O!BRGT,AJ.X)C"3X5C2JE+QH,)I\C!>>#H.,
+MZ`8`-')"I;>:T+D7._NUG?VM!$Q]-.Q"X>-1JPU`5VAB'P<XJ[_63[NPR8#R
+MB;+#_KF.&S+][+7>;@V&6P7/\1/%F]W.4._UN\>:3M>+GM1AK4L#;,"4`H9H
+MG4'K)RT5D];&:Q7/==[37%S"8+H&T6--$V3A?:%M31^>H@6YKHJE-J[;;NHP
+M;0$ZB"*61EGO7-?Z_6Y_H`^[4#,:CL`0\0PG67/]1-.ABT>I#>CU6S_5&^?L
+M"P=H,(:-#%SC)A`1#AUX->SV`?*`5NMD[S)G1QU-[W='0^1J6O<!([K=U"R*
+MP*/3;7PK"N/M>&WM)ZT--'R;J!YO,XTP):WJ1DMO8)P??=#Z'^RQG:U5`,/6
+MF09M`)C]>0+HI-M_5>\W20^%_,W?RB49;[>T>5>+O":1`TH,\G-6'THZT_ID
+M@#?%ZC"'8'3VD("4=FBM%Z=#@CFM=YIM&%U`!WX6?)*<2\A*_56]A0VI5I(M
+M.6MU]).^ING',,M?#@@FV:DXV\ZT`5X$J+AF6A2PVTA.OBX&J.MHC2$Y*"8K
+M@VP*=5=OIS$5<D^U=G=%%FKZJ2U`4='H4>MNEK/P<F&L<P56S*:6KRE^TNH0
+MP6GY_8&V"O6/(ZIU)ZTMK4%C15:C>W8&';JB.KJ^&?)V*\G)"9D8HZ8+LHKF
+M9DH^S=^^!BL!@NPGQV8<0N_@*&U_`N"H_X*)VODHQDX`>[@*%J959QTNS`]I
+M6P\6U/8DA951;"%=NRD(3T&)&@QA!1T0YY.=QF*Q7<=Z$EE][00E$N55EP0-
+MS"JIM35.8:'K4\]5#Q)@K[K]E[`6-EJ]%I`8BM_=%.D[T'KU?GVHX=K62!4;
+MA*W1K@\&(:;JDR5$!#8D8:6@ODVICYL^Z/:'>K</*Q4N0^@89GKW*6*&H4&(
+M8)U)+J):T#BM]W6>4#[;<1>?7)I>$A+$!RZ@>+?QQ=(X[[`TT.ODF@404A&.
+MKYUM5)5?@C#2Z\UF/TT&8^\PP;"8*:F7NMJ!?@`35F_@Y]1T<<Y+/\AH8&>_
+M>R:7]=3^J;?;W5?Z<??%:""%80H058M"37\!BVPO?9D<=6CA)PC]5;^U:BUN
+M=D?'0-UQ=]1I:,0.D/3K]`GD#+)XH/=`BY/KPNHE886NM:I9QVU@8W"T`VC=
+M\=72*K.DXJ6U'S53#K&*:Q%N*8J6<2>W&C0[H6-A:41E%$]AKD"+OX-MFDL`
+MQ=A#2:?`$>D?>>7#W@\O%*?]A#P`XKW@S=@K$;@B9G!6A_F!0@1:(X_$,?_2
+M]]BL%V^<N31@"VE-[V,ED4@LI[/TT9LMD`,P&W'@EW#?A^=4$=Y@>%?9Y$"?
+MVXXRC_3QM1"LZ@]@Z+5#`#^J9J%H00P*C52!5,CJLMHK18JP"H++$P(&VS@9
+M]R4"&.DS^/-ZJZ!V%--TF'J?"/3]]Z(HBHXH_B:*X\UK4;QNB,V;!PY?J-$4
+MF[_BOQ3D-K?I8R1;1L#;N^#-G:.=BGP)]WPR`4>0V@NIF*VGW__P?3.(XCBT
+M:WC7278YL"\/J;IH2WLC>7\`6?X%QN+R=GIE"L17.:LOZHSACFX2Y*(<5)U/
+M'L18H(F/.15TZ1CZON&0#@Y&;H!UC&$?#V$L6P7@(9.?*]ROA&<3D@ZVM0O.
+M7^!1!*K#%<>?&7@^N4]EQ<)V71-=<`$Y!H3#"]QD2=H#TW4$3$5-^GTIE`9%
+MWW<-0YJ<XN4VU\"'C9H\&ZEM<,&R+/B1<C1)D2D7Y2TN^&&YQC5%Q^+B@RSX
+M/.BTL*3L(>H&U4$\Z;??"OK[/1][;?O\YP=1GTY%=*0(C%EM.-DSBF<:7!\4
+MG4'!33IO![VK&\O_]H>"&#S5K'<GCCW'N5X^G3KJ-UXL!%E#6V7PKT(VDQD^
+M;78&Y?Y)X\G.3OEU<629[S&Y_C2X2J-X#O,&AJXH3F'>_'<$.OKZI#XKSO]+
+MN+3_775\Y/O?;N60XC_M'>Y7#@X.,/X;?@GX>O[_)9Z'#^0]8MF'V8?AI5/T
+MT,<`OBZ#[[D1'GDD37`1P:MPT.R7+B/$J\8\FX(*`);X$PPIJF%R<\M']C6Q
+ML[NW+YY4Q&XE^U#>5[O@VUD#JUA<G<09_AHZ8\M=V+!ZUJ\-RRO(6T?DIPIU
+MS\O/R=K9C\I^AWY4B(8^K=ETH1HMDK@FC"TRCP7ZU%U;:.E3"^\3?2@4R:$R
+M$_U*`.7,*1X\`\"[L5-V_/!^KQ)D90%B0->*!A$71'`+>8F1.I/2M(R3#OXH
+M(#=2T#(\_'B`W(Y=318@@/')&64)&BGLQJV,?;I$$LO"4O@&0]XE,`3POX@C
+MY*^5S2S5$G"'S*`RO+-]>H\Q_F@?];1ZD[TRD0A>B*DG(JV`GO,7I>P;L?E[
+M1QOB!A2V37_@9U/+WH"*'SW"""2>J&2S3.+RU6F_B`\?`J"^-ORIWGY:H6;#
+M*H_7H]T9\#^,U0E]C2EER:EM8[.Z(?".7QZ_^6SFH73BXQ!4;BF;S>#E7:((
+M"LE`C7%5:TUL9#/!VAV&,\3/1U/C71FMBL3.LT?5+'G-FJ@\Q+Z9A)N((*YB
+M-*@B<'QJ9S,R*D;8.S3J-LU(E\3#)L:`OHN],C;HC`SZ%L._U,XTCF[FW@!_
+MN"\WH"^@.V57$#\NIWF88N*C#Z)!YFW22-B(HGC+:<!UV6&;WS.WLQD8"IPF
+MBL9;4>%2GHUW>]&T`N7]MNSZES`&P]&7.3JBGK07LB/M1=B/D6Z\\3WJQBEZ
+MB\?Z\M:<S7#>A_/]$TGC:)$?(PVO>^)AMEDA.N4/2(M5)(%G]A@V/\M$B6)U
+M&9SM%@"<?Z2W@"`?YR4S-D88VC<4;N)W(N4#4O9!TOJ!T?T!S*'95<T:[GB2
+MS=*+9,17I?'_Q[-*_PL$_=]0!^E_!ZOMORH[>PG[K_W]O<I7_>]+/)%U.UBV
+M_],T?7V^W*/F?T]K#,J?J8Y*9:]RB'?\K)K_E8J*_WBP4]F%^5_=W]O]A]C_
+M3/3$GO_R^1_K_U#Z+XR_P_!//NOE_^[!;MC_E<-#[/^]K_$_O]`S\.=SV(?6
+M1%W<F5.,+D1&?FE[;I$[&];SI6PGOCO^R7!<VK7+Z)E]8V;`AJ@F#K,->W'O
+MF-<W7DT<#YK9%X[M+VKJ?F'-@FV1;:'-;KG)&GNVY]CO@`H7T,^]!>OQ6=[$
+M5FKBB@)=PK^EB5NZ-)Q;J.F^9$Q]O%LS=&,)1O$WO[]CVOXH01^7KG^3J*HA
+M]73.)9-W:M%8FD'(S=N2;YG%6].8E:9&^9M#;3(N&VSBC.?A97+,Q`HDFMTP
+MVCTG[$6J"]0JF;=?2WIP+%^Y($$/(J"!=6ZVA[;YE64LT<#M#%3]W_:NK;MM
+M&PD_A[\"C>,3.RLQEGQ-ZV:;B],F;>RLXU[VG.QI*1&654ND2DJU7<?_=G_(
+MSC<#D.!%MI3N0QZ(GL8VB.M@,#<,!L5"&XCN*PKD.(C<@MUJ0?83;.,-D-0M
+MN?EER??;O3`@1;:JC1GHO(S?NP6KD"@]/BK%=JK%G#?JI,QNM8S[CI44VJO"
+MK!CLV&,7<Y`%8]:9CB>/5Z]A&[II(YNP52?Z#_K*2G1FV?*\5<>:Y9VXU[RM
+MH8H-6W_R)<X%=QW]*PK>W8:L@OU,;DC*!1C/=&^M9_##G:7&`S<(\7>B-&-?
+ML9'`ZVGJ)6Q3^^VTKR.=/=1NG_^U[Y"+L<UI25%&XAG+3ZKXU$FKUQ&.C#3?
+ML;\X@Y&&G8(#CJC)/L:Q[WG&@5A3"YGK;:(S*Y83(I:*/<1SZ'AHO>RDZ[F.
+MM!4G75]9/V6N%\9]OD>0!=O-^O!0IL_!`+AJT?^7ZMFV:>"KMAO*]C(:^[+0
+MMCR=7H@"4(L`!M"^I9^%5HK(QMV=S!D6K']3^*.6YE@=AS<?$56&0G)2!YM*
+M(A0?J*8Y=A61+#NC5\_^Q>;A0)WJ"QK)!)?E<4ERJFW/MJRO^+33E,&;\!-A
+M!QPM`?X)[WF>:R=OU[G-:1*?LF<TD6E8[5[?L2XPJ,U99QY)-FIW`?NG^?J=
+M</B%$5Z'IR;FHZ._`*LKKAOU8D(U6^SD8]#4AN_)#;YF`-D&?AA:?/<*;OD%
+MYW$XW8=#A+WIS?#P.!]ZNJ5RU/VW;"3CW##'P?WV;>EA<1+=XRLZ3`G*@Z&E
+M1EAK?1D@+''+?;/=JPS<$+&L>3FZQNF^;-TT'NLPN,J65H#!I%(&PN^ZJHP6
+M<=56$7;U>YI6Q4X9Y$2/)MQ)_9+7HU\5:G5T#$"J3)RQ,-$3;S75T]E$M?\`
+M5H+=J_:DH]H]95Y<,-F=+#OGZ^93-_O$G-SD;F:YS!Y-[E:6:\48R=]&OOE]
+M)^\*S-?D[A;;VS79>WEAPV"]%5S!0HYE\;RD7%JM;+<D7LG%,!54/G[W5FY?
+M&`*FJ#[RX7Q-<.$-03@4Q\KW?=C_?_GE%W5\\-/!,:)P>RL0\"]/U0.\`R*&
+M+KC6Y(*;:K_`!ESIG\$X#-;NXQ_*>WQ&7>!!^=/'\.-^>^!S)<_SP*[;B)#W
+MT5[B^/C!_^!_?*CVU>JU]+)SHYZB*MK)!#9OE?>%MZ(OF;86'B?Y^OZ#PM^J
+M_1(.A3\='+X\.O[UQ2OVOOFZ<]_S^OGE-R\]D^MPR`0`^B(CP(J;UGU,YM=B
+MO*G[-$DL-M1\%*2J^<"3]\9;*IL_0<3\CB>B5LVV\V!+3\P2\36`7X^/CDZ\
+M\7DXI.695#Z@\;F%2^=I^=])_WJCU6EU6YNMK=9V:^?&?,RE\JP-<\"CS&UD
+M_DG["?]?=ZCNWHVRQR=*3@`&_),8)E_4DSO,+B6A$;<][^CY&\*]K^/>[_Z#
+MM1G'R&VGZ_GO"7X/$CQJZ&$YU,N#]R>H49JMPL7JHY\/O_YM2.U&L]_4C^4,
+M<S/;9`RD1"%#GJW):\A#-?GW#UY&%VF+/)"QYP<<G^GX<MS_3`>8[Z7/88!$
+M>?NZ73/,Y/->9"%5HXCVSRG1&U'"[)%H::#9>:VM]IG.2@@I<3#[C:34%#<?
+MX2PZEQKR[*ADOC/[)"T$"0O?/[Q^<7#X_D!]C_$\_Y%XBG`R^L'/7/QZB$"\
+MZ&BA9GF$AAG>6<$R39D6U<[XZ,)5P256"M*9D8Y2X2]VJH]J6ZRGP7/A:,_,
+MB;]GBS-6.UM;12[>KS"J>K^0&AFA;E15F>'NUDF0D./<%;D5VH9[<!LL)%5M
+MJSVH@#5B<4^`@,6RN#480.GV[]_66[EEK[S;<K^!.V"?@Y,@,M[=WJ[4R'CG
+MX_$?N&B/50^#"$\^#%1Z-::?YZF'29Q"&[3>T"SH_*$<-XS)+!G@&'OJ*3A2
+MP!UAF5&CP(/KTQNN'>G;<<5LUSZ-8W__X.C5;<`4KP_''4:K"M*W<XMECO^B
+M!&'F@>LE12W9@("L`,M?I"N)?K6&<#0D37,]>PM6'%FIK-R276&%=L%1L'*:
+M.R^[^C4<H*SZ"!\OHE=&F8,'#F*U7<!&$%QQJ&$8KK*;S!#8\S_X-_&+N7>/
+MG=?SC_=L3J>[ZV_0?YTLQR/0,VJ`\B_I;I-CB7B:S%V_!]?4^@V7[)^-XU#!
+MI7&AXL7736^O@*=']__/@Z`V+3;G5`WU+,W9O+D%;1U)Y>Y).*_![CO->^6.
+MY4/]R&M<S/+:(!VF=J>VMNM'E]4O4W,[LNU;)IY9WSV!].P?%[4$@TG*=29S
+MMC+A[N:.BJ@G(I;'D:N7:[UE)W=S2VVGBU5^XW:>GD6:.FTQWKPOX@@1(50\
+M"BUEF<*D>D%?JPYIH8ZN<I<TQDNJ4/K^$4\#!Q?GZN'S@V]?'UXK#N0&WG40
+MT=C!G-B:W4OCD89YJEC__@WJWU/J6NK!?^_XX,W!BY/[-P_5TZ>J0F1Y')/R
+M,(I_XO%?A->"DR)H!\U7K$V1T*I?A6X-)^87<$#SZU>69-0XZ-EF<C>](D"R
+M`@P4ALI]AHJR8/FP"%QL,Q_NJZ\8/.QW9YMXT/D`$!%MI)\W]VMA=*\`H&Q8
+MU:P,4,IX$3(E85PYBB=B[TVM7136_[",*;E,=#$'5]P2#!GQ(\QQ1BV(-$Y#
+M!C*.6V(.'E5&G(JHXZ*0.[IRAHM&`,FQ,7L2K4S56J0O\2QI#]8DMF!9JRC.
+M*8@!>]>JQI64.O_;W*P&-9D9%!=`J;)F5'$FE5K[E2Q3/QUI/5$=S^"&X3,W
+M56]8KW1*IMKM('2,6&SKG$6".0\01WM#_2<?:K5VJ$=Y;?$T3C3A7S""C-*/
+MQY-@.NP-^95'D1Y7"6\&`YV`ULTBY42^HOF9T^L[1RFZQRH$G.DT66NW8"IL
+M29R,G&3G-H@\+U?[,Z!;,3;/R<77$@6OJ+!N9^6<;+QUV.6T1+*S6XO%V:KP
+M+EG&^K5G(GOM/2IE9].K?LJ@4?>)QU[]D.VQTI?M3,C8+G[H.'/T.^5O/%=D
+M>XXVA<.?=#KLI\9FW`]PKS,D=A<G>C(*^J(EX<R2VLZQ14(!T9ZVP;^(O3*Z
+MX"F3>EUPE;$%XIJ#,,I6J]?PS->U;#3K;NL5DG5[\<R87QH(/M)`!BQCUTER
+MM@:)7H4:I!?=JZIMR%:.<I3_;>40V5<U@M8<$`V,]#\G!)$SPGK@NO"8TX:W
+M>-]"?S^Q4\-Z%^_-(?.?V*73PA+].BSE$_MUF=*GU,=AFXC?!8RI40Z*!>KE
+M?Z':,!?=0KC+QB);"QKN+=4*%C(:S%D0#?0H'G@>W@'(`J[R&\+O-%YY>T[*
+M,K6[GTS[WPS&EWZHGWIM$KQQ%CJ%,T@0QA.(-"`Z$N<JQN,!TV36G^)\M8WK
+MI=H\VP"F+0XK;75(%8SN;A7UBCM17IA$67YB@.A@%`9)J'XY/#A1X[X2P-/P
+M9YJ'W^G>/7P9D5S!!A^>:GG3!<><`UH/#$EZIH81%/+9;+`07,Q49Z/I$&>-
+M*IU-^.!,3@O9(H1(V@+^1^H]R91HV@0MOK7I5\-+=BX83K,+;K&Q5U"?0T2N
+M#\V=#-QLH]9_I@QN?>?NU@,>N`PS:Y>IMKD,+!?_A^:JEX`;C6\L`!6[RD9L
+M,1-_0V*->9A[T=H;?I=K4\VWP17>]UZN=H<RPB&_Q1RR^"^;)EOJG]FO*5&=
+M;6GX.7CG8<RW<<Z"L=J/Y/=OQ!,5KU>CC]DD9$^&6'K9H"R6[G0FV;%@EPMJ
+M(N*9/8>`HQ8.+Q+P^"!2WP:G4QKU_H!_EOKC!\AXPYQA)Z`U(X2+6,S/9N#>
+M'+^?'<!]"U9)*K6VLM?M;J[7=?U<)Q$W=QP3A3A/_AO]14#=[^DD+G5/F,BH
+M,34[UR&?:NTYX<3*SL;F]KI=9PZHNAQ`3PG7Q0H<Q1'[KRE615),H+.[MVX7
+MB]LV&_[5B'0;`MT/`4VA3\#9-SG^#P%GE#H1XH>73\8I?*?FW2MDU0T2!188
+M?`';A?<'5I=OW4.%BMJ38*"S57VI^VJ#H\<^67!5(;MG&Y#:_1-^3%CDE_%[
+MN)U%5B'C6ZQ&0C)P`.%3'>GMC3X]56_BLRA%5[_W?B_U8^U+-&3%0VZQ>#A@
+M!Z5X-IW,I@3FS=VMG74?R$WZ,N($H,S#E8?0\L9;F#H'L.6"3[@@QI^'(!PB
+MS`+CQ+I]/CW34JPOC5B+X6.2BCEX;65KQ[3&W?:Z(KGV.KY+<S87G"E&E%E@
+M,8JR=,.DCA\5XN!57XHU!6YC-.XQ)@=DJ^U[04PN*X$$/58=!>9&N:-^GNQU
+MUUUF0S1[F6Y`F0U7&,^B@6$`KY(A4=G1DGAXRHQF>C6):=,-,&*[V":TA+67
+M^X;[TOB[>QUG_),$'&V9+N-+"2MR<6Z86Q;'`B"RCA>$.!%3F47B6+J6?7X;
+MZ5RK43#!I48)4I(2]9Q,KGS+47C8>\L,F]O$($TVP:.'9ZQ2/0G8MRTU%ZG!
+M97PBAN"??QFAAOWEB#S"F=;C>!]BU"=IT-FD><M$QBM18--8VICH&-L)_IXZ
+M2(?LV8HPMFCW3`^+/FT%#[W4=U=M8WMY1"F:?*R\QJ!AK4K>L2*Q/G95+=,I
+MF&WWR6*[V;#47-V%C&OB3^LP,M/S+0'FII>:C_'@I`4<(P!V&D2Z2C$L2CFA
+MA@VULMR7'?1HH8E$_Q6(6(MW3[)@+(;>\FIGDA<A#1Z?;G'D)=8G9J,ZO=.%
+M6W<QN/7C)-&7_6GUB-)G`H43/FO"X^VL+_'`<]1G^S(;V_U<ZJ)^.PL#56%^
+M,_8?%%.BV=30%21#Y]ZF:LWZYHJ``NK%PMB"^#$<8P$)EGO^$W\S6R#@Q]LA
+M8>/;_G<Z(M5D?SRF24??C(=1Y$=Z^M22=^YL9QF,R85+ZM$V`\XO.+VWJ#S'
+MH,`:[+#P.#.^A*3DX94^XA&GI[*,_>GHRN(`ZVH=Z>?MD*098B_?^PZ$Y)=Q
+MJ;-G++H(2O(M2BS*7-F'/>#Q;MW%&6RU[/..]9SE%]-1W]S2Q\N9[*\+5VD3
+MG\*\ZTF5V>B"\-FS49",KGQ7Z20I=-F)S-6Q!76,RL:MWDU:(,H!]]G,UN?+
+M`=@BA$V]810D\C32MM]]G!)I[^<8<V5HYIYZE\2XB4;:K_6DWB?VF99ZFL)/
+M?22D5XCTT/@(A[I%R-JB$E9PYM:[RR"2)@F>]FWHR`-IOI6HM<XRK5G*)'IR
+M04DZ(G(B.+Y+XFD4#36I7PEN6NR'O_?*[22#LR^446#A`&W5?2`WG(5&@B,T
+MY;.`W8U[VG0.P!#-ZM&.(N7-S(0[WUJT<V['ZN$,:.H5V^?=L^,7%@71I&S]
+MA9O,)3O3..A!D`QCQ#8@1!!:RB>9LTF:Z1LA!.T9<XG#+,"(=;17:TRNS%_K
+MOB*BFQ!>D!9'.PY:"FTC4HEL;!+,C'$M%<9!FQ278X"]CUBL?L075(C:_=-=
+MN8V]!6<Z)LV_?!09]@@EV`J7\>109-I<GA&7<6;7MLX:5Y'EMJ)/%%^LP[9S
+M='+P)2G1@X1-%T*RZQS^62C<\O=:^,?OM.3!"8GL!EEGRW^BUB`U'=,0OJ,.
+M>GI*8A/]>Z$U:G:YQK:_L4[D=$8TMQ^`UAIYGT0T!,_WX`5QE;F^AS$$`L/;
+M+:GD4<E5$<>=AS81J<S91'`T)E,!`;5SH$Y^+$X5XX)'.:*3JO2,!]:#U!CI
+M3#KC93,(>I`,S]5)$M/^W=<7T[HU<WP;[&(Y)K+NYH+K+Q(>+ZX52'/;DRRE
+MVQ7><>:IR8TKTJR+W*JSO5R_."ZP_1K%E$T;9B-5#/H8%>GI!;[26:K+.MNJ
+MXJN$+OPV%J5\8A@*Q3*TY^_F]`A4D%C)&%1B*J(XBVKC'B)*RO=QP0BJTZPV
+M>ZX?PRIB28]C!MC87`Q+F'HX>J,5"J%HC(?,M^-S;/%99'`\1W$V+@%_:USA
+M!/9LW.LN,A((/[2N`RAM4R'V+34+K3F3!4*"7WM'K:7GP\D$?HK;7ZQG.CG4
+MELXB'8EMMDWL%X@*^O)L-#D+B.9F3(8-+Z($'+Y^GP7`2M=]5_!>#,+2782H
+M9+)(?A.KXF\F>___^-W;SR'^0W>WT^'X#[O=)OY#DYK4I"8UJ4E-:E*3FM2D
+M)C6I24UJ4I.:U*0F-:E)36I2DYK4I"8UJ4E-:E*3FM2D)C6I2?/2_P"5Y0%=
+$`.`!````
+`
+end
diff --git a/contrib/start_dynamic_ppp b/contrib/start_dynamic_ppp
new file mode 100644
index 00000000..7ceeddb3
--- /dev/null
+++ b/contrib/start_dynamic_ppp
@@ -0,0 +1,16 @@
+#!/bin/sh
+# setup hostname in /etc/hosts.  use IP if no name available.
+echo cyberhq > /tmp/local_name
+echo $4 > /tmp/ip
+host $4 | fgrep Name | cut -c7- > /tmp/ip_name
+if [ ! -s /tmp/ip_name ]; then
+    echo $4 > /tmp/ip_name
+fi
+cat /tmp/ip_name > /etc/sendmail.cw
+paste /tmp/ip /tmp/ip_name /tmp/local_name > /tmp/host_bottom
+cat /etc/hosts.top /tmp/host_bottom > /etc/hosts
+rm /tmp/ip /tmp/ip_name /tmp/host_bottom /tmp/local_name
+# Restart sendmail with new name.
+kill -HUP `head -1 /var/run/sendmail.pid`
+# Start fetchmail as root to fetch our mail.
+fetchmail
diff --git a/contrib/toprocmail b/contrib/toprocmail
new file mode 100644
index 00000000..159c0b38
--- /dev/null
+++ b/contrib/toprocmail
@@ -0,0 +1,46 @@
+#!/usr/bin/perl
+
+# fetchmail -> procmail pretti-fier proxy thingamajig
+# ver. 2000-04-01
+#
+# John Lim Eng Hooi <jleh@mail.com>
+#
+
+# Where's procmail located?
+$proc_path = '/usr/bin/procmail';
+
+# Define your ANSI color codes here, I've only bothered to define
+# those I use :)
+$ANSI_green = "\e[0;32m";
+$ANSI_b_white = "\e[1;37m";
+$ANSI_normal = "\e[0;39m";
+
+# Open up procmail
+open (PROCPIPE, "|$proc_path") || die "Can't open procmail pipe!";
+
+# Analyze the message line by line
+while (<STDIN>) {
+
+   # Suck up the lines we want, in this case I just want From: and Subject:
+   if (/^From:/) {
+     $from = $_;
+   }
+
+   if (/^Subject:/) {
+     $subj = $_;
+   }
+
+   # Stuff it out to the pipe too
+   print PROCPIPE;
+}
+
+# Print it out
+print "\n";
+print $ANSI_green, "  ", $from;
+print $ANSI_b_white, "  ", $subj, $ANSI_normal;
+
+# fetchmail's status is appended after this
+print "  -->";
+
+# We're done
+close (PROCPIPE);
diff --git a/contrib/zsh-completion b/contrib/zsh-completion
new file mode 100644
index 00000000..c5e653f4
--- /dev/null
+++ b/contrib/zsh-completion
@@ -0,0 +1,20 @@
+# Set up command completion for zsh
+#
+fetchmailauthtypes=(password kerberos kerberos_v5)
+fetchmailprotocols=(auto pop2 pop3 apop rpop kpop sdps imap imap-k4 imap-gss etrn)
+function fetchmailformattedinterfaces ()
+{ reply=(`ifconfig|perl -e '$/="";while(<>){s/[\r\n]//g;if(/^(\w+\d*).*inet addr:([\d\.]+)/){print "$1/$2\n";}}'`) }
+function fetchmailcompctl ()
+{ reply=(`awk '{ print $2 }' < ~/.fetchmailrc` `fetchmail --help 2>&1| cut -c 7-19 | sed "s/,//g"`) }
+compctl -K fetchmailcompctl \
+	-x "C[-1,-L|--logfile]" -f \
+	-  "C[-1,-f|--fetchmailrc]" -f \
+	-  "C[-1,-i|--idfile]" -f \
+	-  "C[-1,-I|--interface]" -K fetchmailformattedinterfaces \
+	-  "C[-1,-M|--monitor]" -K fetchmailformattedinterfaces \
+	-  "C[-1,-p|--protocol]" -k fetchmailprotocols \
+	-  "C[-1,-A|--auth]" -k fetchmailauthtypes \
+	-  "c[-1,--plugin]" -m \
+	-  "c[-1,--plugout]" -m \
+	-- fetchmail
+
diff --git a/fetchmail.png b/fetchmail.png
new file mode 100644
index 00000000..19f5031b
--- /dev/null
+++ b/fetchmail.png
diff --git a/fetchmail.ppm b/fetchmail.ppm
new file mode 100644
index 00000000..71593dd1
--- /dev/null
+++ b/fetchmail.ppm
diff --git a/fetchmail.xpm b/fetchmail.xpm
new file mode 100644
index 00000000..94c6670d
--- /dev/null
+++ b/fetchmail.xpm
@@ -0,0 +1,302 @@
+/* XPM */
+static char *magick[] = {
+/* columns rows colors chars-per-pixel */
+"60 40 256 2",
+"   c Gray0",
+".  c Gray3",
+"X  c #000010",
+"o  c #101010",
+"O  c #000021",
+"+  c #000029",
+"@  c #000039",
+"#  c #001839",
+"$  c #211818",
+"%  c #311000",
+"&  c #312100",
+"*  c #312918",
+"=  c #213139",
+"-  c #293139",
+";  c #00004a",
+":  c #000052",
+">  c #00184a",
+",  c #18104a",
+"<  c #000063",
+"1  c #00006b",
+"2  c #001063",
+"3  c #00215a",
+"4  c #002952",
+"5  c #10294a",
+"6  c #002963",
+"7  c #312942",
+"8  c #292163",
+"9  c #29217b",
+"0  c #4a3910",
+"q  c #4a3129",
+"w  c #5a3929",
+"e  c #6b2900",
+"r  c #633908",
+"t  c #6b3910",
+"y  c #4a4a31",
+"u  c #734218",
+"i  c #6b4229",
+"p  c #6b5231",
+"a  c #7b5229",
+"s  c #7b5a31",
+"d  c #4a4a7b",
+"f  c #6b5242",
+"g  c #6b5a42",
+"h  c #63635a",
+"j  c #736b42",
+"k  c #636b6b",
+"l  c #736b63",
+"z  c #000094",
+"x  c #00009c",
+"c  c #0000a5",
+"v  c #0000ad",
+"b  c #00298c",
+"n  c #00299c",
+"m  c #003184",
+"M  c #00399c",
+"N  c #0021b5",
+"B  c #212194",
+"V  c #0000ce",
+"C  c #0000d6",
+"Z  c #0018c6",
+"A  c #0810de",
+"S  c #0000e7",
+"D  c #0000f7",
+"F  c Blue",
+"G  c #0808ff",
+"H  c #1810e7",
+"J  c #0029c6",
+"K  c #0029ff",
+"L  c #2929ff",
+"P  c #004a8c",
+"I  c #004a9c",
+"U  c #10529c",
+"Y  c #005abd",
+"T  c #215294",
+"R  c #0052d6",
+"E  c #0042e7",
+"W  c #0042ff",
+"Q  c #004af7",
+"!  c #004aff",
+"~  c #0052ef",
+"^  c #0052ff",
+"/  c #006bef",
+"(  c #0063ff",
+")  c #007bff",
+"_  c #317bd6",
+"`  c #5a63bd",
+"'  c #637384",
+"]  c #737b84",
+"[  c #4242ff",
+"{  c #4a42ff",
+"}  c #4a52ff",
+"|  c #427bce",
+" . c #635af7",
+".. c #636bef",
+"X. c #0084ff",
+"o. c #008cff",
+"O. c #1084ff",
+"+. c #2984ff",
+"@. c #39adff",
+"#. c #7b9494",
+"$. c #638cb5",
+"%. c #5294c6",
+"&. c #528ce7",
+"*. c #5a9cf7",
+"=. c #4aa5ff",
+"-. c #52b5ff",
+";. c #739cd6",
+":. c #7384ef",
+">. c #7bb5d6",
+",. c #6ba5ef",
+"<. c #63adff",
+"1. c #6bbdff",
+"2. c #7bade7",
+"3. c #843910",
+"4. c #844208",
+"5. c #9c5218",
+"6. c #8c5221",
+"7. c #8c5229",
+"8. c #945a29",
+"9. c #9c5229",
+"0. c #946339",
+"q. c #a56318",
+"w. c #a56b39",
+"e. c #846352",
+"r. c #84735a",
+"t. c #947b63",
+"y. c #a57b5a",
+"u. c #ad7b52",
+"i. c #b5734a",
+"p. c #b57b4a",
+"a. c #d67b18",
+"s. c #847bce",
+"d. c #9c944a",
+"f. c #8c8473",
+"g. c #9c846b",
+"h. c #9c847b",
+"j. c #9c947b",
+"k. c #ad8c5a",
+"l. c #b58452",
+"z. c #ad8463",
+"x. c #bd8c63",
+"c. c #b59463",
+"v. c #bd946b",
+"b. c #a5a55a",
+"n. c #adad5a",
+"m. c #a5a573",
+"M. c #bda573",
+"N. c #b5b563",
+"B. c #ff9431",
+"V. c #c68c4a",
+"C. c #c68c5a",
+"Z. c #c6946b",
+"A. c #ce9463",
+"S. c #ce9c6b",
+"D. c #de9c6b",
+"F. c #cead7b",
+"G. c #d6a573",
+"H. c #dead73",
+"J. c #dede52",
+"K. c #c6c663",
+"L. c #ced67b",
+"P. c #dee773",
+"I. c #f7f752",
+"U. c #eff76b",
+"Y. c #ffff73",
+"T. c #848484",
+"R. c Gray55",
+"E. c #9c8c84",
+"W. c Gray58",
+"Q. c #9c9c94",
+"!. c #848cb5",
+"~. c #a5a594",
+"^. c #a5a5a5",
+"/. c Gray68",
+"(. c #adb5b5",
+"). c Gray71",
+"_. c #848cc6",
+"`. c #a5a5de",
+"'. c #a5bdc6",
+"]. c #b5bdc6",
+"[. c #a5a5ef",
+"{. c #a5bde7",
+"}. c #84ceff",
+"|. c #94d6ff",
+" X c #94efff",
+".X c #bdc6c6",
+"XX c #bdc6ce",
+"oX c #b5c6d6",
+"OX c #a5cef7",
+"+X c #addeff",
+"@X c #b5ceef",
+"#X c #c6ad9c",
+"$X c #ceb58c",
+"%X c #d6b584",
+"&X c #d6b58c",
+"*X c #d6bd8c",
+"=X c #deb58c",
+"-X c #d6bdb5",
+";X c #efb58c",
+":X c #c6ce8c",
+">X c #c6c6bd",
+",X c #dec6ad",
+"<X c #decebd",
+"1X c #d6d6bd",
+"2X c #ffce8c",
+"3X c #f7ce9c",
+"4X c #ffde94",
+"5X c #efdea5",
+"6X c #e7debd",
+"7X c #efd6b5",
+"8X c #efd6bd",
+"9X c NavajoWhite",
+"0X c #f7debd",
+"qX c #ffd6bd",
+"wX c #ffff8c",
+"eX c #e7e7ad",
+"rX c #e7e7bd",
+"tX c #efefbd",
+"yX c #ffe7b5",
+"uX c #ffffa5",
+"iX c #f7f7bd",
+"pX c #ffffb5",
+"aX c #c6c6c6",
+"sX c #c6c6ce",
+"dX c #cecece",
+"fX c #ceced6",
+"gX c #c6d6de",
+"hX c #d6cec6",
+"jX c #decec6",
+"kX c #d6d6ce",
+"lX c #dedece",
+"zX c #cedeef",
+"xX c #d6dee7",
+"cX c #cee7e7",
+"vX c #d6e7e7",
+"bX c #d6efff",
+"nX c #e7dec6",
+"mX c #efd6c6",
+"MX c #ffdec6",
+"NX c #efefce",
+"BX c #e7efd6",
+"VX c #efe7d6",
+"CX c #f7efc6",
+"ZX c #ffefce",
+"AX c #f7e7de",
+"SX c #ffffc6",
+"DX c #f7f7de",
+"FX c #ffffd6",
+"GX c #e7e7e7",
+"HX c #efefef",
+"JX c #eff7ef",
+"KX c #e7f7ff",
+"LX c #ffffe7",
+"PX c #f7ffff",
+"IX c #fff7f7",
+"UX c Gray100",
+/* pixels */
+"UXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXR.",
+"UXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUX).  ",
+"UXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXkXo   ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXT.T.T.T.T.T.T.T.T.T.T.T.T.T.T.T.T.T.T.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXf.h.h UXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXUXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaX.XsXaXaXaXf.t 6.q.e.'.UXUXUXUXUXUXUXUXUXUXUXUXUXUXUXIXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          T.T.aXaXaXW.e.t 9.H.G.0.i (.vXUXUXUXUXUXUXUXUXUXUXUXUXUXlX^.T.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          UXPXk E.u 8.w.A.H.&X$X3XA.e Q.'.xXUXUXUXUXUXUXUXUXUXGXW./.UXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          UXUXp 5.Z.Z.x.F.*XF.F.%X5X3Xp.u g oX>XUXUXUXUXUXHXQ.^.UXUXUXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          UXUXr.D.v.x.x.k.F.=X=XF.0.p.9X;XV.#XzXR.aXUXGX^.R.UXUXUXUXUXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          UXUXr.A.Z.x.v.c.z.u.s 6.w f 3.3.4.g.vXUXkXR./.UXUX/.UXUXUXUXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          UXUXe.A.x.k.C.Z.Z.l.u.p.T.UXkXGX].sXUXUXUXUXUXUXUXHXQ.UXUXUXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          UXUXe.A.S.Z.x.Z.x.x.Z.D.T.UXUXUX].UXUXUXUXUXUXUXUXUXHX^.UXUXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          UXUXt.p.7.6.l.C.C.C.i.6.T.UXGX~.UXUXUXUXUXUXUXUXUXUXUXGX^.UXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          UXUXw s h.g.p p p i e.g.T.UXaXUXUXUXUXUXUXUXUXUXUXUXUXUXUXlXT.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX          UXUXl aXaXaXaXaXaXaXaXaXT.T.T.T.T.T.T.T.T.T.T.T.T.T.T.T.T.T.T.aXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXsXaXaX          T.T.aXaXaXaXaXaXaXsXsXsXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXsXsXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaX  . . .   aXaXaXaXaXaXaXaXhXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXsXsXsX>XaXaXsXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXXXXXaXaXaXaXaXaXaXaXaXaXaXaXaXXXXXsXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXsXaXaXsXsXsXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXXX7XyXdXaXaXaXaXaXaXaXaXaXaXaXdX7XqXkXsXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXsXXXiXCXdXiXiXsXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXsXaX9XOX=.AXkXaXaXaXjXmXaXdXaXsXaX.X2.,.fXhXsXaXaXaXsXaXdXaXaXaXaXaX>XXXaXaXtX .`.kX..:.NXsXaXaXaXaX      ",
+"UXUXUXaXaXaXaXXXyX<.n ! : 9XlXsX<X.X{.MX.XXX<XkX0X_ ^ $ LXdX.XkXhXdX1XhXXXhXdXaXaXhX6XhX].pXF : K.F v d.HXaXaXaXaX      ",
+"UXUXUXaXaXaX.XkXmX) 6 yXl.KXgXyXZX+.Z E.IXqXcXdXSX@X( & IX8XBXsX6XSXlXtXSXfXtXVXrXCX[.rXFXoXeXj SX} c b.HX>XaXaXaX      ",
+"UXUXUXaXaXaXaXMXY ) R = bXI M O.-X/ X.< H.@.b Q %.XX) U ~ ^ 2X&.F A C F ` S F L.[.F 7 F ^.>XF S Y.{ c n.HXaXaXaXaX      ",
+"UXUXUXaXaXaXaXkX9X) # 3X) 6 >.W % |.J a.|.! e }.X W.o.% .X^ & LXF O P.F + :XF $ LX< j.F : wXL z J.} c b.HXaXaXaXaX      ",
+"UXUXUXaXaXaXaXhX0X) > 8X) 3 M.y.G.-.N B.1.^ a FX4X+X^ r KXK 0 LXF * FXF * IXF * JXH - F : wXL z I. .x n.HXaXaXaXaX      ",
+"UXUXUXaXaXaXaX1XkXX.b uX( E lX XQ.*.^ #.AX! Y KX| $.X.0 +XF y IXF , DXF , gXF y L D m.F z uXG C U.[ V N.JXaXaXaXaX      ",
+"UXUXUXaXaXaXaXlX;.3 2 ] ZXT 2 O g.DXP @ v.1Xm : q %.4 5 _.: : ` < @ !.1 @ s.< ; ~.c @ ' < d B ; 9 B : 8 nXdXaXaXaX      ",
+"UXUXUXaXaXsXsXaX6X7XMXaXlXMX,XVXHXhXqX7XxXVX9X,XIXmX7XNXnXyXNX6XiXNXnXpXNXrXiXCXlXpXnXFXeXnXiXSXnXtXpXnXsXhXaXaXaX      ",
+"UXUXUXaXaXaXaXaXsXfXsXdXaXsXfXdXaXaXdXfXaXaXfXkXaXsXfXdXdXdXdXdXsXdXdXsXdXsXsXdXsXsXfXaXfXdXsXsXdXdXsXdXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaX      ",
+"UXUXUXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaXaX      ",
+"UXUXlX                                                                                                                  ",
+"UXkX$                                                                                                                   ",
+"R.o                                                                                                                     "
+};
diff --git a/getopt.h b/getopt.h
new file mode 100644
index 00000000..4ac33b71
--- /dev/null
+++ b/getopt.h
@@ -0,0 +1,129 @@
+/* Declarations for getopt.
+   Copyright (C) 1989, 90, 91, 92, 93, 94 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by the
+   Free Software Foundation; either version 2, or (at your option) any
+   later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.  */
+
+#ifndef _GETOPT_H
+#define _GETOPT_H 1
+
+#ifdef	__cplusplus
+extern "C" {
+#endif
+
+/* For communication from `getopt' to the caller.
+   When `getopt' finds an option that takes an argument,
+   the argument value is returned here.
+   Also, when `ordering' is RETURN_IN_ORDER,
+   each non-option ARGV-element is returned here.  */
+
+extern char *optarg;
+
+/* Index in ARGV of the next element to be scanned.
+   This is used for communication to and from the caller
+   and for communication between successive calls to `getopt'.
+
+   On entry to `getopt', zero means this is the first call; initialize.
+
+   When `getopt' returns EOF, this is the index of the first of the
+   non-option elements that the caller should itself scan.
+
+   Otherwise, `optind' communicates from one call to the next
+   how much of ARGV has been scanned so far.  */
+
+extern int optind;
+
+/* Callers store zero here to inhibit the error message `getopt' prints
+   for unrecognized options.  */
+
+extern int opterr;
+
+/* Set to an option character which was unrecognized.  */
+
+extern int optopt;
+
+/* Describe the long-named options requested by the application.
+   The LONG_OPTIONS argument to getopt_long or getopt_long_only is a vector
+   of `struct option' terminated by an element containing a name which is
+   zero.
+
+   The field `has_arg' is:
+   no_argument		(or 0) if the option does not take an argument,
+   required_argument	(or 1) if the option requires an argument,
+   optional_argument 	(or 2) if the option takes an optional argument.
+
+   If the field `flag' is not NULL, it points to a variable that is set
+   to the value given in the field `val' when the option is found, but
+   left unchanged if the option is not found.
+
+   To have a long-named option do something other than set an `int' to
+   a compiled-in constant, such as set a value from `optarg', set the
+   option's `flag' field to zero and its `val' field to a nonzero
+   value (the equivalent single-letter option character, if there is
+   one).  For long options that have a zero `flag' field, `getopt'
+   returns the contents of the `val' field.  */
+
+struct option
+{
+#if defined (__STDC__) && __STDC__
+  const char *name;
+#else
+  char *name;
+#endif
+  /* has_arg can't be an enum because some compilers complain about
+     type mismatches in all the code that assumes it is an int.  */
+  int has_arg;
+  int *flag;
+  int val;
+};
+
+/* Names for the values of the `has_arg' field of `struct option'.  */
+
+#define	no_argument		0
+#define required_argument	1
+#define optional_argument	2
+
+#if defined (__STDC__) && __STDC__
+#ifdef __GNU_LIBRARY__
+/* Many other libraries have conflicting prototypes for getopt, with
+   differences in the consts, in stdlib.h.  To avoid compilation
+   errors, only prototype getopt for the GNU C library.  */
+extern int getopt (int argc, char *const *argv, const char *shortopts);
+#else /* not __GNU_LIBRARY__ */
+extern int getopt ();
+#endif /* __GNU_LIBRARY__ */
+extern int getopt_long (int argc, char *const *argv, const char *shortopts,
+		        const struct option *longopts, int *longind);
+extern int getopt_long_only (int argc, char *const *argv,
+			     const char *shortopts,
+		             const struct option *longopts, int *longind);
+
+/* Internal only.  Users should not call this directly.  */
+extern int _getopt_internal (int argc, char *const *argv,
+			     const char *shortopts,
+		             const struct option *longopts, int *longind,
+			     int long_only);
+#else /* not __STDC__ */
+extern int getopt ();
+extern int getopt_long ();
+extern int getopt_long_only ();
+
+extern int _getopt_internal ();
+#endif /* __STDC__ */
+
+#ifdef	__cplusplus
+}
+#endif
+
+#endif /* _GETOPT_H */
diff --git a/gettext.m4 b/gettext.m4
new file mode 100644
index 00000000..ab9546f7
--- /dev/null
+++ b/gettext.m4
@@ -0,0 +1,329 @@
+# Macro to add for using GNU gettext.
+# Ulrich Drepper <drepper@cygnus.com>, 1995.
+#
+# This file can be copied and used freely without restrictions.  It can
+# be used in projects which are not available under the GNU Public License
+# but which still want to provide support for the GNU gettext functionality.
+# Please note that the actual code is *not* freely available.
+
+# serial 108
+
+AC_PREREQ(2.13)               dnl Minimum Autoconf version required.
+
+AC_DEFUN(AM_WITH_NLS,
+  [AC_MSG_CHECKING([whether NLS is requested])
+    dnl Default is enabled NLS
+    AC_ARG_ENABLE(nls,
+      [  --disable-nls           do not use Native Language Support],
+      USE_NLS=$enableval, USE_NLS=yes)
+    AC_MSG_RESULT($USE_NLS)
+    AC_SUBST(USE_NLS)
+
+    USE_INCLUDED_LIBINTL=no
+
+    AC_ARG_WITH(locale-dir,
+      [  --with-locale-dir=DIR   specify locale directory],
+      LOCALE_DIR=$withval)
+    test -z "$LOCALE_DIR" && LOCALE_DIR='$(datadir)/locale'
+    AC_SUBST(LOCALE_DIR)
+
+    AC_ARG_WITH(gnu-locale-dir,
+      [  --with-gnu-locale-dir=DIR specify GNU locale directory],
+      GNU_LOCALE_DIR=$withval)
+    test -z "$GNU_LOCALE_DIR" && GNU_LOCALE_DIR='$(prefix)/share/locale'
+    AC_SUBST(GNU_LOCALE_DIR)
+
+    dnl If we use NLS figure out what method
+    if test "$USE_NLS" = "yes"; then
+      AC_DEFINE(ENABLE_NLS, 1, [Define to 1 if NLS is requested.])
+      AC_MSG_CHECKING([whether included gettext is requested])
+      AC_ARG_WITH(included-gettext,
+        [  --with-included-gettext use the GNU gettext library included here],
+        nls_cv_force_use_gnu_gettext=$withval,
+        nls_cv_force_use_gnu_gettext=no)
+      AC_MSG_RESULT($nls_cv_force_use_gnu_gettext)
+
+      nls_cv_use_gnu_gettext="$nls_cv_force_use_gnu_gettext"
+      if test "$nls_cv_force_use_gnu_gettext" != "yes"; then
+        dnl User does not insist on using GNU NLS library.  Figure out what
+        dnl to use.  If gettext or catgets are available (in this order) we
+        dnl use this.  Else we have to fall back to GNU NLS library.
+	dnl catgets is only used if permitted by option --with-catgets.
+	nls_cv_header_intl=
+	nls_cv_header_libgt=
+	CATOBJEXT=NONE
+
+	AC_CHECK_HEADER(libintl.h,
+	  [AC_CACHE_CHECK([for gettext in libc], gt_cv_func_gettext_libc,
+	    [AC_TRY_LINK([#include <libintl.h>], [return (int) gettext ("")],
+	       gt_cv_func_gettext_libc=yes, gt_cv_func_gettext_libc=no)])
+
+	   if test "$gt_cv_func_gettext_libc" != "yes"; then
+	     AC_CHECK_LIB(intl, bindtextdomain,
+	       [AC_CHECK_LIB(intl, gettext)])
+	   fi
+
+	   if test "$gt_cv_func_gettext_libc" = "yes" \
+	      || test "$ac_cv_lib_intl_gettext" = "yes"; then
+	      AC_DEFINE(HAVE_GETTEXT, 1,
+	  [Define to 1 if you have gettext and don't want to use GNU gettext.])
+	      AM_PATH_PROG_WITH_TEST(MSGFMT, msgfmt,
+		[test -z "`$ac_dir/$ac_word -h 2>&1 | grep 'dv '`"], no)dnl
+	      if test "$MSGFMT" != "no"; then
+		AC_CHECK_FUNCS(dcgettext)
+		AC_PATH_PROG(GMSGFMT, gmsgfmt, $MSGFMT)
+		AM_PATH_PROG_WITH_TEST(XGETTEXT, xgettext,
+		  [test -z "`$ac_dir/$ac_word -h 2>&1 | grep '(HELP)'`"], :)
+		AC_TRY_LINK(, [extern int _nl_msg_cat_cntr;
+			       return _nl_msg_cat_cntr],
+		  [CATOBJEXT=.gmo
+		   DATADIRNAME=share],
+		  [CATOBJEXT=.mo
+		   DATADIRNAME=lib])
+		INSTOBJEXT=.mo
+	      fi
+	    fi
+	])
+
+        if test "$CATOBJEXT" = "NONE"; then
+	  AC_MSG_CHECKING([whether catgets can be used])
+	  AC_ARG_WITH(catgets,
+	    [  --with-catgets          use catgets functions if available],
+	    nls_cv_use_catgets=$withval, nls_cv_use_catgets=no)
+	  AC_MSG_RESULT($nls_cv_use_catgets)
+
+	  if test "$nls_cv_use_catgets" = "yes"; then
+	    dnl No gettext in C library.  Try catgets next.
+	    AC_CHECK_LIB(i, main)
+	    AC_CHECK_FUNC(catgets,
+	      [AC_DEFINE(HAVE_CATGETS, 1,
+			 [Define as 1 if you have catgets and don't want to use GNU gettext.])
+	       INTLOBJS="\$(CATOBJS)"
+	       AC_PATH_PROG(GENCAT, gencat, no)dnl
+	       if test "$GENCAT" != "no"; then
+		 AC_PATH_PROG(GMSGFMT, gmsgfmt, no)
+		 if test "$GMSGFMT" = "no"; then
+		   AM_PATH_PROG_WITH_TEST(GMSGFMT, msgfmt,
+		    [test -z "`$ac_dir/$ac_word -h 2>&1 | grep 'dv '`"], no)
+		 fi
+		 AM_PATH_PROG_WITH_TEST(XGETTEXT, xgettext,
+		   [test -z "`$ac_dir/$ac_word -h 2>&1 | grep '(HELP)'`"], :)
+		 USE_INCLUDED_LIBINTL=yes
+		 CATOBJEXT=.cat
+		 INSTOBJEXT=.cat
+		 DATADIRNAME=lib
+		 INTLDEPS='$(top_builddir)/intl/libintl.a'
+		 INTLLIBS=$INTLDEPS
+		 LIBS=`echo $LIBS | sed -e 's/-lintl//'`
+		 nls_cv_header_intl=intl/libintl.h
+		 nls_cv_header_libgt=intl/libgettext.h
+	       fi])
+	  fi
+        fi
+
+        if test "$CATOBJEXT" = "NONE"; then
+	  dnl Neither gettext nor catgets in included in the C library.
+	  dnl Fall back on GNU gettext library.
+	  nls_cv_use_gnu_gettext=yes
+        fi
+      fi
+
+      if test "$nls_cv_use_gnu_gettext" = "yes"; then
+        dnl Mark actions used to generate GNU NLS library.
+        INTLOBJS="\$(GETTOBJS)"
+        AM_PATH_PROG_WITH_TEST(MSGFMT, msgfmt,
+	  [test -z "`$ac_dir/$ac_word -h 2>&1 | grep 'dv '`"], msgfmt)
+        AC_PATH_PROG(GMSGFMT, gmsgfmt, $MSGFMT)
+        AM_PATH_PROG_WITH_TEST(XGETTEXT, xgettext,
+	  [test -z "`$ac_dir/$ac_word -h 2>&1 | grep '(HELP)'`"], :)
+        AC_SUBST(MSGFMT)
+	USE_INCLUDED_LIBINTL=yes
+        CATOBJEXT=.gmo
+        INSTOBJEXT=.mo
+        DATADIRNAME=share
+	INTLDEPS='$(top_builddir)/intl/libintl.a'
+	INTLLIBS=$INTLDEPS
+	LIBS=`echo $LIBS | sed -e 's/-lintl//'`
+        nls_cv_header_intl=intl/libintl.h
+        nls_cv_header_libgt=intl/libgettext.h
+      fi
+
+      dnl Test whether we really found GNU xgettext.
+      if test "$XGETTEXT" != ":"; then
+	dnl If it is no GNU xgettext we define it as : so that the
+	dnl Makefiles still can work.
+	if $XGETTEXT --omit-header /dev/null 2> /dev/null; then
+	  : ;
+	else
+	  AC_MSG_RESULT(
+	    [found xgettext program is not GNU xgettext; ignore it])
+	  XGETTEXT=":"
+	fi
+      fi
+
+      # We need to process the po/ directory.
+      POSUB=po
+    else
+      DATADIRNAME=share
+      nls_cv_header_intl=intl/libintl.h
+      nls_cv_header_libgt=intl/libgettext.h
+    fi
+    if test -z "$nls_cv_header_intl"; then
+      # Clean out junk possibly left behind by a previous configuration.
+      rm -f intl/libintl.h
+    fi
+    AC_LINK_FILES($nls_cv_header_libgt, $nls_cv_header_intl)
+    AC_OUTPUT_COMMANDS(
+     [case "$CONFIG_FILES" in *po/Makefile.in*)
+        sed -e "/POTFILES =/r po/POTFILES" po/Makefile.in > po/Makefile
+      esac])
+
+
+    # If this is used in GNU gettext we have to set USE_NLS to `yes'
+    # because some of the sources are only built for this goal.
+    if test "$PACKAGE" = gettext; then
+      USE_NLS=yes
+      USE_INCLUDED_LIBINTL=yes
+    fi
+
+    dnl These rules are solely for the distribution goal.  While doing this
+    dnl we only have to keep exactly one list of the available catalogs
+    dnl in configure.in.
+    for lang in $ALL_LINGUAS; do
+      GMOFILES="$GMOFILES $lang.gmo"
+      POFILES="$POFILES $lang.po"
+    done
+
+    dnl Make all variables we use known to autoconf.
+    AC_SUBST(USE_INCLUDED_LIBINTL)
+    AC_SUBST(CATALOGS)
+    AC_SUBST(CATOBJEXT)
+    AC_SUBST(DATADIRNAME)
+    AC_SUBST(GMOFILES)
+    AC_SUBST(INSTOBJEXT)
+    AC_SUBST(INTLDEPS)
+    AC_SUBST(INTLLIBS)
+    AC_SUBST(INTLOBJS)
+    AC_SUBST(POFILES)
+    AC_SUBST(POSUB)
+  ])
+
+AC_DEFUN(AM_GNU_GETTEXT,
+  [AC_REQUIRE([AC_PROG_MAKE_SET])dnl
+   AC_REQUIRE([AC_PROG_CC])dnl
+   AC_REQUIRE([AC_PROG_RANLIB])dnl
+   AC_REQUIRE([AC_ISC_POSIX])dnl
+   AC_REQUIRE([AC_HEADER_STDC])dnl
+   AC_REQUIRE([AC_C_CONST])dnl
+   AC_REQUIRE([AC_C_INLINE])dnl
+   AC_REQUIRE([AC_TYPE_OFF_T])dnl
+   AC_REQUIRE([AC_TYPE_SIZE_T])dnl
+   AC_REQUIRE([AC_FUNC_ALLOCA])dnl
+   AC_REQUIRE([AC_FUNC_MMAP])dnl
+
+   AC_CHECK_HEADERS([argz.h limits.h locale.h nl_types.h malloc.h string.h \
+unistd.h sys/param.h])
+   AC_CHECK_FUNCS([getcwd munmap putenv setenv setlocale strchr strcasecmp \
+strdup __argz_count __argz_stringify __argz_next])
+
+   if test "${ac_cv_func_stpcpy+set}" != "set"; then
+     AC_CHECK_FUNCS(stpcpy)
+   fi
+   if test "${ac_cv_func_stpcpy}" = "yes"; then
+     AC_DEFINE(HAVE_STPCPY, 1, [Define to 1 if you have the stpcpy function.])
+   fi
+
+   AM_LC_MESSAGES
+   AM_WITH_NLS
+
+   if test "x$CATOBJEXT" != "x"; then
+     if test "x$ALL_LINGUAS" = "x"; then
+       LINGUAS=
+     else
+       AC_MSG_CHECKING(for catalogs to be installed)
+       NEW_LINGUAS=
+       for lang in ${LINGUAS=$ALL_LINGUAS}; do
+         case "$ALL_LINGUAS" in
+          *$lang*) NEW_LINGUAS="$NEW_LINGUAS $lang" ;;
+         esac
+       done
+       LINGUAS=$NEW_LINGUAS
+       AC_MSG_RESULT($LINGUAS)
+     fi
+
+     dnl Construct list of names of catalog files to be constructed.
+     if test -n "$LINGUAS"; then
+       for lang in $LINGUAS; do CATALOGS="$CATALOGS $lang$CATOBJEXT"; done
+     fi
+   fi
+
+   dnl The reference to <locale.h> in the installed <libintl.h> file
+   dnl must be resolved because we cannot expect the users of this
+   dnl to define HAVE_LOCALE_H.
+   if test $ac_cv_header_locale_h = yes; then
+     INCLUDE_LOCALE_H="#include <locale.h>"
+   else
+     INCLUDE_LOCALE_H="\
+/* The system does not provide the header <locale.h>.  Take care yourself.  */"
+   fi
+   AC_SUBST(INCLUDE_LOCALE_H)
+
+   dnl Determine which catalog format we have (if any is needed)
+   dnl For now we know about two different formats:
+   dnl   Linux libc-5 and the normal X/Open format
+   test -d intl || mkdir intl
+   if test "$CATOBJEXT" = ".cat"; then
+     AC_CHECK_HEADER(linux/version.h, msgformat=linux, msgformat=xopen)
+
+     dnl Transform the SED scripts while copying because some dumb SEDs
+     dnl cannot handle comments.
+     sed -e '/^#/d' $srcdir/intl/$msgformat-msg.sed > intl/po2msg.sed
+   fi
+   dnl po2tbl.sed is always needed.
+   sed -e '/^#.*[^\\]$/d' -e '/^#$/d' \
+     $srcdir/intl/po2tbl.sed.in > intl/po2tbl.sed
+
+   dnl In the intl/Makefile.in we have a special dependency which makes
+   dnl only sense for gettext.  We comment this out for non-gettext
+   dnl packages.
+   if test "$PACKAGE" = "gettext"; then
+     GT_NO="#NO#"
+     GT_YES=
+   else
+     GT_NO=
+     GT_YES="#YES#"
+   fi
+   AC_SUBST(GT_NO)
+   AC_SUBST(GT_YES)
+
+   dnl If the AC_CONFIG_AUX_DIR macro for autoconf is used we possibly
+   dnl find the mkinstalldirs script in another subdir but ($top_srcdir).
+   dnl Try to locate is.
+   MKINSTALLDIRS=
+   if test -n "$ac_aux_dir"; then
+     MKINSTALLDIRS="$ac_aux_dir/mkinstalldirs"
+   fi
+   if test -z "$MKINSTALLDIRS"; then
+     MKINSTALLDIRS="\$(top_srcdir)/mkinstalldirs"
+   fi
+   AC_SUBST(MKINSTALLDIRS)
+
+   dnl *** For now the libtool support in intl/Makefile is not for real.
+   l=
+   AC_SUBST(l)
+
+   dnl Generate list of files to be processed by xgettext which will
+   dnl be included in po/Makefile.
+   test -d po || mkdir po
+   case "$srcdir" in
+   .)
+     posrcprefix="../" ;;
+   /* | [[A-Za-z]]:*)
+     posrcprefix="$srcdir/" ;;
+   *)
+     posrcprefix="../$srcdir/" ;;
+   esac
+   rm -f po/POTFILES
+   sed -e "/^#/d" -e "/^\$/d" -e "s,.*,	$posrcprefix& \\\\," -e "\$s/\(.*\) \\\\/\1/" \
+	< $srcdir/po/POTFILES.in > po/POTFILES
+  ])
diff --git a/install-sh b/install-sh
new file mode 100755
index 00000000..36f96f3e
--- /dev/null
+++ b/install-sh
@@ -0,0 +1,276 @@
+#!/bin/sh
+#
+# install - install a program, script, or datafile
+# This comes from X11R5 (mit/util/scripts/install.sh).
+#
+# Copyright 1991 by the Massachusetts Institute of Technology
+#
+# Permission to use, copy, modify, distribute, and sell this software and its
+# documentation for any purpose is hereby granted without fee, provided that
+# the above copyright notice appear in all copies and that both that
+# copyright notice and this permission notice appear in supporting
+# documentation, and that the name of M.I.T. not be used in advertising or
+# publicity pertaining to distribution of the software without specific,
+# written prior permission.  M.I.T. makes no representations about the
+# suitability of this software for any purpose.  It is provided "as is"
+# without express or implied warranty.
+#
+# Calling this script install-sh is preferred over install.sh, to prevent
+# `make' implicit rules from creating a file called install from it
+# when there is no Makefile.
+#
+# This script is compatible with the BSD install script, but was written
+# from scratch.  It can only install one file at a time, a restriction
+# shared with many OS's install programs.
+
+
+# set DOITPROG to echo to test this script
+
+# Don't use :- since 4.3BSD and earlier shells don't like it.
+doit="${DOITPROG-}"
+
+
+# put in absolute paths if you don't have them in your path; or use env. vars.
+
+mvprog="${MVPROG-mv}"
+cpprog="${CPPROG-cp}"
+chmodprog="${CHMODPROG-chmod}"
+chownprog="${CHOWNPROG-chown}"
+chgrpprog="${CHGRPPROG-chgrp}"
+stripprog="${STRIPPROG-strip}"
+rmprog="${RMPROG-rm}"
+mkdirprog="${MKDIRPROG-mkdir}"
+
+transformbasename=""
+transform_arg=""
+instcmd="$mvprog"
+chmodcmd="$chmodprog 0755"
+chowncmd=""
+chgrpcmd=""
+stripcmd=""
+rmcmd="$rmprog -f"
+mvcmd="$mvprog"
+src=""
+dst=""
+dir_arg=""
+
+while [ x"$1" != x ]; do
+    case $1 in
+	-c) instcmd=$cpprog
+	    shift
+	    continue;;
+
+	-d) dir_arg=true
+	    shift
+	    continue;;
+
+	-m) chmodcmd="$chmodprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-o) chowncmd="$chownprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-g) chgrpcmd="$chgrpprog $2"
+	    shift
+	    shift
+	    continue;;
+
+	-s) stripcmd=$stripprog
+	    shift
+	    continue;;
+
+	-t=*) transformarg=`echo $1 | sed 's/-t=//'`
+	    shift
+	    continue;;
+
+	-b=*) transformbasename=`echo $1 | sed 's/-b=//'`
+	    shift
+	    continue;;
+
+	*)  if [ x"$src" = x ]
+	    then
+		src=$1
+	    else
+		# this colon is to work around a 386BSD /bin/sh bug
+		:
+		dst=$1
+	    fi
+	    shift
+	    continue;;
+    esac
+done
+
+if [ x"$src" = x ]
+then
+	echo "$0: no input file specified" >&2
+	exit 1
+else
+	:
+fi
+
+if [ x"$dir_arg" != x ]; then
+	dst=$src
+	src=""
+
+	if [ -d "$dst" ]; then
+		instcmd=:
+		chmodcmd=""
+	else
+		instcmd=$mkdirprog
+	fi
+else
+
+# Waiting for this to be detected by the "$instcmd $src $dsttmp" command
+# might cause directories to be created, which would be especially bad
+# if $src (and thus $dsttmp) contains '*'.
+
+	if [ -f "$src" ] || [ -d "$src" ]
+	then
+		:
+	else
+		echo "$0: $src does not exist" >&2
+		exit 1
+	fi
+
+	if [ x"$dst" = x ]
+	then
+		echo "$0: no destination specified" >&2
+		exit 1
+	else
+		:
+	fi
+
+# If destination is a directory, append the input filename; if your system
+# does not like double slashes in filenames, you may need to add some logic
+
+	if [ -d "$dst" ]
+	then
+		dst=$dst/`basename "$src"`
+	else
+		:
+	fi
+fi
+
+## this sed command emulates the dirname command
+dstdir=`echo "$dst" | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'`
+
+# Make sure that the destination directory exists.
+#  this part is taken from Noah Friedman's mkinstalldirs script
+
+# Skip lots of stat calls in the usual case.
+if [ ! -d "$dstdir" ]; then
+defaultIFS='
+	'
+IFS="${IFS-$defaultIFS}"
+
+oIFS=$IFS
+# Some sh's can't handle IFS=/ for some reason.
+IFS='%'
+set - `echo "$dstdir" | sed -e 's@/@%@g' -e 's@^%@/@'`
+IFS=$oIFS
+
+pathcomp=''
+
+while [ $# -ne 0 ] ; do
+	pathcomp=$pathcomp$1
+	shift
+
+	if [ ! -d "$pathcomp" ] ;
+        then
+		$mkdirprog "$pathcomp"
+	else
+		:
+	fi
+
+	pathcomp=$pathcomp/
+done
+fi
+
+if [ x"$dir_arg" != x ]
+then
+	$doit $instcmd "$dst" &&
+
+	if [ x"$chowncmd" != x ]; then $doit $chowncmd "$dst"; else : ; fi &&
+	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd "$dst"; else : ; fi &&
+	if [ x"$stripcmd" != x ]; then $doit $stripcmd "$dst"; else : ; fi &&
+	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd "$dst"; else : ; fi
+else
+
+# If we're going to rename the final executable, determine the name now.
+
+	if [ x"$transformarg" = x ]
+	then
+		dstfile=`basename "$dst"`
+	else
+		dstfile=`basename "$dst" $transformbasename |
+			sed $transformarg`$transformbasename
+	fi
+
+# don't allow the sed command to completely eliminate the filename
+
+	if [ x"$dstfile" = x ]
+	then
+		dstfile=`basename "$dst"`
+	else
+		:
+	fi
+
+# Make a couple of temp file names in the proper directory.
+
+	dsttmp=$dstdir/#inst.$$#
+	rmtmp=$dstdir/#rm.$$#
+
+# Trap to clean up temp files at exit.
+
+	trap 'status=$?; rm -f "$dsttmp" "$rmtmp" && exit $status' 0
+	trap '(exit $?); exit' 1 2 13 15
+
+# Move or copy the file name to the temp name
+
+	$doit $instcmd "$src" "$dsttmp" &&
+
+# and set any options; do chmod last to preserve setuid bits
+
+# If any of these fail, we abort the whole thing.  If we want to
+# ignore errors from any of these, just make sure not to ignore
+# errors from the above "$doit $instcmd $src $dsttmp" command.
+
+	if [ x"$chowncmd" != x ]; then $doit $chowncmd "$dsttmp"; else :;fi &&
+	if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd "$dsttmp"; else :;fi &&
+	if [ x"$stripcmd" != x ]; then $doit $stripcmd "$dsttmp"; else :;fi &&
+	if [ x"$chmodcmd" != x ]; then $doit $chmodcmd "$dsttmp"; else :;fi &&
+
+# Now remove or move aside any old file at destination location.  We try this
+# two ways since rm can't unlink itself on some systems and the destination
+# file might be busy for other reasons.  In this case, the final cleanup
+# might fail but the new file should still install successfully.
+
+{
+	if [ -f "$dstdir/$dstfile" ]
+	then
+		$doit $rmcmd -f "$dstdir/$dstfile" 2>/dev/null ||
+		$doit $mvcmd -f "$dstdir/$dstfile" "$rmtmp" 2>/dev/null ||
+		{
+		  echo "$0: cannot unlink or rename $dstdir/$dstfile" >&2
+		  (exit 1); exit
+		}
+	else
+		:
+	fi
+} &&
+
+# Now rename the file to the real destination.
+
+	$doit $mvcmd "$dsttmp" "$dstdir/$dstfile"
+
+fi &&
+
+# The final little trick to "correctly" pass the exit status to the exit trap.
+
+{
+	(exit 0); exit
+}
diff --git a/intl/ChangeLog b/intl/ChangeLog
new file mode 100644
index 00000000..19895015
--- /dev/null
+++ b/intl/ChangeLog
@@ -0,0 +1,1086 @@
+1998-04-29  Ulrich Drepper  <drepper@cygnus.com>
+
+	* intl/localealias.c (read_alias_file): Use unsigned char for
+	local variables.  Remove unused variable tp.
+	* intl/l10nflist.c (_nl_normalize_codeset): Use unsigned char *
+	for type of codeset.  For loosing Solaris systems.
+	* intl/loadinfo.h: Adapt prototype of _nl_normalize_codeset.
+	* intl/bindtextdom.c (BINDTEXTDOMAIN): Don't define local variable
+	len if not needed.
+	Patches by Jim Meyering.
+
+1998-04-28  Ulrich Drepper  <drepper@cygnus.com>
+
+	* loadmsgcat.c (_nl_load_domain): Don't assign the element use_mmap if
+	mmap is not supported.
+
+	* hash-string.h: Don't include <values.h>.
+
+1998-04-27  Ulrich Drepper  <drepper@cygnus.com>
+
+	* textdomain.c: Use strdup is available.
+
+	* localealias.c: Define HAVE_MEMPCPY so that we can use this
+	function.  Define and use semapahores to protect modfication of
+	global objects when compiling for glibc.  Add code to allow
+	freeing alias table.
+
+	* l10nflist.c: Don't assume stpcpy not being a macro.
+
+	* gettextP.h: Define internal_function macri if not already done.
+	Use glibc byte-swap macros instead of defining SWAP when compiled
+	for glibc.
+	(struct loaded_domain): Add elements to allow unloading.
+
+	* Makefile.in (distclean): Don't remove libintl.h here.
+
+	* bindtextdomain.c: Carry over changes from glibc.  Use strdup if
+	available.
+
+	* dcgettext.c: Don't assume stpcpy not being a macro.  Mark internal
+	functions.  Add memory freeing code for glibc.
+
+	* dgettext.c: Update copyright.
+
+	* explodename.c: Include stdlib.h and string.h only if they exist.
+	Use strings.h eventually.
+
+	* finddomain.c: Mark internal functions.  Use strdup if available.
+	Add memory freeing code for glibc.
+
+1997-10-10 20:00  Ulrich Drepper  <drepper@cygnus.com>
+
+	* libgettext.h: Fix dummy textdomain and bindtextdomain macros.
+	They should return reasonable values.
+	Reported by Tom Tromey <tromey@cygnus.com>.
+
+1997-09-16 03:33  Ulrich Drepper  <drepper@cygnus.com>
+
+	* libgettext.h: Define PARAMS also to `args' if __cplusplus is defined.
+	* intlh.inst.in: Likewise.
+	Reported by Jean-Marc Lasgouttes <Jean-Marc.Lasgouttes@inria.fr>.
+
+	* libintl.glibc: Update from current glibc version.
+
+1997-09-06 02:10  Ulrich Drepper  <drepper@cygnus.com>
+
+	* intlh.inst.in: Reformat copyright.
+
+1997-08-19 15:22  Ulrich Drepper  <drepper@cygnus.com>
+
+	* dcgettext.c (DCGETTEXT): Remove wrong comment.
+
+1997-08-16 00:13  Ulrich Drepper  <drepper@cygnus.com>
+
+	* Makefile.in (install-data): Don't change directory to install.
+
+1997-08-01 14:30  Ulrich Drepper  <drepper@cygnus.com>
+
+	* cat-compat.c: Fix copyright.
+
+	* localealias.c: Don't define strchr unless !HAVE_STRCHR.
+
+	* loadmsgcat.c: Update copyright.  Fix typos.
+
+	* l10nflist.c: Don't define strchr unless !HAVE_STRCHR.
+	(_nl_make_l10nflist): Handle sponsor and revision correctly.
+
+	* gettext.c: Update copyright.
+	* gettext.h: Likewise.
+	* hash-string.h: Likewise.
+
+	* finddomain.c: Remoave dead code.  Define strchr only if
+	!HAVE_STRCHR.
+
+	* explodename.c: Include <sys/types.h>.
+
+	* explodename.c: Reformat copyright text.
+	(_nl_explode_name): Fix typo.
+
+	* dcgettext.c: Define and use __set_errno.
+	(guess_category_value): Don't use setlocale if HAVE_LC_MESSAGES is
+	not defined.
+
+	* bindtextdom.c: Pretty printing.
+
+1997-05-01 02:25  Ulrich Drepper  <drepper@cygnus.com>
+
+	* dcgettext.c (guess_category_value): Don't depend on
+	HAVE_LC_MESSAGES.  We don't need the macro here.
+	Patch by Bruno Haible <haible@ilog.fr>.
+
+	* cat-compat.c (textdomain): DoN't refer to HAVE_SETLOCALE_NULL
+	macro.  Instead use HAVE_LOCALE_NULL and define it when using
+	glibc, as in dcgettext.c.
+	Patch by Bruno Haible <haible@ilog.fr>.
+
+	* Makefile.in (CPPFLAGS): New variable.  Reported by Franc,ois
+	Pinard.
+
+Mon Mar 10 06:51:17 1997  Ulrich Drepper  <drepper@cygnus.com>
+
+	* Makefile.in: Implement handling of libtool.
+
+	* gettextP.h: Change data structures for use of generic lowlevel
+	i18n file handling.
+
+Wed Dec  4 20:21:18 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* textdomain.c: Put parentheses around arguments of memcpy macro
+	definition.
+	* localealias.c: Likewise.
+	* l10nflist.c: Likewise.
+	* finddomain.c: Likewise.
+	* bindtextdom.c: Likewise.
+	Reported by Thomas Esken.
+
+Mon Nov 25 22:57:51 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* textdomain.c: Move definition of `memcpy` macro to right
+	position.
+
+Fri Nov 22 04:01:58 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* finddomain.c [!HAVE_STRING_H && !_LIBC]: Define memcpy using
+ 	bcopy if not already defined.  Reported by Thomas Esken.
+	* bindtextdom.c: Likewise.
+	* l10nflist.c: Likewise.
+	* localealias.c: Likewise.
+	* textdomain.c: Likewise.
+
+Tue Oct 29 11:10:27 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* Makefile.in (libdir): Change to use exec_prefix instead of
+ 	prefix.  Reported by Knut-HåvardAksnes <etokna@eto.ericsson.se>.
+
+Sat Aug 31 03:07:09 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* l10nflist.c (_nl_normalize_codeset): We convert to lower case,
+	so don't prepend uppercase `ISO' for only numeric arg.
+
+Fri Jul 19 00:15:46 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* l10nflist.c: Move inclusion of argz.h, ctype.h, stdlib.h after
+	definition of _GNU_SOURCE.  Patch by Roland McGrath.
+
+	* Makefile.in (uninstall): Fix another bug with `for' loop and
+	empty arguments.  Patch by Jim Meyering.  Correct name os
+	uninstalled files: no intl- prefix anymore.
+
+	* Makefile.in (install-data): Again work around shells which
+	cannot handle mpty for list.  Reported by Jim Meyering.
+
+Sat Jul 13 18:11:35 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* Makefile.in (install): Split goal.  Now depend on install-exec
+        and install-data.
+	(install-exec, install-data): New goals.  Created from former
+	install goal.
+	Reported by Karl Berry.
+
+Sat Jun 22 04:58:14 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* Makefile.in (MKINSTALLDIRS): New variable.  Path to
+        mkinstalldirs script.
+	(install): use MKINSTALLDIRS variable or if the script is not present
+	try to find it in the $top_scrdir).
+
+Wed Jun 19 02:56:56 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* l10nflist.c: Linux libc *partly* includes the argz_* functions.
+	Grr.  Work around by renaming the static version and use macros
+	for renaming.
+
+Tue Jun 18 20:11:17 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* l10nflist.c: Correct presence test macros of __argz_* functions.
+
+	* l10nflist.c: Include <argz.h> based on test of it instead when
+	__argz_* functions are available.
+	Reported by Andreas Schwab.
+
+Thu Jun 13 15:17:44 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* explodename.c, l10nflist.c: Define NULL for dumb systems.
+
+Tue Jun 11 17:05:13 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* intlh.inst.in, libgettext.h (dcgettext): Rename local variable
+	result to __result to prevent name clash.
+
+	* l10nflist.c, localealias.c, dcgettext.c: Define _GNU_SOURCE to
+        get prototype for stpcpy and strcasecmp.
+
+	* intlh.inst.in, libgettext.h: Move declaration of
+	`_nl_msg_cat_cntr' outside __extension__ block to prevent warning
+	from gcc's -Wnested-extern option.
+
+Fri Jun  7 01:58:00 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* Makefile.in (install): Remove comment.
+
+Thu Jun  6 17:28:17 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* Makefile.in (install): Work around for another Buglix stupidity.
+	Always use an `else' close for `if's.  Reported by Nelson Beebe.
+
+	* Makefile.in (intlh.inst): Correct typo in phony rule.
+	Reported by Nelson Beebe.
+
+Thu Jun  6 01:49:52 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* dcgettext.c (read_alias_file): Rename variable alloca_list to
+	block_list as the macro calls assume.
+	Patch by Eric Backus.
+
+	* localealias.c [!HAVE_ALLOCA]: Define alloca as macro using
+        malloc.
+	(read_alias_file): Rename varriabe alloca_list to block_list as the
+	macro calls assume.
+	Patch by Eric Backus.
+
+	* l10nflist.c: Correct conditional for <argz.h> inclusion.
+	Reported by Roland McGrath.
+
+	* Makefile.in (all): Depend on all-@USE_INCLUDED_LIBINTL@, not
+        all-@USE_NLS@.
+
+	* Makefile.in (install): intlh.inst comes from local dir, not
+        $(srcdir).
+
+	* Makefile.in (intlh.inst): Special handling of this goal.  If
+	used in gettext, this is really a rul to construct this file.  If
+	used in any other package it is defined as a .PHONY rule with
+	empty body.
+
+	* finddomain.c: Extract locale file information handling into
+	l10nfile.c.  Rename local stpcpy__ function to stpcpy.
+
+	* dcgettext.c (stpcpy): Add local definition.
+
+	* l10nflist.c: Solve some portability problems.  Patches partly by
+	Thomas Esken.  Add local definition of stpcpy.
+
+Tue Jun  4 02:47:49 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* intlh.inst.in: Don't depend including <locale.h> on
+	HAVE_LOCALE_H.  Instead configure must rewrite this fiile
+	depending on the result of the configure run.
+
+	* Makefile.in (install): libintl.inst is now called intlh.inst.
+	Add rules for updating intlh.inst from intlh.inst.in.
+
+	* libintl.inst: Renamed to intlh.inst.in.
+
+	* localealias.c, dcgettext.c [__GNUC__]: Define HAVE_ALLOCA to 1
+        because gcc has __buitlin_alloca.
+	Reported by Roland McGrath.
+
+Mon Jun  3 00:32:16 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* Makefile.in (installcheck): New goal to fulfill needs of
+        automake's distcheck.
+
+	* Makefile.in (install): Reorder commands so that VERSION is
+        found.
+
+	* Makefile.in (gettextsrcdir): Now use subdirectory intl/ in
+        @datadir@/gettext.
+	(COMSRCS): Add l10nfile.c.
+	(OBJECTS): Add l10nfile.o.
+	(DISTFILES): Rename to DISTFILE.normal.  Remove $(DISTFILES.common).
+	(DISTFILE.gettext): Remove $(DISTFILES.common).
+	(all-gettext): Remove goal.
+	(install): If $(PACKAGE) = gettext install, otherwose do nothing.  No
+	package but gettext itself should install libintl.h + headers.
+	(dist): Extend goal to work for gettext, too.
+	(dist-gettext): Remove goal.
+
+	* dcgettext.c [!HAVE_ALLOCA]: Define macro alloca by using malloc.
+
+Sun Jun  2 17:33:06 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* loadmsgcat.c (_nl_load_domain): Parameter is now comes from
+        find_l10nfile.
+
+Sat Jun  1 02:23:03 1996  Ulrich Drepper  <drepper@cygnus.com>
+
+	* l10nflist.c (__argz_next): Add definition.
+
+	* dcgettext.c [!HAVE_ALLOCA]: Add code for handling missing alloca
+	code.  Use new l10nfile handling.
+
+	* localealias.c [!HAVE_ALLOCA]: Add code for handling missing
+        alloca code.
+
+	* l10nflist.c: Initial revision.
+
+Tue Apr  2 18:51:18 1996  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (all-gettext): New goal.  Same as all-yes.
+
+Thu Mar 28 23:01:22 1996  Karl Eichwalder  <ke@ke.central.de>
+
+	* Makefile.in (gettextsrcdir): Define using @datadir@.
+
+Tue Mar 26 12:39:14 1996  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c: Include <ctype.h>.  Reported by Roland McGrath.
+
+Sat Mar 23 02:00:35 1996  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c (stpcpy): Rename to stpcpy__ to prevent clashing
+        with external declaration.
+
+Sat Mar  2 00:47:09 1996  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (all-no): Rename from all_no.
+
+Sat Feb 17 00:25:59 1996  Ulrich Drepper  <drepper@myware>
+
+	* gettextP.h [loaded_domain]: Array `successor' must now contain up
+        to 63 elements (because of codeset name normalization).
+
+	* finddomain.c: Implement codeset name normalization.
+
+Thu Feb 15 04:39:09 1996  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (all): Define to `all-@USE_NLS@'.
+	(all-yes, all_no): New goals.  `all-no' is noop, `all-yes'
+	is former all.
+
+Mon Jan 15 21:46:01 1996  Howard Gayle  <howard@hal.com>
+
+	* localealias.c (alias_compare): Increment string pointers in loop
+        of strcasecmp replacement.
+
+Fri Dec 29 21:16:34 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (install-src): Who commented this goal out ? :-)
+
+Fri Dec 29 15:08:16 1995  Ulrich Drepper  <drepper@myware>
+
+	* dcgettext.c (DCGETTEXT): Save `errno'.  Failing system calls
+	should not effect it because a missing catalog is no error.
+	Reported by Harald K<o:>nig <koenig@tat.physik.uni-tuebingen.de>.
+
+Tue Dec 19 22:09:13 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (Makefile): Explicitly use $(SHELL) for running
+        shell scripts.
+
+Fri Dec 15 17:34:59 1995  Andreas Schwab  <schwab@issan.informatik.uni-dortmund.de>
+
+	* Makefile.in (install-src): Only install library and header when
+	we use the own implementation.  Don't do it when using the
+	system's gettext or catgets functions.
+
+	* dcgettext.c (find_msg): Must not swap domain->hash_size here.
+
+Sat Dec  9 16:24:37 1995  Ulrich Drepper  <drepper@myware>
+
+	* localealias.c, libintl.inst, libgettext.h, hash-string.h,
+	gettextP.h, finddomain.c, dcgettext.c, cat-compat.c:
+	Use PARAMS instead of __P.  Suggested by Roland McGrath.
+
+Tue Dec  5 11:39:14 1995  Larry Schwimmer  <rosebud@cyclone.stanford.edu>
+
+	* libgettext.h: Use `#if !defined (_LIBINTL_H)' instead of `#if
+	!_LIBINTL_H' because Solaris defines _LIBINTL_H as empty.
+
+Mon Dec  4 15:42:07 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (install-src):
+	Install libintl.inst instead of libintl.h.install.
+
+Sat Dec  2 22:51:38 1995  Marcus Daniels  <marcus@sysc.pdx.edu>
+
+	* cat-compat.c (textdomain):
+	Reverse order in which files are tried you load.  First
+	try local file, when this failed absolute path.
+
+Wed Nov 29 02:03:53 1995  Nelson H. F. Beebe  <beebe@math.utah.edu>
+
+	* cat-compat.c (bindtextdomain): Add missing { }.
+
+Sun Nov 26 18:21:41 1995  Ulrich Drepper  <drepper@myware>
+
+	* libintl.inst: Add missing __P definition.  Reported by Nelson Beebe.
+
+	* Makefile.in:
+	Add dummy `all' and `dvi' goals.  Reported by Tom Tromey.
+
+Sat Nov 25 16:12:01 1995  Franc,ois Pinard  <pinard@iro.umontreal.ca>
+
+	* hash-string.h: Capitalize arguments of macros.
+
+Sat Nov 25 12:01:36 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (DISTFILES): Prevent files names longer than 13
+	characters.  libintl.h.glibc->libintl.glibc,
+	libintl.h.install->libintl.inst.  Reported by Joshua R. Poulson.
+
+Sat Nov 25 11:31:12 1995  Eric Backus  <ericb@lsid.hp.com>
+
+	* dcgettext.c: Fix bug in preprocessor conditionals.
+
+Sat Nov 25 02:35:27 1995  Nelson H. F. Beebe  <beebe@math.utah.edu>
+
+	* libgettext.h: Solaris cc does not understand
+	 #if !SYMBOL1 && !SYMBOL2.  Sad	but true.
+
+Thu Nov 23 16:22:14 1995  Ulrich Drepper  <drepper@myware>
+
+	* hash-string.h (hash_string):
+	Fix for machine with >32 bit `unsigned long's.
+
+	* dcgettext.c (DCGETTEXT):
+	Fix horrible bug in loop for alternative translation.
+
+Thu Nov 23 01:45:29 1995  Ulrich Drepper  <drepper@myware>
+
+	* po2tbl.sed.in, linux-msg.sed, xopen-msg.sed:
+	Some further simplifications in message number generation.
+
+Mon Nov 20 21:08:43 1995  Ulrich Drepper  <drepper@myware>
+
+	* libintl.h.glibc: Use __const instead of const in prototypes.
+
+	* Makefile.in (install-src):
+	Install libintl.h.install instead of libintl.h.  This
+	is a stripped-down version.  Suggested by Peter Miller.
+
+	* libintl.h.install, libintl.h.glibc: Initial revision.
+
+	* localealias.c (_nl_expand_alias, read_alias_file):
+	Protect prototypes in type casts by __P.
+
+Tue Nov 14 16:43:58 1995  Ulrich Drepper  <drepper@myware>
+
+	* hash-string.h: Correct prototype for hash_string.
+
+Sun Nov 12 12:42:30 1995  Ulrich Drepper  <drepper@myware>
+
+	* hash-string.h (hash_string): Add prototype.
+
+	* gettextP.h: Fix copyright.
+	(SWAP): Add prototype.
+
+Wed Nov  8 22:56:33 1995  Ulrich Drepper  <drepper@myware>
+
+	* localealias.c (read_alias_file): Forgot sizeof.
+	Avoid calling *printf function.  This introduces a big overhead.
+	Patch by Roland McGrath.
+
+Tue Nov  7 14:21:08 1995  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c, cat-compat.c: Wrong indentation in #if for stpcpy.
+
+	* finddomain.c (stpcpy):
+	Define substitution function local.  The macro was to flaky.
+
+	* cat-compat.c: Fix typo.
+
+	* xopen-msg.sed, linux-msg.sed:
+	While bringing message number to right place only accept digits.
+
+	* linux-msg.sed, xopen-msg.sed: Now that the counter does not have
+	leading 0s we don't need to remove them.  Reported by Marcus
+	Daniels.
+
+	* Makefile.in (../po/cat-id-tbl.o): Use $(top_srdir) in
+	dependency.  Reported by Marcus Daniels.
+
+	* cat-compat.c: (stpcpy) [!_LIBC && !HAVE_STPCPY]: Define replacement.
+	Generally cleanup using #if instead of #ifndef.
+
+	* Makefile.in: Correct typos in comment.  By Franc,ois Pinard.
+
+Mon Nov  6 00:27:02 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (install-src): Don't install libintl.h and libintl.a
+	if we use an available gettext implementation.
+
+Sun Nov  5 22:02:08 1995  Ulrich Drepper  <drepper@myware>
+
+	* libgettext.h: Fix typo: HAVE_CATGETTS -> HAVE_CATGETS.  Reported
+	by Franc,ois Pinard.
+
+	* libgettext.h: Use #if instead of #ifdef/#ifndef.
+
+	* finddomain.c:
+	Comments describing what has to be done should start with FIXME.
+
+Sun Nov  5 19:38:01 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (DISTFILES): Split.  Use DISTFILES with normal meaning.
+	DISTFILES.common names the files common to both dist goals.
+	DISTFILES.gettext are the files only distributed in GNU gettext.
+
+Sun Nov  5 17:32:54 1995  Ulrich Drepper  <drepper@myware>
+
+	* dcgettext.c (DCGETTEXT): Correct searching in derived locales.
+	This was necessary since a change in _nl_find_msg several weeks
+	ago.  I really don't know this is still not fixed.
+
+Sun Nov  5 12:43:12 1995  Ulrich Drepper  <drepper@myware>
+
+	* loadmsgcat.c (_nl_load_domain): Test for FILENAME == NULL.  This
+	might mark a special condition.
+
+	* finddomain.c (make_entry_rec): Don't make illegal entry as decided.
+
+	* Makefile.in (dist): Suppress error message when ln failed.
+	Get files from $(srcdir) explicitly.
+
+	* libgettext.h (gettext_const): Rename to gettext_noop.
+
+Fri Nov  3 07:36:50 1995  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c (make_entry_rec):
+	Protect against wrong locale names by testing mask.
+
+	* libgettext.h (gettext_const): Add macro definition.
+	Capitalize macro arguments.
+
+Thu Nov  2 23:15:51 1995  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c (_nl_find_domain):
+	Test for pointer != NULL before accessing value.
+	Reported by Tom Tromey.
+
+	* gettext.c (NULL):
+	Define as (void*)0 instad of 0.  Reported by Franc,ois Pinard.
+
+Mon Oct 30 21:28:52 1995  Ulrich Drepper  <drepper@myware>
+
+	* po2tbl.sed.in: Serious typo bug fixed by Jim Meyering.
+
+Sat Oct 28 23:20:47 1995  Ulrich Drepper  <drepper@myware>
+
+	* libgettext.h: Disable dcgettext optimization for Solaris 2.3.
+
+	* localealias.c (alias_compare):
+	Peter Miller reported that tolower in some systems is
+	even dumber than I thought.  Protect call by `isupper'.
+
+Fri Oct 27 22:22:51 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (libdir, includedir): New variables.
+	(install-src): Install libintl.a and libintl.h in correct dirs.
+
+Fri Oct 27 22:07:29 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (SOURCES): Fix typo: intrl.compat.c -> intl-compat.c.
+
+	* po2tbl.sed.in: Patch for buggy SEDs by Christian von Roques.
+
+	* localealias.c:
+	Fix typo and superflous test.  Reported by Christian von Roques.
+
+Fri Oct  6 11:52:05 1995  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c (_nl_find_domain):
+	Correct some remainder from the pre-CEN syntax.  Now
+	we don't have a constant number of successors anymore.
+
+Wed Sep 27 21:41:13 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (DISTFILES): Add libintl.h.glibc.
+
+	* Makefile.in (dist-libc): Add goal for packing sources for glibc.
+	(COMSRCS, COMHDRS): Splitted to separate sources shared with glibc.
+
+	* loadmsgcat.c: Forget to continue #if line.
+
+	* localealias.c:
+	[_LIBC]: Rename strcasecmp to __strcasecmp to keep ANSI C name
+	space clean.
+
+	* dcgettext.c, finddomain.c: Better comment to last change.
+
+	* loadmsgcat.c:
+	[_LIBC]: Rename fstat, open, close, read, mmap, and munmap to
+	__fstat, __open, __close, __read, __mmap, and __munmap resp
+	to keep ANSI C name space clean.
+
+	* finddomain.c:
+	[_LIBC]: Rename stpcpy to __stpcpy to keep ANSI C name space clean.
+
+	* dcgettext.c:
+	[_LIBC]: Rename getced and stpcpy to __getcwd and __stpcpy resp to
+	keep ANSI C name space clean.
+
+	* libgettext.h:
+	Include sys/types.h for those old SysV systems out there.
+	Reported by Francesco Potorti`.
+
+	* loadmsgcat.c (use_mmap): Define if compiled for glibc.
+
+	* bindtextdom.c: Include all those standard headers
+	unconditionally if _LIBC is defined.
+
+	* finddomain.c: Fix 2 times defiend -> defined.
+
+	* textdomain.c: Include libintl.h instead of libgettext.h when
+	compiling for glibc.  Include all those standard headers
+	unconditionally if _LIBC is defined.
+
+	* localealias.c, loadmsgcat.c: Prepare to be compiled in glibc.
+
+	* gettext.c:
+	Include libintl.h instead of libgettext.h when compiling for glibc.
+	Get NULL from stddef.h if we compile for glibc.
+
+	* finddomain.c: Include libintl.h instead of libgettext.h when
+	compiling for glibc.  Include all those standard headers
+	unconditionally if _LIBC is defined.
+
+	* dcgettext.c: Include all those standard headers unconditionally
+	if _LIBC is defined.
+
+	* dgettext.c: If compiled in glibc include libintl.h instead of
+	libgettext.h.
+	(locale.h): Don't rely on HAVE_LOCALE_H when compiling for glibc.
+
+	* dcgettext.c: If compiled in glibc include libintl.h instead of
+	libgettext.h.
+	(getcwd): Don't rely on HAVE_GETCWD when compiling for glibc.
+
+	* bindtextdom.c:
+	If compiled in glibc include libintl.h instead of libgettext.h.
+
+Mon Sep 25 22:23:06 1995  Ulrich Drepper  <drepper@myware>
+
+	* localealias.c (_nl_expand_alias): Don't call bsearch if NMAP <= 0.
+	Reported by Marcus Daniels.
+
+	* cat-compat.c (bindtextdomain):
+	String used in putenv must not be recycled.
+	Reported by Marcus Daniels.
+
+	* libgettext.h (__USE_GNU_GETTEXT):
+	Additional symbol to signal that we use GNU gettext
+	library.
+
+	* cat-compat.c (bindtextdomain):
+	Fix bug with the strange stpcpy replacement.
+	Reported by Nelson Beebe.
+
+Sat Sep 23 08:23:51 1995  Ulrich Drepper  <drepper@myware>
+
+	* cat-compat.c: Include <string.h> for stpcpy prototype.
+
+	* localealias.c (read_alias_file):
+	While expand strdup code temporary variable `cp' hided
+	higher level variable with same name.  Rename to `tp'.
+
+	* textdomain.c (textdomain):
+	Avoid warning by using temporary variable in strdup code.
+
+	* finddomain.c (_nl_find_domain): Remove unused variable `application'.
+
+Thu Sep 21 15:51:44 1995  Ulrich Drepper  <drepper@myware>
+
+	* localealias.c (alias_compare):
+	Use strcasecmp() only if available.  Else use
+	implementation in place.
+
+	* intl-compat.c:
+	Wrapper functions now call *__ functions instead of __*.
+
+	* libgettext.h: Declare prototypes for *__ functions instead for __*.
+
+	* cat-compat.c, loadmsgcat.c:
+	Don't use xmalloc, xstrdup, and stpcpy.  These functions are not part
+	of the standard libc and so prevent libintl.a from being used
+	standalone.
+
+	* bindtextdom.c:
+	Don't use xmalloc, xstrdup, and stpcpy.  These functions are not part
+	of the standard libc and so prevent libintl.a from being used
+	standalone.
+	Rename to bindtextdomain__ if not used in GNU C Library.
+
+	* dgettext.c:
+	Rename function to dgettext__ if not used in GNU C Library.
+
+	* gettext.c:
+	Don't use xmalloc, xstrdup, and stpcpy.  These functions are not part
+	of the standard libc and so prevent libintl.a from being used
+	standalone.
+	Functions now called gettext__ if not used in GNU C Library.
+
+	* dcgettext.c, localealias.c, textdomain.c, finddomain.c:
+	Don't use xmalloc, xstrdup, and stpcpy.  These functions are not part
+	of the standard libc and so prevent libintl.a from being used
+	standalone.
+
+Sun Sep 17 23:14:49 1995  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c: Correct some bugs in handling of CEN standard
+ 	locale definitions.
+
+Thu Sep  7 01:49:28 1995  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c: Implement CEN syntax.
+
+	* gettextP.h (loaded_domain): Extend number of successors to 31.
+
+Sat Aug 19 19:25:29 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (aliaspath): Remove path to X11 locale dir.
+
+	* Makefile.in: Make install-src depend on install.  This helps
+ 	gettext to install the sources and other packages can use the
+ 	install goal.
+
+Sat Aug 19 15:19:33 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (uninstall): Remove stuff installed by install-src.
+
+Tue Aug 15 13:13:53 1995  Ulrich Drepper  <drepper@myware>
+
+	* VERSION.in: Initial revision.
+
+	* Makefile.in (DISTFILES):
+	Add VERSION file.  This is not necessary for gettext, but
+	for other packages using this library.
+
+Tue Aug 15 06:16:44 1995  Ulrich Drepper  <drepper@myware>
+
+	* gettextP.h (_nl_find_domain):
+	New prototype after changing search strategy.
+
+	* finddomain.c (_nl_find_domain):
+	We now try only to find a specified catalog.  Fall back to other
+	catalogs listed in the locale list is now done in __dcgettext.
+
+	* dcgettext.c (__dcgettext):
+	Now we provide message fall back even to different languages.
+	I.e. if a message is not available in one language all the other
+ 	in the locale list a tried.  Formerly fall back was only possible
+ 	within one language.  Implemented by moving one loop from
+ 	_nl_find_domain to here.
+
+Mon Aug 14 23:45:50 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (gettextsrcdir):
+	Directory where source of GNU gettext library are made
+	available.
+	(INSTALL, INSTALL_DATA): Programs used for installing sources.
+	(gettext-src): New.  Rule to install GNU gettext sources for use in
+	gettextize shell script.
+
+Sun Aug 13 14:40:48 1995  Ulrich Drepper  <drepper@myware>
+
+	* loadmsgcat.c (_nl_load_domain):
+	Use mmap for loading only when munmap function is
+	also available.
+
+	* Makefile.in (install): Depend on `all' goal.
+
+Wed Aug  9 11:04:33 1995  Ulrich Drepper  <drepper@myware>
+
+	* localealias.c (read_alias_file):
+	Do not overwrite '\n' when terminating alias value string.
+
+	* localealias.c (read_alias_file):
+	Handle long lines.  Ignore the rest not fitting in
+	the buffer after the initial `fgets' call.
+
+Wed Aug  9 00:54:29 1995  Ulrich Drepper  <drepper@myware>
+
+	* gettextP.h (_nl_load_domain):
+	Add prototype, replacing prototype for _nl_load_msg_cat.
+
+	* finddomain.c (_nl_find_domain):
+	Remove unneeded variable filename and filename_len.
+	(expand_alias): Remove prototype because functions does not
+ 	exist anymore.
+
+	* localealias.c (read_alias_file):
+	Change type of fname_len parameter to int.
+	(xmalloc): Add prototype.
+
+	* loadmsgcat.c: Better prototypes for xmalloc.
+
+Tue Aug  8 22:30:39 1995  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c (_nl_find_domain):
+	Allow alias name to be constructed from the four components.
+
+	* Makefile.in (aliaspath): New variable.  Set to preliminary value.
+	(SOURCES): Add localealias.c.
+	(OBJECTS): Add localealias.o.
+
+	* gettextP.h: Add prototype for _nl_expand_alias.
+
+	* finddomain.c: Aliasing handled in intl/localealias.c.
+
+	* localealias.c: Aliasing for locale names.
+
+	* bindtextdom.c: Better prototypes for xmalloc and xstrdup.
+
+Mon Aug  7 23:47:42 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (DISTFILES): gettext.perl is now found in misc/.
+
+	* cat-compat.c (bindtextdomain):
+	Correct implementation.  dirname parameter was not used.
+	Reported by Marcus Daniels.
+
+	* gettextP.h (loaded_domain):
+	New fields `successor' and `decided' for oo, lazy
+	message handling implementation.
+
+	* dcgettext.c:
+	Adopt for oo, lazy message handliing.
+  	Now we can inherit translations from less specific locales.
+	(find_msg): New function.
+
+	* loadmsgcat.c, finddomain.c:
+	Complete rewrite.  Implement oo, lazy message handling :-).
+  	We now have an additional environment variable `LANGUAGE' with
+ 	a higher priority than LC_ALL for the LC_MESSAGE locale.
+  	Here we can set a colon separated list of specifications each
+ 	of the form `language[_territory[.codeset]][@modifier]'.
+
+Sat Aug  5 09:55:42 1995  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c (unistd.h):
+	Include to get _PC_PATH_MAX defined on system having it.
+
+Fri Aug  4 22:42:00 1995  Ulrich Drepper  <drepper@myware>
+
+	* finddomain.c (stpcpy): Include prototype.
+
+	* Makefile.in (dist): Remove `copying instead' message.
+
+Wed Aug  2 18:52:03 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (ID, TAGS): Do not use $^.
+
+Tue Aug  1 20:07:11 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (TAGS, ID): Use $^ as command argument.
+	(TAGS): Give etags -o option t write to current directory,
+ 	not $(srcdir).
+	(ID): Use $(srcdir) instead os $(top_srcdir)/src.
+	(distclean): Remove ID.
+
+Sun Jul 30 11:51:46 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (gnulocaledir):
+	New variable, always using share/ for data directory.
+	(DEFS): Add GNULOCALEDIR, used in finddomain.c.
+
+	* finddomain.c (_nl_default_dirname):
+	Set to GNULOCALEDIR, because it always has to point
+	to the directory where GNU gettext Library writes it to.
+
+	* intl-compat.c (textdomain, bindtextdomain):
+	Undefine macros before function definition.
+
+Sat Jul 22 01:10:02 1995  Ulrich Drepper  <drepper@myware>
+
+	* libgettext.h (_LIBINTL_H):
+	Protect definition in case where this file is included as
+	libgettext.h on Solaris machines.  Add comment about this.
+
+Wed Jul 19 02:36:42 1995  Ulrich Drepper  <drepper@myware>
+
+	* intl-compat.c (textdomain): Correct typo.
+
+Wed Jul 19 01:51:35 1995  Ulrich Drepper  <drepper@myware>
+
+	* dcgettext.c (dcgettext): Function now called __dcgettext.
+
+	* dgettext.c (dgettext): Now called __dgettext and calls
+ 	__dcgettext.
+
+	* gettext.c (gettext):
+	Function now called __gettext and calls __dgettext.
+
+	* textdomain.c (textdomain): Function now called __textdomain.
+
+	* bindtextdom.c (bindtextdomain): Function now called
+ 	__bindtextdomain.
+
+	* intl-compat.c: Initial revision.
+
+	* Makefile.in (SOURCES): Add intl-compat.c.
+	(OBJECTS): We always compile the GNU gettext library functions.
+  	OBJECTS contains all objects but cat-compat.o, ../po/cat-if-tbl.o,
+ 	and intl-compat.o.
+  	(GETTOBJS): Contains now only intl-compat.o.
+
+	* libgettext.h:
+	Re-include protection matches dualistic character of libgettext.h.
+	For all functions in GNU gettext library define __ counter part.
+
+	* finddomain.c (strchr): Define as index if not found in C library.
+	(_nl_find_domain): For relative paths paste / in between.
+
+Tue Jul 18 16:37:45 1995  Ulrich Drepper  <drepper@myware>
+
+	* loadmsgcat.c, finddomain.c: Add inclusion of sys/types.h.
+
+	* xopen-msg.sed: Fix bug with `msgstr ""' lines.
+	A little bit better comments.
+
+Tue Jul 18 01:18:27 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in:
+	po-mode.el, makelinks, combine-sh are now found in ../misc.
+
+	* po-mode.el, makelinks, combine-sh, elisp-comp:
+	Moved to ../misc/.
+
+	* libgettext.h, gettextP.h, gettext.h: Uniform test for __STDC__.
+
+Sun Jul 16 22:33:02 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (INSTALL, INSTALL_DATA): New variables.
+	(install-data, uninstall): Install/uninstall .elc file.
+
+	* po-mode.el (Installation comment):
+	Add .pox as possible extension of .po files.
+
+Sun Jul 16 13:23:27 1995  Ulrich Drepper  <drepper@myware>
+
+	* elisp-comp: Complete new version by Franc,ois: This does not
+ 	fail when not compiling in the source directory.
+
+Sun Jul 16 00:12:17 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (../po/cat-id-tbl.o):
+	Use $(MAKE) instead of make for recursive make.
+
+	* Makefile.in (.el.elc): Use $(SHELL) instead of /bin/sh.
+	(install-exec): Add missing dummy goal.
+	(install-data, uninstall): @ in multi-line shell command at
+ 	beginning, not in front of echo.  Reported by Eric Backus.
+
+Sat Jul 15 00:21:28 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (DISTFILES):
+	Rename libgettext.perl to gettext.perl to fit in 14 chars
+	file systems.
+
+	* gettext.perl:
+ 	Rename to gettext.perl to fit in 14 chars file systems.
+
+Thu Jul 13 23:17:20 1995  Ulrich Drepper  <drepper@myware>
+
+	* cat-compat.c: If !STDC_HEADERS try to include malloc.h.
+
+Thu Jul 13 20:55:02 1995  Ulrich Drepper  <drepper@myware>
+
+	* po2tbl.sed.in: Pretty printing.
+
+	* linux-msg.sed, xopen-msg.sed:
+	Correct bugs with handling substitute flags in branches.
+
+	* hash-string.h (hash_string):
+	Old K&R compilers don't under stand `unsigned char'.
+
+	* gettext.h (nls_uint32):
+	Some old K&R compilers (eg HP) don't understand `unsigned int'.
+
+	* cat-compat.c (msg_to_cat_id): De-ANSI-fy prototypes.
+
+Thu Jul 13 01:34:33 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (ELCFILES): New variable.
+	(DISTFILES): Add elisp-comp.
+	Add implicit rule for .el -> .elc compilation.
+	(install-data): install $ELCFILES
+	(clean): renamed po-to-tbl and po-to-msg to po2tbl and po2msg resp.
+
+	* elisp-comp: Initial revision
+
+Wed Jul 12 16:14:52 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in:
+	cat-id-tbl.c is now found in po/.  This enables us to use an identical
+	intl/ directory in all packages.
+
+	* dcgettext.c (dcgettext): hashing does not work for table size <= 2.
+
+	* textdomain.c: fix typo (#if def -> #if defined)
+
+Tue Jul 11 18:44:43 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in (stamp-cat-id): use top_srcdir to address source files
+	(DISTFILES,distclean): move tupdate.perl to src/
+
+	* po-to-tbl.sed.in:
+	add additional jump to clear change flag to recognize multiline strings
+
+Tue Jul 11 01:32:50 1995  Ulrich Drepper  <drepper@myware>
+
+	* textdomain.c: Protect inclusion of stdlib.h and string.h.
+
+	* loadmsgcat.c: Protect inclusion of stdlib.h.
+
+	* libgettext.h: Protect inclusion of locale.h.
+	Allow use in C++ programs.
+	Define NULL is not happened already.
+
+	* Makefile.in (DISTFILES): ship po-to-tbl.sed.in instead of
+	po-to-tbl.sed.
+	(distclean): remove po-to-tbl.sed and tupdate.perl.
+
+	* tupdate.perl.in: Substitute Perl path even in exec line.
+	Don't include entries without translation from old .po file.
+
+Tue Jul  4 00:41:51 1995  Ulrich Drepper  <drepper@myware>
+
+	* tupdate.perl.in: use "Updated: " in msgid "".
+
+	* cat-compat.c: Fix typo (LOCALDIR -> LOCALEDIR).
+ 	Define getenv if !__STDC__.
+
+	* bindtextdom.c: Protect stdlib.h and string.h inclusion.
+ 	Define free if !__STDC__.
+
+	* finddomain.c: Change DEF_MSG_DOM_DIR to LOCALEDIR.
+ 	Define free if !__STDC__.
+
+	* cat-compat.c: Change DEF_MSG_DOM_DIR to LOCALEDIR.
+
+Mon Jul  3 23:56:30 1995  Ulrich Drepper  <drepper@myware>
+
+	* Makefile.in: Use LOCALEDIR instead of DEF_MSG_DOM_DIR.
+	Remove unneeded $(srcdir) from Makefile.in dependency.
+
+	* makelinks: Add copyright and short description.
+
+	* po-mode.el: Last version for 0.7.
+
+	* tupdate.perl.in: Fix die message.
+
+	* dcgettext.c: Protect include of string.h.
+
+	* gettext.c: Protect include of stdlib.h and further tries to get NULL.
+
+	* finddomain.c: Some corrections in includes.
+
+	* Makefile.in (INCLUDES): Prune list correct path to Makefile.in.
+
+	* po-to-tbl.sed: Adopt for new .po file format.
+
+	* linux-msg.sed, xopen-msg.sed: Adopt for new .po file format.
+
+Sun Jul  2 23:55:03 1995  Ulrich Drepper  <drepper@myware>
+
+	* tupdate.perl.in: Complete rewrite for new .po file format.
+
+Sun Jul  2 02:06:50 1995  Ulrich Drepper  <drepper@myware>
+
+	* First official release.  This directory contains all the code
+	needed to internationalize own packages.  It provides functions
+	which allow to use the X/Open catgets function with an interface
+	like the Uniforum gettext function.  For system which does not
+	have neither of those a complete implementation is provided.
diff --git a/intl/Makefile.in b/intl/Makefile.in
new file mode 100644
index 00000000..3f14c13c
--- /dev/null
+++ b/intl/Makefile.in
@@ -0,0 +1,216 @@
+# Makefile for directory with message catalog handling in GNU NLS Utilities.
+# Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+PACKAGE = @PACKAGE@
+VERSION = @VERSION@
+
+SHELL = /bin/sh
+
+srcdir = @srcdir@
+top_srcdir = @top_srcdir@
+top_builddir = ..
+VPATH = @srcdir@
+
+prefix = @prefix@
+exec_prefix = @exec_prefix@
+transform = @program_transform_name@
+libdir = $(exec_prefix)/lib
+includedir = $(prefix)/include
+datadir = $(prefix)/@DATADIRNAME@
+localedir = $(datadir)/locale
+gnulocaledir = $(prefix)/share/locale
+gettextsrcdir = $(datadir)/gettext/intl
+aliaspath = $(localedir):.
+subdir = intl
+
+DESTDIR =
+
+INSTALL = @INSTALL@
+INSTALL_DATA = @INSTALL_DATA@
+MKINSTALLDIRS = @MKINSTALLDIRS@
+
+l = @l@
+
+AR = ar
+CC = @CC@
+LIBTOOL = @LIBTOOL@
+RANLIB = @RANLIB@
+
+DEFS = -DLOCALEDIR=\"$(localedir)\" -DGNULOCALEDIR=\"$(gnulocaledir)\" \
+-DLOCALE_ALIAS_PATH=\"$(aliaspath)\" @DEFS@
+CPPFLAGS = @CPPFLAGS@
+CFLAGS = @CFLAGS@
+LDFLAGS = @LDFLAGS@
+
+COMPILE = $(CC) -c $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(XCFLAGS)
+
+HEADERS = $(COMHDRS) libgettext.h loadinfo.h
+COMHDRS = gettext.h gettextP.h hash-string.h
+SOURCES = $(COMSRCS) intl-compat.c cat-compat.c
+COMSRCS = bindtextdom.c dcgettext.c dgettext.c gettext.c \
+finddomain.c loadmsgcat.c localealias.c textdomain.c l10nflist.c \
+explodename.c
+OBJECTS = @INTLOBJS@ bindtextdom.$lo dcgettext.$lo dgettext.$lo gettext.$lo \
+finddomain.$lo loadmsgcat.$lo localealias.$lo textdomain.$lo l10nflist.$lo \
+explodename.$lo
+CATOBJS = cat-compat.$lo ../po/cat-id-tbl.$lo
+GETTOBJS = intl-compat.$lo
+DISTFILES.common = ChangeLog Makefile.in linux-msg.sed po2tbl.sed.in \
+xopen-msg.sed $(HEADERS) $(SOURCES)
+DISTFILES.normal = VERSION
+DISTFILES.gettext = libintl.glibc intlh.inst.in
+
+.SUFFIXES:
+.SUFFIXES: .c .o .lo
+.c.o:
+	$(COMPILE) $<
+.c.lo:
+	$(LIBTOOL) --mode=compile $(COMPILE) $<
+
+INCLUDES = -I.. -I. -I$(top_srcdir)/intl -I$(top_srcdir)/lib
+
+all: all-@USE_INCLUDED_LIBINTL@
+
+all-yes: libintl.$la intlh.inst
+all-no:
+
+libintl.a: $(OBJECTS)
+	rm -f $@
+	$(AR) cru $@ $(OBJECTS)
+	$(RANLIB) $@
+
+libintl.la: $(OBJECTS)
+	$(LIBTOOL) --mode=link $(CC) $(LDFLAGS) -o $@ $(OBJECTS) \
+		   -version-info 1:0 -rpath $(libdir)
+
+../po/cat-id-tbl.$lo: ../po/cat-id-tbl.c $(top_srcdir)/po/$(PACKAGE).pot
+	cd ../po && $(MAKE) cat-id-tbl.$lo
+
+check: all
+
+# This installation goal is only used in GNU gettext.  Packages which
+# only use the library should use install instead.
+
+# We must not install the libintl.h/libintl.a files if we are on a
+# system which has the gettext() function in its C library or in a
+# separate library or use the catgets interface.  A special case is
+# where configure found a previously installed GNU gettext library.
+# If you want to use the one which comes with this version of the
+# package, you have to use `configure --with-included-gettext'.
+install: install-exec install-data
+install-exec: all
+	if test "$(PACKAGE)" = "gettext" \
+	   && test '@INTLOBJS@' = '$(GETTOBJS)'; then \
+	  if test -r $(MKINSTALLDIRS); then \
+	    $(MKINSTALLDIRS) $(DESTDIR)$(libdir) $(DESTDIR)$(includedir); \
+	  else \
+	    $(top_srcdir)/mkinstalldirs $(DESTDIR)$(libdir) $(DESTDIR)$(includedir); \
+	  fi; \
+	  $(INSTALL_DATA) intlh.inst $(DESTDIR)$(includedir)/libintl.h; \
+	  $(INSTALL_DATA) libintl.a $(DESTDIR)$(libdir)/libintl.a; \
+	else \
+	  : ; \
+	fi
+install-data: all
+	if test "$(PACKAGE)" = "gettext"; then \
+	  if test -r $(MKINSTALLDIRS); then \
+	    $(MKINSTALLDIRS) $(DESTDIR)$(gettextsrcdir); \
+	  else \
+	    $(top_srcdir)/mkinstalldirs $(DESTDIR)$(gettextsrcdir); \
+	  fi; \
+	  $(INSTALL_DATA) VERSION $(DESTDIR)$(gettextsrcdir)/VERSION; \
+	  dists="$(DISTFILES.common)"; \
+	  for file in $$dists; do \
+	    $(INSTALL_DATA) $(srcdir)/$$file $(DESTDIR)$(gettextsrcdir)/$$file; \
+	  done; \
+	else \
+	  : ; \
+	fi
+
+# Define this as empty until I found a useful application.
+installcheck:
+
+uninstall:
+	dists="$(DISTFILES.common)"; \
+	for file in $$dists; do \
+	  rm -f $(DESTDIR)$(gettextsrcdir)/$$file; \
+	done
+
+info dvi:
+
+$(OBJECTS): ../config.h libgettext.h
+bindtextdom.$lo finddomain.$lo loadmsgcat.$lo: gettextP.h gettext.h loadinfo.h
+dcgettext.$lo: gettextP.h gettext.h hash-string.h loadinfo.h
+
+tags: TAGS
+
+TAGS: $(HEADERS) $(SOURCES)
+	here=`pwd`; cd $(srcdir) && etags -o $$here/TAGS $(HEADERS) $(SOURCES)
+
+id: ID
+
+ID: $(HEADERS) $(SOURCES)
+	here=`pwd`; cd $(srcdir) && mkid -f$$here/ID $(HEADERS) $(SOURCES)
+
+
+mostlyclean:
+	rm -f *.a *.o *.lo core core.*
+
+clean: mostlyclean
+
+distclean: clean
+	rm -f Makefile ID TAGS po2msg.sed po2tbl.sed
+
+maintainer-clean: distclean
+	@echo "This command is intended for maintainers to use;"
+	@echo "it deletes files that may require special tools to rebuild."
+
+
+# GNU gettext needs not contain the file `VERSION' but contains some
+# other files which should not be distributed in other packages.
+distdir = ../$(PACKAGE)-$(VERSION)/$(subdir)
+dist distdir: Makefile $(DISTFILES)
+	if test "$(PACKAGE)" = gettext; then \
+	  additional="$(DISTFILES.gettext)"; \
+	else \
+	  additional="$(DISTFILES.normal)"; \
+	fi; \
+	for file in $(DISTFILES.common) $$additional; do \
+	  ln $(srcdir)/$$file $(distdir) 2> /dev/null \
+	    || cp -p $(srcdir)/$$file $(distdir); \
+	done
+
+dist-libc:
+	tar zcvf intl-glibc.tar.gz $(COMSRCS) $(COMHDRS) libintl.h.glibc
+
+Makefile: Makefile.in ../config.status
+	cd .. \
+	  && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
+
+# The dependency for intlh.inst is different in gettext and all other
+# packages.  Because we cannot you GNU make features we have to solve
+# the problem while rewriting Makefile.in.
+@GT_YES@intlh.inst: intlh.inst.in ../config.status
+@GT_YES@	cd .. \
+@GT_YES@	&& CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= \
+@GT_YES@	  $(SHELL) ./config.status
+@GT_NO@.PHONY: intlh.inst
+@GT_NO@intlh.inst:
+
+# Tell versions [3.59,3.63) of GNU make not to export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
diff --git a/intl/VERSION b/intl/VERSION
new file mode 100644
index 00000000..ee66b061
--- /dev/null
+++ b/intl/VERSION
@@ -0,0 +1 @@
+GNU gettext library from gettext-0.10.35
diff --git a/intl/bindtextdom.c b/intl/bindtextdom.c
new file mode 100644
index 00000000..d9c3f349
--- /dev/null
+++ b/intl/bindtextdom.c
@@ -0,0 +1,203 @@
+/* Implementation of the bindtextdomain(3) function
+   Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#if defined STDC_HEADERS || defined _LIBC
+# include <stdlib.h>
+#else
+# ifdef HAVE_MALLOC_H
+#  include <malloc.h>
+# else
+void free ();
+# endif
+#endif
+
+#if defined HAVE_STRING_H || defined _LIBC
+# include <string.h>
+#else
+# include <strings.h>
+# ifndef memcpy
+#  define memcpy(Dst, Src, Num) bcopy (Src, Dst, Num)
+# endif
+#endif
+
+#ifdef _LIBC
+# include <libintl.h>
+#else
+# include "libgettext.h"
+#endif
+#include "gettext.h"
+#include "gettextP.h"
+
+/* @@ end of prolog @@ */
+
+/* Contains the default location of the message catalogs.  */
+extern const char _nl_default_dirname[];
+
+/* List with bindings of specific domains.  */
+extern struct binding *_nl_domain_bindings;
+
+
+/* Names for the libintl functions are a problem.  They must not clash
+   with existing names and they should follow ANSI C.  But this source
+   code is also used in GNU C Library where the names have a __
+   prefix.  So we have to make a difference here.  */
+#ifdef _LIBC
+# define BINDTEXTDOMAIN __bindtextdomain
+# ifndef strdup
+#  define strdup(str) __strdup (str)
+# endif
+#else
+# define BINDTEXTDOMAIN bindtextdomain__
+#endif
+
+/* Specify that the DOMAINNAME message catalog will be found
+   in DIRNAME rather than in the system locale data base.  */
+char *
+BINDTEXTDOMAIN (domainname, dirname)
+     const char *domainname;
+     const char *dirname;
+{
+  struct binding *binding;
+
+  /* Some sanity checks.  */
+  if (domainname == NULL || domainname[0] == '\0')
+    return NULL;
+
+  for (binding = _nl_domain_bindings; binding != NULL; binding = binding->next)
+    {
+      int compare = strcmp (domainname, binding->domainname);
+      if (compare == 0)
+	/* We found it!  */
+	break;
+      if (compare < 0)
+	{
+	  /* It is not in the list.  */
+	  binding = NULL;
+	  break;
+	}
+    }
+
+  if (dirname == NULL)
+    /* The current binding has be to returned.  */
+    return binding == NULL ? (char *) _nl_default_dirname : binding->dirname;
+
+  if (binding != NULL)
+    {
+      /* The domain is already bound.  If the new value and the old
+	 one are equal we simply do nothing.  Otherwise replace the
+	 old binding.  */
+      if (strcmp (dirname, binding->dirname) != 0)
+	{
+	  char *new_dirname;
+
+	  if (strcmp (dirname, _nl_default_dirname) == 0)
+	    new_dirname = (char *) _nl_default_dirname;
+	  else
+	    {
+#if defined _LIBC || defined HAVE_STRDUP
+	      new_dirname = strdup (dirname);
+	      if (new_dirname == NULL)
+		return NULL;
+#else
+	      size_t len = strlen (dirname) + 1;
+	      new_dirname = (char *) malloc (len);
+	      if (new_dirname == NULL)
+		return NULL;
+
+	      memcpy (new_dirname, dirname, len);
+#endif
+	    }
+
+	  if (binding->dirname != _nl_default_dirname)
+	    free (binding->dirname);
+
+	  binding->dirname = new_dirname;
+	}
+    }
+  else
+    {
+      /* We have to create a new binding.  */
+#if !defined _LIBC && !defined HAVE_STRDUP
+      size_t len;
+#endif
+      struct binding *new_binding =
+	(struct binding *) malloc (sizeof (*new_binding));
+
+      if (new_binding == NULL)
+	return NULL;
+
+#if defined _LIBC || defined HAVE_STRDUP
+      new_binding->domainname = strdup (domainname);
+      if (new_binding->domainname == NULL)
+	return NULL;
+#else
+      len = strlen (domainname) + 1;
+      new_binding->domainname = (char *) malloc (len);
+      if (new_binding->domainname == NULL)
+	return NULL;
+      memcpy (new_binding->domainname, domainname, len);
+#endif
+
+      if (strcmp (dirname, _nl_default_dirname) == 0)
+	new_binding->dirname = (char *) _nl_default_dirname;
+      else
+	{
+#if defined _LIBC || defined HAVE_STRDUP
+	  new_binding->dirname = strdup (dirname);
+	  if (new_binding->dirname == NULL)
+	    return NULL;
+#else
+	  len = strlen (dirname) + 1;
+	  new_binding->dirname = (char *) malloc (len);
+	  if (new_binding->dirname == NULL)
+	    return NULL;
+	  memcpy (new_binding->dirname, dirname, len);
+#endif
+	}
+
+      /* Now enqueue it.  */
+      if (_nl_domain_bindings == NULL
+	  || strcmp (domainname, _nl_domain_bindings->domainname) < 0)
+	{
+	  new_binding->next = _nl_domain_bindings;
+	  _nl_domain_bindings = new_binding;
+	}
+      else
+	{
+	  binding = _nl_domain_bindings;
+	  while (binding->next != NULL
+		 && strcmp (domainname, binding->next->domainname) > 0)
+	    binding = binding->next;
+
+	  new_binding->next = binding->next;
+	  binding->next = new_binding;
+	}
+
+      binding = new_binding;
+    }
+
+  return binding->dirname;
+}
+
+#ifdef _LIBC
+/* Alias for function name in GNU C Library.  */
+weak_alias (__bindtextdomain, bindtextdomain);
+#endif
diff --git a/intl/cat-compat.c b/intl/cat-compat.c
new file mode 100644
index 00000000..867d901b
--- /dev/null
+++ b/intl/cat-compat.c
@@ -0,0 +1,262 @@
+/* Compatibility code for gettext-using-catgets interface.
+   Copyright (C) 1995, 1997 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#include <stdio.h>
+
+#ifdef STDC_HEADERS
+# include <stdlib.h>
+# include <string.h>
+#else
+char *getenv ();
+# ifdef HAVE_MALLOC_H
+#  include <malloc.h>
+# endif
+#endif
+
+#ifdef HAVE_NL_TYPES_H
+# include <nl_types.h>
+#endif
+
+#include "libgettext.h"
+
+/* @@ end of prolog @@ */
+
+/* XPG3 defines the result of `setlocale (category, NULL)' as:
+   ``Directs `setlocale()' to query `category' and return the current
+     setting of `local'.''
+   However it does not specify the exact format.  And even worse: POSIX
+   defines this not at all.  So we can use this feature only on selected
+   system (e.g. those using GNU C Library).  */
+#ifdef _LIBC
+# define HAVE_LOCALE_NULL
+#endif
+
+/* The catalog descriptor.  */
+static nl_catd catalog = (nl_catd) -1;
+
+/* Name of the default catalog.  */
+static const char default_catalog_name[] = "messages";
+
+/* Name of currently used catalog.  */
+static const char *catalog_name = default_catalog_name;
+
+/* Get ID for given string.  If not found return -1.  */
+static int msg_to_cat_id PARAMS ((const char *msg));
+
+/* Substitution for systems lacking this function in their C library.  */
+#if !_LIBC && !HAVE_STPCPY
+static char *stpcpy PARAMS ((char *dest, const char *src));
+#endif
+
+
+/* Set currently used domain/catalog.  */
+char *
+textdomain (domainname)
+     const char *domainname;
+{
+  nl_catd new_catalog;
+  char *new_name;
+  size_t new_name_len;
+  char *lang;
+
+#if defined HAVE_SETLOCALE && defined HAVE_LC_MESSAGES \
+    && defined HAVE_LOCALE_NULL
+  lang = setlocale (LC_MESSAGES, NULL);
+#else
+  lang = getenv ("LC_ALL");
+  if (lang == NULL || lang[0] == '\0')
+    {
+      lang = getenv ("LC_MESSAGES");
+      if (lang == NULL || lang[0] == '\0')
+	lang = getenv ("LANG");
+    }
+#endif
+  if (lang == NULL || lang[0] == '\0')
+    lang = "C";
+
+  /* See whether name of currently used domain is asked.  */
+  if (domainname == NULL)
+    return (char *) catalog_name;
+
+  if (domainname[0] == '\0')
+    domainname = default_catalog_name;
+
+  /* Compute length of added path element.  */
+  new_name_len = sizeof (LOCALEDIR) - 1 + 1 + strlen (lang)
+		 + sizeof ("/LC_MESSAGES/") - 1 + sizeof (PACKAGE) - 1
+		 + sizeof (".cat");
+
+  new_name = (char *) malloc (new_name_len);
+  if (new_name == NULL)
+    return NULL;
+
+  strcpy (new_name, PACKAGE);
+  new_catalog = catopen (new_name, 0);
+
+  if (new_catalog == (nl_catd) -1)
+    {
+      /* NLSPATH search didn't work, try absolute path */
+      sprintf (new_name, "%s/%s/LC_MESSAGES/%s.cat", LOCALEDIR, lang,
+	       PACKAGE);
+      new_catalog = catopen (new_name, 0);
+
+      if (new_catalog == (nl_catd) -1)
+	{
+	  free (new_name);
+	  return (char *) catalog_name;
+	}
+    }
+
+  /* Close old catalog.  */
+  if (catalog != (nl_catd) -1)
+    catclose (catalog);
+  if (catalog_name != default_catalog_name)
+    free ((char *) catalog_name);
+
+  catalog = new_catalog;
+  catalog_name = new_name;
+
+  return (char *) catalog_name;
+}
+
+char *
+bindtextdomain (domainname, dirname)
+     const char *domainname;
+     const char *dirname;
+{
+#if HAVE_SETENV || HAVE_PUTENV
+  char *old_val, *new_val, *cp;
+  size_t new_val_len;
+
+  /* This does not make much sense here but to be compatible do it.  */
+  if (domainname == NULL)
+    return NULL;
+
+  /* Compute length of added path element.  If we use setenv we don't need
+     the first byts for NLSPATH=, but why complicate the code for this
+     peanuts.  */
+  new_val_len = sizeof ("NLSPATH=") - 1 + strlen (dirname)
+		+ sizeof ("/%L/LC_MESSAGES/%N.cat");
+
+  old_val = getenv ("NLSPATH");
+  if (old_val == NULL || old_val[0] == '\0')
+    {
+      old_val = NULL;
+      new_val_len += 1 + sizeof (LOCALEDIR) - 1
+	             + sizeof ("/%L/LC_MESSAGES/%N.cat");
+    }
+  else
+    new_val_len += strlen (old_val);
+
+  new_val = (char *) malloc (new_val_len);
+  if (new_val == NULL)
+    return NULL;
+
+# if HAVE_SETENV
+  cp = new_val;
+# else
+  cp = stpcpy (new_val, "NLSPATH=");
+# endif
+
+  cp = stpcpy (cp, dirname);
+  cp = stpcpy (cp, "/%L/LC_MESSAGES/%N.cat:");
+
+  if (old_val == NULL)
+    {
+# if __STDC__
+      stpcpy (cp, LOCALEDIR "/%L/LC_MESSAGES/%N.cat");
+# else
+
+      cp = stpcpy (cp, LOCALEDIR);
+      stpcpy (cp, "/%L/LC_MESSAGES/%N.cat");
+# endif
+    }
+  else
+    stpcpy (cp, old_val);
+
+# if HAVE_SETENV
+  setenv ("NLSPATH", new_val, 1);
+  free (new_val);
+# else
+  putenv (new_val);
+  /* Do *not* free the environment entry we just entered.  It is used
+     from now on.   */
+# endif
+
+#endif
+
+  return (char *) domainname;
+}
+
+#undef gettext
+char *
+gettext (msg)
+     const char *msg;
+{
+  int msgid;
+
+  if (msg == NULL || catalog == (nl_catd) -1)
+    return (char *) msg;
+
+  /* Get the message from the catalog.  We always use set number 1.
+     The message ID is computed by the function `msg_to_cat_id'
+     which works on the table generated by `po-to-tbl'.  */
+  msgid = msg_to_cat_id (msg);
+  if (msgid == -1)
+    return (char *) msg;
+
+  return catgets (catalog, 1, msgid, (char *) msg);
+}
+
+/* Look through the table `_msg_tbl' which has `_msg_tbl_length' entries
+   for the one equal to msg.  If it is found return the ID.  In case when
+   the string is not found return -1.  */
+static int
+msg_to_cat_id (msg)
+     const char *msg;
+{
+  int cnt;
+
+  for (cnt = 0; cnt < _msg_tbl_length; ++cnt)
+    if (strcmp (msg, _msg_tbl[cnt]._msg) == 0)
+      return _msg_tbl[cnt]._msg_number;
+
+  return -1;
+}
+
+
+/* @@ begin of epilog @@ */
+
+/* We don't want libintl.a to depend on any other library.  So we
+   avoid the non-standard function stpcpy.  In GNU C Library this
+   function is available, though.  Also allow the symbol HAVE_STPCPY
+   to be defined.  */
+#if !_LIBC && !HAVE_STPCPY
+static char *
+stpcpy (dest, src)
+     char *dest;
+     const char *src;
+{
+  while ((*dest++ = *src++) != '\0')
+    /* Do nothing. */ ;
+  return dest - 1;
+}
+#endif
diff --git a/intl/dcgettext.c b/intl/dcgettext.c
new file mode 100644
index 00000000..c4c7a2c7
--- /dev/null
+++ b/intl/dcgettext.c
@@ -0,0 +1,624 @@
+/* Implementation of the dcgettext(3) function.
+   Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#include <sys/types.h>
+
+#ifdef __GNUC__
+# define alloca __builtin_alloca
+# define HAVE_ALLOCA 1
+#else
+# if defined HAVE_ALLOCA_H || defined _LIBC
+#  include <alloca.h>
+# else
+#  ifdef _AIX
+ #pragma alloca
+#  else
+#   ifndef alloca
+char *alloca ();
+#   endif
+#  endif
+# endif
+#endif
+
+#include <errno.h>
+#ifndef errno
+extern int errno;
+#endif
+#ifndef __set_errno
+# define __set_errno(val) errno = (val)
+#endif
+
+#if defined STDC_HEADERS || defined _LIBC
+# include <stdlib.h>
+#else
+char *getenv ();
+# ifdef HAVE_MALLOC_H
+#  include <malloc.h>
+# else
+void free ();
+# endif
+#endif
+
+#if defined HAVE_STRING_H || defined _LIBC
+# ifndef _GNU_SOURCE
+#  define _GNU_SOURCE	1
+# endif
+# include <string.h>
+#else
+# include <strings.h>
+#endif
+#if !HAVE_STRCHR && !defined _LIBC
+# ifndef strchr
+#  define strchr index
+# endif
+#endif
+
+#if defined HAVE_UNISTD_H || defined _LIBC
+# include <unistd.h>
+#endif
+
+#include "gettext.h"
+#include "gettextP.h"
+#ifdef _LIBC
+# include <libintl.h>
+#else
+# include "libgettext.h"
+#endif
+#include "hash-string.h"
+
+/* @@ end of prolog @@ */
+
+#ifdef _LIBC
+/* Rename the non ANSI C functions.  This is required by the standard
+   because some ANSI C functions will require linking with this object
+   file and the name space must not be polluted.  */
+# define getcwd __getcwd
+# ifndef stpcpy
+#  define stpcpy __stpcpy
+# endif
+#else
+# if !defined HAVE_GETCWD
+char *getwd ();
+#  define getcwd(buf, max) getwd (buf)
+# else
+char *getcwd ();
+# endif
+# ifndef HAVE_STPCPY
+static char *stpcpy PARAMS ((char *dest, const char *src));
+# endif
+#endif
+
+/* Amount to increase buffer size by in each try.  */
+#define PATH_INCR 32
+
+/* The following is from pathmax.h.  */
+/* Non-POSIX BSD systems might have gcc's limits.h, which doesn't define
+   PATH_MAX but might cause redefinition warnings when sys/param.h is
+   later included (as on MORE/BSD 4.3).  */
+#if defined(_POSIX_VERSION) || (defined(HAVE_LIMITS_H) && !defined(__GNUC__))
+# include <limits.h>
+#endif
+
+#ifndef _POSIX_PATH_MAX
+# define _POSIX_PATH_MAX 255
+#endif
+
+#if !defined(PATH_MAX) && defined(_PC_PATH_MAX)
+# define PATH_MAX (pathconf ("/", _PC_PATH_MAX) < 1 ? 1024 : pathconf ("/", _PC_PATH_MAX))
+#endif
+
+/* Don't include sys/param.h if it already has been.  */
+#if defined(HAVE_SYS_PARAM_H) && !defined(PATH_MAX) && !defined(MAXPATHLEN)
+# include <sys/param.h>
+#endif
+
+#if !defined(PATH_MAX) && defined(MAXPATHLEN)
+# define PATH_MAX MAXPATHLEN
+#endif
+
+#ifndef PATH_MAX
+# define PATH_MAX _POSIX_PATH_MAX
+#endif
+
+/* XPG3 defines the result of `setlocale (category, NULL)' as:
+   ``Directs `setlocale()' to query `category' and return the current
+     setting of `local'.''
+   However it does not specify the exact format.  And even worse: POSIX
+   defines this not at all.  So we can use this feature only on selected
+   system (e.g. those using GNU C Library).  */
+#ifdef _LIBC
+# define HAVE_LOCALE_NULL
+#endif
+
+/* Name of the default domain used for gettext(3) prior any call to
+   textdomain(3).  The default value for this is "messages".  */
+const char _nl_default_default_domain[] = "messages";
+
+/* Value used as the default domain for gettext(3).  */
+const char *_nl_current_default_domain = _nl_default_default_domain;
+
+/* Contains the default location of the message catalogs.  */
+const char _nl_default_dirname[] = GNULOCALEDIR;
+
+/* List with bindings of specific domains created by bindtextdomain()
+   calls.  */
+struct binding *_nl_domain_bindings;
+
+/* Prototypes for local functions.  */
+static char *find_msg PARAMS ((struct loaded_l10nfile *domain_file,
+			       const char *msgid)) internal_function;
+static const char *category_to_name PARAMS ((int category)) internal_function;
+static const char *guess_category_value PARAMS ((int category,
+						 const char *categoryname))
+     internal_function;
+
+
+/* For those loosing systems which don't have `alloca' we have to add
+   some additional code emulating it.  */
+#ifdef HAVE_ALLOCA
+/* Nothing has to be done.  */
+# define ADD_BLOCK(list, address) /* nothing */
+# define FREE_BLOCKS(list) /* nothing */
+#else
+struct block_list
+{
+  void *address;
+  struct block_list *next;
+};
+# define ADD_BLOCK(list, addr)						      \
+  do {									      \
+    struct block_list *newp = (struct block_list *) malloc (sizeof (*newp));  \
+    /* If we cannot get a free block we cannot add the new element to	      \
+       the list.  */							      \
+    if (newp != NULL) {							      \
+      newp->address = (addr);						      \
+      newp->next = (list);						      \
+      (list) = newp;							      \
+    }									      \
+  } while (0)
+# define FREE_BLOCKS(list)						      \
+  do {									      \
+    while (list != NULL) {						      \
+      struct block_list *old = list;					      \
+      list = list->next;						      \
+      free (old);							      \
+    }									      \
+  } while (0)
+# undef alloca
+# define alloca(size) (malloc (size))
+#endif	/* have alloca */
+
+
+/* Names for the libintl functions are a problem.  They must not clash
+   with existing names and they should follow ANSI C.  But this source
+   code is also used in GNU C Library where the names have a __
+   prefix.  So we have to make a difference here.  */
+#ifdef _LIBC
+# define DCGETTEXT __dcgettext
+#else
+# define DCGETTEXT dcgettext__
+#endif
+
+/* Look up MSGID in the DOMAINNAME message catalog for the current CATEGORY
+   locale.  */
+char *
+DCGETTEXT (domainname, msgid, category)
+     const char *domainname;
+     const char *msgid;
+     int category;
+{
+#ifndef HAVE_ALLOCA
+  struct block_list *block_list = NULL;
+#endif
+  struct loaded_l10nfile *domain;
+  struct binding *binding;
+  const char *categoryname;
+  const char *categoryvalue;
+  char *dirname, *xdomainname;
+  char *single_locale;
+  char *retval;
+  int saved_errno = errno;
+
+  /* If no real MSGID is given return NULL.  */
+  if (msgid == NULL)
+    return NULL;
+
+  /* If DOMAINNAME is NULL, we are interested in the default domain.  If
+     CATEGORY is not LC_MESSAGES this might not make much sense but the
+     defintion left this undefined.  */
+  if (domainname == NULL)
+    domainname = _nl_current_default_domain;
+
+  /* First find matching binding.  */
+  for (binding = _nl_domain_bindings; binding != NULL; binding = binding->next)
+    {
+      int compare = strcmp (domainname, binding->domainname);
+      if (compare == 0)
+	/* We found it!  */
+	break;
+      if (compare < 0)
+	{
+	  /* It is not in the list.  */
+	  binding = NULL;
+	  break;
+	}
+    }
+
+  if (binding == NULL)
+    dirname = (char *) _nl_default_dirname;
+  else if (binding->dirname[0] == '/')
+    dirname = binding->dirname;
+  else
+    {
+      /* We have a relative path.  Make it absolute now.  */
+      size_t dirname_len = strlen (binding->dirname) + 1;
+      size_t path_max;
+      char *ret;
+
+      path_max = (unsigned) PATH_MAX;
+      path_max += 2;		/* The getcwd docs say to do this.  */
+
+      dirname = (char *) alloca (path_max + dirname_len);
+      ADD_BLOCK (block_list, dirname);
+
+      __set_errno (0);
+      while ((ret = getcwd (dirname, path_max)) == NULL && errno == ERANGE)
+	{
+	  path_max += PATH_INCR;
+	  dirname = (char *) alloca (path_max + dirname_len);
+	  ADD_BLOCK (block_list, dirname);
+	  __set_errno (0);
+	}
+
+      if (ret == NULL)
+	{
+	  /* We cannot get the current working directory.  Don't signal an
+	     error but simply return the default string.  */
+	  FREE_BLOCKS (block_list);
+	  __set_errno (saved_errno);
+	  return (char *) msgid;
+	}
+
+      stpcpy (stpcpy (strchr (dirname, '\0'), "/"), binding->dirname);
+    }
+
+  /* Now determine the symbolic name of CATEGORY and its value.  */
+  categoryname = category_to_name (category);
+  categoryvalue = guess_category_value (category, categoryname);
+
+  xdomainname = (char *) alloca (strlen (categoryname)
+				 + strlen (domainname) + 5);
+  ADD_BLOCK (block_list, xdomainname);
+
+  stpcpy (stpcpy (stpcpy (stpcpy (xdomainname, categoryname), "/"),
+		  domainname),
+	  ".mo");
+
+  /* Creating working area.  */
+  single_locale = (char *) alloca (strlen (categoryvalue) + 1);
+  ADD_BLOCK (block_list, single_locale);
+
+
+  /* Search for the given string.  This is a loop because we perhaps
+     got an ordered list of languages to consider for th translation.  */
+  while (1)
+    {
+      /* Make CATEGORYVALUE point to the next element of the list.  */
+      while (categoryvalue[0] != '\0' && categoryvalue[0] == ':')
+	++categoryvalue;
+      if (categoryvalue[0] == '\0')
+	{
+	  /* The whole contents of CATEGORYVALUE has been searched but
+	     no valid entry has been found.  We solve this situation
+	     by implicitly appending a "C" entry, i.e. no translation
+	     will take place.  */
+	  single_locale[0] = 'C';
+	  single_locale[1] = '\0';
+	}
+      else
+	{
+	  char *cp = single_locale;
+	  while (categoryvalue[0] != '\0' && categoryvalue[0] != ':')
+	    *cp++ = *categoryvalue++;
+	  *cp = '\0';
+	}
+
+      /* If the current locale value is C (or POSIX) we don't load a
+	 domain.  Return the MSGID.  */
+      if (strcmp (single_locale, "C") == 0
+	  || strcmp (single_locale, "POSIX") == 0)
+	{
+	  FREE_BLOCKS (block_list);
+	  __set_errno (saved_errno);
+	  return (char *) msgid;
+	}
+
+
+      /* Find structure describing the message catalog matching the
+	 DOMAINNAME and CATEGORY.  */
+      domain = _nl_find_domain (dirname, single_locale, xdomainname);
+
+      if (domain != NULL)
+	{
+	  retval = find_msg (domain, msgid);
+
+	  if (retval == NULL)
+	    {
+	      int cnt;
+
+	      for (cnt = 0; domain->successor[cnt] != NULL; ++cnt)
+		{
+		  retval = find_msg (domain->successor[cnt], msgid);
+
+		  if (retval != NULL)
+		    break;
+		}
+	    }
+
+	  if (retval != NULL)
+	    {
+	      FREE_BLOCKS (block_list);
+	      __set_errno (saved_errno);
+	      return retval;
+	    }
+	}
+    }
+  /* NOTREACHED */
+}
+
+#ifdef _LIBC
+/* Alias for function name in GNU C Library.  */
+weak_alias (__dcgettext, dcgettext);
+#endif
+
+
+static char *
+internal_function
+find_msg (domain_file, msgid)
+     struct loaded_l10nfile *domain_file;
+     const char *msgid;
+{
+  size_t top, act, bottom;
+  struct loaded_domain *domain;
+
+  if (domain_file->decided == 0)
+    _nl_load_domain (domain_file);
+
+  if (domain_file->data == NULL)
+    return NULL;
+
+  domain = (struct loaded_domain *) domain_file->data;
+
+  /* Locate the MSGID and its translation.  */
+  if (domain->hash_size > 2 && domain->hash_tab != NULL)
+    {
+      /* Use the hashing table.  */
+      nls_uint32 len = strlen (msgid);
+      nls_uint32 hash_val = hash_string (msgid);
+      nls_uint32 idx = hash_val % domain->hash_size;
+      nls_uint32 incr = 1 + (hash_val % (domain->hash_size - 2));
+      nls_uint32 nstr = W (domain->must_swap, domain->hash_tab[idx]);
+
+      if (nstr == 0)
+	/* Hash table entry is empty.  */
+	return NULL;
+
+      if (W (domain->must_swap, domain->orig_tab[nstr - 1].length) == len
+	  && strcmp (msgid,
+		     domain->data + W (domain->must_swap,
+				       domain->orig_tab[nstr - 1].offset)) == 0)
+	return (char *) domain->data + W (domain->must_swap,
+					  domain->trans_tab[nstr - 1].offset);
+
+      while (1)
+	{
+	  if (idx >= domain->hash_size - incr)
+	    idx -= domain->hash_size - incr;
+	  else
+	    idx += incr;
+
+	  nstr = W (domain->must_swap, domain->hash_tab[idx]);
+	  if (nstr == 0)
+	    /* Hash table entry is empty.  */
+	    return NULL;
+
+	  if (W (domain->must_swap, domain->orig_tab[nstr - 1].length) == len
+	      && strcmp (msgid,
+			 domain->data + W (domain->must_swap,
+					   domain->orig_tab[nstr - 1].offset))
+	         == 0)
+	    return (char *) domain->data
+	      + W (domain->must_swap, domain->trans_tab[nstr - 1].offset);
+	}
+      /* NOTREACHED */
+    }
+
+  /* Now we try the default method:  binary search in the sorted
+     array of messages.  */
+  bottom = 0;
+  top = domain->nstrings;
+  while (bottom < top)
+    {
+      int cmp_val;
+
+      act = (bottom + top) / 2;
+      cmp_val = strcmp (msgid, domain->data
+			       + W (domain->must_swap,
+				    domain->orig_tab[act].offset));
+      if (cmp_val < 0)
+	top = act;
+      else if (cmp_val > 0)
+	bottom = act + 1;
+      else
+	break;
+    }
+
+  /* If an translation is found return this.  */
+  return bottom >= top ? NULL : (char *) domain->data
+                                + W (domain->must_swap,
+				     domain->trans_tab[act].offset);
+}
+
+
+/* Return string representation of locale CATEGORY.  */
+static const char *
+internal_function
+category_to_name (category)
+     int category;
+{
+  const char *retval;
+
+  switch (category)
+  {
+#ifdef LC_COLLATE
+  case LC_COLLATE:
+    retval = "LC_COLLATE";
+    break;
+#endif
+#ifdef LC_CTYPE
+  case LC_CTYPE:
+    retval = "LC_CTYPE";
+    break;
+#endif
+#ifdef LC_MONETARY
+  case LC_MONETARY:
+    retval = "LC_MONETARY";
+    break;
+#endif
+#ifdef LC_NUMERIC
+  case LC_NUMERIC:
+    retval = "LC_NUMERIC";
+    break;
+#endif
+#ifdef LC_TIME
+  case LC_TIME:
+    retval = "LC_TIME";
+    break;
+#endif
+#ifdef LC_MESSAGES
+  case LC_MESSAGES:
+    retval = "LC_MESSAGES";
+    break;
+#endif
+#ifdef LC_RESPONSE
+  case LC_RESPONSE:
+    retval = "LC_RESPONSE";
+    break;
+#endif
+#ifdef LC_ALL
+  case LC_ALL:
+    /* This might not make sense but is perhaps better than any other
+       value.  */
+    retval = "LC_ALL";
+    break;
+#endif
+  default:
+    /* If you have a better idea for a default value let me know.  */
+    retval = "LC_XXX";
+  }
+
+  return retval;
+}
+
+/* Guess value of current locale from value of the environment variables.  */
+static const char *
+internal_function
+guess_category_value (category, categoryname)
+     int category;
+     const char *categoryname;
+{
+  const char *retval;
+
+  /* The highest priority value is the `LANGUAGE' environment
+     variable.  This is a GNU extension.  */
+  retval = getenv ("LANGUAGE");
+  if (retval != NULL && retval[0] != '\0')
+    return retval;
+
+  /* `LANGUAGE' is not set.  So we have to proceed with the POSIX
+     methods of looking to `LC_ALL', `LC_xxx', and `LANG'.  On some
+     systems this can be done by the `setlocale' function itself.  */
+#if defined HAVE_SETLOCALE && defined HAVE_LC_MESSAGES && defined HAVE_LOCALE_NULL
+  return setlocale (category, NULL);
+#else
+  /* Setting of LC_ALL overwrites all other.  */
+  retval = getenv ("LC_ALL");
+  if (retval != NULL && retval[0] != '\0')
+    return retval;
+
+  /* Next comes the name of the desired category.  */
+  retval = getenv (categoryname);
+  if (retval != NULL && retval[0] != '\0')
+    return retval;
+
+  /* Last possibility is the LANG environment variable.  */
+  retval = getenv ("LANG");
+  if (retval != NULL && retval[0] != '\0')
+    return retval;
+
+  /* We use C as the default domain.  POSIX says this is implementation
+     defined.  */
+  return "C";
+#endif
+}
+
+/* @@ begin of epilog @@ */
+
+/* We don't want libintl.a to depend on any other library.  So we
+   avoid the non-standard function stpcpy.  In GNU C Library this
+   function is available, though.  Also allow the symbol HAVE_STPCPY
+   to be defined.  */
+#if !_LIBC && !HAVE_STPCPY
+static char *
+stpcpy (dest, src)
+     char *dest;
+     const char *src;
+{
+  while ((*dest++ = *src++) != '\0')
+    /* Do nothing. */ ;
+  return dest - 1;
+}
+#endif
+
+
+#ifdef _LIBC
+/* If we want to free all resources we have to do some work at
+   program's end.  */
+static void __attribute__ ((unused))
+free_mem (void)
+{
+  struct binding *runp;
+
+  for (runp = _nl_domain_bindings; runp != NULL; runp = runp->next)
+    {
+      free (runp->domainname);
+      if (runp->dirname != _nl_default_dirname)
+	/* Yes, this is a pointer comparison.  */
+	free (runp->dirname);
+    }
+
+  if (_nl_current_default_domain != _nl_default_default_domain)
+    /* Yes, again a pointer comparison.  */
+    free ((char *) _nl_current_default_domain);
+}
+
+text_set_element (__libc_subfreeres, free_mem);
+#endif
diff --git a/intl/dgettext.c b/intl/dgettext.c
new file mode 100644
index 00000000..0510c2b0
--- /dev/null
+++ b/intl/dgettext.c
@@ -0,0 +1,59 @@
+/* Implementation of the dgettext(3) function
+   Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#if defined HAVE_LOCALE_H || defined _LIBC
+# include <locale.h>
+#endif
+
+#ifdef _LIBC
+# include <libintl.h>
+#else
+# include "libgettext.h"
+#endif
+
+/* @@ end of prolog @@ */
+
+/* Names for the libintl functions are a problem.  They must not clash
+   with existing names and they should follow ANSI C.  But this source
+   code is also used in GNU C Library where the names have a __
+   prefix.  So we have to make a difference here.  */
+#ifdef _LIBC
+# define DGETTEXT __dgettext
+# define DCGETTEXT __dcgettext
+#else
+# define DGETTEXT dgettext__
+# define DCGETTEXT dcgettext__
+#endif
+
+/* Look up MSGID in the DOMAINNAME message catalog of the current
+   LC_MESSAGES locale.  */
+char *
+DGETTEXT (domainname, msgid)
+     const char *domainname;
+     const char *msgid;
+{
+  return DCGETTEXT (domainname, msgid, LC_MESSAGES);
+}
+
+#ifdef _LIBC
+/* Alias for function name in GNU C Library.  */
+weak_alias (__dgettext, dgettext);
+#endif
diff --git a/intl/explodename.c b/intl/explodename.c
new file mode 100644
index 00000000..8066dc29
--- /dev/null
+++ b/intl/explodename.c
@@ -0,0 +1,188 @@
+/* Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+   Contributed by Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#if defined STDC_HEADERS || defined _LIBC
+# include <stdlib.h>
+#endif
+
+#if defined HAVE_STRING_H || defined _LIBC
+# include <string.h>
+#else
+# include <strings.h>
+#endif
+#include <sys/types.h>
+
+#include "loadinfo.h"
+
+/* On some strange systems still no definition of NULL is found.  Sigh!  */
+#ifndef NULL
+# if defined __STDC__ && __STDC__
+#  define NULL ((void *) 0)
+# else
+#  define NULL 0
+# endif
+#endif
+
+/* @@ end of prolog @@ */
+
+int
+_nl_explode_name (name, language, modifier, territory, codeset,
+		  normalized_codeset, special, sponsor, revision)
+     char *name;
+     const char **language;
+     const char **modifier;
+     const char **territory;
+     const char **codeset;
+     const char **normalized_codeset;
+     const char **special;
+     const char **sponsor;
+     const char **revision;
+{
+  enum { undecided, xpg, cen } syntax;
+  char *cp;
+  int mask;
+
+  *modifier = NULL;
+  *territory = NULL;
+  *codeset = NULL;
+  *normalized_codeset = NULL;
+  *special = NULL;
+  *sponsor = NULL;
+  *revision = NULL;
+
+  /* Now we determine the single parts of the locale name.  First
+     look for the language.  Termination symbols are `_' and `@' if
+     we use XPG4 style, and `_', `+', and `,' if we use CEN syntax.  */
+  mask = 0;
+  syntax = undecided;
+  *language = cp = name;
+  while (cp[0] != '\0' && cp[0] != '_' && cp[0] != '@'
+	 && cp[0] != '+' && cp[0] != ',')
+    ++cp;
+
+  if (*language == cp)
+    /* This does not make sense: language has to be specified.  Use
+       this entry as it is without exploding.  Perhaps it is an alias.  */
+    cp = strchr (*language, '\0');
+  else if (cp[0] == '_')
+    {
+      /* Next is the territory.  */
+      cp[0] = '\0';
+      *territory = ++cp;
+
+      while (cp[0] != '\0' && cp[0] != '.' && cp[0] != '@'
+	     && cp[0] != '+' && cp[0] != ',' && cp[0] != '_')
+	++cp;
+
+      mask |= TERRITORY;
+
+      if (cp[0] == '.')
+	{
+	  /* Next is the codeset.  */
+	  syntax = xpg;
+	  cp[0] = '\0';
+	  *codeset = ++cp;
+
+	  while (cp[0] != '\0' && cp[0] != '@')
+	    ++cp;
+
+	  mask |= XPG_CODESET;
+
+	  if (*codeset != cp && (*codeset)[0] != '\0')
+	    {
+	      *normalized_codeset = _nl_normalize_codeset (*codeset,
+							   cp - *codeset);
+	      if (strcmp (*codeset, *normalized_codeset) == 0)
+		free ((char *) *normalized_codeset);
+	      else
+		mask |= XPG_NORM_CODESET;
+	    }
+	}
+    }
+
+  if (cp[0] == '@' || (syntax != xpg && cp[0] == '+'))
+    {
+      /* Next is the modifier.  */
+      syntax = cp[0] == '@' ? xpg : cen;
+      cp[0] = '\0';
+      *modifier = ++cp;
+
+      while (syntax == cen && cp[0] != '\0' && cp[0] != '+'
+	     && cp[0] != ',' && cp[0] != '_')
+	++cp;
+
+      mask |= XPG_MODIFIER | CEN_AUDIENCE;
+    }
+
+  if (syntax != xpg && (cp[0] == '+' || cp[0] == ',' || cp[0] == '_'))
+    {
+      syntax = cen;
+
+      if (cp[0] == '+')
+	{
+ 	  /* Next is special application (CEN syntax).  */
+	  cp[0] = '\0';
+	  *special = ++cp;
+
+	  while (cp[0] != '\0' && cp[0] != ',' && cp[0] != '_')
+	    ++cp;
+
+	  mask |= CEN_SPECIAL;
+	}
+
+      if (cp[0] == ',')
+	{
+ 	  /* Next is sponsor (CEN syntax).  */
+	  cp[0] = '\0';
+	  *sponsor = ++cp;
+
+	  while (cp[0] != '\0' && cp[0] != '_')
+	    ++cp;
+
+	  mask |= CEN_SPONSOR;
+	}
+
+      if (cp[0] == '_')
+	{
+ 	  /* Next is revision (CEN syntax).  */
+	  cp[0] = '\0';
+	  *revision = ++cp;
+
+	  mask |= CEN_REVISION;
+	}
+    }
+
+  /* For CEN syntax values it might be important to have the
+     separator character in the file name, not for XPG syntax.  */
+  if (syntax == xpg)
+    {
+      if (*territory != NULL && (*territory)[0] == '\0')
+	mask &= ~TERRITORY;
+
+      if (*codeset != NULL && (*codeset)[0] == '\0')
+	mask &= ~XPG_CODESET;
+
+      if (*modifier != NULL && (*modifier)[0] == '\0')
+	mask &= ~XPG_MODIFIER;
+    }
+
+  return mask;
+}
diff --git a/intl/finddomain.c b/intl/finddomain.c
new file mode 100644
index 00000000..81ea29bf
--- /dev/null
+++ b/intl/finddomain.c
@@ -0,0 +1,216 @@
+/* Handle list of needed message catalogs
+   Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+   Written by Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#include <ctype.h>
+#include <errno.h>
+#include <stdio.h>
+#include <sys/types.h>
+
+#if defined STDC_HEADERS || defined _LIBC
+# include <stdlib.h>
+#else
+# ifdef HAVE_MALLOC_H
+#  include <malloc.h>
+# else
+void free ();
+# endif
+#endif
+
+#if defined HAVE_STRING_H || defined _LIBC
+# include <string.h>
+#else
+# include <strings.h>
+# ifndef memcpy
+#  define memcpy(Dst, Src, Num) bcopy (Src, Dst, Num)
+# endif
+#endif
+#if !HAVE_STRCHR && !defined _LIBC
+# ifndef strchr
+#  define strchr index
+# endif
+#endif
+
+#if defined HAVE_UNISTD_H || defined _LIBC
+# include <unistd.h>
+#endif
+
+#include "gettext.h"
+#include "gettextP.h"
+#ifdef _LIBC
+# include <libintl.h>
+#else
+# include "libgettext.h"
+#endif
+
+/* @@ end of prolog @@ */
+/* List of already loaded domains.  */
+static struct loaded_l10nfile *_nl_loaded_domains;
+
+
+/* Return a data structure describing the message catalog described by
+   the DOMAINNAME and CATEGORY parameters with respect to the currently
+   established bindings.  */
+struct loaded_l10nfile *
+internal_function
+_nl_find_domain (dirname, locale, domainname)
+     const char *dirname;
+     char *locale;
+     const char *domainname;
+{
+  struct loaded_l10nfile *retval;
+  const char *language;
+  const char *modifier;
+  const char *territory;
+  const char *codeset;
+  const char *normalized_codeset;
+  const char *special;
+  const char *sponsor;
+  const char *revision;
+  const char *alias_value;
+  int mask;
+
+  /* LOCALE can consist of up to four recognized parts for the XPG syntax:
+
+		language[_territory[.codeset]][@modifier]
+
+     and six parts for the CEN syntax:
+
+	language[_territory][+audience][+special][,[sponsor][_revision]]
+
+     Beside the first part all of them are allowed to be missing.  If
+     the full specified locale is not found, the less specific one are
+     looked for.  The various parts will be stripped off according to
+     the following order:
+		(1) revision
+		(2) sponsor
+		(3) special
+		(4) codeset
+		(5) normalized codeset
+		(6) territory
+		(7) audience/modifier
+   */
+
+  /* If we have already tested for this locale entry there has to
+     be one data set in the list of loaded domains.  */
+  retval = _nl_make_l10nflist (&_nl_loaded_domains, dirname,
+			       strlen (dirname) + 1, 0, locale, NULL, NULL,
+			       NULL, NULL, NULL, NULL, NULL, domainname, 0);
+  if (retval != NULL)
+    {
+      /* We know something about this locale.  */
+      int cnt;
+
+      if (retval->decided == 0)
+	_nl_load_domain (retval);
+
+      if (retval->data != NULL)
+	return retval;
+
+      for (cnt = 0; retval->successor[cnt] != NULL; ++cnt)
+	{
+	  if (retval->successor[cnt]->decided == 0)
+	    _nl_load_domain (retval->successor[cnt]);
+
+	  if (retval->successor[cnt]->data != NULL)
+	    break;
+	}
+      return cnt >= 0 ? retval : NULL;
+      /* NOTREACHED */
+    }
+
+  /* See whether the locale value is an alias.  If yes its value
+     *overwrites* the alias name.  No test for the original value is
+     done.  */
+  alias_value = _nl_expand_alias (locale);
+  if (alias_value != NULL)
+    {
+#if defined _LIBC || defined HAVE_STRDUP
+      locale = strdup (alias_value);
+      if (locale == NULL)
+	return NULL;
+#else
+      size_t len = strlen (alias_value) + 1;
+      locale = (char *) malloc (len);
+      if (locale == NULL)
+	return NULL;
+
+      memcpy (locale, alias_value, len);
+#endif
+    }
+
+  /* Now we determine the single parts of the locale name.  First
+     look for the language.  Termination symbols are `_' and `@' if
+     we use XPG4 style, and `_', `+', and `,' if we use CEN syntax.  */
+  mask = _nl_explode_name (locale, &language, &modifier, &territory,
+			   &codeset, &normalized_codeset, &special,
+			   &sponsor, &revision);
+
+  /* Create all possible locale entries which might be interested in
+     generalization.  */
+  retval = _nl_make_l10nflist (&_nl_loaded_domains, dirname,
+			       strlen (dirname) + 1, mask, language, territory,
+			       codeset, normalized_codeset, modifier, special,
+			       sponsor, revision, domainname, 1);
+  if (retval == NULL)
+    /* This means we are out of core.  */
+    return NULL;
+
+  if (retval->decided == 0)
+    _nl_load_domain (retval);
+  if (retval->data == NULL)
+    {
+      int cnt;
+      for (cnt = 0; retval->successor[cnt] != NULL; ++cnt)
+	{
+	  if (retval->successor[cnt]->decided == 0)
+	    _nl_load_domain (retval->successor[cnt]);
+	  if (retval->successor[cnt]->data != NULL)
+	    break;
+	}
+    }
+
+  /* The room for an alias was dynamically allocated.  Free it now.  */
+  if (alias_value != NULL)
+    free (locale);
+
+  return retval;
+}
+
+
+#ifdef _LIBC
+static void __attribute__ ((unused))
+free_mem (void)
+{
+  struct loaded_l10nfile *runp = _nl_loaded_domains;
+
+  while (runp != NULL)
+    {
+      struct loaded_l10nfile *here = runp;
+      if (runp->data != NULL)
+	_nl_unload_domain ((struct loaded_domain *) runp->data);
+      runp = runp->next;
+      free (here);
+    }
+}
+
+text_set_element (__libc_subfreeres, free_mem);
+#endif
diff --git a/intl/gettext.c b/intl/gettext.c
new file mode 100644
index 00000000..d929f98d
--- /dev/null
+++ b/intl/gettext.c
@@ -0,0 +1,70 @@
+/* Implementation of gettext(3) function.
+   Copyright (C) 1995, 1997 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#ifdef _LIBC
+# define __need_NULL
+# include <stddef.h>
+#else
+# ifdef STDC_HEADERS
+#  include <stdlib.h>		/* Just for NULL.  */
+# else
+#  ifdef HAVE_STRING_H
+#   include <string.h>
+#  else
+#   define NULL ((void *) 0)
+#  endif
+# endif
+#endif
+
+#ifdef _LIBC
+# include <libintl.h>
+#else
+# include "libgettext.h"
+#endif
+
+/* @@ end of prolog @@ */
+
+/* Names for the libintl functions are a problem.  They must not clash
+   with existing names and they should follow ANSI C.  But this source
+   code is also used in GNU C Library where the names have a __
+   prefix.  So we have to make a difference here.  */
+#ifdef _LIBC
+# define GETTEXT __gettext
+# define DGETTEXT __dgettext
+#else
+# define GETTEXT gettext__
+# define DGETTEXT dgettext__
+#endif
+
+/* Look up MSGID in the current default message catalog for the current
+   LC_MESSAGES locale.  If not found, returns MSGID itself (the default
+   text).  */
+char *
+GETTEXT (msgid)
+     const char *msgid;
+{
+  return DGETTEXT (NULL, msgid);
+}
+
+#ifdef _LIBC
+/* Alias for function name in GNU C Library.  */
+weak_alias (__gettext, gettext);
+#endif
diff --git a/intl/gettext.h b/intl/gettext.h
new file mode 100644
index 00000000..3cd23d7d
--- /dev/null
+++ b/intl/gettext.h
@@ -0,0 +1,105 @@
+/* Internal header for GNU gettext internationalization functions.
+   Copyright (C) 1995, 1997 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU Library General Public
+   License along with the GNU C Library; see the file COPYING.LIB.  If not,
+   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#ifndef _GETTEXT_H
+#define _GETTEXT_H 1
+
+#include <stdio.h>
+
+#if HAVE_LIMITS_H || _LIBC
+# include <limits.h>
+#endif
+
+/* @@ end of prolog @@ */
+
+/* The magic number of the GNU message catalog format.  */
+#define _MAGIC 0x950412de
+#define _MAGIC_SWAPPED 0xde120495
+
+/* Revision number of the currently used .mo (binary) file format.  */
+#define MO_REVISION_NUMBER 0
+
+/* The following contortions are an attempt to use the C preprocessor
+   to determine an unsigned integral type that is 32 bits wide.  An
+   alternative approach is to use autoconf's AC_CHECK_SIZEOF macro, but
+   doing that would require that the configure script compile and *run*
+   the resulting executable.  Locally running cross-compiled executables
+   is usually not possible.  */
+
+#if __STDC__
+# define UINT_MAX_32_BITS 4294967295U
+#else
+# define UINT_MAX_32_BITS 0xFFFFFFFF
+#endif
+
+/* If UINT_MAX isn't defined, assume it's a 32-bit type.
+   This should be valid for all systems GNU cares about because
+   that doesn't include 16-bit systems, and only modern systems
+   (that certainly have <limits.h>) have 64+-bit integral types.  */
+
+#ifndef UINT_MAX
+# define UINT_MAX UINT_MAX_32_BITS
+#endif
+
+#if UINT_MAX == UINT_MAX_32_BITS
+typedef unsigned nls_uint32;
+#else
+# if USHRT_MAX == UINT_MAX_32_BITS
+typedef unsigned short nls_uint32;
+# else
+#  if ULONG_MAX == UINT_MAX_32_BITS
+typedef unsigned long nls_uint32;
+#  else
+  /* The following line is intended to throw an error.  Using #error is
+     not portable enough.  */
+  "Cannot determine unsigned 32-bit data type."
+#  endif
+# endif
+#endif
+
+
+/* Header for binary .mo file format.  */
+struct mo_file_header
+{
+  /* The magic number.  */
+  nls_uint32 magic;
+  /* The revision number of the file format.  */
+  nls_uint32 revision;
+  /* The number of strings pairs.  */
+  nls_uint32 nstrings;
+  /* Offset of table with start offsets of original strings.  */
+  nls_uint32 orig_tab_offset;
+  /* Offset of table with start offsets of translation strings.  */
+  nls_uint32 trans_tab_offset;
+  /* Size of hashing table.  */
+  nls_uint32 hash_tab_size;
+  /* Offset of first hashing entry.  */
+  nls_uint32 hash_tab_offset;
+};
+
+struct string_desc
+{
+  /* Length of addressed string.  */
+  nls_uint32 length;
+  /* Offset of string in file.  */
+  nls_uint32 offset;
+};
+
+/* @@ begin of epilog @@ */
+
+#endif	/* gettext.h  */
diff --git a/intl/gettextP.h b/intl/gettextP.h
new file mode 100644
index 00000000..00c52031
--- /dev/null
+++ b/intl/gettextP.h
@@ -0,0 +1,89 @@
+/* Header describing internals of gettext library
+   Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+   Written by Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifndef _GETTEXTP_H
+#define _GETTEXTP_H
+
+#include "loadinfo.h"
+
+/* @@ end of prolog @@ */
+
+#ifndef PARAMS
+# if __STDC__
+#  define PARAMS(args) args
+# else
+#  define PARAMS(args) ()
+# endif
+#endif
+
+#ifndef internal_function
+# define internal_function
+#endif
+
+#ifndef W
+# define W(flag, data) ((flag) ? SWAP (data) : (data))
+#endif
+
+
+#ifdef _LIBC
+# include <byteswap.h>
+# define SWAP(i) bswap_32 (i)
+#else
+static nls_uint32 SWAP PARAMS ((nls_uint32 i));
+
+static inline nls_uint32
+SWAP (i)
+     nls_uint32 i;
+{
+  return (i << 24) | ((i & 0xff00) << 8) | ((i >> 8) & 0xff00) | (i >> 24);
+}
+#endif
+
+
+struct loaded_domain
+{
+  const char *data;
+  int use_mmap;
+  size_t mmap_size;
+  int must_swap;
+  nls_uint32 nstrings;
+  struct string_desc *orig_tab;
+  struct string_desc *trans_tab;
+  nls_uint32 hash_size;
+  nls_uint32 *hash_tab;
+};
+
+struct binding
+{
+  struct binding *next;
+  char *domainname;
+  char *dirname;
+};
+
+struct loaded_l10nfile *_nl_find_domain PARAMS ((const char *__dirname,
+						 char *__locale,
+						 const char *__domainname))
+     internal_function;
+void _nl_load_domain PARAMS ((struct loaded_l10nfile *__domain))
+     internal_function;
+void _nl_unload_domain PARAMS ((struct loaded_domain *__domain))
+     internal_function;
+
+/* @@ begin of epilog @@ */
+
+#endif /* gettextP.h  */
diff --git a/intl/hash-string.h b/intl/hash-string.h
new file mode 100644
index 00000000..cacb38e4
--- /dev/null
+++ b/intl/hash-string.h
@@ -0,0 +1,59 @@
+/* Implements a string hashing function.
+   Copyright (C) 1995, 1997 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU Library General Public
+   License along with the GNU C Library; see the file COPYING.LIB.  If not,
+   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+/* @@ end of prolog @@ */
+
+#ifndef PARAMS
+# if __STDC__
+#  define PARAMS(Args) Args
+# else
+#  define PARAMS(Args) ()
+# endif
+#endif
+
+/* We assume to have `unsigned long int' value with at least 32 bits.  */
+#define HASHWORDBITS 32
+
+
+/* Defines the so called `hashpjw' function by P.J. Weinberger
+   [see Aho/Sethi/Ullman, COMPILERS: Principles, Techniques and Tools,
+   1986, 1987 Bell Telephone Laboratories, Inc.]  */
+static unsigned long hash_string PARAMS ((const char *__str_param));
+
+static inline unsigned long
+hash_string (str_param)
+     const char *str_param;
+{
+  unsigned long int hval, g;
+  const char *str = str_param;
+
+  /* Compute the hash value for the given string.  */
+  hval = 0;
+  while (*str != '\0')
+    {
+      hval <<= 4;
+      hval += (unsigned long) *str++;
+      g = hval & ((unsigned long) 0xf << (HASHWORDBITS - 4));
+      if (g != 0)
+	{
+	  hval ^= g >> (HASHWORDBITS - 8);
+	  hval ^= g;
+	}
+    }
+  return hval;
+}
diff --git a/intl/intl-compat.c b/intl/intl-compat.c
new file mode 100644
index 00000000..503efa0f
--- /dev/null
+++ b/intl/intl-compat.c
@@ -0,0 +1,76 @@
+/* intl-compat.c - Stub functions to call gettext functions from GNU gettext
+   Library.
+   Copyright (C) 1995 Software Foundation, Inc.
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#include "libgettext.h"
+
+/* @@ end of prolog @@ */
+
+
+#undef gettext
+#undef dgettext
+#undef dcgettext
+#undef textdomain
+#undef bindtextdomain
+
+
+char *
+bindtextdomain (domainname, dirname)
+     const char *domainname;
+     const char *dirname;
+{
+  return bindtextdomain__ (domainname, dirname);
+}
+
+
+char *
+dcgettext (domainname, msgid, category)
+     const char *domainname;
+     const char *msgid;
+     int category;
+{
+  return dcgettext__ (domainname, msgid, category);
+}
+
+
+char *
+dgettext (domainname, msgid)
+     const char *domainname;
+     const char *msgid;
+{
+  return dgettext__ (domainname, msgid);
+}
+
+
+char *
+gettext (msgid)
+     const char *msgid;
+{
+  return gettext__ (msgid);
+}
+
+
+char *
+textdomain (domainname)
+     const char *domainname;
+{
+  return textdomain__ (domainname);
+}
diff --git a/intl/l10nflist.c b/intl/l10nflist.c
new file mode 100644
index 00000000..9c7dc183
--- /dev/null
+++ b/intl/l10nflist.c
@@ -0,0 +1,411 @@
+/* Handle list of needed message catalogs
+   Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
+   Contributed by Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+
+#if defined HAVE_STRING_H || defined _LIBC
+# ifndef _GNU_SOURCE
+#  define _GNU_SOURCE	1
+# endif
+# include <string.h>
+#else
+# include <strings.h>
+# ifndef memcpy
+#  define memcpy(Dst, Src, Num) bcopy (Src, Dst, Num)
+# endif
+#endif
+#if !HAVE_STRCHR && !defined _LIBC
+# ifndef strchr
+#  define strchr index
+# endif
+#endif
+
+#if defined _LIBC || defined HAVE_ARGZ_H
+# include <argz.h>
+#endif
+#include <ctype.h>
+#include <sys/types.h>
+
+#if defined STDC_HEADERS || defined _LIBC
+# include <stdlib.h>
+#endif
+
+#include "loadinfo.h"
+
+/* On some strange systems still no definition of NULL is found.  Sigh!  */
+#ifndef NULL
+# if defined __STDC__ && __STDC__
+#  define NULL ((void *) 0)
+# else
+#  define NULL 0
+# endif
+#endif
+
+/* @@ end of prolog @@ */
+
+#ifdef _LIBC
+/* Rename the non ANSI C functions.  This is required by the standard
+   because some ANSI C functions will require linking with this object
+   file and the name space must not be polluted.  */
+# ifndef stpcpy
+#  define stpcpy(dest, src) __stpcpy(dest, src)
+# endif
+#else
+# ifndef HAVE_STPCPY
+static char *stpcpy PARAMS ((char *dest, const char *src));
+# endif
+#endif
+
+/* Define function which are usually not available.  */
+
+#if !defined _LIBC && !defined HAVE___ARGZ_COUNT
+/* Returns the number of strings in ARGZ.  */
+static size_t argz_count__ PARAMS ((const char *argz, size_t len));
+
+static size_t
+argz_count__ (argz, len)
+     const char *argz;
+     size_t len;
+{
+  size_t count = 0;
+  while (len > 0)
+    {
+      size_t part_len = strlen (argz);
+      argz += part_len + 1;
+      len -= part_len + 1;
+      count++;
+    }
+  return count;
+}
+# undef __argz_count
+# define __argz_count(argz, len) argz_count__ (argz, len)
+#endif	/* !_LIBC && !HAVE___ARGZ_COUNT */
+
+#if !defined _LIBC && !defined HAVE___ARGZ_STRINGIFY
+/* Make '\0' separated arg vector ARGZ printable by converting all the '\0's
+   except the last into the character SEP.  */
+static void argz_stringify__ PARAMS ((char *argz, size_t len, int sep));
+
+static void
+argz_stringify__ (argz, len, sep)
+     char *argz;
+     size_t len;
+     int sep;
+{
+  while (len > 0)
+    {
+      size_t part_len = strlen (argz);
+      argz += part_len;
+      len -= part_len + 1;
+      if (len > 0)
+	*argz++ = sep;
+    }
+}
+# undef __argz_stringify
+# define __argz_stringify(argz, len, sep) argz_stringify__ (argz, len, sep)
+#endif	/* !_LIBC && !HAVE___ARGZ_STRINGIFY */
+
+#if !defined _LIBC && !defined HAVE___ARGZ_NEXT
+static char *argz_next__ PARAMS ((char *argz, size_t argz_len,
+				  const char *entry));
+
+static char *
+argz_next__ (argz, argz_len, entry)
+     char *argz;
+     size_t argz_len;
+     const char *entry;
+{
+  if (entry)
+    {
+      if (entry < argz + argz_len)
+        entry = strchr (entry, '\0') + 1;
+
+      return entry >= argz + argz_len ? NULL : (char *) entry;
+    }
+  else
+    if (argz_len > 0)
+      return argz;
+    else
+      return 0;
+}
+# undef __argz_next
+# define __argz_next(argz, len, entry) argz_next__ (argz, len, entry)
+#endif	/* !_LIBC && !HAVE___ARGZ_NEXT */
+
+
+/* Return number of bits set in X.  */
+static int pop PARAMS ((int x));
+
+static inline int
+pop (x)
+     int x;
+{
+  /* We assume that no more than 16 bits are used.  */
+  x = ((x & ~0x5555) >> 1) + (x & 0x5555);
+  x = ((x & ~0x3333) >> 2) + (x & 0x3333);
+  x = ((x >> 4) + x) & 0x0f0f;
+  x = ((x >> 8) + x) & 0xff;
+
+  return x;
+}
+
+
+struct loaded_l10nfile *
+_nl_make_l10nflist (l10nfile_list, dirlist, dirlist_len, mask, language,
+		    territory, codeset, normalized_codeset, modifier, special,
+		    sponsor, revision, filename, do_allocate)
+     struct loaded_l10nfile **l10nfile_list;
+     const char *dirlist;
+     size_t dirlist_len;
+     int mask;
+     const char *language;
+     const char *territory;
+     const char *codeset;
+     const char *normalized_codeset;
+     const char *modifier;
+     const char *special;
+     const char *sponsor;
+     const char *revision;
+     const char *filename;
+     int do_allocate;
+{
+  char *abs_filename;
+  struct loaded_l10nfile *last = NULL;
+  struct loaded_l10nfile *retval;
+  char *cp;
+  size_t entries;
+  int cnt;
+
+  /* Allocate room for the full file name.  */
+  abs_filename = (char *) malloc (dirlist_len
+				  + strlen (language)
+				  + ((mask & TERRITORY) != 0
+				     ? strlen (territory) + 1 : 0)
+				  + ((mask & XPG_CODESET) != 0
+				     ? strlen (codeset) + 1 : 0)
+				  + ((mask & XPG_NORM_CODESET) != 0
+				     ? strlen (normalized_codeset) + 1 : 0)
+				  + (((mask & XPG_MODIFIER) != 0
+				      || (mask & CEN_AUDIENCE) != 0)
+				     ? strlen (modifier) + 1 : 0)
+				  + ((mask & CEN_SPECIAL) != 0
+				     ? strlen (special) + 1 : 0)
+				  + (((mask & CEN_SPONSOR) != 0
+				      || (mask & CEN_REVISION) != 0)
+				     ? (1 + ((mask & CEN_SPONSOR) != 0
+					     ? strlen (sponsor) + 1 : 0)
+					+ ((mask & CEN_REVISION) != 0
+					   ? strlen (revision) + 1 : 0)) : 0)
+				  + 1 + strlen (filename) + 1);
+
+  if (abs_filename == NULL)
+    return NULL;
+
+  retval = NULL;
+  last = NULL;
+
+  /* Construct file name.  */
+  memcpy (abs_filename, dirlist, dirlist_len);
+  __argz_stringify (abs_filename, dirlist_len, ':');
+  cp = abs_filename + (dirlist_len - 1);
+  *cp++ = '/';
+  cp = stpcpy (cp, language);
+
+  if ((mask & TERRITORY) != 0)
+    {
+      *cp++ = '_';
+      cp = stpcpy (cp, territory);
+    }
+  if ((mask & XPG_CODESET) != 0)
+    {
+      *cp++ = '.';
+      cp = stpcpy (cp, codeset);
+    }
+  if ((mask & XPG_NORM_CODESET) != 0)
+    {
+      *cp++ = '.';
+      cp = stpcpy (cp, normalized_codeset);
+    }
+  if ((mask & (XPG_MODIFIER | CEN_AUDIENCE)) != 0)
+    {
+      /* This component can be part of both syntaces but has different
+	 leading characters.  For CEN we use `+', else `@'.  */
+      *cp++ = (mask & CEN_AUDIENCE) != 0 ? '+' : '@';
+      cp = stpcpy (cp, modifier);
+    }
+  if ((mask & CEN_SPECIAL) != 0)
+    {
+      *cp++ = '+';
+      cp = stpcpy (cp, special);
+    }
+  if ((mask & (CEN_SPONSOR | CEN_REVISION)) != 0)
+    {
+      *cp++ = ',';
+      if ((mask & CEN_SPONSOR) != 0)
+	cp = stpcpy (cp, sponsor);
+      if ((mask & CEN_REVISION) != 0)
+	{
+	  *cp++ = '_';
+	  cp = stpcpy (cp, revision);
+	}
+    }
+
+  *cp++ = '/';
+  stpcpy (cp, filename);
+
+  /* Look in list of already loaded domains whether it is already
+     available.  */
+  last = NULL;
+  for (retval = *l10nfile_list; retval != NULL; retval = retval->next)
+    if (retval->filename != NULL)
+      {
+	int compare = strcmp (retval->filename, abs_filename);
+	if (compare == 0)
+	  /* We found it!  */
+	  break;
+	if (compare < 0)
+	  {
+	    /* It's not in the list.  */
+	    retval = NULL;
+	    break;
+	  }
+
+	last = retval;
+      }
+
+  if (retval != NULL || do_allocate == 0)
+    {
+      free (abs_filename);
+      return retval;
+    }
+
+  retval = (struct loaded_l10nfile *)
+    malloc (sizeof (*retval) + (__argz_count (dirlist, dirlist_len)
+				* (1 << pop (mask))
+				* sizeof (struct loaded_l10nfile *)));
+  if (retval == NULL)
+    return NULL;
+
+  retval->filename = abs_filename;
+  retval->decided = (__argz_count (dirlist, dirlist_len) != 1
+		     || ((mask & XPG_CODESET) != 0
+			 && (mask & XPG_NORM_CODESET) != 0));
+  retval->data = NULL;
+
+  if (last == NULL)
+    {
+      retval->next = *l10nfile_list;
+      *l10nfile_list = retval;
+    }
+  else
+    {
+      retval->next = last->next;
+      last->next = retval;
+    }
+
+  entries = 0;
+  /* If the DIRLIST is a real list the RETVAL entry corresponds not to
+     a real file.  So we have to use the DIRLIST separation mechanism
+     of the inner loop.  */
+  cnt = __argz_count (dirlist, dirlist_len) == 1 ? mask - 1 : mask;
+  for (; cnt >= 0; --cnt)
+    if ((cnt & ~mask) == 0
+	&& ((cnt & CEN_SPECIFIC) == 0 || (cnt & XPG_SPECIFIC) == 0)
+	&& ((cnt & XPG_CODESET) == 0 || (cnt & XPG_NORM_CODESET) == 0))
+      {
+	/* Iterate over all elements of the DIRLIST.  */
+	char *dir = NULL;
+
+	while ((dir = __argz_next ((char *) dirlist, dirlist_len, dir))
+	       != NULL)
+	  retval->successor[entries++]
+	    = _nl_make_l10nflist (l10nfile_list, dir, strlen (dir) + 1, cnt,
+				  language, territory, codeset,
+				  normalized_codeset, modifier, special,
+				  sponsor, revision, filename, 1);
+      }
+  retval->successor[entries] = NULL;
+
+  return retval;
+}
+
+/* Normalize codeset name.  There is no standard for the codeset
+   names.  Normalization allows the user to use any of the common
+   names.  */
+const char *
+_nl_normalize_codeset (codeset, name_len)
+     const unsigned char *codeset;
+     size_t name_len;
+{
+  int len = 0;
+  int only_digit = 1;
+  char *retval;
+  char *wp;
+  size_t cnt;
+
+  for (cnt = 0; cnt < name_len; ++cnt)
+    if (isalnum (codeset[cnt]))
+      {
+	++len;
+
+	if (isalpha (codeset[cnt]))
+	  only_digit = 0;
+      }
+
+  retval = (char *) malloc ((only_digit ? 3 : 0) + len + 1);
+
+  if (retval != NULL)
+    {
+      if (only_digit)
+	wp = stpcpy (retval, "iso");
+      else
+	wp = retval;
+
+      for (cnt = 0; cnt < name_len; ++cnt)
+	if (isalpha (codeset[cnt]))
+	  *wp++ = tolower (codeset[cnt]);
+	else if (isdigit (codeset[cnt]))
+	  *wp++ = codeset[cnt];
+
+      *wp = '\0';
+    }
+
+  return (const char *) retval;
+}
+
+
+/* @@ begin of epilog @@ */
+
+/* We don't want libintl.a to depend on any other library.  So we
+   avoid the non-standard function stpcpy.  In GNU C Library this
+   function is available, though.  Also allow the symbol HAVE_STPCPY
+   to be defined.  */
+#if !_LIBC && !HAVE_STPCPY
+static char *
+stpcpy (dest, src)
+     char *dest;
+     const char *src;
+{
+  while ((*dest++ = *src++) != '\0')
+    /* Do nothing. */ ;
+  return dest - 1;
+}
+#endif
diff --git a/intl/libgettext.h b/intl/libgettext.h
new file mode 100644
index 00000000..3a92960a
--- /dev/null
+++ b/intl/libgettext.h
@@ -0,0 +1,182 @@
+/* Message catalogs for internationalization.
+   Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+/* Because on some systems (e.g. Solaris) we sometimes have to include
+   the systems libintl.h as well as this file we have more complex
+   include protection above.  But the systems header might perhaps also
+   define _LIBINTL_H and therefore we have to protect the definition here.  */
+
+#if !defined _LIBINTL_H || !defined _LIBGETTEXT_H
+#ifndef _LIBINTL_H
+# define _LIBINTL_H	1
+#endif
+#define _LIBGETTEXT_H	1
+
+/* We define an additional symbol to signal that we use the GNU
+   implementation of gettext.  */
+#define __USE_GNU_GETTEXT 1
+
+#include <sys/types.h>
+
+#if HAVE_LOCALE_H
+# include <locale.h>
+#endif
+
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* @@ end of prolog @@ */
+
+#ifndef PARAMS
+# if __STDC__ || defined __cplusplus
+#  define PARAMS(args) args
+# else
+#  define PARAMS(args) ()
+# endif
+#endif
+
+#ifndef NULL
+# if !defined __cplusplus || defined __GNUC__
+#  define NULL ((void *) 0)
+# else
+#  define NULL (0)
+# endif
+#endif
+
+#if !HAVE_LC_MESSAGES
+/* This value determines the behaviour of the gettext() and dgettext()
+   function.  But some system does not have this defined.  Define it
+   to a default value.  */
+# define LC_MESSAGES (-1)
+#endif
+
+
+/* Declarations for gettext-using-catgets interface.  Derived from
+   Jim Meyering's libintl.h.  */
+struct _msg_ent
+{
+  const char *_msg;
+  int _msg_number;
+};
+
+
+#if HAVE_CATGETS
+/* These two variables are defined in the automatically by po-to-tbl.sed
+   generated file `cat-id-tbl.c'.  */
+extern const struct _msg_ent _msg_tbl[];
+extern int _msg_tbl_length;
+#endif
+
+
+/* For automatical extraction of messages sometimes no real
+   translation is needed.  Instead the string itself is the result.  */
+#define gettext_noop(Str) (Str)
+
+/* Look up MSGID in the current default message catalog for the current
+   LC_MESSAGES locale.  If not found, returns MSGID itself (the default
+   text).  */
+extern char *gettext PARAMS ((const char *__msgid));
+extern char *gettext__ PARAMS ((const char *__msgid));
+
+/* Look up MSGID in the DOMAINNAME message catalog for the current
+   LC_MESSAGES locale.  */
+extern char *dgettext PARAMS ((const char *__domainname, const char *__msgid));
+extern char *dgettext__ PARAMS ((const char *__domainname,
+				 const char *__msgid));
+
+/* Look up MSGID in the DOMAINNAME message catalog for the current CATEGORY
+   locale.  */
+extern char *dcgettext PARAMS ((const char *__domainname, const char *__msgid,
+				int __category));
+extern char *dcgettext__ PARAMS ((const char *__domainname,
+				  const char *__msgid, int __category));
+
+
+/* Set the current default message catalog to DOMAINNAME.
+   If DOMAINNAME is null, return the current default.
+   If DOMAINNAME is "", reset to the default of "messages".  */
+extern char *textdomain PARAMS ((const char *__domainname));
+extern char *textdomain__ PARAMS ((const char *__domainname));
+
+/* Specify that the DOMAINNAME message catalog will be found
+   in DIRNAME rather than in the system locale data base.  */
+extern char *bindtextdomain PARAMS ((const char *__domainname,
+				  const char *__dirname));
+extern char *bindtextdomain__ PARAMS ((const char *__domainname,
+				    const char *__dirname));
+
+#if ENABLE_NLS
+
+/* Solaris 2.3 has the gettext function but dcgettext is missing.
+   So we omit this optimization for Solaris 2.3.  BTW, Solaris 2.4
+   has dcgettext.  */
+# if !HAVE_CATGETS && (!HAVE_GETTEXT || HAVE_DCGETTEXT)
+
+#  define gettext(Msgid)						      \
+     dgettext (NULL, Msgid)
+
+#  define dgettext(Domainname, Msgid)					      \
+     dcgettext (Domainname, Msgid, LC_MESSAGES)
+
+#  if defined __GNUC__ && __GNUC__ == 2 && __GNUC_MINOR__ >= 7
+/* This global variable is defined in loadmsgcat.c.  We need a sign,
+   whether a new catalog was loaded, which can be associated with all
+   translations.  */
+extern int _nl_msg_cat_cntr;
+
+#   define dcgettext(Domainname, Msgid, Category)			      \
+  (__extension__							      \
+   ({									      \
+     char *__result;							      \
+     if (__builtin_constant_p (Msgid))					      \
+       {								      \
+	 static char *__translation__;					      \
+	 static int __catalog_counter__;				      \
+	 if (! __translation__ || __catalog_counter__ != _nl_msg_cat_cntr)    \
+	   {								      \
+	     __translation__ =						      \
+	       dcgettext__ (Domainname, Msgid, Category);		      \
+	     __catalog_counter__ = _nl_msg_cat_cntr;			      \
+	   }								      \
+	 __result = __translation__;					      \
+       }								      \
+     else								      \
+       __result = dcgettext__ (Domainname, Msgid, Category);		      \
+     __result;								      \
+    }))
+#  endif
+# endif
+
+#else
+
+# define gettext(Msgid) (Msgid)
+# define dgettext(Domainname, Msgid) (Msgid)
+# define dcgettext(Domainname, Msgid, Category) (Msgid)
+# define textdomain(Domainname) ((char *) Domainname)
+# define bindtextdomain(Domainname, Dirname) ((char *) Dirname)
+
+#endif
+
+/* @@ begin of epilog @@ */
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/intl/linux-msg.sed b/intl/linux-msg.sed
new file mode 100644
index 00000000..5918e720
--- /dev/null
+++ b/intl/linux-msg.sed
@@ -0,0 +1,100 @@
+# po2msg.sed - Convert Uniforum style .po file to Linux style .msg file
+# Copyright (C) 1995 Free Software Foundation, Inc.
+# Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+#
+# The first directive in the .msg should be the definition of the
+# message set number.  We use always set number 1.
+#
+1 {
+  i\
+$set 1 # Automatically created by po2msg.sed
+  h
+  s/.*/0/
+  x
+}
+#
+# Mitch's old catalog format does not allow comments.
+#
+# We copy the original message as a comment into the .msg file.
+#
+/^msgid/ {
+  s/msgid[ 	]*"//
+#
+# This does not work now with the new format.
+# /"$/! {
+#   s/\\$//
+#   s/$/ ... (more lines following)"/
+# }
+  x
+# The following nice solution is by
+# Bruno <Haible@ma2s2.mathematik.uni-karlsruhe.de>
+  td
+# Increment a decimal number in pattern space.
+# First hide trailing `9' digits.
+  :d
+  s/9\(_*\)$/_\1/
+  td
+# Assure at least one digit is available.
+  s/^\(_*\)$/0\1/
+# Increment the last digit.
+  s/8\(_*\)$/9\1/
+  s/7\(_*\)$/8\1/
+  s/6\(_*\)$/7\1/
+  s/5\(_*\)$/6\1/
+  s/4\(_*\)$/5\1/
+  s/3\(_*\)$/4\1/
+  s/2\(_*\)$/3\1/
+  s/1\(_*\)$/2\1/
+  s/0\(_*\)$/1\1/
+# Convert the hidden `9' digits to `0's.
+  s/_/0/g
+  x
+  G
+  s/\(.*\)"\n\([0-9]*\)/$ #\2 Original Message:(\1)/p
+}
+#
+# The .msg file contains, other then the .po file, only the translations
+# but each given a unique ID.  Starting from 1 and incrementing by 1 for
+# each message we assign them to the messages.
+# It is important that the .po file used to generate the cat-id-tbl.c file
+# (with po-to-tbl) is the same as the one used here.  (At least the order
+# of declarations must not be changed.)
+#
+/^msgstr/ {
+  s/msgstr[ 	]*"\(.*\)"/# \1/
+# Clear substitution flag.
+  tb
+# Append the next line.
+  :b
+  N
+# Look whether second part is continuation line.
+  s/\(.*\n\)"\(.*\)"/\1\2/
+# Yes, then branch.
+  ta
+  P
+  D
+# Note that D includes a jump to the start!!
+# We found a continuation line.  But before printing insert '\'.
+  :a
+  s/\(.*\)\(\n.*\)/\1\\\2/
+  P
+# We cannot use D here.
+  s/.*\n\(.*\)/\1/
+  tb
+}
+d
diff --git a/intl/loadinfo.h b/intl/loadinfo.h
new file mode 100644
index 00000000..f4ebf6d8
--- /dev/null
+++ b/intl/loadinfo.h
@@ -0,0 +1,76 @@
+/* Copyright (C) 1996, 1997 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+   Contributed by Ulrich Drepper <drepper@cygnus.com>, 1996.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifndef PARAMS
+# if __STDC__
+#  define PARAMS(args) args
+# else
+#  define PARAMS(args) ()
+# endif
+#endif
+
+/* Encoding of locale name parts.  */
+#define CEN_REVISION		1
+#define CEN_SPONSOR		2
+#define CEN_SPECIAL		4
+#define XPG_NORM_CODESET	8
+#define XPG_CODESET		16
+#define TERRITORY		32
+#define CEN_AUDIENCE		64
+#define XPG_MODIFIER		128
+
+#define CEN_SPECIFIC	(CEN_REVISION|CEN_SPONSOR|CEN_SPECIAL|CEN_AUDIENCE)
+#define XPG_SPECIFIC	(XPG_CODESET|XPG_NORM_CODESET|XPG_MODIFIER)
+
+
+struct loaded_l10nfile
+{
+  const char *filename;
+  int decided;
+
+  const void *data;
+
+  struct loaded_l10nfile *next;
+  struct loaded_l10nfile *successor[1];
+};
+
+
+extern const char *_nl_normalize_codeset PARAMS ((const unsigned char *codeset,
+						  size_t name_len));
+
+extern struct loaded_l10nfile *
+_nl_make_l10nflist PARAMS ((struct loaded_l10nfile **l10nfile_list,
+			    const char *dirlist, size_t dirlist_len, int mask,
+			    const char *language, const char *territory,
+			    const char *codeset,
+			    const char *normalized_codeset,
+			    const char *modifier, const char *special,
+			    const char *sponsor, const char *revision,
+			    const char *filename, int do_allocate));
+
+
+extern const char *_nl_expand_alias PARAMS ((const char *name));
+
+extern int _nl_explode_name PARAMS ((char *name, const char **language,
+				     const char **modifier,
+				     const char **territory,
+				     const char **codeset,
+				     const char **normalized_codeset,
+				     const char **special,
+				     const char **sponsor,
+				     const char **revision));
diff --git a/intl/loadmsgcat.c b/intl/loadmsgcat.c
new file mode 100644
index 00000000..515892df
--- /dev/null
+++ b/intl/loadmsgcat.c
@@ -0,0 +1,222 @@
+/* Load needed message catalogs.
+   Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#include <fcntl.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+
+#if defined STDC_HEADERS || defined _LIBC
+# include <stdlib.h>
+#endif
+
+#if defined HAVE_UNISTD_H || defined _LIBC
+# include <unistd.h>
+#endif
+
+#if (defined HAVE_MMAP && defined HAVE_MUNMAP) || defined _LIBC
+# include <sys/mman.h>
+#endif
+
+#include "gettext.h"
+#include "gettextP.h"
+
+/* @@ end of prolog @@ */
+
+#ifdef _LIBC
+/* Rename the non ISO C functions.  This is required by the standard
+   because some ISO C functions will require linking with this object
+   file and the name space must not be polluted.  */
+# define open   __open
+# define close  __close
+# define read   __read
+# define mmap   __mmap
+# define munmap __munmap
+#endif
+
+/* We need a sign, whether a new catalog was loaded, which can be associated
+   with all translations.  This is important if the translations are
+   cached by one of GCC's features.  */
+int _nl_msg_cat_cntr = 0;
+
+
+/* Load the message catalogs specified by FILENAME.  If it is no valid
+   message catalog do nothing.  */
+void
+internal_function
+_nl_load_domain (domain_file)
+     struct loaded_l10nfile *domain_file;
+{
+  int fd;
+  size_t size;
+  struct stat st;
+  struct mo_file_header *data = (struct mo_file_header *) -1;
+#if (defined HAVE_MMAP && defined HAVE_MUNMAP && !defined DISALLOW_MMAP) \
+    || defined _LIBC
+  int use_mmap = 0;
+#endif
+  struct loaded_domain *domain;
+
+  domain_file->decided = 1;
+  domain_file->data = NULL;
+
+  /* If the record does not represent a valid locale the FILENAME
+     might be NULL.  This can happen when according to the given
+     specification the locale file name is different for XPG and CEN
+     syntax.  */
+  if (domain_file->filename == NULL)
+    return;
+
+  /* Try to open the addressed file.  */
+  fd = open (domain_file->filename, O_RDONLY);
+  if (fd == -1)
+    return;
+
+  /* We must know about the size of the file.  */
+  if (fstat (fd, &st) != 0
+      || (size = (size_t) st.st_size) != st.st_size
+      || size < sizeof (struct mo_file_header))
+    {
+      /* Something went wrong.  */
+      close (fd);
+      return;
+    }
+
+#if (defined HAVE_MMAP && defined HAVE_MUNMAP && !defined DISALLOW_MMAP) \
+    || defined _LIBC
+  /* Now we are ready to load the file.  If mmap() is available we try
+     this first.  If not available or it failed we try to load it.  */
+  data = (struct mo_file_header *) mmap (NULL, size, PROT_READ,
+					 MAP_PRIVATE, fd, 0);
+
+  if (data != (struct mo_file_header *) -1)
+    {
+      /* mmap() call was successful.  */
+      close (fd);
+      use_mmap = 1;
+    }
+#endif
+
+  /* If the data is not yet available (i.e. mmap'ed) we try to load
+     it manually.  */
+  if (data == (struct mo_file_header *) -1)
+    {
+      size_t to_read;
+      char *read_ptr;
+
+      data = (struct mo_file_header *) malloc (size);
+      if (data == NULL)
+	return;
+
+      to_read = size;
+      read_ptr = (char *) data;
+      do
+	{
+	  long int nb = (long int) read (fd, read_ptr, to_read);
+	  if (nb == -1)
+	    {
+	      close (fd);
+	      return;
+	    }
+
+	  read_ptr += nb;
+	  to_read -= nb;
+	}
+      while (to_read > 0);
+
+      close (fd);
+    }
+
+  /* Using the magic number we can test whether it really is a message
+     catalog file.  */
+  if (data->magic != _MAGIC && data->magic != _MAGIC_SWAPPED)
+    {
+      /* The magic number is wrong: not a message catalog file.  */
+#if (defined HAVE_MMAP && defined HAVE_MUNMAP && !defined DISALLOW_MMAP) \
+    || defined _LIBC
+      if (use_mmap)
+	munmap ((caddr_t) data, size);
+      else
+#endif
+	free (data);
+      return;
+    }
+
+  domain_file->data
+    = (struct loaded_domain *) malloc (sizeof (struct loaded_domain));
+  if (domain_file->data == NULL)
+    return;
+
+  domain = (struct loaded_domain *) domain_file->data;
+  domain->data = (char *) data;
+#if (defined HAVE_MMAP && defined HAVE_MUNMAP && !defined DISALLOW_MMAP) \
+    || defined _LIBC
+  domain->use_mmap = use_mmap;
+#endif
+  domain->mmap_size = size;
+  domain->must_swap = data->magic != _MAGIC;
+
+  /* Fill in the information about the available tables.  */
+  switch (W (domain->must_swap, data->revision))
+    {
+    case 0:
+      domain->nstrings = W (domain->must_swap, data->nstrings);
+      domain->orig_tab = (struct string_desc *)
+	((char *) data + W (domain->must_swap, data->orig_tab_offset));
+      domain->trans_tab = (struct string_desc *)
+	((char *) data + W (domain->must_swap, data->trans_tab_offset));
+      domain->hash_size = W (domain->must_swap, data->hash_tab_size);
+      domain->hash_tab = (nls_uint32 *)
+	((char *) data + W (domain->must_swap, data->hash_tab_offset));
+      break;
+    default:
+      /* This is an illegal revision.  */
+#if (defined HAVE_MMAP && defined HAVE_MUNMAP && !defined DISALLOW_MMAP) \
+    || defined _LIBC
+      if (use_mmap)
+	munmap ((caddr_t) data, size);
+      else
+#endif
+	free (data);
+      free (domain);
+      domain_file->data = NULL;
+      return;
+    }
+
+  /* Show that one domain is changed.  This might make some cached
+     translations invalid.  */
+  ++_nl_msg_cat_cntr;
+}
+
+
+#ifdef _LIBC
+void
+internal_function
+_nl_unload_domain (domain)
+     struct loaded_domain *domain;
+{
+  if (domain->use_mmap)
+    munmap ((caddr_t) domain->data, domain->mmap_size);
+  else
+    free ((void *) domain->data);
+
+  free (domain);
+}
+#endif
diff --git a/intl/localealias.c b/intl/localealias.c
new file mode 100644
index 00000000..bca555a6
--- /dev/null
+++ b/intl/localealias.c
@@ -0,0 +1,424 @@
+/* Handle aliases for locale names.
+   Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+   Written by Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#include <ctype.h>
+#include <stdio.h>
+#include <sys/types.h>
+
+#ifdef __GNUC__
+# define alloca __builtin_alloca
+# define HAVE_ALLOCA 1
+#else
+# if defined HAVE_ALLOCA_H || defined _LIBC
+#  include <alloca.h>
+# else
+#  ifdef _AIX
+ #pragma alloca
+#  else
+#   ifndef alloca
+char *alloca ();
+#   endif
+#  endif
+# endif
+#endif
+
+#if defined STDC_HEADERS || defined _LIBC
+# include <stdlib.h>
+#else
+char *getenv ();
+# ifdef HAVE_MALLOC_H
+#  include <malloc.h>
+# else
+void free ();
+# endif
+#endif
+
+#if defined HAVE_STRING_H || defined _LIBC
+# ifndef _GNU_SOURCE
+#  define _GNU_SOURCE	1
+# endif
+# include <string.h>
+#else
+# include <strings.h>
+# ifndef memcpy
+#  define memcpy(Dst, Src, Num) bcopy (Src, Dst, Num)
+# endif
+#endif
+#if !HAVE_STRCHR && !defined _LIBC
+# ifndef strchr
+#  define strchr index
+# endif
+#endif
+
+#include "gettext.h"
+#include "gettextP.h"
+
+/* @@ end of prolog @@ */
+
+#ifdef _LIBC
+/* Rename the non ANSI C functions.  This is required by the standard
+   because some ANSI C functions will require linking with this object
+   file and the name space must not be polluted.  */
+# define strcasecmp __strcasecmp
+
+# define mempcpy __mempcpy
+# define HAVE_MEMPCPY	1
+
+/* We need locking here since we can be called from different places.  */
+# include <bits/libc-lock.h>
+
+__libc_lock_define_initialized (static, lock);
+#endif
+
+
+/* For those loosing systems which don't have `alloca' we have to add
+   some additional code emulating it.  */
+#ifdef HAVE_ALLOCA
+/* Nothing has to be done.  */
+# define ADD_BLOCK(list, address) /* nothing */
+# define FREE_BLOCKS(list) /* nothing */
+#else
+struct block_list
+{
+  void *address;
+  struct block_list *next;
+};
+# define ADD_BLOCK(list, addr)						      \
+  do {									      \
+    struct block_list *newp = (struct block_list *) malloc (sizeof (*newp));  \
+    /* If we cannot get a free block we cannot add the new element to	      \
+       the list.  */							      \
+    if (newp != NULL) {							      \
+      newp->address = (addr);						      \
+      newp->next = (list);						      \
+      (list) = newp;							      \
+    }									      \
+  } while (0)
+# define FREE_BLOCKS(list)						      \
+  do {									      \
+    while (list != NULL) {						      \
+      struct block_list *old = list;					      \
+      list = list->next;						      \
+      free (old);							      \
+    }									      \
+  } while (0)
+# undef alloca
+# define alloca(size) (malloc (size))
+#endif	/* have alloca */
+
+
+struct alias_map
+{
+  const char *alias;
+  const char *value;
+};
+
+
+static char *string_space = NULL;
+static size_t string_space_act = 0;
+static size_t string_space_max = 0;
+static struct alias_map *map;
+static size_t nmap = 0;
+static size_t maxmap = 0;
+
+
+/* Prototypes for local functions.  */
+static size_t read_alias_file PARAMS ((const char *fname, int fname_len))
+     internal_function;
+static void extend_alias_table PARAMS ((void));
+static int alias_compare PARAMS ((const struct alias_map *map1,
+				  const struct alias_map *map2));
+
+
+const char *
+_nl_expand_alias (name)
+    const char *name;
+{
+  static const char *locale_alias_path = LOCALE_ALIAS_PATH;
+  struct alias_map *retval;
+  const char *result = NULL;
+  size_t added;
+
+#ifdef _LIBC
+  __libc_lock_lock (lock);
+#endif
+
+  do
+    {
+      struct alias_map item;
+
+      item.alias = name;
+
+      if (nmap > 0)
+	retval = (struct alias_map *) bsearch (&item, map, nmap,
+					       sizeof (struct alias_map),
+					       (int (*) PARAMS ((const void *,
+								 const void *))
+						) alias_compare);
+      else
+	retval = NULL;
+
+      /* We really found an alias.  Return the value.  */
+      if (retval != NULL)
+	{
+	  result = retval->value;
+	  break;
+	}
+
+      /* Perhaps we can find another alias file.  */
+      added = 0;
+      while (added == 0 && locale_alias_path[0] != '\0')
+	{
+	  const char *start;
+
+	  while (locale_alias_path[0] == ':')
+	    ++locale_alias_path;
+	  start = locale_alias_path;
+
+	  while (locale_alias_path[0] != '\0' && locale_alias_path[0] != ':')
+	    ++locale_alias_path;
+
+	  if (start < locale_alias_path)
+	    added = read_alias_file (start, locale_alias_path - start);
+	}
+    }
+  while (added != 0);
+
+#ifdef _LIBC
+  __libc_lock_unlock (lock);
+#endif
+
+  return result;
+}
+
+
+static size_t
+internal_function
+read_alias_file (fname, fname_len)
+     const char *fname;
+     int fname_len;
+{
+#ifndef HAVE_ALLOCA
+  struct block_list *block_list = NULL;
+#endif
+  FILE *fp;
+  char *full_fname;
+  size_t added;
+  static const char aliasfile[] = "/locale.alias";
+
+  full_fname = (char *) alloca (fname_len + sizeof aliasfile);
+  ADD_BLOCK (block_list, full_fname);
+#ifdef HAVE_MEMPCPY
+  mempcpy (mempcpy (full_fname, fname, fname_len),
+	   aliasfile, sizeof aliasfile);
+#else
+  memcpy (full_fname, fname, fname_len);
+  memcpy (&full_fname[fname_len], aliasfile, sizeof aliasfile);
+#endif
+
+  fp = fopen (full_fname, "r");
+  if (fp == NULL)
+    {
+      FREE_BLOCKS (block_list);
+      return 0;
+    }
+
+  added = 0;
+  while (!feof (fp))
+    {
+      /* It is a reasonable approach to use a fix buffer here because
+	 a) we are only interested in the first two fields
+	 b) these fields must be usable as file names and so must not
+	    be that long
+       */
+      unsigned char buf[BUFSIZ];
+      unsigned char *alias;
+      unsigned char *value;
+      unsigned char *cp;
+
+      if (fgets (buf, sizeof buf, fp) == NULL)
+	/* EOF reached.  */
+	break;
+
+      /* Possibly not the whole line fits into the buffer.  Ignore
+	 the rest of the line.  */
+      if (strchr (buf, '\n') == NULL)
+	{
+	  char altbuf[BUFSIZ];
+	  do
+	    if (fgets (altbuf, sizeof altbuf, fp) == NULL)
+	      /* Make sure the inner loop will be left.  The outer loop
+		 will exit at the `feof' test.  */
+	      break;
+	  while (strchr (altbuf, '\n') == NULL);
+	}
+
+      cp = buf;
+      /* Ignore leading white space.  */
+      while (isspace (cp[0]))
+	++cp;
+
+      /* A leading '#' signals a comment line.  */
+      if (cp[0] != '\0' && cp[0] != '#')
+	{
+	  alias = cp++;
+	  while (cp[0] != '\0' && !isspace (cp[0]))
+	    ++cp;
+	  /* Terminate alias name.  */
+	  if (cp[0] != '\0')
+	    *cp++ = '\0';
+
+	  /* Now look for the beginning of the value.  */
+	  while (isspace (cp[0]))
+	    ++cp;
+
+	  if (cp[0] != '\0')
+	    {
+	      size_t alias_len;
+	      size_t value_len;
+
+	      value = cp++;
+	      while (cp[0] != '\0' && !isspace (cp[0]))
+		++cp;
+	      /* Terminate value.  */
+	      if (cp[0] == '\n')
+		{
+		  /* This has to be done to make the following test
+		     for the end of line possible.  We are looking for
+		     the terminating '\n' which do not overwrite here.  */
+		  *cp++ = '\0';
+		  *cp = '\n';
+		}
+	      else if (cp[0] != '\0')
+		*cp++ = '\0';
+
+	      if (nmap >= maxmap)
+		extend_alias_table ();
+
+	      alias_len = strlen (alias) + 1;
+	      value_len = strlen (value) + 1;
+
+	      if (string_space_act + alias_len + value_len > string_space_max)
+		{
+		  /* Increase size of memory pool.  */
+		  size_t new_size = (string_space_max
+				     + (alias_len + value_len > 1024
+					? alias_len + value_len : 1024));
+		  char *new_pool = (char *) realloc (string_space, new_size);
+		  if (new_pool == NULL)
+		    {
+		      FREE_BLOCKS (block_list);
+		      return added;
+		    }
+		  string_space = new_pool;
+		  string_space_max = new_size;
+		}
+
+	      map[nmap].alias = memcpy (&string_space[string_space_act],
+					alias, alias_len);
+	      string_space_act += alias_len;
+
+	      map[nmap].value = memcpy (&string_space[string_space_act],
+					value, value_len);
+	      string_space_act += value_len;
+
+	      ++nmap;
+	      ++added;
+	    }
+	}
+    }
+
+  /* Should we test for ferror()?  I think we have to silently ignore
+     errors.  --drepper  */
+  fclose (fp);
+
+  if (added > 0)
+    qsort (map, nmap, sizeof (struct alias_map),
+	   (int (*) PARAMS ((const void *, const void *))) alias_compare);
+
+  FREE_BLOCKS (block_list);
+  return added;
+}
+
+
+static void
+extend_alias_table ()
+{
+  size_t new_size;
+  struct alias_map *new_map;
+
+  new_size = maxmap == 0 ? 100 : 2 * maxmap;
+  new_map = (struct alias_map *) realloc (map, (new_size
+						* sizeof (struct alias_map)));
+  if (new_map == NULL)
+    /* Simply don't extend: we don't have any more core.  */
+    return;
+
+  map = new_map;
+  maxmap = new_size;
+}
+
+
+#ifdef _LIBC
+static void __attribute__ ((unused))
+free_mem (void)
+{
+  if (string_space != NULL)
+    free (string_space);
+  if (map != NULL)
+    free (map);
+}
+text_set_element (__libc_subfreeres, free_mem);
+#endif
+
+
+static int
+alias_compare (map1, map2)
+     const struct alias_map *map1;
+     const struct alias_map *map2;
+{
+#if defined _LIBC || defined HAVE_STRCASECMP
+  return strcasecmp (map1->alias, map2->alias);
+#else
+  const unsigned char *p1 = (const unsigned char *) map1->alias;
+  const unsigned char *p2 = (const unsigned char *) map2->alias;
+  unsigned char c1, c2;
+
+  if (p1 == p2)
+    return 0;
+
+  do
+    {
+      /* I know this seems to be odd but the tolower() function in
+	 some systems libc cannot handle nonalpha characters.  */
+      c1 = isupper (*p1) ? tolower (*p1) : *p1;
+      c2 = isupper (*p2) ? tolower (*p2) : *p2;
+      if (c1 == '\0')
+	break;
+      ++p1;
+      ++p2;
+    }
+  while (c1 == c2);
+
+  return c1 - c2;
+#endif
+}
diff --git a/intl/po2tbl.sed.in b/intl/po2tbl.sed.in
new file mode 100644
index 00000000..b3bcca4d
--- /dev/null
+++ b/intl/po2tbl.sed.in
@@ -0,0 +1,102 @@
+# po2tbl.sed - Convert Uniforum style .po file to lookup table for catgets
+# Copyright (C) 1995 Free Software Foundation, Inc.
+# Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+1 {
+  i\
+/* Automatically generated by po2tbl.sed from @PACKAGE NAME@.pot.  */\
+\
+#if HAVE_CONFIG_H\
+# include <config.h>\
+#endif\
+\
+#include "libgettext.h"\
+\
+const struct _msg_ent _msg_tbl[] = {
+  h
+  s/.*/0/
+  x
+}
+#
+# Write msgid entries in C array form.
+#
+/^msgid/ {
+  s/msgid[ 	]*\(".*"\)/  {\1/
+  tb
+# Append the next line
+  :b
+  N
+# Look whether second part is continuation line.
+  s/\(.*\)"\(\n\)"\(.*"\)/\1\2\3/
+# Yes, then branch.
+  ta
+# Because we assume that the input file correctly formed the line
+# just read cannot be again be a msgid line.  So it's safe to ignore
+# it.
+  s/\(.*\)\n.*/\1/
+  bc
+# We found a continuation line.  But before printing insert '\'.
+  :a
+  s/\(.*\)\(\n.*\)/\1\\\2/
+  P
+# We cannot use D here.
+  s/.*\n\(.*\)/\1/
+# Some buggy seds do not clear the `successful substitution since last ``t'''
+# flag on `N', so we do a `t' here to clear it.
+  tb
+# Not reached
+  :c
+  x
+# The following nice solution is by
+# Bruno <Haible@ma2s2.mathematik.uni-karlsruhe.de>
+  td
+# Increment a decimal number in pattern space.
+# First hide trailing `9' digits.
+  :d
+  s/9\(_*\)$/_\1/
+  td
+# Assure at least one digit is available.
+  s/^\(_*\)$/0\1/
+# Increment the last digit.
+  s/8\(_*\)$/9\1/
+  s/7\(_*\)$/8\1/
+  s/6\(_*\)$/7\1/
+  s/5\(_*\)$/6\1/
+  s/4\(_*\)$/5\1/
+  s/3\(_*\)$/4\1/
+  s/2\(_*\)$/3\1/
+  s/1\(_*\)$/2\1/
+  s/0\(_*\)$/1\1/
+# Convert the hidden `9' digits to `0's.
+  s/_/0/g
+  x
+  G
+  s/\(.*\)\n\([0-9]*\)/\1, \2},/
+  s/\(.*\)"$/\1/
+  p
+}
+#
+# Last line.
+#
+$ {
+  i\
+};\
+
+  g
+  s/0*\(.*\)/int _msg_tbl_length = \1;/p
+}
+d
diff --git a/intl/textdomain.c b/intl/textdomain.c
new file mode 100644
index 00000000..88557460
--- /dev/null
+++ b/intl/textdomain.c
@@ -0,0 +1,108 @@
+/* Implementation of the textdomain(3) function.
+   Copyright (C) 1995, 1996, 1997, 1998 Free Software Foundation, Inc.
+   Written by Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2, or (at your option)
+   any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software Foundation,
+   Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
+#if defined STDC_HEADERS || defined _LIBC
+# include <stdlib.h>
+#endif
+
+#if defined STDC_HEADERS || defined HAVE_STRING_H || defined _LIBC
+# include <string.h>
+#else
+# include <strings.h>
+# ifndef memcpy
+#  define memcpy(Dst, Src, Num) bcopy (Src, Dst, Num)
+# endif
+#endif
+
+#ifdef _LIBC
+# include <libintl.h>
+#else
+# include "libgettext.h"
+#endif
+
+/* @@ end of prolog @@ */
+
+/* Name of the default text domain.  */
+extern const char _nl_default_default_domain[];
+
+/* Default text domain in which entries for gettext(3) are to be found.  */
+extern const char *_nl_current_default_domain;
+
+
+/* Names for the libintl functions are a problem.  They must not clash
+   with existing names and they should follow ANSI C.  But this source
+   code is also used in GNU C Library where the names have a __
+   prefix.  So we have to make a difference here.  */
+#ifdef _LIBC
+# define TEXTDOMAIN __textdomain
+# ifndef strdup
+#  define strdup(str) __strdup (str)
+# endif
+#else
+# define TEXTDOMAIN textdomain__
+#endif
+
+/* Set the current default message catalog to DOMAINNAME.
+   If DOMAINNAME is null, return the current default.
+   If DOMAINNAME is "", reset to the default of "messages".  */
+char *
+TEXTDOMAIN (domainname)
+     const char *domainname;
+{
+  char *old;
+
+  /* A NULL pointer requests the current setting.  */
+  if (domainname == NULL)
+    return (char *) _nl_current_default_domain;
+
+  old = (char *) _nl_current_default_domain;
+
+  /* If domain name is the null string set to default domain "messages".  */
+  if (domainname[0] == '\0'
+      || strcmp (domainname, _nl_default_default_domain) == 0)
+    _nl_current_default_domain = _nl_default_default_domain;
+  else
+    {
+      /* If the following malloc fails `_nl_current_default_domain'
+	 will be NULL.  This value will be returned and so signals we
+	 are out of core.  */
+#if defined _LIBC || defined HAVE_STRDUP
+      _nl_current_default_domain = strdup (domainname);
+#else
+      size_t len = strlen (domainname) + 1;
+      char *cp = (char *) malloc (len);
+      if (cp != NULL)
+	memcpy (cp, domainname, len);
+      _nl_current_default_domain = cp;
+#endif
+    }
+
+  if (old != _nl_default_default_domain)
+    free (old);
+
+  return (char *) _nl_current_default_domain;
+}
+
+#ifdef _LIBC
+/* Alias for function name in GNU C Library.  */
+weak_alias (__textdomain, textdomain);
+#endif
diff --git a/intl/xopen-msg.sed b/intl/xopen-msg.sed
new file mode 100644
index 00000000..b19c0bbd
--- /dev/null
+++ b/intl/xopen-msg.sed
@@ -0,0 +1,104 @@
+# po2msg.sed - Convert Uniforum style .po file to X/Open style .msg file
+# Copyright (C) 1995 Free Software Foundation, Inc.
+# Ulrich Drepper <drepper@gnu.ai.mit.edu>, 1995.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+#
+# The first directive in the .msg should be the definition of the
+# message set number.  We use always set number 1.
+#
+1 {
+  i\
+$set 1 # Automatically created by po2msg.sed
+  h
+  s/.*/0/
+  x
+}
+#
+# We copy all comments into the .msg file.  Perhaps they can help.
+#
+/^#/ s/^#[ 	]*/$ /p
+#
+# We copy the original message as a comment into the .msg file.
+#
+/^msgid/ {
+# Does not work now
+#  /"$/! {
+#    s/\\$//
+#    s/$/ ... (more lines following)"/
+#  }
+  s/^msgid[ 	]*"\(.*\)"$/$ Original Message: \1/
+  p
+}
+#
+# The .msg file contains, other then the .po file, only the translations
+# but each given a unique ID.  Starting from 1 and incrementing by 1 for
+# each message we assign them to the messages.
+# It is important that the .po file used to generate the cat-id-tbl.c file
+# (with po-to-tbl) is the same as the one used here.  (At least the order
+# of declarations must not be changed.)
+#
+/^msgstr/ {
+  s/msgstr[ 	]*"\(.*\)"/\1/
+  x
+# The following nice solution is by
+# Bruno <Haible@ma2s2.mathematik.uni-karlsruhe.de>
+  td
+# Increment a decimal number in pattern space.
+# First hide trailing `9' digits.
+  :d
+  s/9\(_*\)$/_\1/
+  td
+# Assure at least one digit is available.
+  s/^\(_*\)$/0\1/
+# Increment the last digit.
+  s/8\(_*\)$/9\1/
+  s/7\(_*\)$/8\1/
+  s/6\(_*\)$/7\1/
+  s/5\(_*\)$/6\1/
+  s/4\(_*\)$/5\1/
+  s/3\(_*\)$/4\1/
+  s/2\(_*\)$/3\1/
+  s/1\(_*\)$/2\1/
+  s/0\(_*\)$/1\1/
+# Convert the hidden `9' digits to `0's.
+  s/_/0/g
+  x
+# Bring the line in the format `<number> <message>'
+  G
+  s/^[^\n]*$/& /
+  s/\(.*\)\n\([0-9]*\)/\2 \1/
+# Clear flag from last substitution.
+  tb
+# Append the next line.
+  :b
+  N
+# Look whether second part is a continuation line.
+  s/\(.*\n\)"\(.*\)"/\1\2/
+# Yes, then branch.
+  ta
+  P
+  D
+# Note that `D' includes a jump to the start!!
+# We found a continuation line.  But before printing insert '\'.
+  :a
+  s/\(.*\)\(\n.*\)/\1\\\2/
+  P
+# We cannot use the sed command `D' here
+  s/.*\n\(.*\)/\1/
+  tb
+}
+d
diff --git a/kerberos.h b/kerberos.h
new file mode 100644
index 00000000..32cb93e9
--- /dev/null
+++ b/kerberos.h
@@ -0,0 +1,33 @@
+/*
+ * kerberos.h -- Headers for Kerberos support.
+ *
+ * For license terms, see the file COPYING in this directory.
+ */
+
+#ifndef H_KERBEROS__
+#define H_KERBEROS__
+#include  "config.h"
+#if defined(KERBEROS_V4) || defined(KERBEROS_V5)
+
+#ifdef KERBEROS_V5
+#include <krb5.h>
+#include <com_err.h>
+#endif
+
+#ifdef KERBEROS_V4
+#  if defined (__bsdi__) 
+#    include <des.h> /* order of includes matters */
+#    define krb_get_err_text(e) (krb_err_txt[e])
+#  endif
+#  include <krb.h>
+#  if defined(__NetBSD__) || defined(__FreeBSD__) || defined(__linux__)
+#    define krb_get_err_text(e) (krb_err_txt[e])
+#    include <des.h>
+#  endif
+#endif
+
+/* des.h might define _ for no good reason.  */
+#undef _
+
+#endif /* KERBEROS_V4 || KERBEROS_V5 */
+#endif /* H_KERBEROS__ */
diff --git a/lcmessage.m4 b/lcmessage.m4
new file mode 100644
index 00000000..7ff8b759
--- /dev/null
+++ b/lcmessage.m4
@@ -0,0 +1,22 @@
+# Check whether LC_MESSAGES is available in <locale.h>.
+# Ulrich Drepper <drepper@cygnus.com>, 1995.
+#
+# This file can be copied and used freely without restrictions.  It can
+# be used in projects which are not available under the GNU Public License
+# but which still want to provide support for the GNU gettext functionality.
+# Please note that the actual code is *not* freely available.
+
+# serial 2
+
+AC_PREREQ(2.13)               dnl Minimum Autoconf version required.
+
+AC_DEFUN(AM_LC_MESSAGES,
+  [if test $ac_cv_header_locale_h = yes; then
+    AC_CACHE_CHECK([for LC_MESSAGES], am_cv_val_LC_MESSAGES,
+      [AC_TRY_LINK([#include <locale.h>], [return LC_MESSAGES],
+       am_cv_val_LC_MESSAGES=yes, am_cv_val_LC_MESSAGES=no)])
+    if test $am_cv_val_LC_MESSAGES = yes; then
+      AC_DEFINE(HAVE_LC_MESSAGES, 1,
+		[Define if your locale.h file contains LC_MESSAGES.])
+    fi
+  fi])
diff --git a/libntlm-0.21/COPYING b/libntlm-0.21/COPYING
new file mode 100644
index 00000000..a43ea212
--- /dev/null
+++ b/libntlm-0.21/COPYING
@@ -0,0 +1,339 @@
+		    GNU GENERAL PUBLIC LICENSE
+		       Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+                          675 Mass Ave, Cambridge, MA 02139, USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+			    Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+		    GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+			    NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+		     END OF TERMS AND CONDITIONS
+
+	Appendix: How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) 19yy  <name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+    Gnomovision version 69, Copyright (C) 19yy name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/libntlm-0.21/HISTORY b/libntlm-0.21/HISTORY
new file mode 100644
index 00000000..58c31c57
--- /dev/null
+++ b/libntlm-0.21/HISTORY
@@ -0,0 +1,21 @@
+
+7 October 1999   Revsion  0.21
+
+Added support for usernames with embedded domain strings of the
+format username@domain.  If present, the domain will override the
+domain that is returned by the host in the challenge.
+
+6 October 1999   Revision 0.2
+-----------------------------
+
+Fixed another byte-order problem in unicode routine in smbutil.c.
+Added a copy of GPL to the distribution.  Added test driver
+program directory.
+
+5 October 1999   Revision 0.1
+-----------------------------
+
+Fixed usage of byte-order macros in smbutil.c.  Hopefully this
+will make it work on SPARC machines...
+
+
diff --git a/libntlm-0.21/Makefile b/libntlm-0.21/Makefile
new file mode 100644
index 00000000..3195f4b0
--- /dev/null
+++ b/libntlm-0.21/Makefile
@@ -0,0 +1,42 @@
+CFLAGS=-Wall -g
+
+DEST=/usr/local
+LIBDEST=$(DEST)/lib
+INCDEST=$(DEST)/include
+
+SRCS=smbdes.c smbencrypt.c smbmd4.c smbutil.c
+OBJS=smbdes.o smbencrypt.o smbmd4.o smbutil.o
+
+libntlm.a: $(OBJS)
+	ar cru libntlm.a $(OBJS)
+	ranlib libntlm.a
+
+install: libntlm.a ntlm.h
+	install libntlm.a $(LIBDEST)
+	install ntlm.h $(INCDEST)
+
+clean: 
+	rm -f *.a *.o *~ *.bak \#*\#
+
+depend:
+	makedepend $(SRCS)
+# DO NOT DELETE
+
+smbdes.o: smbdes.h
+smbencrypt.o: /usr/include/unistd.h /usr/include/sys/feature_tests.h
+smbencrypt.o: /usr/include/sys/types.h /usr/include/sys/isa_defs.h
+smbencrypt.o: /usr/include/sys/machtypes.h /usr/include/sys/int_types.h
+smbencrypt.o: /usr/include/sys/select.h /usr/include/sys/time.h
+smbencrypt.o: /usr/include/sys/time.h /usr/include/sys/unistd.h
+smbencrypt.o: /usr/include/stdlib.h /usr/include/string.h
+smbencrypt.o: /usr/include/ctype.h smbbyteorder.h smbdes.h smbmd4.h
+smbmd4.o: smbmd4.h
+smbutil.o: /usr/include/unistd.h /usr/include/sys/feature_tests.h
+smbutil.o: /usr/include/sys/types.h /usr/include/sys/isa_defs.h
+smbutil.o: /usr/include/sys/machtypes.h /usr/include/sys/int_types.h
+smbutil.o: /usr/include/sys/select.h /usr/include/sys/time.h
+smbutil.o: /usr/include/sys/time.h /usr/include/sys/unistd.h
+smbutil.o: /usr/include/stdlib.h /usr/include/stdio.h
+smbutil.o: /usr/include/sys/va_list.h /usr/include/ctype.h
+smbutil.o: /usr/include/assert.h /usr/include/string.h ntlm.h smbencrypt.h
+smbutil.o: smbbyteorder.h
diff --git a/libntlm-0.21/README b/libntlm-0.21/README
new file mode 100644
index 00000000..2ce20c39
--- /dev/null
+++ b/libntlm-0.21/README
@@ -0,0 +1,98 @@
+
+This directory contains sources for a library which provides
+routines to manipulate the structures used for the client end
+of Microsoft NTLM authentication.
+
+This code was taken mostly from the Samba project and was
+initially intended for use with Microsoft Exchange Server when
+it is configured to require NTLM authentication for clients of
+it's IMAP server.
+
+BUILDING
+
+If you want the library installed in /usr/local/lib and
+the header in /usr/local/include, then
+
+ $ make
+ $ make install
+
+will probably work.  Not much effort has been put into making
+this portable, and I only know for sure that it works on i386
+Linux glibc systems -- though there shouldn't be anything all
+that system-specific anywhere.  System byte order differences
+should already be taken care of.
+
+TEST PROGRAM
+
+The test directory contains sources for a program named
+"dumper" that will dump out base64 NTLM auth messages in a
+readable format.  It will also take a challenge and generate a
+response if provided with a username and password.
+
+USAGE  
+  
+The application program must convert these structures to/from
+base64 which is used to transfer data for IMAP authentication.
+For example usage see the sources for the mutt MUA or the
+fetchmail package.
+
+In general the usage is something like shown below (no, I don't
+know if this code even compiles, but you get the idea
+hopefully):
+
+
+#include <ntlm.h>
+
+extern char *seqTag;  /* IMAP sequence number */
+
+int imap_auth_ntlm(char *user, char *domain, char *pass)
+{
+  tSmbNtlmAuthRequest   request;              
+  tSmbNtlmAuthChallenge challenge;
+  tSmbNtlmAuthResponse  response;
+  char buffer[512];
+  char tmpstr[32];
+  
+  writeToServer("%s AUTHENTICATE NTLM\r\n",seqTag);
+  readFromServer(buffer)
+  
+  /* buffer should be "+", but we won't show code to check */
+
+  /* 
+   * prepare the request, convert to base64, and send it to
+   * the the server.  My server didn't care about domain, and NULL
+   * worked fine.
+   */
+
+  buildSmbNtlmAuthRequest(&request,user,domain);
+  convertToBase64(buffer, &request, SmbLength(&request));
+  writeToServer("%s\r\n",buffer);
+  
+  /* read challange data from server, convert from base64 */
+  
+  readFromServer(buffer);
+  
+  /* buffer should contain the string "+ [base 64 data]" */
+  
+  convertFromBase64(&challenge, buffer+2);
+  
+  /* prepare response, convert to base64, send to server */
+  
+  buildSmbNtlmAuthResponse(&challenge, &response, user, pass);
+  convertToBase64(buffer,&response,SmbLength(&response));
+  writeToServer("%s\r\n",buffer);
+  
+  /* read line from server, it should be "[seq] OK blah blah blah" */
+  
+  readFromServer(buffer);
+  
+  sprintf(tmpstr,"%s OK",seqTag);
+  
+  if (strncmp(buffer,tmpstr,strlen(tmpstr)))
+  {
+    /* login failed */
+    return -1;
+  }
+  
+  return 0;
+}
diff --git a/libntlm-0.21/ntlm.h b/libntlm-0.21/ntlm.h
new file mode 100644
index 00000000..3f6d206f
--- /dev/null
+++ b/libntlm-0.21/ntlm.h
@@ -0,0 +1,68 @@
+typedef unsigned short uint16;
+typedef unsigned int   uint32;
+typedef unsigned char  uint8;
+
+
+/* 
+ * These structures are byte-order dependant, and should not
+ * be manipulated except by the use of the routines provided
+ */
+
+typedef struct
+{
+uint16  len;
+uint16  maxlen;
+uint32  offset;
+}tSmbStrHeader;
+
+typedef struct
+{
+char          ident[8];
+uint32        msgType;
+uint32        flags;
+tSmbStrHeader    user;
+tSmbStrHeader    domain;
+uint8         buffer[1024];
+uint32        bufIndex;
+}tSmbNtlmAuthRequest;
+
+typedef struct
+{
+char          ident[8];
+uint32        msgType;
+tSmbStrHeader    uDomain;
+uint32        flags;
+uint8         challengeData[8];
+uint8         reserved[8];
+tSmbStrHeader    emptyString;
+uint8         buffer[1024];
+uint32        bufIndex;
+}tSmbNtlmAuthChallenge;
+
+
+typedef struct
+{
+char          ident[8];
+uint32        msgType;
+tSmbStrHeader    lmResponse;
+tSmbStrHeader    ntResponse;
+tSmbStrHeader    uDomain;
+tSmbStrHeader    uUser;
+tSmbStrHeader    uWks;
+tSmbStrHeader    sessionKey;
+uint32        flags;
+uint8         buffer[1024];
+uint32        bufIndex;
+}tSmbNtlmAuthResponse;
+
+/* public: */
+
+#define SmbLength(ptr) (((ptr)->buffer - (uint8*)(ptr)) + (ptr)->bufIndex)
+
+extern void dumpSmbNtlmAuthRequest(FILE *fp, tSmbNtlmAuthRequest *request);
+extern void dumpSmbNtlmAuthChallenge(FILE *fp, tSmbNtlmAuthChallenge *challenge);
+extern void dumpSmbNtlmAuthResponse(FILE *fp, tSmbNtlmAuthResponse *response);
+
+extern void buildSmbNtlmAuthRequest(tSmbNtlmAuthRequest *request, char *user, char *domain);
+extern void buildSmbNtlmAuthResponse(tSmbNtlmAuthChallenge *challenge, tSmbNtlmAuthResponse *response, char *user, char *password);
+
diff --git a/libntlm-0.21/smb.h b/libntlm-0.21/smb.h
new file mode 100644
index 00000000..eb5e382e
--- /dev/null
+++ b/libntlm-0.21/smb.h
@@ -0,0 +1,52 @@
+typedef unsigned short uint16;
+typedef unsigned       uint32;
+typedef unsigned char  uint8;
+
+typedef struct
+{
+uint16  len;
+uint16  maxlen;
+uint32  offset;
+}tSmbStrHeader;
+
+typedef struct
+{
+char          ident[8];
+uint32        msgType;
+uint32        flags;
+tSmbStrHeader    user;
+tSmbStrHeader    domain;
+uint8         buffer[1024];
+uint32        bufIndex;
+}tSmbNtlmAuthRequest;
+
+typedef struct
+{
+char          ident[8];
+uint32        msgType;
+tSmbStrHeader    uDomain;
+uint32        flags;
+uint8         challengeData[8];
+uint8         reserved[8];
+tSmbStrHeader    emptyString;
+uint8         buffer[1024];
+uint32        bufIndex;
+}tSmbNtlmAuthChallenge;
+
+
+typedef struct
+{
+char          ident[8];
+uint32        msgType;
+tSmbStrHeader    lmResponse;
+tSmbStrHeader    ntResponse;
+tSmbStrHeader    uDomain;
+tSmbStrHeader    uUser;
+tSmbStrHeader    uWks;
+tSmbStrHeader    sessionKey;
+uint32        flags;
+uint8         buffer[1024];
+uint32        bufIndex;
+}tSmbNtlmAuthResponse;
+
+#define SmbLength(ptr) (((ptr)->buffer - (uint8*)(ptr)) + (ptr)->bufIndex)
diff --git a/libntlm-0.21/smbbyteorder.h b/libntlm-0.21/smbbyteorder.h
new file mode 100644
index 00000000..59ae4979
--- /dev/null
+++ b/libntlm-0.21/smbbyteorder.h
@@ -0,0 +1,265 @@
+/* 
+   Unix SMB/Netbios implementation.
+   Version 1.9.
+   SMB Byte handling
+   Copyright (C) Andrew Tridgell 1992-1998
+   
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+   
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#ifndef _BYTEORDER_H
+#define _BYTEORDER_H
+
+/*
+   This file implements macros for machine independent short and 
+   int manipulation
+
+Here is a description of this file that I emailed to the samba list once:
+
+> I am confused about the way that byteorder.h works in Samba. I have
+> looked at it, and I would have thought that you might make a distinction
+> between LE and BE machines, but you only seem to distinguish between 386
+> and all other architectures.
+> 
+> Can you give me a clue?
+
+sure.
+
+The distinction between 386 and other architectures is only there as
+an optimisation. You can take it out completely and it will make no
+difference. The routines (macros) in byteorder.h are totally byteorder
+independent. The 386 optimsation just takes advantage of the fact that
+the x86 processors don't care about alignment, so we don't have to
+align ints on int boundaries etc. If there are other processors out
+there that aren't alignment sensitive then you could also define
+CAREFUL_ALIGNMENT=0 on those processors as well.
+
+Ok, now to the macros themselves. I'll take a simple example, say we
+want to extract a 2 byte integer from a SMB packet and put it into a
+type called uint16 that is in the local machines byte order, and you
+want to do it with only the assumption that uint16 is _at_least_ 16
+bits long (this last condition is very important for architectures
+that don't have any int types that are 2 bytes long)
+
+You do this:
+
+#define CVAL(buf,pos) (((unsigned char *)(buf))[pos])
+#define PVAL(buf,pos) ((unsigned)CVAL(buf,pos))
+#define SVAL(buf,pos) (PVAL(buf,pos)|PVAL(buf,(pos)+1)<<8)
+
+then to extract a uint16 value at offset 25 in a buffer you do this:
+
+char *buffer = foo_bar();
+uint16 xx = SVAL(buffer,25);
+
+We are using the byteoder independence of the ANSI C bitshifts to do
+the work. A good optimising compiler should turn this into efficient
+code, especially if it happens to have the right byteorder :-)
+
+I know these macros can be made a bit tidier by removing some of the
+casts, but you need to look at byteorder.h as a whole to see the
+reasoning behind them. byteorder.h defines the following macros:
+
+SVAL(buf,pos) - extract a 2 byte SMB value
+IVAL(buf,pos) - extract a 4 byte SMB value
+SVALS(buf,pos) signed version of SVAL()
+IVALS(buf,pos) signed version of IVAL()
+
+SSVAL(buf,pos,val) - put a 2 byte SMB value into a buffer
+SIVAL(buf,pos,val) - put a 4 byte SMB value into a buffer
+SSVALS(buf,pos,val) - signed version of SSVAL()
+SIVALS(buf,pos,val) - signed version of SIVAL()
+
+RSVAL(buf,pos) - like SVAL() but for NMB byte ordering
+RSVALS(buf,pos) - like SVALS() but for NMB byte ordering
+RIVAL(buf,pos) - like IVAL() but for NMB byte ordering
+RIVALS(buf,pos) - like IVALS() but for NMB byte ordering
+RSSVAL(buf,pos,val) - like SSVAL() but for NMB ordering
+RSIVAL(buf,pos,val) - like SIVAL() but for NMB ordering
+RSIVALS(buf,pos,val) - like SIVALS() but for NMB ordering
+
+it also defines lots of intermediate macros, just ignore those :-)
+
+*/
+
+/* some switch macros that do both store and read to and from SMB buffers */
+
+#define RW_PCVAL(read,inbuf,outbuf,len) \
+	{ if (read) { PCVAL (inbuf,0,outbuf,len); } \
+	else      { PSCVAL(inbuf,0,outbuf,len); } }
+
+#define RW_PIVAL(read,big_endian,inbuf,outbuf,len) \
+	{ if (read) { if (big_endian) { RPIVAL(inbuf,0,outbuf,len); } else { PIVAL(inbuf,0,outbuf,len); } } \
+	else      { if (big_endian) { RPSIVAL(inbuf,0,outbuf,len); } else { PSIVAL(inbuf,0,outbuf,len); } } }
+
+#define RW_PSVAL(read,big_endian,inbuf,outbuf,len) \
+	{ if (read) { if (big_endian) { RPSVAL(inbuf,0,outbuf,len); } else { PSVAL(inbuf,0,outbuf,len); } } \
+	else      { if (big_endian) { RPSSVAL(inbuf,0,outbuf,len); } else { PSSVAL(inbuf,0,outbuf,len); } } }
+
+#define RW_CVAL(read, inbuf, outbuf, offset) \
+	{ if (read) { (outbuf) = CVAL (inbuf,offset); } \
+	else      { SCVAL(inbuf,offset,outbuf); } }
+
+#define RW_IVAL(read, big_endian, inbuf, outbuf, offset) \
+	{ if (read) { (outbuf) = ((big_endian) ? RIVAL(inbuf,offset) : IVAL (inbuf,offset)); } \
+	else      { if (big_endian) { RSIVAL(inbuf,offset,outbuf); } else { SIVAL(inbuf,offset,outbuf); } } }
+
+#define RW_SVAL(read, big_endian, inbuf, outbuf, offset) \
+	{ if (read) { (outbuf) = ((big_endian) ? RSVAL(inbuf,offset) : SVAL (inbuf,offset)); } \
+	else      { if (big_endian) { RSSVAL(inbuf,offset,outbuf); } else { SSVAL(inbuf,offset,outbuf); } } }
+
+#undef CAREFUL_ALIGNMENT
+
+/* we know that the 386 can handle misalignment and has the "right" 
+   byteorder */
+#ifdef __i386__
+#define CAREFUL_ALIGNMENT 0
+#endif
+
+#ifndef CAREFUL_ALIGNMENT
+#define CAREFUL_ALIGNMENT 1
+#endif
+
+#define CVAL(buf,pos) (((unsigned char *)(buf))[pos])
+#define PVAL(buf,pos) ((unsigned)CVAL(buf,pos))
+#define SCVAL(buf,pos,val) (CVAL(buf,pos) = (val))
+
+
+#if CAREFUL_ALIGNMENT
+
+#define SVAL(buf,pos) (PVAL(buf,pos)|PVAL(buf,(pos)+1)<<8)
+#define IVAL(buf,pos) (SVAL(buf,pos)|SVAL(buf,(pos)+2)<<16)
+#define SSVALX(buf,pos,val) (CVAL(buf,pos)=(val)&0xFF,CVAL(buf,pos+1)=(val)>>8)
+#define SIVALX(buf,pos,val) (SSVALX(buf,pos,val&0xFFFF),SSVALX(buf,pos+2,val>>16))
+#define SVALS(buf,pos) ((int16)SVAL(buf,pos))
+#define IVALS(buf,pos) ((int32)IVAL(buf,pos))
+#define SSVAL(buf,pos,val) SSVALX((buf),(pos),((uint16)(val)))
+#define SIVAL(buf,pos,val) SIVALX((buf),(pos),((uint32)(val)))
+#define SSVALS(buf,pos,val) SSVALX((buf),(pos),((int16)(val)))
+#define SIVALS(buf,pos,val) SIVALX((buf),(pos),((int32)(val)))
+
+#else /* CAREFUL_ALIGNMENT */
+
+/* this handles things for architectures like the 386 that can handle
+   alignment errors */
+/*
+   WARNING: This section is dependent on the length of int16 and int32
+   being correct 
+*/
+
+/* get single value from an SMB buffer */
+#define SVAL(buf,pos) (*(uint16 *)((char *)(buf) + (pos)))
+#define IVAL(buf,pos) (*(uint32 *)((char *)(buf) + (pos)))
+#define SVALS(buf,pos) (*(int16 *)((char *)(buf) + (pos)))
+#define IVALS(buf,pos) (*(int32 *)((char *)(buf) + (pos)))
+
+/* store single value in an SMB buffer */
+#define SSVAL(buf,pos,val) SVAL(buf,pos)=((uint16)(val))
+#define SIVAL(buf,pos,val) IVAL(buf,pos)=((uint32)(val))
+#define SSVALS(buf,pos,val) SVALS(buf,pos)=((int16)(val))
+#define SIVALS(buf,pos,val) IVALS(buf,pos)=((int32)(val))
+
+#endif /* CAREFUL_ALIGNMENT */
+
+/* macros for reading / writing arrays */
+
+#define SMBMACRO(macro,buf,pos,val,len,size) \
+{ int l; for (l = 0; l < (len); l++) (val)[l] = macro((buf), (pos) + (size)*l); }
+
+#define SSMBMACRO(macro,buf,pos,val,len,size) \
+{ int l; for (l = 0; l < (len); l++) macro((buf), (pos) + (size)*l, (val)[l]); }
+
+/* reads multiple data from an SMB buffer */
+#define PCVAL(buf,pos,val,len) SMBMACRO(CVAL,buf,pos,val,len,1)
+#define PSVAL(buf,pos,val,len) SMBMACRO(SVAL,buf,pos,val,len,2)
+#define PIVAL(buf,pos,val,len) SMBMACRO(IVAL,buf,pos,val,len,4)
+#define PCVALS(buf,pos,val,len) SMBMACRO(CVALS,buf,pos,val,len,1)
+#define PSVALS(buf,pos,val,len) SMBMACRO(SVALS,buf,pos,val,len,2)
+#define PIVALS(buf,pos,val,len) SMBMACRO(IVALS,buf,pos,val,len,4)
+
+/* stores multiple data in an SMB buffer */
+#define PSCVAL(buf,pos,val,len) SSMBMACRO(SCVAL,buf,pos,val,len,1)
+#define PSSVAL(buf,pos,val,len) SSMBMACRO(SSVAL,buf,pos,val,len,2)
+#define PSIVAL(buf,pos,val,len) SSMBMACRO(SIVAL,buf,pos,val,len,4)
+#define PSCVALS(buf,pos,val,len) SSMBMACRO(SCVALS,buf,pos,val,len,1)
+#define PSSVALS(buf,pos,val,len) SSMBMACRO(SSVALS,buf,pos,val,len,2)
+#define PSIVALS(buf,pos,val,len) SSMBMACRO(SIVALS,buf,pos,val,len,4)
+
+
+/* now the reverse routines - these are used in nmb packets (mostly) */
+#define SREV(x) ((((x)&0xFF)<<8) | (((x)>>8)&0xFF))
+#define IREV(x) ((SREV(x)<<16) | (SREV((x)>>16)))
+
+#define RSVAL(buf,pos) SREV(SVAL(buf,pos))
+#define RSVALS(buf,pos) SREV(SVALS(buf,pos))
+#define RIVAL(buf,pos) IREV(IVAL(buf,pos))
+#define RIVALS(buf,pos) IREV(IVALS(buf,pos))
+#define RSSVAL(buf,pos,val) SSVAL(buf,pos,SREV(val))
+#define RSSVALS(buf,pos,val) SSVALS(buf,pos,SREV(val))
+#define RSIVAL(buf,pos,val) SIVAL(buf,pos,IREV(val))
+#define RSIVALS(buf,pos,val) SIVALS(buf,pos,IREV(val))
+
+/* reads multiple data from an SMB buffer (big-endian) */
+#define RPSVAL(buf,pos,val,len) SMBMACRO(RSVAL,buf,pos,val,len,2)
+#define RPIVAL(buf,pos,val,len) SMBMACRO(RIVAL,buf,pos,val,len,4)
+#define RPSVALS(buf,pos,val,len) SMBMACRO(RSVALS,buf,pos,val,len,2)
+#define RPIVALS(buf,pos,val,len) SMBMACRO(RIVALS,buf,pos,val,len,4)
+
+/* stores multiple data in an SMB buffer (big-endian) */
+#define RPSSVAL(buf,pos,val,len) SSMBMACRO(RSSVAL,buf,pos,val,len,2)
+#define RPSIVAL(buf,pos,val,len) SSMBMACRO(RSIVAL,buf,pos,val,len,4)
+#define RPSSVALS(buf,pos,val,len) SSMBMACRO(RSSVALS,buf,pos,val,len,2)
+#define RPSIVALS(buf,pos,val,len) SSMBMACRO(RSIVALS,buf,pos,val,len,4)
+
+#define DBG_RW_PCVAL(charmode,string,depth,base,read,inbuf,outbuf,len) \
+	{ RW_PCVAL(read,inbuf,outbuf,len) \
+	DEBUG(5,("%s%04x %s: ", \
+             tab_depth(depth), base,string)); \
+    if (charmode) print_asc(5, (unsigned char*)(outbuf), (len)); else \
+	{ int idx; for (idx = 0; idx < len; idx++) { DEBUG(5,("%02x ", (outbuf)[idx])); } } \
+	DEBUG(5,("\n")); } 
+
+#define DBG_RW_PSVAL(charmode,string,depth,base,read,big_endian,inbuf,outbuf,len) \
+	{ RW_PSVAL(read,big_endian,inbuf,outbuf,len) \
+	DEBUG(5,("%s%04x %s: ", \
+             tab_depth(depth), base,string)); \
+    if (charmode) print_asc(5, (unsigned char*)(outbuf), 2*(len)); else \
+	{ int idx; for (idx = 0; idx < len; idx++) { DEBUG(5,("%04x ", (outbuf)[idx])); } } \
+	DEBUG(5,("\n")); }
+
+#define DBG_RW_PIVAL(charmode,string,depth,base,read,big_endian,inbuf,outbuf,len) \
+	{ RW_PIVAL(read,big_endian,inbuf,outbuf,len) \
+	DEBUG(5,("%s%04x %s: ", \
+             tab_depth(depth), base,string)); \
+    if (charmode) print_asc(5, (unsigned char*)(outbuf), 4*(len)); else \
+	{ int idx; for (idx = 0; idx < len; idx++) { DEBUG(5,("%08x ", (outbuf)[idx])); } } \
+	DEBUG(5,("\n")); }
+
+#define DBG_RW_CVAL(string,depth,base,read,inbuf,outbuf) \
+	{ RW_CVAL(read,inbuf,outbuf,0) \
+	DEBUG(5,("%s%04x %s: %02x\n", \
+             tab_depth(depth), base, string, outbuf)); }
+
+#define DBG_RW_SVAL(string,depth,base,read,big_endian,inbuf,outbuf) \
+	{ RW_SVAL(read,big_endian,inbuf,outbuf,0) \
+	DEBUG(5,("%s%04x %s: %04x\n", \
+             tab_depth(depth), base, string, outbuf)); }
+
+#define DBG_RW_IVAL(string,depth,base,read,big_endian,inbuf,outbuf) \
+	{ RW_IVAL(read,big_endian,inbuf,outbuf,0) \
+	DEBUG(5,("%s%04x %s: %08x\n", \
+             tab_depth(depth), base, string, outbuf)); }
+
+#endif /* _BYTEORDER_H */
diff --git a/libntlm-0.21/smbdes.c b/libntlm-0.21/smbdes.c
new file mode 100644
index 00000000..e3ab78af
--- /dev/null
+++ b/libntlm-0.21/smbdes.c
@@ -0,0 +1,399 @@
+/* 
+   Unix SMB/Netbios implementation.
+   Version 1.9.
+
+   a partial implementation of DES designed for use in the 
+   SMB authentication protocol
+
+   Copyright (C) Andrew Tridgell 1998
+   
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+   
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#include "smbdes.h"
+
+/* NOTES: 
+
+   This code makes no attempt to be fast! In fact, it is a very
+   slow implementation 
+
+   This code is NOT a complete DES implementation. It implements only
+   the minimum necessary for SMB authentication, as used by all SMB
+   products (including every copy of Microsoft Windows95 ever sold)
+
+   In particular, it can only do a unchained forward DES pass. This
+   means it is not possible to use this code for encryption/decryption
+   of data, instead it is only useful as a "hash" algorithm.
+
+   There is no entry point into this code that allows normal DES operation.
+
+   I believe this means that this code does not come under ITAR
+   regulations but this is NOT a legal opinion. If you are concerned
+   about the applicability of ITAR regulations to this code then you
+   should confirm it for yourself (and maybe let me know if you come
+   up with a different answer to the one above)
+*/
+
+
+#define uchar unsigned char
+
+static uchar perm1[56] = {57, 49, 41, 33, 25, 17,  9,
+			 1, 58, 50, 42, 34, 26, 18,
+			10,  2, 59, 51, 43, 35, 27,
+			19, 11,  3, 60, 52, 44, 36,
+			63, 55, 47, 39, 31, 23, 15,
+			 7, 62, 54, 46, 38, 30, 22,
+			14,  6, 61, 53, 45, 37, 29,
+			21, 13,  5, 28, 20, 12,  4};
+
+static uchar perm2[48] = {14, 17, 11, 24,  1,  5,
+                         3, 28, 15,  6, 21, 10,
+                        23, 19, 12,  4, 26,  8,
+                        16,  7, 27, 20, 13,  2,
+                        41, 52, 31, 37, 47, 55,
+                        30, 40, 51, 45, 33, 48,
+                        44, 49, 39, 56, 34, 53,
+                        46, 42, 50, 36, 29, 32};
+
+static uchar perm3[64] = {58, 50, 42, 34, 26, 18, 10,  2,
+			60, 52, 44, 36, 28, 20, 12,  4,
+			62, 54, 46, 38, 30, 22, 14,  6,
+			64, 56, 48, 40, 32, 24, 16,  8,
+			57, 49, 41, 33, 25, 17,  9,  1,
+			59, 51, 43, 35, 27, 19, 11,  3,
+			61, 53, 45, 37, 29, 21, 13,  5,
+			63, 55, 47, 39, 31, 23, 15,  7};
+
+static uchar perm4[48] = {   32,  1,  2,  3,  4,  5,
+                            4,  5,  6,  7,  8,  9,
+                            8,  9, 10, 11, 12, 13,
+                           12, 13, 14, 15, 16, 17,
+                           16, 17, 18, 19, 20, 21,
+                           20, 21, 22, 23, 24, 25,
+                           24, 25, 26, 27, 28, 29,
+                           28, 29, 30, 31, 32,  1};
+
+static uchar perm5[32] = {      16,  7, 20, 21,
+                              29, 12, 28, 17,
+                               1, 15, 23, 26,
+                               5, 18, 31, 10,
+                               2,  8, 24, 14,
+                              32, 27,  3,  9,
+                              19, 13, 30,  6,
+                              22, 11,  4, 25};
+
+
+static uchar perm6[64] ={ 40,  8, 48, 16, 56, 24, 64, 32,
+                        39,  7, 47, 15, 55, 23, 63, 31,
+                        38,  6, 46, 14, 54, 22, 62, 30,
+                        37,  5, 45, 13, 53, 21, 61, 29,
+                        36,  4, 44, 12, 52, 20, 60, 28,
+                        35,  3, 43, 11, 51, 19, 59, 27,
+                        34,  2, 42, 10, 50, 18, 58, 26,
+                        33,  1, 41,  9, 49, 17, 57, 25};
+
+
+static uchar sc[16] = {1, 1, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 1};
+
+static uchar sbox[8][4][16] = {
+	{{14,  4, 13,  1,  2, 15, 11,  8,  3, 10,  6, 12,  5,  9,  0,  7},
+	 {0, 15,  7,  4, 14,  2, 13,  1, 10,  6, 12, 11,  9,  5,  3,  8},
+	 {4,  1, 14,  8, 13,  6,  2, 11, 15, 12,  9,  7,  3, 10,  5,  0},
+	 {15, 12,  8,  2,  4,  9,  1,  7,  5, 11,  3, 14, 10,  0,  6, 13}},
+
+	{{15,  1,  8, 14,  6, 11,  3,  4,  9,  7,  2, 13, 12,  0,  5, 10},
+	 {3, 13,  4,  7, 15,  2,  8, 14, 12,  0,  1, 10,  6,  9, 11,  5},
+	 {0, 14,  7, 11, 10,  4, 13,  1,  5,  8, 12,  6,  9,  3,  2, 15},
+	 {13,  8, 10,  1,  3, 15,  4,  2, 11,  6,  7, 12,  0,  5, 14,  9}},
+
+	{{10,  0,  9, 14,  6,  3, 15,  5,  1, 13, 12,  7, 11,  4,  2,  8},
+	 {13,  7,  0,  9,  3,  4,  6, 10,  2,  8,  5, 14, 12, 11, 15,  1},
+	 {13,  6,  4,  9,  8, 15,  3,  0, 11,  1,  2, 12,  5, 10, 14,  7},
+	 {1, 10, 13,  0,  6,  9,  8,  7,  4, 15, 14,  3, 11,  5,  2, 12}},
+
+	{{7, 13, 14,  3,  0,  6,  9, 10,  1,  2,  8,  5, 11, 12,  4, 15},
+	 {13,  8, 11,  5,  6, 15,  0,  3,  4,  7,  2, 12,  1, 10, 14,  9},
+	 {10,  6,  9,  0, 12, 11,  7, 13, 15,  1,  3, 14,  5,  2,  8,  4},
+	 {3, 15,  0,  6, 10,  1, 13,  8,  9,  4,  5, 11, 12,  7,  2, 14}},
+
+	{{2, 12,  4,  1,  7, 10, 11,  6,  8,  5,  3, 15, 13,  0, 14,  9},
+	 {14, 11,  2, 12,  4,  7, 13,  1,  5,  0, 15, 10,  3,  9,  8,  6},
+	 {4,  2,  1, 11, 10, 13,  7,  8, 15,  9, 12,  5,  6,  3,  0, 14},
+	 {11,  8, 12,  7,  1, 14,  2, 13,  6, 15,  0,  9, 10,  4,  5,  3}},
+
+	{{12,  1, 10, 15,  9,  2,  6,  8,  0, 13,  3,  4, 14,  7,  5, 11},
+	 {10, 15,  4,  2,  7, 12,  9,  5,  6,  1, 13, 14,  0, 11,  3,  8},
+	 {9, 14, 15,  5,  2,  8, 12,  3,  7,  0,  4, 10,  1, 13, 11,  6},
+	 {4,  3,  2, 12,  9,  5, 15, 10, 11, 14,  1,  7,  6,  0,  8, 13}},
+
+	{{4, 11,  2, 14, 15,  0,  8, 13,  3, 12,  9,  7,  5, 10,  6,  1},
+	 {13,  0, 11,  7,  4,  9,  1, 10, 14,  3,  5, 12,  2, 15,  8,  6},
+	 {1,  4, 11, 13, 12,  3,  7, 14, 10, 15,  6,  8,  0,  5,  9,  2},
+	 {6, 11, 13,  8,  1,  4, 10,  7,  9,  5,  0, 15, 14,  2,  3, 12}},
+
+	{{13,  2,  8,  4,  6, 15, 11,  1, 10,  9,  3, 14,  5,  0, 12,  7},
+	 {1, 15, 13,  8, 10,  3,  7,  4, 12,  5,  6, 11,  0, 14,  9,  2},
+	 {7, 11,  4,  1,  9, 12, 14,  2,  0,  6, 10, 13, 15,  3,  5,  8},
+	 {2,  1, 14,  7,  4, 10,  8, 13, 15, 12,  9,  0,  3,  5,  6, 11}}};
+
+static void permute(char *out, char *in, uchar *p, int n)
+{
+	int i;
+	for (i=0;i<n;i++)
+		out[i] = in[p[i]-1];
+}
+
+static void lshift(char *d, int count, int n)
+{
+	char out[64];
+	int i;
+	for (i=0;i<n;i++)
+		out[i] = d[(i+count)%n];
+	for (i=0;i<n;i++)
+		d[i] = out[i];
+}
+
+static void concat(char *out, char *in1, char *in2, int l1, int l2)
+{
+	while (l1--)
+		*out++ = *in1++;
+	while (l2--)
+		*out++ = *in2++;
+}
+
+static void xor(char *out, char *in1, char *in2, int n)
+{
+	int i;
+	for (i=0;i<n;i++)
+		out[i] = in1[i] ^ in2[i];
+}
+
+static void dohash(char *out, char *in, char *key, int forw)
+{
+	int i, j, k;
+	char pk1[56];
+	char c[28];
+	char d[28];
+	char cd[56];
+	char ki[16][48];
+	char pd1[64];
+	char l[32], r[32];
+	char rl[64];
+
+	permute(pk1, key, perm1, 56);
+
+	for (i=0;i<28;i++)
+		c[i] = pk1[i];
+	for (i=0;i<28;i++)
+		d[i] = pk1[i+28];
+
+	for (i=0;i<16;i++) {
+		lshift(c, sc[i], 28);
+		lshift(d, sc[i], 28);
+
+		concat(cd, c, d, 28, 28); 
+		permute(ki[i], cd, perm2, 48); 
+	}
+
+	permute(pd1, in, perm3, 64);
+
+	for (j=0;j<32;j++) {
+		l[j] = pd1[j];
+		r[j] = pd1[j+32];
+	}
+
+	for (i=0;i<16;i++) {
+		char er[48];
+		char erk[48];
+		char b[8][6];
+		char cb[32];
+		char pcb[32];
+		char r2[32];
+
+		permute(er, r, perm4, 48);
+
+		xor(erk, er, ki[forw ? i : 15 - i], 48);
+
+		for (j=0;j<8;j++)
+			for (k=0;k<6;k++)
+				b[j][k] = erk[j*6 + k];
+
+		for (j=0;j<8;j++) {
+			int m, n;
+			m = (b[j][0]<<1) | b[j][5];
+
+			n = (b[j][1]<<3) | (b[j][2]<<2) | (b[j][3]<<1) | b[j][4]; 
+
+			for (k=0;k<4;k++) 
+				b[j][k] = (sbox[j][m][n] & (1<<(3-k)))?1:0; 
+		}
+
+		for (j=0;j<8;j++)
+			for (k=0;k<4;k++)
+				cb[j*4+k] = b[j][k];
+		permute(pcb, cb, perm5, 32);
+
+		xor(r2, l, pcb, 32);
+
+		for (j=0;j<32;j++)
+			l[j] = r[j];
+
+		for (j=0;j<32;j++)
+			r[j] = r2[j];
+	}
+
+	concat(rl, r, l, 32, 32);
+
+	permute(out, rl, perm6, 64);
+}
+
+static void str_to_key(unsigned char *str,unsigned char *key)
+{
+	int i;
+
+	key[0] = str[0]>>1;
+	key[1] = ((str[0]&0x01)<<6) | (str[1]>>2);
+	key[2] = ((str[1]&0x03)<<5) | (str[2]>>3);
+	key[3] = ((str[2]&0x07)<<4) | (str[3]>>4);
+	key[4] = ((str[3]&0x0F)<<3) | (str[4]>>5);
+	key[5] = ((str[4]&0x1F)<<2) | (str[5]>>6);
+	key[6] = ((str[5]&0x3F)<<1) | (str[6]>>7);
+	key[7] = str[6]&0x7F;
+	for (i=0;i<8;i++) {
+		key[i] = (key[i]<<1);
+	}
+}
+
+
+static void smbhash(unsigned char *out, unsigned char *in, unsigned char *key, int forw)
+{
+	int i;
+	char outb[64];
+	char inb[64];
+	char keyb[64];
+	unsigned char key2[8];
+
+	str_to_key(key, key2);
+
+	for (i=0;i<64;i++) {
+		inb[i] = (in[i/8] & (1<<(7-(i%8)))) ? 1 : 0;
+		keyb[i] = (key2[i/8] & (1<<(7-(i%8)))) ? 1 : 0;
+		outb[i] = 0;
+	}
+
+	dohash(outb, inb, keyb, forw);
+
+	for (i=0;i<8;i++) {
+		out[i] = 0;
+	}
+
+	for (i=0;i<64;i++) {
+		if (outb[i])
+			out[i/8] |= (1<<(7-(i%8)));
+	}
+}
+
+void E_P16(unsigned char *p14,unsigned char *p16)
+{
+	unsigned char sp8[8] = {0x4b, 0x47, 0x53, 0x21, 0x40, 0x23, 0x24, 0x25};
+	smbhash(p16, sp8, p14, 1);
+	smbhash(p16+8, sp8, p14+7, 1);
+}
+
+void E_P24(unsigned char *p21, unsigned char *c8, unsigned char *p24)
+{
+	smbhash(p24, c8, p21, 1);
+	smbhash(p24+8, c8, p21+7, 1);
+	smbhash(p24+16, c8, p21+14, 1);
+}
+
+void D_P16(unsigned char *p14, unsigned char *in, unsigned char *out)
+{
+	smbhash(out, in, p14, 0);
+        smbhash(out+8, in+8, p14+7, 0);
+}
+
+void E_old_pw_hash( unsigned char *p14, unsigned char *in, unsigned char *out)
+{
+        smbhash(out, in, p14, 1);
+        smbhash(out+8, in+8, p14+7, 1);
+}
+
+void cred_hash1(unsigned char *out,unsigned char *in,unsigned char *key)
+{
+	unsigned char buf[8];
+
+	smbhash(buf, in, key, 1);
+	smbhash(out, buf, key+9, 1);
+}
+
+void cred_hash2(unsigned char *out,unsigned char *in,unsigned char *key)
+{
+	unsigned char buf[8];
+	static unsigned char key2[8];
+
+	smbhash(buf, in, key, 1);
+	key2[0] = key[7];
+	smbhash(out, buf, key2, 1);
+}
+
+void cred_hash3(unsigned char *out,unsigned char *in,unsigned char *key, int forw)
+{
+        static unsigned char key2[8];
+
+        smbhash(out, in, key, forw);
+        key2[0] = key[7];
+        smbhash(out + 8, in + 8, key2, forw);
+}
+
+void SamOEMhash( unsigned char *data, unsigned char *key, int val)
+{
+  unsigned char s_box[256];
+  unsigned char index_i = 0;
+  unsigned char index_j = 0;
+  unsigned char j = 0;
+  int ind;
+
+  for (ind = 0; ind < 256; ind++)
+  {
+    s_box[ind] = (unsigned char)ind;
+  }
+
+  for( ind = 0; ind < 256; ind++)
+  {
+     unsigned char tc;
+
+     j += (s_box[ind] + key[ind%16]);
+
+     tc = s_box[ind];
+     s_box[ind] = s_box[j];
+     s_box[j] = tc;
+  }
+  for( ind = 0; ind < (val ? 516 : 16); ind++)
+  {
+    unsigned char tc;
+    unsigned char t;
+
+    index_i++;
+    index_j += s_box[index_i];
+
+    tc = s_box[index_i];
+    s_box[index_i] = s_box[index_j];
+    s_box[index_j] = tc;
+
+    t = s_box[index_i] + s_box[index_j];
+    data[ind] = data[ind] ^ s_box[t];
+  }
+}
diff --git a/libntlm-0.21/smbdes.h b/libntlm-0.21/smbdes.h
new file mode 100644
index 00000000..f890fcd5
--- /dev/null
+++ b/libntlm-0.21/smbdes.h
@@ -0,0 +1,9 @@
+
+extern void E_P16(unsigned char *p14,unsigned char *p16);
+extern void E_P24(unsigned char *p21, unsigned char *c8, unsigned char *p24);
+extern void D_P16(unsigned char *p14, unsigned char *in, unsigned char *out);
+extern void E_old_pw_hash( unsigned char *p14, unsigned char *in, unsigned char *out);
+extern void cred_hash1(unsigned char *out,unsigned char *in,unsigned char *key);
+extern void cred_hash2(unsigned char *out,unsigned char *in,unsigned char *key);
+extern void cred_hash3(unsigned char *out,unsigned char *in,unsigned char *key, int forw);
+extern void SamOEMhash( unsigned char *data, unsigned char *key, int val);
diff --git a/libntlm-0.21/smbencrypt.c b/libntlm-0.21/smbencrypt.c
new file mode 100644
index 00000000..e58f0d41
--- /dev/null
+++ b/libntlm-0.21/smbencrypt.c
@@ -0,0 +1,323 @@
+/* 
+   Unix SMB/Netbios implementation.
+   Version 1.9.
+   SMB parameters and setup
+   Copyright (C) Andrew Tridgell 1992-1998
+   Modified by Jeremy Allison 1995.
+   
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+   
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#define DEBUG(a,b) ;
+
+extern int DEBUGLEVEL;
+
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <ctype.h>
+#include "smbbyteorder.h"
+#include "smbdes.h"
+#include "smbmd4.h"
+
+typedef unsigned char uchar;
+typedef signed short int16;
+typedef unsigned short uint16;
+typedef int BOOL;
+#define False 0
+#define True  1
+
+/****************************************************************************
+ Like strncpy but always null terminates. Make sure there is room!
+ The variable n should always be one less than the available size.
+****************************************************************************/
+
+char *StrnCpy(char *dest,const char *src, size_t n)
+{
+  char *d = dest;
+  if (!dest) return(NULL);
+  if (!src) {
+    *dest = 0;
+    return(dest);
+  }
+  while (n-- && (*d++ = *src++)) ;
+  *d = 0;
+  return(dest);
+}
+
+size_t skip_multibyte_char(char c)
+{
+return 0;
+}
+
+
+/*******************************************************************
+safe string copy into a known length string. maxlength does not
+include the terminating zero.
+********************************************************************/
+
+char *safe_strcpy(char *dest,const char *src, size_t maxlength)
+{
+    size_t len;
+
+    if (!dest) {
+        DEBUG(0,("ERROR: NULL dest in safe_strcpy\n"));
+        return NULL;
+    }
+
+    if (!src) {
+        *dest = 0;
+        return dest;
+    }  
+
+    len = strlen(src);
+
+    if (len > maxlength) {
+            DEBUG(0,("ERROR: string overflow by %d in safe_strcpy [%.50s]\n",
+                     (int)(len-maxlength), src));
+            len = maxlength;
+    }
+      
+    memcpy(dest, src, len);
+    dest[len] = 0;
+    return dest;
+}  
+
+
+void strupper(char *s)
+{
+while (*s)
+  {
+    {
+    size_t skip = skip_multibyte_char( *s );
+    if( skip != 0 )
+      s += skip;
+    else
+      {
+      if (islower(*s))
+	*s = toupper(*s);
+      s++;
+      }
+    }
+  }
+}
+
+extern void SMBOWFencrypt(uchar passwd[16], uchar *c8, uchar p24[24]);
+
+/*
+ This implements the X/Open SMB password encryption
+ It takes a password, a 8 byte "crypt key" and puts 24 bytes of 
+ encrypted password into p24 
+ */
+
+void SMBencrypt(uchar *passwd, uchar *c8, uchar *p24)
+  {
+  uchar p14[15], p21[21];
+  
+  memset(p21,'\0',21);
+  memset(p14,'\0',14);
+  StrnCpy((char *)p14,(char *)passwd,14);
+  
+  strupper((char *)p14);
+  E_P16(p14, p21); 
+  
+  SMBOWFencrypt(p21, c8, p24);
+  
+#ifdef DEBUG_PASSWORD
+  DEBUG(100,("SMBencrypt: lm#, challenge, response\n"));
+  dump_data(100, (char *)p21, 16);
+  dump_data(100, (char *)c8, 8);
+  dump_data(100, (char *)p24, 24);
+#endif
+  }
+
+/* Routines for Windows NT MD4 Hash functions. */
+static int _my_wcslen(int16 *str)
+{
+	int len = 0;
+	while(*str++ != 0)
+		len++;
+	return len;
+}
+
+/*
+ * Convert a string into an NT UNICODE string.
+ * Note that regardless of processor type 
+ * this must be in intel (little-endian)
+ * format.
+ */
+ 
+static int _my_mbstowcs(int16 *dst, uchar *src, int len)
+{
+	int i;
+	int16 val;
+ 
+	for(i = 0; i < len; i++) {
+		val = *src;
+		SSVAL(dst,0,val);
+		dst++;
+		src++;
+		if(val == 0)
+			break;
+	}
+	return i;
+}
+
+/* 
+ * Creates the MD4 Hash of the users password in NT UNICODE.
+ */
+ 
+void E_md4hash(uchar *passwd, uchar *p16)
+{
+	int len;
+	int16 wpwd[129];
+	
+	/* Password cannot be longer than 128 characters */
+	len = strlen((char *)passwd);
+	if(len > 128)
+		len = 128;
+	/* Password must be converted to NT unicode */
+	_my_mbstowcs(wpwd, passwd, len);
+	wpwd[len] = 0; /* Ensure string is null terminated */
+	/* Calculate length in bytes */
+	len = _my_wcslen(wpwd) * sizeof(int16);
+
+	mdfour(p16, (unsigned char *)wpwd, len);
+}
+
+/* Does both the NT and LM owfs of a user's password */
+void nt_lm_owf_gen(char *pwd, uchar nt_p16[16], uchar p16[16])
+{
+	char passwd[130];
+
+	memset(passwd,'\0',130);
+	safe_strcpy( passwd, pwd, sizeof(passwd)-1);
+
+	/* Calculate the MD4 hash (NT compatible) of the password */
+	memset(nt_p16, '\0', 16);
+	E_md4hash((uchar *)passwd, nt_p16);
+
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("nt_lm_owf_gen: pwd, nt#\n"));
+	dump_data(120, passwd, strlen(passwd));
+	dump_data(100, (char *)nt_p16, 16);
+#endif
+
+	/* Mangle the passwords into Lanman format */
+	passwd[14] = '\0';
+	strupper(passwd);
+
+	/* Calculate the SMB (lanman) hash functions of the password */
+
+	memset(p16, '\0', 16);
+	E_P16((uchar *) passwd, (uchar *)p16);
+
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("nt_lm_owf_gen: pwd, lm#\n"));
+	dump_data(120, passwd, strlen(passwd));
+	dump_data(100, (char *)p16, 16);
+#endif
+	/* clear out local copy of user's password (just being paranoid). */
+	memset(passwd, '\0', sizeof(passwd));
+}
+
+/* Does the des encryption from the NT or LM MD4 hash. */
+void SMBOWFencrypt(uchar passwd[16], uchar *c8, uchar p24[24])
+{
+	uchar p21[21];
+ 
+	memset(p21,'\0',21);
+ 
+	memcpy(p21, passwd, 16);    
+	E_P24(p21, c8, p24);
+}
+
+/* Does the des encryption from the FIRST 8 BYTES of the NT or LM MD4 hash. */
+void NTLMSSPOWFencrypt(uchar passwd[8], uchar *ntlmchalresp, uchar p24[24])
+{
+	uchar p21[21];
+ 
+	memset(p21,'\0',21);
+	memcpy(p21, passwd, 8);    
+	memset(p21 + 8, 0xbd, 8);    
+
+	E_P24(p21, ntlmchalresp, p24);
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("NTLMSSPOWFencrypt: p21, c8, p24\n"));
+	dump_data(100, (char *)p21, 21);
+	dump_data(100, (char *)ntlmchalresp, 8);
+	dump_data(100, (char *)p24, 24);
+#endif
+}
+
+
+/* Does the NT MD4 hash then des encryption. */
+ 
+void SMBNTencrypt(uchar *passwd, uchar *c8, uchar *p24)
+{
+	uchar p21[21];
+ 
+	memset(p21,'\0',21);
+ 
+	E_md4hash(passwd, p21);    
+	SMBOWFencrypt(p21, c8, p24);
+
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("SMBNTencrypt: nt#, challenge, response\n"));
+	dump_data(100, (char *)p21, 16);
+	dump_data(100, (char *)c8, 8);
+	dump_data(100, (char *)p24, 24);
+#endif
+}
+
+#if 0
+
+BOOL make_oem_passwd_hash(char data[516], const char *passwd, uchar old_pw_hash[16], BOOL unicode)
+{
+	int new_pw_len = strlen(passwd) * (unicode ? 2 : 1);
+
+	if (new_pw_len > 512)
+	{
+		DEBUG(0,("make_oem_passwd_hash: new password is too long.\n"));
+		return False;
+	}
+
+	/*
+	 * Now setup the data area.
+	 * We need to generate a random fill
+	 * for this area to make it harder to
+	 * decrypt. JRA.
+	 */
+	generate_random_buffer((unsigned char *)data, 516, False);
+	if (unicode)
+	{
+		struni2( &data[512 - new_pw_len], passwd);
+	}
+	else
+	{
+		fstrcpy( &data[512 - new_pw_len], passwd);
+	}
+	SIVAL(data, 512, new_pw_len);
+
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("make_oem_passwd_hash\n"));
+	dump_data(100, data, 516);
+#endif
+	SamOEMhash( (unsigned char *)data, (unsigned char *)old_pw_hash, True);
+
+	return True;
+}
+
+#endif
diff --git a/libntlm-0.21/smbencrypt.h b/libntlm-0.21/smbencrypt.h
new file mode 100644
index 00000000..0f33b062
--- /dev/null
+++ b/libntlm-0.21/smbencrypt.h
@@ -0,0 +1,2 @@
+void SMBencrypt(char *passwd, uint8 *c8, uint8 *p24);
+void SMBNTencrypt(char *passwd, uint8 *c8, uint8 *p24);
diff --git a/libntlm-0.21/smbmd4.c b/libntlm-0.21/smbmd4.c
new file mode 100644
index 00000000..f43d797d
--- /dev/null
+++ b/libntlm-0.21/smbmd4.c
@@ -0,0 +1,172 @@
+/* 
+   Unix SMB/Netbios implementation.
+   Version 1.9.
+   a implementation of MD4 designed for use in the SMB authentication protocol
+   Copyright (C) Andrew Tridgell 1997-1998.
+   
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+   
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#include "smbmd4.h"
+
+typedef unsigned uint32;
+
+/* NOTE: This code makes no attempt to be fast! 
+
+   It assumes that a int is at least 32 bits long
+*/
+
+static uint32 A, B, C, D;
+
+static uint32 F(uint32 X, uint32 Y, uint32 Z)
+{
+	return (X&Y) | ((~X)&Z);
+}
+
+static uint32 G(uint32 X, uint32 Y, uint32 Z)
+{
+	return (X&Y) | (X&Z) | (Y&Z); 
+}
+
+static uint32 H(uint32 X, uint32 Y, uint32 Z)
+{
+	return X^Y^Z;
+}
+
+static uint32 lshift(uint32 x, int s)
+{
+	x &= 0xFFFFFFFF;
+	return ((x<<s)&0xFFFFFFFF) | (x>>(32-s));
+}
+
+#define ROUND1(a,b,c,d,k,s) a = lshift(a + F(b,c,d) + X[k], s)
+#define ROUND2(a,b,c,d,k,s) a = lshift(a + G(b,c,d) + X[k] + (uint32)0x5A827999,s)
+#define ROUND3(a,b,c,d,k,s) a = lshift(a + H(b,c,d) + X[k] + (uint32)0x6ED9EBA1,s)
+
+/* this applies md4 to 64 byte chunks */
+static void mdfour64(uint32 *M)
+{
+	int j;
+	uint32 AA, BB, CC, DD;
+	uint32 X[16];
+
+	for (j=0;j<16;j++)
+		X[j] = M[j];
+
+	AA = A; BB = B; CC = C; DD = D;
+
+        ROUND1(A,B,C,D,  0,  3);  ROUND1(D,A,B,C,  1,  7);  
+	ROUND1(C,D,A,B,  2, 11);  ROUND1(B,C,D,A,  3, 19);
+        ROUND1(A,B,C,D,  4,  3);  ROUND1(D,A,B,C,  5,  7);  
+	ROUND1(C,D,A,B,  6, 11);  ROUND1(B,C,D,A,  7, 19);
+        ROUND1(A,B,C,D,  8,  3);  ROUND1(D,A,B,C,  9,  7);  
+	ROUND1(C,D,A,B, 10, 11);  ROUND1(B,C,D,A, 11, 19);
+        ROUND1(A,B,C,D, 12,  3);  ROUND1(D,A,B,C, 13,  7);  
+	ROUND1(C,D,A,B, 14, 11);  ROUND1(B,C,D,A, 15, 19);	
+
+        ROUND2(A,B,C,D,  0,  3);  ROUND2(D,A,B,C,  4,  5);  
+	ROUND2(C,D,A,B,  8,  9);  ROUND2(B,C,D,A, 12, 13);
+        ROUND2(A,B,C,D,  1,  3);  ROUND2(D,A,B,C,  5,  5);  
+	ROUND2(C,D,A,B,  9,  9);  ROUND2(B,C,D,A, 13, 13);
+        ROUND2(A,B,C,D,  2,  3);  ROUND2(D,A,B,C,  6,  5);  
+	ROUND2(C,D,A,B, 10,  9);  ROUND2(B,C,D,A, 14, 13);
+        ROUND2(A,B,C,D,  3,  3);  ROUND2(D,A,B,C,  7,  5);  
+	ROUND2(C,D,A,B, 11,  9);  ROUND2(B,C,D,A, 15, 13);
+
+	ROUND3(A,B,C,D,  0,  3);  ROUND3(D,A,B,C,  8,  9);  
+	ROUND3(C,D,A,B,  4, 11);  ROUND3(B,C,D,A, 12, 15);
+        ROUND3(A,B,C,D,  2,  3);  ROUND3(D,A,B,C, 10,  9);  
+	ROUND3(C,D,A,B,  6, 11);  ROUND3(B,C,D,A, 14, 15);
+        ROUND3(A,B,C,D,  1,  3);  ROUND3(D,A,B,C,  9,  9);  
+	ROUND3(C,D,A,B,  5, 11);  ROUND3(B,C,D,A, 13, 15);
+        ROUND3(A,B,C,D,  3,  3);  ROUND3(D,A,B,C, 11,  9);  
+	ROUND3(C,D,A,B,  7, 11);  ROUND3(B,C,D,A, 15, 15);
+
+	A += AA; B += BB; C += CC; D += DD;
+	
+	A &= 0xFFFFFFFF; B &= 0xFFFFFFFF;
+	C &= 0xFFFFFFFF; D &= 0xFFFFFFFF;
+
+	for (j=0;j<16;j++)
+		X[j] = 0;
+}
+
+static void copy64(uint32 *M, unsigned char *in)
+{
+	int i;
+
+	for (i=0;i<16;i++)
+		M[i] = (in[i*4+3]<<24) | (in[i*4+2]<<16) |
+			(in[i*4+1]<<8) | (in[i*4+0]<<0);
+}
+
+static void copy4(unsigned char *out,uint32 x)
+{
+	out[0] = x&0xFF;
+	out[1] = (x>>8)&0xFF;
+	out[2] = (x>>16)&0xFF;
+	out[3] = (x>>24)&0xFF;
+}
+
+/* produce a md4 message digest from data of length n bytes */
+void mdfour(unsigned char *out, unsigned char *in, int n)
+{
+	unsigned char buf[128];
+	uint32 M[16];
+	uint32 b = n * 8;
+	int i;
+
+	A = 0x67452301;
+	B = 0xefcdab89;
+	C = 0x98badcfe;
+	D = 0x10325476;
+
+	while (n > 64) {
+		copy64(M, in);
+		mdfour64(M);
+		in += 64;
+		n -= 64;
+	}
+
+	for (i=0;i<128;i++)
+		buf[i] = 0;
+	memcpy(buf, in, n);
+	buf[n] = 0x80;
+	
+	if (n <= 55) {
+		copy4(buf+56, b);
+		copy64(M, buf);
+		mdfour64(M);
+	} else {
+		copy4(buf+120, b); 
+		copy64(M, buf);
+		mdfour64(M);
+		copy64(M, buf+64);
+		mdfour64(M);
+	}
+
+	for (i=0;i<128;i++)
+		buf[i] = 0;
+	copy64(M, buf);
+
+	copy4(out, A);
+	copy4(out+4, B);
+	copy4(out+8, C);
+	copy4(out+12, D);
+
+	A = B = C = D = 0;
+}
+
+
diff --git a/libntlm-0.21/smbmd4.h b/libntlm-0.21/smbmd4.h
new file mode 100644
index 00000000..af739949
--- /dev/null
+++ b/libntlm-0.21/smbmd4.h
@@ -0,0 +1 @@
+extern void mdfour(unsigned char *out, unsigned char *in, int n);
diff --git a/libntlm-0.21/smbutil.c b/libntlm-0.21/smbutil.c
new file mode 100644
index 00000000..415e0665
--- /dev/null
+++ b/libntlm-0.21/smbutil.c
@@ -0,0 +1,218 @@
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <ctype.h>
+#include <assert.h>
+#include <string.h>
+#include "ntlm.h"
+#include "smbencrypt.h"
+#include "smbbyteorder.h"
+
+char versionString[] ="libntlm version 0.21";
+
+/* Utility routines that handle NTLM auth structures. */
+
+/* The [IS]VAL macros are to take care of byte order for non-Intel
+ * Machines -- I think this file is OK, but it hasn't been tested.
+ * The other files (the ones stolen from Samba) should be OK.
+ */
+
+
+/* I am not crazy about these macros -- they seem to have gotten
+ * a bit complex.  A new scheme for handling string/buffer fields
+ * in the structures probably needs to be designed
+ */
+
+#define AddBytes(ptr, header, buf, count) \
+{ \
+if (buf && count) \
+  { \
+  SSVAL(&ptr->header.len,0,count); \
+  SSVAL(&ptr->header.maxlen,0,count); \
+  SIVAL(&ptr->header.offset,0,((ptr->buffer - ((uint8*)ptr)) + ptr->bufIndex)); \
+  memcpy(ptr->buffer+ptr->bufIndex, buf, count); \
+  ptr->bufIndex += count; \
+  } \
+else \
+  { \
+  ptr->header.len = \
+  ptr->header.maxlen = 0; \
+  SIVAL(&ptr->header.offset,0,ptr->bufIndex); \
+  } \
+}
+
+#define AddString(ptr, header, string) \
+{ \
+char *p = string; \
+int len = 0; \
+if (p) len = strlen(p); \
+AddBytes(ptr, header, ((unsigned char*)p), len); \
+}
+
+#define AddUnicodeString(ptr, header, string) \
+{ \
+char *p = string; \
+unsigned char *b = NULL; \
+int len = 0; \
+if (p) \
+  { \
+  len = strlen(p); \
+  b = strToUnicode(p); \
+  } \
+AddBytes(ptr, header, b, len*2); \
+}
+
+
+#define GetUnicodeString(structPtr, header) \
+unicodeToString(((char*)structPtr) + IVAL(&structPtr->header.offset,0) , SVAL(&structPtr->header.len,0)/2)
+#define GetString(structPtr, header) \
+toString((((char *)structPtr) + IVAL(&structPtr->header.offset,0)), SVAL(&structPtr->header.len,0))
+#define DumpBuffer(fp, structPtr, header) \
+dumpRaw(fp,((unsigned char*)structPtr)+IVAL(&structPtr->header.offset,0),SVAL(&structPtr->header.len,0))
+
+
+static void dumpRaw(FILE *fp, unsigned char *buf, size_t len)
+  {
+  int i;
+  
+  for (i=0; i<len; ++i)
+    fprintf(fp,"%02x ",buf[i]);
+    
+    fprintf(fp,"\n");
+  }
+
+static char *unicodeToString(char *p, size_t len)
+  {
+  int i;
+  static char buf[1024];
+
+  assert(len+1 < sizeof buf);
+  
+  for (i=0; i<len; ++i)
+    {  
+    buf[i] = *p & 0x7f;
+    p += 2;
+    }
+
+  buf[i] = '\0';
+  return buf;
+  }
+
+static unsigned char *strToUnicode(char *p)
+  {
+  static unsigned char buf[1024];
+  size_t l = strlen(p);
+  int i = 0;
+  
+  assert(l*2 < sizeof buf);
+  
+  while (l--)
+    {
+    buf[i++] = *p++;
+    buf[i++] = 0;
+    }
+  
+  return buf;
+  }
+
+static unsigned char *toString(char *p, size_t len)
+  {
+  static unsigned char buf[1024];
+  
+  assert(len+1 < sizeof buf);
+  
+  memcpy(buf,p,len);
+  buf[len] = 0;
+  return buf;
+  }
+
+void dumpSmbNtlmAuthRequest(FILE *fp, tSmbNtlmAuthRequest *request)
+  {
+  fprintf(fp,"NTLM Request:\n");
+  fprintf(fp,"      Ident = %s\n",request->ident);
+  fprintf(fp,"      mType = %d\n",IVAL(&request->msgType,0));
+  fprintf(fp,"      Flags = %08x\n",IVAL(&request->flags,0));
+  fprintf(fp,"       User = %s\n",GetString(request,user));
+  fprintf(fp,"     Domain = %s\n",GetString(request,domain));
+  }
+
+void dumpSmbNtlmAuthChallenge(FILE *fp, tSmbNtlmAuthChallenge *challenge)
+  {
+  fprintf(fp,"NTLM Challenge:\n");
+  fprintf(fp,"      Ident = %s\n",challenge->ident);
+  fprintf(fp,"      mType = %d\n",IVAL(&challenge->msgType,0));
+  fprintf(fp,"     Domain = %s\n",GetUnicodeString(challenge,uDomain));
+  fprintf(fp,"      Flags = %08x\n",IVAL(&challenge->flags,0));
+  fprintf(fp,"  Challenge = "); dumpRaw(fp, challenge->challengeData,8);
+  }
+
+void dumpSmbNtlmAuthResponse(FILE *fp, tSmbNtlmAuthResponse *response)
+  {
+  fprintf(fp,"NTLM Response:\n");
+  fprintf(fp,"      Ident = %s\n",response->ident);
+  fprintf(fp,"      mType = %d\n",IVAL(&response->msgType,0));
+  fprintf(fp,"     LmResp = "); DumpBuffer(fp,response,lmResponse);
+  fprintf(fp,"     NTResp = "); DumpBuffer(fp,response,ntResponse);
+  fprintf(fp,"     Domain = %s\n",GetUnicodeString(response,uDomain));
+  fprintf(fp,"       User = %s\n",GetUnicodeString(response,uUser));
+  fprintf(fp,"        Wks = %s\n",GetUnicodeString(response,uWks));
+  fprintf(fp,"       sKey = "); DumpBuffer(fp, response,sessionKey);
+  fprintf(fp,"      Flags = %08x\n",IVAL(&response->flags,0));
+  }
+
+void buildSmbNtlmAuthRequest(tSmbNtlmAuthRequest *request, char *user, char *domain)
+  {
+    char *u = strdup(user);
+    char *p = strchr(u,'@');
+    
+    if (p)
+      {
+        if (!domain) 
+          domain = p+1;
+        *p = '\0';
+      }
+    
+    request->bufIndex = 0;
+    memcpy(request->ident,"NTLMSSP\0\0\0",8);
+    SIVAL(&request->msgType,0,1);
+    SIVAL(&request->flags,0,0x0000b207);  /* have to figure out what these mean */
+    AddString(request,user,u);
+    AddString(request,domain,domain);
+    free(u);
+  }
+
+void buildSmbNtlmAuthResponse(tSmbNtlmAuthChallenge *challenge, tSmbNtlmAuthResponse *response, char *user, char *password)
+  {
+    uint8 lmRespData[24];
+    uint8 ntRespData[24];
+    char *d = strdup(GetUnicodeString(challenge,uDomain));
+    char *domain = d;
+    char *u = strdup(user);
+    char *p = strchr(u,'@');
+    
+    if (p)
+      {
+        domain = p+1;
+        *p = '\0';
+      }
+    
+    SMBencrypt(password,   challenge->challengeData, lmRespData);
+    SMBNTencrypt(password, challenge->challengeData, ntRespData);
+    
+    response->bufIndex = 0;
+    memcpy(response->ident,"NTLMSSP\0\0\0",8);
+    SIVAL(&response->msgType,0,3);
+    
+    AddBytes(response,lmResponse,lmRespData,24);
+    AddBytes(response,ntResponse,ntRespData,24);
+    AddUnicodeString(response,uDomain,domain);
+    AddUnicodeString(response,uUser,u);
+    AddUnicodeString(response,uWks,u);
+    AddString(response,sessionKey,NULL);
+  
+    response->flags = challenge->flags;
+    
+    free(d);
+    free(u);
+  }
+    
diff --git a/libntlm-0.21/test/COPYING b/libntlm-0.21/test/COPYING
new file mode 100755
index 00000000..a43ea212
--- /dev/null
+++ b/libntlm-0.21/test/COPYING
@@ -0,0 +1,339 @@
+		    GNU GENERAL PUBLIC LICENSE
+		       Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+                          675 Mass Ave, Cambridge, MA 02139, USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+			    Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+		    GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+			    NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+		     END OF TERMS AND CONDITIONS
+
+	Appendix: How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the program's name and a brief idea of what it does.>
+    Copyright (C) 19yy  <name of author>
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+    Gnomovision version 69, Copyright (C) 19yy name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  <signature of Ty Coon>, 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
diff --git a/libntlm-0.21/test/Makefile b/libntlm-0.21/test/Makefile
new file mode 100644
index 00000000..d99dcb09
--- /dev/null
+++ b/libntlm-0.21/test/Makefile
@@ -0,0 +1,6 @@
+dumper: dumper.c getargs.o
+	gcc -g -I.. -o dumper dumper.c getargs.o ../libntlm.a
+	
+clean:
+	rm -f *.a *.o dumper *.bak *~ \#*\#
+
diff --git a/libntlm-0.21/test/README b/libntlm-0.21/test/README
new file mode 100644
index 00000000..bcff72ac
--- /dev/null
+++ b/libntlm-0.21/test/README
@@ -0,0 +1,19 @@
+
+Dumper is a simple command line utility to display in readable
+format base64 NTLM messages.  Given a base64 NTLM challenge, a
+username and a password, it will optionally generate and
+display a response message.  
+
+Note that there are multiple correct response messages message
+depending on what order the string data is placed at the end of
+the frame. There is no required order. Dumper should always
+generate the string data in the same order (and thus identical
+base64 responses), even on different architectures.
+
+It's possible that another application will generate a
+different but also correct response message.
+
+Run "dumper -?" for help.
+
+Someday I'll write more documentation...
+
diff --git a/libntlm-0.21/test/dumper.c b/libntlm-0.21/test/dumper.c
new file mode 100644
index 00000000..aa84d127
--- /dev/null
+++ b/libntlm-0.21/test/dumper.c
@@ -0,0 +1,237 @@
+#include <stdlib.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <ntlm.h>
+
+#include "getargs.h"
+
+int from64tobits(char *out, const char *in);
+void to64frombits(unsigned char *out, const unsigned char *in, int inlen);
+
+int dumpReq;
+int dumpChal;
+int dumpResp;
+int genResp;
+int dumpRaw;
+int dumpb64only;
+int genReq;
+
+char *username = "joeuser";
+char *password = "joespw";
+
+argSpec argSpecArray[] =
+{
+ {'q', OptionBoolean, &dumpReq, NULL, "dump NTLM request", NULL},
+ {'Q', OptionBoolean, &genReq,  NULL, "generate (and dump) NTLM request", NULL},
+ {'c', OptionBoolean, &dumpChal, NULL, "dump NTLM challange", NULL},
+ {'g', OptionBoolean, &genResp, NULL, "generate (and dump) NTLM response given a challenge", NULL},
+ {'r', OptionBoolean, &dumpResp, NULL, "dump NTLM response", NULL},
+ {'R', OptionBoolean, &dumpRaw, NULL, "dump raw bytes", NULL},
+ {'6', OptionBoolean, &dumpb64only, NULL, "dump generated base64 only", NULL},
+ {'u', OptionString,  &username, NULL, "username", NULL},
+ {'p', OptionString,  &password, NULL, "password", NULL},
+};
+
+int argSpecCount = (sizeof argSpecArray / sizeof argSpecArray[0]);
+char *progName;
+
+void usage(void)
+{
+  printf("usage: %s [options] [base-64-string]\n", progName);
+  printf("       %s -?     will display options\n", progName);
+}
+
+unsigned char buf[4096];
+unsigned char buf2[4096];
+
+int main(int argc, char *argv[])
+{
+  int rawLen = 0;
+  int argsUsed;
+  int i;
+  
+  progName = argv[0];
+  
+  argsUsed = getargs(argc, argv, argSpecArray, argSpecCount);
+
+  if (argsUsed < 0)
+    {
+      usage();
+      exit(1);
+    }
+ 
+  argc -= argsUsed;
+  argv += argsUsed;
+
+  if (argc != 1 && argc != 0)
+    {
+      usage();
+      exit(1);
+    }
+  
+  
+  if (argc == 1)
+    {
+      rawLen = from64tobits(buf,argv[0]);
+      if (genReq)
+        fprintf(stderr,"%s: extra argument with -Q ignored\n",progName);
+    }
+  else
+    {
+      if (dumpReq || dumpChal || dumpResp || dumpRaw)
+        {
+          fprintf(stderr,"%s: -q -r -c -R specified but no base64 data\n",progName);
+          return 1;
+        }
+    }
+  
+  
+  printf("Converted base64 string to %d data bytes\n",rawLen);
+  
+  if (dumpReq)
+    dumpSmbNtlmAuthRequest(stdout,(tSmbNtlmAuthRequest*)buf);
+  else if (dumpChal)
+    dumpSmbNtlmAuthChallenge(stdout,(tSmbNtlmAuthChallenge*)buf);
+  else if (dumpResp)
+    dumpSmbNtlmAuthResponse(stdout,(tSmbNtlmAuthResponse*)buf);
+  
+  if (dumpRaw)
+    for (i=0; i<rawLen; ++i)
+      printf("%3d: %02x\n",i,buf[i]);
+
+  if (genReq)
+    {
+      buildSmbNtlmAuthRequest((tSmbNtlmAuthRequest*)buf2,username,NULL);
+      to64frombits(buf, buf2, SmbLength((tSmbNtlmAuthResponse*)buf2));
+
+      printf("%s\n",buf);
+
+      if (!dumpb64only)
+        dumpSmbNtlmAuthRequest(stdout,(tSmbNtlmAuthRequest*)buf2);
+    }
+  
+  if (genResp)
+    {
+      buildSmbNtlmAuthResponse((tSmbNtlmAuthChallenge*)buf,
+                               (tSmbNtlmAuthResponse*)buf2,
+                               username,password);
+
+      to64frombits(buf, buf2, SmbLength((tSmbNtlmAuthResponse*)buf2));
+      
+      printf("%s\n",buf);
+
+      if (!dumpb64only)
+        dumpSmbNtlmAuthResponse(stdout,(tSmbNtlmAuthResponse*)buf2);
+    }
+  
+  return 0;
+}
+
+
+
+
+
+
+
+
+/*
+ * base64.c -- base-64 conversion routines.
+ *
+ * For license terms, see the file COPYING in this directory.
+ *
+ * This base 64 encoding is defined in RFC2045 section 6.8,
+ * "Base64 Content-Transfer-Encoding", but lines must not be broken in the
+ * scheme used here.
+ */
+
+/*
+ * This code borrowed from fetchmail sources
+ */
+
+
+static const char base64digits[] =
+   "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
+
+#define BAD	-1
+static const char base64val[] = {
+    BAD,BAD,BAD,BAD, BAD,BAD,BAD,BAD, BAD,BAD,BAD,BAD, BAD,BAD,BAD,BAD,
+    BAD,BAD,BAD,BAD, BAD,BAD,BAD,BAD, BAD,BAD,BAD,BAD, BAD,BAD,BAD,BAD,
+    BAD,BAD,BAD,BAD, BAD,BAD,BAD,BAD, BAD,BAD,BAD, 62, BAD,BAD,BAD, 63,
+     52, 53, 54, 55,  56, 57, 58, 59,  60, 61,BAD,BAD, BAD,BAD,BAD,BAD,
+    BAD,  0,  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,BAD, BAD,BAD,BAD,BAD,
+    BAD, 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,BAD, BAD,BAD,BAD,BAD
+};
+#define DECODE64(c)  (isascii(c) ? base64val[c] : BAD)
+
+void to64frombits(unsigned char *out, const unsigned char *in, int inlen)
+/* raw bytes in quasi-big-endian order to base 64 string (NUL-terminated) */
+{
+    for (; inlen >= 3; inlen -= 3)
+    {
+	*out++ = base64digits[in[0] >> 2];
+	*out++ = base64digits[((in[0] << 4) & 0x30) | (in[1] >> 4)];
+	*out++ = base64digits[((in[1] << 2) & 0x3c) | (in[2] >> 6)];
+	*out++ = base64digits[in[2] & 0x3f];
+	in += 3;
+    }
+    if (inlen > 0)
+    {
+	unsigned char fragment;
+    
+	*out++ = base64digits[in[0] >> 2];
+	fragment = (in[0] << 4) & 0x30;
+	if (inlen > 1)
+	    fragment |= in[1] >> 4;
+	*out++ = base64digits[fragment];
+	*out++ = (inlen < 2) ? '=' : base64digits[(in[1] << 2) & 0x3c];
+	*out++ = '=';
+    }
+    *out = '\0';
+}
+
+int from64tobits(char *out, const char *in)
+/* base 64 to raw bytes in quasi-big-endian order, returning count of bytes */
+{
+    int len = 0;
+    register unsigned char digit1, digit2, digit3, digit4;
+
+    if (in[0] == '+' && in[1] == ' ')
+	in += 2;
+    if (*in == '\r')
+	return(0);
+
+    do {
+	digit1 = in[0];
+	if (DECODE64(digit1) == BAD)
+	    return(-1);
+	digit2 = in[1];
+	if (DECODE64(digit2) == BAD)
+	    return(-1);
+	digit3 = in[2];
+	if (digit3 != '=' && DECODE64(digit3) == BAD)
+	    return(-1); 
+	digit4 = in[3];
+	if (digit4 != '=' && DECODE64(digit4) == BAD)
+	    return(-1);
+	in += 4;
+	*out++ = (DECODE64(digit1) << 2) | (DECODE64(digit2) >> 4);
+	++len;
+	if (digit3 != '=')
+	{
+	    *out++ = ((DECODE64(digit2) << 4) & 0xf0) | (DECODE64(digit3) >> 2);
+	    ++len;
+	    if (digit4 != '=')
+	    {
+		*out++ = ((DECODE64(digit3) << 6) & 0xc0) | DECODE64(digit4);
+		++len;
+	    }
+	}
+    } while 
+	(*in && *in != '\r' && digit4 != '=');
+
+    return (len);
+}
+
+/* base64.c ends here */
diff --git a/libntlm-0.21/test/getargs.c b/libntlm-0.21/test/getargs.c
new file mode 100644
index 00000000..ca81fc4d
--- /dev/null
+++ b/libntlm-0.21/test/getargs.c
@@ -0,0 +1,240 @@
+#include "getargs.h"
+#include <stdio.h>
+#include <string.h>
+
+double dummy(double x)
+{
+return x * 56.7;
+}
+
+static int findString(char *name, char **namelist)
+  {
+  int i;
+
+  for (i=0; *namelist; ++namelist, ++i)
+    if (!strcmp(name, *namelist))
+      return i;
+  return -1;
+  }
+
+static char *progName;
+
+typedef int (*fptrNoParam)(void);
+typedef int (*fptrParam)(char*);
+
+static void errorMsg(char c, const char *expected, const char *got)
+  {
+  fprintf(stderr,"%s: option -%c expected %s parameter, got '%s'\n",progName,c,expected,got);
+  }
+
+static void prOptions(argSpec arg[], int specCount)
+  {
+  int i;
+  fprintf(stderr,"%s: options: \n",progName);
+
+  for (i=0; i<specCount; ++i)
+    {
+    fprintf(stderr,"        -%c ",arg[i].optionChar);
+    switch (arg[i].optionType)
+      {
+      case OptionInteger:    fprintf(stderr,"<integer>  "); break;
+      case OptionLong:       fprintf(stderr,"<long>     "); break;
+      case OptionDouble:     fprintf(stderr,"<float>    "); break;
+      case OptionString:     fprintf(stderr,"<string>   "); break;
+      case OptionBoolean:    fprintf(stderr,"           "); break;
+      case OptionEnumerated: fprintf(stderr,"<string>   "); break;
+      }
+    fprintf(stderr,arg[i].helpString);
+    if (arg[i].optionType == OptionEnumerated)
+      {
+      char **s;
+      int d = *(unsigned*)arg[i].optionPtr;
+      int n;
+      fprintf(stderr,"\n");
+      fprintf(stderr,"                      where <string> is one of:\n");
+      for (n=0,s=arg[i].enumValues; *s; ++s,++n)
+	fprintf(stderr,"                          %s%s\n",*s,n==d ? " (default)" : "");
+      }
+    else
+      {
+      switch (arg[i].optionType)
+	{
+	case OptionInteger:    fprintf(stderr," (default %d)\n",*(int*)arg[i].optionPtr); break;
+	case OptionLong:       fprintf(stderr," (default %ld)\n",*(long*)arg[i].optionPtr); break;
+	case OptionDouble:     fprintf(stderr," (default %f)\n",*(double*)arg[i].optionPtr); break;
+	case OptionString:     fprintf(stderr," (default '%s')\n",*(char**)arg[i].optionPtr); break;
+	case OptionBoolean:    fprintf(stderr,"\n"); break;
+	case OptionEnumerated: break;
+	}
+      }
+    }
+  }
+
+union
+  {
+  int i;
+  long l;
+  double d;
+  char *p;
+  }trash;
+
+int getargs(int argc, char *argv[], argSpec arg[], int specCount)
+  {
+  int argsUsed;
+  char *p;
+  int a;
+  int argDone;
+
+  progName = argv[0];
+  argsUsed = 1;
+  ++argv;
+  
+  while (argsUsed < argc)
+    {
+    /* at this point, argv[0] is the next item to be processed */
+    
+    p = argv[0];
+
+    if (*p != '-')
+      return argsUsed;
+
+    ++argsUsed;
+    ++argv;
+
+    ++p;
+
+    if (*p =='?')
+      {
+      prOptions(arg,specCount);
+      return -1;
+      }
+
+    argDone = 0;
+
+    for (a=0; a<specCount;)
+      {
+      char *optionArgPtr = "";
+      void *optionPtr = &trash;
+
+      if (*p == arg[a].optionChar)
+	{
+	if (arg[a].optionType != OptionBoolean)
+	  {
+	  if (p[1] != '\0')
+	    optionArgPtr = p+1;
+	  else
+	    {
+	    optionArgPtr = argv[0];
+	    ++argsUsed;
+	    ++argv;
+	    }
+
+	  if (argsUsed > argc)
+	    {
+	    errorMsg(*p,"","");
+	    return -1;
+	    }
+	  }
+
+	if (arg[a].optionPtr)
+	  optionPtr = arg[a].optionPtr;
+
+	switch (arg[a].optionType)
+	  {
+	  case OptionInteger:
+	    {
+	    char *format = "%d";
+	    if (optionArgPtr[0]=='x')
+	      {
+	      format = "%x";
+	      ++optionArgPtr;
+	      }
+	    else if (optionArgPtr[0]=='0' && optionArgPtr[1]=='x')
+	      {
+	      format = "%x";
+	      optionArgPtr+=2;
+	      }
+
+	    if (sscanf(optionArgPtr,format,optionPtr) != 1)
+	      {
+	      errorMsg(*p,"integer",optionArgPtr);
+	      return -1;
+	      }
+	    break;
+	    }
+
+	  case OptionLong:
+	    if (sscanf(optionArgPtr,"%ld",(long*)optionPtr) != 1)
+	      {
+	      errorMsg(*p,"long",optionArgPtr);
+	      return -1;
+	      }
+	    break;
+
+	  case OptionString:
+	    *((char**)optionPtr) = strdup(optionArgPtr);
+	    break;
+
+	  case OptionDouble:
+	    if (sscanf(optionArgPtr,"%lf",(double*)optionPtr) != 1)
+	      {
+	      errorMsg(*p,"floating point",optionArgPtr);
+	      return -1;
+	      }
+	    break;
+
+	  case OptionBoolean:
+	    *((int*)optionPtr) = 1;
+	    break;
+
+	  case OptionEnumerated:
+	    if ((*((int*)optionPtr) = findString(optionArgPtr,arg[a].enumValues)) < 0)
+		{
+		char **n = arg[a].enumValues;
+		fprintf(stderr,"%s: option -%c expects parameter to be one of:\n",progName,*p);
+		while (*n)
+		  {
+		  fprintf(stderr,"                    %s\n",*n);
+		  ++n;
+		  }
+		return -1;
+		}
+	    break;
+
+	  default:
+	    break;
+	  }
+
+	if (arg[a].funcPtr)
+	  {
+	  int s = (*arg[a].funcPtr)(optionArgPtr);
+	  if (s<0)
+	    return s;
+	  }
+
+	if (arg[a].optionType == OptionBoolean)
+	  {
+	  ++p;
+	  if (*p != '\0')
+	    {
+	    a = 0;
+	    continue;
+	    }
+	  }
+
+	argDone = 1;
+	break;
+	}
+      ++a;
+      }
+
+    if (!argDone)
+      {
+      fprintf(stderr,"%s: unrecognized option '%c'\n",progName,*p);
+      prOptions(arg,specCount);
+      return -1;
+      }
+    }
+  return argsUsed;
+  }
+
diff --git a/libntlm-0.21/test/getargs.h b/libntlm-0.21/test/getargs.h
new file mode 100644
index 00000000..1f5a1857
--- /dev/null
+++ b/libntlm-0.21/test/getargs.h
@@ -0,0 +1,19 @@
+typedef struct
+  {
+  char optionChar;
+  enum 
+    {
+    OptionInteger,
+    OptionDouble,
+    OptionLong,
+    OptionString,
+    OptionBoolean,
+    OptionEnumerated
+    } optionType;
+  void *optionPtr;
+  int (*funcPtr)(char *param);
+  char *helpString;
+  char **enumValues;
+  }argSpec;
+
+extern int getargs(int argc, char *argv[], argSpec *arg, int numberSpecs);
diff --git a/memmove.c b/memmove.c
new file mode 100644
index 00000000..2ffab60c
--- /dev/null
+++ b/memmove.c
@@ -0,0 +1,22 @@
+/*
+ * Scratch implementation of memmove() in case your C library lacks one.
+ *
+ * For license terms, see the file COPYING in this directory.
+ */
+char *memmove(char *dst, register char *src, register int n)
+{
+    register char *svdst;
+
+    if ((dst > src) && (dst < src + n)) 
+    {
+        src += n;
+        for (svdst = dst + n; n-- > 0; )
+            *--svdst = *--src;
+    }
+    else
+    {
+        for (svdst = dst; n-- > 0; )
+            *svdst++ = *src++;
+    }
+    return dst;
+}
diff --git a/mime64/Makefile b/mime64/Makefile
new file mode 100644
index 00000000..a94322ba
--- /dev/null
+++ b/mime64/Makefile
@@ -0,0 +1,14 @@
+DESTDIR = /usr/local/bin
+CFLAGS = $G $O $S
+O = -m486 -O2
+S = -s
+G =
+
+mime64:	mime64.c
+	$(CC) $(CFLAGS) -o $@ $^
+
+install:mime64
+	install -s mime64 $(DESTDIR)
+
+clobber:
+	rm -f mime64
diff --git a/mime64/README b/mime64/README
new file mode 100644
index 00000000..f87e9d52
--- /dev/null
+++ b/mime64/README
@@ -0,0 +1,81 @@
+
+                   MIME64 Encoder/Decoder
+
+WHAT MIME64 IS:  MIME64 is an encoding described in RFC1341 as MIME base64.
+Its purpose is to encode binary files into ASCII so that they may be passed
+through e-mail gates.  In this regard, MIME64 is similar to UUENCODE.
+Although most binaries these days are transmitted using UUENCODE, I
+have seen a few using MIME64, and I have had requests from friends that
+I decode MIME64 files that have fallen into their hands.  As long as
+some MIME64 continues to exist, a package such as this one is useful
+to have.
+
+
+WHAT THIS PACKAGE CONTAINS:  This package contains both executable
+and ANSI-C source code for a MIME64 encoder/decoder (MIME.EXE and
+MIME.C respecively).  It also contains this README file, and a MIME64
+encoded file called MIME.64.  The latter will decode to MIME.ZIP if
+you issue the DOS command line:
+
+   MIME64 MIME.64 MIME.ZIP
+
+If you unzip the zip file, you will get an essay by Mark Grand about
+MIME.
+
+
+HOW TO USE THIS PACKAGE:  To decode a MIME64 file you may type:
+
+   MIME64 infile outfile
+
+If you leave out the outfile specification, the output file will
+overwrite the input file unless there is a filename specifier in
+the header of the input file.  If there is a file name specifier
+in infile, and no outfile is given, the output file will be
+according to the specifier.  An example of a filename specifier
+in the header of a base64 MIME file is:
+
+Content-Type: text/plain; charset=US-ASCII; name=dork.zip
+
+The filename specified here is dork.zip.
+
+If the input file has a content transfer encoding of any but base64,
+that input will be ignored.  For example, if it had a header line of:
+
+Content-transfer-encoding: unusualformat
+
+instead of:
+
+Content-transfer-encoding: base64
+
+there would be no output.  If no content-transfer-encoding line is
+given in the file, MIME64 assumes the file to be base64 and decodes
+it accordingly.
+
+There can be several files encoded into an input file.  If subsequent
+encoded files are found in the input file, they will be decoded according
+to the name specified in a content-type line.
+
+To encode a file into MIME64 format, type:
+
+   MIME64 infile outfile -e
+
+If you leave off the outfile specification, the output will
+overwrite the input.  MIME64 does not permit you to encode more than
+one file at a time.  If you wish to combine several base64 files,
+you will have to do so with a text editor.
+
+
+STATUS OF THIS PACKAGE:  This package is freeware.  As author, I
+claim no copyright.  If you change the source code and intend to
+propogate that change to other users, please include a comment to
+that effect at the top that states:  The date of the change, the
+nature of the change, and who made the change.  As a courtesy, I also
+ask that you retain the comment that acknowledges me as the original
+author.
+
+
+SEND QUESTIONS ABOUT THIS PACKAGE TO:  hahn@lds.loral.com
+
+Karl Hahn
+
+
diff --git a/mime64/mime.txt b/mime64/mime.txt
new file mode 100644
index 00000000..109e481c
--- /dev/null
+++ b/mime64/mime.txt
@@ -0,0 +1,831 @@
+

+

+                            MIME Overview

+

+                by Mark Grand <mark@premenos.sf.ca.us>

+

+Internet e-mail allows mail messages to be exchanged between users of

+computers around the world and occasionally beyond... to space

+shuttles.  One of the main reasons that Internet e-mail has achieved

+such wide use is because it provides a standard mechanism for messages

+to be exchanged between over 1,000,000 computers connected to the

+Internet.

+

+The standards that are the basis for Internet e-mail were established

+in 1982.  Though they were state of the art in 1982, in the

+intervening years they have begun to show their age.  The 1982

+standards allow for mail messages that contain a single human readable

+message with the restrictions that:

+

+    * the message contains only ASCII characters.

+

+    * the message contains no lines longer than 1000 characters.

+

+    * the message does not exceed a certain length

+

+The 1982 standards do not allow EDI to be transmitted through Internet

+mail, since EDI messages can violate all of these restrictions.  There

+are a number of other types of messages and services that have are

+supported by other mail standards that have been designed more

+recently.  In June of 1992 a new Internet mail standard was approved.

+This new standard is called MIME.

+

+MIME is an acronym for Multipurpose Internet Mail Extensions.  It

+builds on the older standard by standardizing additional fields for

+mail message headers that describe new types of content and

+organization for messages.

+

+MIME allows mail messages to contain:

+

+    * Multiple objects in a single message.

+

+    * Text having unlimited line length or overall length.

+

+    * Character sets other than ASCII.

+

+    * Multi-font messages.

+

+    * Binary or application specific files.

+

+    * Images, Audio, Video and multi-media messages.

+

+MIME defines the following new header fields:

+

+1.  A MIME-Version header field, which uses a version number to

+    declare that a message conforms to the MIME standard.

+

+2.  A Content-Type header field, which can be used to specify the type

+    and subtype of data in the body of a message and to fully specify

+    the encoding of such data.

+

+    2.a.  A Text Content-Type value, which can be used to represent

+          textual information in a number of character sets and

+          formatted text description languages in a standardized

+          manner.

+

+    2.b.  A Multipart Content-Type value, which can be used to combine

+          several body parts, possibly of differing types of data,

+          into a single message.

+

+    2.c.  An Application Content-Type value, which can be used to

+          transmit application data or binary data.

+

+    2.d.  A Message Content-Type value, for encapsulating a mail

+          message.

+

+    2.e.  An Image Content-Type value, for transmitting still image

+          (picture) data.

+

+    2.f.  An Audio Content-Type value, for transmitting audio or voice

+          data.

+

+    2.g.  A Video Content-Type value, for transmitting video or moving

+          image data, possibly with audio as part of the composite

+          video data format.

+

+3.  A Content-Transfer-Encoding header field, that specifies how the

+    data is encoded to allow it to pass through mail transports having

+    data or character set limitations.

+

+4.  Two optional header fields that can be used to further describe

+    the data in a message body, the Content-ID and Content-Description

+    header fields.

+

+MIME is an extensible mechanism.  It is expected that the set of

+content-type/subtype pairs and their associated parameters will grow

+with time.  Several other MIME fields, such as character set names,

+are likely to have new values defined over time.  To ensure that the

+set of such values develops in an orderly, and public manner, MIME

+defines a registration process which uses the Internet Assigned

+Numbers Authority (IANA) as a central registry for such values.

+

+To promote interoperability between implementations, the MIME standard

+document specifies a minimal subset of the above mechanisms that are

+required for an implementation to claim to conform to the MIME

+standard.

+

+

+

+                        MIME Technical Summary

+

+MIME is defined by an Internet standard document called RFC 1341.

+This document summarizes the contents of RFC 1341.  Sufficient detail

+is presented here to understand the capabilities of MIME.  For

+sufficient detail to implement MIME please read RFC 1341.

+

+MIME allows messages to contain multiple objects.  When multiple

+objects are in a MIME message, they are represented in a form called a

+body part.  A body part has a header and a body, so it makes sense to

+speak about the body of a body part. Also, body parts can be nested in

+bodies that contain one or multiple body parts.

+

+The Content-Type values, subtypes, and parameter names defined in the

+MIME standard are not case insensitive.  However, many parameter

+values are case sensitive.

+

+The MIME standard is written to allow MIME to be extended in certain

+ways, without having to revise the standard.  MIME specifies sets of

+values that are allowed for various fields and parameters.  The

+provides a procedure for extending these sets of values by registering

+them with an entity called the Internet Assigned Numbers Authority

+(IANA).

+

+

+The MIME-Version Header Field

+

+MIME is designed to be compatible with older Internet mail standards.

+In particular, it is compatible with RFC 822.  If a mail reading

+program receives a message that is a MIME message then it will likely

+perform additional processing for the MIME message that it would not

+perform for non-MIME messages.  In order to allow mail reading

+programs to recognize MIME messages, MIME messages are required to

+contain a MIME-Version header field.  The MIME-Version header field

+specifies the version of the MIME standard that the message conforms

+to.

+

+As of this writing there is only version (1.0) of the MIME standard.

+Messages that comply with the standard must include a header field,

+with the following verbatim text:

+

+        MIME-Version: 1.0

+

+The MIME-Version header field is required at the top level of a

+message. It is not required for each body part of a multipart entity.

+It is required for the embedded headers of a body of type "message" if

+and only if the embedded message is claimed to be MIME-compliant.

+

+

+The Content-Type Header Field

+

+The Content-Type field describes the data contained in the body fully

+enough that the mail reader can pick an appropriate mechanism to

+present the data to the user, or otherwise deal with the data in an

+appropriate manner.

+

+The Content-Type header field is used to specify the nature of data in

+the body or body part, by giving type and subtype identifiers, and by

+providing parameters that may be needed for certain types.  After the

+type and subtype names, the remainder of the header field is a set of

+parameters, specified in an attribute/value notation.  The set of

+meaningful parameters differs for different types.  The order of

+parameters is not significant.  Comments are allowed (in accordance

+with RFC 822 rules) in structured header fields by placing them in

+parentheses.

+

+The top-level Content-Type is used to declare the general type of

+data, while the subtype specifies a specific format for that type of

+data.  Thus, a Content-Type of Image/xyz is enough to tell a mail

+reader that the data is an image, even if the mail reader has no

+knowledge of the specific image format xyz.  Such information can be

+used, to decide whether or not to show a user the raw data from an

+unrecognized subtype -- such an action might be reasonable for

+unrecognized subtypes of Text, but not for unrecognized subtypes of

+Image or Audio.  For this reason, registered subtypes of Audio, Image,

+Text, and Video, should not contain embedded information that is

+really of a different type.  Such compound types are usually

+represented using the Multipart or Application types.

+

+Parameters are modifiers of the content-subtype.  Although most

+parameters make sense only with certain content-types, others are

+"global" in the sense that they might apply to any subtype.  For

+example, the Boundary parameter, which is used to indicate how body

+parts are separated from each other, makes sense only for the

+Multipart content-type.  The Charset parameter might make sense with

+several content-types.

+

+The MIME standard defines seven content-types.  The authors of the

+MIME standard state that the set of seven types is "substantially

+complete".  They expect additional supported types to be accommodated

+by creating new subtypes of the seven initial top-level types.  The

+MIME standard, functioning as a constitution for the MIME community,

+states that new standard content types can be defined only by revising

+the standard (as opposed to the registration procedure for other types

+of extensions).  However, MIME does provide for the use of

+non-standard content types.  Non-standard content-types can be used,

+but must be given names starting with X-.  Future standard content

+type names will not begin with X-.

+

+The syntax for the content type header field is

+

+    Content-Type := type "/" subtype [";" parameter]...

+

+The defined content types are:

+

+    Application

+        indicates data that does not fit into any of the other

+        categories, such as uninterpreted binary data or information

+        to be processed by a mail-based application. In addition to

+        the following subtypes, it is likely that additional subtypes

+        will be defined for applications such as mail-based scheduling

+        systems, spreadsheets and EDI.

+

+    Application/Octet-Stream

+        indicates uninterpreted binary data, which a mail reading

+        program may simply offer to write the information into a file.

+        Possible parameters for Application/Octet-Stream include:

+

+        Name

+            a suggested name for the binary data if stored as a file.

+

+        Type

+            the general type or category of binary data.  This is

+            intended for human recipients rather than for automated

+            processing.

+

+        Conversions

+            the operations that performed on the data before putting

+            it the body.  Note that the standard defines no conversion

+            values.  Any conversion values that do not begin with X-

+            must be preceded by a published specification and by

+            registration with IANA.

+

+        Padding

+            the number of bits of padding that were appended to the

+            bitstream comprising the actual contents to produce the

+            enclosed byte-oriented data.  This is useful for enclosing

+            a bitstream in a body when the total number of bits is not

+            a multiple of the byte size.

+

+    Application/ODA

+        indicates a body containing information encoded according to

+        the Office Document Architecture (ODA) standards, using the

+        ODIF representation format.  For Application/ODA, the

+        Content-Type line should also specify an attribute/value pair

+        that indicates the document application profile (DAP), using a

+        Profile parameter.  Thus an appropriate header field might

+        look like this:

+

+            Content-Type: application/oda;

+                          profile=Q112

+

+        Consult the ODA standard for further information.

+

+    Application/PostScript

+        indicates a body containing a postscript document.

+

+Audio

+    Indicates audio data.  Audio requires an audio output device (such

+    as a speaker or a telephone) to "display" the contents.

+

+    Audio/Basic

+        The content of the Audio/Basic subtype is audio encoded using

+        8-bit ISDN u-law. When this subtype is present, a sample rate

+        of 8000 Hz and a single channel is assumed.

+

+    Image

+        Image data.  Image requires a display device (such as a

+        graphical display, a printer, or a FAX machine) to view the

+        information.

+

+    Image/Jpeg

+        indicates an image in JPEG format.

+

+    Image/Gif

+        indicates an image in GIF format.

+

+Message

+    indicates an encapsulated message.

+

+    Message/Rfc822

+        indicates that the body contains an encapsulated message, with

+        the syntax of an RFC 822 message.

+

+    Message/Partial

+        indicates a partial message, allowing fragmented transmission

+        of bodies too large to be passed through mail transport

+        facilities.  Message/Partial indicates that the body contains

+        a fragment of a larger message.

+

+        Three parameters are required in a Content-Type field of type

+        Message/Partial: The first, Id, is a unique identifier, as

+        close to world-unique as possible, used to match the parts

+        together.  The second, Number, an integer, is the part number

+        indicating where this part fits into the sequence of

+        fragments.  The third, Total, another integer, is the total

+        number of parts. Total is required on the final part, and

+        optional on earlier parts.

+

+    Message/External-Body

+        indicates that the actual body data are not included, but

+        merely referenced.  In this case, the parameters describe a

+        mechanism for accessing the external data.

+

+        When a body or body part is of type Message/External-Body,

+        it consists of a header, a blank line, and the message header

+        for the encapsulated message.  If another blank line appears,

+        this ends the message header for the encapsulated message.

+        However, since the encapsulated message's body is itself

+        external, it does not appear in the area that follows.  For

+        example, consider this message:

+

+            Content-type: message/external-body;

+                          access-type=local-file;

+                          name=/u/nsb/Me.gif

+

+            Content-type: image/gif

+

+            THIS IS NOT REALLY THE BODY!

+

+        The area at the end, which constitutes a phantom body, is

+        ignored for most external-body messages.  However, it may be

+        used to contain auxiliary information for a

+        "mail-server".

+

+        The only parameter of Message/ExternalÄBody that is always

+        mandatory is Access-Type.  Its other parameters are mandatory

+        or optional depending on the value of Access-Type.  The values

+        defined for the Access-Type parameter are FTP, ANON-FTP, TFTP,

+        AFS, LOCAL-FILE, and MAIL-SERVER.  Except for values beginning

+        with X-, other values must be registered with IANA.

+

+        The standard also specifies additional parameters that are to

+        be used in conjunction with the various access types.

+

+        In addition to access-type specific parameters, the standard

+        defines the following parameters which are optional for all

+        access types:

+

+            * The Expiration parameter is used to specify a date after

+              which the existence of the external data is not

+              guaranteed. 

+

+            * The Size parameter is used to specify the size of the

+              data.

+

+Multipart

+

+    indicates data consisting of multiple body parts; each having its

+    own data type.  It is possible to tell where each body part begins

+    and ends because each body part is preceded by a special string

+    called an encapsulation boundary; the last body part is followed

+    by a closing boundary.

+

+    The boundary strings used are specified by a mandatory parameter

+    called Boundary.  The encapsulation boundary is an end of line

+    followed by two hyphens followed by the boundary parameter value

+    of the ContentÄType header field.  The closing boundary is the

+    same as the encapsulation boundary with the addition of two

+    hyphens at the end of the line.

+

+    The encapsulation boundary must not appear inside any of the

+    encapsulated parts.  It is crucial that the composing user agent

+    be able to choose and specify the unique boundary that will

+    separate the body parts.  Encapsulation boundaries may be no

+    longer than 70 characters, not counting the blank line and leading

+    hyphens.

+

+    Thus, a typical multipart Content-Type header field might look

+    like:

+

+        Content-Type: multipart/mixed; boundary=gc0y0pkb9ex

+

+    This indicates a body consisting of several body parts, each

+    having a structure syntactically identical to an RFC 822 message,

+    except that the header area may be completely empty, and each part

+    is preceded by the line

+

+        --gc0y0pkb9ex

+

+    The closing boundary following the last body part indicates that

+    no further body parts will follow.  It is identical to the

+    preceding encapsulation boundaries, with the addition of two more

+    hyphens at the end of the line:

+

+        --gc0y0pkb9ex--

+

+    There is room for additional information prior to the first

+    encapsulation boundary and following the final boundary.  These

+    areas are often blank.  Anything appearing before the first or

+    after the last boundary is ignored.

+

+    As a simple example, the following multipart message has two

+    parts, both plain text, one explicitly typed and one implicitly

+    typed:

+

+        From: Nathaniel Borenstein <nsb@bellcore.com>

+        To: Ned Freed <ned@innosoft.com>

+        Subject: Sample message

+        MIME-Version: 1.0

+        Content-type: multipart/mixed;

+                      boundary="simple boundary"

+

+        This is the preamble.  It is to be ignored, though it is a

+        handy place for mail composers to include an explanatory note

+        to non-MIME compliant readers.

+

+        --simple boundary

+

+        This is implicitly typed plain ASCII text.

+        --simple boundary

+        Content-type: text/plain; charset=us-ascii

+

+        This is explicitly typed plain ASCII text.

+        It DOES end with a line break.

+

+        --simple boundary--

+        This is the epilogue.  It is also to be ignored.

+

+    The use of a Content-Type of multipart in a body part within

+    another multipart entity is explicitly allowed.  In such cases,

+    care must be taken to ensure that each nested multipart entity

+    uses a different boundary delimiter.

+

+    The use of the multipart Content-Type with only a single body part

+    may be useful in certain contexts, and is explicitly permitted.

+

+    Multipart/Mixed

+        indicates multiple independent body parts to be viewed

+        serially.

+

+    Multipart/Alternative

+        is syntactically identical to Multipart/Mixed.  Each part is

+        an "alternative" version of the same information.  Mail

+        readers should recognize that the content of the parts are

+        interchangeable.  The mail reader should either choose the

+        "best" type based on the user's environment and preferences,

+        or offer the user the available alternatives.  Generally,

+        choosing the best type means displaying only the last part

+        that can be displayed.  This may be used, for example, to send

+        mail in a fancy text format in such a way that it can easily

+        be displayed anywhere:

+

+            From:  Nathaniel Borenstein <nsb@bellcore.com>

+            To: Ned Freed <ned@innosoft.com>

+            Subject: Formatted text mail

+            MIME-Version: 1.0

+            Content-Type: multipart/alternative;

+                          boundary=boundary42

+

+

+            --boundary42

+            Content-Type: text/plain; charset=us-ascii

+

+            ...plain text version of message goes here...

+            --boundary42

+            Content-Type: text/richtext

+

+            ... richtext version of same message goes here ...

+            --boundary42

+            Content-Type: text/x-whatever

+

+            ... fanciest formatted version of same message goes here

+            ...

+            --boundary42--

+

+        In this example, users whose mail system understood the

+        text/x-whatever format would see only the fancy version,

+        while other users would see only the richtext or plain text

+        version, depending on the capabilities of their system.

+

+        Some mail reading programs that recognize more than one of the

+        formats will offer the user a choice of which format to view.

+        This makes sense, for example, if mail includes both a nicely

+        formatted image version and an easily edited text version.

+        The point is that multiple versions of the same data are not

+        automatically shown.  Either the user is shown the last

+        recognized version or explicitly given the choice.

+

+    Multipart/Parallel

+        is syntactically identical to Multipart/Mixed.  However, in a

+        parallel body, all of the body parts are intended to be

+        presented simultaneously on hardware and software that are

+        capable of doing so.  Composing agents should be aware that

+        many mail readers will lack this capability and will show the

+        parts serially in any event.

+

+        Multipart/Parallel will likely be used for multimedia messages

+        that combine such message types as text, audio and/or video.

+

+    Multipart/Digest

+        Indicates that each of the body parts is an RFC 822 mail

+        message.  Multipart/Digest is syntactically identical to

+        Multipart/Mixed, except that the default Content-Type value

+        for a body part is changed from Text/Plain to Message/Rfc822.

+

+Text

+    The text Content-Type is for sending material that is principally

+    textual in form.  It is the default Content-Type.  A Charset

+    parameter may be used to indicate the character set of the text.

+    The default Content-Type for Internet mail is

+        text/plain; Charset=US-ASCII.

+

+    The value of the Charset parameter is not case sensitive.

+    Allowable values are US-ASCII, ISO-8859-1, ISO-8859-2, ... and

+    ISO-8859-9. The default value for Charset is US-ASCII.

+

+    Text/Plain

+        indicates plain (unformatted) text.  No special software is

+        required to get the full meaning of the text, aside from

+        support for the indicated character set.  Other subtypes

+        should be used for enriched text in forms where application

+        software may enhance the appearance of the text, but such

+        software must not be required in order to get the general idea

+        of the content.  Possible future subtypes include any readable

+        word processor format.

+

+    Text/Richtext

+        indicates a simple portable word processing format that is

+        defined by the MIME standard.  It is a very small subset of

+        SGML.  Mail readers that implement Richtext may implement only

+        a subset of it.

+

+        When a mail composing program is given a file in a word

+        processing format to send and there is no standardized subtype

+        for that format, then the message composing program may

+        reformat the file into richtext format which will preserve

+        more of the original formatting information than reformatting

+        the file to plain ASCII.

+

+Video

+    indicates that the body contains a time-varying-picture image,

+    possibly with color and coordinated sound.  The term Video is

+    used very generically and does not refer to any particular

+    technology or format.  It is not meant to preclude subtypes

+    such as animated drawings encoded compactly.

+

+    Video/Mpeg

+        indicates video coded according to the MPEG standard.

+

+x-TypeName

+    This is any type name that begins with X-.  A Content-Type value

+    beginning with X- is a private value, to be used by consenting

+    mail systems by mutual agreement.  The standard specifies no

+    subtypes.

+

+No type may be specified without a subtype.

+

+The standard allows the use of additional sub-types without having to

+change the standard.  However, it is important to insure that

+sub-types used by different user communities of MIME do not conflict.

+It would be confusing if Content-Type: application/foobar meant two

+different things.  The standard specifies two mechanisms for defining

+new Content-Type subtypes:

+

+1.  Private values (starting with X-) may be defined between

+    cooperating mail composing and reading programs without outside

+    registration.  Use of this mechanism requires knowing that the

+    reader of the message will not mistake the content type for

+    something other than originally intended.

+

+2.  New standard values must be registered with IANA.  Where intended

+    for public use, the formats they refer to must also be defined by

+    a published specification.

+

+Messages that do not have a Content-Type field in their header are

+displayed by user agents as if

+

+    Content-Type: Text/plain; Charset=US-ASCII

+

+had been specified.

+

+When a mail reader encounters mail with an unknown Content-Type value,

+it will generally treat it as equivalent to application/octet-stream.

+

+

+The Content-Transfer-Encoding Header Field

+

+Many Content-Types which could usefully be transported via e-mail are

+represented, in their "natural" format, as 8-bit character or binary

+data.  Such data cannot be transmitted over some transport protocols.

+For example, SMTP (Simple Mail Transfer Protocol is an Internet

+standard for transporting e-mail defined by a document called RFC 821)

+restricts mail messages to 7-bit ASCII data with lines no longer than

+1000 characters.

+

+MIME provides two mechanisms for re-encoding such data into a 7-bit

+short-line format.  The Content-Transfer-Encoding header field

+indicates the mechanism used to perform such an encoding.  The

+Content-Transfer-Encoding field indicates the transformation that has

+been used to represent the body in an acceptable manner for transport.

+

+The possible values for the Content-Transfer-Encoding field are:

+        BASE64

+        QUOTED-PRINTABLE

+        8BIT

+        7BIT

+        BINARY

+        x-EncodingName

+These values are not case sensitive.  That is, Base64, BASE64 and

+bAsE64 are all equivalent.  An encoding type of 7BIT requires that the

+body is already in a 7-bit mail-ready representation.  That is the

+default value: Content-Transfer-Encoding: 7BIT is assumed if the

+Content-Transfer-Encoding header field is not present.

+

+Both BASE64 and the QUOTED-PRINTABLE imply an encoding that consists

+of lines no longer than 76 ASCII characters.  In other respects the

+two encoding schemes are very different.

+

+The encoding scheme implied by QUOTED-PRINTABLE is most appropriate

+for data that consists primarily of printable ASCII characters. Using

+this encoding method, printable ASCII character are represented as

+themselves.  The equals sign (=) serves as an escape character.  Any

+character that is not a printable or white space ASCII character is

+represented as an equals sign followed by two hexadecimal digits.  An

+equals sign in the message is also represented in this way.  Lines

+that are longer than 76 characters are cut off after the 75th

+character and the line ends with a equals sign.

+

+The advantages of using the QUOTED-PRINTABLE encoding for message that

+are mostly printable ASCII characters are that few additional

+characters are required and the message can be read by human beings

+who to not have a MIME aware mail reading program.  As an example,

+here is an EDI interchange in QUOTED-PRINTABLE encoding:

+

+ISA*00*          *00*          *01*987654321      *12*8005551234     *910=

+607*0111*U*00200*110000777*0*T*>

+GS*PO*987654321*8005551234*920501*2032*7721*X*002003

+ST*850*000000001

+BEG*00*NE*MS1112**920501**CONTRACT#

+REF*IT*8128827763

+N1*ST*MAVERICK SYSTEMS

+N3*3312 NEW HAMPSHIRE STREET

+N4*SAN JOSE*CA*94811

+PO1*1*25*EA***VC*TP8MM*CB*TAPE8MM

+PO1*2*30*EA***VC*TP1/4*CB*TAPE1/4INCH

+PO1*3*125*EA***VC*DSK31/2*CB*DISK35

+CTT*3

+SE*11*000000001

+GE*1*7721

+IEA*1*110000777

+

+Except for the ISA segment having been wrapped onto two lines, the

+QUOTED-PRINTABLE encoding of the interchange is identical to its 7BIT

+representation.

+

+The BASE64 encoding mechanism is well suited for representing binary

+files.  It represents any sequence of three bytes as four printable

+ASCII characters.  The same interchange as shown above but using the

+BASE64 encoding would look like:

+

+SVNBKjAwKiAgICAgICAgICAqMDAqICAgICAgICAgICowMSo5ODc2NTQzMjEgICAgICAqMTIq

+ODAwNTU1MTIzNCAgICAgKjkxMDYwNyowMTExKlUqMDAyMDAqMTEwMDAwNzc3KjAqVCo+CkdT

+KlBPKjk4NzY1NDMyMSo4MDA1NTUxMjM0KjkyMDUwMSoyMDMyKjc3MjEqWCowMDIwMDMKU1Qq

+ODUwKjAwMDAwMDAwMQpCRUcqMDAqTkUqTVMxMTEyKio5MjA1MDEqKkNPTlRSQUNUIwpSRUYq

+SVQqODEyODgyNzc2MwpOMSpTVCpNQVZFUklDSyBTWVNURU1TCk4zKjMzMTIgTkVXIEhBTVBT

+SElSRSBTVFJFRVQKTjQqU0FOIEpPU0UqQ0EqOTQ4MTEKUE8xKjEqMjUqRUEqKipWQypUUDhN

+TSpDQipUQVBFOE1NClBPMSoyKjMwKkVBKioqVkMqVFAxLzQqQ0IqVEFQRTEvNElOQ0gKUE8x

+KjMqMTI1KkVBKioqVkMqRFNLMzEvMipDQipESVNLMzUKQ1RUKjMKU0UqMTEqMDAwMDAwMDAx

+CkdFKjEqNzcyMQpJRUEqMSoxMTAwMDA3NzcK

+

+BASE64 bears some resemblance to uuencode in both appearance and

+function.  However, uuencode uses characters that may not be processed

+properly by an EBCDIC gateway.

+

+The values 8bit, 7bit, and binary all imply that no encoding has been

+performed. However, they are useful to indicate of the kind of data

+contained in the object, and therefore of the kind of encoding that

+might need to be performed for transmission in a given transport

+system.  7bit means that the data is all represented as short lines of

+ASCII data.  8bit means that the lines are short, but there may be

+non-ASCII characters.  Binary means that not only may non-ASCII

+characters be present, but also that the lines are not necessarily

+short enough for SMTP transport.

+

+The difference between 8bit and binary is that binary does not require

+adherence to any limits on line length.  8bit and binary are intended

+for compatibility with future Internet e-mail transport standards and

+with gateways to non-Internet environments.  As of this writing there

+are no standardized Internet e-mail transports for which it is

+legitimate to include unencoded 8-bit or binary data in mail bodies.

+

+Note that the five values defined for the Content-Transfer-Encoding

+field imply nothing about the Content-Type other than the algorithm by

+which it was encoded or the transport system requirements if

+unencoded.

+

+Some implementations may support additional Content-Transfer-Encoding

+values (it is permitted but strongly discouraged by the standard).

+Any such additional values must have names that begin with X- to

+indicate its non-standard status For example:

+

+        Content-Transfer-Encoding: x-my-new-encoding.

+

+If a Content-Transfer-Encoding header field appears as part of a

+message header, it applies to the entire body of that message.  If a

+Content-Transfer-Encoding header field appears as part of a body

+part's headers, it applies only to the body of that body part.  If a

+message or body part is of type Multipart or Message, the

+Content-Transfer-Encoding must be 7bit, 8bit or Binary.

+

+The encoding mechanisms defined here explicitly encode all data in

+ASCII.  Thus, for example, suppose a message or body part has header

+fields such as:

+

+        Content-Type: text/plain; charset=ISO-8859-1

+        Content-transfer-encoding: base64

+

+This should be interpreted to mean that the body is a Base64 ASCII

+encoding of data that was originally in ISO-8859-1, and will be in

+that character set again after decoding.

+

+

+Optional Content-ID Header Field

+

+It may be desirable to allow one body to reference another.

+Accordingly, bodies may be labeled using the Content-ID header field,

+which is syntactically identical to the RFC 822 Message-ID header

+field: Content-ID values should be be as unique as possible.

+

+

+Optional Content-Description Header Field

+

+The ability to associate descriptive information with a body is often

+desirable. For example, it may be useful to mark an Image body as

+"a picture of the Space Shuttle Endeavor."  Such text may be

+placed in the Content-Description header field.

+

+

+Summary

+

+Using MIME-Version, Content-Type, and Content-Transfer-Encoding header

+fields, it is possible to include arbitrary types of data objects in

+RFC 822 conformant mail messages.  No restrictions imposed by RFC 821

+or RFC 822 are violated. MIME has been designed to avoid problems

+caused by additional restrictions imposed by some Internet mail

+transport mechanisms. The Multipart and Message content types allow

+mixing and hierarchical structuring of objects of different types in a

+single message.  Further content types provide a mechanism for tagging

+messages or body parts as audio, image, or other kinds of data.  A

+parameter syntax allows further specification of data format details,

+particularly the specification of alternate character sets.

+Additional optional header fields provide mechanisms for certain

+extensions deemed desirable by many implementors.  Finally, a number

+of useful content types are defined for general use by consenting user

+agents, notably Text/Richtext, Message/Partial, and

+Message/External-Body.

+

+To promote interoperability between user agents, the MIME standard

+specifies a minimal subset of MIME features a user agent must support

+to be considered MIME conformant.

+

+

+A Complex Multipart Example

+

+The outline of a complex multipart message follows.  This message has

+five parts to be displayed serially: two introductory plain text

+parts, an embedded multipart message, a richtext part, and a closing

+encapsulated text message in a non-ASCII character set.  The embedded

+multipart message has two parts to be displayed in parallel, a picture

+and an audio fragment.

+

+    MIME-Version: 1.0

+    From: Nathaniel Borenstein <nsb@bellcore.com>

+    Subject: A multipart example

+    Content-Type: multipart/mixed;

+                  boundary=unique-boundary-1

+

+    This is the preamble area of a multipart message.  Mail readers

+    that understand multipart format should ignore this preamble.

+    If you are reading this text, you might want to consider changing

+    to a mail reader that understands how to properly display

+    multipart messages.

+    --unique-boundary-1

+

+    Some text appears here...

+    [Note that the preceding blank line means

+    no header fields were given and this is text,

+    with charset US ASCII.  It could have been

+    done with explicit typing as in the next part.]

+

+    --unique-boundary-1

+    Content-type: text/plain; charset=US-ASCII

+

+    This could have been part of the previous part, but illustrates

+    explicit versus implicit typing of body parts.

+

+    --unique-boundary-1

+    Content-Type: multipart/parallel; boundary=unique-boundary-2

+

+    --unique-boundary-2

+    Content-Type: audio/basic

+    Content-Transfer-Encoding: base64

+

+    ... base64-encoded 8000 Hz single-channel

+    u-law-format audio data goes here ...

+

+    --unique-boundary-2

+    Content-Type: image/gif

+    Content-Transfer-Encoding: Base64

+

+    ... base64-encoded image data goes here...

+

+    --unique-boundary-2--

+

+    --unique-boundary-1

+    Content-type: text/richtext

+

+    This is <bold><italic>richtext.</italic></bold><nl><nl>Isn't it

+    <bigger><bigger>cool?</bigger></bigger>

+

+    --unique-boundary-1

+    Content-Type: message/rfc822

+

+    From: (name in US-ASCII)

+    Subject: (subject in US-ASCII)

+    Content-Type: Text/plain; charset=ISO-8859-1

+    Content-Transfer-Encoding: Quoted-printable

+

+    ... Additional text in ISO-8859-1 goes here ...

+

+    --unique-boundary-1--

+

diff --git a/mime64/mime64.c b/mime64/mime64.c
new file mode 100644
index 00000000..c7ddd3ed
--- /dev/null
+++ b/mime64/mime64.c
@@ -0,0 +1,795 @@
+/* mime64 */
+/* MIME base64 encoder/decoder by Karl Hahn  hahn@lds.loral.com  3-Aug-94 */
+/* modified 30-Sep-94 by Karl Hahn hahn@lds.loral.com: handle multiple
+   content */
+/* modified 12-Jan-95 by Karl Hahn hahn@lds.loral.com: handle file names
+   that are encased in quotes */
+/* modified 18-Jan-95 by Karl Hahn hahn@lds.loral.com: prevent complete
+   failure if filename in name field matches name of input file */
+/* modified 19-Jan-95 by Karl Hahn hahn@lds.loral.com: prevent early exit
+   if last decoded character falls on a multiple of 3 -- would cause error
+   message and failure to rename output file if rename was necessary */
+/* modified 19-Jan-95 by Karl Hahn hahn@lds.loral.com: prevent complete
+   failure if a line of text preceding the MIME64 stuff contains no
+   non-base64 characters */
+/* modified 19-Jan-95 by Karl Hahn hahn@lds.loral.com: fixed command
+   line parser to prevent missing a name field preceded by another
+   name field */
+/* modified 19-Jan-95 by Karl Hahn hahn@lds.loral.com: prevent error
+   message at the end of decoding each section.  Terminates output
+   file now on a blank line as well as the conditions that did so
+   previously */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+#ifdef __FreeBSD__
+#define	strcmpi(x,y)	strcasecmp(x,y)
+#endif
+
+char alphabet[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
+                  "0123456789+/";
+
+enum TOKENTYPE { NONE, BLANKS, PUNCT, TAG, NAME, CONTENT };
+
+struct TOKEN {
+                char *text;
+                int  length;
+                int  index;
+                enum TOKENTYPE type;
+             };
+
+int compare_token( struct TOKEN *token, char *text )
+{
+   int index=0;
+   int count;
+   int result;
+   char blivit1, blivit2;
+
+   count = token->length;
+
+   if ( count > 0 )
+   {
+      result = 1;
+   }
+   else
+   {
+      result = 0;
+   }
+
+   while ( (count > 0) && ( result != 0 ) )
+   {
+      blivit1 = token->text[index++];
+      if ( (blivit1 >= 'a' ) && (blivit1 <= 'z') )
+      {
+         blivit1 -= ' ';
+      }
+
+      blivit2 = *text++;
+      if ( (blivit2 >= 'a' ) && (blivit2 <= 'z') )
+      {
+         blivit2 -= ' ';
+      }
+
+      if ( blivit1 != blivit2 )
+      {
+         result = 0;
+      }
+
+      count--;
+   }
+
+   return result;
+}
+
+int ispunct( char blivit )
+{
+   if ( ( blivit >= 'a' ) && (blivit <= 'z' ) )
+   {
+      blivit -= ' ';
+   }
+
+   if ( ( ( blivit < '0' ) ||
+          ( ( blivit > '9' ) && (blivit < 'A') ) ||
+          ( blivit > 'Z' ) ) &&
+        ( blivit != '-') && (blivit != '/') && (blivit != '.') )
+   {
+      return 1;
+   }
+   else
+   {
+      return 0;
+   }
+}
+
+void fixname( char *name )
+{
+   while ( *name != '\0' )
+   {
+
+     if (ispunct( *name ) )
+     {
+        *name = '\0';
+     }
+
+     name++;
+   }
+}
+
+void acquire_token( char *line, enum TOKENTYPE type, struct TOKEN *token )
+{
+   int doneflag=0, startflag=1;
+   int index;
+   enum TOKENTYPE nextstate=NONE;
+   char blivit;
+
+   if (token->type == NONE)
+   {
+      token->index = 0;
+      token->length = 0;
+   }
+
+   index = token->index + token->length;
+
+   token->text = 0;
+
+   while ( doneflag == 0 )
+   {
+      blivit = line[index];
+      if ( (blivit >= 'a') && (blivit <= 'z') )
+      {
+         blivit -= ' ';
+      }
+
+      switch (token->type)
+      {
+         case NONE:
+         if ( blivit == ' ')
+         {
+            index++;
+            token->index++;
+         }
+         else
+         {
+            token->type = TAG;
+            nextstate = TAG;
+         }
+         break;
+
+         case BLANKS:
+         if      ( blivit == ' ')
+         {
+            index++;
+         }
+         else if ( ispunct( blivit ) )
+         {
+            token->type = PUNCT;
+            token->index = index;
+         }
+         else
+         {
+            token->type = nextstate;
+            token->index = index;
+         }
+         break;
+
+         case PUNCT:
+         if      ( blivit <  ' ')
+         {
+            doneflag = 1;
+            token->type = NONE;
+            token->index = index;
+            token->text = line + index;
+            token->length = 0;
+         }
+         else if ( blivit == ' ' )
+         {
+            token->type = BLANKS;
+            token->index = index;
+            if      ( line[ token->index ] == ';' )
+            {
+               nextstate = NAME;
+            }
+            else if ( line[ token->index ] == '=' )
+            {
+               nextstate = CONTENT;
+            }
+
+         }
+         else if ( ispunct( blivit ) )
+         {
+            index++;
+         }
+         else
+         {
+            if      ( line[ token->index ] == ';' )
+            {
+               nextstate = NAME;
+            }
+            else if ( line[ token->index ] == '=' )
+            {
+               nextstate = CONTENT;
+            }
+
+            token->type = nextstate;
+            token->index = index;
+         }
+         break;
+
+         case TAG:
+         if ( ispunct( blivit ) )
+         {
+            token->length = index - token->index;
+            token->text = line + token->index;
+            nextstate = NAME;
+
+            if ( ( ( type == TAG ) || ( type == NONE ) ) && !startflag)
+            {
+               doneflag = 1;
+            }
+            else if (blivit == ' ')
+            {
+               token->type = BLANKS;
+               token->index = index;
+            }
+            else
+            {
+               token->type = PUNCT;
+               token->index = index;
+            }
+         }
+         else
+         {
+            index++;
+         }
+         break;
+
+         case NAME:
+         if ( ispunct( blivit ) )
+         {
+            token->length = index - token->index;
+            token->text = line + token->index;
+
+            if ( blivit != ';' )
+            {
+               nextstate = CONTENT;
+            }
+            else
+            {
+               nextstate = NAME;
+            }
+
+            if ( ( ( type == NAME ) || ( type == NONE ) ) && !startflag )
+            {
+               doneflag = 1;
+            }
+            else if (blivit == ' ')
+            {
+               token->type = BLANKS;
+               token->index = index;
+            }
+            else
+            {
+               token->type = PUNCT;
+               token->index = index;
+            }
+         }
+         else
+         {
+            index++;
+         }
+         break;
+
+         case CONTENT:
+         if ( ispunct( blivit ) )
+         {
+            token->length = index - token->index;
+            token->text = line + token->index;
+            nextstate = NAME;
+
+            if ( ( ( type == CONTENT ) || ( type == NONE ) ) && !startflag )
+            {
+               doneflag = 1;
+            }
+            else if (blivit == ' ')
+            {
+               token->type = BLANKS;
+               token->index = index;
+            }
+            else
+            {
+               token->type = PUNCT;
+               token->index = index;
+            }
+         }
+         else
+         {
+            index++;
+         }
+         break;
+      }
+      startflag = 0;
+   }
+}
+
+void fputch( char blivit, FILE *f )
+{
+/*   if (blivit == '\n') fputc( '\r', f );*/
+   fputc( blivit, f );
+}
+
+int classify_args( int narg,
+                   char *rawargs[], char *fileargs[], char *optargs[] )
+{
+   int index, jndex, kndex;
+   char *argptr;
+
+   for ( index = 0, jndex = 0, kndex = 0; index < narg; index++ )
+   {
+      argptr = rawargs[index];
+      if (*argptr == '-')
+      {
+         argptr++;
+         optargs[kndex++] = argptr;
+      }
+      else
+      {
+         fileargs[jndex++] = argptr;
+      }
+   }
+
+   return kndex;
+}
+
+int cvt_ascii( unsigned char alpha )
+{
+   if      ( (alpha >= 'A') && (alpha <= 'Z') ) return (int)(alpha - 'A');
+   else if ( (alpha >= 'a') && (alpha <= 'z') )
+        return 26 + (int)(alpha - 'a');
+   else if ( (alpha >= '0') && (alpha <= '9' ) )
+        return 52 + (int)(alpha - '0');
+   else if ( alpha == '+' ) return 62;
+   else if ( alpha == '/' ) return 63;
+   else if ( alpha == '=' ) return -2;
+   else                     return -1;
+}
+
+char *fileargs[64], *optargs[64];
+
+struct STATE64 {
+                  unsigned long int accum;
+                  int               shift;
+               };
+
+
+int main( int nargs, char *cargs[] )
+{
+   int n_options, n_files, index, jndex, shift, save_shift;
+   enum { ENCODE, DECODE } whattodo = DECODE;
+   int help_flag = 0, replace_flag = 0, perm_replace_flag = 0, quit = 0;
+   int cycle_flag = 0;
+   FILE *fin, *fout = NULL, *dummy;
+   unsigned char blivit;
+   unsigned long accum, value;
+   char buf[80], dumname[80];
+   char *cptr, *altptr;
+   int decode_state;
+   struct TOKEN token;
+   int firsttime = 1;
+   int skipflag = 0;
+   int printmsg = 1;
+   int outcount = 0;
+
+   n_options = classify_args( nargs, cargs, fileargs, optargs );
+
+   n_files = nargs - n_options;
+
+   if ( n_files < 2 ) help_flag = 1;
+
+   for ( index = 0; index < n_options; index++ )
+   {
+      if ( ( optargs[index][0] == 'e' ) ||
+           ( optargs[index][0] == 'E' ) ) whattodo = ENCODE;
+      if ( optargs[index][0] == '?' ) help_flag = 1;
+   }
+
+   if ( help_flag )
+   {
+      printf( "mime64 infile [outfile] [-option] [-option] etc.\n\n"
+              "convert between binary and MIME BASE64 format\n\n"
+              "        -e       MIME base64 encode (default is decode)\n"
+              "        -?       display help message\n\n"
+              "if no outfile given, output file replaces infile\n" );
+   }
+
+   if ( n_files < 2 ) exit(0);
+
+   if ( whattodo == DECODE )
+   {
+      fin = fopen( fileargs[1], "r" );
+   }
+   else
+   {
+      fin = fopen( fileargs[1], "rb" );
+   }
+
+   if ( fin == 0 )
+   {
+      printf( "%s file not found\n", fileargs[1] );
+      exit(-1);
+   }
+
+   if ( n_files > 2 )
+   {
+      if ( whattodo == DECODE )
+      {
+         sprintf( dumname, "%s", fileargs[2] );
+      }
+      else
+      {
+         fout = fopen( fileargs[2], "w" );
+
+	 if ( fout == 0 )
+	 {
+	    printf( "Couldn't open %s for output\n", fileargs[2] );
+	 }
+      }
+   }
+   else
+   {
+      if ( whattodo == DECODE )
+      {
+         sprintf( dumname, "%s", fileargs[1] );
+      }
+      else
+      {
+         fout = fopen( "$$$$$$$$.$$$", "w" );
+      }
+
+      replace_flag = 1;
+   }
+
+
+do {
+   quit = 0;
+   printmsg = 1;
+
+   if ( whattodo == DECODE )
+   {
+      shift = 0;
+      accum = 0;
+      decode_state = 0;
+
+      while ( ( !feof( fin ) ) && (quit == 0) )
+      {
+         fgets( buf, 80, fin );
+         if ( feof( fin ) )
+         {
+            if ( ( dumname[0] != '\0' ) && ( shift != 0 ) )
+            {
+               printf( "Unexpected end of file encountered in %s\n"
+                       "last few bytes may have been lost\n", dumname );
+               quit = 1;
+               decode_state = 1;
+               continue;
+            }
+            else if ( cycle_flag == 0 )
+            {
+               quit = 1;
+               decode_state = 1;
+               continue;
+            }
+         }
+         else
+         {
+            cycle_flag = 1;
+
+            if ( (decode_state == 1) &&
+                 ( (buf[0] == '\n') || (buf[0] < '+') ) )
+            {
+               quit = 1;
+
+               if ( shift != 0 )
+               {
+                  printf( "Unexpected end of section in %s\n"
+                          "last few bytes may have been lost\n", dumname );
+               }
+
+               continue;
+            }
+         }
+
+
+         if ( decode_state == 0 )
+         {
+            for ( index = 0;
+                  (buf[index] != '\n') && (buf[index] != '\0') &&
+                  (decode_state >= 0);
+                  index++ )
+            {
+               if ( ( (buf[index] >= 'A') && (buf[index] <= 'Z') ) ||
+                    ( (buf[index] >= 'a') && (buf[index] <= 'z') ) ||
+                    ( (buf[index] >= '0') && (buf[index] <= '9') ) ||
+                    (buf[index] == '+') ||
+                    (buf[index] == '/') ||
+                    (buf[index] == '=') )
+               {
+                  decode_state = 1;
+               }
+               else
+               {
+                  decode_state = -2;
+               }
+            }
+
+            if ( decode_state <= 0 )
+            {
+
+               decode_state = 0;
+               token.type = NONE;
+
+               acquire_token( buf, TAG, &token );
+               if      ( compare_token( &token, "Content-Type") )
+               {
+                  do
+                  {
+                     acquire_token( buf, NAME, &token );
+                     if ( compare_token( &token, "name" ) )
+                     {
+                        acquire_token( buf, CONTENT, &token );
+
+                        if ( ( replace_flag ) ||
+                             ( firsttime == 0 ) )
+                        {
+                           sscanf( token.text, "%s", dumname );
+                           fixname( dumname );
+
+                           if ( strcmpi( dumname, fileargs[1] ) != 0 )
+                           {
+                              replace_flag = 0;
+                           }
+                           else
+                           {
+                              if ( perm_replace_flag )
+                              {
+                                 printf( 
+                                 "More than one output file named %s\n",
+                                 dumname );
+
+                                 exit(-1);
+                              }
+                           }
+                        }
+                     }
+                  } while ( token.type != NONE );
+               }
+               else if ( compare_token( &token, "Content-transfer-encoding" ) )
+               {
+                  skipflag = 1;
+
+                  do
+                  {
+                     acquire_token( buf, NAME, &token );
+                     if ( compare_token( &token, "base64" ) )
+                     {
+                        skipflag = 0;
+                     }
+                  } while ( token.type != NONE );
+               }
+               continue;
+            }
+            else if ( skipflag != 0 )
+            {
+               continue;
+            }
+         }
+
+         if ( printmsg )
+         {
+            if ( skipflag )
+            {
+               printf( "Section %s not MIME base64\n", dumname );
+            }
+            else
+            {
+               printf( "Creating %s\n", dumname );
+               if ( strcmpi( dumname, fileargs[1] ) == 0 )
+               {
+                  replace_flag = 1;
+               }
+
+               if ( replace_flag )
+               {
+                  fout = fopen( "$$$$$$$$.$$$", "wb" );
+               }
+               else
+               {
+                  fout = fopen( dumname, "wb" );
+               }
+
+               if ( fout == 0 )
+               {
+                  printf( "Couldn't open %s for output\n", dumname );
+               }
+            }
+
+            printmsg = 0;
+         }
+
+         if ( fout == 0 )
+         {
+            printf( "No filename given for subsequent section\n" );
+            exit(-1);
+         }
+
+         if ( feof(fin) )
+         {
+            quit = 1;
+         }
+
+         if ( quit != 0 )
+         {
+            buf[0] = '\0';
+         }
+
+         for ( index = 0; (buf[index] != '\n') && (buf[index] != '\0'); index++)
+         {
+            value = cvt_ascii( buf[index] );
+
+            if ( value < 64 )
+            {
+               accum <<= 6;
+               shift += 6;
+               accum |= value;
+               if ( shift >= 8 )
+               {
+                  shift -= 8;
+                  value = accum >> shift;
+                  blivit = (unsigned char)value & 0xFFl;
+                  fputc( blivit, fout );
+               }
+            }
+            else
+            {
+               quit = 1;
+               break;
+            }
+         }
+      }
+   }
+   else
+   {
+      fprintf ( fout,
+       "Content-Type: text/plain; charset=US-ASCII; name=%s\n"
+       "Content-transfer-encoding: base64\n\n", fileargs[1] );
+
+      shift = 0;
+      accum = 0;
+      index = 0;
+      while ( ( !feof( fin ) ) || (shift != 0) )
+      {
+         if ( ( !feof( fin ) ) && ( quit == 0 ) )
+         {
+            blivit = fgetc( fin );
+
+            if ( feof( fin ) )
+            {
+               quit = 1;
+               save_shift = shift;
+               blivit = 0;
+            }
+         }
+         else
+         {
+            quit = 1;
+            save_shift = shift;
+            blivit = 0;
+         }
+
+         if ( (quit == 0) || (shift != 0) )
+         {
+            value = (unsigned long)blivit;
+            accum <<= 8;
+            shift += 8;
+            accum |= value;
+         } /* ENDIF */
+
+         while ( shift >= 6 )
+         {
+            shift -= 6;
+            value = (accum >> shift) & 0x3Fl;
+            blivit = alphabet[value];
+
+            buf[index++] = blivit;
+            if ( index >= 60 )
+            {
+               buf[index] = '\0';
+               fprintf( fout, "%s\n", buf );
+               index = 0;
+            }
+
+            if ( quit != 0 )
+            {
+               shift = 0;
+            }
+         }
+      }
+
+      if      ( save_shift == 2 )
+      {
+         buf[index++] = '=';
+         if ( index >= 60 )
+         {
+            buf[index] = '\0';
+            fprintf( fout, "%s\n", buf );
+            index = 0;
+         }
+
+         buf[index++] = '=';
+         if ( index >= 60 )
+         {
+            buf[index] = '\0';
+            fprintf( fout, "%s\n", buf );
+            index = 0;
+         }
+      }
+      else if ( save_shift == 4 )
+      {
+         buf[index++] = '=';
+         if ( index >= 60 )
+         {
+            buf[index] = '\0';
+            fprintf( fout, "%s\n", buf );
+            index = 0;
+         }
+      }
+
+      if ( index != 0 )
+      {
+         buf[index] = '\0';
+         fprintf( fout, "%s\n", buf );
+      }
+   }
+
+   if ( fout )
+   {
+      ++outcount;
+      fclose( fout );
+   }
+
+   if ( replace_flag )
+   {
+      perm_replace_flag = 1;
+
+      if ( ( whattodo == DECODE ) && ( decode_state <= 0 ) && ( outcount == 0 ) )
+      {
+         remove( "$$$$$$$$.$$$" );
+         printf( "No MIME base64 lines found in %s\n", fileargs[1] );
+      }
+   }
+   else
+   {
+      if ( ( whattodo == DECODE ) && ( decode_state <= 0 ) && ( outcount == 0 ) )
+      {
+         remove( fileargs[2] );
+         printf( "No MIME base64 lines found in %s\n", fileargs[1] );
+      }
+   }
+
+   fout = 0;
+   firsttime = 0;
+   dumname[0] = '\0';
+   cycle_flag = 0;
+
+} while ( !feof( fin ) );
+
+
+if ( perm_replace_flag )
+{
+   remove( fileargs[1] );
+   rename( "$$$$$$$$.$$$", fileargs[1] );
+}
+
+fclose( fin );
+}
diff --git a/missing b/missing
new file mode 100755
index 00000000..6a37006e
--- /dev/null
+++ b/missing
@@ -0,0 +1,336 @@
+#! /bin/sh
+# Common stub for a few missing GNU programs while installing.
+# Copyright (C) 1996, 1997, 1999, 2000, 2002 Free Software Foundation, Inc.
+# Originally by Fran,cois Pinard <pinard@iro.umontreal.ca>, 1996.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+# 02111-1307, USA.
+
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+if test $# -eq 0; then
+  echo 1>&2 "Try \`$0 --help' for more information"
+  exit 1
+fi
+
+run=:
+
+# In the cases where this matters, `missing' is being run in the
+# srcdir already.
+if test -f configure.ac; then
+  configure_ac=configure.ac
+else
+  configure_ac=configure.in
+fi
+
+case "$1" in
+--run)
+  # Try to run requested program, and just exit if it succeeds.
+  run=
+  shift
+  "$@" && exit 0
+  ;;
+esac
+
+# If it does not exist, or fails to run (possibly an outdated version),
+# try to emulate it.
+case "$1" in
+
+  -h|--h|--he|--hel|--help)
+    echo "\
+$0 [OPTION]... PROGRAM [ARGUMENT]...
+
+Handle \`PROGRAM [ARGUMENT]...' for when PROGRAM is missing, or return an
+error status if there is no known handling for PROGRAM.
+
+Options:
+  -h, --help      display this help and exit
+  -v, --version   output version information and exit
+  --run           try to run the given command, and emulate it if it fails
+
+Supported PROGRAM values:
+  aclocal      touch file \`aclocal.m4'
+  autoconf     touch file \`configure'
+  autoheader   touch file \`config.h.in'
+  automake     touch all \`Makefile.in' files
+  bison        create \`y.tab.[ch]', if possible, from existing .[ch]
+  flex         create \`lex.yy.c', if possible, from existing .c
+  help2man     touch the output file
+  lex          create \`lex.yy.c', if possible, from existing .c
+  makeinfo     touch the output file
+  tar          try tar, gnutar, gtar, then tar without non-portable flags
+  yacc         create \`y.tab.[ch]', if possible, from existing .[ch]"
+    ;;
+
+  -v|--v|--ve|--ver|--vers|--versi|--versio|--version)
+    echo "missing 0.4 - GNU automake"
+    ;;
+
+  -*)
+    echo 1>&2 "$0: Unknown \`$1' option"
+    echo 1>&2 "Try \`$0 --help' for more information"
+    exit 1
+    ;;
+
+  aclocal*)
+    if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
+       # We have it, but it failed.
+       exit 1
+    fi
+
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`acinclude.m4' or \`${configure_ac}'.  You might want
+         to install the \`Automake' and \`Perl' packages.  Grab them from
+         any GNU archive site."
+    touch aclocal.m4
+    ;;
+
+  autoconf)
+    if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
+       # We have it, but it failed.
+       exit 1
+    fi
+
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`${configure_ac}'.  You might want to install the
+         \`Autoconf' and \`GNU m4' packages.  Grab them from any GNU
+         archive site."
+    touch configure
+    ;;
+
+  autoheader)
+    if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
+       # We have it, but it failed.
+       exit 1
+    fi
+
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`acconfig.h' or \`${configure_ac}'.  You might want
+         to install the \`Autoconf' and \`GNU m4' packages.  Grab them
+         from any GNU archive site."
+    files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' ${configure_ac}`
+    test -z "$files" && files="config.h"
+    touch_files=
+    for f in $files; do
+      case "$f" in
+      *:*) touch_files="$touch_files "`echo "$f" |
+				       sed -e 's/^[^:]*://' -e 's/:.*//'`;;
+      *) touch_files="$touch_files $f.in";;
+      esac
+    done
+    touch $touch_files
+    ;;
+
+  automake*)
+    if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
+       # We have it, but it failed.
+       exit 1
+    fi
+
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified \`Makefile.am', \`acinclude.m4' or \`${configure_ac}'.
+         You might want to install the \`Automake' and \`Perl' packages.
+         Grab them from any GNU archive site."
+    find . -type f -name Makefile.am -print |
+	   sed 's/\.am$/.in/' |
+	   while read f; do touch "$f"; done
+    ;;
+
+  autom4te)
+    if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
+       # We have it, but it failed.
+       exit 1
+    fi
+
+    echo 1>&2 "\
+WARNING: \`$1' is needed, and you do not seem to have it handy on your
+         system.  You might have modified some files without having the
+         proper tools for further handling them.
+         You can get \`$1Help2man' as part of \`Autoconf' from any GNU
+         archive site."
+
+    file=`echo "$*" | sed -n 's/.*--output[ =]*\([^ ]*\).*/\1/p'`
+    test -z "$file" && file=`echo "$*" | sed -n 's/.*-o[ ]*\([^ ]*\).*/\1/p'`
+    if test -f "$file"; then
+	touch $file
+    else
+	test -z "$file" || exec >$file
+	echo "#! /bin/sh"
+	echo "# Created by GNU Automake missing as a replacement of"
+	echo "#  $ $@"
+	echo "exit 0"
+	chmod +x $file
+	exit 1
+    fi
+    ;;
+
+  bison|yacc)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified a \`.y' file.  You may need the \`Bison' package
+         in order for those modifications to take effect.  You can get
+         \`Bison' from any GNU archive site."
+    rm -f y.tab.c y.tab.h
+    if [ $# -ne 1 ]; then
+        eval LASTARG="\${$#}"
+	case "$LASTARG" in
+	*.y)
+	    SRCFILE=`echo "$LASTARG" | sed 's/y$/c/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" y.tab.c
+	    fi
+	    SRCFILE=`echo "$LASTARG" | sed 's/y$/h/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" y.tab.h
+	    fi
+	  ;;
+	esac
+    fi
+    if [ ! -f y.tab.h ]; then
+	echo >y.tab.h
+    fi
+    if [ ! -f y.tab.c ]; then
+	echo 'main() { return 0; }' >y.tab.c
+    fi
+    ;;
+
+  lex|flex)
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified a \`.l' file.  You may need the \`Flex' package
+         in order for those modifications to take effect.  You can get
+         \`Flex' from any GNU archive site."
+    rm -f lex.yy.c
+    if [ $# -ne 1 ]; then
+        eval LASTARG="\${$#}"
+	case "$LASTARG" in
+	*.l)
+	    SRCFILE=`echo "$LASTARG" | sed 's/l$/c/'`
+	    if [ -f "$SRCFILE" ]; then
+	         cp "$SRCFILE" lex.yy.c
+	    fi
+	  ;;
+	esac
+    fi
+    if [ ! -f lex.yy.c ]; then
+	echo 'main() { return 0; }' >lex.yy.c
+    fi
+    ;;
+
+  help2man)
+    if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
+       # We have it, but it failed.
+       exit 1
+    fi
+
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+	 you modified a dependency of a manual page.  You may need the
+	 \`Help2man' package in order for those modifications to take
+	 effect.  You can get \`Help2man' from any GNU archive site."
+
+    file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'`
+    if test -z "$file"; then
+	file=`echo "$*" | sed -n 's/.*--output=\([^ ]*\).*/\1/p'`
+    fi
+    if [ -f "$file" ]; then
+	touch $file
+    else
+	test -z "$file" || exec >$file
+	echo ".ab help2man is required to generate this page"
+	exit 1
+    fi
+    ;;
+
+  makeinfo)
+    if test -z "$run" && (makeinfo --version) > /dev/null 2>&1; then
+       # We have makeinfo, but it failed.
+       exit 1
+    fi
+
+    echo 1>&2 "\
+WARNING: \`$1' is missing on your system.  You should only need it if
+         you modified a \`.texi' or \`.texinfo' file, or any other file
+         indirectly affecting the aspect of the manual.  The spurious
+         call might also be the consequence of using a buggy \`make' (AIX,
+         DU, IRIX).  You might want to install the \`Texinfo' package or
+         the \`GNU make' package.  Grab either from any GNU archive site."
+    file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'`
+    if test -z "$file"; then
+      file=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'`
+      file=`sed -n '/^@setfilename/ { s/.* \([^ ]*\) *$/\1/; p; q; }' $file`
+    fi
+    touch $file
+    ;;
+
+  tar)
+    shift
+    if test -n "$run"; then
+      echo 1>&2 "ERROR: \`tar' requires --run"
+      exit 1
+    fi
+
+    # We have already tried tar in the generic part.
+    # Look for gnutar/gtar before invocation to avoid ugly error
+    # messages.
+    if (gnutar --version > /dev/null 2>&1); then
+       gnutar "$@" && exit 0
+    fi
+    if (gtar --version > /dev/null 2>&1); then
+       gtar "$@" && exit 0
+    fi
+    firstarg="$1"
+    if shift; then
+	case "$firstarg" in
+	*o*)
+	    firstarg=`echo "$firstarg" | sed s/o//`
+	    tar "$firstarg" "$@" && exit 0
+	    ;;
+	esac
+	case "$firstarg" in
+	*h*)
+	    firstarg=`echo "$firstarg" | sed s/h//`
+	    tar "$firstarg" "$@" && exit 0
+	    ;;
+	esac
+    fi
+
+    echo 1>&2 "\
+WARNING: I can't seem to be able to run \`tar' with the given arguments.
+         You may want to install GNU tar or Free paxutils, or check the
+         command line arguments."
+    exit 1
+    ;;
+
+  *)
+    echo 1>&2 "\
+WARNING: \`$1' is needed, and you do not seem to have it handy on your
+         system.  You might have modified some files without having the
+         proper tools for further handling them.  Check the \`README' file,
+         it often tells you about the needed prerequirements for installing
+         this package.  You may also peek at any GNU archive site, in case
+         some other package would contain this missing \`$1' program."
+    exit 1
+    ;;
+esac
+
+exit 0
diff --git a/mkinstalldirs b/mkinstalldirs
new file mode 100755
index 00000000..7b09c22a
--- /dev/null
+++ b/mkinstalldirs
@@ -0,0 +1,40 @@
+#! /bin/sh
+# mkinstalldirs --- make directory hierarchy
+# Author: Noah Friedman <friedman@prep.ai.mit.edu>
+# Created: 1993-05-16
+# Public domain
+
+# $Id: mkinstalldirs,v 1.1 2004/06/08 03:59:00 rfunk Exp $
+
+errstatus=0
+
+for file
+do
+   set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'`
+   shift
+
+   pathcomp=
+   for d
+   do
+     pathcomp="$pathcomp$d"
+     case "$pathcomp" in
+       -* ) pathcomp=./$pathcomp ;;
+     esac
+
+     if test ! -d "$pathcomp"; then
+        echo "mkdir $pathcomp"
+
+        mkdir "$pathcomp" || lasterr=$?
+
+        if test ! -d "$pathcomp"; then
+  	  errstatus=$lasterr
+        fi
+     fi
+
+     pathcomp="$pathcomp/"
+   done
+done
+
+exit $errstatus
+
+# mkinstalldirs ends here
diff --git a/po/.cvsignore b/po/.cvsignore
new file mode 100644
index 00000000..f340e8f0
--- /dev/null
+++ b/po/.cvsignore
@@ -0,0 +1,3 @@
+Makefile.in.in
+stamp-cat-id
+ChangeLog
diff --git a/po/.pot b/po/.pot
new file mode 100644
index 00000000..7f2ab664
--- /dev/null
+++ b/po/.pot
@@ -0,0 +1,1885 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 1998-11-30 16:34-0500\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=CHARSET\n"
+"Content-Transfer-Encoding: ENCODING\n"
+
+#: checkalias.c:142
+#, c-format
+msgid "Checking if %s is really the same node as %s"
+msgstr ""
+
+#: checkalias.c:146
+msgid "Yes, their IP addresses match"
+msgstr ""
+
+#: checkalias.c:150
+msgid "No, their IP addresses don't match"
+msgstr ""
+
+#: checkalias.c:168 checkalias.c:193
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s."
+msgstr ""
+
+#: driver.c:137
+#, c-format
+msgid "mapped %s to local %s"
+msgstr ""
+
+#: driver.c:192
+#, c-format
+msgid "passed through %s matching %s"
+msgstr ""
+
+#: driver.c:246
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+
+#: driver.c:285
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver"
+msgstr ""
+
+#: driver.c:291
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver"
+msgstr ""
+
+#: driver.c:362
+msgid "no Received address found"
+msgstr ""
+
+#: driver.c:371
+#, c-format
+msgid "found Received address `%s'"
+msgstr ""
+
+#: driver.c:730
+msgid "message delimiter found while scanning headers"
+msgstr ""
+
+#: driver.c:854
+#, c-format
+msgid "no local matches, forwarding to %s"
+msgstr ""
+
+#: driver.c:868
+msgid "forwarding and deletion suppressed due to DNS errors"
+msgstr ""
+
+#: driver.c:965
+msgid "writing RFC822 msgblk.headers"
+msgstr ""
+
+#: driver.c:985
+msgid "no recipient addresses matched declared local names"
+msgstr ""
+
+#: driver.c:991
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr ""
+
+#: driver.c:999
+msgid "message has embedded NULs"
+msgstr ""
+
+#: driver.c:1006
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr ""
+
+#: driver.c:1121
+msgid "writing message text"
+msgstr ""
+
+#: driver.c:1164
+#, c-format
+msgid "kerberos error %s"
+msgstr ""
+
+#: driver.c:1223
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] "
+msgstr ""
+
+#: driver.c:1318
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail."
+msgstr ""
+
+#: driver.c:1353
+msgid "Kerberos V4 support not linked."
+msgstr ""
+
+#: driver.c:1361
+msgid "Kerberos V5 support not linked."
+msgstr ""
+
+#: driver.c:1372
+#, c-format
+msgid "Option --flush is not supported with %s"
+msgstr ""
+
+#: driver.c:1378
+#, c-format
+msgid "Option --all is not supported with %s"
+msgstr ""
+
+#: driver.c:1386
+#, c-format
+msgid "Option --limit is not supported with %s"
+msgstr ""
+
+#: driver.c:1404
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s."
+msgstr ""
+
+#: driver.c:1408
+#, c-format
+msgid "timeout after %d seconds waiting for server %s."
+msgstr ""
+
+#: driver.c:1412
+#, c-format
+msgid "timeout after %d seconds waiting for %s."
+msgstr ""
+
+#: driver.c:1417
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond."
+msgstr ""
+
+#: driver.c:1419
+#, c-format
+msgid "timeout after %d seconds."
+msgstr ""
+
+#: driver.c:1435
+msgid "Subject: fetchmail sees repeated timeouts\r\n"
+msgstr ""
+
+#: driver.c:1437
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timouts while attempting to get mail from %s@%s."
+msgstr ""
+
+#: driver.c:1442
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP listener"
+msgstr ""
+
+#: driver.c:1444
+msgid ""
+"is wedged, or that your mailbox file on the server has been corrupted by"
+msgstr ""
+
+#: driver.c:1446
+msgid "a server error.  You can run `fetchmail -v -v' to diagnose the problem."
+msgstr ""
+
+#: driver.c:1448
+msgid "Fetchmail won't poll this mailbox again until you restart it."
+msgstr ""
+
+#: driver.c:1469
+#, c-format
+msgid "pre-connection command failed with status %d"
+msgstr ""
+
+#: driver.c:1496
+msgid "fetchmail: internal inconsistency"
+msgstr ""
+
+#: driver.c:1506
+#, c-format
+msgid "fetchmail: %s connection to %s failed"
+msgstr ""
+
+#: driver.c:1512
+msgid ": host is unknown"
+msgstr ""
+
+#: driver.c:1514
+msgid ": name is valid but has no IP address"
+msgstr ""
+
+#: driver.c:1516
+msgid ": unrecoverable name server error"
+msgstr ""
+
+#: driver.c:1518
+msgid ": temporary name server error"
+msgstr ""
+
+#: driver.c:1520
+#, c-format
+msgid ": unknown DNS error %d"
+msgstr ""
+
+#: driver.c:1576
+#, c-format
+msgid "Lock-busy error on %s@%s"
+msgstr ""
+
+#: driver.c:1583
+#, c-format
+msgid "Authorization failure on %s@%s"
+msgstr ""
+
+#: driver.c:1597
+msgid "Subject: fetchmail authentication failed\r\n"
+msgstr ""
+
+#: driver.c:1599
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s."
+msgstr ""
+
+#: driver.c:1603
+msgid "The attempt to get authorization failed."
+msgstr ""
+
+#: driver.c:1605
+msgid "This probably means your password is invalid."
+msgstr ""
+
+#: driver.c:1626
+#, c-format
+msgid "selecting or re-polling folder %s"
+msgstr ""
+
+#: driver.c:1628
+msgid "selecting or re-polling default folder"
+msgstr ""
+
+#: driver.c:1664
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr ""
+
+#: driver.c:1667
+#, c-format
+msgid "%s at %s"
+msgstr ""
+
+#. only used for ETRN
+#: driver.c:1671
+#, c-format
+msgid "Polling %s"
+msgstr ""
+
+#: driver.c:1675
+#, c-format
+msgid "%d %s (%d seen) for %s"
+msgstr ""
+
+#: driver.c:1676 driver.c:1681
+msgid "messages"
+msgstr ""
+
+#: driver.c:1677 driver.c:1682
+msgid "message"
+msgstr ""
+
+#: driver.c:1680
+#, c-format
+msgid "%d %s for %s"
+msgstr ""
+
+#: driver.c:1686
+#, c-format
+msgid " (%d octets)."
+msgstr ""
+
+#: driver.c:1692
+#, c-format
+msgid "No mail for %s"
+msgstr ""
+
+#: driver.c:1766
+#, c-format
+msgid "Skipping message %d, length -1"
+msgstr ""
+
+#: driver.c:1776
+#, c-format
+msgid "skipping message %d"
+msgstr ""
+
+#: driver.c:1821
+#, c-format
+msgid " (oversized, %d octets)"
+msgstr ""
+
+#: driver.c:1844
+#, c-format
+msgid "reading message %d of %d"
+msgstr ""
+
+#: driver.c:1848
+#, c-format
+msgid " (%d %soctets)"
+msgstr ""
+
+#: driver.c:1849
+msgid "header "
+msgstr ""
+
+#: driver.c:1894
+#, c-format
+msgid " (%d body octets) "
+msgstr ""
+
+#: driver.c:1963
+#, c-format
+msgid "message %d was not the expected length (%d actual != %d expected)"
+msgstr ""
+
+#: driver.c:2001
+msgid " retained"
+msgstr ""
+
+#: driver.c:2009
+msgid " flushed"
+msgstr ""
+
+#: driver.c:2018
+msgid " not flushed"
+msgstr ""
+
+#: driver.c:2024
+#, c-format
+msgid "fetchlimit reached; %d messages left on server"
+msgstr ""
+
+#: driver.c:2066
+msgid "socket"
+msgstr ""
+
+#: driver.c:2069
+msgid "authorization"
+msgstr ""
+
+#: driver.c:2072
+msgid "missing or bad RFC822 header"
+msgstr ""
+
+#: driver.c:2075
+msgid "MDA"
+msgstr ""
+
+#: driver.c:2078
+msgid "client/server synchronization"
+msgstr ""
+
+#: driver.c:2081
+msgid "client/server protocol"
+msgstr ""
+
+#: driver.c:2084
+msgid "lock busy on server"
+msgstr ""
+
+#: driver.c:2087
+msgid "SMTP transaction"
+msgstr ""
+
+#: driver.c:2090
+msgid "DNS lookup"
+msgstr ""
+
+#: driver.c:2093
+msgid "undefined"
+msgstr ""
+
+#: driver.c:2099
+#, c-format
+msgid "%s error while fetching from %s"
+msgstr ""
+
+#: driver.c:2107
+#, c-format
+msgid "post-connection command failed with status %d"
+msgstr ""
+
+#: env.c:59
+#, c-format
+msgid "%s: can't find your name and home directory!\n"
+msgstr ""
+
+#: env.c:84
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr ""
+
+#: env.c:100
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr ""
+
+#: error.c:109
+msgid "Unknown system error"
+msgstr ""
+
+#: error.c:140
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr ""
+
+#: error.c:236
+#, c-format
+msgid ": Error %d"
+msgstr ""
+
+#: error.c:340 error.c:368 error.c:442 error.c:470
+msgid "partial error message buffer overflow"
+msgstr ""
+
+#: etrn.c:44
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP"
+msgstr ""
+
+#: etrn.c:50
+#, c-format
+msgid "%s's SMTP listener does not support ETRN"
+msgstr ""
+
+#. OK, queuing for node <x> started
+#: etrn.c:73
+#, c-format
+msgid "Queuing for %s started"
+msgstr ""
+
+#. OK, no messages waiting for node <x>
+#: etrn.c:77
+#, c-format
+msgid "No messages waiting for %s"
+msgstr ""
+
+#. OK, pending messages for node <x> started
+#. OK, <n> pending messages for node <x> started
+#: etrn.c:82
+#, c-format
+msgid "Pending messages for %s started"
+msgstr ""
+
+#. Unable to queue messages for node <x>
+#: etrn.c:86
+#, c-format
+msgid "Unable to queue messages for node %s"
+msgstr ""
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:90
+#, c-format
+msgid "Node %s not allowed: %s"
+msgstr ""
+
+#. Syntax Error
+#: etrn.c:94
+msgid "ETRN syntax error"
+msgstr ""
+
+#. Syntax Error in Parameters
+#: etrn.c:98
+msgid "ETRN syntax error in parameters"
+msgstr ""
+
+#: etrn.c:102
+#, c-format
+msgid "Unknown ETRN error %d"
+msgstr ""
+
+#: etrn.c:146
+msgid "Option --keep is not supported with ETRN\n"
+msgstr ""
+
+#: etrn.c:150
+msgid "Option --flush is not supported with ETRN\n"
+msgstr ""
+
+#: etrn.c:154
+msgid "Option --remote is not supported with ETRN\n"
+msgstr ""
+
+#: etrn.c:158
+msgid "Option --check is not supported with ETRN\n"
+msgstr ""
+
+#: fetchmail.c:134
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr ""
+
+#: fetchmail.c:174
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr ""
+
+#: fetchmail.c:238
+msgid "Taking options from command line"
+msgstr ""
+
+#: fetchmail.c:242
+#, c-format
+msgid " and %s\n"
+msgstr ""
+
+#: fetchmail.c:244
+#, c-format
+msgid "Lockfile at %s\n"
+msgstr ""
+
+#: fetchmail.c:248
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr ""
+
+#: fetchmail.c:265
+msgid "fetchmail: cannot allocate memory for lock name.\n"
+msgstr ""
+
+#: fetchmail.c:275
+msgid "fetchmail: removing stale lockfile\n"
+msgstr ""
+
+#: fetchmail.c:285
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr ""
+
+#: fetchmail.c:294
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr ""
+
+#: fetchmail.c:300
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr ""
+
+#: fetchmail.c:301 fetchmail.c:307
+msgid "background"
+msgstr ""
+
+#: fetchmail.c:301 fetchmail.c:307
+msgid "foreground"
+msgstr ""
+
+#: fetchmail.c:306
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr ""
+
+#: fetchmail.c:322
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+
+#: fetchmail.c:328
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+
+#: fetchmail.c:335
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr ""
+
+#: fetchmail.c:342
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+
+#: fetchmail.c:348
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr ""
+
+#: fetchmail.c:360
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr ""
+
+#: fetchmail.c:419
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr ""
+
+#: fetchmail.c:459
+#, c-format
+msgid "starting fetchmail %s daemon "
+msgstr ""
+
+#: fetchmail.c:519
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)"
+msgstr ""
+
+#: fetchmail.c:532
+#, c-format
+msgid "interval not reached, not querying %s"
+msgstr ""
+
+#: fetchmail.c:559
+msgid "saved UID List"
+msgstr ""
+
+#: fetchmail.c:565
+#, c-format
+msgid "Query status=%d"
+msgstr ""
+
+#: fetchmail.c:621
+msgid "All connections are wedged.  Exiting."
+msgstr ""
+
+#: fetchmail.c:626
+#, c-format
+msgid "fetchmail: sleeping at %s"
+msgstr ""
+
+#: fetchmail.c:721
+#, c-format
+msgid "awakened by %s"
+msgstr ""
+
+#: fetchmail.c:723
+#, c-format
+msgid "awakened by signal %d"
+msgstr ""
+
+#: fetchmail.c:734
+#, c-format
+msgid "awakened at %s"
+msgstr ""
+
+#: fetchmail.c:740
+#, c-format
+msgid "normal termination, status %d"
+msgstr ""
+
+#: fetchmail.c:867
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr ""
+
+#: fetchmail.c:975
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+
+#: fetchmail.c:1014
+#, c-format
+msgid "couldn't find HESIOD pobox for %s"
+msgstr ""
+
+#: fetchmail.c:1040
+#, c-format
+msgid "couldn't find canonical DNS name of %s"
+msgstr ""
+
+#: fetchmail.c:1064
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr ""
+
+#: fetchmail.c:1071
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr ""
+
+#: fetchmail.c:1091
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+
+#: fetchmail.c:1156
+#, c-format
+msgid "terminated with signal %d"
+msgstr ""
+
+#: fetchmail.c:1216
+#, c-format
+msgid "fetchmail: %s querying %s (protocol %s) at %s"
+msgstr ""
+
+#: fetchmail.c:1235
+msgid "POP2 support is not configured.\n"
+msgstr ""
+
+#: fetchmail.c:1245
+msgid "POP3 support is not configured.\n"
+msgstr ""
+
+#: fetchmail.c:1257
+msgid "IMAP support is not configured.\n"
+msgstr ""
+
+#: fetchmail.c:1263
+msgid "ETRN support is not configured.\n"
+msgstr ""
+
+#: fetchmail.c:1269
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr ""
+
+#: fetchmail.c:1274
+msgid "unsupported protocol selected."
+msgstr ""
+
+#: fetchmail.c:1286
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr ""
+
+#: fetchmail.c:1288
+#, c-format
+msgid "Logfile is %s\n"
+msgstr ""
+
+#: fetchmail.c:1290
+#, c-format
+msgid "Idfile is %s\n"
+msgstr ""
+
+#: fetchmail.c:1293
+msgid "Progress messages will be logged via syslog\n"
+msgstr ""
+
+#: fetchmail.c:1296
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr ""
+
+#: fetchmail.c:1298
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr ""
+
+#: fetchmail.c:1306
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr ""
+
+#: fetchmail.c:1310
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr ""
+
+#: fetchmail.c:1313
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr ""
+
+#: fetchmail.c:1316
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr ""
+
+#: fetchmail.c:1318
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr ""
+
+#: fetchmail.c:1319 fetchmail.c:1391 fetchmail.c:1394
+msgid "will not"
+msgstr ""
+
+#: fetchmail.c:1319 fetchmail.c:1391 fetchmail.c:1394
+msgid "will"
+msgstr ""
+
+#: fetchmail.c:1329
+msgid "  Password will be prompted for.\n"
+msgstr ""
+
+#: fetchmail.c:1332
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1334
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1336
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1345
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr ""
+
+#: fetchmail.c:1348
+#, c-format
+msgid "  Protocol is %s"
+msgstr ""
+
+#: fetchmail.c:1351
+#, c-format
+msgid " (using service %s)"
+msgstr ""
+
+#: fetchmail.c:1353
+#, c-format
+msgid " (using network security options %s)"
+msgstr ""
+
+#: fetchmail.c:1356
+#, c-format
+msgid " (using port %d)"
+msgstr ""
+
+#: fetchmail.c:1359
+msgid " (using default port)"
+msgstr ""
+
+#: fetchmail.c:1361
+msgid " (forcing UIDL use)"
+msgstr ""
+
+#: fetchmail.c:1365
+msgid "  Kerberos V4 preauthentication enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1367
+msgid "  Kerberos V5 preauthentication enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1369
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr ""
+
+#: fetchmail.c:1371
+msgid " (default).\n"
+msgstr ""
+
+#: fetchmail.c:1377
+msgid "  Default mailbox selected.\n"
+msgstr ""
+
+#: fetchmail.c:1382
+msgid "  Selected mailboxes are:"
+msgstr ""
+
+#: fetchmail.c:1387
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr ""
+
+#: fetchmail.c:1388
+msgid "All"
+msgstr ""
+
+#: fetchmail.c:1388
+msgid "Only new"
+msgstr ""
+
+#: fetchmail.c:1390
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr ""
+
+#: fetchmail.c:1393
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+
+#: fetchmail.c:1396
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr ""
+
+#: fetchmail.c:1397 fetchmail.c:1400 fetchmail.c:1403 fetchmail.c:1406
+#: fetchmail.c:1409 fetchmail.c:1517
+msgid "enabled"
+msgstr ""
+
+#: fetchmail.c:1397 fetchmail.c:1400 fetchmail.c:1403 fetchmail.c:1406
+#: fetchmail.c:1409 fetchmail.c:1517
+msgid "disabled"
+msgstr ""
+
+#: fetchmail.c:1399
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr ""
+
+#: fetchmail.c:1402
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr ""
+
+#: fetchmail.c:1405
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+
+#: fetchmail.c:1408
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr ""
+
+#: fetchmail.c:1411
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr ""
+
+#: fetchmail.c:1412
+msgid "discarded"
+msgstr ""
+
+#: fetchmail.c:1412
+msgid "kept"
+msgstr ""
+
+#: fetchmail.c:1417
+#, c-format
+msgid "  Message size limit is %d bytes (--limit %d).\n"
+msgstr ""
+
+#: fetchmail.c:1420
+msgid "  No message size limit (--limit 0).\n"
+msgstr ""
+
+#: fetchmail.c:1422
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+
+#: fetchmail.c:1425
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+
+#: fetchmail.c:1428
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr ""
+
+#: fetchmail.c:1431
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr ""
+
+#: fetchmail.c:1433
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr ""
+
+#: fetchmail.c:1435
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr ""
+
+#: fetchmail.c:1438
+#, c-format
+msgid "  Deletion interval between expunges is %d (--expunge %d).\n"
+msgstr ""
+
+#: fetchmail.c:1440
+msgid "  No expunges (--expunge 0).\n"
+msgstr ""
+
+#: fetchmail.c:1443
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr ""
+
+#: fetchmail.c:1445
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1450
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr ""
+
+#: fetchmail.c:1455
+msgid " (default)"
+msgstr ""
+
+#: fetchmail.c:1459
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr ""
+
+#: fetchmail.c:1468
+msgid "  Recognized listener spam block responses are:"
+msgstr ""
+
+#: fetchmail.c:1474
+msgid "  Spam-blocking disabled\n"
+msgstr ""
+
+#: fetchmail.c:1477
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1480
+msgid "  No pre-connection command.\n"
+msgstr ""
+
+#: fetchmail.c:1482
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1485
+msgid "  No post-connection command.\n"
+msgstr ""
+
+#: fetchmail.c:1488
+msgid "  No localnames declared for this host.\n"
+msgstr ""
+
+#: fetchmail.c:1498
+msgid "  Multi-drop mode: "
+msgstr ""
+
+#: fetchmail.c:1500
+msgid "  Single-drop mode: "
+msgstr ""
+
+#: fetchmail.c:1502
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr ""
+
+#: fetchmail.c:1516
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr ""
+
+#: fetchmail.c:1520
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr ""
+
+#: fetchmail.c:1522
+msgid "IP address.\n"
+msgstr ""
+
+#: fetchmail.c:1524
+msgid "name.\n"
+msgstr ""
+
+#: fetchmail.c:1527
+msgid "  Envelope-address routing is disabled\n"
+msgstr ""
+
+#: fetchmail.c:1530
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr ""
+
+#: fetchmail.c:1531
+msgid "Received"
+msgstr ""
+
+#: fetchmail.c:1533
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr ""
+
+#: fetchmail.c:1536
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr ""
+
+#: fetchmail.c:1539
+msgid "  No prefix stripping\n"
+msgstr ""
+
+#: fetchmail.c:1546
+msgid "  Predeclared mailserver aliases:"
+msgstr ""
+
+#: fetchmail.c:1555
+msgid "  Local domains:"
+msgstr ""
+
+#: fetchmail.c:1565
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr ""
+
+#: fetchmail.c:1567
+msgid "  No interface requirement specified.\n"
+msgstr ""
+
+#: fetchmail.c:1569
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr ""
+
+#: fetchmail.c:1571
+msgid "  No monitor interface specified.\n"
+msgstr ""
+
+#: fetchmail.c:1575
+#, c-format
+msgid "  Server connections will be mode via plugin %s (--plugin %s).\n"
+msgstr ""
+
+#: fetchmail.c:1577
+msgid "  No plugin command specified.\n"
+msgstr ""
+
+#: fetchmail.c:1579
+#, c-format
+msgid "  Listener connections will be mode via plugout %s (--plugout %s).\n"
+msgstr ""
+
+#: fetchmail.c:1581
+msgid "  No plugout command specified.\n"
+msgstr ""
+
+#: fetchmail.c:1585
+msgid "  No UIDs saved from this host.\n"
+msgstr ""
+
+#: fetchmail.c:1594
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr ""
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr ""
+
+#: getpass.c:73
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr ""
+
+#: getpass.c:195
+msgid ""
+"\n"
+"Caught signal... bailing out."
+msgstr ""
+
+#: imap.c:147
+msgid "Could not decode initial BASE64 challenge"
+msgstr ""
+
+#: imap.c:163
+msgid "Could not decode OTP challenge"
+msgstr ""
+
+#: imap.c:170 pop3.c:183
+msgid "Secret pass phrase: "
+msgstr ""
+
+#: imap.c:246
+msgid "could not decode initial BASE64 challenge"
+msgstr ""
+
+#: imap.c:296
+#, c-format
+msgid "principal %s in ticket does not match -u %s"
+msgstr ""
+
+#: imap.c:302
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior"
+msgstr ""
+
+#: imap.c:368
+msgid "could not decode BASE64 ready response"
+msgstr ""
+
+#: imap.c:375
+msgid "challenge mismatch"
+msgstr ""
+
+#: imap.c:448
+#, c-format
+msgid "Couldn't get service name for [%s]"
+msgstr ""
+
+#: imap.c:454
+#, c-format
+msgid "Using service name [%s]"
+msgstr ""
+
+#: imap.c:470
+msgid "Sending credentials"
+msgstr ""
+
+#: imap.c:476
+msgid "Error exchanging credentials"
+msgstr ""
+
+#: imap.c:512
+msgid "Couldn't unwrap security level data"
+msgstr ""
+
+#: imap.c:517
+msgid "Credential exchange complete"
+msgstr ""
+
+#: imap.c:521
+msgid "Server requires integrity and/or privacy"
+msgstr ""
+
+#: imap.c:530
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s"
+msgstr ""
+
+#: imap.c:534
+#, c-format
+msgid "Maximum GSS token size is %ld"
+msgstr ""
+
+#: imap.c:547
+msgid "Error creating security level request"
+msgstr ""
+
+#: imap.c:552
+#, c-format
+msgid "Requesting authorisation as %s"
+msgstr ""
+
+#: imap.c:564
+msgid "Releasing GSS credentials"
+msgstr ""
+
+#: imap.c:567
+msgid "Error releasing credentials"
+msgstr ""
+
+#: imap.c:614
+msgid "Protocol identified as IMAP4 rev 1"
+msgstr ""
+
+#: imap.c:620
+msgid "Protocol identified as IMAP4 rev 0"
+msgstr ""
+
+#: imap.c:627
+msgid "Protocol identified as IMAP2 or IMAP2BIS"
+msgstr ""
+
+#: imap.c:638
+msgid "OTP authentication is supported"
+msgstr ""
+
+#: imap.c:650
+msgid "GSS authentication is supported"
+msgstr ""
+
+#: imap.c:656
+msgid "Required GSS capability not supported by server"
+msgstr ""
+
+#: imap.c:665
+msgid "KERBEROS_V4 authentication is supported"
+msgstr ""
+
+#: imap.c:682
+msgid "Required KERBEROS_V4 capability not supported by server"
+msgstr ""
+
+#: imap.c:690
+msgid "Required LOGIN capability not supported by server"
+msgstr ""
+
+#: imap.c:744
+msgid "re-poll failed"
+msgstr ""
+
+#: imap.c:761
+msgid "mailbox selection failed"
+msgstr ""
+
+#: interface.c:173
+msgid "missing IP interface address"
+msgstr ""
+
+#: interface.c:185
+msgid "invalid IP interface address"
+msgstr ""
+
+#: interface.c:187
+msgid "invalid IP interface mask"
+msgstr ""
+
+#: interface.c:223
+#, c-format
+msgid "activity on %s -noted- as %d"
+msgstr ""
+
+#: interface.c:237
+#, c-format
+msgid "skipping poll of %s, %s down"
+msgstr ""
+
+#: interface.c:246
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded"
+msgstr ""
+
+#: interface.c:257
+#, c-format
+msgid "activity on %s checked as %d"
+msgstr ""
+
+#: interface.c:264
+#, c-format
+msgid "skipping poll of %s, %s inactive"
+msgstr ""
+
+#: netrc.c:228
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr ""
+
+#: netrc.c:232
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr ""
+
+#: netrc.c:268
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr ""
+
+#: options.c:163 options.c:207
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr ""
+
+#: options.c:172
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr ""
+
+#: options.c:173
+msgid "smaller"
+msgstr ""
+
+#: options.c:173
+msgid "larger"
+msgstr ""
+
+#: options.c:347
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr ""
+
+#: options.c:378
+#, c-format
+msgid "Invalid preauthentication `%s' specified.\n"
+msgstr ""
+
+#: options.c:496
+msgid "fetchmail: network security support is disabled\n"
+msgstr ""
+
+#: options.c:551
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr ""
+
+#: options.c:552
+msgid "  Options are as follows:\n"
+msgstr ""
+
+#: options.c:553
+msgid "  -?, --help        display this option help\n"
+msgstr ""
+
+#: options.c:554
+msgid "  -V, --version     display version info\n"
+msgstr ""
+
+#: options.c:556
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr ""
+
+#: options.c:557
+msgid "  -s, --silent      work silently\n"
+msgstr ""
+
+#: options.c:558
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr ""
+
+#: options.c:559
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr ""
+
+#: options.c:560
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr ""
+
+#: options.c:561
+msgid "  -q, --quit        kill daemon process\n"
+msgstr ""
+
+#: options.c:562
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr ""
+
+#: options.c:563
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+
+#: options.c:564
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+
+#: options.c:565
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr ""
+
+#: options.c:566
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr ""
+
+#: options.c:567
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr ""
+
+#: options.c:569
+msgid "  -I, --interface   interface required specification\n"
+msgstr ""
+
+#: options.c:570
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr ""
+
+#: options.c:572
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+
+#: options.c:573
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+
+#: options.c:575
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+
+#: options.c:576
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr ""
+
+#: options.c:577
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr ""
+
+#: options.c:578
+msgid "  -A, --auth        authentication type (password or kerberos)\n"
+msgstr ""
+
+#: options.c:579
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr ""
+
+#: options.c:580
+msgid "  -E, --envelope    envelope address header\n"
+msgstr ""
+
+#: options.c:581
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+
+#: options.c:583
+msgid "  -u, --username    specify users's login on server\n"
+msgstr ""
+
+#: options.c:584
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr ""
+
+#: options.c:585
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr ""
+
+#: options.c:586
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr ""
+
+#: options.c:587
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr ""
+
+#: options.c:588
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr ""
+
+#: options.c:589
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr ""
+
+#: options.c:590
+msgid "  -w, --warnings   interval between warning mail notification\n"
+msgstr ""
+
+#: options.c:593
+msgid "  -T, --netsec      set IP security request\n"
+msgstr ""
+
+#: options.c:595
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr ""
+
+#: options.c:596
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr ""
+
+#: options.c:597
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr ""
+
+#: options.c:598
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+
+#: options.c:599
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+
+#: options.c:600
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+
+#: options.c:601
+msgid "      --mda         set MDA to use for forwarding\n"
+msgstr ""
+
+#: options.c:602
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr ""
+
+#: options.c:603
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr ""
+
+#: options.c:604
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr ""
+
+#: pop3.c:209
+msgid "Required APOP timestamp not found in greeting"
+msgstr ""
+
+#: pop3.c:217
+msgid "Timestamp syntax error in greeting"
+msgstr ""
+
+#: pop3.c:239
+msgid "Undefined protocol request in POP3_auth"
+msgstr ""
+
+#: pop3.c:247
+msgid "lock busy!  Is another session active?"
+msgstr ""
+
+#: pop3.c:355
+msgid "Messages inserted into list on server. Cannot handle this."
+msgstr ""
+
+#: pop3.c:429
+msgid "protocol error"
+msgstr ""
+
+#: pop3.c:442
+msgid "protocol error while fetching UIDLs"
+msgstr ""
+
+#: pop3.c:666
+msgid "Option --remote is not supported with POP3\n"
+msgstr ""
+
+#: rpa.c:116
+msgid "Success"
+msgstr ""
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr ""
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr ""
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr ""
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr ""
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr ""
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):"
+msgstr ""
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr ""
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr ""
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr ""
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr ""
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr ""
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):"
+msgstr ""
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr ""
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr ""
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr ""
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr ""
+
+#: rpa.c:293
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr ""
+
+#: rpa.c:298
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr ""
+
+#: rpa.c:304
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr ""
+
+#: rpa.c:309
+msgid "Session key established:"
+msgstr ""
+
+#: rpa.c:340
+msgid "RPA authorisation complete\n"
+msgstr ""
+
+#: rpa.c:369
+msgid "Get response\n"
+msgstr ""
+
+#: rpa.c:399
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr ""
+
+#: rpa.c:461
+msgid "Hdr not 60\n"
+msgstr ""
+
+#: rpa.c:482
+msgid "Token length error\n"
+msgstr ""
+
+#: rpa.c:487
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr ""
+
+#: rpa.c:493
+msgid "Mechanism field incorrect\n"
+msgstr ""
+
+#: rpa.c:530
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr ""
+
+#: rpa.c:545
+msgid "Inbound binary data:\n"
+msgstr ""
+
+#: rpa.c:583
+msgid "Outbound data:\n"
+msgstr ""
+
+#: rpa.c:649
+msgid "RPA String too long\n"
+msgstr ""
+
+#: rpa.c:654
+msgid "Unicode:"
+msgstr ""
+
+#: rpa.c:716
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr ""
+
+#: rpa.c:717
+msgid "    prevent you logging in, but means you\n"
+msgstr ""
+
+#: rpa.c:718
+msgid "    cannot be sure you are talking to the\n"
+msgstr ""
+
+#: rpa.c:719
+msgid "    service that you think you are (replay\n"
+msgstr ""
+
+#: rpa.c:720
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr ""
+
+#: rpa.c:731
+msgid "User challenge:"
+msgstr ""
+
+#: rpa.c:889
+msgid "MD5 being applied to data block:\n"
+msgstr ""
+
+#: rpa.c:902
+msgid "MD5 result is: "
+msgstr ""
+
+#: sink.c:162
+#, c-format
+msgid "forwarding to %s"
+msgstr ""
+
+#: sink.c:380
+msgid "BSMTP file open or preamble write failed"
+msgstr ""
+
+#: sink.c:501
+#, c-format
+msgid "about to deliver with: %s"
+msgstr ""
+
+#: sink.c:524
+msgid "MDA open failed"
+msgstr ""
+
+#: sink.c:538
+#, c-format
+msgid "%cMTP connect to %s failed"
+msgstr ""
+
+#: sink.c:620
+#, c-format
+msgid "%cMTP error: %s"
+msgstr ""
+
+#: sink.c:691
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'"
+msgstr ""
+
+#: sink.c:705
+#, c-format
+msgid "can't even send to %s!"
+msgstr ""
+
+#: sink.c:758
+msgid "MDA exited abnormally or returned nonzero status"
+msgstr ""
+
+#: sink.c:770
+msgid "Message termination or close of BSMTP file failed"
+msgstr ""
+
+#: sink.c:779
+msgid "SMTP listener refused delivery"
+msgstr ""
+
+#: sink.c:806
+msgid "LMTP delivery error on EOM"
+msgstr ""
+
+#: sink.c:809
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s"
+msgstr ""
+
+#: socket.c:57
+#, c-format
+msgid "fetchmail: socketpair failed: %s(%d)"
+msgstr ""
+
+#: socket.c:65
+#, c-format
+msgid "running %s %s %s"
+msgstr ""
+
+#: socket.c:67
+#, c-format
+msgid "execl(%s) failed: %s (%d)"
+msgstr ""
+
+#: socket.c:92
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s): %s(%d)"
+msgstr ""
+
+#: socket.c:170
+#, c-format
+msgid "fetchmail: illegal address length received for host %s"
+msgstr ""
+
+#: xmalloc.c:32
+msgid "malloc failed"
+msgstr ""
+
+#: xmalloc.c:43
+msgid "realloc failed"
+msgstr ""
diff --git a/po/Makefile.in.in b/po/Makefile.in.in
new file mode 100644
index 00000000..d2c18793
--- /dev/null
+++ b/po/Makefile.in.in
@@ -0,0 +1,251 @@
+# Makefile for program source directory in GNU NLS utilities package.
+# Copyright (C) 1995, 1996, 1997 by Ulrich Drepper <drepper@gnu.ai.mit.edu>
+#
+# This file file be copied and used freely without restrictions.  It can
+# be used in projects which are not available under the GNU Public License
+# but which still want to provide support for the GNU gettext functionality.
+# Please note that the actual code is *not* freely available.
+
+PACKAGE = @PACKAGE@
+VERSION = @VERSION@
+
+SHELL = /bin/sh
+@SET_MAKE@
+
+srcdir = @srcdir@
+top_builddir = ..
+top_srcdir = @top_srcdir@
+VPATH = @srcdir@
+
+prefix = @prefix@
+exec_prefix = @exec_prefix@
+datadir = $(prefix)/@DATADIRNAME@
+localedir = $(datadir)/locale
+gnulocaledir = $(prefix)/share/locale
+gettextsrcdir = $(prefix)/share/gettext/po
+subdir = po
+
+DESTDIR =
+
+INSTALL = @INSTALL@
+INSTALL_DATA = @INSTALL_DATA@
+MKINSTALLDIRS = $(top_srcdir)/@MKINSTALLDIRS@
+
+CC = @CC@
+GENCAT = @GENCAT@
+GMSGFMT = PATH=../src:$$PATH @GMSGFMT@
+MSGFMT = @MSGFMT@
+XGETTEXT = PATH=../src:$$PATH @XGETTEXT@
+MSGMERGE = PATH=../src:$$PATH msgmerge
+
+DEFS = @DEFS@
+CFLAGS = @CFLAGS@
+CPPFLAGS = @CPPFLAGS@
+
+INCLUDES = -I.. -I$(top_srcdir)/intl
+
+COMPILE = $(CC) -c $(DEFS) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(XCFLAGS)
+
+SOURCES = cat-id-tbl.c
+POFILES = @POFILES@
+GMOFILES = @GMOFILES@
+DISTFILES = ChangeLog Makefile.in.in POTFILES.in $(PACKAGE).pot \
+stamp-cat-id $(POFILES) $(GMOFILES) $(SOURCES)
+
+POTFILES = $(top_builddir)/rcfile_y.c \
+
+CATALOGS = @CATALOGS@
+CATOBJEXT = @CATOBJEXT@
+INSTOBJEXT = @INSTOBJEXT@
+
+.SUFFIXES:
+.SUFFIXES: .c .o .po .pox .gmo .mo .msg .cat
+
+.c.o:
+	$(COMPILE) $<
+
+.po.pox:
+	$(MAKE) $(PACKAGE).pot
+	$(MSGMERGE) $< $(srcdir)/$(PACKAGE).pot -o $*.pox
+
+.po.mo:
+	$(MSGFMT) -o $@ $<
+
+.po.gmo:
+	file=$(srcdir)/`echo $* | sed 's,.*/,,'`.gmo \
+	  && rm -f $$file && $(GMSGFMT) -o $$file $<
+
+.po.cat:
+	sed -f ../intl/po2msg.sed < $< > $*.msg \
+	  && rm -f $@ && $(GENCAT) $@ $*.msg
+
+
+all: all-@USE_NLS@
+
+all-yes: cat-id-tbl.c $(CATALOGS)
+all-no:
+
+$(srcdir)/$(PACKAGE).pot: $(POTFILES)
+	$(XGETTEXT) --default-domain=$(PACKAGE) --directory=$(top_srcdir) \
+	  --add-comments --keyword=GT_ --keyword=NGT_ \
+	  --files-from=$(srcdir)/POTFILES.in \
+	&& test ! -f $(PACKAGE).po \
+	   || ( rm -f $(srcdir)/$(PACKAGE).pot \
+		&& mv $(PACKAGE).po $(srcdir)/$(PACKAGE).pot )
+
+$(srcdir)/cat-id-tbl.c: stamp-cat-id; @:
+$(srcdir)/stamp-cat-id: $(PACKAGE).pot
+	rm -f cat-id-tbl.tmp
+	sed -f ../intl/po2tbl.sed $(srcdir)/$(PACKAGE).pot \
+		| sed -e "s/@PACKAGE NAME@/$(PACKAGE)/" > cat-id-tbl.tmp
+	if cmp -s cat-id-tbl.tmp $(srcdir)/cat-id-tbl.c; then \
+	  rm cat-id-tbl.tmp; \
+	else \
+	  echo cat-id-tbl.c changed; \
+	  rm -f $(srcdir)/cat-id-tbl.c; \
+	  mv cat-id-tbl.tmp $(srcdir)/cat-id-tbl.c; \
+	fi
+	cd $(srcdir) && rm -f stamp-cat-id && echo timestamp > stamp-cat-id
+
+
+install: install-exec install-data
+install-exec:
+install-data: install-data-@USE_NLS@
+install-data-no: all
+install-data-yes: all
+	if test -r "$(MKINSTALLDIRS)"; then \
+	  $(MKINSTALLDIRS) $(DESTDIR)$(datadir); \
+	else \
+	  $(SHELL) $(top_srcdir)/mkinstalldirs $(DESTDIR)$(datadir); \
+	fi
+	@catalogs='$(CATALOGS)'; \
+	for cat in $$catalogs; do \
+	  cat=`basename $$cat`; \
+	  case "$$cat" in \
+	    *.gmo) destdir=$(DESTDIR)$(gnulocaledir);; \
+	    *)     destdir=$(DESTDIR)$(localedir);; \
+	  esac; \
+	  lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
+	  dir=$$destdir/$$lang/LC_MESSAGES; \
+	  if test -r "$(MKINSTALLDIRS)"; then \
+	    $(MKINSTALLDIRS) $$dir; \
+	  else \
+	    $(SHELL) $(top_srcdir)/mkinstalldirs $$dir; \
+	  fi; \
+	  if test -r $$cat; then \
+	    $(INSTALL_DATA) $$cat $$dir/$(PACKAGE)$(INSTOBJEXT); \
+	    echo "installing $$cat as $$dir/$(PACKAGE)$(INSTOBJEXT)"; \
+	  else \
+	    $(INSTALL_DATA) $(srcdir)/$$cat $$dir/$(PACKAGE)$(INSTOBJEXT); \
+	    echo "installing $(srcdir)/$$cat as" \
+		 "$$dir/$(PACKAGE)$(INSTOBJEXT)"; \
+	  fi; \
+	  if test -r $$cat.m; then \
+	    $(INSTALL_DATA) $$cat.m $$dir/$(PACKAGE)$(INSTOBJEXT).m; \
+	    echo "installing $$cat.m as $$dir/$(PACKAGE)$(INSTOBJEXT).m"; \
+	  else \
+	    if test -r $(srcdir)/$$cat.m ; then \
+	      $(INSTALL_DATA) $(srcdir)/$$cat.m \
+		$$dir/$(PACKAGE)$(INSTOBJEXT).m; \
+	      echo "installing $(srcdir)/$$cat as" \
+		   "$$dir/$(PACKAGE)$(INSTOBJEXT).m"; \
+	    else \
+	      true; \
+	    fi; \
+	  fi; \
+	done
+	if test "$(PACKAGE)" = "gettext"; then \
+	  if test -r "$(MKINSTALLDIRS)"; then \
+	    $(MKINSTALLDIRS) $(DESTDIR)$(gettextsrcdir); \
+	  else \
+	    $(SHELL) $(top_srcdir)/mkinstalldirs $(DESTDIR)$(gettextsrcdir); \
+	  fi; \
+	  $(INSTALL_DATA) $(srcdir)/Makefile.in.in \
+			  $(DESTDIR)$(gettextsrcdir)/Makefile.in.in; \
+	else \
+	  : ; \
+	fi
+
+# Define this as empty until I found a useful application.
+installcheck:
+
+uninstall:
+	catalogs='$(CATALOGS)'; \
+	for cat in $$catalogs; do \
+	  cat=`basename $$cat`; \
+	  lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
+	  rm -f $(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$(PACKAGE)$(INSTOBJEXT); \
+	  rm -f $(DESTDIR)$(localedir)/$$lang/LC_MESSAGES/$(PACKAGE)$(INSTOBJEXT).m; \
+	  rm -f $(DESTDIR)$(gnulocaledir)/$$lang/LC_MESSAGES/$(PACKAGE)$(INSTOBJEXT); \
+	  rm -f $(DESTDIR)$(gnulocaledir)/$$lang/LC_MESSAGES/$(PACKAGE)$(INSTOBJEXT).m; \
+	done
+	rm -f $(DESTDIR)$(gettextsrcdir)/po-Makefile.in.in
+
+check: all
+
+cat-id-tbl.o: ../intl/libgettext.h
+
+dvi info tags TAGS ID:
+
+mostlyclean:
+	rm -f core core.* *.pox $(PACKAGE).po *.old.po cat-id-tbl.tmp
+	rm -fr *.o
+
+clean: mostlyclean
+
+distclean: clean
+	rm -f Makefile Makefile.in POTFILES *.mo *.msg *.cat *.cat.m
+
+maintainer-clean: distclean
+	@echo "This command is intended for maintainers to use;"
+	@echo "it deletes files that may require special tools to rebuild."
+	rm -f $(GMOFILES)
+
+distdir = ../$(PACKAGE)-$(VERSION)/$(subdir)
+dist distdir: update-po $(DISTFILES)
+	dists="$(DISTFILES)"; \
+	for file in $$dists; do \
+	  ln $(srcdir)/$$file $(distdir) 2> /dev/null \
+	    || cp -p $(srcdir)/$$file $(distdir); \
+	done
+
+update-po: Makefile
+	$(MAKE) $(PACKAGE).pot
+	PATH=`pwd`/../src:$$PATH; \
+	cd $(srcdir); \
+	catalogs='$(CATALOGS)'; \
+	for cat in $$catalogs; do \
+	  cat=`basename $$cat`; \
+	  lang=`echo $$cat | sed 's/\$(CATOBJEXT)$$//'`; \
+	  mv $$lang.po $$lang.old.po; \
+	  echo "$$lang:"; \
+	  if $(MSGMERGE) $$lang.old.po $(PACKAGE).pot -o $$lang.po; then \
+	    rm -f $$lang.old.po; \
+	  else \
+	    echo "msgmerge for $$cat failed!"; \
+	    rm -f $$lang.po; \
+	    mv $$lang.old.po $$lang.po; \
+	  fi; \
+	done
+
+POTFILES: POTFILES.in
+	( if test 'x$(srcdir)' != 'x.'; then \
+	    posrcprefix='$(top_srcdir)/'; \
+	  else \
+	    posrcprefix="../"; \
+	  fi; \
+	  rm -f $@-t $@ \
+	    && (sed -e '/^#/d' -e '/^[ 	]*$$/d' \
+		    -e "s@.*@	$$posrcprefix& \\\\@" < $(srcdir)/$@.in \
+		| sed -e '$$s/\\$$//') > $@-t \
+	    && chmod a-w $@-t \
+	    && mv $@-t $@ )
+
+Makefile: Makefile.in.in ../config.status POTFILES
+	cd .. \
+	  && CONFIG_FILES=$(subdir)/$@.in CONFIG_HEADERS= \
+	       $(SHELL) ./config.status
+
+# Tell versions [3.59,3.63) of GNU make not to export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
diff --git a/po/POTFILES.in b/po/POTFILES.in
new file mode 100644
index 00000000..e2970f20
--- /dev/null
+++ b/po/POTFILES.in
@@ -0,0 +1,30 @@
+# files with translatable strings in fetchmail package
+checkalias.c
+cram.c
+driver.c
+env.c
+etrn.c
+fetchmail.c
+fetchmail.h
+getpass.c
+gssapi.c
+idle.c
+imap.c
+interface.c
+kerberos.c
+lock.c
+netrc.c
+odmr.c
+opie.c
+options.c
+pop3.c
+rcfile_y.c
+report.c
+rfc822.c
+rpa.c
+sink.c
+smtp.c
+socket.c
+transact.c
+uid.c
+xmalloc.c
diff --git a/po/ca.gmo b/po/ca.gmo
new file mode 100644
index 00000000..a53d3d20
--- /dev/null
+++ b/po/ca.gmo
diff --git a/po/ca.po b/po/ca.po
new file mode 100644
index 00000000..b1ea9b9d
--- /dev/null
+++ b/po/ca.po
@@ -0,0 +1,2890 @@
+# Catalan messages for fetchmail.
+# Copyright (C) 2003 Free Software Foundation, Inc.
+# Ernest Adrogué Calveras <eadrogue@gmx.net>, 2003.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 6.2.3\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2003-07-27 17:54+0200\n"
+"Last-Translator: Ernest Adrogué Calveras <eadrogue@gmx.net>\n"
+"Language-Team: Catalan <ca@dodds.net>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=iso-8859-1\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Comprovant si realment %s és el mateix node que %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Afirmatiu, les adreces IP coincideixen\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Negatiu, les adreces IP no coincideixen\n"
+
+# poll of
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr "no s'ha pogut resoldre el nom `%s' quan es consultava %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "no s'ha pogut desxifrar la codificació BASE64\n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "desxifrat com a %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "error de kerberos %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [el servidor diu: '%*s'] \n"
+
+# "avís de" o "avís per"?
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Subject: fetchmail: avís de missatges excessivament grans.\n"
+"\n"
+"Els següents missatges de mida excessiva s'han deixat al servidor %s:"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\tmissatge %d de %d octets: s'ha omès.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "ometent el missatge %s@%s:%d (%d octets)"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "ometent el missatge %s@%s:%d (%d octets)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr " (mida -1)"
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr " (massa gran)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr "falta l'encapçalament, missatge %s@%s:%d (%d octets)\n"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "llegint el missatge %s@%s:%d de %d"
+
+# %s pot ser nul, o bé "header "
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d octets%s)"
+
+# en o a?
+#: driver.c:606
+msgid "header "
+msgstr " en l'encapçalament"
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d octets en el cos) "
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"el missatge %s@%s:%d no tenia la mida esperada (%d real != %d esperada)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " retingut\n"
+
+# lliurat, expedit, despatxat, esborrat, eliminat...
+#: driver.c:776
+msgid " flushed\n"
+msgstr " eliminat\n"
+
+# ídem
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " no eliminat\n"
+
+# traducció de "fetchlimit"
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+"límit de %d obtencions assolit; resten %d missatges al compte %s del "
+"servidor %s\n"
+
+# socket o sòcol?
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "SIGPIPE rebut des d'un MDA, o error de flux de socket\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr "temps esgotat després de %d segons esperant connectar amb %s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "temps esgotat després de %d segons esperant el servidor %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "temps esgotat després de %d segons esperant per a %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr "temps esgotat després de %d segons esperant resposta del receptor.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "temps d'espera esgotat després de %d segons.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Subject: fetchmail: s'esgota el temps d'espera molt sovint\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"El fetchmail ha excedit el temps d'espera més de %d cops quan intentava "
+"obtenir el correu de %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Això pot voler dir que el servidor de correu s'ha encallat, que el\n"
+"receptor SMTP té algun problema, o bé que el servidor ha fet malbé\n"
+"per error el fitxer que conté el vostre correu. Podeu executar\n"
+"`fetchmail -v -v' per mirar d'identificar el problema.\n"
+"\n"
+"El fetchmail no tornarà a comprovar més aquesta bústia fins que el\n"
+"reinicieu.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "l'ordre de preconnexió ha fallat amb estat %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "no s'ha pogut trobar cap casella HESIOD per %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "El servidor principal no té nom.\n"
+
+#: driver.c:1016
+#, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "no s'ha pogut trobar el nom canònic DNS de %s (%s)\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "inconsistència interna\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "la connexió %s amb %s ha fallat"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "host desconegut."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "el nom és vàlid, però no té cap adreça IP."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "error no recuperable del servidor de noms."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "error passatger del servidor de noms."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "error de DNS %d no identificat."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Subject: fetchmail: servidor inaccessible.\n"
+"\n"
+"El fetchmail no pot contactar amb el servidor de correu %s:"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "La conexió SSL ha fallat.\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Bloqueig temporal de la bústia a %s@%s\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Servidor ocupat a %s@%s\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "L'autorització per %s@%s%s ha fallat\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr " (prèviament autoritzat)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: fetchmail: l'autenticació de %s@%s ha fallat\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "El fetchmail no ha pogut obtenir el correu de %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"L'intent d'obtenir autorització ha fallat.\n"
+"Com que en ocasions anteriors ja s'havia obtingut autorització amb èxit\n"
+"per aquesta connexió, probablement es tracta d'un altra mena de problema\n"
+"(tal com que el servidor està ocupat) que el fetchmail no pot identificar\n"
+"perquè el servidor no envia missatges d'error que ho permetin.\n"
+"\n"
+"No obstant, si heu canviat els paràmetres d'aquest compte des de que s'ha\n"
+"iniciat el dimoni fetchmail, haureu d'aturar el dimoni, canviar la\n"
+"configuració, i aleshores reiniciar-lo.\n"
+"\n"
+"El fetchmail continarà intentant connectar-s'hi a cada cicle, però\n"
+"no us enviarà més notificacions fins que el servei es restableixi."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"L'intent d'obtenir autorització ha fallat.\n"
+"Probablement això significa que la vostra contrasenya no és vàlida, però\n"
+"també podria ser una altre mena d'error que el fetchmail no pot distingir\n"
+"d'aquest perquè el servidor no envia els missatges d'error apropiats.\n"
+"\n"
+"El dimoni fetchmail continuarà funcionant i intentant connectar-s'hi a cada\n"
+"cicle, però no us enviarà més notificacions fins que restabliu el servei."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr "Es torna a recollir el correu immediatament de %s@%s\n"
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Error no identificat de login o autenticació a %s@%s\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Autorització reeixida a %s@%s\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: fetchmail: autenticació reeixida a %s@%s\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "El fetchmail ha estat capaç d'accedir a %s@%s.\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "El servei s'ha restablert.\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "seleccionant o re-comprovant la carpeta %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "seleccionant o re-comprovant la carpeta per omissió\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s a %s (carpeta %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s a %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Consultant %s\n"
+
+# seen
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d vistos) per %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "missatges"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "missatge"
+
+#: driver.c:1366
+msgid "seen"
+msgstr ""
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s per %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d octets).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "No hi ha correu per %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "recompte de missatges fals!"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "de socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "de capçalera RFC822"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "de MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "de sincronització client/servidor"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "de protocol client/servidor"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "de `lock busy' al servidor"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "de transacció SMTP"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "de consulta DNS"
+
+# aquest missatge va directe a stderr
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "error no definit\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "error %s mentre es lliurava via SMTP al host %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "error %s mentre es recollia de %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "l'ordre de postconnexió ha fallat amb estat %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "El suport per Kerberos V4 no està enllaçat.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "El suport per Kerberos V5 no està enllaçat.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "L'opció --flush no està suportada amb %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "L'opció --all no està suportada amb %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "L'opció --limit no està suportada amb %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: La variable d'entorn QMAILINJECT està definida.\n"
+"Això és perillós perquè pot provocar que el qmail-inject o l'embolcall\n"
+"de sendmail del qmail facin malbé les capçaleres From: i Message-ID:.\n"
+"Proveu \"env QMAILINJECT= %s ELS VOSTRES ARGUMENTS AQUÍ\"\n"
+"%s: Avorta.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: La variable d'entorn NULLMAILER_FLAGS està definida.\n"
+"Això és perillós perquè pot provocar que el nullmailer-inject o l'embolcall\n"
+"de sendmail del nullmailer facin malbé les capçaleres From:, Message-ID:, o\n"
+"Return-Path:.\n"
+"Proveu \"env NULLMAILER_FLAGS= %s ELS VOSTRES ARGUMENTS AQUÍ\"\n"
+"%s: Avorta.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: No existeixes. Escampa la boira.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: no s'ha pogut determinar el vostre host!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "ha fallat la funció gethostbyname per %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "el receptor SMTP de %s no suporta ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "el receptor SMTP de %s no suporta ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "S'ha iniciat la cua per %s\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "No hi han missatges pendents per %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "S'ha iniciat la cua de missatges pendents per %s\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Els missatges pel node %s no s'han pogut posar a la cua\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "El node %s no està permès: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "error de sintaxi d'ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "error de sintaxi d'ETRN en els paràmetres\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Error d'ETRN no identificat %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "L'opció --keep no està suportada amb ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "L'opció --flush no està suportada amb ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "L'opció --remote no està suportada amb ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "L'opció --check no està suportada amb ETRN\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: invocat amb"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "no s'ha pogut determinar quin és el directori actual\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Aquesta és la versió del fetchmail %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Obtenint les opcions de la línia d'ordres%s%s\n"
+
+# després d'això vé el nom d'un fitxer
+#: fetchmail.c:332
+msgid " and "
+msgstr " i de "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "No hi ha cap servidor de correu configurat. Potser falta el %s?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: no heu especificat cap servidor de correu.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: no hi ha cap altre fetchmail funcionant\n"
+
+# bailing out
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: error finalitzant el fetchmail %s a %d; es deixa estar.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "en segon terme"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "en primer terme"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: el fetchmail %s a %d ha finalitzat.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: no es pot comprovar el correu mentre funcioni un altre procés del "
+"fetchmail.\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: no es poden consultar els hosts especificats amb un altre "
+"fetchmail funcionant a %d.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: hi ha un altre fetchmail funcionant en primer terme a %d.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: no es poden acceptar opcions mentre funcioni un altre fetchmail "
+"en segon terme.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr ""
+"fetchmail: el fetchmail funcionant en segon terme a %d s'ha despertat.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: un procés anterior ha finalitzat misteriosament a %d.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: no s'ha trobat cap contrasenya per %s@%s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Entreu la contrasenya per %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "iniciant el dimoni fetchmail %s \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "no s'ha pogut obrir %s per afegir-hi els registres \n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "no s'ha pogut verificar l'hora de %s (error %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "reiniciant fetchmail (%s ha canviat)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+"l'intent de reexecució pot fallar ja que el directori no ha estat restaurat\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "l'intent de reexecutar el fetchmail ha fallat\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"s'ha omès la consulta de %s (error d'autenticació o massa temps excedits)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "no s'ha completat l'interval, no es consultarà %s\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Estat de la consulta=0 (SUCCESS)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Estat de la consulta=1 (NOMAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Estat de la consulta=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Estat de la consulta=3 (AUTHFAIL)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Estat de la consulta=4 (PROTOCOL)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Estat de la consulta=5 (SYNTAX)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "Estat de la consulta=6 (IOERR)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "Estat de la consulta=7 (ERROR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Estat de la consulta=8 (EXCLUDE)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Estat de la consulta=9 (LOCKBUSY)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "Estat de la consulta=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "Estat de la consulta=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Estat de la consulta=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Estat de la consulta=13 (MAXFETCH)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Estat de la consulta=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Totes les connexions estan bloquejades. Sortint.\n"
+
+# %s és la sortida de timestamp()
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "dormint el %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "despertat per %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "despertat pel senyal %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "despertat el %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "finalització normal, estat %d\n"
+
+# nota: run-control és fitxer de control (i.e. .fetchmailrc)
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "no s'ha pogut verificar l'hora del fitxer de control\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr ""
+"Atenció: hi ha múltiples mencions del host %s en el fitxer de configuració\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "El suport per SSL no està compilat.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: atenció: cap DNS disponible per verificar les obtencions "
+"`multidrop' de %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr ""
+"la configuració de %s no és vàlida, el nombre d'un port no pot ser negatiu\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr ""
+"la configuració de %s no és vàlida, RPOP requereix un port privilegiat\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"la configuració de %s no és vàlida, LMTP no pot usar el port habitual "
+"d'SMTP\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "En mode dimoni les opcions `fetchall' i `keep on' són incompatibles!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "finalitzat amb senyal %d\n"
+
+# conflicte query-poll
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s interrogant %s (protocol %s) el %s: s'inicia la consulta\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "el suport per POP2 no està configurat.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "el suport per POP3 no està configurat.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "el suport per IMAP no està configurat.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "el suport per ETRN no està configurat.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "El suport per ETRN necessita la funció gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "El suport per ODMR no està configurat.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "El suport per ODMR necessita la funció gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "heu seleccionat un protocol que no està suportat.\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s interrogant %s (protocol %s) el %s: la consulta ha finalitzat\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "L'interval entre consultes és de %d segons\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "El fitxer de registre és %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "El fitxer d'identificacions és %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "L'activitat es registrarà via syslog\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "El fetchmail enmascararà i no generarà capçaleres `Recieved'\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr ""
+"El fetchmail mostrarà punts de progressió àdhuc als fitxers de registre.\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr "El fetchmail enviarà els missatges `multidrop' mal adreçats a %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "El fetchmail dirigirà els missatges d'error al postmaster.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "El fetchmail dirigirà els missatges d'error al remitent.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Opcions per l'obtenció de %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  El correu d'obtindrà via %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  Aquest servidor es consultarà cada %d intervals.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  El nom autèntic del servidor és %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr ""
+"  Aquest host%ses consultarà quan no se'n hagi especificat cap altre.\n"
+
+# comprovar on s'apliquen aquestes substitucions
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr " no "
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr " "
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Es demanarà la contrasenya.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  Secret APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  Identificació RPOP = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Contrasenya = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  El protocol és KPOP amb autenticació per Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  El protocol és %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (usant el servei %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (usant les opcions de seguretat de xarxa %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (usant el port %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (usant el port per defecte)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (obligant l'ús d'UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  S'intentaran tots els mètodes d'autenticació disponibles.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  S'obligarà l'autenticació per contrasenya.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  S'obligarà l'autenticació per NTLM.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  S'obligarà l'autenticació per OTP.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  S'obligarà l'autenticació per CRAM-Md5.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  S'obligarà l'autenticació per GSSAPI.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  S'obligarà l'autenticació per Kerberos V4.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  S'obligarà l'autenticació per Kerberos V5.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  S'assumeix que el xifrat és d'extrem a extrem.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  El servei principal de correu és: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  Sessions encriptades amb SSL habilitades.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  Protocol SSL: %s.\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  Comprovació del certificat SSL del servidor habilitada.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  Directori de certificats SSL de confiança: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr ""
+"  Empremta de la clau SSL (comprovada contra la clau del servidor): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  El temps d'espera de la resposta del servidor és de %d segons"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (per defecte).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Seleccionada la bústia per defecte.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Les bústies seleccionades són:"
+
+# al tanto amb la substitució
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  S'obtindran els missatges %s (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "tant nous com vells"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "nous"
+
+# la substitució és: "<espai>/ no "
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Els missatges obtinguts%ses conservaran al servidor (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+"  Els missatges vells%ss'eliminaran abans d'obtenir el correu (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  La reescriptura d'adreces locals està %sda (--norewrite %s).\n"
+
+# nota: s'ha d'escriure la terminació masculina o femenina segons
+# convingui, per exemple: %st o bé %sda.
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "habilita"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "deshabilita"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  L'eliminació de retorns de carro està %sda (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  L'inserció de retorns de carro està %sa (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+"  L'interpretació del Content-Transfer-Encoding està %sda (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  El desxifrat MIME està %st (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  La pausa després de cada obtenció està %sda (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Les línies Status que no estiguin en blanc es %s (dropstatus %s)\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "descartaran"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "mantindran"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Les línies Delivered-To es %s (dropdelivered %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  El límit de mida dels missatges és de %d octets (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  No hi ha límit de mida dels missatges (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  L'interval d'avisos de grandària dels missatges és de %d segons (--"
+"warnings %d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+"  Avisos de la grandària dels missatges a cada obtenció (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  El límit de missatges obtinguts és de %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  No hi ha límit de missatges rebuts (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  El límit de missatges obtinguts és de %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  No hi ha límit de mida dels missatges (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  El límit de missatges enviats en sèrie és de %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  No hi ha límit de missatges enviats en sèrie (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+"  L'interval entre supressions és de %d missatge(s) eliminat(s) (--expunge %"
+"d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  No es suprimiran els missatges fins al final (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Els dominis pels quals es recollirà el correu són:"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (per omissió)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Els missatges s'afegiran a %s com a BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Els missatges es lliuraran amb \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Els missatges es reenviaran per %cMTP a:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  El nom del host a la línia MAIL FROM serà %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr "  L'adreça de les línies RCPT TO enviades per SMTP serà %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Les respostes del servidor reconegudes com a bloqueig d'spam són:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  El bloqueig d'spam està deshabilitat\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  La connexió amb el servidor s'iniciarà amb \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  No hi ha cap ordre de preconnexió.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  La connexió amb el servidor es finalitzarà amb \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  No hi ha cap ordre de postconnexió.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  No s'ha declarat cap nom local per aquest host.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Mode multi-drop: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Mode single-drop: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "S'ha(n) reconegut %d nom(s) local(s).\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  La consulta DNS d'adreces `multidrop' està %sda.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr "  Els àlies del servidor es compararan amb les adreces `multidrop' "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "per l'adreça IP.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "pel nom.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  L'encaminament per l'adreça de l'embolcall està deshabilitat.\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  S'assumeix que la capçalera de l'embolcall és: %s\n"
+
+# nom de la capçalera
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Recieved"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  El nombre de capçaleres de l'embolcall que s'analitzaran és: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Es suprimirà el prefix %s del nom d'usuari\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  No es suprimirà cap prefix\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Àlies predeclarats del servidor de correu:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Dominis locals:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  La connexió s'establirà a través de l'interfície %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  No s'ha especificat cap interfície requerida.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Es monitorarà l'interfície %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  No s'ha especificat cap interfície a monitorar.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr "  Les connexions amb el servidor es faran via %s (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  No s'ha especificat cap ordre de connexió.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  Les connexions amb el receptor SMTP es faran via %s (--plugout %s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  No s'ha especificat cap ordre de connexió per SMTP.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  No s'ha desat cap UID d'aquest host.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  S'han desat %d UIDs.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr "  S'afegirà el rastre de l'obtenció a la capçalera Received.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  No s'afegirà el rastre de l'obtenció a la capçalera Received.\n"
+".\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Propietats de pas \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "ha fallat la rutina alloca"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "ERROR: la funció getpassword() no està suportada\n"
+
+# bailing out
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"S'ha rebut un SIGINT... es deixa estar.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "No s'ha pogut obtenir el nom de servei de [%s]\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "S'usa el nom de servei [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Enviant les credencials\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Error en l'intercanvi de credencials\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "No s'ha pogut desajustar el nivell de seguretat de dades\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "S'ha completat l'intercanvi de credencials\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "El servidor requereix integritat i/o privacitat\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Indicadors del nivell de seguretat desajustat: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "La mida màxima del component GSS és %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Error quan es creava la petició del nivell de seguretat\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Enviant les credencials GSS\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Error quan s'enviaven les credencials GSS\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: procés dormint durant %d segons.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "S'ha identificat el protocol com a IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "S'ha identificat el protocol com a IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "S'ha identificat el protocol com a IMAP2 o IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "es farà una pausa després de l'obtenció\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "Es requereix capacitat per OTP no compilada en el fetchmail\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Es requereix capacitat per NTLM no compilada en el fetchmail\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "El servidor no suporta la capacitat per LOGIN requerida\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "la supressió de missatges ha fallat\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "la re-obtenció ha fallat\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "hi ha %d missatge(s) esperant després de la re-obtenció\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "ha fallat la selecció de bústia\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "hi ha %d missatge(s) esperant després de la primera obtenció\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "hi ha %d missatge(s) esperant després de la supressió\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "la recerca de missatges nous ha fallat\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u és nou\n"
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr "%u és el primer missatge nou\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"No s'ha pogut obrir l'interfície kvm. Asseguereu-vos que el fetchmail és "
+"SGID kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "No s'ha pogut analitzar el nom de la interfície de %s"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: sysctl (iflist estimate) ha fallat"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: malloc ha fallat"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: sysctl (iflist) ha fallat"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "El missatge d'encaminament versió %d és incomprensible."
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "No s'ha trobat cap interfície amb el nom de %s"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "No s'ha trobat cap adreça IP per %s"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "falta l'adreça IP de l'interfície\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "l'adreça IP de l'interfície no és vàlida\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "la màscara IP de l'interfície no és vàlida\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "activitat a %s -vista- com %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr ""
+"ometent l'obtenció de %s, %s apagada\n"
+"\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "ometent l'obtenció de %s, l'adreça IP de %s està exclosa\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "activitat a %s comprovada com %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "ometent l'obtenció de %s, %s inactiva\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "activitat a %s era %d, és %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "no s'ha pogut desxifrar la codificació BASE64 inicial\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "el principal %s del bitllet no encaixa amb -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "l'instància no nul·la (%s) pot provocar un comportament estrany\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "no s'ha pogut desxifrar la resposta de disponibilitat en BASE64\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "la codificació no encaixa\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: esborrant el fitxer de bloqueig antic\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: ha fallat la creació del bloqueig.\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "atenció: s'ha trobat \"%s\" abans que cap nom de host"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: atenció: s'ha trobat \"%s\" abans que cap nom de host\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: atenció: component \"%s\" no identificat\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "El receptor SMTP de %s no suporta ATRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "S'inicia el període de descarrega ara...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "La petició ATRN ha estat refusada.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "No es pot processar la petició ATRN en aquests moments\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "No teniu correu.\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Ordre no implementada\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Autenticació requerida.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Error d'ODMR no identificat %d\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "L'opció --keep no està suportada amb ODMR\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "L'opció --flush no està suportada amb ODMR\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "L'opció --remote no està suportada amb ODMR\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "L'opció --check no està suportada amb ODMR\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "recv fatal del servidor\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "No s'ha pogut desxifrar la codificació OTP\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Contrasenya secreta: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "La cadena '%s' no és un nombre vàlid.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "El valor de la cadena '%s' és %s que %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "més petit"
+
+#: options.c:211
+msgid "larger"
+msgstr "més gran"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "El protocol `%s' especificat no és vàlid.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "L'autenticació `%s' especificada no és vàlida.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: el suport per seguretat de xarxa està deshabilitat\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "sintaxi: fetchmail [opcions] [servidor ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Les opcions són les següents:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        mostra aquesta ajuda\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     mostra informació sobre la versió\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       comprova si hi ha correu sense recollir-lo\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      funciona en silenci\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     genera missatges informatius i de diagnòstic\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      funciona com a dimoni, en intervals de n segons\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    funciona com a dimoni, però en primer terme\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        finalitza el procés d'un dimoni\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     especifica el fitxer on registrar l'activitat\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      en mode dimoni, registra l'activitat via syslog(3)\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr "      --invisible   no deixa traces a les capçaleres dels missatges\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc usa un fitxer de control d'execució alternatiu\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      usa un fixter d'UIDs alternatiu\n"
+
+# last resort
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  especifica el destinatari en última instància\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr ""
+"      --nobounce    redirigeix els missatges retornats cap al postmaster\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   interfície de xarxa requerida pel funcionament\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr ""
+"  -M, --monitor     monitora l'activitat de l'interfície especificada\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         encripta les comunicacions amb ssl\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      fitxer que conté la clau ssl privada\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     certificat ssl del client\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      --sslproto    obliga l'ús del protocol ssl (ssl2/ssl3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+"      --plugin      especifica l'ordre externa per obrir una connexió\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plogout     especifica l'ordre externa per obrir una connexió smtp\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    especifica el protocol que s'usa per obtenir el correu\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        obliga l'ús d'UIDLs (només pop3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        port TCP/IP al qual connectar-se\n"
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr "      --auth        tipus d'autenticació (password/kerberos/ssh/otp)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     temps d'espera per la resposta del servidor\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    capçalera que conté l'adreça de l'embolcall\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr "  -Q, --qvirtual    prefix que es suprimeix del nom d'usuari local\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   servei de correu principal\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+"      --tracepolls  afegeix el rastre de l'obtenció a la capçalera Received\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    especifica el nom de login al servidor\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         recull els missatges tant nous com vells\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr ""
+"  -K, --nokeep      esborra els missatges nous després de recollir-los\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        deixa els missatges al servidor un cop recollits\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       esborra els missatges vells del servidor\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   no reescriu les adreces de l'encapçalament\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr ""
+"  -l, --limit       no recull els missatges que superin la mida "
+"especificada\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    interval entre avisos de notificació de correu\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      efectua una petició de seguretat IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    estableix el host pel reenviament via SMTP\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr "      --fetchdomains recull el correu pels dominis especificats\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr "  -D, --smtpaddress estableix el domini usat pel lliurament via SMTP\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr "      --smtpname    estableix el nom complet SMTP nomusuari@domini\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr ""
+"  -Z, --antispam,   estableix els valors reconeguts com a resposta antispam\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+"  -b, --batchlimit  estableix el límit de missatges SMTP enviats en sèrie\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  estableix el límit de missatges obtinguts per connexió\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr "      --fetchdomains recull el correu pels dominis especificats\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+"  -e, --expunge     estableix el màxim de missatges eliminats entre "
+"supressions\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         estableix l'MDA que s'utilitza pel reenviament\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       estableix el fitxer de sortida BSMTP\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        usa LMTP (RFC2033) pel lliurament\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      estableix el nom de la carpeta remota\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+"      --showdots    mostra punts de progressió àdhuc als fitxers de "
+"registre\n"
+
+# timestamp: marca horària
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "No s'ha trobat la marca horària APOP requerida a la salutació\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Error de sintaxi en la marca horària de la salutació\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Petició de protocol indefinida a POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "bloqueig temporal! Hi ha alguna altra sessió activa?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr ""
+"Els missatges estan inserits a la llista del servidor. No es pot continuar.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "error de protocol\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "error de protocol quan es rebien els UIDLs\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "L'opció --remote no està suportada amb POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "opcions del servidor després de les opcions de l'usuari"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "SDPS no habilitat."
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "petició de seguretat no vàlida"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "suport per seguretat de xarxa deshabilitat"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: l'opció d'interfície només està suportada en Linux (sense IPv6) i "
+"FreeBSD\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: l'opció de monitoració només està suportada en Linux (sense IPv6) "
+"i FreeBSD\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "SSL no habilitat"
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "final de l'entrada"
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "El fitxer %s ha de ser un fitxer ordinari.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "El fitxer %s no pot tenir permisos més que -rwx--x--- (0710).\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "El fitxer %s ha de ser propietat vostra.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Error no identificat del sistema"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (missatge de registre incomplet)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "error parcial pel desbordament del buffer del missatge"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "Es reescriurà la capçalera %s"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "La versió reescrita és %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Reeixit"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Usuari restringit (hi ha algun problema amb el compte)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "El nom d'usuari o la contrasenya no són vàlids"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "Error fatal"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "Component RPA 2: Error del desxifrat Base64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "El servei ha elegit la versió RPA %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Clau del servei (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Marca horària del servei %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "La mida del component RPA 2 és incorrecta\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Llista de reialmes: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "Error d'RPA a la cadena servei@reialme\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "Component RPA 4: Error de desxifrat Base64\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Autenticació de l'usuari (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "Estat RPA: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "La mida del component RPA 4 és incorrecta\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA us rebutja: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA us rebutja, motiu desconegut\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "La mida del component RPA User Authentication és incorrecta: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "La mida del component RPA Session key és incorrecta: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "Fallada en l'autenticació del _servei_ RPA. Nom del servidor fals?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Clau de sessió establerta:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "Autorització RPA completada\n"
+
+# és un nom?
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Petició de resposta\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "La petició de resposta ha retornat %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "Capçalera diferent de 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "La mida del component és incorrecta\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "La mida del component %d no lliga amb rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Mecanisme de camp incorrecte\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "error de dec64 al caràcter %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Dades binàries entrants:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Dades sortints:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "Cadena RPA massa llarga\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA no ha pogut obrir /dev/urandom. Això no impedeix\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    que entreu al sistema, però vol dir que no\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    podeu estar segurs d'estar parlant amb el\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    servei que creieu (són possibles atacs\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    per repetició per part d'un servei deshonest).\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Clau de l'usuari:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "MD5 que s'aplica al bloc de dades:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "L'MD5 resultant és: \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "reenviant a %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (cos del missatge retornat)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "correu de %s retornat a %s\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "L'error desat encara és %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "Error %cMTP: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "Ha fallat l'obertura del fitxer BSMTP o l'escriptura del preàmbul\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "El receptor %cMTP no admet l'adreça del destinatari `%s'\n"
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "El receptor %cMTP no admet l'adreça de destinació `%s'\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "cap adreça coincideix; el postmaster no està definit.\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "ni tan sols es pot enviar a %s!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "cap adreça coincideix; reenviant a %s.\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "a punt de lliurar amb: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "l'obertura de l'MDA ha fallat\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "La connexió %cMTP amb %s ha fallat\n"
+
+# raise
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "no s'ha pogut lliurar via SMTP; recorrent a %s"
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr "MDA finalitzat pel senyal %d\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "L'MDA ha retornat un estat no nul: %d\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr ""
+"Estrany: La funció pclose de l'MDA a retornat %d, no es pot continuar a %s:%"
+"d\n"
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Ha fallat la terminació del missatge o el tancament del fitxer BSMTP\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "El receptor SMTP refusa el lliurament\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "Error de lliurament LMTP a EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Resposta no-503 inesperada al final del missatge LMTP: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tEl Dimoni Fetchmail\n"
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "Autenticació CRAM-MD5 per ESMTP...\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "El servidor ha rebutjat l'ordre AUTH.\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "La resposta en base64 del servidor és incorrecta.\n"
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "Codificació desxifrada com a %s\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "Autenticació per ESMTP sense xifrat...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "Autenticació de LOGIN per ESMTP...\n"
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr "error de protocol del receptor smtp\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: la rutina malloc ha fallat\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: la rutina socketpair ha fallat\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: la rutina fork ha fallat\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "la rutina dup2 ha fallat\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "executant %s (host %s servei %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "la rutina execvp(%s) ha fallat\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: s'ha rebut una adreça de llargada incorrecta pel host %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Organització emissora: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+"Atenció: El nom de l'organització emissora és massa llarg (pot estar "
+"truncat).\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "Organització desconeguda\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "Nom comú de l'emissor: %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+"Atenció: El nom comú de l'emissor és massa llarg (pot estar truncat).\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "Nom comú de l'emissor desconegut\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Nom comú del servidor: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "Certificat incorrecte: El component CommonName és massa llarg!\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "El nom comú del servidor no encaixa: %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+"El nom del servidor no està definit, no es pot verificar el certificat!\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "Nom comú del servidor desconegut\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "El certificat no especifica el nom del servidor!\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "EVP_md5() ha fallat!\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "Memòria exhaurida!\n"
+
+# digest text
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "El buffer del sumari de text és massa petit!\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "Empremta de la clau de %s: %s\n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "Les empremtes digitals de %s encaixen.\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "Les empremtes digitals de %s no encaixen!\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "Atenció: verificació del certificat del servidor: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "emissor desconegut (primers %d caràcters): %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Descriptor del fitxer fora d'abast per SSL"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr "El protocol SSL especificat `%s' no és vàlid, s'usa SSLv23.\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr "La verificació del certificat o de l'empremta s'ha omès!\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr "Es torna a intentar llegir el socket Cygwin\n"
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr "El reintent de llegir el socket Cygwin ha fallat!\n"
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s s'ha assignat al nom local %s\n"
+
+# què significa?
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "el %s processat encaixa amb %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analitzant la línea Received:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "línia acceptada, %s és un àlies del servidor de correu\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "línia rebutjada, %s no és un àlies del servidor de correu\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "no s'ha trobat cap adreça a la capçalera Received\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "s'ha trobat l'adreça `%s' a la capçalera Received\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr ""
+"s'ha trobat un delimitador de missatge quan s'analitzava l'encapçalament\n"
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "s'ha trobat una línia incorrecta quan s'analitzava l'encapçalament\n"
+
+#: transact.c:554
+#, fuzzy, c-format
+msgid "line: %s"
+msgstr "Consultant %s\n"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "cap conincidència local, reenviant a %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "reenviament i eliminació omesos a causa d'errors de DNS\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "escrivint l'encapçalament RFC822 msgblk\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "cap adreça de destinatari coincideix amb els noms locals declarats"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "l'adreça del destinatari %s no lliga amb cap nom local"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "el missatge conté caràcters NUL"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "el receptor SMTP ha rebutjat les adreces locals de destinació: "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "escrivint el text del missatge\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "Antiga llista d'UIDs de %s:"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <buit>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Esborrany de llista d'UIDs:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, fuzzy, c-format
+msgid "Merged UID list from %s:"
+msgstr "Antiga llista d'UIDs de %s:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "Nova llista d'UIDs de %s:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "intercanviant llistes d'UIDs\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr ""
+"no s'intercanvien llistes d'UIDs, no s'han trobat UIDs en aquesta consulta\n"
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "intercanviant llistes d'UIDs\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "Esborrant el fitxer d'identificadors.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "Escrivint el fitxer d'identificadors.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "la rutina malloc ha fallat\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "la rutina realloc ha fallat\n"
diff --git a/po/cat-id-tbl.c b/po/cat-id-tbl.c
new file mode 100644
index 00000000..e69de29b
--- /dev/null
+++ b/po/cat-id-tbl.c
diff --git a/po/cs.gmo b/po/cs.gmo
new file mode 100644
index 00000000..999be274
--- /dev/null
+++ b/po/cs.gmo
diff --git a/po/cs.po b/po/cs.po
new file mode 100644
index 00000000..f1a3f08e
--- /dev/null
+++ b/po/cs.po
@@ -0,0 +1,2862 @@
+# Czech messages for fetchmail.
+# Jiøí Pavlovský <pavlovsk@ff.cuni.cz>, 1999 - 2001.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail-5.8.1\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2001-04-20 23:03+0200\n"
+"Last-Translator: Jiøí Pavlovský <pavlovsk@ff.cuni.cz>\n"
+"Language-Team: Czech <cs@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=ISO-8859-2\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Ovìøuji zda uzly %s a %s jsou toto¾né\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Ano, jejich IP-adresy se shodují\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Ne, jejich IP-adresy se li¹í\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr "chyba DNS serveru pøi vyhledávání `%s' v prùbìhu stahování z %s\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr ""
+
+#: cram.c:103
+#, fuzzy, c-format
+msgid "decoded as %s\n"
+msgstr "probuzen v %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "chyba kerberu %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [server øíká '%*s'] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Subject: fetchmail: varování kvùli pøíli¹ veliké zprávì\n"
+"\n"
+"Následující zprávy zùstanou kvùli pøíli¹né velikosti na serveru %s:"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\t%d. zpráva o délce %d v bajtech byla fetchmailem pøeskoèena.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "zprávu %d (poèet oktetù: %d) vynechávám"
+
+#: driver.c:549
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "zprávu %d (poèet oktetù: %d) vynechávám"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr ""
+
+#: driver.c:568
+#, fuzzy
+msgid " (oversized)"
+msgstr " (nadmìrná velikost, poèet bajtù: %d)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr ""
+
+#: driver.c:600
+#, fuzzy, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "ètu %d. zprávu z %d"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (poèet bajtù: %d %s)"
+
+#: driver.c:606
+msgid "header "
+msgstr "v hlavièce "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (poèet bajtù v tìle: %d)"
+
+#: driver.c:736
+#, fuzzy, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr "zpráva %d má neoèekávanou velikost (velikost je %d, oèekáváno %d)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr "zachována(y)\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr "smazána(y)\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " nesmazána(y)\n"
+
+#: driver.c:809
+#, fuzzy, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+"hranice pro sta¾ení (%d) dosa¾ena; poèet zpráv ponechaných na serveru: %d\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "buï nastala chyba soketu, nebo MDA poslal SIGPIPE\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr "Bìhem %d vteøin se nepodaøilo navázat spojení se serverem %s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "Bìhem %d vteøin nepøi¹la od serveru %s odpovìï.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "Bìhem %d vteøin server %s neodpovìdìl.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr "Bìhem %d vteøin nepøi¹la od démona odpovìï.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "Vypr¹el èas (poèet vteøin: %d).\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Vìc: opakovanì vypr¹el èas\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr "Více ne¾ %d. vypr¹el èas pøi pokusu stáhnout po¹tu z %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"To mù¾e znamenat, ¾e vá¹ po¹tovní server je mimo provoz, nebo SMTP démon\n"
+"je nedostupný, nebo schránka na serveru byla po¹kozena\n"
+"chybou serveru. Problém mù¾ete identifikovat pøíkazem `fetchmail -v -v'.\n"
+"\n"
+"Fetchmail ji¾ nebude vybírat z této schránky, dokud jej znovu nespustíte.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "pøíkaz pøed spojením selhal (status %d)\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "HESIOD schránku pro %s nelze nalézt\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Vedoucí server nemá ¾ádné jméno.\n"
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "kanonické DNS jméno pro %s nelze nalézt\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "vnitøní inkonzistence\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "%s spojení s %s se nezdaøilo"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "stroj není znám"
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "jméno je platné, ale nemá IP-adresu"
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "neodstranitelná chyba serveru doménových jmen"
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "doèasná chyba serveru doménových jmen"
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "neznámá chyba DNS %d"
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Subject: fetchmail: varování kvùli nedostupnosti serveru\n"
+"\n"
+"Nepodaøilo se navázat spojení se serverem %s:"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "SSL spojení se nezdaøilo.\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Chyba zámku na %s@%s\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Pøi stahování z %s@%s nastala chyba: server je zaneprázdnìn\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Chyba autorizace pro %s@%s%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr ""
+
+#: driver.c:1217
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Vìc: autentizace fetchmailu se nezdaøila\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail nemohl stáhnout po¹tu z %s@%s.\n"
+
+#: driver.c:1224
+#, fuzzy
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Autorizace se nezdaøila.\n"
+"Jeliko¾ toto spojení ji¾ bylo jednou úspì¹nì autorizováno, tak se zøejmì\n"
+"jedná o jinou chybu (napø. mù¾e být zaneprázdnìn server), kterou fetchmail\n"
+"nemù¾e identifikovat, proto¾e server nezaslal jednoznaèné chybové hlá¹ení.\n"
+"Pokud jste v¹ak po spu¹tìní fetchmail démona zmìnil nastavení va¹eho úètu,\n"
+"pak musíte zmìnit konfigurace fetchmailu a poté jej restartovat.\n"
+"Fetchmail démon bude pokraèovat v èinnosti a v ka¾dém cyklu se pokusí "
+"navázat\n"
+"spojení se serverem. ®ádná dal¹í upozornìní nebudou do obnovení slu¾by\n"
+"zasílána."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Autorizace se nezdaøila.\n"
+"To pravdìpodobnì znamená, ¾e va¹e heslo je nesprávné, ale mù¾e se jednat\n"
+"i o jinou chybu, nebo» nìkteré servery nezasílají jednoznaèná chybová "
+"hlá¹ení.\n"
+"Fetchmail démon bude pokraèovat v èinnosti a v ka¾dém cyklu se pokusí "
+"navázat\n"
+"spojení se serverem. ®ádná dal¹í upozornìní nebudou do obnovení slu¾by\n"
+"zasílána."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr ""
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Neznámá chyba pøi pøihlá¹ení èi autorizaci na %s@%s\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Úspì¹ná autorizace pro %s@%s\n"
+
+#: driver.c:1289
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Vìc: úspì¹ná autentizace fetchmailu\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail se úspì¹nì pøihlásil k %s@%s.\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "Slu¾ba byla obnovena.\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "otevírám schránku %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "otevírám implicitní schránku\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s na %s (schránka %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s na %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Stahuji z %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "poèet %2$s pro u¾ivatele %4$s: %1$d (%3$d pøeètených)"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "zpráv"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "zpráv"
+
+#: driver.c:1366
+msgid "seen"
+msgstr ""
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "poèet %2$s pro u¾ivatele %3$s: %1$d"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (poèet bajtù: %d).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "®ádná po¹ta pro u¾ivatele %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr ""
+
+#: driver.c:1515
+msgid "socket"
+msgstr "soketu"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "RFC822 hlavièky"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "synchronizace mezi serverem a klientem"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "klient/server protokolu"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "zámku na serveru"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "SMTP transakce"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "hledání jména stroje"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "nedefinovaná\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "pøi odesílání SMTP protokolem na %2$s nastala chyba %1$s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "pøi stahování z %2$s nastala chyba %1$s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "pøíkaz po spojení selhal (status %d)\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Kerberos v4 není podporován.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Kerberos v5 není podporován.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Pøepínaè --flush nepodporuje argument %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Pøepínaè --all nepodporuje argument %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Pøepínaè --limit nepodporuje argument %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Takový úèet zde neexistuje. Okam¾itì se odpojte.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: jméno va¹eho stroje nelze zjistit!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "volání gethostbyname pro %s selhalo\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "SMTP démon na %s nepodporuje ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "SMTP démon na %s nepodporuje ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Vytváøím frontu pro %s\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Pro %s nejsou ¾ádné zprávy\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Posílám zprávy pro %s\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Frontu zpráv pro %s nelze vytvoøit\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Uzel %s nemá povolen pøístup: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "syntaktická chyba ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "syntaktická chyba v parametrech ETRN\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Neznámá chyba ETRN %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "Pøepínaè --keep není s protokolem ETRN podporován.\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "Pøepínaè --flush není s protokolem ETRN podporován.\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "Pøepínaè --remote není s protokolem ETRN podporován.\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "Pøepínaè --check není s protokolem ETRN podporován.\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "zadané pøepínaèe:"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr ""
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Fetchmail verze %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Zpracovávám volby z pøíkazového øádku%s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " a "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "Není specifikován ¾ádný po¹tovní server - mo¾ná chybí %s?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: nebyl specifikován ¾ádný po¹tovní server.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: jiný fetchmail není spu¹tìn\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: nepodaøilo se zabít fetchmail %s (PID %d); konèím.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "na pozadí"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "v popøedí"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: fetchmail %s (PID %d) byl zabit.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: po¹tu nelze stahovat, kdy¾ ji jiný fetchmail stahuje z tého¾ "
+"serveru.\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: po¹tu nelze stahovat ze zadaných serverù, kdy¾ bì¾í jiný "
+"fetchmail\n"
+"(PID %d).\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: v popøedí bì¾í jiný fetchmail (PID %d).\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail:  neakceptuji pøepínaèe, jestli¾e jiný fetchmail bì¾í na pozadí.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: fetchmail bì¾ící na pozadí (PID %d) byl probuzen.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: star¹í proces (PID %d) z neznámých dùvodù skonèil.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: heslo pro %s@%s nelze nalézt.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Zadejte heslo pro %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "spou¹tím fetchmail démon %s \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr ""
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "èas poslední zmìny %s nelze zjistit (chyba %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "znovu spou¹tím fetchmail (konfiguraèní soubor %s byl zmìnìn)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "pokus o opìtovné spu¹tìní fetchmailu selhal\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"nebudu stahovat z %s (chyba autentizace nebo se nepodaøilo navázat spojení)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "je¹tì nenastala doba pro spojení s %s\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Status spojení=0 (SUCCESS)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Status spojení=1 (NOMAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Status spojení=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Status spojení=3 (AUTHFAIL)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Status spojení=4 (PROTOCOL)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Status spojení=5 (SYNTAX)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "Status spojení=6 (IOERR)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "Status spojení=7 (ERROR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Status spojení=8 (EXCLUDE)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Status spojení=9 (LOCKBUSY)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "Status spojení=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "Status spojení=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Status spojení=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Status spojení=13 (MAXFETCH)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Status spojení=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "®ádné ze spojení není aktivní. Konèím.\n"
+
+#: fetchmail.c:748
+#, fuzzy, c-format
+msgid "sleeping at %s\n"
+msgstr "fetchmail: spím v %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "probuzen %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "probuzen signálem %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "probuzen v %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "normální ukonèení, status %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "èas poslední zmìny konfiguraèního souboru nelze zjistit\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr "Varování: stroj %s je v konfiguraèním souboru zmínìn vícekrát\n"
+
+#: fetchmail.c:1116
+#, fuzzy
+msgid "SSL support is not compiled in.\n"
+msgstr "POP2 protokol není nastaven.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: varování: není dostupný DNS server pro kontrolu výbìru "
+"spoleèných\n"
+"schránek na %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "Konfigurace pro %s je chybná, èíslo portu nesmí být záporné.\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "Konfigurace pro %s je chybná, RPOP vy¾aduje privilegovaný port\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"Konfigurace pro %s je chybná, LMTP nesmí pou¾ívat implicitní port SMTP.\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr ""
+"Pokud fetchmail bì¾í jako démon, nelze pou¾ít voleb fetchall a keep "
+"souèasnì!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "ukonèen signálem %d\n"
+
+#: fetchmail.c:1339
+#, fuzzy, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "v %4$s %1$s stahuje protokolem %3$s z %2$s\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "POP2 protokol není nastaven.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "POP3 protokol není nastaven.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "IMAP protokol není nastaven.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "ETRN protokol není nastaven.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "ETRN není bez funkce gethostbyname(2) podporováno.\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "ODMR protokol není nastaven.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "ODMR není bez funkce gethostbyname(2) podporováno.\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "Byl zvolen nepodporovaný protokol.\n"
+
+#: fetchmail.c:1427
+#, fuzzy, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "v %4$s %1$s stahuje protokolem %3$s z %2$s\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "Stahování probìhne ka¾dou %d. vteøinu\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Èinnost zaznamenávám do souboru %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "UID ukládám do souboru %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Zprávy o èinnosti zaznamenávám pomocí syslogu\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr ""
+"Fetchmail bude pracovat skrytì a nebude generovat hlavièku 'Received'\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr ""
+"Teèky znázoròující postup èinnosti bude fetchmail zapisovat\n"
+"i do ¾urnálového souboru.\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr ""
+"©patnì adresované zprávy ze spoleèných schránek budou pøeposílány na %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Chybové zprávy budou posílány u¾ivateli postmaster.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Chybové zprávy budou posílány odesilateli.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Volby pro stahování z %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Po¹ta bude sta¾ena z %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  Po¹ta bude z tohoto serveru stahována ka¾dou %d. periodu.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Skuteèné jméno tohoto serveru: %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr ""
+"  Pokud není ¾ádný stroj specifikován, %s stahovat z tohoto poèítaèe.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr "nebudou"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr "budou"
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Bude po¾adováno heslo.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  Heslo APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  RPOP u¾ivatel = \"%s\"\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Heslo = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr " Protokol KPOP s autentizací typu Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr " Protokol %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr "  (pou¾ívám slu¾bu %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (pou¾ívám bezpeènostní sí»ové volby %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (pou¾ívám port %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (pou¾ívám implicitní port)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr "  (vynucenì pou¾ívám UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  Vyzkou¹ím ve¹keré dostupné autentizaèní metody.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  Autentizace heslem je podporována\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  NTLM autentizace je podporována\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  OTP autentizace je podporována\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  CRAM-MD5 autentizace je podporována\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  GSSAPI autentizace je podporována\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Kerberos V4 autentizace bude vynucena.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Kerberos V5 autentizace bude vynucena.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  Pøedpokládám ¹ifrované spojení.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  U¾ivatelem po¹tovní slu¾by je %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1566
+#, fuzzy, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr " Protokol %s"
+
+#: fetchmail.c:1568
+#, fuzzy
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "Certifikát serveru zatím nenabyl platnosti"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr ""
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr ""
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  Poèet vteøin, po který bude oèekávána odpovìï serveru: %d"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (implicitní).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Zvolené po¹tovní schránky: implicitní\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Zvolené po¹tovní schránky:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  Stahované zprávy: %s (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "v¹echny"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "pouze nové"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Sta¾ené zprávy %s ponechány na serveru (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr "  Pøed zaèátkem stahování %s staré zprávy smazány (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  Pøepisování místních adres: %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "zapnuto"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "vypnuto"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  Mazání znaku CR: %s (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Vynucení znaku CR: %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+"  Interpretování polo¾ky 'Content-Transfer-Encoding': %s (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  dekódování MIME: %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  stálé spojení s IMAP serverem: %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Neprázdné 'Status' øádky budou %s (dropstatus %s)\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "odstranìny"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "ponechány"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Delivered-To øádky budou %s (dropdelivered %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  Maximální velikost zprávy v bajtech: %d (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  Maximální velikost zprávy v bajtech: neomezena (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr "  Interval zasílání varovných zpráv: %d vteøin (--warnings %d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+"  Interval zasílání varovných zpráv: pøi ka¾dém stahování (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr ""
+"  Maximální poèet zpráv sta¾ených ze serveru je %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr ""
+"  Maximální poèet zpráv sta¾ených ze serveru: neomezen (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr ""
+"  Maximální poèet zpráv sta¾ených ze serveru je %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Maximální velikost zprávy v bajtech: neomezena (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  SMTP dávkový limit: %d\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  SMTP dávkový limit: neomezeno (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr "  Zahazování zpráv: po ka¾dém %d. smazání (--expunge %d)\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Zahazování zpráv: po ukonèení spojení (--expunge 0)\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr ""
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (implicitní)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Zprávy budou pøipojeny k %s jako BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Zprávy budou doruèeny pomocí \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Zprávy budou pøeposlány pomocí %cMTP na:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  Název stroje v MAIL FROM øádku bude %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr "  V SMTP pøíkazu RCPT TO bude pou¾ita adresa %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Antispammingová pravidla:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Antispammingová pravidla: vypnuta\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  Pøíkaz pro navázání spojení se serverem: \"%s\"\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Pøíkaz pro navázání spojení se serverem: nespecifikován\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  Pøíkaz pro ukonèení spojení se serverem: \"%s\"\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Pøíkaz pro ukonèení spojení se serverem: nespecifikován\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Poèet rozpoznaných místních jmen: 0\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Re¾im spoleèných schránek"
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Re¾im soukromých schránek: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "Poèet rozpoznaných místních jmen: %d\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  Vyhledávání DNS jmen pro adresy spoleèných schránek je %s\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr ""
+"Pøezdívky serveru budou porovnávány s adresami spoleèných schránek podle "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "IP-adresy.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "jména.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  Smìrování dle obálkové adresy vypnuto\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Za obálkovou hlavièku pova¾uji: %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Pøijmuto"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr " Poèet obálkových hlavièek ke zpracování: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Pøedpona %s bude odtr¾ena od u¾ivatelského id\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  ®ádné pøedpony nebudou odtrhávány\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Deklarované pøezdívky po¹tovního serveru:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Místní domény:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  Spojení musí procházet pøes toto rozhraní: %s\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Spojení musí procházet pøes toto rozhraní: nespecifikováno\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Monitorování aktivity: monitoruji %s\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Monitorování aktivity: vypnuto\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr "  Pøíkaz pro navázání TCP spojení: %s (--plugin %s)\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Pøíkaz pro navázání TCP spojení: nespecifikován\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr "  Pøíkaz pro navázání SMTP spojení: %s (--plugout %s)\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Pøíkaz pro navázání SMTP spojení: nespecifikován\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Poèet UID ulo¾ených z tohoto stroje: 0\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  Poèet UID ulo¾ených z tohoto stroje: %d\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Pøedávací vlastnosti \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "volání alloca selhalo"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "CHYBA: funkce getpassword() není podporována\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"Zachycen SIGINT... konèím.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr ""
+
+#: gssapi.c:68
+#, fuzzy, c-format
+msgid "Using service name [%s]\n"
+msgstr "  (pou¾ívám slu¾bu %s)"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr ""
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr ""
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr ""
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr ""
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr ""
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr ""
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr ""
+
+#: gssapi.c:179
+#, fuzzy
+msgid "Error creating security level request\n"
+msgstr "chybný bezpeènostní po¾adavek"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr ""
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr ""
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: vlákno uspáno (poèet sekund: %d)\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protokol rozpoznán jako IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protokol rozpoznán jako IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protokol rozpoznán jako IMAP2 nebo IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "budu udr¾ovat stálé spojení se serverem\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr ""
+"Fetchmail byl pøelo¾en bez podpory pro po¾adovanou metodu ovìøení OTP\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr ""
+"Fetchmail byl pøelo¾en bez podpory pro po¾adovanou metodu ovìøení NTLM\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Server nepodporuje po¾adovanou metodu ovìøení LOGIN\n"
+
+#: imap.c:641 imap.c:707
+#, fuzzy
+msgid "expunge failed\n"
+msgstr "obnovené stahování se nezdaøilo\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "obnovené stahování se nezdaøilo\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "poèet zpráv zbývajících po obnoveném stahování: %d\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "volba po¹tovní schránky se nezdaøila\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "poèet zpráv zbývajících po prvním stahování: %d\n"
+
+#: imap.c:711
+#, fuzzy, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "poèet zpráv zbývajících po obnoveném stahování: %d\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "hledání nepøeètených zpráv bylo neúspì¹né\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u nepøeètených\n"
+
+#: imap.c:776 pop3.c:679
+#, fuzzy, c-format
+msgid "%u is first unseen\n"
+msgstr "%u nepøeètených\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"Nemohu otevøít kvm rozhraní. Ujistìte se, ¾e fetchmail má práva skupiny kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "Nelze analyzovat název rozhraní %s"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: volání sysctl (získání seznamu rozhraní) selhalo"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: volání malloc selhalo"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: volání sysctl (seznam rozhraní) selhalo"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "Neznámá smìøovací zpráva %d"
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "Rozhraní %s nenalezeno"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "pro rozhraní %s nebyly nalezeny ¾ádné IP-adresy"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "chybí adresa IP-rozhraní\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "nesprávná IP-adresa rozhraní\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "nesprávná IP-maska rozhraní\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "aktivita na %s zaznamenána jako %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "nestahuji z %s, %s není operativní\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "nestahuji z %s, IP-adresa %s vylouèena\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "aktivita na %s zkontrolována jako %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "nestahuji z %s, %s není aktivní\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "aktivita na %s byla %d, je %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr ""
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr ""
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr ""
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr ""
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr ""
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: odstraòuji staré zámky\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: nepodaøilo se vytvoøit zámek\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "varování: døíve ne¾ jméno stroje bylo nalezeno \"%s\""
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: varování: døíve ne¾ jméno stroje bylo nalezeno \"%s\"\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s%d: varování: neznámý token \"%s\"\n"
+
+#: odmr.c:65
+#, fuzzy, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "SMTP démon na %s nepodporuje ETRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr ""
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr ""
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr ""
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr ""
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr ""
+
+#. Authentication required
+#: odmr.c:125
+#, fuzzy
+msgid "Authentication required.\n"
+msgstr "  GSSAPI autentizace je podporována\n"
+
+#: odmr.c:129
+#, fuzzy, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Neznámá chyba ETRN %d\n"
+
+#: odmr.c:244
+#, fuzzy
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "Pøepínaè --keep není s protokolem ETRN podporován.\n"
+
+#: odmr.c:248
+#, fuzzy
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "Pøepínaè --flush není s protokolem ETRN podporován.\n"
+
+#: odmr.c:252
+#, fuzzy
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "Pøepínaè --remote není s protokolem ETRN podporován.\n"
+
+#: odmr.c:256
+#, fuzzy
+msgid "Option --check is not supported with ODMR\n"
+msgstr "Pøepínaè --check není s protokolem ETRN podporován.\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr ""
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr ""
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr ""
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "Øetìzec '%s' není platným èíslem.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "Hodnota øetìzce '%s' je %s ne¾ %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "men¹í"
+
+#: options.c:211
+msgid "larger"
+msgstr "vìt¹í"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Specifikovaný protokol `%s' není správný.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Specifikovaná autentizaèní metoda %s je nesprávná.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: funkce sí»ové bezpeènosti jsou vypnuty\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "Pou¾ití: fetchmail [pøepínaèe] [server ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Pøepínaèe:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        zobrazí tuto nápovìdu\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     zobrazí informace o verzi\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       zkontroluje, ale nestáhne po¹tu\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      nevypisuje  ¾ádné hlá¹ky\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     vypisuje kontrolní hlá¹ky\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      bì¾í jako démon jednou za n vteøin\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    démon se neodpojí od terminálu\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        ukonèí démon\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     soubor pro záznam èinnosti\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      pokud bì¾í jako démon, zaznamená vìt¹inu zpráv pomocí\n"
+"                    pomocí syslog(3)\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   nebude zapisovat hlavièku 'Received' a bude\n"
+"                    pøedstírat, ¾e je po¹tovním serverem\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc alternativní konfiguraèní soubor\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      alternativní UID soubor\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  nouzový pøíjemce po¹ty\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr ""
+"      --nobounce    zprávy s hlá¹ením o chybách budou posílány u¾ivateli\n"
+"                    postmaster.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   vy¾adované parametry rozhraní\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     monitoruje aktivitu na rozhraní\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         pou¾ije bezpeènostní protokol ssl\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      soubor se soukromým klíèem ssl\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     certifikát ssl klienta\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      --sslproto    pou¾ije ssl protokol (ssl2/ssl3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr "      --plugin      vnìj¹í pøíkaz k navázání TCP spojení\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr "      --plugout     vnìj¹í pøíkaz k navázání smtp spojení\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr "  -p, --protocol    protokol pro stahování (viz manuálová stránka)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        pou¾ije UIDL (pouze s pop3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        TCP/IP port, ke kterému se pøipojí\n"
+
+#: options.c:694
+#, fuzzy
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr "      --auth         druh autentizace (heslo/kerberos/ssh)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     èas po který se bude èekat na odpovìï serveru\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr ""
+"  -E, --envelope    hlavièka, její¾ hodnota bude pova¾ována za obálkovou "
+"adresu\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+"  -Q, --qvirtual    pøedpona, je¾ bude odtr¾ena od id místního u¾ivatele\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   u¾ivatel po¹tovní slu¾by\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    u¾ivatelské jméno na serveru\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         stáhne staré i nové zprávy\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      nové zprávy po sta¾ení sma¾e\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        nové zprávy po sta¾ení ponechá na serveru\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       sma¾e staré zprávy ze serveru\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   nepøepí¹e adresy v hlavièkách\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -l, --limit       nestáhne zprávy pøekraèující zadanou velikost\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    interval zasílání varovných zpráv\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      nastaví bezpeènostní výzvu IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    SMTP server pøejímající zprávy\n"
+
+#: options.c:714
+#, fuzzy
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr "  -B, --fetchlimit  maximální poèet zpráv sta¾ených ze serveru\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr "  -D, --smtpadress  cílová SMTP doména\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr "      --smtpname    nastaví plná SMTP jméno na jméno@doména\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    specifikuje odpovìdi antispammingových pravidel\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr "  -b, --batchlimit  dávkový limit pro SMTP spojení\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr "  -B, --fetchlimit  maximální poèet zpráv sta¾ených ze serveru\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr "  -B, --fetchlimit  maximální poèet zpráv sta¾ených ze serveru\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr "  -e, --expunge     maximální poèet smazání mezi zahozením zpráv\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         MDA kterému budou pøedávány zprávy\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       výstupní BSMTP soubor\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        pro doruèení pou¾ije LMTP (RFC2033)\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      jméno vzdálené po¹tovní schránky\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+"      --showdots    teèky zobrazující postup èinnosti bude "
+"vypisovat                           i do souboru se záznamem o èinnosti\n"
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "Po¾adovaný èasový údaj APOP nebyl v pozdravu nalezen\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Syntaktická chyba v èasovém údaji z pozdravu\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "®ádost o neznámý protokol v POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "Zamèeno! Je aktivní jiné sezení?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr "Zprávy na serveru jsou v listu. Nelze zpracovat.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "chyba protokolu\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "chyba protokolu pøi stahování seznamu UIDL\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "Pøepínaè --remote není s protokolem POP3 podporován\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "volba 'server' následuje po volbì 'user'"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "SDPS není zapnuto"
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "chybný bezpeènostní po¾adavek"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "funkce sí»ové bezpeènosti jsou vypnuty"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: volba 'interface' je podporována pouze na Linuxu (bez IPv6)\n"
+"a FreeBSD\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: volba 'monitor' je podporována pouze na Linuxu (bez IPv6)\n"
+"a FreeBSD\n"
+
+#: rcfile_y.y:350
+#, fuzzy
+msgid "SSL is not enabled"
+msgstr "SDPS není zapnuto"
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "konec vstupu"
+
+#: rcfile_y.y:435
+#, fuzzy, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "SOubor %s nesmí být symbolickým odkazem.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "Pøístupová práva souboru %s musí být maximýlnì -rwx--x--- (0710).\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "Musíte být vlastníkem souboru %s.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "neznámá systémová chyba"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (nedokonèený záznam èinnosti)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "pøeteèení bufferu pøi tvoøení chybové zprávy"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "chystám se pøepsat %s"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "Pøepsaná verze je %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Úspìch"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Limitovaný u¾ivatel (nìco je v nepoøádku s úètem)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "Nesprávné u¾ivatelské id èi heslo"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "chyba oblasti"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "RPA token2: chyba pøi dekódováni BASE64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Verze RPA %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Heslo slu¾by (l=%d)\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Èasový údaj slu¾by %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "Chybná dálka RPA tokenu 2\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Seznam oblastí:  %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "chyba RPA v øetìzci slu¾ba@oblast\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA token 4: chyba pøi dekódováni BASE64\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Autentizace u¾ivatele (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "status RPA: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "Chybná délka RPA tokenu 4\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA vás odmítá: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA vás odmítá, dùvod není znám\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "Chybná délka ovìøení u¾ivatele: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "Chybná délka klíèe sezení: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "Autentizaèní _slu¾ba_ RPA selhala. Fale¹ný server?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Klíè sezení vytvoøen:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "RPA autentizace dokonèena\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Oèekávám odpovìï\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Oèekávání odpovìdi skonèilo s výsledkem %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "Délka hlavièky není 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "Chybná délka tokenu\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "Délka tokenu (%d) neodpovídá rxlen (%d)\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "©patný mechanismus\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "dec64 chyba na znaku %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Vstupní binární data:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Výstupní binární data:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "RPA øetìzec je pøíli¹ dlouhý\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA se nezdaøilo otevøít /dev/urandom. To by vám\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    nemìlo zabránit v pøihlá¹ení, nicménì\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    si nemù¾ete být jisti, ¾e komunikujete\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    s tou slu¾bou, co se domníváte (Slu¾ba\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    se mù¾e vydávat za jinou s neèestným úmyslem.)\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Výzva u¾ivatele:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "aplikuji MD5 na datový block:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "výsledek MD5 je:\n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "pøeposílám na %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (posláno hlá¹ení o chybì)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "zpráva s hlí¹ením o chybì od %s poslána %s\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "Ulo¾ená chyba je stále %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "%cMTP chyba: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "nezdaøilo se otevøení BSMTP souboru èi zápis preambule\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "%cMTP démonu se nelíbí cílová adresa `%s'\n"
+
+#: sink.c:989
+#, fuzzy, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "%cMTP démonu se nelíbí cílová adresa `%s'\n"
+
+#: sink.c:1027
+#, fuzzy
+msgid "no address matches; no postmaster set.\n"
+msgstr "neodpovídá ¾ádná adresa; pøeposílám na %s\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "nelze odeslat ani na %s!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "neodpovídá ¾ádná adresa; pøeposílám na %s\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "chystám se doruèit pomocí %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "chyba pøi spu¹tìní MDA\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "%cMTP spojení s %s se nezdaøilo\n"
+
+#: sink.c:1283
+#, fuzzy, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "nepodaøilo se spustit démon; pou¾ívám "
+
+#: sink.c:1339
+#, fuzzy, c-format
+msgid "MDA died of signal %d\n"
+msgstr "probuzen signálem %d\n"
+
+#: sink.c:1342
+#, fuzzy, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "MDA buï skonèil chybnì, nebo vrátil nenulový status\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr ""
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Ukonèení zprávy èi uzavøení BSMTP souboru se nezdaøilo\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "SMTP démon odmítl doruèení\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "chyba LMTP pøíkazu EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Na LMTP pøíkaz EOM neoèekávanì pøi¹la jiná odpovìï (%s) ne¾ 503\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tFetchmail démon\n"
+
+#: smtp.c:86
+#, fuzzy
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "  CRAM-MD5 autentizace je podporována\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr ""
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr ""
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr ""
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:361 smtp.c:384
+#, fuzzy
+msgid "smtp listener protocol error\n"
+msgstr "chyba protokolu\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: volání malloc selhalo\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: volání socketpair selhalo\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: volání fork selhalo\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "volání dup2 selhalo\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "spou¹tím %s (stroj %s slu¾ba %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "volání execvp(%s) selhalo\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: nesprávná délka adresy pro stroj %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Organizace vydavatele: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "Neznámá organizace\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "Jméno vydavatele: %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "Neznámé jméno vydavatele\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Jméno poèítaèe: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr ""
+
+#: socket.c:812
+#, fuzzy, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "Jméno poèítaèe: %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "Neznámé jméno poèítaèe\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr ""
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr ""
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr ""
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr ""
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr ""
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr ""
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr ""
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr ""
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr ""
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Nejsou volné deskriptory souborù pro SSL"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr "Byl zadán chybný SSL protokol (`%s'), pou¾ívám implicitní SSLv23.\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr ""
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr ""
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr ""
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s mapováno na místní %s\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "pøedáno %s, vyhovuje %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analyzuji hlavièku 'Received':\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "øádek akceptován, %s je pøezdívkou po¹tovního serveru\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "øádek odmítnut, %s není pøezdívkou po¹tovního serveru\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "hlavièka 'Received' s adresou nebyla nalezena\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "v hlavièce 'Received' byla nalezena adresa `%s'\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "pøi prohledávání hlavièek byl nalezen oddìlovaè zprávy\n"
+
+#: transact.c:552
+#, fuzzy
+msgid "incorrect header line found while scanning headers\n"
+msgstr "pøi prohledávání hlavièek byl nalezen oddìlovaè zprávy\n"
+
+#: transact.c:554
+#, fuzzy, c-format
+msgid "line: %s"
+msgstr "Stahuji z %s\n"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "nevyhovuje ¾ádná z místních adres, pøeposílám na %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "pøeposílání a mazání bylo zru¹eno kvùli chybám DNS\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "zapisuji RFC822 msgblk.headers\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr ""
+"adresám pøíjemcù nevyhovuje ¾ádné z deklarovaných místních u¾ivatelských jmen"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "adrese pøíjemce (%s) nevyhovuje ¾ádné z místních u¾ivatelských jmen"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "zpráva obsahuje znaky NUL"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "SMTP démon odmítl tyto místní adresy:"
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "zapisuji text zprávy\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "Starý seznam UID z %s:"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <prázdný>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Pracovní seznam UID:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, fuzzy, c-format
+msgid "Merged UID list from %s:"
+msgstr "Starý seznam UID z %s:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "Nový seznam UID z %s:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "Prohazuji seznamy UID.\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr "Neprohazuji seznamy UID. Pøi tomto spojení se ¾ádná UID nevyskytla.\n"
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "Prohazuji seznamy UID.\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "Ma¾u soubor s UID.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "Ukládám UID do souboru.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "volání malloc selhalo\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "volání realloc selhalo\n"
+
+#~ msgid "Skipping message %d, length -1\n"
+#~ msgstr "Zprávu %d vynechávám, délka -1\n"
+
+#~ msgid "unknown issuer= %s"
+#~ msgstr "neznámý vydavatel= %s"
+
+#~ msgid "Server Certificate expired"
+#~ msgstr "Platnost certifikátu serveru ji¾ vypr¹ela"
+
+#~ msgid "fetchmail: monitor option is only supported under Linux\n"
+#~ msgstr "fetchmail: volba 'monitor' je podporivána pouze na Linuxu\n"
+
+#~ msgid "fetchmail: %s connection to %s failed"
+#~ msgstr "fetchmail: %s spojení s %s se nepodaøilo navázat"
+
+#~ msgid "Lockfile at %s\n"
+#~ msgstr "Zamykací soubor na %s\n"
+
+#~ msgid "fetchmail: cannot allocate memory for lock name.\n"
+#~ msgstr "fetchmail: pamì» pro jméno zámku nelze alokovat.\n"
diff --git a/po/da.gmo b/po/da.gmo
new file mode 100644
index 00000000..a84c590b
--- /dev/null
+++ b/po/da.gmo
diff --git a/po/da.po b/po/da.po
new file mode 100644
index 00000000..fc58a75f
--- /dev/null
+++ b/po/da.po
@@ -0,0 +1,2821 @@
+# Danish messages for fetchmail
+# Copyright (C) 2001, 2002 Free Software Foundation, Inc.
+# Byrial Ole Jensen <byrial@image.dk>, 2000-2003
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 6.2.2\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2003-04-10 18:50+0200\n"
+"Last-Translator: Byrial Ole Jensen <byrial@image.dk>\n"
+"Language-Team: Danish <dansk@klid.dk>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=iso-8859-1\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Tjekker om %s virkelig er samme maskine som %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Ja, deres IP-adresser stemmer overens\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Nej, deres IP-adresser stemmer ikke overens\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr "navneserverfejl ved opslag på \"%s\" ved prøvning af %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "kunne ikke afkode BASE64-anråb\n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "afkodet som %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "kerberosfejl %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [server siger '%*s']\n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Subject: Fetchmail-advarsel om for store breve\n"
+"\n"
+"Disse breve er for store og forbliver paa postserveren %s:"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\t%d. brev, %d oktetter lang, sprunget over af fetchmail.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "Springer brev %s@%s:%d over (%d oktetter)"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "Springer brev %s@%s:%d over (%d oktetter)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr " (længde -1)"
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr " (for langt)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr "kunne ikke hente brevhoveder, brev %s@%s:%d (%d oktetter)\n"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "læser brev %s@%s:%d af %d"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d %soktetter)"
+
+#: driver.c:606
+msgid "header "
+msgstr "brevhoved-"
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d oktetter i brevkrop)"
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr "brev %s@%s:%d havde ikke den forventede længde (%d != %d forventet)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " bevaret\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " slettet\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " ikke slettet\n"
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr "afhentningsgrænse %d nået; %d breve tilbage på server %s konto %s\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "SIGPIPE kastet fra en MDA, eller en strømsokkelfejl\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr "tidsafbrud efter %d sekunders venten på forbindelse til server %s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "tidsafbrud efter %d sekunders venten på server %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "tidsafbrud efter %d sekunders venten på %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr "tidsafbrud efter %d sekunders venten på svar fra modtager.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "tidsafbrud efter %d sekunder.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Subject: fetchmail har gentagne tidsafbrud\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail fik mere end %d tidsafbrud ved forsoeg paa at hente post fra %s@%"
+"s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Det kan betyde at din postserver eller din SMTP-server er ude af drift,\n"
+"eller at din brevbakke-fil paa serveren er blevet oedelagt ved en server-\n"
+"fejl. Du kan koere \"fetchmail -v -v\" for at diagnosticere problemet.\n"
+"\n"
+"Fetchmail vil ikke proeve den brevbakke igen foer du genstarter den.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "forbindelseskommando mislykkedes med status %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "kunne ikke finde HESIOD-postboks for %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Fører-server har ikke noget navn.\n"
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "kunne ikke finde kanonisk DNS-navn for %s\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "intern uoverensstemmelse\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "%s-forbindelse til %s mislykkedes"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "værten er ukendt."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "navnet er gyldigt, men har ingen IP-adresse."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "uoprettelig navneserverfejl."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "midlertidig navneserverfejl."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "ukendt DNS-fejl %d."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Subject: Fetchmail-advarsel om utilgaengelig server.\n"
+"\n"
+"Fetchmail kunne ikke naa postserveren %s:"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "SSL-forbindelse mislykkedes.\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Lås optaget-fejl på %s@%s\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Server optaget-fejl på %s@%s\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Godkendelsesfejl på %s@%s%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr " (tidligere godkendt)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: fetchmail - godkendelse mislykkedes paa %s@%s\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail kunne ikke hente post fra %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Forsoeget paa at opnaa adgangstilladelse mislykkedes.\n"
+"Da der tidligere er opnaaet adgangstilladelelse for denne forbindelse,\n"
+"skyldes dette sandsynligvis en anden fejl (saasom optaget server) som\n"
+"fetchmail ikke kan se fordi serveren ikke sendte en ordentlig fejl-\n"
+"meddelelse.\n"
+"\n"
+"Hvis du imidlertid HAR aendret din kontoopsaetning efter at fetchmail-\n"
+"daemonen blev startet, er det noedvendigt at stoppe daemonen, aendre din\n"
+"opsaetning og så genstarte daemonen.\n"
+"\n"
+"Fetchmail-daemonen vil fortsat koere og forsoege at lave forbindelse.\n"
+"Der vil ikke blive flere meddelelser foer servicen er genetableret."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Forsoeget paa at opnaa adgangstilladelse mislykkedes.\n"
+"Det betyder sandsynligvis at dit kodeord er ugyldigt, men nogle servere\n"
+"har ogsaa andre fejltilstande som fetchmail ikke kan skelne fra dette,\n"
+"fordi de ikke sender brugbare fejlmeddelelser ved indlogningsfejl.\n"
+"\n"
+"Fetchmail-daemonen vil fortsat koere og forsoege at lave forbindelse.\n"
+"Der vil ikke blive flere meddelelser foer servicen er genetableret."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr "Prøver straks igen %s@%s\n"
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Ukendt indlognings- eller godkendelsesfejl på %s@%s\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Godkendelse i orden på %s@%s\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: fetchmail - godkendelse i orden paa %s@%s\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail var i stand til at logge ind på %s@%s.\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "Servicen er blevet reetableret.\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "vælger eller prøver igen brevbakke %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "vælger eller prøver igen indbakken\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s ved %s (brevbakke %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s ved %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Prøver %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d gamle) til %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "breve"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "brev"
+
+#: driver.c:1366
+msgid "seen"
+msgstr ""
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s til %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d oktetter).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "Ingen post til %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "falsk brev-tal!"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "sokkel"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "manglende eller forkert RFC 822-brevhoved-"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA-"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "klient/server-synkroniserings"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "klient/server-protokol"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "server låst-"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "SMTP-transaktions"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "DNS-opslags"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "udefineret fejl\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "%sfejl ved levering til SMTP-vært fra %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "%sfejl ved hentning fra %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "afslutningskommando fejlede med kode %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "ikke oversat med Kerberos V4-støtte.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "ikke oversat med Kerberos V5-støtte.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Tilvalg --flush er ikke understøttet med %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Tilvalg --all er ikke understøttet med %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Tilvalg --limit er ikke understøttet med %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: QMAILINJECT-miljøvariablen er sat.\n"
+"Det er farligt da det kan få qmail-inject eller qmails sendmail-omslag\n"
+"til at rette i dine From:- eller Message-ID:-brevhoveder.\n"
+"Prøv \"env QMAILINJECT= %s DINE ARGUMENTER HER\"\n"
+"%s: afbryder.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: NULLMAILER_FLAGS-miljøvariablen er sat.\n"
+"Det er farligt da det kan få mullmailer-inject eller nullmailers\n"
+"sendmail-omslag til at rette i dine From:-, Message-ID: eller\n"
+"Return-Path:-brevhoveder.\n"
+"Prøv \"env NULLMAILER_FLAGS= %s DINE ARGUMENTER HER\"\n"
+"%s: afbryder.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Du findes ikke.  Fjern dig.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: kan ikke bestemme din værtsmaskine!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "gethostbyname fejlede for %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "%s's SMTP-modtager understøtter ikke ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "%s's SMTP-modtager understøtter ikke ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Kø for %s startet\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Ingen breve venter på %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Ikke-leverede breve til %s gjort klar\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Kan ikke stille breve i kø til maskine %s\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Maskine %s ikke tilladt: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "ETRN-syntaksfejl\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "ETRN-syntaksfejl i parametre\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Ukendt ETRN-fejl %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "Tilvalg --keep er ikke understøttet med ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "Tilvalg --flush er ikke understøttet med ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "Tilvalg --remote er ikke understøttet med ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "Tilvalg --check er ikke understøttet med ETRN\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: kaldt med"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "kunne ikke få det nuværende arbejdskatalog\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Dette er fetchmail udgave %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Bruger tilvalg fra kommandolinje%s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " og "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "Ingen postservere sat op - måske mangler %s?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: ingen postservere er blevet specificeret.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: ingen anden fetchmail kører\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: fejl ved drab af %sfetchmail på %d; jeg trækker mig.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "baggrunds"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "forgrunds"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %sfetchmail på %d dræbt.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: kan ikke tjekke post mens en anden fetchmail til samme vært "
+"kører.\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: kan ikke prøve de specificerede værter mens en anden fetchmail "
+"kører på %d.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: en anden forgrundsfetchmail kører på %d.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr "fetchmail: kan ikke tage tilvalg mens en baggrundsfetchmail kører.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: baggrunds fetchmail på %d vækket.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: ældre søskende på %d døde på mystisk vis.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: kan ikke finde et kodeord for %s@%s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Angiv kodeord for %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "starter fetchmail %s-dæmon\n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "kunne ikke åbne %s for at tilføje logs til \n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "kunne ikke tidsfæste %s (fejl %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "genstarter fetchmail (%s ændret)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+"forsøg på at genstarte kan mislykkes da kataloget ikke er genoprettet\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "forsøg på at genstarte fetchmail fejlede\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"prøve af %s droppet (mislykket godkendelse eller for mange tidsafbrud)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "interval ikke nået, spørger ikke %s\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Spørgestatus=0 (succes)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Spørgestatus=1 (ingen post)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Spørgestatus=2 (sokkelfejl)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Spørgestatus=3 (godkendelsesfejl)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Spørgestatus=4 (protokolfejl)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Spørgestatus=5 (syntaksfejl)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "Spørgestatus=6 (I/O-fejl)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "Spørgestatus=7 (serverfejl)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Spørgestatus=8 (eksklusionsfejl)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Spørgestatus=9 (lås optaget)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "Spørgestatus=10 (SMTP-fejl)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "Spørgestatus=11 (DNS-fejl)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Spørgestatus=12 (BSMTP-fejl)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Spørgestatus=13 (afhentningsgrænse nået)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Spørgestatus=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Alle forbindelser er afbrudte.  Afbryder.\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "sover %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "vækket af %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "vækket af signal %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "vækket %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "normal afslutning, status %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "kunne ikke tidsfæste kørselskontrolfilen\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr "Advarsel: flere forekomster af vært %s i konfigurationsfil\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "ikke konfigureret med SSL-understøttelse.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: advarsel: DNS er ikke tilgængelig til at tjekke flermodtager-"
+"afhentninger fra %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "konfiguration af %s forkert, portnummer kan ikke være negativt\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "konfiguration af %s forkert, RPOP kræver en privilegeret port\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr "konfiguration af %s forkert, LMTP kan ikke bruge standard SMTP-port\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "Brug af både fetchall og keep som dæmon er en fejl!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "afsluttet med signal %d\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s-forespørgsel til %s (protokol %s) begyndt %s\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "ikke konfigureret med POP2-understøttelse.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "ikke konfigureret med POP3-understøttelse.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "ikke konfigureret med IMAP-understøttelse.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "ikke konfigureret med ETRN-understøttelse.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "Kan ikke understøtte ETRN uden gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "ikke konfigureret med ODMR-understøttelse.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "Kan ikke understøtte ODMR uden gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "ikke-understøttet protokol valgt.\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s-forespørgsel til %s (protokol %s) afsluttet %s\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "Prøvemellemrum er %d sekunder\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Logfil er %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Id-fil er %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Forløbsbeskeder vil blive logget vha. syslog\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail vil forstille sig og ikke generere Received\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr "Fetchmail vil vise forløbsprikker selv i logfiler.\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr ""
+"Fetchmail vil i flermodtager-tilstand levere fejladresserede breve til %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Fetchmail vil rette fejlbreve til postmesteren.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail vil rette fejlbreve til afsenderen.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Tilvalg for modtagelse fra %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Post vil blive modtaget via %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  Prøvning af denne server vil ske hvert %d. sekund.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Serverens sande navn er %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr "  Denne vært %s blive forespurgt når ingen vært er specificeret.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr "vil ikke"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr "vil"
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Der vil blive spurgt efter kodeord.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  APOP-hemmlighed = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  RPOP-id = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Kodeord = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  Protokol er KPOP med Kerberos %s-godkendelse"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  Protokol er %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (bruger service %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (bruger netværkssikkerhedstilvalg %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (bruger port %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (bruger standardport)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (fremtvinger UIDL-brug)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  Alle tilgængelige godkendelsesmetoder vil blive forsøgt.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  Kodeordsgodkendelse er påkrævet.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  NTLM-godkendelse er påkrævet.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  OTP-godkendelse er påkrævet.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  CRAM-Md5-godkendelse er påkrævet.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  GSSAPI-godkendelse er påkrævet.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Kerberos V4-godkendelse er påkrævet.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Kerberos V5-godkendelse er påkrævet.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  Antager brug af krypteret forbindelse.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  Fuldmagtsgiver for postservice er: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  Vil bruge SSL-kryptering.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  SSL-protokol: %s\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  SSL-servercertifikat tjekkes.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  Katalog for SSL-certifikater: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr "  SSL-nøgle-fingeraftryk (tjekket mod servernøglen): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  Venter på svar fra server i højst %d sekunder"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (standard).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Indbakken valgt.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Udvalgte brevbakker er:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s breve vil blive hentet (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "Alle"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "Kun nye"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Hentede breve %s blive gemt på serveren (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr "  Gamle breve %s blive slettede før afhentning (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  Omskrivning af serverlokale adresser er %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "slået til"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "slået fra"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  Fjernelse af vognreturtegn er %s (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Indsættelse af vognreturtegn er %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr "  Fortolkning af Content-Transfer-Encoding er %s (pass8bit %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  MIME-afkodning er %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  Tomgang efter prøvning er %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Ikke-tomme statuslinjer vil blive %s (dropstatus %s)\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "slettet"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "bevaret"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  \"Delivered-To\"-linjer vil blive %s (dropdelivered %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  Maksimal størrelse på breve er %d oktetter (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  Ingen maksimal størrelse på breve (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr "  Interval for størrelsesadvarsler er %d sekunder (--warnings %d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr "  Størrelsesadvarsler ved hver prøvning (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  Maksimalt antal hentede breve er %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  Intet maksimalt antal hentede breve (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  Maksimalt antal hentede breve er %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Ingen maksimal størrelse på breve (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  SMTP-brevantalsgrænse er %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  Ingen SMTP-brevantalsgrænse (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr "  Sletninger udføres ved hver %d. brev (--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Ingen forcerede sletninger (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Domæner som der vil blive hentet post til:"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (standard)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Breve vil blive tilføjet %s som BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Breve vil blive leveret med \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Breve vil blive %cMTP-leveret til:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  Værtsdelen af MAIL FROM-linjen vil blive %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr "  Adressen i RCPT TO-linjer til SMTP bliver %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Genkendte spamblokeringssvar fra modtager er:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Spamblokering er slået fra\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  Serverforbindelsen vil blive etableret med \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Ingen etableringskommando.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  Serverforbindelse vil blive lukket med \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Ingen lukningskommando.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Ingen lokale navne er angivet for denne vært.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Flermodtager-tilstand: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Enkeltmodtager-tilstand: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d lokale navne genkendt\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  DNS-opslag for flermodtager-adresser er %s.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr "  Serveraliaser vil blive sammenholdt med flermodtager-adresser efter "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "IP-adresse.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "navn.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "Adressering efter konvolutadressen er slået fra\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Konvolutadressen antages at være i %s-feltet i brevhovedet\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Received"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Nr. konvolutadresse som vil blive analyseret: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Præfiks %s vil blive slettet fra bruger-id\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  Ingen præfikssletning\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Foruderklærede postserveraliaser:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Lokale domæner:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  Forbindelse skal ske gennem grænseflade %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Ingen grænsefladekrav specificeret.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Prøveløkke vil overvåge %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Ingen overvågning af grænseflade specificeret.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr ""
+"  Serverforbindelser vil blive lavet vha. hjælpeprogrammet %s (--plugin %"
+"s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Intet hjælpeprogram til kald af server specificeret.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  Modtagerforbindelser vil blive lavet vha. hjælpeprogrammet %s (--plugout %"
+"s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Intet hjælpeprogram til kald af modtager specificeret.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Ingen IUD'er gemt fra denne vært.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d UID'er gemt.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr "  Sporingsinformation vil blive tilføjet \"Received\"-brevhovedet.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  Sporingsinformation vil ikke blive tilføjet \"Received\"-brevhovedet.\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Egenskaber som ignoreres af fetchmail: \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "alloca mislykkedes"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "FEJL: ingen understøttelse til getpassword()-funktion\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"Fangede SIGINT... Jeg trækker mig.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Kunne ikke få servicenavn for [%s]\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "Bruger servicenavn [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Sender akkreditiver\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Fejl ved udveksling af akkreditiver\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Kunne ikke udpakke sikkerhedsniveaudata\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Akkreditiver udvekslet\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Server kræver integritet og/eller hemmeligholdelse\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Udpakkede sikkerhedsniveauflag: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "Maksimal GSS-symbolstørrelse er %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Fejl ved anmodning af sikkerhedsniveau\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Frigiver GSS-akkreditiver\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Fejl ved frigivelse af akkreditiver\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: tråd sover i %d sekunder.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protokol identificeret som IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protokol identificeret som IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protokol identificeret som IMAP2 eller IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "går i tomgang efter prøvning\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "Fetchmail er ikke oversat med OTP-evne som påkrævet\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Fetchmail er ikke oversat med NTLM-evne som påkrævet\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Server understøtter ikke den krævede indlogningsmåde\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "sletning (EXPUNGE) mislykkedes\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "genprøvning mislykkedes\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "%d breve venter efter genprøvning\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "valg af brevbakke mislykkedes\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "%d breve venter efter første prøvning\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "%d breve venter efter sletning\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "søgning efter usete breve mislykkedes\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u er usete\n"
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr "%u er første usete\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr "Kan ikke åbne kvm-grænseflade. Sørg for at fetchmail er SGID kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "Kan ikke udlede grænsefladenavn fra %s"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: sysctl (få iflist-størrelse) mislykkedes"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: malloc mislykkedes"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: sysctl (få iflist) mislykkedes"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "Forstår ikke version %d af dirigeringsbeskeder."
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "Ingen grænseflade med navnet %s fundet"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "ingen IP-adresse fundet for %s"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "manglende IP-grænsefladeadresse\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "Ugyldig IP-grænsefladeadresse\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "Ugyldig IP-grænseflademaske\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "aktivitet på %s opfattet som %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "springer prøvning af %s over, %s er nede\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "springer prøvning af %s over, %s's IP-adresse er fravalgt\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "aktivitet på %s tjekket som %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "springer prøvning af %s over, %s er inaktiv\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "aktivitet på %s var %d, er %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "kunne ikke afkode det indledende BASE64-anråb\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "fuldmagtsgiver %s i billet stemmer ikke overens med bruger %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "ikke-tom foranledning (%s) kan medføre underlig adfærd\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "kunne ikke afkode BASE64 klar-svar\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "uoverensstemmelse i anråb\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: fjerner efterladt låsefil\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: oprettelse af låsefil mislykkedes\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "advarsel: fandt \"%s\" før noget værtsnavn"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: advarsel: fandt \"%s\" før noget værtsnavn\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: advarsel: ukendt symbol \"%s\"\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "%s's SMTP-modtager understøtter ikke ATRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "Vender nu...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "ATRN-anmodning afvist.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "Kan ikke behandle ATRN-anmodning nu.\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "Du har ingen post.\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Kommando ikke implementeret.\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Godkendelse påkrævet.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Ukendt ODMR-fejl %d.\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "Tilvalg --keep er ikke understøttet med ODMR\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "Tilvalg --flush er ikke understøttet med ODMR\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "Tilvalg --remote er ikke understøttet med ODMR\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "Tilvalg --check er ikke understøttet med ODMR\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "fatal fejl ved læsning fra server\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Kunne ikke afkode OTP-anråb\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Hemmeligt løsen: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "strengen '%s' er ikke en gyldig talstreng.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "Værdien af strengen '%s' er %s end %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "mindre"
+
+#: options.c:211
+msgid "larger"
+msgstr "større"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Ugyldig protokol '%s' specificeret.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Ugyldig godkendelse '%s' specificeret.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: understøttelse af netværkssikkerhed er slået fra\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "brug: fetchmail [tilvalg] [server ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Mulige tilvalg er:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        vis denne hjælp\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     vis versionsinformation\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       tjek om der er breve uden at hente dem\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      vær stille\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     vær larmende (diagnostisk uddata)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      kør som dæmon en gang pr. n sekunder\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    sæt ikke ikke dæmonprocessen i baggrunden\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        dræb dæmonproces\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     angiv navn på logfil\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr "      --syslog      brug syslog(3) som dæmon til de fleste beskeder\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr "      --invisible   skriv ikke Received-linjer & lav værtssløring\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc specificer en alternativ kørselskontrolfil\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      specificer en alternativ UID-fil\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  specificer modtager som sidste udvej\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr ""
+"      --nobounce    omdiriger afviste breve fra bruger til postmester.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   specifikation af krævet grænseflade\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     overvåg grænseflade for aktivitet\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         brug ssl-kryptering\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      privat ssl-nøglefil\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     ssl-klientcertifikat\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      -ssl          brug bestemt af ssl-protokol (ssl2/ss3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr "      --plugin      specificer hjælpeprogram til at åbne forbindelse\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     specificer hjælpeprogram til at åbne smtp-forbindelse\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr "  -p, --protocol    specificer posthentingsprotokol (se man-siden)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        fremtving brug af UID'er (kun pop3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        TCP/IP-serviceport at bruge\n"
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr "      --auth        type godkendelse (password/kerberos/ssh/otp)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     tidsafbrud ved manglende serversvar\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    adressering efter konvolutadresse\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr "  -Q, --qvirtual    præfiks som skal slettes fra lokale bruger-id'er\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   Fuldmagtsgiver for postservice\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+"      --tracepolls  tilføj sporingsinformation i \"Received\"-brevhovedet\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    specificer brugernavn på server\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         hent gamle og nye breve\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      slet nye breve efter hentning\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        gem nye breve efter hentning\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       slet gamle breve på server\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   omskriv ikke adresser i brevhovedet\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -l, --limit       hent ikke breve over den anførte størrelse\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    periode mellem afsendelse af advarsler pr. post\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      anfør IP-sikkerhedsanmodning\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    anfør vært til SMTP-levering\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr "      --fetchdomains hent post til anførte domæner\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr "  -D, --smtpaddress anfør SMTP-afleveringsdomæne at bruge\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr "      --smtpname    anfør fuldt SMTP-navn - brugernavn@domæne\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam,   anfør antispam-svarværdier\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+"  -b, --batchlimit  anfør maks. antal afleveringer pr. SMTP-forbindelse\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  anfør maks. antal hentninger pr. serverforbindelse\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr "      --fetchdomains hent post til anførte domæner\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+"  -e, --expunge     anfør maks. antal sletninger mellem effektueringer\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         anfør MDA til brug for levering\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       anfør BSMTP-uddatafil\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        brug LMTP (RFC 2033) til levering\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      specificer navn på brevbakke på server\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr "      --showdots    vis forløbsprikker selv i logfiler\n"
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "Påkrævet APOP-tidsstempel ikke fundet i hilsen\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Syntaksfejl i tidsstempel i hilsen\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Udefineret protokolønske i POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "lås optaget! Er et andet opkald aktivt?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr "Breve indsat på serverens liste. Kan ikke håndtere dette.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "protokolfejl\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "protokolfejl ved hentning af UID'er\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "Tilvalg --remote er ikke understøttet med POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "tilvalg vedr. server efter brugertilvalgene"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "SDPS er ikke slået til."
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "Ugyldig sikkerhedsanmodning"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "understøttelse af netværkssikkerhed er slået fra"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: grænsefladetilvalg (interface) er kun understøttet under Linux "
+"(uden IPv6) og FreeBSD\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: overvågningstilvalg (monitor) er kun understøttet under Linux "
+"(uden IPv6) og FreeBSD\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "SSL er ikke slået til"
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "slut på inddata"
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "Filen %s skal være en regulær fil.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "Filen %s må ikke flere tilladelser end -rwx--x--- (0710).\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "Filen %s skal være ejet af dig.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Ukendt systemfejl"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (logbesked ikke komplet)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "overløb i buffer til del af fejlbesked"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "Skal til at omskrive %s"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "Omskreven version er %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Succes"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Begrænset bruger (noget er galt med kontoen)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "Ugyldigt brugernavn eller løsen"
+
+# Hvad i alverden er deity error?
+#: rpa.c:119
+msgid "Deity error"
+msgstr "Gudefejl"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "RPA symbol 2: Base64-afkodningsfejl\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Service valgte RPA-version %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Service anråb (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Service tidsstempel %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "RPA symbol 2 længdefejl\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Områdeliste: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "RPA-fejl i service@område-streng\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA symbol 4: Base64-afkodningsfejl\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Brugergodkendelse (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "RPA-status: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "RPA symbol 4 længdefejl\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA afviser dig: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA afviser dig, årsag ukendt\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "RPA-brugergodkendelses-længdefejl: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "RPA-sessionsnøgle-længdefejl: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "RPA _service_ auth-fejl. Narreserver?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Sessionsnøgle etableret:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "RPA-godkendelse komplet\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Får svar\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Får svar %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "Hdr ikke 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "Symbollængdefejl\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "Symbollængde %d stemmer ikke overens med rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Mekanismefelt ukorrekt\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "dec64-fejl ved tegn %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Indgående binære data:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Udgående data:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "RPA-streng for lang\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA Åbning af /dev/urandom mislykkedes. Det skulle ikke\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    forhindre dig i at logge ind, men betyder at du\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    ikke kan være sikker på at du taler med den\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    service som du tror (gentagelses-\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    angreb af en uærlig service er mulig).\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Brugeranråb:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "MD5 bliver anvendt på datablok:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "MD5-resultatet er:\n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "leverer til %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (tekst til afvisningsbrev)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "afvisning af brev fra %s sendt til %s\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "Gemt fejlkode er stadig %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "%cMTP-fejl: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "BSMTP-fil åben eller skrivning af indledning mislykkedes\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "%cMTP-modtager kan ikke lide modtageradresse '%s'\n"
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "%cMTP-modtager kan virkelig ikke lide modtageradresse '%s'\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "ingen adresser passer; postmester ikke sat.\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "kan ikke engang sende til %s!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "ingen adresse-overensstemmelse; leverer til %s.\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "klar til at levere med: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "MDA-åbning mislykkedes\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "%cMTP-forbindelse til %s mislykkedes\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "kan ikke få kontakt til modtager, bruger i stedet %s"
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr "MDA døde af signal %d\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "MDA returnerede en ikke-nul status %d\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr "Underligt: MDA pclose returnede %d, kan ikke håndtere det i %s:%d\n"
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Afslutning af brev eller lukning af BSTMP-fil mislykkedes\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "SMTP-modtager afviste levering\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "LMTP-leveringsfejl på EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Uventet ikke-503-svar til LMTP EOM: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tFetchmail Daemonen\n"
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "ESMTP CRAM-MD5-godkendelse...\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "Serveren afviste AUTH-kommandoen til godkendelse.\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "Fejl i base64-svar fra server.\n"
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "Anråb afkodet: %s\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "ESMTP PLAIN-godkendelse...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "ESMTP LOGIN Authentication...\n"
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr "protokolfejl hos SMTP-modtager\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: malloc mislykkedes\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: socketpair mislykkedes\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: fork mislykkedes\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "dup2 mislykkedes\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "udfører %s (server %s service %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "execvp(%s) mislykkedes\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: ulovlig adresselængde modtaget for vært %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Udsteders organisation: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr "Advarsel: Udsteders organisationsnavn for langt (måske afskåret).\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "Ukendt organisation\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "Udsteders almennavn: %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr "Advarsel: Udsteders almennavn for langt (måske afskåret).\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "Udsteders almennavn ukendt\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Servers almennavn %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "Dårligt certifikat: Almennavn for langt!\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "Uoverensstemmelse i servers almennavn: %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr "Servernavn ikke anført, kunne ikke verificere certifikat!\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "Servers almennavn ukendt\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "Servernavn ikke specificeret i certifikat!\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "EVP_md5() mislykkedes!\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "Ingen hukommelse!\n"
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "Oversigtstekstbuffer for lille!\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "%s nøgle-fingeraftryk: %s\n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "%s fingeraftryk passer.\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "%s fingeraftryk passer ikke!\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "Advarsel: servercertifikat-verificering: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "Ukendt udsteder (de første %d tegn): %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Fildeskriptor har forkert værdi til SSL"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr "Ugyldig SSL-protokol '%s' specificeret, bruger SSLv23.\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr ""
+"Certifikat/fingeraftryk-verifikation blev på en eller anden måde sprunget "
+"over!\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr "Forsøger igen at læse cygwin-sokkel\n"
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr "Forsøg på at læse cygwin-sokkel mislykkedes!\n"
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s svarer til %s lokalt\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "Undersøgt %s som passer med %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analyserer Received-linje:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "linjen accepteret, %s er et alias for postserveren\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "linjen afvist, %s er ikke et alias for postserveren\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "ingen \"Received\"-adresse fundet\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "fandt \"Received\"-adresse `%s'\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "brev afsluttet under læsningen af brevhovedet\n"
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "ukorrekt brevhovedlinje fundet under læsningen af brevhovedet\n"
+
+#: transact.c:554
+#, fuzzy, c-format
+msgid "line: %s"
+msgstr "Prøver %s\n"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "ingen lokale overensstemmelser, leverer til %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "levering og sletning undladt pga. DNS-fejl\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "skriver RFC822 msgblk.headers\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "ingen modtageradresser passer med erklærede lokale navne"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "modtageradresse %s passede ikke med noget lokalt navn"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "brev indeholder NUL-tegn"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "SMTP-modtager afviste lokal modtageradresse: "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "skriver brevtekst\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "Gammel UID-liste fra %s:"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <tom>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Liste af øvrige UID'er:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, fuzzy, c-format
+msgid "Merged UID list from %s:"
+msgstr "Gammel UID-liste fra %s:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "Ny UID-liste fra %s:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "Ombytter UID-lister\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr "Ombytter ikke UID-lister, ingen UID'er set ved denne forespørgsel\n"
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "Ombytter UID-lister\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "Sletter fetchids-fil\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "Skriver fetchids-fil.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "malloc mislykkedes\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "realloc mislykkedes\n"
diff --git a/po/de.gmo b/po/de.gmo
new file mode 100644
index 00000000..d2f56217
--- /dev/null
+++ b/po/de.gmo
diff --git a/po/de.po b/po/de.po
new file mode 100644
index 00000000..4314d6cc
--- /dev/null
+++ b/po/de.po
@@ -0,0 +1,2869 @@
+# German Messages for fetchmail.
+# Copyright (C) 2001 Free Software Foundation, Inc.
+# Michael Piefel <piefel@informatik.hu-berlin.de>, 2001, 2002, 2003.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 6.2.4\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2003-08-14 14:25:41+0200\n"
+"Last-Translator: Michael Piefel <piefel@informatik.hu-berlin.de>\n"
+"Language-Team: German <de@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Es wird überprüft, ob %s und %s wirklich der gleiche Knoten sind\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Ja, ihre IP-Adressen stimmen überein\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Nein, ihre IP-Adressen stimmen nicht überein\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr ""
+"Nameserver-Versagen beim Nachschlagen von „%s“ währen der Abfrage von %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "BASE64-Herausforderung konnte nicht dekodiert werden\n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "dekodiert als %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "Kerberos-Fehler %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [Server sagt „%*s“] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Subject: Fetchmail-Warnung: übergroße Nachrichten\n"
+"\n"
+"Die folgenden übergroßen Nachrichten verbleiben auf dem Mail-Server %s:"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\t%d msg %d Oktetts lang von fetchmail ausgelassen.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "Nachricht %s@%s:%d (%d Oktetts) wird ausgelassen"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "Nachricht %s@%s:%d (%d Oktetts) wird ausgelassen"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr " (Länge -1)"
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr " (übergroß)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr ""
+"Kopfzeilen konnten nicht geholt werden, Nachricht %s@%s:%d (%d Oktetts)\n"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "Nachricht %s@%s:%d von %d wird gelesen"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d %sOktetts)"
+
+#: driver.c:606
+msgid "header "
+msgstr "Kopfzeilen "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d Oktetts im Nachrichtenkörper) "
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"Nachricht %s@%s:%d hatte nicht die erwartete Länge (%d tatsächlich != %d "
+"erwartet\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " aufbewart\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " geflusht\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " nicht geflusht\n"
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr "fetchlimit %d erreicht; %d Nachrichten übrig auf Server %s Konto %s\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "SIGPIPE geworfen von einem MDA oder Stream-Socket-Fehler\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+"Zeitüberschreitung nach %d Sekunden beim Warten auf Verbindung mit Server %"
+"s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "Zeitüberschreitung nach %d Sekunden beim Warten auf Server %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "Zeitüberschreitung nach %d Sekunden beim Warten auf %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr ""
+"Zeitüberschreitung nach %d Sekunden beim Warten Antwort des Lauschers.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "Zeitüberschreitung nach %d Sekunden.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Subject: fetchmail erlebt wiederholte Zeitüberschreitungen\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail hat mehr als %d Zeitüberschreitungen erhalten beim Versuch, Mail "
+"von %s@%s abzuholen.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Das könnte bedeuten, dass Ihr Mailserver hängengeblieben ist, oder das sich\n"
+"Ihr SMTP-Server verkeilt hat, oder dass Ihre Mailbox-Datei auf dem Server\n"
+"durch einen Server-Fehler korrumpiert ist. Sie können „fetchmail -v -v“ "
+"auf-\n"
+"rufen, um das Problem zu diagnostizieren.\n"
+"\n"
+"Fetchmail wird diese Mailbox nicht mehr abfragen, bis Sie es erneut starten\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "Vor-Verbindungs-Befehl scheiterte mit Status %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "konnte das HESIOD-Postfach für %s nicht finden\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Führungsserver hat keinen Namen.\n"
+
+#: driver.c:1016
+#, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "konnte kanonischen DNS-Namen von %s (%s) nicht finden\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "interne Inkonsistenz\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "%s Verbindung zu %s fehlgeschlagen"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "Host ist unbekannt."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "Name ist gültig, hat aber keine IP-Adresse."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "unüberbrückbarer Nameserver-Fehler"
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "temporärer Nameserver-Fehler"
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "unbekannter DNS-Fehler %d."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Subject: Fetchmail-Warnung: unerreichbarer Server.\n"
+"\n"
+"Fetchmail konnte den Mail-Server %s nicht erreichen:"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "SSL-Verbindung fehlgeschlagen.\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Lock-Beschäftigt-Fehler bei %s@%s\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Server-Beschäftigt-Fehler bei %s@%s\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Authentifikationsfehlschlag bei %s@%s%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr " (vormals authorisiert)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: Fetchmail: Authentifikation fehlgeschlagen bei %s@%s\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail konnte keine Mail von %s@%s erhalten.\n"
+
+#
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Der Versuch zur Authentifikation scheiterte.\n"
+"Da wir bereits erfolgreiche Authentifikationen für diese Verbindung "
+"durchgeführt\n"
+"habem, ist dies vermutlich ein anderer Fehler (wie z. B. ein beschäftigter\n"
+"Server), den fetchmail nicht unterscheiden kann, weil der Server keine\n"
+"brauchbare Fehlermeldung geliefert hat.\n"
+"\n"
+"Wenn Sie allerdings tatsächlich die Details Ihres Accounts geändert haben, "
+"seit\n"
+"Sie den fetchmail-Dämonen starteten, dann müssen Sie den Dämonen beenden, "
+"die\n"
+"Konfiguration ändern und den Dämonen neu starten.\n"
+"\n"
+"Der fetchmail-Dämon wird weiterhin laufen und bei jedem Durchgang "
+"versuchen,\n"
+"eine Verbindung herzustellen. Es werden bis zur Wiederherstellung des "
+"Service\n"
+"keine weiteren Meldungen gesendet."
+
+#
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Der Versuch zur Authentifikation scheiterte.\n"
+"Das bedeutet vermutlich, dass Ihr Passwort nicht stimmt, doch manche Server\n"
+"haben andere Fehlerbedingungen, die fetchmail nicht von dieser "
+"unterscheiden\n"
+"kann, da sie keine brauchbare Fehlermeldung liefern.\n"
+"\n"
+"Der fetchmail-Dämon wird weiterhin laufen und bei jedem Durchgang "
+"versuchen,\n"
+"eine Verbindung herzustellen. Es werden bis zur Wiederherstellung des "
+"Service\n"
+"keine weiteren Meldungen gesendet."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr "Sofortige erneute Abfrage von %s@%s\n"
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Unbekannter Einlogg- oder Authentifikationsfehler bei %s@%s\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Authentifikation OK bei %s@%s\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: Fetchmail: Authentifikation OK bei %s@%s\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail war in der Lage, sich bei %s@%s einzuloggen.\n"
+
+#
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "Der Service ist wieder hergestellt.\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "Ordner %s wird gewählt oder erneut abgefragt\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "Vorgabe-Ordner wird gewählt oder erneut abgefragt\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s bei %s (Ordner %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s bei %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Frage %s ab\n"
+
+#: driver.c:1362
+#, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d %s) für %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "Nachrichten"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "Nachricht"
+
+#: driver.c:1366
+msgid "seen"
+msgstr "gesehen"
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s für %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d Oktetts).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "Keine Post für %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "ungültige Nachrichtenanzahl!"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "Socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "fehlende oder fehlerhafte RFC822-Kopfzeile"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "Klient/Server-Synchronisation"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "Klient/Server-Protokoll"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "Lock auf Server beschäftigt"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "SMTP-Transaktion"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "DNS-Nachschlag"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "undefinierter Fehler\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "%s-Fehler bei Auslieferung zu SMTP-Host %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "%s-Fehler beim Abholen von %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "Nach-Verbindungs-Befehl scheiterte mit Status %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Kerberos-V4-Unterstützung nicht vorhanden.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Kerberos-V5-Unterstützung nicht vorhanden.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Option --flush ist mit %s nicht unterstützt\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Option --all ist mit %s nicht unterstützt\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Option --limit ist mit %s nicht unterstützt\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: Die QMAILINJECT-Umgebungsvariable ist gesetzt.\n"
+"Das ist gefährlich, da es qmail-inject oder den Sendmail-Wrapper von qmail "
+"dazu\n"
+"veranlassen kann, an Ihren From:- oder Message-ID:-Headern herumzudoktern.\n"
+"Versuchen Sie es mit „env QMAILINJECT= %s <Argumente> <kommen> <hier>“\n"
+"%s: Abbruch.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: Die NULLMAILER_FLAGS-Umgebungsvariable ist gesetzt.\n"
+"Das ist gefährlich, da es nullmailer-inject oder den Sendmail-Wrapper von\n"
+"nullmailer dazu veranlassen kann, an Ihren From:-, Message-ID:- oder\n"
+"Return-Path:-Headern herumzudoktern.\n"
+"Versuchen Sie es mit „env NULLMAILER_FLAGS= %s <Argumente> <kommen> <hier>“\n"
+"%s: Abbruch.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Sie existieren nicht.  Hinfort!\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: kann Ihren Host nicht bestimmen!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "gethostbyname fehlgeschlagen für %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "%ss SMTP-Lauscher unterstützt ESMTP nicht\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "%ss SMTP-Lauscher unterstützt ETRN nicht\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Einreihen für %s begonnen\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Keine wartenden Nachrichten für %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Schwebende Nachrichten für %s begonnen\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Kann keine Nachrichten einreihen für Knoten %s\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Knoten %s nicht erlaubt: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "ETRN-Syntaxfehler\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "ETRN-Syntaxfehler in Parametern\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Unbekannter ETRN-Fehler %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "Option --keep ist mit ETRN nicht unterstützt\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "Option --flush ist mit ETRN nicht unterstützt\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "Option --remote ist mit ETRN nicht unterstützt\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "Option --check ist mit ETRN nicht unterstützt\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: aufgerufen mit"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "konnte aktuelles Arbeitsverzeichnis nicht bestimmen\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Dies ist fetchmail Version %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Erhalte Optinen von Kommandozeile%s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " und "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "Keine Mailserver konfiguriert -- vielleicht fehlt %s?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: es wurden keine Mailserver spezifiziert.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: kein weiteres fetchmail läuft\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: Fehler beim Abschießen von %s-fetchmail bei %d; Abbruch.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "Hintergrund"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "Vordergrund"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %s-fetchmail bei %d abgeschossen.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: kann Mail nicht abholen, solange auf dem Rechner ein weiteres "
+"fetchmail läuft.\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: kann spezifizierte Hosts nicht abfragen, solange ein weiteres "
+"fetchmail läuft bei %d.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: ein weiteres Vordergrund-fetchmail läuft bei %d.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: kann keine Optionen akzeptieren, solange Hintergrund-fetchmail "
+"läuft.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: Hintergrund-fetchmail bei %d aufgeweckt.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: älteres Geschwister bei %d ist mysteriös gestorben.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: kann kein Passwort für %s@%s finden.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Geben Sie das Passwort für %s@%s ein: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "fetchmail %s Dämon wird gestartet \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "konnte %s nicht öffnen, um Logs anzuhängen \n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "konnte keine Zeitüberprüfung bei %s durchführen (Fehler %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "starte fetchmail erneut (%s verändert)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+"Versuch, fetchmail erneut auszuführen, kann fehlschlagen,\n"
+"da Verzeichnis nicht wieder hergestellt wurde\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "Versuch, fetchmail erneut auszuführen, fehlgeschlagen\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"Abfrage von %s übersprungen (fehlgeschlagene Authentifikation oder zu viele "
+"Zeitüberschreitungen)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "Intervall nicht erreicht, %s wird nicht abgefragt\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Abfragestatus=0 (SUCCESS)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Abfragestatus=1 (NOMAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Abfragestatus=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Abfragestatus=3 (AUTHFAIL)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Abfragestatus=4 (PROTOCOL)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Abfragestatus=5 (SYNTAX)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "Abfragestatus=6 (IOERR)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "Abfragestatus=7 (ERROR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Abfragestatus=8 (EXCLUDE)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Abfragestatus=9 (LOCKBUSY)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "Abfragestatus=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "Abfragestatus=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Abfragestatus=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Abfragestatus=13 (MAXFETCH)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Abfragestatus=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Alle Verbindungen verkeilt. Abbruch.\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "schlafe um %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "erweckt durch %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "erweckt durch Signal %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "erweckt um %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "normaler Beendigung, Status %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "konnte keine Zeitüberprüfung der Run-Control-Datei durchführen\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr "Warnung: mehrfache Erwähnung von Host %s in Konfigurationsdatei\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "SSL-Unterstützung ist nicht einkompiliert.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: Warnung: Kein DNS verfügbar, um Multidrop-Abholung von %s zu "
+"überprüfen\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "%s-Konfiguration ungültig, Portnummber kann nicht negativ sein\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "%s-Konfiguration ungültig, RPOP erfordert einen privilegierten Port\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"%s-Konfiguration ungültig, LMTP kann nicht den Standard-SMTP-Port benutzen\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr ""
+"Sowohl „fetchall“ als auch „keep“ anzuschalten ist im Daemon-Modus ein "
+"Fehler!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "beendet mit Signal %d\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s fragt ab %s (Protokoll %s) um %s: Abfrage gestartet\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "POP2-Unterstützung ist nicht konfiguriert.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "POP3-Unterstützung ist nicht konfiguriert.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "IMAP-Unterstützung ist nicht konfiguriert.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "ETRN-Unterstützung ist nicht konfiguriert.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "Kann ETRN nicht unterstützen ohne gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "ODMR-Unterstützung ist nicht konfiguriert.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "Kann ODMR nicht unterstützen ohne gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "nicht unterstütztes Protokoll ausgewählt.\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s fragt ab %s (Protokoll %s) um %s: Abfrage beendet\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "Abfrageintervall ist %d Sekunden\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Log-Datei ist %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Idfile ist %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Fortschrittsnachrichten werden via syslog geloggt\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail wird maskieren und kein „Received“ generieren\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr "Fetchmail wird Fortschrittspunkte auch in Log-Dateien zeigen.\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr ""
+"Fetchmail wird fehladressierte Multidrop-Nachricht an %s weiterleiten.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Fetchmail wird Fehlerbenachrichtigungen an „postmaster“ schicken.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail wird Fehlerbenachrichtigungen and den Absender schicken.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Optionen für Abholen von %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Post wird abgeholt via %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  Abfrage dieses Servers wird alle %d Intervalle erfolgen.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Wahrer Name des Servers ist %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr "  Dieser Host wird%sabgefragt, wenn kein Host angegeben ist.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr " nicht "
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr " "
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Nach Passwörtern wird nachgefragt.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  APOP-Geheimnis = „%s“.\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  RPOP id = „%s“.\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Passwort = „%s“.\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  Protokoll ist KPOP mit Kerberos-%s-Authentifikation"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  Protokoll ist %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (unter Benutzung von Service %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (unter Benutzung der Netzwerk-Sicherheitsoptionen %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (unter Benutzung des Ports %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (unter Benutzung des Standard-Ports)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (erzwungene UIDL-Benutzung)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  Alle vefügbaren Authentifikationsmehtoden werden versucht.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  Passwort-Authentifikation wird erzwungen.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  NILM-Authentifikation wird erzwungen.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  OTP-Authentifikation wird erzwungen.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  CRAM-Md5-Authentifikation wird erzwungen.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  GSSAPI-Authentifikation wird erzwungen.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Kerberos-V4-Authentifikation wird erzwungen.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Kerberos-V5-Authentifikation wird erzwungen.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  End-zu-End-Verschlüsselung wird angenommen.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  Prinzipal des Mailservice ist: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  SSL-verschlüsselte Sitzungen ermöglicht.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  SSL-Protokoll: %s.\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  SSL-Server-Zertifikat-Überprüfung ermöglicht.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  SSL-Verzeichnis für vertrauenswürdige Zertifikate: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr "  SSL-Schlüssel-Fingerabdruck (gegen Server-Schlüssel überprüft): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  Auszeit für nichtantwortenden Server ist %d Sekunden"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (Voreinstellung).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Standard-Postfach ausgewählt.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Gewählte Postfächer sind:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s Nachrichten werden abgeholt (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "Alle"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "Nur neue"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Abgeholte Nachrichten werden%sauf dem Server belassen (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+"  Alte Nachrichten werden%svor der Nachrichtenabholung geflusht (--flush %"
+"s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  Umschreiben von server-lokalen Adressen ist %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "eingeschaltet"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "abgeschaltet"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  Entfernen von Carriage-Return-Zeichen ist %s (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Erzwingen von Carriage-Return-Zeichen ist %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+"  Interpretation von Content-Transfer-Encoding ist %s (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  MIME-Dekodierung ist %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  „Idle“ nach Abfrage ist %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Nichtleere Statuszeilen werden %s (dropstatus %s)\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "verworfen"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "aufgehoben"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Delivered-To-Zeilen werden %s (dropdelivered %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  Nachrichtengößen-Beschränkung ist %d Oktetts (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  Keine Beschränkung der Nachrichtengöße (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr "  Nachrichtengöße-Warnungsintervall ist %d Sekunden (--warnings %d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr "  Größenwarnungen bei jeder Abfragen (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  Limit für erhaltene Nachrichten ist %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  Kein Limit für erhaltene Nachrichten (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  Limit für erhaltene Nachrichten ist %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Keine Beschränkung der Nachrichtengöße (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  Limit für SMTP-Stapelauslieferung ist %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  Kein Limit für SMTP-Stapelauslieferung (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+"  Anzahl der Löschvorgänge zwischen tatsächlichen Säuberungen auf %d gesetzt "
+"(--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Keine erzwungenen Säuberungen (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Domänen, für die Mail abgeholt werden wird, sind:"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (Voreinstellung)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Nachrichetn werden an %s als BSMTP angehängt\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Nachrichetn werden mit „%s“ ausgeliefert.\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Nachrichten werden mit %cMTP weitergeleitet an:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  Host-Teil der „MAIL FROM“-Zeile ist %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr ""
+"  Adresse, die in „RCPT TO“-Zeilen, die an SMTP ausgeliefert werden, "
+"verwendet wird, ist %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Erkannte Spam-Abblock-Antworten des Lauschers sind:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Spam-Abblocken deaktiviert\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  Server-Verbindung wird aktiviert mit „%s“.\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Kein Vor-Verbindungs-Befehl.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  Server-Verbindungs wird beendet mit „%s“.\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Kein Nach-Verbindungs-Befehl.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Keine lokalen Namen (localnames) für diesen Host definiert.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Multi-Drop-Modus: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Einzel-Drop-Modus: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d lokale Namen erkannt.\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  DNS-Nachschlag für Multi-Drop-Adressen ist %s.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr "  Server-Aliase werden mit multidrop-Adressen verglichen anhand "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "der IP-Adresse.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "des Namens.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  Umschlag-Adress-Routing is deaktiviert\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Umschlag-Header wird angenommen als: %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Erhalten"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Anzahl der zu lesenden Umschlag-Header: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Präfix %s wird von Nutzer-ID entfernt\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  Keine Präfix-Entfernung\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Vordeklarierte Mailserver-Aliase:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Lokale Domänen:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  Verbindung muss durch Schnittstelle %s geschehen.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Kein Schnittstellen-Bindung angefordert.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Abfrageschleife wird %s überwachen.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Kein Ãœberwachungsinterface angegeben.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr ""
+"  Serververbindungen werden mittels Plugin %s durchgeführt (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Kein Plugin-Befehl angegeben.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  Lauscher-Verbindungen werden mittels Plugout %s durchgeführt (--plugout %"
+"s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Kein Plugout-Befehl angegeben.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Keine UIDs von diesem Host gespeichert.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d UIDs gespeichert.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+"  Abfrage-Nachverfolgungsinformationen werden dem Received-Header "
+"hinzugefügt.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  Keine Abfrage-Nachverfolgungsinformationen werden dem Received-Header\n"
+"  hinzugefügt.\n"
+".\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Eigenschaften zum Durchleiten „%s“.\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "alloca fehlgeschlagen"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "FEHLER: getpassword()-Routine wird nicht unterstützt\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"SIGINT erhalten... steige aus.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Konnte Servicenamen für [%s] nicht bestimmen\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "Benutze Servicenamen [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Schicke Beglaubigungen\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Fehler beim Austausch der Beglaubigungen\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Konnte Sicherheitsstufendaten nicht ermitteln\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Beglaubigungsaustausch vollzogen\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Server erfordert Integrität und/oder Privatsphäre\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Ermittelte Sicherheitsstufen-Flags: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "Maximale GSS-Tokengröße is %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Fehler beim Erstellen der Sicherheitsstufenanfrage\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Gebe GSS-Beglaubigungen frei\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Fehler beim Freigeben der Beglaubigungen\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: Thread schläft für %d Sek.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protokoll identifiziert als IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protokoll identifiziert als IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protokoll identifiziert als IMAP2 oder IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "werde nach Abfrage untätig sein\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "Benötigte OTP-Fähigkeit nicht in fetchmail einkompiliert\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Benötigte NTLM-Fähigkeit nicht in fetchmail einkompiliert\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Benötigte NTlM-Fähigkeit nicht vom Server unterstützt\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "Säubern fehlgeschlagen\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "erneute Abfrage fehlgeschlagen\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "%d Nachrichten warten nach der erneuter Abfrage\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "Postfach-Auswahl fehlgeschlagen\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "%d Nachrichten warten nach der ersten Abfrage\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "%d Nachrichten warten nach Säuberung\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "Suche nach ungesehenen Nachrichten fehlgeschlagen\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u ist ungesehen\n"
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr "%u ist erste ungesehene\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"Kann kvm-Schnittstelle nicht öffnen. Stellen Sie sicher, dass fetchmail mit "
+"SGID kmem läuft."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "Kann Interfacenamen nicht aus %s lesen"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: sysctl (iflist-Schätzung) fehlgeschlagen"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: malloc fehlgeschlagen"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: sysctl (iflist) fehlgeschlagen"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "Routing-Nachricht Version %d nicht verstanden."
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "Kein Schnittstelle mit dem Namen %s gefunden"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "Keine IP-Adresse für %s gefunden"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "fehlende IP-Adresse\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "ungültige IP-Schnittstellen-Adresse\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "ungültige IP-Schnittstellen-Maske\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "Aktivität auf %s -festgestellt- als %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "überspringe Abfrage von %s, %s ist aus\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "überspringe Abfrage von %s, %s IP-Adresse ausgeschlossen\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "Aktivität auf %s überprüft als %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "überspringe Abfrage von %s, %s inaktiv\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "Aktivität auf %s war %d, ist %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "konnte initiale BASE64-Herausforderung nicht dekodieren\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "Principal %s im Ticket stimmt nicht überein mit -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "Nicht-Null-Instanz (%s) könnte merkwürdiges Verhalten hervorrufen\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "konnte BASE64-Bestätigungs-Erwiderung nicht dekodieren\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "Herausforderung stimmt nicht überein\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: entferne alte Lockdatei\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: Lock-Herstellung fehlgeschlagen.\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "Warnung: fand „%s“ vor irgendwelchen Hostnamen"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: Warnung: fand „%s“ vor irgendwelchen Hostnamen\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: Warnung: unbekanntes Token „%s“\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "%ss SMPT-Lauscher unterstützt ATRN nicht\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "Jetzt umgedreht...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "ATRN-Anfrage abgelehnt.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "Kann ATRN-Anfrage jetzt nicht bearbeiten\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "Sie haben keine Post.\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Befehl nicht implementiert\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Authentifikation erforderlich.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Unbekannter ODMR-Fehler %d\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "Option --keep ist mit ODMR nicht unterstützt\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "Option --flush ist mit ODMR nicht unterstützt\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "Option --remote ist mit ODMR nicht unterstützt\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "Option --check ist mit ODMR nicht unterstützt\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "Server recv fatal\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Konnte OTP-Herausforderung nicht dekodieren\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Geheime Passphrase: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "Zeichkette „%s“ ist keine gültige Zahl.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "Wert der Zeichnkette „%s“ ist %s als %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "kleiner"
+
+#: options.c:211
+msgid "larger"
+msgstr "größer"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Ungültiges Protokoll „%s“ angegeben.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Ungültige Authentifikation „%s“ angegeben.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: Netzwerksicherheit-Unterstützung ist abgeschaltet\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "Aufruf:  fetchmail [Optionen] [Server ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Optionen sind wir folgt:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        diese Options-Hilfe anzeigen\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     Versionsinformationen anzeigen\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       auf Nachrichten überprüfen, ohne abzuholen\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      schweigsam arbeiten\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     redselig arbeiten (diagnostische Ausgaben)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      alle n Sekunden als Dämon laufen\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    nicht von Dämon-Prozess ablösen\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        Dämon-Prozess abschießen\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     Logdatei-Name angeben\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      als Dämon syslog(3) für die meisten Mitteilungen "
+"verwenden\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   Received nicht schreiben und Host-Spoofing erlauben\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc alternative Konfigurationsdatei angeben\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      alternative UID-Datei angeben\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr ""
+"      --postmaster  Empfänger angeben, der als letzte Zuflucht gebraucht "
+"wird\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr "      --nobounce    Bounces vom Nutzer zum Postmaster umleiten\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   erforderliche Schnittstellen-Angabe\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     Schnittstelle auf Aktivität hin beobachten\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         SSL-verschlüsselte Sitzung ermöglichen\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      SSL-Privater-Schlüssel-Datei\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     SSL-Klienten-Zertifikat\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      --sslproto    SSL-Protokoll erzwingen (SSL2/SSL3/TLS1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr "      --plugin      externes Kommando zum Öffnen der Verbindung\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr "      --plugout     externes Kommando zum Öffnen der SMTP-Verbindung\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr "  -p, --protocol    Abhol-Protokoll angeben (siehe Manpage)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        Benutzung von UIDLs erzwingen (nur POP3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr ""
+"  -P, --port        TCP/IP-Service-Port, zu dem verbunden werden soll\n"
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr ""
+"      --auth        Authentifikations-Typ (Passwort/Kerberos/SSH/OTP)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     Auszeit für nichtantwortenden Server\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    Umschlag-Adress-Header\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+"  -Q, --qvirtual    Präfix, der von lokaler Nutzerkennung entfernt wird\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   Prinzipal des Mailservice\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+"      --tracepolls  Poll-Tracing-Information zum Received-Header hinzufügen\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    Nutzerkennung beim Server angeben\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         alte und neue Nachrichten abholen\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      neue Nachrichten nach Abholung löschen\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        neue Nachrichten nach Abholung aufheben\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       alte Nachrichten auf dem Server löschen\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   Header-Adressen nicht umschreiben\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -l, --limit       Nachrichten über angegebener Größe nicht abholen\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    Intervall zwischen Warnungs-Emails\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec       IP-Sicherheits-Anfrage setzen\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    SMTP-Weiterleitungs-Host festlegen\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr "      --fetchdomains  Post für angegebene Domänen abholen\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr "  -D, --smtpaddress zu benutzende SMTP-Auslieferungs-Domäne setzen\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr "      --smtpname    SMTP-Nutzernamen nutzer@domain setzen\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    Antispam-Antwort-Werte setzen\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr "  -b, --batchlimit  Stapellimit für SMTP-Verbindungen setzen\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr "  -B, --fetchlimit  Limit für Server-Verbindungen setzen\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr "      --fetchdomains  Post für angegebene Domänen abholen\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr "  -e, --expunge     max. Löschungen zwischen Säuberungen setzen\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         MDA für Weiterleitung setzen\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       Ausgabe-BSMTP-Datei setzen\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        LMTP (RFC2033) zum Ausliefern benutzen\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      Namen des entfernten Ordners angeben\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr "      --showdots    Fortschrittspunkte auch in Log-Dateien zeigen\n"
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "Erforderlicher APOP-Zeitstempel nicht in Begrüßung gefunden\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Zeitstempel-Syntax-Fehler in Begrüßung\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Anfrage nach undefiniertem Protokoll in POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "Lock beschäftigt!  Ist eine weitere Sitzung aktiv?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr "Nachrichten in Liste auf Server eingefügt. Kann damit nicht umgehen.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "Protokollfehler\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "Protokollfehler beim Holen der UIDLs\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "Option --remote wird mit POP3 nicht unterstützt\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "Server-Optionen nach Nutzer-Optionen"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "SDPS nicht ermöglicht."
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "ungültige Sicherheits-Anfrage"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "Netzwerk-Sicherheits-Unterstützung abgeschaltet"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: Schnittstellen-Option wird nur unter Linux (ohne IPv6) und "
+"FreeBSD unterstützt\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: Beobachtungs-Option wird nur unter Linux (ohne IPv6) und FreeBSD "
+"unterstützt\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "SSL ist nicht ermöglicht"
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "Ende der Eingabe"
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "Datei %s muss eine reguläre Datei sein.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "Datei %s darf nicht mehr Zugriffrechte haben als -rwx--x-- (0710).\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "Datei %s muss Ihnen gehören.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Unbekannter Systemfehler"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (Log-Meldung unvollständig)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "Überlauf des Puffers für Teilmeldungen"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "Dabei, %s umzuschreiben"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "Umgeschriebene Version ist %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Erfolg"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Eingeschränkter Nutzer (irgendwas mit Account nicht in Ordnung)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "Ungültige Nutzer-ID oder Passphrase"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "Gottheits-Fehler"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "RPA-Token 2: Fehler beim Base64-Dekodieren\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Service wählte RPA-Version %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Service-Herausforderung (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Service-Zeitstempel %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "RPA-Token-2-Längenfehler\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Liste der Reiche: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "RPA-Fehler in service@reich-Zeichenkette\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA-Token 4: Fehler beim Base64-Dekodieren\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Nutzer-Authentifikation (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "RPA-Status: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "RPA-Token-4-Längenfehler\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA lehnt Sie ab: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA lehnt Sie ab, Grund unbekannt\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "RPA Nutzerauthentifikations-Längenfehler: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "RPA Sitzungsschlüssel-Längenfehler: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "RPA _Service_ Authentifikations-Fehlschlag. Server beschwindeln?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Sitzungsschlüssel vereinbart:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "RPA-Authentifikation abgeschlossen\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Hole Erwiderung\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Hole Erwiderung liefert %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "Hdr nicht 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "Token-Längenfehler\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "Tokenlänge %d stimmt nicht mit rxlen %d überein\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Mechanismus-Feld inkorrekt\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "Fehler in dec64 bei Zeichen %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Eingehende binäre Daten:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Ausgehende Daten:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "RPA Zeichnkette zu lang\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA Kann /dev/urandom nicht öffnen. Das sollte Sie nicht\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    davon abhalten, sich einzuloggen, heißt aber, dass Sie\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    nicht sicher sein können, mit dem Service zu reden, mit\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    dem Sie zu reden denken. (Wiedergabe-Angriffe durch einen\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    unehrlichen Host sind möglich.\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Nutzerherausforderung:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "MD5 wird auf Datenblock angewandt:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "MD5-Resultat ist: \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "weitergeleitet an %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (Körper der Umleitungs-Nachricht)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "Post von %s umgeleitet zu %s\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "Gespeicherter Fehler ist immer noch %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "%cMTP-Fehler: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "BSMTP Datei öffnen oder Präambel schreiben fehlgeschlagen\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "%cMTP-Lauscher mag Empfängeradresse „%s“ nicht\n"
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "%cMTP-Lauscher mag Empfänger-Adresse „%s“ irgendwie nicht\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "keine Adressen stimmten überein; kein Postmaster gesetzt.\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "kann noch nicht einmal an %s senden!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "keine Adressen stimmten überein; leite an %s weiter.\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "dabei, auszuliefern mit: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "MDA Öffnen fehlgeschlagen\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "%cMTP-Verbindung zu %s fehlgeschlagen\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "kann Lauscher nicht erreichen; falle zurück auf %s"
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr "MDA starb durch Signal %d\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "MDA gab Status %d ungleich Null zurück\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr ""
+"Merkwürdig: MDA pclose gab %d zurück, kann das nicht behandeln bei %s:%d\n"
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Nachrichtenbeendung oder Schließen der BSMTP-Datei fehlgeschlagen\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "SMTP-Lauscher verweigerte Auslieferung\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "LMTP-Auslieferungsfehler bei EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Unerwartete Nicht-503-Erwiderung auf LMTP EOM: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tDer Fetchmail-Dämon\n"
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "ESMTP-CRAM-MD5-Authentifikation...\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "Server lehnte AUTH-Befehl ab.\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "Ungültige base64-Antwort vom Server.\n"
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "Herausforderung dekodiert: %s\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "ESMTP-PLAIN-Authentifikation...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "ESMTP-LOGIN-Authentifikation...\n"
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr "Protokollfehler im SMTP-Lauscher\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: malloc fehlgeschlagen\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail socketpair fehlgeschlagen\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: fork fehlgeschlagen\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "dup2 fehlgeschlagen\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "benutze %s (Host %s, Service %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "execvp(%s) fehlgeschlagen\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: illegale Adresslänge empfangen für Host %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Herausgeber-Organisation: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+"Warnung: Herausgeber-Organisations-Name zu lang (möglicherweise "
+"beschnitten).\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "Unbekannte Organisation\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "Herausgeber-CommonName: %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+"Warnung: Herausgeber-CommonName zu lang (möglicherweise beschnitten).\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "Unbekannter Herausgeber-CommonName\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Server-CommonName: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "Ungültiges Zertifikat: Server-CommonName zu lang!\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "Server-CommonName stimmt nicht überein: %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr "Server-Name nicht gesetzt, konnte Zertifikat nicht verifizieren!\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "Unbekannter Server-CommonName\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "Server-Name nicht in Zertifikat spezifiziert!\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "EVP_md5() fehlgeschlagen!\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "Kein Speicher mehr frei!\n"
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "Textpuffer für Digest zu klein!\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "%s-Schlüssel-Fingerabdruck: %s\n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "%s-Fingerabdrücke stimmen überein.\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "%s-Fingerabdrücke stimmen nicht überein!\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "Warnung: Server-Zertifikat-Überprüfung: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "unbekannter Herausgeber (erste %d Zeichen): %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Datei-Deskriptor außerhalb des Bereichs für SSL"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr ""
+"Ungültiges SSL-Protokoll „%s“ angegeben, benutze Voreinstellung (SSLv23).\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr "Zertifikat-/Fingerabdruck-Überprüfung wurde irgendwie übersprungen!\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr "Cygwin-Socket-Lese-Wiederholung\n"
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr "Cygwin-Socket-Lese-Wiederholung fehlgeschlagen!\n"
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s auf lokal %s abegebildet\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "passierte %s und passte auf %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"Received-Zeile wird überprüft:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "Zeile akzeptiert, %s ist ein Alias des Mailservers\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "Zeile abgelehnt. %s ist kein Alias des Mailservers\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "keine „Received“-Adresse gefunden\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "„Received“-Adresse „%s“ gefunden\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "Nachrichtentrenner gefunden beim Scannen der Kopfzeilen\n"
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "inkorrekte Kopfzeile gefunden beim Scannen der Kopfzeilen\n"
+
+#: transact.c:554
+#, c-format
+msgid "line: %s"
+msgstr "Zeile: %s"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "keine lokalen Ãœbereinstimmungen, Weiterleitung an %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "Weiterleiten und Löschen wegen DNS-Fehlern unterdrückt\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "schreibe RFC822 msgblk.headers\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "keine Empfängeradresse stimmt mit deklarierten lokalen Namen überein"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "Empfängeradresse %s stimmt mit keinem lokalen Namen überein"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "Nachricht hat eingebettete NUL-Zeichen"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "SMTP-Lauscher lehnte Adressen mit lokalem Empfänger ab: "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "Nachrichtentext wird geschrieben\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "Alte UID-Liste aus %s:"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <leer>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Leere UID-Liste:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, fuzzy, c-format
+msgid "Merged UID list from %s:"
+msgstr "Alte UID-Liste aus %s:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "Neue UID-Liste aus %s:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "UID-Listen werden ausgetauscht\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr ""
+"UID-Listen werden nicht ausgetauscht, in dieser Abfrage keine UIDs gesehen\n"
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "UID-Listen werden ausgetauscht\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "Datei fetchids wird gelöscht.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "Datei fetchids wird geschrieben.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "malloc fehlgeschlagen\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "realloc fehlgeschlagen\n"
diff --git a/po/el.gmo b/po/el.gmo
new file mode 100644
index 00000000..3a6b29fd
--- /dev/null
+++ b/po/el.gmo
diff --git a/po/el.po b/po/el.po
new file mode 100644
index 00000000..421975fc
--- /dev/null
+++ b/po/el.po
@@ -0,0 +1,2849 @@
+# Greek Translation of Fetchmail.
+# Copyright (C) 2003 Free Software Foundation, Inc.
+# Dokianakis Theofanis <madf@hellug.gr>, 2003.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 6.2.2\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2003-05-06 01:03+0300\n"
+"Last-Translator: Dokianakis Theofanis <madf@hellug.gr>\n"
+"Language-Team: Greek <nls@tux.hellug.gr>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=ISO-8859-7\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "¸ëåã÷ïò åÜí ôï %s åßíáé ðñÜãìáôé ï ßäéïò êüìâïò ìå ôïí %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Íáé, ïé IP äéåõèýíóåéò ôïõò ôáéñéÜæïõí\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "¼÷é, ïé IP äéåõèýíóåéò ôïõò äåí ôáéñéÜæïõí\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr ""
+"ç áíáæÞôçóç ôïõ `%s' áðÝôõ÷å (óöÜëìá äéá÷åéñéóôÞ ïíïìÜôùí), êáôá ôçí\n"
+"óõãêÝíôñùóç áëëçëïãñáößáò  ãéá ôï %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "áäõíáìßá áðïêùäéêïðïßçóçò ôçò BASE64 ðñüêëçóçò\n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "áðïêùäéêïðïéÞèçêå óáí %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "óöÜëìá kerberos %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [ï äéá÷åéñéóôÞò ëÝåé '%*s'] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Subject: Ðñïåéäïðïßçóç fetchmail õðåñìåãÝèïõò-ìçíõìÜôùí.\n"
+"\n"
+"Ôá áêüëïõèá õðåñâïëéêïý ìåãÝèïõò ìçíýìáôá ðáñáìÝíïõí óôï äéá÷åéñéóôÞ %s:"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\t%d ìíì %d ìÞêïõò octet ðáñáâëÝèçêáí áðü ôï fetchmail.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "ðáñÜëçøç ìçíýìáôïò %s@%s:%d (%d octets)"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "ðáñÜëçøç ìçíýìáôïò %s@%s:%d (%d octets)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr " (ìÞêïò -1)"
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr " (õðåñöõóéêü ìÝãåèïò)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr "áäõíáìßá ëÞøçò åðéêåöáëßäùí, ìÞíõìá %s@%s:%d (%d octets)\n"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "áíÜãíùóç ìçíýìáôïò %s@%s:%d áðü %d"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d %soctets)"
+
+#: driver.c:606
+msgid "header "
+msgstr "åðéêåöáëßäáò "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d octets óþìáôïò) "
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"ôï ìÞíõìá %s@%s:%d äåí åß÷å ôï áíáìåíüìåíï ìÞêïò(%d ðñáãìáôéêï !=%d "
+"áíáìåíüìåíï)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr "óõãêñáôÞèçêå\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr "äéáãñÜöôçêå\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr "äåí äéáãñÜöôçêå\n"
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+"óå üñéï ëÞøçò %d; %d ìçíýìáôá Ýìåéíáí óôïí äéá÷åéñéóôÞ %s ëïãáñéáóìü%s\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "Ýíá SIGPIPE ðåôÜ÷ôçêå áðü Ýíá MDA Þ áðü óöÜëìá stream socket\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr "ëÞîç ÷ñüíïõ ìåôÜ áðü %d äåýôåñá áíáìïíÞò ãéá óýíäåóç óôïí %s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "ëÞîç ÷ñüíïõ ìåôÜ áðü %d äåýôåñá áíáìïíÞò ãéá ôïí äéá÷åéñéóôÞ %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "ëÞîç ÷ñüíïõ ìåôÜ áðü %d äåýôåñá áíáìïíÞò ãéá ôï %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr ""
+"ëÞîç ÷ñüíïõ ìåôÜ áðü %d äåýôåñá áíáìïíÞò ãéá ôçí áðÜíôçóç ôïõ áêñïáôÞ.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "ëÞîç ÷ñüíïõ ìåôÜ áðü %d äåýôåñá.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Subject: ôï fetchmail âëÝðåé åðáíáëáìâáíüìåíåò ëÞîåéò ïñßùí ÷ñüíïõ\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Ôï fetchmail åßäå ðåñéóóüôåñá áðü %d ëÞîåéò ïñßùí ÷ñüíïõ êáôá ôçí ðñïóðÜèåéá "
+"ãéá ðáñáëáâÞ áëëçëïãñáößáò áðü ôï %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Áõôü ìðïñåß íá óçìáßíåé üôé ï äéá÷åéñéóôÞò áëëçëïãñáößáò óáò Ý÷åé\n"
+"êïëëÞóåé, Þ üôé ï äéá÷åéñéóôÞò SMTP óáò Ý÷åé öñáêÜñåé, Þ ôï áñ÷åßï\n"
+"ãñáììáôïêéâùôßïõ óôï äéá÷åéñéóôÞ Ý÷åé êáôáóôñáöåß áðü Ýíá óöÜëìá ôïõ.\n"
+"Ìðïñåßôå íá åêôåëÝóåôå `fetchmail -v -v' ãéá íá äéáãíþóåôå ôï ðñïâëçìá\n"
+"\n"
+"Ôï fetchmail äåí èá îáíáñùôÞóåé áõôü ôï ãñáììáôïêéâþôéï ìÝ÷ñé íá ôï\n"
+"åðáíåêêéíÞóåôå.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "ç åíôïëÞ ðñï-óýíäåóçò áðÝôõ÷å ìå êáôÜóôáóç %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "áäõíáìßá åýñåóçò HESIOD ôá÷. èõñßäáò ãéá ôï %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Ï åðéêåöáëÞò äéá÷åéñéóôÞò äåí Ý÷åé üíïìá.\n"
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "áäõíáìßá åýñåóçò êáíïíéêïý ïíüìáôïò DNS ôïõ %s\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "åóùôåñéêÞ áóõíÝ÷åéá\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "%s óýíäåóç óôï %s áðÝôõ÷å"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "Üãíùóôïò äéáêïìéóôÞò."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "ôï üíïìá åßíáé Ýãêõñï áëëÜ äåí Ý÷åé äéåýèõíóç IP."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "ìç áíáêôÞóéìï óöÜëìá äéá÷åéñéóôÞ ïíïìÜôùí."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "ðñïóùñéíü óöÜëìá äéá÷åéñéóôÞ ïíïìÜôùí."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "Üãíùóôï óöÜëìá DNS %d."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Subject: Ðñïåéäïðïßçóç áðñïóðÝëáóôïõ-äéáêïìéóôÞ óôï fetchmail.\n"
+"\n"
+"Ôï fetchmail áäõíáôåß íá ðñïóåããßóåé ôï äéáêïìéóôÞ áëëçëïãñáößáò %s:"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "ç óýíäåóç SSL áðÝôõ÷å.\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "ÓöÜëìá lock-busy óôïí %s@%s\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "ÓöÜëìá busy äéáêïìéóôÞ óôïí %s@%s\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Áðïôõ÷ßá åîïõóéïäüôçóçò óôïí %s@%s%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr " (ðñïçãïõìÝíùò åîïõóéïäïôÞèçêå)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: fetchmail áðïôõ÷ßá åîïõóéïäüôçóçò óôï %s@%s\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Áäõíáìßá ôïõ fetchmail ëÞøçò áëëçëïãñáößáò áðü ôï %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"ÁðÝôõ÷å ç ðñïóðÜèåéá ëÞøçò åîïõóéïäüôçóçò.\n"
+"Áöïý Þäç Ý÷åé åðéôõ÷þò ëçöèåß åîïõóéïäüôçóç ãéá áõôÞ ôç óýíäåóç, ßóùò\n"
+"ðñüêåéôå ãéá ìéá áêüìç êáôÜóôáóç áðïôõ÷ßáò (üðùò áðáó÷ïëçìÝíïò äéáêïìéóôÞò)\n"
+"ðïõ ôï fetchmail áäõíáôåß íá îå÷ùñßóåé åðåéäÞ ï äéá÷åéñéóôÞò äåí Ýóôåéëå\n"
+"Ýíá ÷ñÞóéìï ìÞíõìá óöÜëìáôïò.\n"
+"\n"
+"¼ìùò, åÜí Å×ÅÔÅ áëëÜîåé ôéò ëåðôïìÝñåéåò ôïõ ëïãáñéáóìïý óáò áðü ôüôå ðïõ\n"
+"åêêéíÞóáôå ôï äáßìïíá fetchmail, ðñÝðåé íá ôïí óôáìáôÞóåôå, íá áëëÜîåôå ôéò\n"
+"ñõèìßóåéò ôïõ fetchmail, êáé íá ôï åðáíáêêéíÞóåôå.\n"
+"\n"
+"Ï äáßìïíáò fetchmail èá óõíå÷ßóåé íá ôñÝ÷åé êáé èá ðñïóðáèåß íá óõíäåèåß\n"
+"óå êÜèå êýêëï. Äå èá óôáëèïýí ìåëëïíôéêÝò åéäïðïéÞóåéò ìÝ÷ñé íá \n"
+"áðïêáôáóôáèåß ç õðçñåóßá."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"ÁðÝôõ÷å ç ðñïóðÜèåéá ëÞøçò åîïõóéïäüôçóçò.\n"
+"Áõôü ßóùò óçìáßíåé üôé ç ëÝîç êëåéäß åßíáé Üêõñç, áëëÜ ìåñéêïß äéá÷åéñéóôÝò\n"
+"Ý÷ïõí Üëëåò êáôáóôÜóåéò áðïôõ÷ßáò ðïõ ôï fetchmail äåí ìðïñåß íá îå÷ùñßóåé\n"
+"áðü áõôü ãéáôß äå óôÝëíïõí ÷ñÞóéìá ìçíýìáôá óöáëìÜôùí óå áðïôõ÷ßá åéóüäïõ.\n"
+"\n"
+"Ï äáßìïíáò fetchmail èá óõíå÷ßóåé íá ôñÝ÷åé êáé èá ðñïóðáèåß íá óõíäåèåß\n"
+"óå êÜèå êýêëï. Äå èá óôáëèïýí ìåëëïíôéêÝò åéäïðïéÞóåéò ìÝ÷ñé íá\n"
+"áðïêáôáóôáèåß ç õðçñåóßá."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr "Îáíáåñþôçóç áìÝóùò óôï %s@%s\n"
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "¶ãíùóôï óöÜëìá åéóüäïõ Þ åîïõóéïäüôçóçò óôï %s@%s\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Åîïõóéïäüôçóç ðÝôõ÷å óôïí %s@%s\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: åîïõóéïäüôçóç ôïõ fetchmail ðÝôõ÷å óôï %s@%s\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Áäõíáìßá åéóüäïõ ôïõ fetchmail óôï %s@%s.\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "Ç õðçñåóßá áðïêáôáóôÜèçêå.\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "åðéëïãÞ Þ åðáíá-óõãêÝíôñùóç öáêÝëïõ %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "åðéëïãÞ Þ åðáíá-óõãêÝíôñùóç åî'ïñéóìïý öáêÝëïõ\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s óôï  %s (öÜêåëïò %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s óôï  %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "ÓõãêÝíôñùóç áðü %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (åßäå %d) ãéá ôï %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "ìçíýìáôá"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "ìÞíõìá"
+
+#: driver.c:1366
+msgid "seen"
+msgstr ""
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s ãéá ôï %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d octets).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "Äåí õðÜñ÷åé áëëçëïãñáößá ãéá ôï %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "åóöáëìÝíç ìÝôñçóç ìçíõìÜôùí!"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "÷áìÝíç Þ êáêéÜ åðéêåöáëßäá RFC822"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "óõã÷ñïíéóìüò ðåëÜôç/åîõðçñåôçôÞ"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "ðñïôüêïëï ðåëÜôç/åîõðçñåôçôÞ"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "áðáó÷ïëçìÝíï êëåßäïìá óôï äéá÷åéñéóôÞ"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "óõíáëëáãÞ SMTP"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "áíáæÞôçóç DNS"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "ìç ïñéóìÝíï óöÜëìá\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "%s óöÜëìá êáôÜ ôçí áðïóôïëÞ óôï äéáêïìéóôÞ SMTP %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "%s óöÜëìá êáôÜ ôçí ëÞøç áðü ôï %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "ç åíôïëÞ ðñï-óýíäåóçò áðÝôõ÷å ìå êáôÜóôáóç %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Ç õðïóôÞñéîç ãéá Kerberos V4 äåí Ý÷åé óõíäåèåß.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Ç õðïóôÞñéîç ãéá Kerberos V5 äåí Ý÷åé óõíäåèåß.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Ç åðéëïãÞ --flush äåí õðïóôçñßæåôáé ìå ôï %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Ç åðéëïãÞ --all äåí õðïóôçñßæåôáé ìå ôï %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Ç åðéëïãÞ --limit äåí õðïóôçñßæåôáé ìå ôï %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: Ç ìåôáâëçôÞ ðåñéâÜëëïíôïò QMAILINJECT Ý÷åé ïñéóôåß.\n"
+"Áõôü åßíáé åðéêßíäõíï áöïý ìðïñåß íá êÜíåé ôï qmail-inject Þ ôï sendmail\n"
+"wrapper ôïõ qmail íá ðåéñÜîïõí ôéò åðéêåöáëßäåò From: Þ Message-ID:.\n"
+"ÄïêéìÜóôå \"env QMAILINJECT= %s ÔÁ ÏÑÉÓÌÁÔÁ ÓÁÓ ÅÄÙ\"\n"
+"%s: Áêýñùóç.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: Ç ìåôáâëçôÞ ðåñéâÜëëïíôïò NULLMAILER_FLAGS Ý÷åé ïñéóôåß.\n"
+"Áõôü åßíáé åðéêßíäõíï áöïý ìðïñåß íá êÜíåé ôï nullmailer-inject Þ wrapper\n"
+"ôïõ sendmail ôïõ qmail íá ðåéñÜîïõí ôéò åðéêåöáëßäåò From:,Message-ID: Þ\n"
+"Return-Path:.\n"
+"ÄïêéìÜóôå \"env NULLMAILER_FLAGS= %s ÔÁ ÏÑÉÓÌÁÔÁ ÓÁÓ ÅÄÙ\"\n"
+"%s: Áêýñùóç.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Äåí õðÜñ÷åôå.  Öýãåôå ìáêñéÜ.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: áäõíáìßá ðñïóäéïñéóìïý ôïõ óõóôÞìáôïò óáò!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "ç gethostbyname áðÝôõ÷å ãéá ôï %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "ï SMTP áêñïáôÞò ôïõ %s äåí õðïóôçñßæåé ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "ï SMTP áêñïáôÞò ôïõ %s äåí õðïóôçñßæåé ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Åêêßíçóç óõóôïß÷çóçò ãéá ôï %s\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Äåí ðåñéìÝíïõí ìçíýìáôá ãéá ôï %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Åêêßíçóç ôçò åéóáãùãÞò óå áíáìïíÞò ôùí ìçíõìÜôùí ãéá ôï %s\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Áäõíáìßá ôïðïèÝôçóçò óå óåéñÜ ôùí ìçíõìÜôùí ãéá ôï êüìâï %s\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Ï êüìâïò %s äåí åðéôñÝðåôáé: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "Óõíôáêôéêü ëÜèïò ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "Óõíôáêôéêü ëÜèïò ETRN óôéò ðáñáìÝôñïõò\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "¶ãíùóôï óöÜëìá ETRN %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "Ç åðéëïãÞ --keep äåí õðïóôçñßæåôå ìå ôï ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "Ç åðéëïãÞ --flush äåí õðïóôçñßæåôå ìå ôï ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "Ç åðéëïãÞ --remote äåí õðïóôçñßæåôå ìå ôï ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "Ç åðéëïãÞ --check äåí õðïóôçñßæåôå ìå ôï ETRN\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: êáëÝóôçêå ìå"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "áäõíáìßá ëÞøçò ôïõ ôñÝ÷ïíôïò öáêÝëïõ åñãáóßáò (cwd)\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Áõôü åßíáé ôï fetchmail Ýêäïóç %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "ËÞøç ðáñáìåôñùí áðü ôçí ãñáììÞ åíôïëþí%s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " êáé "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr ""
+"Äåí Ý÷ïõí ïñéóôåß äéá÷åéñéóôÝò áëëçëïãñáößáò -- ßóùò ôï %s íá ëåßðåé;\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: äåí Ý÷ïõí ïñéóôåß äéá÷åéñéóôÝò áëëçëïãñáößáò.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: äåí ôñÝ÷åé Üëëï fetchmail\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: óöÜëìá óôç èáíÜôùóç ôïõ %s fetchmail óôï %d; åãêáôÜëåéøç.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "õðüâáèñï"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "ðñïóêÞíéï"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: ôï %s fetchmail óôï %d ôåñìáôßóôçêå.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: áäõíáìßá åëÝã÷ïõ áëëçëïãñáößáò üôáí Ýíá Üëëï fetchmail ôñÝ÷åéóôï "
+"ßäéï óýóôçìá.\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: áäõíáìßá åñþôçóçò ôùí ïñéóìÝíùí äéáêïìéóôþí åíþ ôñÝ÷åé Üëëï\n"
+"           fetchmail óôï %d.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: êÜðïéï Üëëï fetchmail ôñÝ÷åé óôï ðñïóêÞíéï óôï %d.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: åíôïëÝò ìç äåêôÝò üôáí Ýíá fetchmail ôñÝ÷åé óôï ðáñáóêÞíéï.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: áöýðíéóç ðáñáóêçíéáêïý fetchmail óôï %d.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr ""
+"fetchmail: çëéêéùìÝíïò åôåñïèáëåßò áäåñöüò ðÝèáíå ìõóôçñéïäþò óôï %d.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: áäõíáìßá åýñåóç ëÝîçò êëåéäß ãéá ôï %s@%s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "ÐëçêôñïëïãÞóôå ôçí ëÝîç êëåéäß ãéá ôï %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "åêêßíçóç äáßìïíá fetchmail %s \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "áäõíáìßá áíïßãìáôïò ôïõ %s ãéá ðñüóèåóç êáôáãñáöþí óå áõôü \n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "áäõíáìßá åëÝã÷ïõ-þñáò %s (óöÜëìá %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "åðáíåêêßíçóç fetchmail (%s Üëëáîå)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+"ç ðñïóðÜèåéá ãéá åðáíåêê ßóùò áðïôý÷åé áöïý ï öÜêåëïò äåí Ý÷åé "
+"áðïêáôáóôáèåß\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "ç áðüðåéñá ãéá åðáíåêêßíçóç ôïõ fetchmail áðÝôõ÷å\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"ðáñÜâëåøç åñþôçóçò ôïõ %s (áðÝôõ÷å ç åîïõóéïäüôçóç Þ ðïëëÝò ëÞîåéò ÷ñüíïõ)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "ôï äßáëëåéìá äåí Ýöôáóå, äåí ãßíåôå åñþôçóç %s\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=0 (SUCCESS)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=1 (NOMAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=3 (AUTHFAIL)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=4 (PROTOCOL)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=5 (SYNTAX)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=6 (IOERR)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=7 (ERROR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=8 (EXCLUDE)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=9 (LOCKBUSY)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=13 (MAXFETCH)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "ÊáôÜóôáóçò Åñþôçóçò=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "¼ëåò ïé óõíäÝóåéò Ý÷ïõí ìðëïêÜñåé. ÅãêáôÜëåéøç.\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "áäñáíÝò óôï %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "áöõðíßóôçêå áðü ôï %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "áöõðíßóôçêå áðü óÞìá %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "áöõðíßóôçêå óôï %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "öõóéïëïãéêüò ôåñìáôéóìüò, êáôÜóôáóç %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "áäõíáìßá åëÝã÷ïõ-þñáò ôïõ áñ÷åßï run-control\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr ""
+"Ðñïåéäïðïßçóç: ðïëëáðëÝò áíáöïñÝò ôïõ äéáêïìéóôÞ %s óôï áñ÷åßï ñõèìßóåùí\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "ç õðïóôÞñéîç ãéá SSL äåí Ý÷åé ìðåé óôç ìåôÜöñáóç.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: ðñïåéäïðïßçóç: êáíÝíá äéáèÝóéìï DNS ãéá Ýëåã÷ï ëÞøåùí áðü %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr ""
+"ìç Ýãêõñåò ñõèìßóåéò %s, ï áñéèìüò èýñáò äåí ìðïñåß íá åßíáé áñíçôéêüò\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "ìç Ýãêõñåò ñõèìßóåéò %s, ôï RPOP áðáéôåß ðñïíïìéïý÷á èýñá\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"ìç Ýãêõñåò ñõèìßóåéò %s, ôï LMTP äåí êÜíåé ÷ñÞóç ôçò åî ïñéóìïý èýñáò SMTP\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "Åßíáé ëÜèïò ôï fetchall êáé ìáæß ôï ðáñáìïíÞ óå êáôÜóôáóç äáßìïíá!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "Ýëçîå ìå óÞìá %d\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s åñþôçóç %s (ðñùôüêïëëï %s) óôï %s: Üñ÷éóå ç åñþôçóç\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "Äåí Ý÷åé ñõèìéóôåß ç õðïóôÞñéîç POP2.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "Äåí Ý÷åé ñõèìéóôåß ç õðïóôÞñéîç POP3.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "Äåí Ý÷åé ñõèìéóôåß ç õðïóôÞñéîç IMAP.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "Äåí Ý÷åé ñõèìéóôåß ç õðïóôÞñéîç ETRN.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "Áäõíáìßá õðïóôÞñéîçò ETRN ÷ùñßò gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "Äåí Ý÷åé ñõèìéóôåß ç õðïóôÞñéîç ODMR.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "Áäõíáìßá õðïóôÞñéîçò ODMR ÷ùñßò gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "åðéëÝ÷èçêå ìç õðïóôçñéæüìåíï ðñùôüêïëëï.\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s åñþôçóç %s (ðñùôüêïëëï %s) óôï %s: ïëïêëçñþèçêå ç åñþôçóç\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "ÄéÜëëåéìá åñþôçóçò åßíáé %d äåõôåñüëåðôá\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Áñ÷åßï êáôá÷þñéóçò åßíáé ôï %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Áñ÷åßï Id åßíáé ôï %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Ôá ìçíýìáôá ðñïüäïõ èá êáôá÷ùñéèïýí ìÝóù ôïõ syslog\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Ôï fetchmail èá áðïêñõöèåß êáé äå èá ðáñÜãåé Received\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr "Ôï fetchmail èá äåß÷íåé ôåëåßåò ðñïüäïõ êáé óôá áñ÷åßá êáôáãñáöÞò.\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr "Ôï fetchmail èá ðñïùèåß multidrop ìçíýìáôá ìå êáêÞ äéåýèõíóç óôï %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Ôï fetchmail èá äñïìïëïãåß áëëçëïãñáößá óöáëìÜôùí óôï postmaster.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Ôï fetchmail èá äñïìïëïãåß áëëçëïãñáößá óöáëìÜôùí óôï áðïóôïëÝá.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "ÅðéëïãÝò ãéá ëÞøç áðü %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Ç áëëçëïãñáößá èá ëçöèåß ìÝóù ôïõ %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  Åñþôçóç óå áõôü ôï äéá÷åéñéóôÞ èá óõìâåß êÜèå %d äéáëåßìáôá.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Ôï áëçèéíü üíïìá ôïõ äéá÷åéñéóôÞ åßíáé %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr "  Áõôüò ï äéáêïìéóôÞò %s èá åñùôçèåß üôáí äåí Ý÷åé ïñéóôåß êáíÝíáò.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr "'äåí èá"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr "èá"
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Ç ëÝîç êëåéäß èá åñùôÜôå.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  ìõóôéêü APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  RPOP id = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  ËÝîç êëåéäß = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  Ôï ðñùôüêïëëï åßíáé KPOP ìå åîïõóéïäüôçóç Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  Ôï ðñùôüêïëëï åßíáé %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (÷ñÞóç õðçñåóßáò %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (÷ñÞóç åðéëïãþí áóöÜëåéáò äéêôýïõ %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (÷ñçóéìïðïßçóç èýñáò %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (÷ñçóéìïðïßçóç èýñáò åî'ïñéóìïý)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (åîáíáãêáóìüò ÷ñÞóçò UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  ¼ëåò ïé äéáèÝóéìåò ìÝèïäïé åîïõóéïäüôçóçò èá äïêéìáóôïýí.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  Èá åîáíáãêáóôåß ç åîïõóéïäüôçóç ìå ëÝîç êëåéäß.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  Èá åîáíáãêáóôåß ç åîïõóéïäüôçóç NTLM.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  Èá åîáíáãêáóôåß ç åîïõóéïäüôçóç OTP.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  Èá åîáíáãêáóôåß ç åîïõóéïäüôçóç CRAM-Md5.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  Èá åîáíáãêáóôåß ç åîïõóéïäüôçóç GSSAPI.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Èá åîáíáãêáóôåß ç åîïõóéïäüôçóç Kerberos V4.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Èá åîáíáãêáóôåß ç åîïõóéïäüôçóç Kerberos V5.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  ÊñõðôïãñÜöçóç Üêñç-ìå-Üêñç èåùñÞèçêå.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  ÄéåõèõíôÞò õðçñåóßáò áëëçëïãñáößáò åßíáé: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  Åíåñãïðïßçóç êñõðôïãñáöçìÝíùí SSL óõíåäñéþí.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  Ðñùôüêïëëï SSL: %s.\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  Åíåñãïðïßçóç åëÝã÷ïõ ðéóôïðïéçôéêïý äéá÷åéñéóôÞ SSL.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  ÖÜêåëïò åìðéóôåõìÝíïõ ðéóôïðïéçôéêïý SSL: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr "  Áðïôýðùìá êëåéäéïý SSL (óå óýãêñéóç ìå ôï êëåéäß äéá÷åéñéóôÞ): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  ËÞîç ÷ñüíïõ ü÷é-áðÜíôçóçò áðü ôï äéá÷åéñéóôÞ åßíáé %d äåõôåñüëåðôá"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (åî'ïñéóìïý).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Åî ïñéóìïý ãñáììáôïêéâþôéï åðéëÝ÷èçêå.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  ÅðéëåãìÝíá ãñáììáôïêéâþôéá åßíáé:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s ìçíýìáôá èá ëçöèïýí (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "¼ëá"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "Ìüíï ôá íÝá"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  ËçöèÝíôá ìçíýìáôá %s èá êñáôçèïýí óôï äéá÷åéñéóôÞ (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+"  ÐáëéÜ ìçíýìáôá %s èá äéáãñáöïýí ðñéí ôç ëÞøç ìçíõìÜôùí (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr ""
+"  ÅðáíåããñáöÞ ôùí ôïðéêþí-äéá÷åéñéóôÞ äéåõèýíóåùí %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "óå ëåéôïõñãßá"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "åêôüò ëåéôïõñãßáò"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  Áöáßñåóç ôïõ Carriage-return åßíáé %s (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Åîáíáãêáóìüò ôïõ Carriage-return åßíáé %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr "  ÌåôÜöñáóç ôïõ Content-Transfer-Encoding åßíáé %s (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  Áðïêùäéêïðïßçóç MIME åßíáé %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  Çñåìßá ìåôÜ ôçí åñþôçóç åßíáé %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Ïé ãñáììÝò Nonempty Status èá %s (dropstatus %s)\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "áðïññéöèïýí"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "êñáôçèïýí"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Ïé ãñáììÝò Delivered-To èá %s (dropdelivered %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  Ôï üñéï ìåãÝèïõí ìçíýìáôïò åßíáé %d octets (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  ÊáíÝíá üñéï ìåãÝèïõò ìçíýìáôïò (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  Ðåñßïäïò ðñïåéäïðïßçóçò ìåãÝèïõò ìçíýìáôïò åßíáé %d äåýôåñá (--warnings %"
+"d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr "  ÐñïåéäïðïéÞóåéò ìåãÝèïõò óå êÜèå åñþôçóç (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  ¼ñéï ðáñáëçöèÝí-ìçíýìáôïò åßíáé %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  ÊáíÝíá üñéï ðáñáëçöèÝí-ìçíýìáôïò (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  ¼ñéï ðáñáëçöèÝí-ìçíýìáôïò åßíáé %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  ÊáíÝíá üñéï ìåãÝèïõò ìçíýìáôïò (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  ¼ñéï äÝóìçò ìçíýìáôïò SMTP åßíáé %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  ÊáíÝíá üñéï äÝóìçò ìçíýìáôïò SMTP (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+"  Ðåñßïäïò äéáãñáöÞò ìåôáîý åîáëåßøåùí åîáíáãêÜóôçêå óå %d (--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  ÊáììéÜ åîáíáãêáóìÝíç åîÜëåéøç (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Ðåñéï÷Ýò ãéá ôéò ïðïßåò áëëçëïãñáößá èá ëçöèåß åßíáé:"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (åî'ïñéóìïý)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Ôá ìçíýìáôá èá ðñïóôåèïýí óå %s óáí BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Ôá ìçíýìáôá èá äéáíåìçèïýí ìå \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Ôá ìçíýìáôá èá ðñïùèçèïýí %cMTP óå:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  Ôï ìÝñïò äéáêïìéóôÞ ôçò ãñáììÞò MAIL FROM èá åßíáé %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr ""
+"  Äéåýèõíóç ðïõ èá ìðïõí óôéò ãñáììÝò RCPT TO ðïõ áðïóôÝëëïíôáé ìÝóù\n"
+"   SMTP èá åßíáé %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  ÁíáãíùñéóìÝíåò áðáíôÞóåéò ìðëïêáñßóìáôïò spam áêñïáôÞ åßíáé:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Áðåíåñãïðïßçóç ìðëïêáñßóìáôïò-spam\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  Ç óýíäåóç äéá÷åéñéóôÞ èá áñ÷éíÜ ìå \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  ÊáììéÜ åíôïëÞ ðñï-óýíäåóçò.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  Ç óýíäåóç äéá÷åéñéóôÞ èá ôåñìáôßæåôáé ìå \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  ÊáììéÜ åíôïëÞ ìåôÜ-óýíäåóçò.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  ÊáíÝíá ôïðéêü üíïìá äåí ïñßóôçêå ãéá áõôü ôï äéáêïìéóôÞ.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  ÊáôÜóôáóç multi-drop: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  ÊáôÜóôáóç single-drop: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d ôïðéêü üíïìá(ôá) áíáãíùñßóôçêáí.\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  ÁíáæÞôçóç DNS ãéá ôéò äéåõèýíóåéò multidrop åßíáé %s.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr "  Ôá øåõäþíõìá äéá÷åéñéóôÞ èá óõãêñéèïýí ìå äéåõèýíóåéò multidrop ìå "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "äéåýèõíóç IP.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "üíïìá.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  ÁðåíåñãïðïéÞèçêå ç äñïìïëüãçóç Åðéêåöáëßäá-öáêÝëïõ\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "Åðéêåöáëßäá öáêÝëïõ èåùñåßôå íá åßíáé: %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "ÐáñáëÞöèçêå"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Áñéèìüò åðéêåöáëßäáò öáêÝëïõ ðïõ èá åðåîåñãáóôïýí: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Ôï ðñüèåìá %s èá áöáéñåèåß áðü ôï user id\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  ÊáììéÜ áöáßñåóç ðñïèÝìáôïò\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "ÐñïäçëùìÝíá øåõäþíõìá äéá÷åéñéóôÞ-áëëçëïãñáößáò:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  ÔïðéêÝò ðåñéï÷Ýò:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  Ç óýíäåóç ðñÝðåé íá åßíáé ìÝóù ôïõ interface %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Äåí ïñßóôçêáí áðáéôÞóåéò interface.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Âñüã÷ïò åñþôçóçò èá ðáñáêïëïõèåß ôï %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Äåí ïñßóôçêå interface ðáñáêïëïýèçóçò.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr "  ÓõíäÝóåéò äéá÷åéñéóôÞ èá ãßíïõí ìÝóù ôïõ plugin %s (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Äåí ïñßóôçêå åíôïëÞ plugin.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr "  ÓõíäÝóåéò áêñïáôÞ èá ãßíïõí ìÝóù ôïõ plugout %s (--plugout %s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Äåí ïñßóôçêå åíôïëÞ plugout.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Äåí áðïèçêåýôçêáí UID áðü áõôü ôï äéáêïìéóôÞ.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d UID áðïèçêåýôçêáí.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+"  Ðëçñïöïñßåò åíôïðéóìïý åñþôçóçò èá ðñïóôåèåß óôçí åðéêåöáëßäá Received.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  ÊáììéÜ ðëçñïöïñßá åíôïðéóìïý åñþôçóçò äå èá ðñïóôåèåß óôçí åðéêåöáëßäá\n"
+"Received.\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Éäéüôçôåò Pass-through \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "alloca áðÝôõ÷å"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "ÓÖÁËÌÁ: êáììßá õðïóôÞñéîç ãéá ôç ñïõôßíá getpassword()\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"Óýëëçøç SIGINT... åãêáôÜëåéøç.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Áäõíáìßá ëÞøçò ïíüìáôïò õðçñåóßáò ãéá [%s]\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "×ñÞóç ïíüìáôïò õðçñåóßáò [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "ÁðïóôïëÞ äéáðéóôåõôçñßùí\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "ÓöÜëìá óôçí áíôáëëáãÞ äéáðéóôåõôçñßùí\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Áäõíáìßá áðïêÜëõøçò äåäïìÝíùí åðéðÝäïõ áóöÜëåéáò\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Ïëïêëçñþèçêå ç áíôáëëáãÞ äéáðéóôåõôçñßùí\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Ï äéá÷åéñéóôÞò áðáéôåß áêåñáéüôçôá êáé/Þ ìõóôéêüôçôá\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "ÁðïêáëõöèÝíôåò óçìáßåò åðéðÝäïõ áóöÜëåéáò: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "ÌÝãéóôï ìÝãåèïò ôåêìçñßïõ GSS åßíáé %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "ÓöÜëìá óôç äçìéïõñãßá áßôçóçò åðéðÝäïõ áóöÜëåéáò\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "ÁðåëåõèÝñùóç äéáðéóôåõôçñßùí GSS\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "ÓöÜëìá óôçí áðåëåõèÝñùóç äéáðéóôåõôçñßùí\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: áíáìïíÞ íçìÜôùóçò ãéá %d äåõô.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Ôáõôïðïßçóç ðñùôïêüëëïõ óáí IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Ôáõôïðïßçóç ðñùôïêüëëïõ óáí IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Ôáõôïðïßçóç ðñùôïêüëëïõ óáí IMAP2 Þ IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "èá çñåìÞóåé ìåôÜ ôçí åñþôçóç\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "Áðáéôïýìåíç éêáíüôçôá OTP äåí ìåôáãëùôôßóôçêå óôï fetchmail\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Áðáéôïýìåíç éêáíüôçôá NTLM äåí ìåôáãëùôôßóôçêå óôï fetchmail\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Áðáéôïýìåíç éêáíüôçôá LOGIN äåí ìåôáãëùôôßóôçêå óôï fetchmail\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "åîÜëåéøç áðÝôõ÷å\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "åðáíåñþôçóç áðÝôõ÷å\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "%d ìçíýìáôá áíáìÝíïõí ìåôÜ ôçí áðáíåñþôçóç\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "ç åðéëïãÞ ãñáììáôïêéâùôßïõ áðÝôõ÷å\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "%d ìçíýìáôá áíáìÝíïõí ìåôÜ ôçí ðñþôç åñþôçóç\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "%d ìçíýìáôá áíáìÝíïõí ìåôÜ ôçí åîÜëåéøç\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "áíáæÞôçóç ãéá ìç éäùìÝíá ìçíýìáôá áðÝôõ÷å\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u äåí Ý÷åé åéäùèåß\n"
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr "%u åßíáé ôï ðñþôï ìç éäùìÝíï\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"Áäõíáìßá áíïßãìáôïò ôïõ kvm interface. Âåâáéùèåßôå üôé ôï fetchmail\n"
+"åßíáé SGID kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "Áäõíáìßá åðåîåñãáóßáò ôïõ ïíüìáôïò interface áðü ôï %s"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: sysctl (iflist estimate) áðÝôõ÷å"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: malloc áðÝôõ÷å"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: sysctl (iflist) áðÝôõ÷å"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "¸êäïóç ìçíýìáôïò äñïìïëüãçóçò %d äåí ãßíåôáé êáôáíïçôü."
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "Äå âñÝèçêå êáíÝíá interface ìå üíïìá %s"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "Äåí âñÝèçêáí äéåõèýíóåéò IP ãéá ôï %s"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "äåí õðÜñ÷åé äéåýèõíóç IP interface\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "ìç Ýãêõñç äéåýèõíóç IP interface\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "ìç Ýãêõñç IP interface mask\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "äñáóôçñéüôçôá óôï %s -óçìåéþèçêå- óáí %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "ðáñÜâëåøç åñþôçóçò ôïõ %s, ôï %s åßíáé êÜôù\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "ðáñÜâëåøç åñþôçóçò ôïõ %s, ç äéåýèõíóç IP %s áðïêëåßóôçêå\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "äñáóôçñéüôçôá óôï %s åëÝã÷èçêå óáí %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "ðáñÜâëåøç åñþôçóçò ôïõ %s, %s áíåíåñãüò\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "äñáóôçñéüôçôá óôï %s Þôáí %d, åßíáé %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "áäõíáìßá áðïêùäéêïðïßçóçò áñ÷éêÞò ðñüêëçóçò BASE64\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "äéåõèõíôÞò %s óôï åéóéôÞñéï äå ôáéñéÜæåé ôï -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "ç ðåñßðôùóç non-null (%s) ìðïñåß íá ðñïêáëÝóåé ðáñÜîåíç óõìðåñéöïñÜ\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "áäõíáìßá áðïêùäéêïðïßçóçò áðÜíôçóçò åôïéìüôçôáò BASE64\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "ü÷é ôáßñéáóìá ðñüêëçóçò\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: äéáãñáöÞ ðáëéïý áñ÷åßïõ êëåéäþìáôïò\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: áðïôõ÷ßá äçìéïõñãßáò êëåéäþìáôïò.\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "ðñïåéäïðïßçóç: âñÝèçêå ôï \"%s\" ðñéí êÜèå üíïìá äéáêïìéóôÞ"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: ðñïåéäïðïßçóç: âñÝèçêå ôï \"%s\" ðñéí êÜèå üíïìá äéáêïìéóôÞ\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: ðñïåéäïðïßçóç: Üãíùóôï ôåêìÞñéï \"%s\"\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "ï SMTP áêñïáôÞò ôïõ %s äåí õðïóôçñßæåé ÁTRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "ÅðéóôñïöÞ ôþñá...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "Ç áßôçóç ATRN áðïññßöèçêå.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "Áäõíáìßá åðåîåñãáóßáò áßôçóçò ATRN ôþñá\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "Äåí Ý÷åôå áëëçëïãñáößá.\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Ç åíôïëÞ äåí Ý÷åé õëïðïéçèåß\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Áðáéôåßôå åîïõóéïäüôçóç.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "¶ãíùóôï óöÜëìá ODMR %d\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "Ç åðéëïãÞ --keep äåí õðïóôçñßæåôå ìå ôï ODMR\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "Ç åðéëïãÞ --flush äåí õðïóôçñßæåôå ìå ôï ODMR\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "Ç åðéëïãÞ --remote äåí õðïóôçñßæåôå ìå ôï ODMR\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "Ç åðéëïãÞ --check äåí õðïóôçñßæåôå ìå ôï ODMR\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "äéá÷åéñéóôÞò Ýëáâå èáíÜóéìï\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Áäõíáìßá áðïêùäéêïðïßçóçò ðñüêëçóçò OTP\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "ÌõóôéêÞ öñÜóç êëåéäß: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "Ç óõìâïëïóåéñÜ '%s' äåí åßíáé Ýãêõñç óõìâïëïóåéñÜ áñéèìïý.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "ÔéìÞ ôçò óõìâïëïóåéñÜò '%s' åßíáé %s áíôß %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "ìéêñüôåñï"
+
+#: options.c:211
+msgid "larger"
+msgstr "ìåãáëýôåñï"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Ïñßóôçêå ìç Ýãêõñï ðñùôüêïëëï `%s'.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Ïñßóôçêå ìç Ýãêõñç åîïõóéïäüôçóç `%s'.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: áðåíåñãïðïéÞèçêå ç õðïóôÞñéîç áóöÜëåéáò äéêôýïõ\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "÷ñÞóç: fetchmail [åðéëïãÝò] [äéá÷åéñéóôÞò ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Ïé åðéëïãÝò åßíáé ïé áêüëïõèåò:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        áðåéêüíéóç áõôïý ôïõ ìçíýìáôïò âïçèåßáò\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     áðåéêüíéóç ðëçñïöïñßåò åêäüóåùò\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       Ýëåã÷ïò ãéá ìçíýìáôá ÷ùñßò ðáñáëáâÞ\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      áèüñõâç åñãáóßá\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     èïñõâþäçò åñãáóßá (äéáãíùóôéêÞ Ýîïäïò)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      åêôÝëåóç óáí äáßìïíáò ìéá öïñÜ êÜèå n äåýôåñá\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    áêýñùóç áöáßñåóçò äéåñãáóßáò ôïõ äáßìïíá\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        ôåñìáôéóìüò äéåñãáóßáò äáßìïíá\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     êáèïñéóìüò ïíüìáôïò áñ÷åßïõ êáôáãñáöÞò\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      ÷ñçóéìïðïßçóç ôïõ syslog(3) ãéá ôá ðåñéóóüôåñá ìçíýìáôá\n"
+"                    üôáí åêôåëåßôå óáí äáßìïíáò\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   ìç åããñáöÞ Received & ëåéôïõñãßá ôçò áðüêñõøçò "
+"óõóôÞìáôïò\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc ïñéóìüò åíáëëáêôéêïý áñ÷åßïõ ðñïôéìÞóåùí\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      ïñéóìüò åíáëëáêôéêïý áñ÷åßïõ ìå UIDs\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  ïñéóìüò ðáñáëÞðôç óáí ôåëåõôáßá ëýóç\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr ""
+"      --nobounce    áíáäñïìïëüãçóç ôùí áíáðçäÞóåùí áðü ÷ñÞóôç óå "
+"postmaster.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   áðáéôïýìåíïò ïñéóìüò interface\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     ðáñáêïëïýèçóç interface ãéá äñáóôçñéüôçôá\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         åíåñãïðïßçóç ssl êñõðôïãñáöçìÝíçò óõíåäñßáò\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      ðñïóùðéêü áñ÷åßï êëåéäéïý ssl\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     ðéóôïðïéçôéêü ðåëÜôç ssl\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      --sslproto    åîáíáãêáóìüò ðñùôïêüëëïõ ssl (ssl2/ssl3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+"      --plugin      êáèïñéóìüò åîùôåñéêÞò åíôïëÞò ãéá Üíïéãìá óýíäåóçò\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     êáèïñéóìüò åîùôåñéêÞò åíôïëÞò ãéá Üíïéãìá smtp óýíäåóçò\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    êáèïñéóìüò ðñùôïêüëëïõ áíÜêôçóçò (äåßôå óåëßäá man)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        åîáíáãêáóìüò ÷ñÞóçò ôùí UIDL (pop3 ìüíï)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        èýñá õðçñåóßáò TCP/IP ãéá óýíäåóç óå áõôÞ\n"
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr "      --auth        ôýðïò åîïõóéïäüôçóçò (password/kerberos/ssh/otp)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     ÷ñüíïò ëÞîçò ìç-áðÜíôçóçò äéáêïìéóôÞ\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    ôýëéãìá åðéêåöáëßäáò äéåýèõíóçò\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr "  -Q, --qvirtual    ðñüèåìá ãéá áöáßñåóç áðü ôï ôïðéêü user id\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   äéåõèõíôÞò õðçñåóßáò áëëçëïãñáößáò\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+"      --tracepolls  ðñïóèÞêç ðëçñïöüñéáò åíôïðéóìïý-åñþôçóçò óôï Received\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    ïñéóìüò ôïõ user login óôï äéá÷åéñéóôÞ\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         ëÞøç ðáëéþí êáé íÝùí ìçíõìÜôùí\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      äéáãñáöÞ íÝùí ìçíõìÜôùí ìåôÜ ôçí ëÞøç\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        áðïèÞêåõóç íÝùí ìçíõìÜôùí ìåôÜ ôçí ëÞøç\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       ðáëéþí ìçíõìÜôùí áðü ôï äéá÷åéñéóôÞ\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   ü÷é åðáíåããñáöÞ ôçò åðéêåöáëßäáò äéåõèýíóåùí\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -l, --limit       ü÷é ëÞøç ìçíõìÜôùí ðÜíù áðü ôï äïóìÝíï ìÝãåèïò\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr ""
+"  -w, --warnings    ðåñßïäïò ìåôáîý åéäïðïéçôéêïý ìçíýìáôïò ðñïåéäïðïßçóçò\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      ïñéóìüò áßôçóçò áóöáëåßáò IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    ïñéóìüò äéáêïìéóôÞ SMTP ãéá ðñïþèçóç\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr "      --fetchdomains ëÞøç áëëçëïãñáößáò áðü êáèïñéóìÝíåò ðåñéï÷Ýò\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr "  -D, --smtpaddress ïñéóìüò ðåñéï÷þí ðáñÜäïóçò SMTP ãéá ÷ñÞóç\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr "      --smtpname    ïñéóìüò ðëÞñç ïíüìáôïòSMTP username@domain\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam,   ïñéóìüò ôéìþí áðáíôÞóåùí áíôé-spam\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr "  -b, --batchlimit  ïñéóìüò ïñßïõ äÝóìçò ãéá ôéò óõíäÝóåéò SMTP\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  ïñéóìüò ïñßïõ ëÞøçò ãéá ôéò óõíäÝóåéò äéá÷åéñéóôÞ\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr "      --fetchdomains ëÞøç áëëçëïãñáößáò áðü êáèïñéóìÝíåò ðåñéï÷Ýò\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr "  -e, --expunge     ïñéóìüò ìÝãéóôùí äéáãñáöþí ìåôáîý åîáëåßøåùí\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         ïñéóìüò MDA ãéá ÷ñÞóç óå ðñïþèçóç\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       ïñéóìüò áñ÷åßïõ åîüäïõ BSMTP\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        ïñéóìüò LMTP (RFC2033) ãéá ðáñÜäïóç\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      êáèïñéóìüò ïíüìáôïò áðïìáêñõóìÝíïõ öáêÝëïõ\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+"      --showdots    åìöÜíéóç ôåëåßùí ðñïüäïõ êáé óôá áñ÷åßá êáôáãñáöÞò\n"
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "Äå âñÝèçêå ç áðáéôïýìåíç ÷ñïíïëüãçóç óôï ÷áéñåôéóìü\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Óõíôáêôéêü óöÜëìá ÷ñïíïëüãçóçò óôï ÷áéñåôéóìü\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Ìç ïñéóìÝíç áßôçóç ðñùôïêüëëïõ óôï POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "áðáó÷ïëçìÝíï êëåßäùìá!  Åßíáé åíåñãÞ êÜðïéá Üëëç óõíåäñßá;\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr ""
+"Ôá ìçíýìáôá åéóÝñ÷ïíôáé óå ëßóôá óôï äéá÷åéñéóôÞ. Áäõíáìßá ÷åéñéóìïý áõôïý.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "óöÜëìá ðñùôïêüëëïõ\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "óöÜëìá ðñùôïêüëëïõ êáôÜ ôç ëÞøç UIDL\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "Ç åðéëïãÞ --remote äåí õðïóôçñßæåôáé ìå ôï POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "åðéëïãÞ äéá÷åéñéóôÞ ìåôÜ ôéò åðéëïãÝò ÷ñÞóôç"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "ôï SDPS äåí Ý÷åé åíåñãïðïéçèåß."
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "ìç Ýãêõñç áßôçóç áóöÜëåéáò"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "áðåíåñãïðïéÞèçêå ç õðïóôÞñéîç áóöÜëåéá-äéêôýïõ"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: ç åðéëïãÞ interface õðïóôçñßæåôáé ìüíï áðü Linux (÷ùñßò IPv6) êáé "
+"ôï FreeBSD\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: ç åðéëïãÞ monitor õðïóôçñßæåôáé ìüíï áðü Linux (÷ùñßò IPv6) êáé "
+"ôï FreeBSD\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "ôï SSL äåí Ý÷åé åíåñãïðïéçèåß"
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "ôÝëïò åéóüäïõ"
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "Ôï áñ÷åßï %s ðñÝðåé íá åßíáé êáíïíéêü áñ÷åßï.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "Ôï áñ÷åßï %s äå ðñÝðåé íá Ý÷åé ðÜíù áðü -rwx--x--- (0710) Üäåéåò.\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "Ôï áñ÷åßï %s ðñÝðåé íá áíÞêåé óå åóÜò.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "¶ãíùóôï óöÜëìá óõóôÞìáôïò"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (çìéôåëÝò ìÞíõìá êáôáãñáöÞò)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "ìåñéêü óöÜëìá êáôÜôìçóçò ìçíýìáôïò ëÜèïõò"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "Ðñüêåéôå íá åðáíåããñáöåß %s"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "ÎáíáãñáììÝíç Ýêäïóç åßíáé %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Åðéôõ÷ßá"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "ÐåñéïñéóìÝíïò ÷ñÞóôçò (êÜôé óõìâáßíåé ìå ôï ëïãáñéáóìü)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "Ìç Ýãêõñï userid Þ öñÜóç êëåéäß"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "ÓöÜëìá Èåüôçôáò"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "RPA ôåêìÞñéï 2: óöÜëìá áðïêùäéêïðïßçóçò Base64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Ç õðçñåóßá åðÝëåîå Ýêäïóç RPA %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Ðñüêëçóç õðçñåóßáò (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "×ñïíïëüãçóç õðçñåóßáò %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "ÓöÜëìá ìÞêïõò RPA ôåêìçñßïõ 2\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Ëßóôá äéêáéïäïóßáò: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "ÓöÜëìá RPA óôç óõìâïëïóåéñÜ service@realm\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA ôåêìÞñéï 4: óöÜëìá áðïêùäéêïðïßçóçò Base64\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Åîïõóéïäüôçóç ÷ñÞóôç (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "ÊáôÜóôáóç RPA: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "ÓöÜëìá ìÞêïõò RPA ôåêìÞñéï 4\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "Ôï RPA óáò áðïññßðôåé: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "Ôï RPA óáò áðïññßðôåé, Üãíùóôç áéôßá\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "ÓöÜëìá ìÞêïõò Åîïõóéïäüôçóçò ×ñÞóôç RPA: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "ÓöÜëìá ìÞêïõò êëåéäéïý RPA Óõíåäñßáò: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "RPA _service_ auth áðÝôõ÷å. Áðüêñõøç äéá÷åéñéóôÞ;\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "ÅãêáôáóôÜèçêå êëåéäß óõíåäñßáò:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "Åîïõóéïäüôçóç RPA ïëïêëçñþèçêå\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "ËÞøç áðÜíôçóçò\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Ç ëÞøç áðÜíôçóçò åðÝóôñåøå %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "Hdr ü÷é 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "ÓöÜëìá ìÞêïõò ôåêìçñßïõ\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "Ôï ìÞêïò ôåêìçñßïõ %d äéáöùíåß ìå ôï rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "ÅóöáëìÝíïò ìç÷áíéóìüò ðåäßïõ\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "óöÜëìá dec64 óôï ÷áñáêôÞñá %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Åéóåñ÷üìåíá äõáäéêÜ äåäïìÝíá:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Åîåñ÷üìåíá äåäïìÝíá:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "ÓõìâïëïóåéñÜ RPA õðåñâïëéêÜ ìåãÜëç\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "Ôï RPA ÁðÝôõ÷å íá áíïßîåé ôï /dev/urandom. Áõôü äå ðñÝðåé\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    íá óáò åìðïäßæåé íá ìðåßôå, áëëÜ óçìáßíåé üôé\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    äå ìðïñåßôå íá åßóôå óßãïõñïé üôé ìéëÜôå óôçí\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    õðçñåóßá ðïõ íïìßæåôå (åðéèÝóåéò åðáíÜëçøçò\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    áðü ìéá Üôéìç õðçñåóßá åßíáé ðéèáíÝò.)\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Ðñüêëçóç ÷ñÞóôç:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "Ôï MD5 åöáñìüæåôáé óôï ìðëüê äåäïìÝíï:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "ÁðïôÝëåóìá MD5: \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "ðñïùèåßôáé óôï %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (bounce-message óþìá)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "ç áëëçëïãñáößá áðü %s áíáðÞäçóå óôï %s\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "Ôï áðïèçêåõìÝíï óöÜëìá åßíáé áêüìá %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "%cMTP óöÜëìá: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "Áíïé÷ôü áñ÷åßï BSMTP Þ áðÝôõ÷å ç åéóáãùãéêÞ åããñáöÞ\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "Ï áêñïáôÞò %cMTP áðå÷èÜíåôáé ôç äéåýèõíóç ðáñáëÞðôç `%s'\n"
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "Ï áêñïáôÞò %cMTP ðñáãìáôéêÜ áðå÷èÜíåôáé ôç äéåýèõíóç ðáñáëÞðôç `%s'\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "êáíÝíá ôáßñéáóìá äéåýèõíóçò· äåí Ý÷åé ïñéóôåß postmaster.\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "áäõíáìßá áðïóôïëÞò áêüìá êáé óôï %s!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "êáíÝíá ôáßñéáóìá äéåýèõíóçò· ðñïþèçóç óôï %s.\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "ðñüêåéôå íá äéáíåìçèïýí ìå: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "¶íïéãìá MDA áðÝôõ÷å\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "Óýíäåóç %cMTP óôï %s áðÝôõ÷å\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "áäõíáìßá áíýøùóçò áêñïáôÞ· ÷ñÞóç ôïõ %s"
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr "ôï MDA áðåâßùóå áðü óÞìá %d\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "Ôï MDA åðÝóôñåøå ìç-ìçäåíéêÞ êáôÜóôáóç %d\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr "ÐáñÜîåíï: ôï MDA pclose åðÝóôñåøå %d, áäõíáìßá ÷åéñéóìïý óôï %s:%d\n"
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Ôåñìáôéóìüò ìçíýìáôïò Þ êëåßóéìï ôïõ áñ÷åßïõ BSMTP áðÝôõ÷å\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "Ï áêñïáôÞò SMTP áñíÞèçêå ôç äéáíïìÞ\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "ÓöÜëìá äéáíïìÞò LMTP óôï  EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Ìç áíáìåíüìåíç áðÜíôçóç ü÷é-503 óôï LMTP EOM: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tÏ Äáßìïíáò  Fetchmail\n"
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "Åîïõóéïäüôçóç ESMTP CRAM-MD5...\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "Ï äéá÷åéñéóôÞò áðÝññéøå ôçí åíôïëÞ AUTH.\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "ÅóöáëìÝíç áðÜíôçóç BASE64 áðü ôï äéá÷åéñéóôÞ.\n"
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "Áðïêùäéêïðïßçóç ðñüêëçóçò: %s\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "Åîïõóéïäüôçóç ESMTP PLAIN...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "Åîïõóéïäüôçóç ESMTP LOGIN...\n"
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr "óöÜëìá ðñùôïêüëëïõ áêñïáôÞ smtp\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: áðÝôõ÷å ôï malloc\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: socketpair áðÝôõ÷å\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: áðÝôõ÷å ôï fork\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "dup2 áðÝôõ÷å\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "åêôåëåßôå %s (äéáêïìéóôÞò %s õðçñåóßá %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "execvp(%s) áðÝôõ÷å\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: ëÞøç ðáñÜíïìïõ ìÞêïõò äéåýèõíóçò ãéá ôï äéáêïìéóôÞ %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Ïñãáíéóìüò Åêäüôç: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+"Ðñïåéäïðïßçóç: õðåñâïëéêÜ ìåãÜëï ¼íïìá Ïñãáíéóìïý Åêäüôç (ðéèáíÜ êïììÝíï).\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "¶ãíùóôïò Ïñãáíéóìüò\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "Êïéíü¼íïìá Åêäüôç: %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+"Ðñïåéäïðïßçóç: Êïéíü¼íïìá Åêäüôç åßíáé õðåñâïëéêÜ ìåãÜëï (ðéèáíÜ êïììÝíï).\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "¶ãíùóôï Êïéíü¼íïìá Åêäüôç\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Êïéíü¼íïìá Äéá÷åéñéóôÞ: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "Êáêü ðéóôïðïéçôéêü: Subject Êïéíü¼íïìá õðåñâïëéêÜ ìåãÜëï!\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "Ìç ôáßñéáóìá ÊïéíïýÏíüìáôïò ÄéáêïìéóôÞ: %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+"Äåí Ý÷åé ïñéóôåß üíïìá äéá÷åéñéóôÞ, áäõíáìßá åðáëÞèåõóçò ðéóôïðïéçôéêïý!\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "¶ãíùóôï Êïéíü¼íïìá ÄéáêïìéóôÞ\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "Äåí Ý÷åé ïñéóôåß üíïìá äéáêïìéóôÞ óôï ðéóôïðïéçôéêü!\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "EVP_md5() áðÝôõ÷å!\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "Óþèçêå ç ìíÞìç!\n"
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "Ç ðñïóùñéíÞ ìíÞìç êåéìÝíïõ ðåñßëçøçò åßíáé õðåñâïëéêÜ ìéêñÞ!\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "%s áðïôýðùìá êëåéäéïý: %s\n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "%s áðïôõðþìáôá ôáéñéÜæïõí.\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "%s áðïôõðþìáôá äåí ôáéñéÜæïõí!\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "Ðñïåéäïðïßçóç: åðáëÞèåõóç ðéóôïðïéçôéêïý äéáêïìéóôÞ: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "Üãíùóôïò åêäüôçò (ðñþôïé %d ÷áñáêôÞñåò): %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Ï ðåñéãñáöÝáò áñ÷åßïõ åêôüò êëßìáêáò ãéá ôï SSL"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr "Êáèïñßóôçêå Üêõñï ðñïôüêïëëï SSL '%s', ÷ñÞóç åî ïñéóìïý (SSLv23).\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr "ÅðáëÞèåõóç ðéóôïðïéçôéêïý/áðïôõðþìáôïò êÜðùò ðáñáëÞöèçêå!\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr "ÅðáíáðñïóðÜèåéá áíÜãíùóçò õðïäï÷Þò Cygwin\n"
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr "ÅðáíáðñïóðÜèåéá áíÜãíùóçò õðïäï÷Þò Cygwin áðÝôõ÷å!\n"
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "áíôéóôïß÷çóç ôïõ %s óôï ôïðéêü %s\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "ðÝñáóå ìÝóá áðü %s ôáéñéÜæïíôáò ôï %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr "áíÜëõóç ãñáììÞò Received:%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "äåêôÞ ãñáììÞ, ôï %s åßíáé øåõäüíçìï ôïõ äéá÷. áëëçëïãñáößáò\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "ìç äåêôÞ ãñáììÞ, ôï %s äåí åßíáé øåõäüíçìï ôïõ äéá÷. áëëçëïãñáößáò\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "äåí âñÝèçêáí äéåõèýíóåéò Received\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "âñÝèçêáí äéåõèýíóåéò Received `%s'\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "âñÝèçêå ïñéïèÝôçò ìçíýìáôïò êáôÜ ôçí óÜñùóç åðéêåöáëßäùí\n"
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "âñÝèçêå ëÜèïò ãñáììÞ åðéêåöáëßäáò êáôá ôïí Ýëåã÷ï åðéêåöáëßäùí\n"
+
+#: transact.c:554
+#, fuzzy, c-format
+msgid "line: %s"
+msgstr "ÓõãêÝíôñùóç áðü %s\n"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "äåí õðÜñ÷ïõí ôïðéêÜ üìïéá, ðñïþèçóç óôï %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "êáôáóôïëÞ ðñïþèçóçò êáé äéáãñáöÞò ëüãù óöáëìÜôùí ôïõ DNS\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "åããñáöÞ RFC822 msgblk.headers\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "êáììéÜ äéåýèõíóç ðáñáëÞðôç äå ôáéñéÜæåé ìå ôá ïñéóìÝíá ôïðéêÜ ïíüìáôá"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "äéåýèõíóç ðáñáëÞðôç %s äåí ôáéñéÜæåé ìå êáíÝíá ôïðéêü üíïìá"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "ôï ìÞíõìá ðåñéÝ÷åé åíèåôçìÝíá NULs"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "Ï áêñïáôÞò SMTP áðÝññéøå ôéò äéåõèýíóåéò ôïðéêþí ðáñáëçðôþí: "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "åããñáöÞ êåéìÝíïõ ìçíýìáôïò\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "ÐáëéÜ ëßóôá UID áðü %s:"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <Üäåéï>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Ðñü÷åéñç ëßóôá ìå UID:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, fuzzy, c-format
+msgid "Merged UID list from %s:"
+msgstr "ÐáëéÜ ëßóôá UID áðü %s:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "ÍÝá ëßóôá UID áðü %s:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "áíôáëëáãÞ ëéóôþí UID\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr "ü÷é áíôáëëáãÞ ëéóôþí UID, äå âñÝèçêå êáíÝíá UID óå áõôÞ ôçí åñþôçóç\n"
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "áíôáëëáãÞ ëéóôþí UID\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "ÄéáãñáöÞ áñ÷åßïõ fetchids.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "ÅããñáöÞ áñ÷åßïõ fetchids\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "áðÝôõ÷å ôï malloc\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "áðÝôõ÷å ôï realloc\n"
diff --git a/po/es.gmo b/po/es.gmo
new file mode 100644
index 00000000..778159d8
--- /dev/null
+++ b/po/es.gmo
diff --git a/po/es.po b/po/es.po
new file mode 100644
index 00000000..27089228
--- /dev/null
+++ b/po/es.po
@@ -0,0 +1,2901 @@
+# Fetchmail Spanish Translation
+# Copyright © 1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+# Javier Kohen <jkohen@users.sourceforge.net>, 1999.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 6.2.4\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2003-08-15 01:25-0300\n"
+"Last-Translator: Javier Kohen <jkohen@users.sourceforge.net>\n"
+"Language-Team: Spanish <es@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=ISO-8859-1\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Verificando si %s es realmente el mismo nodo que %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Sí, sus direcciones IP coinciden\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "No, sus direcciones IP no coinciden\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr ""
+"fallo en la resolución de nombres buscando `%s' durante la consulta de %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "no fue posible decodificar el desafío BASE64\n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "decodificado como %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "error de kerberos %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s  [el servidor dice '%*s'] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Asunto: [fetchmail] aviso de mensajes excedidos de tamaño.\n"
+"\n"
+"Los siguientes mensajes excedidos de tamaño permanecen en el servidor de "
+"correo %s:"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\t%d mensajes de %d octetos de largo omitidos por fetchmail.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "saltando mensaje %s@%s:%d (%d octetos)"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "saltando mensaje %s@%s:%d (%d octetos)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr " (longitud -1)"
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr " (demasiado grande)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr ""
+"no fue posible recibir los encabezados, mensaje %s@%s:%d (%d octetos)\n"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "leyendo el mensaje %s@%s:%d de %d"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d %soctetos)"
+
+#: driver.c:606
+msgid "header "
+msgstr "encabezado "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d octetos en el cuerpo) "
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"el mensaje %s@%s:%d no tenía la longitud esperada (%d actual != %d "
+"esperada)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " retenido\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " eliminado\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " no eliminado\n"
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+"límite de %d mensajes alcanzado; %d mensajes dejados en el servidor %s para "
+"la cuenta %s\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "SIGPIPE lanzado desde un MDA o un error de socket de flujo\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+"tiempo agotado después de %d segundos de espera para conectarse con el "
+"servidor %s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "tiempo agotado después de %d segundos de espera por el servidor %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "tiempo agotado después de %d segundos de espera por %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr ""
+"tiempo agotado después de %d segundos de esperar respuesta del cliente.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "tiempo agotado después de %d segundos.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Asunto: fetchmail ve repetidos excesos en el tiempo de espera\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail vio más de %d excesos en el tiempo de espera mientras intentaba "
+"obtener correo de %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Esto puede significar que su servidor de correo se trabó, o que su\n"
+"servidor SMTP se colgó, o que su casilla de correo en el servidor ha\n"
+"sido corrupta por un error de servidor. Puede ejecutar `fetchmail -v -v'\n"
+"para diagnosticar el problema.\n"
+"Fetchmail no inquirirá esta casilla hasta que lo reinicie.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "el comando preconexión falló con estado %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "no fue posible encontrar casilla HESIOD para %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "El servidor líder no tiene nombre.\n"
+
+#: driver.c:1016
+#, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "no fue posible encontrar el nombre DNS canónico de %s (%s)\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "inconsistencia interna\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "Fallo la conexión de %s a %s"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "máquina desconocida."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "el nombre es válido pero no tiene dirección IP."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "error irrecuperable en el servidor de nombres."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "error temporario en el servidor de nombres."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "error desconocido en el DNS %d."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Asunto: aviso de server fuera de alcance de fetchmail.\n"
+"\n"
+"Fetchmail no puede alcanzar el servidor de correo %s:"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "Fallo en la conexión SSL.\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Error `lock-busy' en %s@%s\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Error: servidor ocupado en %s@%s\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Fallo de autorización en %s@%s%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr " (previamente autorizado)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Asunto: la autenticación de fetchmail falló en %s@%s\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail no pudo obtener correo de %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"El intento de obtener autorización falló.\n"
+"Debido a que ya hemos tenido éxito al obtener autorización para esta\n"
+"conexión, esto probablemente sea otro modo de fallo (como un servidor\n"
+"ocupado) que fetchmail no puede distinguir porque el servido no envió\n"
+"un mensaje de error útil.\n"
+"\n"
+"Sin embargo, si cambiaste los detalles de tu cuenta tras haber iniciado\n"
+"el proceso fetchmail, necesitás detener el proceso, cambiar la configu-\n"
+"ración de fetchmail y reiniciarlo.\n"
+"\n"
+"El proceso fetchmail continuará corriendo e intentando establecer la\n"
+"conexión en cada ciclo. No se enviarán más notificaciones hasta que el\n"
+"servicio sea restablecido."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"El intento de obtener autorización falló.\n"
+"Esto probablemente signifique que su clave es inválida. Aunque algunos\n"
+"servidores POP3 tienen otros modos de fallar que fetchmail no puede\n"
+"distinguir de éste porque no envían mensajes de error útiles cuando se\n"
+"falla en la entrada.\n"
+"\n"
+"El proceso fetchmail continuará corriendo e intentando establecer la\n"
+"conexión en cada ciclo. No se enviarán más notificaciones hasta que el\n"
+"servicio sea restablecido."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr "Reinquirir inmediatamente %s@%s\n"
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Error de entrada o de autenticación desconocido en %s@%s\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Autorización exitosa en %s@%s\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Asunto: la autenticación de fetchmail aprobada en %s@%s\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail pudo registrarse en %s@%s.\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "El servicio ha sido reestablecido.\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "seleccionando o re-inquiriendo la carpeta %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "seleccionando o re-inquiriendo la carpeta por defecto\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s en %s (carpeta %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s en %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Inquiriendo %s\n"
+
+#: driver.c:1362
+#, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d %s) para %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "mensajes"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "mensaje"
+
+#: driver.c:1366
+msgid "seen"
+msgstr "visto"
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s para %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d octetos).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "No hay correo para %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "¡cantidad de mensajes incorrecta!"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "el encabezado RFC822 falta o está arruinado"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "sincronización cliente/servidor"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "protocolo cliente/servidor"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "bloqueo ocupado en el servidor"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "Transacción SMTP"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "búsqueda en DNS"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "error indefinido\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "error `%s' durante el envío al host SMTP %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "error `%s' recibiendo de %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "el comando posconexión falló con estado %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Soporte de Kerberos V4 no incluido.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Soporte de Kerberos V5 no incluido.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Opción --flush no soportada con %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Opción --all no soportada con %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Opción --limit no soportada con %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: La variable de entorno QMAILINJECT está configurada.\n"
+"Esto es peligroso dado que puede hacer que qmail-inject o el envoltorio\n"
+"sendmail de qmail pisoteen tus encabezados From: o Message-ID:.\n"
+"Prueba \"env QMAILINJECT= %s TUS ARGUMENTOS ACA\"\n"
+"%s: Abort.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: La variable de entorno NULLMAILER_FLAGS está configurada.\n"
+"Esto es peligroso dado que puede hacer que nullmailer-inject o el\n"
+"envoltorio sendmail de nullmailer pisoteen tus encabezados From:,\n"
+"Message-ID: o Return-Path.\n"
+"Prueba 'env NULLMAILER_FLAGS= %s TUS ARGUMENTOS ACA'\n"
+"%s: Abort.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: No existís. Andate.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: ¡no se puede determinar su máquina!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "gethostbyname falló para %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "El servidor de SMTP de %s no soporta ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "El servidor de SMTP de %s no soporta ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Cola para %s iniciada\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "No hay mensajes esperando para %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Mensajes pendientes para %s iniciados\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Incapaz de poner los mensajes para el nodo %s en la cola\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Nodo %s no permitido: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "Error de sintaxis ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "Error de sintaxis ETRN en los parámetros\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Error ETRN desconocido %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "La opción --keep no es soportada con ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "La opción --keep no es soportada con ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "La opción --remote no es soportada con ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "La opción --check no es soportada con ETRN\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: invocado con"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "no fue posible obtener el directorio de trabajo actual\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Esta es la versión de fetchmail %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Tomando opciones de la línea de comandos%s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " y "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "No hay servidores de correo configurados -- ¿por ahí falta %s?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: no han sido especificados servidores de correo.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: ningún otro fetchmail está siendo ejecutando\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: error terminando %s fetchmail (%d); abandonando.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "segundo plano"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "primer plano"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %s fetchmail (%d) terminando.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: no es posible verificar el correo mientras otro fetchmail está en "
+"ejecución hacia la misma máquina\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: no es posible inquirir las máquinas especificadas con otro "
+"fetchmail (%d) en ejecución.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: otro fetchmail (%d) está en ejecución en primer plano.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: no es posible aceptar opciones mientras un fetchmail está en "
+"ejecución en segundo plano.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: fetchmail (%d) en segundo plano despertado.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: proceso hijo más antiguo (%d) murió misteriosamente.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: no se puede encontrar una clave para %s@%s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Ingrese clave para %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "iniciando fetchmail %s en segundo plano \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "no fue posible abrir %s para anexarle mensajes de registro\n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "no se pudo temporizar %s (error %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "reiniciando fetchmail (%s cambió)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+"el intento de re-ejectuar puede fallar dado que el directorio no ha sido "
+"restaurado\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "el intento de re-ejecutar fetchmail falló\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"no se consulta %s (fallo en la autenticación o demasiados excesos de "
+"espera)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "intervalo no alcanzado, no se interrogará %s\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Estado de la consulta=0 (SUCCESS)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Estado de la consulta=1 (NOMAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Estado de la consulta=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Estado de la consulta=3 (AUTHFAIL)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Estado de la consulta=4 (PROTOCOL)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Estado de la consulta=5 (SYNTAX)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "Estado de la consulta=6 (IOERR)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "Estado de la consulta=7 (ERROR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Estado de la consulta=8 (EXCLUDE)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Estado de la consulta=9 (LOCKBUSY)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "Estado de la consulta=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "Estado de la consulta=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Estado de la consulta=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Estado de la consulta=13 (MAXFETCH)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Estado de la consulta=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Todas las conexiones están trabadas. Saliendo.\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "durmiendo en %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "despertado por %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "despertado por señal %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "despertado en %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "terminación normal, estado %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "no se pudo temporizar el archivo de control de ejecución\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr ""
+"Cuidado: múltiple mención de la máquina %s en el archivo de configuración\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "El soporte de SSL no fue compilado.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: cuidado: no hay DNS disponible para verificar recepciones "
+"`multidrop' de %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr ""
+"La configuración %s es inválida, el número de puerto no puede ser negativo\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "configuración de %s inválida, RPOP requiere un puerto privilegiado\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"configuración de %s inválida, LMTP no puede usar el puerto SMTP por defecto\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr ""
+"¡Usar `fetchall' junto a `keep' en modo de ejecución en segundo plano es un "
+"error!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "terminado con señal %d\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s interrogando a %s (protocolo %s) en %s: consulta iniciada\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "El soporte de POP2 no está configurado.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "El soporte de POP3 no está configurado.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "El soporte de IMAP no está configurado.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "El soporte de ETRN no está configurado.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "No se puede soportar ETRN sin gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "El soporte de ODMR no está configurado.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "No se puede soportar ODMR sin gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "fue seleccionado un protocolo no soportado.\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s interrogando %s (protocolo %s) en %s: consulta terminada\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "El intervalo entre consultas es de %d segundos\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "El archivo de registro es %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "El archivo con identificaciones es %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Los mensajes de progreso serán registrados vía syslog\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail enmascarará y no generará `Received'\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr ""
+"Fetchmail mostrará puntos de progreso incluso en los archivos de registro.\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr "Fetchmail reenviará mensajes `multidrop' mal direccionados a %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Fetchmail dirigirá el correo de error al `postmaster'.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail dirigirá el correo de error al remitente.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Opciones para recibir de %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  El correo será recibido vía %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  La consulta de este servidor ocurrirá cada %d intervalos.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  El nombre verdadero del servidor es %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr "  Esta máquina %s interrogada cuando no haya otra especificada.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr "no será"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr "será"
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  La clave será pedida.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  Secreto APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  Identificación RPOP = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Clave = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  El protocolo es KPOP con autenticación Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  El protocolo es %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (usando servicio %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (usando opciones de seguridad de red %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (usando puerto %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (usando puerto por defecto)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (forzando el uso de UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  Se probarán todos los métodos de autenticación disponibles.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  Se forzará autenticación con clave.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  Se forzará autenticación NTLM.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  Se forzará autenticación OTP.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  Se forzará autenticación CRAM-Md5.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  Se forzará autenticación GSSAPI.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Se forzará autenticación Kerberos V4.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Se forzará autenticación Kerberos V5.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  Se asume cifrado de un extremo a otro.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  El principal del servicio de correo es: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  Sesiones encriptadas con SSL activadas.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  Protocolo SSL: %s.\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  Comprobación de certificados SSL del servidor activada.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  Directorio del certificado SSL de confianza: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr ""
+"  Huella dactilar de la llave SSL (comprobada con la llave del servidor): %"
+"s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  El tiempo de espera para respuestas del servidor es de %d segundos"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (por defecto).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  La casilla por defecto está seleccionada.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Las casillas seleccionadas son:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s mensajes serán recibidos (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "Todos los"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "Sólo los nuevos"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Los mensajes recibidos %sn dejados en el servidor (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+"  Los mensajes viejos %sn eliminados antes de la recepción de mensajes (--"
+"flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr ""
+"  La reescritura de las direcciones locales está %sa (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "activado"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "desactivado"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  La remoción de retornos de carro está %sa (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  El fuerce de retornos de carro está %so (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+"  La interpretación de la Codificación de Transmisión de Contenido está %s "
+"(pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  La decodificación MIME está %sa (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  Ocio tras la consulta %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Las líneas `Status' serán %s (dropstatus %s).\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "descartadas"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "guardadas"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Las líneas `Delivered-To' serán %s (dropdelivered %s).\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  El tamaño de los mensajes está limitado a %d octetos (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  El tamaño de los mensajes no está limitado (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  Los avisos sobre el tamaño de los mensajes se darán cada %d segundos (--"
+"warnings %d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+"  Los avisos sobre el tamaño de los mensajes se darán en cada consulta (--"
+"warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr ""
+"  La cantidad de mensajes recibidos está limitada a %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr ""
+"  La cantidad de mensajes recibidos no está limitada (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr ""
+"  La cantidad de mensajes recibidos está limitada a %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  El tamaño de los mensajes no está limitado (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  El límite de mensaje por lote SMTP es %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr ""
+"  La cantidad de mensajes emitidos no está limitada (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+"  El intervalo de borrado entre eliminaciones está forzado a %d (--expunge %"
+"d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  No forzar eliminaciones (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Los dominios para los cuales se recibirá correo son:"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (por defecto)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Los mensajes serán anexados a %s como BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Los mensajes serán entregados con \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Los mensajes serán reenviados con %cMTP a:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  El nombre de la máquina en la línea `MAIL FROM' será %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr ""
+"  La dirección a poner en las líneas RCPT TO enviadas al STMP será %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Las respuestas de servidor reconocidas como bloques de `spam' son:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  El bloqueo de `spam' está desactivado\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  La conexión al servidor será iniciada con \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  No hay comando de pre-conexión.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  La conexión al servidor será terminada con \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  No hay comando posconexión.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  No hay nombres locales declarados para esta máquina.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Modo `multi-drop': "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Modo `single-drop': "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d nombre(s) local(es) reconocidos.\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  Búsqueda en DNS de direcciones `multidrop' está %sa.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr ""
+"  Los alias del servidor serán comparados con las direcciones `multidrop' "
+"por "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "dirección IP.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "nombre.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  El ruteo por la dirección de la envoltura está desactivado\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Se asume que el encabezado de la envoltura es: %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Recibido"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Número del encabezado de la envoltura a ser procesado: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  El prefijo %s será removido del nombre de usuario\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  Ningún prefijo será removido\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Alias predeclarados del servidor de correo:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Dominios locales:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  La conexión debe ser a través de la interfaz %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  No se especificó alguna interfaz requerida.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  El bucle de consulta monitoreará %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  No se especificó una interfaz de monitoreo.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr ""
+"  Las conexiones al servidor se llevarán a cabo a través del `plugin' %s (--"
+"plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  No se especificó un comando para el `plugin'.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  Las conexiones al cliente se llevarán a cabo a través del `plugout' %s (--"
+"plugout %s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  No se especificó un comando para el `plugout'.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  No hay UIDs guardadas de esta máquina.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d UIDs guardadas.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+"  Se agregará información de trazado sobre la consulta al encabezado "
+"Recibido.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  No se agregará información de trazado sobre la consulta al encabezado "
+"Recibido.\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Propiedades de paso \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "alloca falló"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "ERROR: no hay soporte para la rutina getpassword()\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"SIGINT recibido... abortando.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "No fue posible obtener el nombre de servicio para [%s]\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "Usando nombre de servicio [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Enviando credenciales\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Error intercambiando credenciales\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "No fue posible desenvolver los datos del nivel de seguridad\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Intercambio de credenciales completo\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "El servidor requiere integridad y/o privacidad\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Opciones de nivel de seguridad desenvueltas: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "El máximo tamaño del componente GSS es %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Error creando pedido de nivel de seguridad\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Largando las credenciales GSS\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Error largando las credenciales\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: la tarea dormirá por %d segundos\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protocolo identificado como IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protocolo identificado como IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protocolo identificado como IMAP2 o IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "descansará después de inquirir\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "La capacidad OTP requerida no fue compilada en fetchmail\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "La capacidad NTLM requerida no fue compilada en fetchmail\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "La capacidad LOGIN requerida no es soportada por el servidor\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "falló la eliminación\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "falló el reintento de consulta\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "Hay %d mensajes esperando tras el reintento de consulta\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "falló la selección de casilla\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "Hay %d mensajes esperando tras la consulta inicial\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "Hay %d mensajes esperando tras la eliminación\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "la búsqueda de mensajes no visto falló\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u no fue visto\n"
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr "%u es el primero que no fue visto\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"No es posible abrir la interfaz kvm. Asegúrese de que fetchmail este SGID "
+"kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "Incapaz de interpretar el nombre de la interfaz a partir de %s"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: sysctl (estimar lista de interfaces) falló"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: malloc falló"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: sysctl (lista de interfaces) falló"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "No se entendió el mensaje de ruteo versión %d."
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "No se encontró una interfaz con el nombre %s"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "No se encontró dirección IP para %s"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "falta la dirección IP de la interfaz\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "la dirección IP de la interfaz es inválida\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "la máscara IP de la interfaz es inválida\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "actividad en %s -vista- como %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "no se consulta %s, %s desactivada\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "no se consulta %s, la dirección IP de %s fue excluida\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "actividad en %s verificada como %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "no se consulta %s, %s inactiva\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "la actividad en %s era %d, es %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "no fue posible decodificar el desafío BASE64 inicial\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "%s principal en el `ticket' no coincide con -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "La instancia no-nula (%s) puede causar comportamiento extraño\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "no fue posible decodificar la respuesta BASE64 `ready'\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "desafío no coincidente\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: removiendo archivo de bloqueo viejo\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: falló la creación del bloqueo.\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "cuidado: \"%s\" encontrado antes que cualquier nombre de máquina"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr ""
+"%s:%d: cuidado: \"%s\" encontrado antes que cualquier nombre de máquina\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: cuidado: el componente \"%s\" es desconocido\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "El SMTP de %s no soporta ATRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "Date vuelta ahora...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "Pedido ATRN rechazado.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "No es posible procesar el pedido ATRN\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "No tenés correo.\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Comando no implementado\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Autenticación requerida.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Error ODMR desconocido %d\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "La opción --keep no es soportada con ODMR\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "La opción --flush no es soportada con ODMR\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "La opción --remote no es soportada con ODMR\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "La opción --check no es soportada con ODMR\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "fatal recv del server\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "No fue posible decodificar el desafío OTP\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Frase clave secreta: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "La cadena '%s' no es un cadena de números válida.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "El valor de la cadena '%s' es %s que %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "menor"
+
+#: options.c:211
+msgid "larger"
+msgstr "mayor"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "El protocolo `%s' especificado es inválido.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Fue especificada una autenticación `%s' inválida.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: el soporte de seguridad de red está desactivado\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "uso:  fetchmail [opciones] [servidor ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Las opciones son las siguientes:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        muestra esta ayuda\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     muestra información sobre la versión\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       verifica si hay mensajes sin recibirlos\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      trabajar silenciosamente\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr ""
+"  -v, --verbose     trabajar ruidosamente (información de diagnóstico)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr ""
+"  -d, --daemon      correr en segundo plano y activarse una vez cada n "
+"segundos\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    no lanzar un proceso en segundo plano\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        terminar el proceso en segundo plano\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     especificar el nombre del archivo de registro\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      usar syslog(3) para la mayoría de los mensajes cuando se "
+"ejecuta en segundo plano\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   no escribir `Received' y activar falsificación de "
+"máquina\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr ""
+"  -f, --fetchmailrc especificar archivo de control de ejecución alterno\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      especificar archivo de UIDs alterno\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  especificar el recipiente de último recurso\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr "      --nobounce    redirigir rebotes del usuario al postmaster.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   especificación de interfaz requerida\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     monitorear interfaz por actividad\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         activar sesión encriptada con ssl\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      archivo de llave privada ssl\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     certificado ssl del cliente\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      --sslproto    forzar protocolo ssl (ssl2/ssl3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+"      --plugin      especificar el comando externo para abrir una conexión\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     especificar el comando externo para abrir una conexión "
+"smtp\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    especificar el protocolo de recepción (ver página man)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        forzar el uso de UIDLs (sólo pop3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        puerto TCP/IP al cual conectarse\n"
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr "      --auth        tipo de autenticación (clave/kerberos/ssh/otp)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     tiempo de espera por respuesta del servidor\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    envolver encabezados de dirección\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+"  -Q, --qvirtual    prefijo a remover de la identificación local del "
+"usuario\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   servicio de correo principal\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+"      --tracepolls  añadir información sobre trazado de consultas al "
+"encabezado Recibido\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr ""
+"  -u, --username    especificar el `login' del usuario en el servidor\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         recibir mensajes viejos y nuevos\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      borrar nuevos mensajes luego de recibidos\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        guardar nuevos mensajes luego de recibidos\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       borrar viejos mensajes del servidor\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   no reescribir las direcciones del encabezado\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr ""
+"  -l, --limit       no recibir los mensajes más largos que lo especificado\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    intervalo entre las notificaciones de correo\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      configurar el pedido de seguridad IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    configurar la máquina de reenvío de SMTP\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr "      --fetchdomains recibir correo para los dominios especificados\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr "  -D, --smtpaddress configurar el dominio de entrega de SMTP a usar\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr ""
+"      --smtpname    usar nombreusuario@dominio como nombre completo para "
+"SMTP\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    configurar los valores de respuesta anti`spam'\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+"  -b, --batchlimit  configurar el límite de mensajes para las conexiones "
+"SMTP\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  configurar el límite de mensajes para las conexiones al "
+"servidor\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr "      --fetchdomains recibir correo para los dominios especificados\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+"  -e, --expunge     configurar la cantidad de mensajes borrados entre "
+"eliminaciones\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         configurar el MDA para que reenvíe\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       configurar archivo de salida de BSMTP\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        usar LMTP (RFC2033) para entrega\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      especificar nombre de la carpeta remota\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+"      --showdots    mostrar puntos de progreso incluso en los archivos de "
+"registro\n"
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "Estampa de tiempo APOP requerida no encontrada en el saludo\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Error de sintaxis en la estampa de tiempo en el saludo\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Pedido de protocolo indefinido en POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "¡bloqueo ocupado! ¿Hay otra sesión activa?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr ""
+"Mensajes insertados en una lista en el servidor. No se puede manejar esto.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "error de protocolo\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "error de protocolo durante la recepción de UIDLs\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "La opción --remote no es soportada con POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "opciones de servidor tras opciones de usuario"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "SDPS no activado."
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "requerimiento de seguridad inválido"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "soporte de seguridad de red desactivado"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: la opción `interface' solo es soportada bajo Linux (sin IPv6) y "
+"FreeBSD\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: la opción `monitor' solo es soportada bajo Linux (sin IPv6) y "
+"FreeBSD\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "SSL no está activado"
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "fin de entradas"
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "El archivo %s debe ser de tipo normal.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "El archivo %s no debe tener mas que los permisos -rwx--x--- (0710).\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "El archivo %s debe ser poseido por usted.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Error de sistema desconocido"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (mensaje de registro incompleto)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "error parcial en sobrecarga del buffer de mensaje"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "A punto de re-escribir %s"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "La versión re-escrita es %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Éxito"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Usuario restringido (algo mal con la cuenta)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "Id de usuario o contraseña inválidos"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "Error de deidad"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "Componente RPA 2: error de decodificación Base64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "El servicio eligió RPA versión %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Desafío del servicio (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Estampa de tiempo del servicio %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "Error de largo en el componente RPA 2\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Lista de dominios: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "Error de RPA en la cadena servicio@dominio\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "Componente RPA 4: error de decodificación\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Autenticación de usuario (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "Estado RPA: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "Error de largo en el componente RPA 4\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA lo rechaza: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA lo rechaza, razón desconocida\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "Error de largo en la Autenticación de Usuario RPA: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "Error de largo en la llave de sesión RPA: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "Fallo en la autenticación del _servicio_ RPA. ¿Servidor falso?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Llave de sesión establecida:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "Autorización RPA completa\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Obtener respuesta\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Obtener respuesta %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "Encabezado no es 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "Error de largo en el componente\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "El largo %d del componente no está de acuerdo con rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Campo del mecanismo incorrecto\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "Error de dec64 en el caracter %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Datos binarios entrandes:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Datos salientes:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "Cadena RPA muy larga\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA falló abriendo /dev/urandom. Esto no debería\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    prevenir su ingreso, pero significa que\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    no se puede estar seguro de estar hablando\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    a el servicio que usted cree (son posibles\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    ataques de reintento por un servicio deshonesto).\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Desafío de usuario:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "Aplicando MD5 al bloque de datos:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "El resultado de MD5 es: \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "reenviando a %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (cuerpo de mensaje de rebote)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "correo de %s rebotado a %s\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "El error guardado es aún %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "Error de %cMTP: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr ""
+"Fallo en la apertura del archivo de BSMTP o en la escritura del preámbulo\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "Al servidor %cMTP no le gusta la dirección de recipiente `%s'\n"
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr ""
+"Al servidor %cMTP realmente no le gusta la dirección de recipiente `%s'\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "no hay direcciones coincidentes; no se configuró un postmaster.\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "¡ni siquiera es posible enviar a %s!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "no hay direcciones coincidentes; reenviando a %s.\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "a punto de entregar con: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "Fallo en la apertura de MDA\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "Fallo en la conexión de %cMTP a %s\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "no se puede despertar al servidor; recurriendo a %s"
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr "El MDA murió por la señal %d\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "El MDA devolvió un estado distinto a cero %d\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr "Extraño: pclose del MDA devolvió %d, no se puede manejar en %s:%d\n"
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Fallo la terminación del mensaje o el cerrado de BSMTP\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "El servidor SMTP rechazó la entrega\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "Error de entrega de LMTP en EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Respuesta diferente a 503 no esperada a LMTP EOM: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tEl Daemon Fetchmail\n"
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "Autenticación ESMTP CRAM-MD5...\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "El servidor rechazó el comando AUTH.\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "Mala respuesta base64 del server.\n"
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "Desafío decodificado: %s\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "Autenticación ESMTP PLAIN...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "Autenticación ESMTP LOGIN...\n"
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr "error de protocolo en el servidor smtp\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: malloc falló\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: par de sockets falló\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: fork falló\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "dup2 falló\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "ejecutando %s (anfitrión %s servicio %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "execvp(%s) falló\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: largo de dirección ilegal recibido de la máquina %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Organización emisora: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+"Cuidado: el Nombre de la Organización emisora es muy largo (posiblemente "
+"truncado).\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "Organización Desconocida\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "`CommonName' del emisor: %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+"Cuidado: el `CommonName' del emisor es muy largo (posiblemente truncado).\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "`CommonName' del emisor desconocido\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "`CommonName' del servidor: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "Certificado malo: el `CommonName' del sujeto es muy largo!\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "`CommonName' del Servidor no coincide: %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+"El nombre de servidor no fue configurado, ¡no fue posible verificar el "
+"certificado!\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "`CommonName' del Servidor desconocido\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "¡No se especifica el nombre del servidor en el certificado!\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "EVP_md5() falló\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "¡No hay memoria!\n"
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "¡El espacio para el resumen de texto es muy chico!\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "Huella digital de la llave %s: %s\n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "Las huellas digitales de %s coinciden.\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "¡Las huellas digitales de %s no coinciden!\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "Cuidado: la verificación del certificado del servidor: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "Emisor desconocido (primeros %d caracteres): %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Descriptor de archivo fuera de rango para SSL"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr ""
+"El protocolo SSL `%s' especificado es inválido, usando el defecto (SSLv23).\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr ""
+"¡La verificación de certificado/huella digital fue de algún modo saltada!\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr "Reintento de lectura del `socket' cygwin\n"
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr "¡Falló el reintento de lectura del `socket' cygwin\n"
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s mapeado al local %s\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "se atravesó %s coincidiendo con %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analizando línea `Received':\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "línea aceptada, %s es un alias del servidor de correo\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "línea rechazada, %s no es un alias del servidor de correo\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "no se encontró dirección `Received'\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "se encontró la dirección `Received' `%s'\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "delimitador de mensajes encontrado durante barrido de encabezados\n"
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "encabezado incorrecto encontrado durante la revisión de encabezados\n"
+
+#: transact.c:554
+#, c-format
+msgid "line: %s"
+msgstr "línea: %s"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "no hay coincidencias locales, reenviado a %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "reenvío y borrado suprimido debido a errores de DNS\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "escribiendo encabezados RFC822\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr ""
+"ninguna dirección de destino coincidió con los nombres locales declarados"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "la dirección de destino %s no coincide con algún nombre local"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "el mensaje contiene NULs"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "El servidor SMTP rechazó las direcciones locales de destino: "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "escribiendo texto del mensaje\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "Lista de UID viejas de %s:"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <vacía>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Lista borrador de UIDs:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, fuzzy, c-format
+msgid "Merged UID list from %s:"
+msgstr "Lista de UID viejas de %s:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "Lista de UID nuevas de %s:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "se intercambian listas de UID\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr ""
+"no se intercambian las listas de UID, no se encontraron UIDs en esta "
+"consulta\n"
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "se intercambian listas de UID\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "Borrando el archivo fetchids.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "Escribiendo el archivo fetchids.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "malloc falló\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "realloc falló\n"
diff --git a/po/fetchmail.diff b/po/fetchmail.diff
new file mode 100644
index 00000000..d0136f3b
--- /dev/null
+++ b/po/fetchmail.diff
@@ -0,0 +1,2877 @@
+--- BUILD/fetchmail-6.0.0/po/fr.po	2002-03-09 05:18:04.000000000 +0100
++++ fr.po	2002-09-18 17:33:48.000000000 +0200
+@@ -12,8 +12,8 @@
+ msgid ""
+ msgstr ""
+ "Project-Id-Version: fetchmail 5.9.8\n"
+-"POT-Creation-Date: 2000-04-21 00:22-0400\n"
+-"PO-Revision-Date: 2002-02-26 00:29+0100\n"
++"POT-Creation-Date: 2002-09-18 17:18+0200\n"
++"PO-Revision-Date: 2002-09-18 17:33+0200\n"
+ "Last-Translator: Thierry Vignaud <tvignaud@mandrakesoft.com>\n"
+ "Language-Team: fr <fr@li.org>\n"
+ "MIME-Version: 1.0\n"
+@@ -48,17 +48,17 @@
+ msgid "decoded as %s\n"
+ msgstr "Décodé comme %s\n"
+ 
+-#: driver.c:153
++#: driver.c:179
+ #, c-format
+ msgid "kerberos error %s\n"
+ msgstr "erreur kerberos %s\n"
+ 
+-#: driver.c:212 driver.c:217
++#: driver.c:238 driver.c:243
+ #, c-format
+ msgid "krb5_sendauth: %s [server says '%*s'] \n"
+ msgstr "krb5_sendauth: %s  [le serveur indique «%*s»] \n"
+ 
+-#: driver.c:298
++#: driver.c:324
+ #, c-format
+ msgid ""
+ "Subject: Fetchmail oversized-messages warning.\r\n"
+@@ -70,15 +70,15 @@
+ "Les messages suivants, qui sont trop grands, restent sur le serveur\n"
+ "de mail %s:"
+ 
+-#: driver.c:316
++#: driver.c:342
+ #, c-format
+ msgid "\t%d msg %d octets long skipped by fetchmail.\r\n"
+ msgstr "\tmessage %d de %d octets ignoré par fetchmail.\n"
+ 
+-#: driver.c:400
++#: driver.c:426
+ #, c-format
+-msgid "skipping message %d (%d octets)"
+-msgstr "message %d ignoré (%d octets)"
++msgid "skipping message %s@%s:%d (%d octets)"
++msgstr "message %s@%s:%d ignoré (%d octets)"
+ 
+ #.
+ #. * Invalid lengths are produced by Post Office/NT's
+@@ -90,94 +90,97 @@
+ #. * DELE succeeds but doesn't actually delete
+ #. * the message.
+ #.
+-#: driver.c:415
++#: driver.c:442
+ msgid " (length -1)"
+ msgstr " (longueur -1)"
+ 
+-#: driver.c:419
++#: driver.c:445
++msgid " (oversized)"
++msgstr " (trop volumineux)"
++
++#: driver.c:459
+ #, c-format
+-msgid " (oversized, %d octets)"
+-msgstr " (trop volumineux, %d octets)"
++msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
++msgstr "impossible de récupérer l'en-tete du message %s@%s:%d (%d octets)\n"
+ 
+-#: driver.c:443
++#: driver.c:476
+ #, c-format
+-msgid "reading message %d of %d"
+-msgstr "lecture du message %d parmi %d"
++msgid "reading message %s@%s:%d of %d"
++msgstr "lecture du message %s@%s:%d parmi %d"
+ 
+-#: driver.c:447
++#: driver.c:481
+ #, c-format
+ msgid " (%d %soctets)"
+ msgstr " (%d %soctets)"
+ 
+-#: driver.c:448
++#: driver.c:482
+ msgid "header "
+ msgstr "en-tête "
+ 
+-#: driver.c:506
++#: driver.c:553
+ #, c-format
+ msgid " (%d body octets) "
+ msgstr " (%d octets dans le corps) "
+ 
+-#: driver.c:579
++#: driver.c:621
+ #, c-format
+-msgid "message %d was not the expected length (%d actual != %d expected)\n"
+-msgstr ""
+-"le message %d n'est pas de la longueur attendue (%d actuelle != %d "
+-"attendue)\n"
++msgid ""
++"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
++msgstr "le message %s@%s:%d n'est pas de la longueur attendue (%d actuelle != %d attendue)\n"
+ 
+-#: driver.c:620
++#: driver.c:670
+ msgid " retained\n"
+ msgstr " conservé\n"
+ 
+-#: driver.c:628
++#: driver.c:678
+ msgid " flushed\n"
+ msgstr " éliminé\n"
+ 
+-#: driver.c:637
++#: driver.c:687
+ msgid " not flushed\n"
+ msgstr " non éliminé\n"
+ 
+-#: driver.c:642
++#: driver.c:692
+ #, c-format
+-msgid "fetchlimit %d reached; %d messages left on server\n"
+-msgstr "fetchlimit %d atteinte; %d messages demeurent sur le serveur\n"
++msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
++msgstr "fetchlimit %d atteinte; %d messages demeurent sur le serveur %s (compte %s)\n"
+ 
+-#: driver.c:702
++#: driver.c:752
+ msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+ msgstr "«SIGPIPE» envoyé par un MDA ou une erreur de «stream socket»\n"
+ 
+-#: driver.c:710
++#: driver.c:759
+ #, c-format
+ msgid "timeout after %d seconds waiting to connect to server %s.\n"
+ msgstr ""
+ "délai dépassé après %d secondes d'attente d'une connexion avec le serveur %"
+ "s.\n"
+ 
+-#: driver.c:714
++#: driver.c:763
+ #, c-format
+ msgid "timeout after %d seconds waiting for server %s.\n"
+ msgstr "délai dépassé après %d secondes d'attente du serveur %s.\n"
+ 
+-#: driver.c:718
++#: driver.c:767
+ #, c-format
+ msgid "timeout after %d seconds waiting for %s.\n"
+ msgstr "délai dépassé après %d secondes d'attente de %s.\n"
+ 
+-#: driver.c:723
++#: driver.c:772
+ #, c-format
+ msgid "timeout after %d seconds waiting for listener to respond.\n"
+ msgstr "délai dépassé après %d secondes d'attente de la réponse du client.\n"
+ 
+-#: driver.c:726
++#: driver.c:775
+ #, c-format
+ msgid "timeout after %d seconds.\n"
+ msgstr "délai d'attente dépassé après %d secondes.\n"
+ 
+-#: driver.c:738
++#: driver.c:787
+ msgid "Subject: fetchmail sees repeated timeouts\r\n"
+ msgstr "Subject: fetchmail a rencontré plusieurs dépassements de délais\r\n"
+ 
+-#: driver.c:740
++#: driver.c:789
+ #, c-format
+ msgid ""
+ "Fetchmail saw more than %d timeouts while attempting to get mail from %s@%s."
+@@ -186,7 +189,7 @@
+ "Fetchmail a rencontré plus de %d dépassements de délais en attendant du "
+ "courrier de %s@%s.\r\n"
+ 
+-#: driver.c:745
++#: driver.c:794
+ msgid ""
+ "This could mean that your mailserver is stuck, or that your SMTP\r\n"
+ "server is wedged, or that your mailbox file on the server has been\r\n"
+@@ -204,42 +207,56 @@
+ "Fetchmail n'interrogera pas de nouveau cette boîte aux lettres\r\n"
+ "tant que vous ne l'aurez pas redémarré.\r\n"
+ 
+-#: driver.c:781
++#: driver.c:824
+ #, c-format
+ msgid "pre-connection command failed with status %d\n"
+ msgstr "la commande de pré-connexion a échoué avec l'état %d\n"
+ 
+-#: driver.c:815
++#: driver.c:855
++#, c-format
++msgid "couldn't find HESIOD pobox for %s\n"
++msgstr "impossible de trouver la boîte HESIOD pour %s\n"
++
++#: driver.c:877
++msgid "Lead server has no name.\n"
++msgstr "Le serveur principal n'a pas de nom\n"
++
++#: driver.c:900
++#, c-format
++msgid "couldn't find canonical DNS name of %s\n"
++msgstr "impossible de trouver le nom canonique DNS de %s\n"
++
++#: driver.c:937
+ msgid "internal inconsistency\n"
+ msgstr "inconsistance interne\n"
+ 
+-#: driver.c:825
++#: driver.c:947
+ #, c-format
+ msgid "%s connection to %s failed"
+ msgstr "Échec de connexion %s avec %s"
+ 
+-#: driver.c:831
++#: driver.c:953
+ msgid "host is unknown."
+ msgstr "hôte inconnu."
+ 
+-#: driver.c:834
++#: driver.c:956
+ msgid "name is valid but has no IP address."
+ msgstr "le nom est valide mais ne correspond à aucune adresse IP."
+ 
+-#: driver.c:837
++#: driver.c:959
+ msgid "unrecoverable name server error."
+ msgstr "erreur irrécupérable avec le serveur de noms."
+ 
+-#: driver.c:839
++#: driver.c:961
+ msgid "temporary name server error."
+ msgstr "erreur temporaire avec le serveur de noms."
+ 
+-#: driver.c:846
++#: driver.c:968
+ #, c-format
+ msgid "unknown DNS error %d."
+ msgstr "erreur DNS inconnue %d."
+ 
+-#: driver.c:864
++#: driver.c:986
+ #, c-format
+ msgid ""
+ "Subject: Fetchmail unreachable-server warning.\r\n"
+@@ -250,40 +267,40 @@
+ "\r\n"
+ "Fetchmail ne peut pas accéder au serveur de mail %s:"
+ 
+-#: driver.c:889
++#: driver.c:1015 imap.c:374 pop3.c:258
+ msgid "SSL connection failed.\n"
+ msgstr "Échec de la connexion SSL\n"
+ 
+-#: driver.c:931
++#: driver.c:1067
+ #, c-format
+ msgid "Lock-busy error on %s@%s\n"
+ msgstr "Erreur «lock-busy» sur %s@%s\n"
+ 
+-#: driver.c:935
++#: driver.c:1071
+ #, c-format
+ msgid "Server busy error on %s@%s\n"
+ msgstr "Erreur «busy» sur %s@%s\n"
+ 
+-#: driver.c:940
++#: driver.c:1076
+ #, c-format
+ msgid "Authorization failure on %s@%s%s\n"
+ msgstr "Échec de l'autorisation sur %s@%s%s\n"
+ 
+-#: driver.c:943
++#: driver.c:1079
+ msgid " (previously authorized)"
+ msgstr " (précédemment autorisée)"
+ 
+-#: driver.c:964
++#: driver.c:1100
+ #, c-format
+ msgid "Subject: fetchmail authentication failed on %s@%s\r\n"
+ msgstr "Subject: l'authentification de fetchmail a échoué sur %s@%s\r\n"
+ 
+-#: driver.c:967
++#: driver.c:1103
+ #, c-format
+ msgid "Fetchmail could not get mail from %s@%s.\r\n"
+ msgstr "Fetchmail n'a pu recevoir le courrier de %s@%s.\r\n"
+ 
+-#: driver.c:971
++#: driver.c:1107
+ msgid ""
+ "The attempt to get authorization failed.\r\n"
+ "Since we have already succeeded in getting authorization for this\r\n"
+@@ -300,7 +317,7 @@
+ "is restored."
+ msgstr ""
+ 
+-#: driver.c:986
++#: driver.c:1122
+ msgid ""
+ "The attempt to get authorization failed.\r\n"
+ "This probably means your password is invalid, but some servers have\r\n"
+@@ -322,303 +339,324 @@
+ "le service soit réactivé.\r\n"
+ "\r"
+ 
+-#: driver.c:999
++#: driver.c:1136
++#, c-format
++msgid "Repoll immediately on %s@%s\n"
++msgstr ""
++
++#: driver.c:1141
+ #, c-format
+ msgid "Unknown login or authentication error on %s@%s\n"
+ msgstr "Erreur de login ou d'identification inconnue pour %s@%s\n"
+ 
+-#: driver.c:1023
++#: driver.c:1165
+ #, c-format
+ msgid "Authorization OK on %s@%s\n"
+ msgstr "Autorisation OK sur %s@%s\n"
+ 
+-#: driver.c:1029
++#: driver.c:1171
+ #, c-format
+ msgid "Subject: fetchmail authentication OK on %s@%s\r\n"
+ msgstr "Subject: l'authentification de fetchmail a réussie sur %s@%s\r\n"
+ 
+-#: driver.c:1032
++#: driver.c:1174
+ #, c-format
+ msgid "Fetchmail was able to log into %s@%s.\r\n"
+ msgstr "Fetchmail n'a pu enregistrer dans le journal (%s@%s).\r\n"
+ 
+-#: driver.c:1036
++#: driver.c:1178
+ msgid "Service has been restored.\r\n"
+ msgstr "Le service a été réactivé\r\n"
+ 
+-#: driver.c:1067
++#: driver.c:1209
+ #, c-format
+ msgid "selecting or re-polling folder %s\n"
+ msgstr "sélection ou re-réception du dossier %s\n"
+ 
+-#: driver.c:1069
++#: driver.c:1211
+ msgid "selecting or re-polling default folder\n"
+ msgstr "sélection ou re-réception du dossier par défaut\n"
+ 
+-#: driver.c:1085
++#: driver.c:1227
+ #, c-format
+ msgid "%s at %s (folder %s)"
+ msgstr "%s dans %s (dossier %s)"
+ 
+-#: driver.c:1093
++#: driver.c:1235 rcfile_y.y:395
+ #, c-format
+ msgid "%s at %s"
+ msgstr "%s dans %s"
+ 
+ #. only used for ETRN
+-#: driver.c:1098
++#: driver.c:1240
+ #, c-format
+ msgid "Polling %s\n"
+ msgstr "Réception de %s\n"
+ 
+-#: driver.c:1102
++#: driver.c:1244
+ #, c-format
+ msgid "%d %s (%d seen) for %s"
+ msgstr "%d %s (%d vu) pour %s"
+ 
+-#: driver.c:1103 driver.c:1108
++#: driver.c:1245 driver.c:1250
+ msgid "messages"
+ msgstr "messages"
+ 
+-#: driver.c:1104 driver.c:1109
++#: driver.c:1246 driver.c:1251
+ msgid "message"
+ msgstr "message"
+ 
+-#: driver.c:1107
++#: driver.c:1249
+ #, c-format
+ msgid "%d %s for %s"
+ msgstr "%d %s pour %s"
+ 
+-#: driver.c:1113
++#: driver.c:1255
+ #, c-format
+ msgid " (%d octets).\n"
+ msgstr " (%d octets).\n"
+ 
+-#: driver.c:1119
++#: driver.c:1261
+ #, c-format
+ msgid "No mail for %s\n"
+ msgstr "Aucun message pour %s\n"
+ 
+-#: driver.c:1265
++#: driver.c:1324
++msgid "bogus message count!"
++msgstr "mauvais nombre de messages!"
++
++#: driver.c:1438
+ msgid "socket"
+ msgstr "socket"
+ 
+-#: driver.c:1268
++#: driver.c:1441
+ msgid "missing or bad RFC822 header"
+ msgstr "l'en-tête RFC822 est manquant ou endommagé"
+ 
+-#: driver.c:1271
++#: driver.c:1444
+ msgid "MDA"
+ msgstr "MDA"
+ 
+-#: driver.c:1274
++#: driver.c:1447
+ msgid "client/server synchronization"
+ msgstr "synchronisation client/serveur"
+ 
+-#: driver.c:1277
++#: driver.c:1450
+ msgid "client/server protocol"
+ msgstr "protocole client/serveur"
+ 
+-#: driver.c:1280
++#: driver.c:1453
+ msgid "lock busy on server"
+ msgstr "verrou actif sur le serveur"
+ 
+-#: driver.c:1283
++#: driver.c:1456
+ msgid "SMTP transaction"
+ msgstr "Transaction SMTP"
+ 
+-#: driver.c:1286
++#: driver.c:1459
+ msgid "DNS lookup"
+ msgstr "requête au DNS"
+ 
+-#: driver.c:1289
++#: driver.c:1462
+ msgid "undefined error\n"
+ msgstr "erreur non définie\n"
+ 
+-#: driver.c:1300
++#: driver.c:1473
+ #, c-format
+ msgid "%s error while delivering to SMTP host %s\n"
+ msgstr "erreur %s durant l'envoi vers le serveur SMTP %s\n"
+ 
+-#: driver.c:1302
++#: driver.c:1475
+ #, c-format
+ msgid "%s error while fetching from %s\n"
+ msgstr "erreur %s durant la réception de %s\n"
+ 
+-#: driver.c:1310
++#: driver.c:1483
+ #, c-format
+ msgid "post-connection command failed with status %d\n"
+ msgstr "la commande de post-connexion a échoué avec l'état %d\n"
+ 
+-#: driver.c:1330
++#: driver.c:1503
+ msgid "Kerberos V4 support not linked.\n"
+ msgstr "Support de Kerberos V4 non inclus.\n"
+ 
+-#: driver.c:1338
++#: driver.c:1511
+ msgid "Kerberos V5 support not linked.\n"
+ msgstr "Support de Kerberos V5 non inclus.\n"
+ 
+-#: driver.c:1349
++#: driver.c:1522
+ #, c-format
+ msgid "Option --flush is not supported with %s\n"
+ msgstr "Option --flush non supportée avec %s\n"
+ 
+-#: driver.c:1355
++#: driver.c:1528
+ #, c-format
+ msgid "Option --all is not supported with %s\n"
+ msgstr "Option --all non supportée avec %s\n"
+ 
+-#: driver.c:1363
++#: driver.c:1536
+ #, c-format
+ msgid "Option --limit is not supported with %s\n"
+ msgstr "Option --limit non supportée avec %s\n"
+ 
+-#: env.c:51
++#: env.c:60
++#, c-format
++msgid ""
++"%s: The QMAILINJECT environment variable is set.\n"
++"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
++"tamper with your From: or Message-ID: headers.\n"
++"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
++"%s: Abort.\n"
++msgstr ""
++
++#: env.c:72
++#, c-format
++msgid ""
++"%s: The NULLMAILER_FLAGS environment variable is set.\n"
++"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
++"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
++"headers.\n"
++"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
++"%s: Abort.\n"
++msgstr ""
++
++#: env.c:84
+ #, c-format
+ msgid "%s: You don't exist.  Go away.\n"
+ msgstr "%s: Vous n'existez pas.  Allez vous en.\n"
+ 
+-#: env.c:117
++#: env.c:145
+ #, c-format
+ msgid "%s: can't determine your host!"
+ msgstr "%s: impossible de déterminer le nom de votre hôte !"
+ 
+-#: env.c:133
++#: env.c:161
+ #, c-format
+ msgid "gethostbyname failed for %s\n"
+ msgstr "«gethostbyname» a échoué pour %s\n"
+ 
+-#: report.c:101
+-msgid "Unknown system error"
+-msgstr "Erreur système inconnue"
+-
+-#: report.c:128
+-#, c-format
+-msgid "%s (log message incomplete)"
+-msgstr "%s (message de trace incomplet)"
+-
+-#: report.c:286 report.c:314 report.c:386 report.c:414
+-msgid "partial error message buffer overflow"
+-msgstr "erreur partielle de surcharge du tampon de message"
+-
+-#: etrn.c:45 odmr.c:53
++#: etrn.c:47 odmr.c:58
+ #, c-format
+ msgid "%s's SMTP listener does not support ESMTP\n"
+ msgstr "Le serveur SMTP de %s ne supporte pas ESMTP\n"
+ 
+-#: etrn.c:51
++#: etrn.c:53
+ #, c-format
+ msgid "%s's SMTP listener does not support ETRN\n"
+ msgstr "Le serveur SMTP de %s ne supporte pas ETRN\n"
+ 
+-#: etrn.c:75
++#: etrn.c:77
+ #, c-format
+ msgid "Queuing for %s started\n"
+ msgstr "Queue pour %s initiée\n"
+ 
+-#: etrn.c:80
++#: etrn.c:82
+ #, c-format
+ msgid "No messages waiting for %s\n"
+ msgstr "Aucun message en attente pour %s\n"
+ 
+-#: etrn.c:86
++#: etrn.c:88
+ #, c-format
+ msgid "Pending messages for %s started\n"
+ msgstr "Messages en attente pour %s initiés\n"
+ 
+ #. Unable to queue messages for node <x>
+-#: etrn.c:90
++#: etrn.c:92
+ #, c-format
+ msgid "Unable to queue messages for node %s\n"
+ msgstr "Impossible de placer les messages pour le noeud %s en queue\n"
+ 
+ #. Node <x> not allowed: <reason>
+-#: etrn.c:94
++#: etrn.c:96
+ #, c-format
+ msgid "Node %s not allowed: %s\n"
+ msgstr "Noeud %s non permis : %s\n"
+ 
+ #. Syntax Error
+-#: etrn.c:98
++#: etrn.c:100
+ msgid "ETRN syntax error\n"
+ msgstr "Erreur de syntaxe ETRN\n"
+ 
+ #. Syntax Error in Parameters
+-#: etrn.c:102
++#: etrn.c:104
+ msgid "ETRN syntax error in parameters\n"
+ msgstr "Erreur de syntaxe ETRN dans les paramètres\n"
+ 
+-#: etrn.c:106
++#: etrn.c:108
+ #, c-format
+ msgid "Unknown ETRN error %d\n"
+ msgstr "Erreur ETRN inconnue %d\n"
+ 
+-#: etrn.c:151
++#: etrn.c:153
+ msgid "Option --keep is not supported with ETRN\n"
+ msgstr "Option --keep non supportée avec ETRN\n"
+ 
+-#: etrn.c:155
++#: etrn.c:157
+ msgid "Option --flush is not supported with ETRN\n"
+ msgstr "Option --keep non supportée avec ETRN\n"
+ 
+-#: etrn.c:159
++#: etrn.c:161
+ msgid "Option --remote is not supported with ETRN\n"
+ msgstr "Option --remote non supportée avec ETRN\n"
+ 
+-#: etrn.c:163
++#: etrn.c:165
+ msgid "Option --check is not supported with ETRN\n"
+ msgstr "Option --check non supportée avec ETRN\n"
+ 
+-#: fetchmail.c:161
++#: fetchmail.c:155
+ msgid "fetchmail: invoked with"
+ msgstr "fetchmail appellé avec"
+ 
+-#: fetchmail.c:190
++#: fetchmail.c:179
++msgid "could not get current working directory\n"
++msgstr "impossible de trouver le répertoire de travail courrant\n"
++
++#: fetchmail.c:189
+ #, c-format
+ msgid "This is fetchmail release %s"
+ msgstr "Ceci est fetchmail, version %s"
+ 
+-#: fetchmail.c:327
++#: fetchmail.c:330
+ #, c-format
+ msgid "Taking options from command line%s%s\n"
+ msgstr "Lecture des options sur la ligne de commande %s%s\n"
+ 
+-#: fetchmail.c:328
++#: fetchmail.c:331
+ msgid " and "
+ msgstr " et "
+ 
+-#: fetchmail.c:333
++#: fetchmail.c:336
+ #, c-format
+ msgid "No mailservers set up -- perhaps %s is missing?\n"
+ msgstr "Pas de serveur de courrier paramétré -- %s est peut-être manquant ?\n"
+ 
+-#: fetchmail.c:354
++#: fetchmail.c:357
+ msgid "fetchmail: no mailservers have been specified.\n"
+ msgstr "fetchmail: aucun serveur de courrier n'a été spécifié.\n"
+ 
+-#: fetchmail.c:363
++#: fetchmail.c:366
+ msgid "fetchmail: no other fetchmail is running\n"
+ msgstr "fetchmail: aucun autre fetchmail n'est en cours d'exécution\n"
+ 
+-#: fetchmail.c:369
++#: fetchmail.c:372
+ #, c-format
+ msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+ msgstr "fetchmail: erreur en terminant %s fetchmail (%d); abandon.\n"
+ 
+-#: fetchmail.c:370 fetchmail.c:376
++#: fetchmail.c:373 fetchmail.c:379
+ msgid "background"
+ msgstr "tâche de fond"
+ 
+-#: fetchmail.c:370 fetchmail.c:376
++#: fetchmail.c:373 fetchmail.c:379
+ msgid "foreground"
+ msgstr "premier plan"
+ 
+-#: fetchmail.c:375
++#: fetchmail.c:378
+ #, c-format
+ msgid "fetchmail: %s fetchmail at %d killed.\n"
+ msgstr "fetchmail: %s fetchmail (%d) terminé.\n"
+ 
+-#: fetchmail.c:391
++#: fetchmail.c:394
+ msgid ""
+ "fetchmail: can't check mail while another fetchmail to same host is "
+ "running.\n"
+@@ -626,7 +664,7 @@
+ "fetchmail: impossible de vérifier le courrier lorsqu'un autre fetchmail est "
+ "exécuté sur le même hôte\n"
+ 
+-#: fetchmail.c:397
++#: fetchmail.c:400
+ #, c-format
+ msgid ""
+ "fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+@@ -634,13 +672,13 @@
+ "fetchmail: impossible de récupérer le courrier si un autre fetchmail est "
+ "exécuté sur %d.\n"
+ 
+-#: fetchmail.c:404
++#: fetchmail.c:407
+ #, c-format
+ msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+ msgstr ""
+ "fetchmail: un autre fetchmail, au premier plan, est en exécution sur %d.\n"
+ 
+-#: fetchmail.c:416
++#: fetchmail.c:417
+ msgid ""
+ "fetchmail: can't accept options while a background fetchmail is running.\n"
+ msgstr ""
+@@ -667,139 +705,152 @@
+ msgid "Enter password for %s@%s: "
+ msgstr "Entrez le mot de passe pour %s@%s : "
+ 
+-#: fetchmail.c:486
++#: fetchmail.c:487
+ #, c-format
+ msgid "starting fetchmail %s daemon \n"
+ msgstr "démarrage de fetchmail %s en tâche de fond \n"
+ 
+-#: fetchmail.c:540
++#: fetchmail.c:502 fetchmail.c:504
++#, c-format
++msgid "could not open %s to append logs to \n"
++msgstr "impossible d'ouvrir %s pour y ajouter les messages\n"
++
++#: fetchmail.c:542
+ #, c-format
+ msgid "couldn't time-check %s (error %d)\n"
+ msgstr "«time-check» %s impossible (erreur %d)\n"
+ 
+-#: fetchmail.c:545
++#: fetchmail.c:547
+ #, c-format
+ msgid "restarting fetchmail (%s changed)\n"
+ msgstr "redémarrage de fetchmail (%s  a changé)\n"
+ 
+-#: fetchmail.c:570
++#: fetchmail.c:552
++msgid "attempt to re-exec may fail as directory has not been restored\n"
++msgstr "la tentative de réexécution peut échouer car le répertoire n'a pas été recréé\n"
++
++#: fetchmail.c:579
+ msgid "attempt to re-exec fetchmail failed\n"
+ msgstr "la tentative d'exécuter à nouveau fetchmail a échoué\n"
+ 
+-#: fetchmail.c:598
++#: fetchmail.c:607
+ #, c-format
+ msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+ msgstr ""
+ "réception de %s ignorée (authentification échouée ou dépassements de "
+ "délais)\n"
+ 
+-#: fetchmail.c:610
++#: fetchmail.c:619
+ #, c-format
+ msgid "interval not reached, not querying %s\n"
+ msgstr "intervalle non atteint, pas de requête vers %s\n"
+ 
+-#: fetchmail.c:641
++#: fetchmail.c:650
+ msgid "Query status=0 (SUCCESS)\n"
+ msgstr "État de la requête=0 (SUCCES)\n"
+ 
+-#: fetchmail.c:643
++#: fetchmail.c:652
+ msgid "Query status=1 (NOMAIL)\n"
+ msgstr "État de la requête=1 (PAS DE MAIL)\n"
+ 
+-#: fetchmail.c:645
++#: fetchmail.c:654
+ msgid "Query status=2 (SOCKET)\n"
+ msgstr "État de la requête=2 (SOCKET)\n"
+ 
+-#: fetchmail.c:647
++#: fetchmail.c:656
+ msgid "Query status=3 (AUTHFAIL)\n"
+ msgstr "État de la requête=3 (ECHEC DE L'AUTHENTIFICATION)\n"
+ 
+-#: fetchmail.c:649
++#: fetchmail.c:658
+ msgid "Query status=4 (PROTOCOL)\n"
+ msgstr "État de la requête=4 (PROTOCOLE)\n"
+ 
+-#: fetchmail.c:651
++#: fetchmail.c:660
+ msgid "Query status=5 (SYNTAX)\n"
+ msgstr "État de la requête=5 (SYNTAXE)\n"
+ 
+-#: fetchmail.c:653
++#: fetchmail.c:662
+ msgid "Query status=6 (IOERR)\n"
+ msgstr "État de la requête=6 (ERREUR E/S)\n"
+ 
+-#: fetchmail.c:655
++#: fetchmail.c:664
+ msgid "Query status=7 (ERROR)\n"
+ msgstr "État de la requête=7 (ERREUR)\n"
+ 
+-#: fetchmail.c:657
++#: fetchmail.c:666
+ msgid "Query status=8 (EXCLUDE)\n"
+ msgstr "État de la requête=8 (EXCLU)\n"
+ 
+-#: fetchmail.c:659
++#: fetchmail.c:668
+ msgid "Query status=9 (LOCKBUSY)\n"
+ msgstr "État de la requête=9 (verrou déjà pris)\n"
+ 
+-#: fetchmail.c:661
++#: fetchmail.c:670
+ msgid "Query status=10 (SMTP)\n"
+ msgstr "État de la requête=10 (SMTP)\n"
+ 
+-#: fetchmail.c:663
++#: fetchmail.c:672
+ msgid "Query status=11 (DNS)\n"
+ msgstr "État de la requête=11 (DNS)\n"
+ 
+-#: fetchmail.c:665
++#: fetchmail.c:674
+ msgid "Query status=12 (BSMTP)\n"
+ msgstr "État de la requête=12 (BSMTP)\n"
+ 
+-#: fetchmail.c:667
++#: fetchmail.c:676
+ msgid "Query status=13 (MAXFETCH)\n"
+ msgstr "État de la requête=13 (NOMBRE MAXIMUM DE MESSAGES ATTEINT)\n"
+ 
+-#: fetchmail.c:669
++#: fetchmail.c:678
+ #, c-format
+ msgid "Query status=%d\n"
+ msgstr "État de la requête=%d\n"
+ 
+-#: fetchmail.c:715
++#: fetchmail.c:724
+ msgid "All connections are wedged.  Exiting.\n"
+ msgstr "Toutes les connexions sont établies. Terminé.\n"
+ 
+-#: fetchmail.c:722
++#: fetchmail.c:731
+ #, c-format
+-msgid "fetchmail: sleeping at %s\n"
+-msgstr "fetchmail: mise en sommeil à %s\n"
++msgid "sleeping at %s\n"
++msgstr "mise en sommeil à %s\n"
+ 
+-#: fetchmail.c:734
++#: fetchmail.c:755
+ #, c-format
+ msgid "awakened by %s\n"
+ msgstr "réveillé par %s\n"
+ 
+-#: fetchmail.c:737
++#: fetchmail.c:758
+ #, c-format
+ msgid "awakened by signal %d\n"
+ msgstr "réveillé par un signal %d\n"
+ 
+-#: fetchmail.c:744
++#: fetchmail.c:765
+ #, c-format
+ msgid "awakened at %s\n"
+ msgstr "réveillé à %s\n"
+ 
+-#: fetchmail.c:750
++#: fetchmail.c:771
+ #, c-format
+ msgid "normal termination, status %d\n"
+ msgstr "terminaison normale, état %d\n"
+ 
+-#: fetchmail.c:893
++#: fetchmail.c:920
+ msgid "couldn't time-check the run-control file\n"
+ msgstr "impossible de «time-check» le fichier run-control\n"
+ 
+-#: fetchmail.c:926
++#: fetchmail.c:953
+ #, c-format
+ msgid "Warning: multiple mentions of host %s in config file\n"
+ msgstr ""
+ "Attention : plusieurs mentions de l'hôte %s dans le fichier de "
+ "configuration\n"
+ 
+-#: fetchmail.c:1076
++#: fetchmail.c:1095
++msgid "SSL support is not compiled in.\n"
++msgstr "Le support de SSL n'est pas été activé à la compilation.\n"
++
++#: fetchmail.c:1126
+ #, c-format
+ msgid ""
+ "fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+@@ -807,607 +858,598 @@
+ "fetchmail: attention: aucun DNS disponible pour vérifier les réceptions "
+ "«multidrop» depuis %s\n"
+ 
+-#: fetchmail.c:1100
+-#, c-format
+-msgid "couldn't find HESIOD pobox for %s\n"
+-msgstr "impossible de trouver la boîte HESIOD pour %s\n"
+-
+-#: fetchmail.c:1118
+-msgid "Lead server has no name.\n"
+-msgstr "Le serveur principal n'a pas de nom\n"
+-
+-#: fetchmail.c:1139 fetchmail.c:1170
+-#, c-format
+-msgid "couldn't find canonical DNS name of %s\n"
+-msgstr "impossible de trouver le nom canonique DNS de %s\n"
+-
+-#: fetchmail.c:1210
++#: fetchmail.c:1143
+ #, c-format
+ msgid "%s configuration invalid, port number cannot be negative\n"
+ msgstr "configuration de %s invalide, le numéro de port ne peut être négatif\n"
+ 
+-#: fetchmail.c:1217
++#: fetchmail.c:1150
+ #, c-format
+ msgid "%s configuration invalid, RPOP requires a privileged port\n"
+ msgstr "configuration de %s invalide, RPOP requiert un port privilégié\n"
+ 
+-#: fetchmail.c:1233
++#: fetchmail.c:1166
+ #, c-format
+ msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+ msgstr ""
+ "configuration de %s invalide, LMTP ne peut utiliser le port SMTP par défaut\n"
+ 
+-#: fetchmail.c:1248
++#: fetchmail.c:1181
+ msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+ msgstr "Utiliser «fetchall» et «keep» ensemble en mode démon est une erreur!\n"
+ 
+-#: fetchmail.c:1287
+-msgid "all mailserver name lookups failed, exiting\n"
+-msgstr " toutes les tentatives pour résoudre le nom du serveur de mail ont échouées. Fin du processus.\n"
+-
+-#: fetchmail.c:1316
++#: fetchmail.c:1231
+ #, c-format
+ msgid "terminated with signal %d\n"
+ msgstr "terminé par un signal %d\n"
+ 
+-#: fetchmail.c:1406
++#: fetchmail.c:1316
+ #, c-format
+-msgid "%s querying %s (protocol %s) at %s\n"
+-msgstr "%s interroge %s (protocole %s) à %s\n"
++msgid "%s querying %s (protocol %s) at %s: poll started\n"
++msgstr "%s interroge %s (protocole %s) à %s : intérrogation en cours\n"
+ 
+-#: fetchmail.c:1426
++#: fetchmail.c:1341
+ msgid "POP2 support is not configured.\n"
+ msgstr "Le support de POP2 n'est pas configuré.\n"
+ 
+-#: fetchmail.c:1436
++#: fetchmail.c:1353
+ msgid "POP3 support is not configured.\n"
+ msgstr "Le support de POP3 n'est pas configuré.\n"
+ 
+-#: fetchmail.c:1444
++#: fetchmail.c:1361
+ msgid "IMAP support is not configured.\n"
+ msgstr "Le support d'IMAP n'est pas configuré.\n"
+ 
+-#: fetchmail.c:1449
++#: fetchmail.c:1367
+ msgid "ETRN support is not configured.\n"
+ msgstr "Le support d'ETRN n'est pas configuré.\n"
+ 
+-#: fetchmail.c:1455
++#: fetchmail.c:1373
+ msgid "Cannot support ETRN without gethostbyname(2).\n"
+ msgstr "Impossible de supporter ETRN sans gethostbyname(2).\n"
+ 
+-#: fetchmail.c:1461
++#: fetchmail.c:1380
+ msgid "ODMR support is not configured.\n"
+ msgstr "Le support de ODMR n'est pas configuré.\n"
+ 
+-#: fetchmail.c:1467
++#: fetchmail.c:1386
+ msgid "Cannot support ODMR without gethostbyname(2).\n"
+ msgstr "Impossible de supporter ODMR sans gethostbyname(2).\n"
+ 
+-#: fetchmail.c:1472
++#: fetchmail.c:1392
+ msgid "unsupported protocol selected.\n"
+ msgstr "protocole sélectionné non supporté.\n"
+ 
+-#: fetchmail.c:1484
++#: fetchmail.c:1402
++#, c-format
++msgid "%s querying %s (protocol %s) at %s: poll completed\n"
++msgstr "%s interroge %s (protocole %s) à %s : interrogation finie\n"
++
++#: fetchmail.c:1419
+ #, c-format
+ msgid "Poll interval is %d seconds\n"
+ msgstr "L'intervalle entre les réceptions est de %d secondes\n"
+ 
+-#: fetchmail.c:1486
++#: fetchmail.c:1421
+ #, c-format
+ msgid "Logfile is %s\n"
+ msgstr "Le fichier de traces est %s\n"
+ 
+-#: fetchmail.c:1488
++#: fetchmail.c:1423
+ #, c-format
+ msgid "Idfile is %s\n"
+ msgstr "Le fichier des identificateurs est %s\n"
+ 
+-#: fetchmail.c:1491
++#: fetchmail.c:1426
+ msgid "Progress messages will be logged via syslog\n"
+ msgstr "Les messages de progression sont enregistrés via syslog\n"
+ 
+-#: fetchmail.c:1494
++#: fetchmail.c:1429
+ msgid "Fetchmail will masquerade and will not generate Received\n"
+ msgstr "Fetchmail va se masquer et ne générer aucun «Received»\n"
+ 
+-#: fetchmail.c:1496
++#: fetchmail.c:1431
+ msgid "Fetchmail will show progress dots even in logfiles.\n"
+ msgstr "Fetchmail affichera des points de progression, même dans le journal\n"
+ 
+-#: fetchmail.c:1498
++#: fetchmail.c:1433
+ #, c-format
+ msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+ msgstr ""
+ "Fetchmail réexpédiera les messages «multidrop» mal aiguillés vers %s.\n"
+ 
+-#: fetchmail.c:1502
++#: fetchmail.c:1437
+ msgid "Fetchmail will direct error mail to the postmaster.\n"
+ msgstr ""
+ "Fetchmail expédiera les erreurs de messagerie\n"
+ "au maître de poste.\n"
+ 
+-#: fetchmail.c:1504
++#: fetchmail.c:1439
+ msgid "Fetchmail will direct error mail to the sender.\n"
+ msgstr "Fetchmail expédiera les erreur de messagerie à l'envoyeur\n"
+ 
+-#: fetchmail.c:1511
++#: fetchmail.c:1446
+ #, c-format
+ msgid "Options for retrieving from %s@%s:\n"
+ msgstr "Options pour la réception depuis %s@%s:\n"
+ 
+-#: fetchmail.c:1515
++#: fetchmail.c:1450
+ #, c-format
+ msgid "  Mail will be retrieved via %s\n"
+ msgstr "  Le courrier sera reçu via %s\n"
+ 
+-#: fetchmail.c:1518
++#: fetchmail.c:1453
+ #, c-format
+ msgid "  Poll of this server will occur every %d intervals.\n"
+ msgstr "  La réception depuis ce serveur s'opérera tous les %d intervalles.\n"
+ 
+-#: fetchmail.c:1521
++#: fetchmail.c:1456
+ #, c-format
+ msgid "  True name of server is %s.\n"
+ msgstr "  Le vrai nom du serveur est %s.\n"
+ 
+-#: fetchmail.c:1523
++#: fetchmail.c:1458
+ #, c-format
+ msgid "  This host %s be queried when no host is specified.\n"
+ msgstr "  Cet hôte %s interrogé lorsqu'aucun hôte n'est spécifié.\n"
+ 
+-#: fetchmail.c:1524 fetchmail.c:1637 fetchmail.c:1640
++#: fetchmail.c:1459 fetchmail.c:1572 fetchmail.c:1575
+ msgid "will not"
+ msgstr "ne sera pas"
+ 
+-#: fetchmail.c:1524 fetchmail.c:1637 fetchmail.c:1640
++#: fetchmail.c:1459 fetchmail.c:1572 fetchmail.c:1575
+ msgid "will"
+ msgstr "sera"
+ 
+-#: fetchmail.c:1528
++#: fetchmail.c:1463
+ msgid "  Password will be prompted for.\n"
+ msgstr "  Le mot de passe sera requis.\n"
+ 
+-#: fetchmail.c:1532
++#: fetchmail.c:1467
+ #, c-format
+ msgid "  APOP secret = \"%s\".\n"
+ msgstr "  Secret APOP = \"%s\".\n"
+ 
+-#: fetchmail.c:1535
++#: fetchmail.c:1470
+ #, c-format
+ msgid "  RPOP id = \"%s\".\n"
+ msgstr "  Identification RPOP = \"%s\".\n"
+ 
+-#: fetchmail.c:1538
++#: fetchmail.c:1473
+ #, c-format
+ msgid "  Password = \"%s\".\n"
+ msgstr "  Mot de passe = \"%s\".\n"
+ 
+-#: fetchmail.c:1551
++#: fetchmail.c:1486
+ #, c-format
+ msgid "  Protocol is KPOP with Kerberos %s authentication"
+ msgstr "  Le protocole est KPOP avec authentification Kerberos %s"
+ 
+-#: fetchmail.c:1554
++#: fetchmail.c:1489
+ #, c-format
+ msgid "  Protocol is %s"
+ msgstr "  Le protocole est %s"
+ 
+-#: fetchmail.c:1557
++#: fetchmail.c:1492
+ #, c-format
+ msgid " (using service %s)"
+ msgstr " (utilisant le service %s)"
+ 
+-#: fetchmail.c:1559
++#: fetchmail.c:1494
+ #, c-format
+ msgid " (using network security options %s)"
+ msgstr " (utilisant les options réseaux de sécurité %s)"
+ 
+-#: fetchmail.c:1562
++#: fetchmail.c:1497
+ #, c-format
+ msgid " (using port %d)"
+ msgstr " (utilisant le port %d)"
+ 
+-#: fetchmail.c:1565
++#: fetchmail.c:1500
+ msgid " (using default port)"
+ msgstr " (utilisant le port par défaut)"
+ 
+-#: fetchmail.c:1567
++#: fetchmail.c:1502
+ msgid " (forcing UIDL use)"
+ msgstr " (forçant l'usage des UIDL)"
+ 
+-#: fetchmail.c:1573
++#: fetchmail.c:1508
+ msgid "  All available authentication methods will be tried.\n"
+ msgstr "  Toutes les méthodes d'authentification vont être essayées.\n"
+ 
+-#: fetchmail.c:1576
++#: fetchmail.c:1511
+ msgid "  Password authentication will be forced.\n"
+ msgstr "Authentification par mot de passe forcé.\n"
+ 
+-#: fetchmail.c:1579
++#: fetchmail.c:1514
+ msgid "  NTLM authentication will be forced.\n"
+ msgstr "L'authentification NTLM forcée.\n"
+ 
+-#: fetchmail.c:1582
++#: fetchmail.c:1517
+ msgid "  OTP authentication will be forced.\n"
+ msgstr "  Authentification OTP forcée.\n"
+ 
+-#: fetchmail.c:1585
++#: fetchmail.c:1520
+ msgid "  CRAM-Md5 authentication will be forced.\n"
+ msgstr "  Authentification CRAM-Md5 forcée.\n"
+ 
+-#: fetchmail.c:1588
++#: fetchmail.c:1523
+ msgid "  GSSAPI authentication will be forced.\n"
+ msgstr "  Authentification GSSAPI forcée.\n"
+ 
+-#: fetchmail.c:1591
++#: fetchmail.c:1526
+ msgid "  Kerberos V4 authentication will be forced.\n"
+ msgstr "  Authentification de Kerberos V4 forcée.\n"
+ 
+-#: fetchmail.c:1594
++#: fetchmail.c:1529
+ msgid "  Kerberos V5 authentication will be forced.\n"
+ msgstr " Authentification de Kerberos V5 forcée.\n"
+ 
+-#: fetchmail.c:1597
++#: fetchmail.c:1532
+ msgid "  End-to-end encryption assumed.\n"
+ msgstr "  cryptage «End-to-end» assumé.\n"
+ 
+-#: fetchmail.c:1601
++#: fetchmail.c:1536
+ #, c-format
+ msgid "  Mail service principal is: %s\n"
+ msgstr "  Le principal service de mail est: %s\n"
+ 
+-#: fetchmail.c:1604
++#: fetchmail.c:1539
+ msgid "  SSL encrypted sessions enabled.\n"
+ msgstr "  Les sessions encryptée SSL sont supportées.\n"
+ 
+-#: fetchmail.c:1606
++#: fetchmail.c:1541
+ msgid "  SSL server certificate checking enabled.\n"
+ msgstr "  Activation de la vérification des certificats du serveur SSL.\n"
+ 
+-#: fetchmail.c:1608
++#: fetchmail.c:1543
+ #, c-format
+ msgid "  SSL trusted certificate directory: %s\n"
+ msgstr "  Répertoire des certificats SSL surs: %s\n"
+ 
+-#: fetchmail.c:1611
++#: fetchmail.c:1546
+ #, c-format
+ msgid "  SSL key fingerprint (checked against the server key): %s\n"
+ msgstr "  Signature de la clé SSL (vérifié via le serveur de clés): %s\n"
+ 
+-#: fetchmail.c:1614
++#: fetchmail.c:1549
+ #, c-format
+ msgid "  Server nonresponse timeout is %d seconds"
+ msgstr "  Le délai d'attente d'une réponse du serveur est de %d secondes"
+ 
+-#: fetchmail.c:1616
++#: fetchmail.c:1551
+ msgid " (default).\n"
+ msgstr " (par défaut).\n"
+ 
+-#: fetchmail.c:1623
++#: fetchmail.c:1558
+ msgid "  Default mailbox selected.\n"
+ msgstr "  La boîte aux lettres par défaut est sélectionnée.\n"
+ 
+-#: fetchmail.c:1628
++#: fetchmail.c:1563
+ msgid "  Selected mailboxes are:"
+ msgstr "  Les boîtes aux lettres sélectionnées sont :"
+ 
+-#: fetchmail.c:1633
++#: fetchmail.c:1568
+ #, c-format
+ msgid "  %s messages will be retrieved (--all %s).\n"
+ msgstr "  %s messages seront reçus (--all %s).\n"
+ 
+-#: fetchmail.c:1634
++#: fetchmail.c:1569
+ msgid "All"
+ msgstr "Tous les"
+ 
+-#: fetchmail.c:1634
++#: fetchmail.c:1569
+ msgid "Only new"
+ msgstr "Uniquement les nouveaux"
+ 
+-#: fetchmail.c:1636
++#: fetchmail.c:1571
+ #, c-format
+ msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+ msgstr "  Tout message récupéré %s conservé sur le serveur (--keep %s).\n"
+ 
+-#: fetchmail.c:1639
++#: fetchmail.c:1574
+ #, c-format
+ msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+ msgstr ""
+ "  Tout ancien message %s éliminé avant relève du courrier (--flush %s).\n"
+ 
+-#: fetchmail.c:1642
++#: fetchmail.c:1577
+ #, c-format
+ msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+ msgstr "  La ré-écriture des adresses locales est %se (--norewrite %s).\n"
+ 
+-#: fetchmail.c:1643 fetchmail.c:1646 fetchmail.c:1649 fetchmail.c:1652
+-#: fetchmail.c:1655 fetchmail.c:1658 fetchmail.c:1791
++#: fetchmail.c:1578 fetchmail.c:1581 fetchmail.c:1584 fetchmail.c:1587
++#: fetchmail.c:1590 fetchmail.c:1593 fetchmail.c:1726
+ msgid "enabled"
+ msgstr "activé"
+ 
+-#: fetchmail.c:1643 fetchmail.c:1646 fetchmail.c:1649 fetchmail.c:1652
+-#: fetchmail.c:1655 fetchmail.c:1658 fetchmail.c:1791
++#: fetchmail.c:1578 fetchmail.c:1581 fetchmail.c:1584 fetchmail.c:1587
++#: fetchmail.c:1590 fetchmail.c:1593 fetchmail.c:1726
+ msgid "disabled"
+ msgstr "inactivé"
+ 
+-#: fetchmail.c:1645
++#: fetchmail.c:1580
+ #, c-format
+ msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+ msgstr "  La suppression des retour-chariots est %se (stripcr %s).\n"
+ 
+-#: fetchmail.c:1648
++#: fetchmail.c:1583
+ #, c-format
+ msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+ msgstr "  Le forçage des retour-chariots est %s (forcecr %s).\n"
+ 
+-#: fetchmail.c:1651
++#: fetchmail.c:1586
+ #, c-format
+ msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+ msgstr ""
+ "  L'interprétation des «Content-Transfer-Encoding» est %se (pass8bits %s).\n"
+ 
+-#: fetchmail.c:1654
++#: fetchmail.c:1589
+ #, c-format
+ msgid "  MIME decoding is %s (mimedecode %s).\n"
+ msgstr "  Le décodage MIME est %s (mimedecode %s).\n"
+ 
+-#: fetchmail.c:1657
++#: fetchmail.c:1592
+ #, c-format
+ msgid "  Idle after poll is %s (idle %s).\n"
+ msgstr "  L'inoccupation après la réception est %s (idle %s).\n"
+ 
+-#: fetchmail.c:1660
++#: fetchmail.c:1595
+ #, c-format
+ msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+ msgstr "  Les lignes «Status» non vides seront %ses (dropstatus %s).\n"
+ 
+-#: fetchmail.c:1661 fetchmail.c:1664
++#: fetchmail.c:1596 fetchmail.c:1599
+ msgid "discarded"
+ msgstr "ignoré"
+ 
+-#: fetchmail.c:1661 fetchmail.c:1664
++#: fetchmail.c:1596 fetchmail.c:1599
+ msgid "kept"
+ msgstr "conservé"
+ 
+-#: fetchmail.c:1663
++#: fetchmail.c:1598
+ #, c-format
+ msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+-msgstr "  Les lignes «Delivered-To» non vides seront %ses (dropdelivered %s).\n"
++msgstr ""
++"  Les lignes «Delivered-To» non vides seront %ses (dropdelivered %s).\n"
+ 
+-#: fetchmail.c:1669
++#: fetchmail.c:1604
+ #, c-format
+ msgid "  Message size limit is %d octets (--limit %d).\n"
+ msgstr "  La taille des messages est limitée à %d octets (--limit %d).\n"
+ 
+-#: fetchmail.c:1672
++#: fetchmail.c:1607
+ msgid "  No message size limit (--limit 0).\n"
+ msgstr "  La taille des messages n'est pas limitée (--limit 0).\n"
+ 
+-#: fetchmail.c:1674
++#: fetchmail.c:1609
+ #, c-format
+ msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+ msgstr ""
+ "  Alertes sur la taille des messages toutes les %d secondes (--warnings %"
+ "d).\n"
+ 
+-#: fetchmail.c:1677
++#: fetchmail.c:1612
+ msgid "  Size warnings on every poll (--warnings 0).\n"
+ msgstr ""
+ "  Alertes sur la taille des messages à chaque réception (--warnings 0).\n"
+ 
+-#: fetchmail.c:1680
++#: fetchmail.c:1615
+ #, c-format
+ msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+ msgstr "  Le nombre de messages reçu est limité à %d (--fetchlimit %d).\n"
+ 
+-#: fetchmail.c:1683
++#: fetchmail.c:1618
+ msgid "  No received-message limit (--fetchlimit 0).\n"
+ msgstr "  Le nombre de messages reçu n'est pas limité (--fetchlimit 0).\n"
+ 
+-#: fetchmail.c:1685
++#: fetchmail.c:1620
+ #, c-format
+ msgid "  SMTP message batch limit is %d.\n"
+ msgstr "  Le nombre de messages expédiés est limité à %d.\n"
+ 
+-#: fetchmail.c:1687
++#: fetchmail.c:1622
+ msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+ msgstr "  Le nombre de messages expédiés n'est pas limité (--batchlimit 0).\n"
+ 
+-#: fetchmail.c:1691
++#: fetchmail.c:1626
+ #, c-format
+ msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+ msgstr ""
+ "  Purge à chaque fois que %d messages ont été éliminés (--expunge %d).\n"
+ 
+-#: fetchmail.c:1693
++#: fetchmail.c:1628
+ msgid "  No forced expunges (--expunge 0).\n"
+ msgstr "  Aucune purge forcée n'aura lieu (--expunge 0).\n"
+ 
+-#: fetchmail.c:1700
++#: fetchmail.c:1635
+ msgid "  Domains for which mail will be fetched are:"
+ msgstr "  Domaines pour lesquels le mail est récupéré :"
+ 
+-#: fetchmail.c:1705 fetchmail.c:1725
++#: fetchmail.c:1640 fetchmail.c:1660
+ msgid " (default)"
+ msgstr " (par défaut)"
+ 
+-#: fetchmail.c:1710
++#: fetchmail.c:1645
+ #, c-format
+ msgid "  Messages will be appended to %s as BSMTP\n"
+ msgstr "  Les messages seront ajoutés après %s en tant que BSMTP\n"
+ 
+-#: fetchmail.c:1712
++#: fetchmail.c:1647
+ #, c-format
+ msgid "  Messages will be delivered with \"%s\".\n"
+ msgstr "  Les messages seront acheminés avec \"%s\".\n"
+ 
+-#: fetchmail.c:1719
++#: fetchmail.c:1654
+ #, c-format
+ msgid "  Messages will be %cMTP-forwarded to:"
+ msgstr "  Les messages seront réexpédiés via %cMTP vers :"
+ 
+-#: fetchmail.c:1730
++#: fetchmail.c:1665
+ #, c-format
+ msgid "  Host part of MAIL FROM line will be %s\n"
+ msgstr "  Le nom de la machine sur la ligne «MAIL FROM» sera %s\n"
+ 
+-#: fetchmail.c:1733
++#: fetchmail.c:1668
+ #, c-format
+ msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+ msgstr "  L'adresse placée après la commande SMTP 'RCPT TO' sera %s\n"
+ 
+-#: fetchmail.c:1742
++#: fetchmail.c:1677
+ msgid "  Recognized listener spam block responses are:"
+ msgstr "  Les réponses du serveur reconnaissant des blocs de «spam» sont :"
+ 
+-#: fetchmail.c:1748
++#: fetchmail.c:1683
+ msgid "  Spam-blocking disabled\n"
+ msgstr "  Le blocage du «spam» est inactivé\n"
+ 
+-#: fetchmail.c:1751
++#: fetchmail.c:1686
+ #, c-format
+ msgid "  Server connection will be brought up with \"%s\".\n"
+ msgstr "  La connexion au serveur sera initiée avec \"%s\".\n"
+ 
+-#: fetchmail.c:1754
++#: fetchmail.c:1689
+ msgid "  No pre-connection command.\n"
+ msgstr "  Aucune commande de pré-connexion définie.\n"
+ 
+-#: fetchmail.c:1756
++#: fetchmail.c:1691
+ #, c-format
+ msgid "  Server connection will be taken down with \"%s\".\n"
+ msgstr "  La connexion au serveur sera terminée avec \"%s\".\n"
+ 
+-#: fetchmail.c:1759
++#: fetchmail.c:1694
+ msgid "  No post-connection command.\n"
+ msgstr "  Aucune commande de post-connexion définie.\n"
+ 
+-#: fetchmail.c:1762
++#: fetchmail.c:1697
+ msgid "  No localnames declared for this host.\n"
+ msgstr "  Aucun nom local déclaré pour cet hôte.\n"
+ 
+-#: fetchmail.c:1772
++#: fetchmail.c:1707
+ msgid "  Multi-drop mode: "
+ msgstr "  Mode «multi-drop»: "
+ 
+-#: fetchmail.c:1774
++#: fetchmail.c:1709
+ msgid "  Single-drop mode: "
+ msgstr "  Mode «single-drop»: "
+ 
+-#: fetchmail.c:1776
++#: fetchmail.c:1711
+ #, c-format
+ msgid "%d local name(s) recognized.\n"
+ msgstr "%d nom(s) local(aux) reconnu(s).\n"
+ 
+-#: fetchmail.c:1790
++#: fetchmail.c:1725
+ #, c-format
+ msgid "  DNS lookup for multidrop addresses is %s.\n"
+ msgstr "  La requête DNS des adresses «multidrop» est %se.\n"
+ 
+-#: fetchmail.c:1794
++#: fetchmail.c:1729
+ msgid "  Server aliases will be compared with multidrop addresses by "
+ msgstr ""
+ "  Les alias du serveur seront comparés avec les adresses «multidrop» par "
+ 
+-#: fetchmail.c:1796
++#: fetchmail.c:1731
+ msgid "IP address.\n"
+ msgstr "adresse IP.\n"
+ 
+-#: fetchmail.c:1798
++#: fetchmail.c:1733
+ msgid "name.\n"
+ msgstr "nom.\n"
+ 
+-#: fetchmail.c:1801
++#: fetchmail.c:1736
+ msgid "  Envelope-address routing is disabled\n"
+ msgstr "  Le routage vers l'adresse d'enveloppe est inactivé\n"
+ 
+-#: fetchmail.c:1804
++#: fetchmail.c:1739
+ #, c-format
+ msgid "  Envelope header is assumed to be: %s\n"
+ msgstr "  L'en-tête d'enveloppe est pris comme étant : %s\n"
+ 
+-#: fetchmail.c:1805
++#: fetchmail.c:1740
+ msgid "Received"
+ msgstr "Received"
+ 
+-#: fetchmail.c:1807
++#: fetchmail.c:1742
+ #, c-format
+ msgid "  Number of envelope header to be parsed: %d\n"
+ msgstr "  Numéro de l'en-tête d'enveloppe devant être traité : %d\n"
+ 
+-#: fetchmail.c:1810
++#: fetchmail.c:1745
+ #, c-format
+ msgid "  Prefix %s will be removed from user id\n"
+ msgstr "  Le préfixe %s sera soustrait des id d'utilisateur\n"
+ 
+-#: fetchmail.c:1813
++#: fetchmail.c:1748
+ msgid "  No prefix stripping\n"
+ msgstr "  Aucun préfixe ne sera soustrait\n"
+ 
+-#: fetchmail.c:1820
++#: fetchmail.c:1755
+ msgid "  Predeclared mailserver aliases:"
+ msgstr "  Alias pré-déclarés du serveur de courrier :"
+ 
+-#: fetchmail.c:1829
++#: fetchmail.c:1764
+ msgid "  Local domains:"
+ msgstr "  Domaines locaux :"
+ 
+-#: fetchmail.c:1839
++#: fetchmail.c:1774
+ #, c-format
+ msgid "  Connection must be through interface %s.\n"
+ msgstr "  La connexion se fera via l'interface %s.\n"
+ 
+-#: fetchmail.c:1841
++#: fetchmail.c:1776
+ msgid "  No interface requirement specified.\n"
+ msgstr "  Aucun choix d'interface n'a été spécifié.\n"
+ 
+-#: fetchmail.c:1843
++#: fetchmail.c:1778
+ #, c-format
+ msgid "  Polling loop will monitor %s.\n"
+ msgstr "  La boucle de réception observera %s.\n"
+ 
+-#: fetchmail.c:1845
++#: fetchmail.c:1780
+ msgid "  No monitor interface specified.\n"
+ msgstr "  Aucune interface à observer n'a été spécifiée.\n"
+ 
+-#: fetchmail.c:1849
++#: fetchmail.c:1784
+ #, c-format
+ msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+ msgstr "  Connexions au serveur à travers le «plugin» %s (--plugin %s).\n"
+ 
+-#: fetchmail.c:1851
++#: fetchmail.c:1786
+ msgid "  No plugin command specified.\n"
+ msgstr "  Aucune commande de «plugin» n'a été spécifiée.\n"
+ 
+-#: fetchmail.c:1853
++#: fetchmail.c:1788
+ #, c-format
+ msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+ msgstr "  Connexions au client à travers le «plugout» %s (--plugout %s).\n"
+ 
+-#: fetchmail.c:1855
++#: fetchmail.c:1790
+ msgid "  No plugout command specified.\n"
+ msgstr "  Aucune commande de «plugout» n'a été spécifiée.\n"
+ 
+-#: fetchmail.c:1860
++#: fetchmail.c:1795
+ msgid "  No UIDs saved from this host.\n"
+ msgstr "  Aucun UID n'a été enregistré sur cet hôte.\n"
+ 
+-#: fetchmail.c:1869
++#: fetchmail.c:1804
+ #, c-format
+ msgid "  %d UIDs saved.\n"
+ msgstr "  %d UIDs enregistrés.\n"
+ 
+-#: fetchmail.c:1877
++#: fetchmail.c:1812
+ msgid "  Poll trace information will be added to the Received header.\n"
+-msgstr "  Information de traçage de la réception ajoutée aux en-tetes Received.\n"
++msgstr ""
++"  Information de traçage de la réception ajoutée aux en-tetes Received.\n"
+ 
+-#: fetchmail.c:1879
++#: fetchmail.c:1814
+ msgid ""
+ "  No poll trace information will be added to the Received header.\n"
+ ".\n"
+-msgstr "  Aucune ajout d'information de traçage de la réception aux en-tetes Received.\n"
++msgstr ""
++"  Aucune ajout d'information de traçage de la réception aux en-tetes "
++"Received.\n"
+ 
+-#: fetchmail.c:1882
++#: fetchmail.c:1817
+ #, c-format
+ msgid "  Pass-through properties \"%s\".\n"
+ msgstr "  Propriétés du passage \"%s\".\n"
+@@ -1416,7 +1458,7 @@
+ #. * This is a hack to help xgettext which cannot find strings in
+ #. * macro definitions like the one for xalloca above.
+ #.
+-#: fetchmail.h:549
++#: fetchmail.h:568 fetchmail.h:574
+ msgid "alloca failed"
+ msgstr "échec d'alloca"
+ 
+@@ -1450,177 +1492,187 @@
+ msgid "Error exchanging credentials\n"
+ msgstr "Erreur durant l'échange des credentials\n"
+ 
+-#: gssapi.c:140
++#: gssapi.c:144
+ msgid "Couldn't unwrap security level data\n"
+ msgstr "Impossible d'extraire les données du niveau de sécurité\n"
+ 
+-#: gssapi.c:145
++#: gssapi.c:149
+ msgid "Credential exchange complete\n"
+ msgstr "Echange des credentials terminé\n"
+ 
+-#: gssapi.c:149
++#: gssapi.c:153
+ msgid "Server requires integrity and/or privacy\n"
+ msgstr "Le serveur requiert des échanges intègres et/ou privés\n"
+ 
+-#: gssapi.c:158
++#: gssapi.c:162
+ #, c-format
+ msgid "Unwrapped security level flags: %s%s%s\n"
+ msgstr "Options du niveau de sécurité extraites : %s%s%s\n"
+ 
+-#: gssapi.c:162
++#: gssapi.c:166
+ #, c-format
+ msgid "Maximum GSS token size is %ld\n"
+ msgstr "La taille du composant GSS maximal est %ld\n"
+ 
+-#: gssapi.c:175
++#: gssapi.c:179
+ msgid "Error creating security level request\n"
+ msgstr "Erreur à la création de la requête de niveau de sécurité\n"
+ 
+-#: gssapi.c:186
++#: gssapi.c:190
+ msgid "Releasing GSS credentials\n"
+ msgstr "Lâchage des credentials GSS\n"
+ 
+-#: gssapi.c:189
++#: gssapi.c:193
+ msgid "Error releasing credentials\n"
+ msgstr "Erreur de relarguage des credentials\n"
+ 
+-#: idle.c:57
++#: idle.c:62
+ #, c-format
+ msgid "fetchmail: thread sleeping for %d sec.\n"
+ msgstr "fetchmail: mise en sommeil du thread pour %d secondes.\n"
+ 
+-#: imap.c:246
++#: imap.c:270
+ msgid "Protocol identified as IMAP4 rev 1\n"
+ msgstr "Protocole identifié comme étant IMAP4 rev \n"
+ 
+-#: imap.c:252
++#: imap.c:276
+ msgid "Protocol identified as IMAP4 rev 0\n"
+ msgstr "Protocole identifié comme étant IMAP4 rev 0\n"
+ 
+-#: imap.c:259
++#: imap.c:283
+ msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+ msgstr "Protocole identifié comme étant IMAP2 ou IMAP2BIS\n"
+ 
+-#: imap.c:283
++#: imap.c:307
+ msgid "will idle after poll\n"
+ msgstr "attendra après la réception\n"
+ 
+-#: imap.c:372
++#: imap.c:417
+ msgid "Required OTP capability not compiled into fetchmail\n"
+ msgstr "La fonctionnalité OTP requise n'est pas supportée par fetchmail\n"
+ 
+-#: imap.c:394
++#: imap.c:439
+ msgid "Required NTLM capability not compiled into fetchmail\n"
+ msgstr "La fonctionnalité NTLM requise n'est pas supportée par fetchmail.\n"
+ 
+-#: imap.c:403
++#: imap.c:448
+ msgid "Required LOGIN capability not supported by server\n"
+ msgstr "La fonction LOGIN requise n'est pas supportée par le serveur\n"
+ 
+-#: imap.c:491
++#: imap.c:533 imap.c:595
++#, fuzzy
++msgid "expunge failed\n"
++msgstr "échec de execvp(%s)\n"
++
++#: imap.c:551 imap.c:580
+ msgid "re-poll failed\n"
+ msgstr "échec durant la re-réception\n"
+ 
+-#: imap.c:499
++#: imap.c:559
+ #, c-format
+ msgid "%d messages waiting after re-poll\n"
+ msgstr "%d messages en attente après le nouveau poll\n"
+ 
+-#: imap.c:508
++#: imap.c:569
+ msgid "mailbox selection failed\n"
+ msgstr "échec de la sélection de boîte aux lettres\n"
+ 
+-#: imap.c:512
++#: imap.c:573
+ #, c-format
+ msgid "%d messages waiting after first poll\n"
+ msgstr "%d messages en attente après le premier poll\n"
+ 
+-#: imap.c:535
++#: imap.c:599
++#, fuzzy, c-format
++msgid "%d messages waiting after expunge\n"
++msgstr "%d messages en attente après le nouveau poll\n"
++
++#: imap.c:620
+ msgid "search for unseen messages failed\n"
+ msgstr "échec de la recherche des messages non-vus\n"
+ 
+-#: imap.c:559
++#: imap.c:644
+ #, c-format
+ msgid "%u is unseen\n"
+ msgstr "%u n'est pas vu\n"
+ 
+-#: interface.c:255
++#: interface.c:253
+ msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+ msgstr ""
+ "Impossible d'ouvrir l'interface kvm.\n"
+ "Assurez-vous que fetchmail est SGID kmem."
+ 
+-#: interface.c:400
++#: interface.c:398
+ #, c-format
+ msgid "Unable to parse interface name from %s"
+ msgstr "Impossible d'interpréter le nom de l'interface depuis %s"
+ 
+-#: interface.c:422
++#: interface.c:420
+ msgid "get_ifinfo: sysctl (iflist estimate) failed"
+ msgstr "get_ifinfo: échec du sysctl (iflist estimate)"
+ 
+-#: interface.c:428
++#: interface.c:426
+ msgid "get_ifinfo: malloc failed"
+ msgstr "get_ifinfo: échec malloc"
+ 
+-#: interface.c:434
++#: interface.c:432
+ msgid "get_ifinfo: sysctl (iflist) failed"
+ msgstr "get_ifinfo: échec du sysctl (iflist)"
+ 
+-#: interface.c:452
++#: interface.c:450
+ #, c-format
+ msgid "Routing message version %d not understood."
+ msgstr "La version %d du message de routage n'est pas compréhensible"
+ 
+ #. we did not find an interface with a matching name
+-#: interface.c:484
++#: interface.c:482
+ #, c-format
+ msgid "No interface found with name %s"
+ msgstr "Aucune interface n'a été trouvée avec le nom %s"
+ 
+-#: interface.c:542
++#: interface.c:540
+ #, c-format
+ msgid "No IP address found for %s"
+ msgstr "Aucune adresse IP trouvée pour %s"
+ 
+-#: interface.c:594
++#: interface.c:592
+ msgid "missing IP interface address\n"
+ msgstr "l'adresse IP de l'interface est manquante\n"
+ 
+-#: interface.c:610
++#: interface.c:608
+ msgid "invalid IP interface address\n"
+ msgstr "l'adresse IP de l'interface est invalide\n"
+ 
+-#: interface.c:616
++#: interface.c:614
+ msgid "invalid IP interface mask\n"
+ msgstr "le masque de l'interface est invalide\n"
+ 
+-#: interface.c:655
++#: interface.c:653
+ #, c-format
+ msgid "activity on %s -noted- as %d\n"
+ msgstr "activité sur %s -notée- comme étant %d\n"
+ 
+-#: interface.c:670
++#: interface.c:668
+ #, c-format
+ msgid "skipping poll of %s, %s down\n"
+ msgstr "la réception depuis %s est ignorée, %s arrêtée\n"
+ 
+-#: interface.c:689
++#: interface.c:687
+ #, c-format
+ msgid "skipping poll of %s, %s IP address excluded\n"
+ msgstr "la réception depuis %s est ignorée, l'adresse IP de %s est exclue\n"
+ 
+-#: interface.c:701
++#: interface.c:699
+ #, c-format
+ msgid "activity on %s checked as %d\n"
+ msgstr "activité sur %s vérifiée comme étant %d\n"
+ 
+-#: interface.c:727
++#: interface.c:725
+ #, c-format
+ msgid "skipping poll of %s, %s inactive\n"
+ msgstr "la réception depuis %s est ignorée, %s inactivée\n"
+ 
+-#: interface.c:734
++#: interface.c:732
+ #, c-format
+ msgid "activity on %s was %d, is %d\n"
+ msgstr "l'activité sur %s était %d, est %d\n"
+@@ -1655,84 +1707,83 @@
+ msgid "fetchmail: lock creation failed.\n"
+ msgstr "fetchmail: impossible de créer le verrou.\n"
+ 
+-#: netrc.c:217
++#: netrc.c:218
+ #, c-format
+ msgid "warning: found \"%s\" before any host names"
+ msgstr "attention: \"%s\" rencontré avant tout nom d'hôte"
+ 
+-#: netrc.c:221
++#: netrc.c:222
+ #, c-format
+ msgid "%s:%d: warning: found \"%s\" before any host names\n"
+ msgstr "%s:%d: attention: \"%s\" rencontré avant tout nom d'hôte\n"
+ 
+-#: netrc.c:260
++#: netrc.c:261
+ #, c-format
+ msgid "%s:%d: warning: unknown token \"%s\"\n"
+ msgstr "%s:%d: attention: le composant \"%s\" est inconnu\n"
+ 
+-#: odmr.c:59
++#: odmr.c:64
+ #, c-format
+ msgid "%s's SMTP listener does not support ATRN\n"
+ msgstr "Le serveur SMTP %s ne supporte pas ATRN\n"
+ 
+-#: odmr.c:97
++#: odmr.c:102
+ msgid "Turnaround now...\n"
+ msgstr ""
+ 
+-#: odmr.c:102
++#: odmr.c:107
+ msgid "ATRN request refused.\n"
+ msgstr "requête ATRN refusée.\n"
+ 
+ #. Unable to process ATRN request now
+-#: odmr.c:106
++#: odmr.c:111
+ msgid "Unable to process ATRN request now\n"
+ msgstr "Impossible de traiter la requete ATRN maintenant\n"
+ 
+-#. You have no mail
+-#: odmr.c:110
++#: odmr.c:116
+ msgid "You have no mail.\n"
+ msgstr "Vous n'avez pas de mail\n"
+ 
+ #. Command not implemented
+-#: odmr.c:114
++#: odmr.c:120
+ msgid "Command not implemented\n"
+ msgstr "Commande non implémentée\n"
+ 
+ #. Authentication required
+-#: odmr.c:118
++#: odmr.c:124
+ msgid "Authentication required.\n"
+ msgstr "Authentification nécessaire.\n"
+ 
+-#: odmr.c:122
++#: odmr.c:128
+ #, c-format
+ msgid "Unknown ODMR error %d\n"
+ msgstr "Erreur ODMR inconnue %d\n"
+ 
+-#: odmr.c:225
++#: odmr.c:231
+ msgid "Option --keep is not supported with ODMR\n"
+ msgstr "L'option --keep n'est pas supportée avec ODMR\n"
+ 
+-#: odmr.c:229
++#: odmr.c:235
+ msgid "Option --flush is not supported with ODMR\n"
+ msgstr "L'option --keep n'est pas supportée avec ODMR\n"
+ 
+-#: odmr.c:233
++#: odmr.c:239
+ msgid "Option --remote is not supported with ODMR\n"
+ msgstr "L'option --remote n'est pas supportée avec ODMR\n"
+ 
+-#: odmr.c:237
++#: odmr.c:243
+ msgid "Option --check is not supported with ODMR\n"
+ msgstr "L'option --check n'est pas supportée avec ODMR\n"
+ 
+ #: opie.c:37
+-msgid "Could not decode initial BASE64 challenge\n"
+-msgstr "Impossible de décoder le challenge BASE64 initial\n"
++msgid "server recv fatal\n"
++msgstr ""
+ 
+-#: opie.c:46
++#: opie.c:51
+ msgid "Could not decode OTP challenge\n"
+ msgstr "Impossible de décoder le challenge OTP\n"
+ 
+-#: opie.c:53
++#: opie.c:59
+ msgid "Secret pass phrase: "
+ msgstr "Phrase de passe secrète : "
+ 
+@@ -1891,7 +1942,8 @@
+ 
+ #: options.c:680
+ msgid "      --auth        authentication type (password/kerberos/ssh)\n"
+-msgstr "      --auth        type d'authentification (mot de passe/kerberos/ssh)\n"
++msgstr ""
++"      --auth        type d'authentification (mot de passe/kerberos/ssh)\n"
+ 
+ #: options.c:681
+ msgid "  -t, --timeout     server nonresponse timeout\n"
+@@ -2009,316 +2061,397 @@
+ 
+ #: options.c:711
+ msgid "      --showdots    show progress dots even in logfiles\n"
+-msgstr "      --showdots    affiche des points de progression, même dans le journal\n"
++msgstr ""
++"      --showdots    affiche des points de progression, même dans le journal\n"
+ 
+-#: pop3.c:296
++#: pop3.c:333
+ msgid "Required APOP timestamp not found in greeting\n"
+ msgstr "L'horodatage APOP requis est absent du message d'invitation\n"
+ 
+-#: pop3.c:305
++#: pop3.c:342
+ msgid "Timestamp syntax error in greeting\n"
+ msgstr "Erreur de syntaxe dans l'horodatage du message d'invitation\n"
+ 
+-#: pop3.c:327
++#: pop3.c:364
+ msgid "Undefined protocol request in POP3_auth\n"
+ msgstr "Requête de protocole indéfinie dans POP3_auth\n"
+ 
+-#: pop3.c:335
++#: pop3.c:372
+ msgid "lock busy!  Is another session active?\n"
+ msgstr "Fichier verrou en service. Y'a-t-il une autre session active ?\n"
+ 
+-#: pop3.c:443
++#: pop3.c:480
+ msgid "Messages inserted into list on server. Cannot handle this.\n"
+ msgstr "Messages insérés dans une liste du serveur. Impossible de gérer ça.\n"
+ 
+-#: pop3.c:514
++#: pop3.c:551
+ msgid "protocol error\n"
+ msgstr "erreur de protocole\n"
+ 
+-#: pop3.c:527
++#: pop3.c:564
+ msgid "protocol error while fetching UIDLs\n"
+ msgstr "erreur de protocole durant la réception des UIDLs\n"
+ 
+-#: pop3.c:764
++#: pop3.c:817
+ msgid "Option --remote is not supported with POP3\n"
+ msgstr "L'option --remote n'est pas supportée avec POP3\n"
+ 
+-#: rfc822.c:57
++#: rcfile_y.y:123
++msgid "server option after user options"
++msgstr ""
++
++#: rcfile_y.y:170
++msgid "SDPS not enabled."
++msgstr "le support de SDPS est désactivé"
++
++#: rcfile_y.y:218
++msgid "invalid security request"
++msgstr "requête de niveau de sécurité invalide"
++
++#: rcfile_y.y:224
++msgid "network-security support disabled"
++msgstr "le support de la sécurité réseau est inactif"
++
++#: rcfile_y.y:231
++msgid ""
++"fetchmail: interface option is only supported under Linux (without IPv6) and "
++"FreeBSD\n"
++msgstr ""
++
++#: rcfile_y.y:238
++msgid ""
++"fetchmail: monitor option is only supported under Linux (without IPv6) and "
++"FreeBSD\n"
++msgstr ""
++
++#: rcfile_y.y:350
++msgid "SSL is not enabled"
++msgstr "le support de SSL n'est pas activé"
++
++#: rcfile_y.y:396
++msgid "end of input"
++msgstr "fin de l'entrée"
++
++#: rcfile_y.y:433
++#, c-format
++msgid "File %s must not be a symbolic link.\n"
++msgstr "Le fichier %s doit etre un lien symbolique.\n"
++
++#: rcfile_y.y:440
++#, c-format
++msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
++msgstr "Le fichier %s doit avoir au moins les permissions -rwx--x--- (0710)\n"
++
++#: rcfile_y.y:452
++#, c-format
++msgid "File %s must be owned by you.\n"
++msgstr "Le fichier %s doit vous appartenir.\n"
++
++#: report.c:81
++msgid "Unknown system error"
++msgstr "Erreur système inconnue"
++
++#: report.c:108
++#, c-format
++msgid "%s (log message incomplete)"
++msgstr "%s (message de trace incomplet)"
++
++#: report.c:266 report.c:294 report.c:366 report.c:394
++msgid "partial error message buffer overflow"
++msgstr "erreur partielle de surcharge du tampon de message"
++
++#: rfc822.c:73
+ #, c-format
+ msgid "About to rewrite %s"
+ msgstr "Sur le point de réécrire %s"
+ 
+-#: rfc822.c:193
++#: rfc822.c:209
+ #, c-format
+ msgid "Rewritten version is %s\n"
+ msgstr "La version réécrite est %s\n"
+ 
+-#: rpa.c:113
++#: rpa.c:116
+ msgid "Success"
+ msgstr "Succès"
+ 
+-#: rpa.c:114
++#: rpa.c:117
+ msgid "Restricted user (something wrong with account)"
+ msgstr "Utilisation restreinte (quelque chose d'anormal avec le compte)"
+ 
+-#: rpa.c:115
++#: rpa.c:118
+ msgid "Invalid userid or passphrase"
+ msgstr "ID Utilisateur ou phrase de passe invalide"
+ 
+-#: rpa.c:116
++#: rpa.c:119
+ msgid "Deity error"
+ msgstr "Erreur fatale"
+ 
+-#: rpa.c:169
++#: rpa.c:172
+ msgid "RPA token 2: Base64 decode error\n"
+ msgstr "Composant RPA 2: erreur de décodage Base64\n"
+ 
+-#: rpa.c:180
++#: rpa.c:183
+ #, c-format
+ msgid "Service chose RPA version %d.%d\n"
+ msgstr "Service retenu RPA version %d.%d\n"
+ 
+-#: rpa.c:186
++#: rpa.c:189
+ #, c-format
+ msgid "Service challenge (l=%d):\n"
+ msgstr "Challenge du service (l=%d):\n"
+ 
+-#: rpa.c:195
++#: rpa.c:198
+ #, c-format
+ msgid "Service timestamp %s\n"
+ msgstr "Horodatage du service %s\n"
+ 
+-#: rpa.c:200
++#: rpa.c:203
+ msgid "RPA token 2 length error\n"
+ msgstr "Erreur sur la longueur du composant RPA 2\n"
+ 
+-#: rpa.c:204
++#: rpa.c:207
+ #, c-format
+ msgid "Realm list: %s\n"
+ msgstr "Liste des domaines : %s\n"
+ 
+-#: rpa.c:208
++#: rpa.c:211
+ msgid "RPA error in service@realm string\n"
+ msgstr "Erreur RPA dans la chaîne service@domaine\n"
+ 
+-#: rpa.c:245
++#: rpa.c:248
+ msgid "RPA token 4: Base64 decode error\n"
+ msgstr "Composant RPA 4 : erreur de décodage\n"
+ 
+-#: rpa.c:256
++#: rpa.c:259
+ #, c-format
+ msgid "User authentication (l=%d):\n"
+ msgstr "Authentification de l'utilisateur (l=%d):\n"
+ 
+-#: rpa.c:270
++#: rpa.c:273
+ #, c-format
+ msgid "RPA status: %02X\n"
+ msgstr "Etat RPA : %02X\n"
+ 
+-#: rpa.c:276
++#: rpa.c:279
+ msgid "RPA token 4 length error\n"
+ msgstr "Erreur dans la longueur du composant RPA 4\n"
+ 
+-#: rpa.c:283
++#: rpa.c:286
+ #, c-format
+ msgid "RPA rejects you: %s\n"
+ msgstr "RPA vous a rejeté : %s\n"
+ 
+-#: rpa.c:285
++#: rpa.c:288
+ msgid "RPA rejects you, reason unknown\n"
+ msgstr "RPA vous a rejeté pour une raison inconnue\n"
+ 
+-#: rpa.c:291
++#: rpa.c:294
+ #, c-format
+ msgid "RPA User Authentication length error: %d\n"
+-msgstr "Erreur dans la longueur de l'authentification RPA de l'utilisateur : %d\n"
++msgstr ""
++"Erreur dans la longueur de l'authentification RPA de l'utilisateur : %d\n"
+ 
+-#: rpa.c:296
++#: rpa.c:299
+ #, c-format
+ msgid "RPA Session key length error: %d\n"
+ msgstr "Erreur de longueur de clé de session RPA : %d\n"
+ 
+-#: rpa.c:302
++#: rpa.c:305
+ msgid "RPA _service_ auth fail. Spoof server?\n"
+ msgstr "Échec d'authentification du _service_ RPA. Serveur falsifié ?\n"
+ 
+-#: rpa.c:307
++#: rpa.c:310
+ msgid "Session key established:\n"
+ msgstr "Clé de session établie :\n"
+ 
+-#: rpa.c:338
++#: rpa.c:341
+ msgid "RPA authorisation complete\n"
+ msgstr "Autorisation RPA complète\n"
+ 
+-#: rpa.c:367
++#: rpa.c:370
+ msgid "Get response\n"
+ msgstr "Obtention de la réponse\n"
+ 
+-#: rpa.c:397
++#: rpa.c:400
+ #, c-format
+ msgid "Get response return %d [%s]\n"
+ msgstr "Obtention d'un retour de réponse %d [%s]\n"
+ 
+-#: rpa.c:460
++#: rpa.c:463
+ msgid "Hdr not 60\n"
+ msgstr "L'en-tête n'est pas 60\n"
+ 
+-#: rpa.c:481
++#: rpa.c:484
+ msgid "Token length error\n"
+ msgstr "Erreur de longueur de composant\n"
+ 
+-#: rpa.c:486
++#: rpa.c:489
+ #, c-format
+ msgid "Token Length %d disagrees with rxlen %d\n"
+ msgstr "La longueur %d du composant n'est pas conforme à rxlen %d\n"
+ 
+-#: rpa.c:492
++#: rpa.c:495
+ msgid "Mechanism field incorrect\n"
+ msgstr "Champ du mécanisme incorrect\n"
+ 
+-#: rpa.c:529
++#: rpa.c:532
+ #, c-format
+ msgid "dec64 error at char %d: %x\n"
+ msgstr "Erreur dec64 sur le caractère %d : %x\n"
+ 
+-#: rpa.c:544
++#: rpa.c:547
+ msgid "Inbound binary data:\n"
+ msgstr "Données binaires entrantes :\n"
+ 
+-#: rpa.c:582
++#: rpa.c:585
+ msgid "Outbound data:\n"
+ msgstr "Données sortantes:\n"
+ 
+-#: rpa.c:648
++#: rpa.c:651
+ msgid "RPA String too long\n"
+ msgstr "Chaîne de caractères RPA trop longue\n"
+ 
+-#: rpa.c:653
++#: rpa.c:656
+ msgid "Unicode:\n"
+ msgstr "Unicode:\n"
+ 
+-#: rpa.c:715
++#: rpa.c:718
+ msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+ msgstr "Échec RPA à l'ouverture de /dev/urandom. Ceci ne devrait pas\n"
+ 
+-#: rpa.c:716
++#: rpa.c:719
+ msgid "    prevent you logging in, but means you\n"
+ msgstr "    empêcher votre login, mais signifie que\n"
+ 
+-#: rpa.c:717
++#: rpa.c:720
+ msgid "    cannot be sure you are talking to the\n"
+ msgstr "    rien ne garantit que vous discutez avec\n"
+ 
+-#: rpa.c:718
++#: rpa.c:721
+ msgid "    service that you think you are (replay\n"
+ msgstr "    le service que vous pensez utiliser (des attaques\n"
+ 
+-#: rpa.c:719
++#: rpa.c:722
+ msgid "    attacks by a dishonest service are possible.)\n"
+ msgstr "    par imitation par un service louche sont possibles).\n"
+ 
+-#: rpa.c:730
++#: rpa.c:733
+ msgid "User challenge:\n"
+ msgstr "Challenge d'utilisateur :\n"
+ 
+-#: rpa.c:888
++#: rpa.c:891
+ msgid "MD5 being applied to data block:\n"
+ msgstr "Application de MD5 au bloc de données :\n"
+ 
+-#: rpa.c:901
++#: rpa.c:904
+ msgid "MD5 result is: \n"
+ msgstr "Le résultat de MD5 est : \n"
+ 
+-#: sink.c:176
++#: sink.c:212
+ #, c-format
+ msgid "forwarding to %s\n"
+ msgstr "réexpédition vers %s\n"
+ 
+-#: sink.c:310
++#: sink.c:308
+ msgid "SMTP: (bounce-message body)\n"
+ msgstr "SMTP: (corps du message ayant rebondi)\n"
+ 
+ #. this will usually go to sylog...
+-#: sink.c:313
++#: sink.c:311
+ #, c-format
+ msgid "mail from %s bounced to %s\n"
+ msgstr "message depuis %s ayant rebondi sur %s\n"
+ 
+-#: sink.c:414
++#: sink.c:416
+ #, c-format
+ msgid "Saved error is still %d\n"
+ msgstr "L'erreur mémorisée est toujours %d\n"
+ 
+-#: sink.c:459
++#: sink.c:471 sink.c:549
+ #, c-format
+ msgid "%cMTP error: %s\n"
+ msgstr "Erreur %cMTP: %s\n"
+ 
+-#: sink.c:577
++#: sink.c:698
+ msgid "BSMTP file open or preamble write failed\n"
+ msgstr "Échec d'ouverture du fichier BSMTP ou à l'écriture du préambule\n"
+ 
+-#: sink.c:720
++#: sink.c:905
+ #, c-format
+ msgid "%cMTP listener doesn't like recipient address `%s'\n"
+ msgstr "Le serveur %cMTP n'apprécie pas l'adresse de destinataire `%s'\n"
+ 
+-#: sink.c:740
++#: sink.c:912
++#, c-format
++msgid "%cMTP listener doesn't really like recipient address `%s'\n"
++msgstr "Le serveur %cMTP n'apprécie pas l'adresse du destinataire `%s'\n"
++
++#: sink.c:950
+ msgid "no address matches; no postmaster set.\n"
+ msgstr "les adresses ne correspondent pas ; pas de postmaster\n"
+ 
+-#: sink.c:757
++#: sink.c:957
+ #, c-format
+ msgid "can't even send to %s!\n"
+ msgstr "il n'est même pas possible d'expédier vers %s\n"
+ 
+-#: sink.c:763
++#: sink.c:963
+ #, c-format
+ msgid "no address matches; forwarding to %s.\n"
+ msgstr "aucune correspondance dans les adresses ; réexpédition vers %s.\n"
+ 
+-#: sink.c:784
++#: sink.c:1112
++#, c-format
++msgid "about to deliver with: %s\n"
++msgstr "sur le point de délivrer le courrier à : %s\n"
++
++#: sink.c:1136
++msgid "MDA open failed\n"
++msgstr "Échec d'ouverture MDA\n"
++
++#: sink.c:1180
+ #, c-format
+ msgid "%cMTP connect to %s failed\n"
+ msgstr "Échec de connexion %cMTP avec %s\n"
+ 
+-#: sink.c:805
++#: sink.c:1204
+ #, c-format
+ msgid "can't raise the listener; falling back to %s"
+ msgstr ""
+ 
+-#: sink.c:927
++#: sink.c:1259
+ #, c-format
+-msgid "about to deliver with: %s\n"
+-msgstr "sur le point de délivrer le courrier à : %s\n"
+-
+-#: sink.c:950
+-msgid "MDA open failed\n"
+-msgstr "Échec d'ouverture MDA\n"
++msgid "MDA died of signal %d\n"
++msgstr "le programme de livraison du courrier a été tué par un signal %d\n"
+ 
+-#: sink.c:1023
++#: sink.c:1262
+ #, c-format
+ msgid "MDA returned nonzero status %d\n"
+ msgstr "MDA a retourné un état non nul (%d)\n"
+ 
+-#: sink.c:1039
++#: sink.c:1265
++#, c-format
++msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
++msgstr ""
++
++#: sink.c:1286
+ msgid "Message termination or close of BSMTP file failed\n"
+ msgstr "Échec à la terminaison du message ou à la fermeture de BSMTP\n"
+ 
+-#: sink.c:1053
++#: sink.c:1302
+ msgid "SMTP listener refused delivery\n"
+ msgstr "Le serveur SMTP a refusé de délivrer le courrier\n"
+ 
+-#: sink.c:1082
++#: sink.c:1332
+ msgid "LMTP delivery error on EOM\n"
+ msgstr "Erreur de délivrance LMTP en EOM\n"
+ 
+-#: sink.c:1085
++#: sink.c:1335
+ #, c-format
+ msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+ msgstr "Réponse non-503 inattendue à un ordre LMTP EOM: %s\n"
+ 
+-#: sink.c:1223
++#: sink.c:1474
+ msgid ""
+ "--\r\n"
+ "\t\t\t\tThe Fetchmail Daemon\r\n"
+@@ -2326,158 +2459,195 @@
+ "--\r\n"
+ "\t\t\t\tLe Démon Fetchmail\r\n"
+ 
+-#: socket.c:100 socket.c:126
++#: smtp.c:85
++msgid "ESMTP CRAM-MD5 Authentication...\n"
++msgstr "Authentification ESMTP CRAM-Md5...\n"
++
++#. Server rejects AUTH
++#: smtp.c:91 smtp.c:150
++msgid "Server rejected the AUTH command.\n"
++msgstr "Le serveur a refusé la commande AUTH.\n"
++
++#: smtp.c:99 smtp.c:157 smtp.c:166 smtp.c:172
++msgid "Bad base64 reply from server.\n"
++msgstr "Mauvaise réponse en base 64 du serveur.\n"
++
++#: smtp.c:103
++#, fuzzy, c-format
++msgid "Challenge decoded: %s\n"
++msgstr "Décodé comme %s\n"
++
++#: smtp.c:124
++msgid "ESMTP PLAIN Authentication...\n"
++msgstr "Autentification ESMTP PLAIN ...\n"
++
++#: smtp.c:144
++msgid "ESMTP LOGIN Authentication...\n"
++msgstr "Autentification ESMTP LOGIN ...\n"
++
++#: socket.c:107 socket.c:133
+ msgid "fetchmail: malloc failed\n"
+ msgstr "fetchmail: échec de malloc\n"
+ 
+-#: socket.c:158
++#: socket.c:165
+ msgid "fetchmail: socketpair failed\n"
+ msgstr "fetchmail: échec socketpair\n"
+ 
+ #. error
+-#: socket.c:164
++#: socket.c:171
+ msgid "fetchmail: fork failed\n"
+ msgstr "fetchmail: échec fork\n"
+ 
+-#: socket.c:172
++#: socket.c:179
+ msgid "dup2 failed\n"
+ msgstr "échec dup2\n"
+ 
+-#: socket.c:178
++#: socket.c:185
+ #, c-format
+ msgid "running %s (host %s service %s)\n"
+ msgstr "exécution de %s (machine %s, service %s)\n"
+ 
+-#: socket.c:181
++#: socket.c:188
+ #, c-format
+ msgid "execvp(%s) failed\n"
+ msgstr "échec de execvp(%s)\n"
+ 
+-#: socket.c:263
++#: socket.c:280
+ #, c-format
+ msgid "fetchmail: getaddrinfo(%s.%s)\n"
+ msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+ 
+-#: socket.c:388
++#: socket.c:427
+ #, c-format
+ msgid "fetchmail: illegal address length received for host %s\n"
+ msgstr "fetchmail: longueur d'adresse illégale reçue de l'hôte %s\n"
+ 
+-#: socket.c:686
++#: socket.c:733
+ #, c-format
+ msgid "Issuer Organization: %s\n"
+-msgstr ""
++msgstr "Organisation de l'expéditeur: %s\n"
+ 
+-#: socket.c:688
++#: socket.c:735
+ msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+-msgstr ""
++msgstr "Avertissement: le nom de l'organisation de l'expéditeur est tros long (et peut etre tronqué).\n"
+ 
+-#: socket.c:690
++#: socket.c:737
+ msgid "Unknown Organization\n"
+ msgstr "Organisation inconnue\n"
+ 
+-#: socket.c:692
++#: socket.c:739
+ #, c-format
+ msgid "Issuer CommonName: %s\n"
+ msgstr ""
+ 
+-#: socket.c:694
++#: socket.c:741
+ msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+-msgstr ""
++msgstr "Avertissement: le nom de l'expéditeur est tros long (et peut etre tronqué).\n"
+ 
+-#: socket.c:696
++#: socket.c:743
+ msgid "Unknown Issuer CommonName\n"
+ msgstr ""
+ 
+-#: socket.c:700
++#: socket.c:747
+ #, c-format
+ msgid "Server CommonName: %s\n"
+ msgstr "Nom commun du serveur: %s\n"
+ 
+ #. Possible truncation. In this case, this is a DNS name, so this
+ #. * is really bad. We do not tolerate this even in the non-strict case.
+-#: socket.c:704
++#: socket.c:751
+ msgid "Bad certificate: Subject CommonName too long!\n"
+ msgstr ""
+ 
+-#: socket.c:720
++#: socket.c:767
+ #, c-format
+ msgid "Server CommonName mismatch: %s != %s\n"
+ msgstr ""
+ 
+-#: socket.c:726
++#: socket.c:773
+ msgid "Server name not set, could not verify certificate!\n"
+-msgstr "Le nom du serveur n'est pas spécifié, impossible de vérifier le certificat!\n"
++msgstr ""
++"Le nom du serveur n'est pas spécifié, impossible de vérifier le certificat!\n"
+ 
+-#: socket.c:731
++#: socket.c:778
+ msgid "Unknown Server CommonName\n"
+ msgstr ""
+ 
+-#: socket.c:733
++#: socket.c:780
+ msgid "Server name not specified in certificate!\n"
+ msgstr "Le nom du serveur n'est pas présent dans le certificat!\n"
+ 
+-#: socket.c:743
++#: socket.c:790
+ msgid "EVP_md5() failed!\n"
+ msgstr "échec de EVP_md5()\n"
+ 
+-#: socket.c:747
++#: socket.c:794
+ msgid "Out of memory!\n"
+ msgstr "Plus de mémoire!\n"
+ 
+-#: socket.c:759
++#: socket.c:806
+ msgid "Digest text buffer too small!\n"
+ msgstr "Le tampon résumé est trop court!\n"
+ 
+-#: socket.c:764
++#: socket.c:812
+ #, c-format
+ msgid "%s key fingerprint: %s\n"
+ msgstr "signature de la clé %s: %s\n"
+ 
+-#: socket.c:767
++#: socket.c:816
+ #, c-format
+ msgid "%s fingerprints match.\n"
+ msgstr "La signature %s correspond.\n"
+ 
+-#: socket.c:769
++#: socket.c:819
+ #, c-format
+ msgid "%s fingerprints do not match!\n"
+ msgstr "La signature %s ne correspond pas!\n"
+ 
+-#: socket.c:777
++#: socket.c:827
+ #, c-format
+ msgid "Warning: server certificate verification: %s\n"
+ msgstr ""
+ 
+-#: socket.c:783
++#: socket.c:833
+ #, c-format
+ msgid "unknown issuer (first %d characters): %s\n"
+ msgstr ""
+ 
+-#: socket.c:815
++#: socket.c:865
+ msgid "File descriptor out of range for SSL"
+ msgstr "Descripteur de fichier inaccessible pour SSL"
+ 
+-#: socket.c:830
++#: socket.c:880
+ #, c-format
+ msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+-msgstr "Le protocole SSL «%s» spécifié est invalide, le protocole par défaut (SSLv23) est utilisé.\n"
++msgstr ""
++"Le protocole SSL «%s» spécifié est invalide, le protocole par défaut "
++"(SSLv23) est utilisé.\n"
+ 
+-#: socket.c:890
++#: socket.c:940
+ msgid "Certificate/fingerprint verification was somehow skipped!\n"
+ msgstr "La vérification du certificat ou de la signature n'a pas été faite!\n"
+ 
++#: socket.c:1012
++msgid "Cygwin socket read retry\n"
++msgstr ""
++
++#: socket.c:1015
++msgid "Cygwin socket read retry failed!\n"
++msgstr ""
++
+ #: transact.c:69
+ #, c-format
+ msgid "mapped %s to local %s\n"
+ msgstr "correspondance de %s en local %s\n"
+ 
+-#: transact.c:126
++#: transact.c:133
+ #, c-format
+ msgid "passed through %s matching %s\n"
+ msgstr "passage au travers de %s et coïncidence avec %s\n"
+ 
+-#: transact.c:193
++#: transact.c:200
+ #, c-format
+ msgid ""
+ "analyzing Received line:\n"
+@@ -2486,60 +2656,60 @@
+ "analyse de la ligne «Received»:\n"
+ "%s"
+ 
+-#: transact.c:232
++#: transact.c:239
+ #, c-format
+ msgid "line accepted, %s is an alias of the mailserver\n"
+ msgstr "ligne acceptée, %s est un alias du serveur de courrier\n"
+ 
+-#: transact.c:238
++#: transact.c:245
+ #, c-format
+ msgid "line rejected, %s is not an alias of the mailserver\n"
+ msgstr "ligne rejetée, %s n'est pas un alias du serveur de courrier\n"
+ 
+-#: transact.c:309
++#: transact.c:316
+ msgid "no Received address found\n"
+ msgstr "aucune adresse trouvée dans «Received»\n"
+ 
+-#: transact.c:318
++#: transact.c:325
+ #, c-format
+ msgid "found Received address `%s'\n"
+ msgstr "adresse `%s' trouvée dans «Received»\n"
+ 
+-#: transact.c:823
++#: transact.c:848
+ msgid "message delimiter found while scanning headers\n"
+ msgstr "délimiteur de message trouvé durant l'analyse des en-têtes\n"
+ 
+-#: transact.c:961
++#: transact.c:986
+ #, c-format
+ msgid "no local matches, forwarding to %s\n"
+ msgstr "aucune correspondance locale, réexpédition vers %s\n"
+ 
+-#: transact.c:976
++#: transact.c:1001
+ msgid "forwarding and deletion suppressed due to DNS errors\n"
+ msgstr "réexpédition et effacement supprimés suite à des erreurs de DNS\n"
+ 
+-#: transact.c:1125
++#: transact.c:1137
+ msgid "writing RFC822 msgblk.headers\n"
+ msgstr "écriture d'en-têtes RFC822\n"
+ 
+-#: transact.c:1146
++#: transact.c:1158
+ msgid "no recipient addresses matched declared local names"
+ msgstr "aucune adresse de destination ne correspond aux noms locaux déclarés"
+ 
+-#: transact.c:1152
++#: transact.c:1164
+ #, c-format
+ msgid "recipient address %s didn't match any local name"
+ msgstr "l'adresse de destination %s ne correspond à aucun nom local"
+ 
+-#: transact.c:1160
++#: transact.c:1172
+ msgid "message has embedded NULs"
+ msgstr "le message contient des caractères NULs"
+ 
+-#: transact.c:1167
++#: transact.c:1179
+ msgid "SMTP listener rejected local recipient addresses: "
+ msgstr "Le serveur SMTP rejette les adresses locales de destination : "
+ 
+-#: transact.c:1296
++#: transact.c:1308
+ msgid "writing message text\n"
+ msgstr "écriture du texte du message\n"
+ 
+@@ -2548,48 +2718,56 @@
+ msgid "lstat: %s: %s\n"
+ msgstr "lstat: %s: %s\n"
+ 
+-#: uid.c:212
++#: uid.c:211
+ #, c-format
+ msgid "Old UID list from %s:"
+ msgstr "Ancienne liste d'UID depuis %s:"
+ 
+-#: uid.c:217 uid.c:228 uid.c:455
++#: uid.c:216 uid.c:227 uid.c:454
+ msgid " <empty>"
+ msgstr " <vide>"
+ 
+-#: uid.c:224
++#: uid.c:223
+ msgid "Scratch list of UIDs:"
+ msgstr ""
+ 
+-#: uid.c:451
++#: uid.c:450
+ #, c-format
+ msgid "New UID list from %s:"
+ msgstr "Nouvelle liste d'UID à partir de %s:"
+ 
+-#: uid.c:479
++#: uid.c:478
+ msgid "swapping UID lists\n"
+ msgstr "inversion des listes d'UIDs\n"
+ 
+-#: uid.c:485
++#: uid.c:484
+ msgid "not swapping UID lists, no UIDs seen this query\n"
+ msgstr ""
+ 
+-#: uid.c:509
++#: uid.c:508
+ msgid "Deleting fetchids file.\n"
+ msgstr "Effacement du fichier fetchids.\n"
+ 
+-#: uid.c:515
++#: uid.c:514
+ msgid "Writing fetchids file.\n"
+ msgstr "Ecriture du fichier fetchids.\n"
+ 
+-#: xmalloc.c:32
++#: xmalloc.c:33
+ msgid "malloc failed\n"
+ msgstr "échec malloc\n"
+ 
+-#: xmalloc.c:46
++#: xmalloc.c:47
+ msgid "realloc failed\n"
+ msgstr "échec realloc\n"
+ 
++#~ msgid "all mailserver name lookups failed, exiting\n"
++#~ msgstr ""
++#~ " toutes les tentatives pour résoudre le nom du serveur de mail ont "
++#~ "échouées. Fin du processus.\n"
++
++#~ msgid "Could not decode initial BASE64 challenge\n"
++#~ msgstr "Impossible de décoder le challenge BASE64 initial\n"
++
+ #~ msgid "fetchmail: %s connection to %s failed"
+ #~ msgstr "fetchmail: échec de la connexion %s à %s"
+ 
diff --git a/po/fetchmail.pot b/po/fetchmail.pot
new file mode 100644
index 00000000..6b913142
--- /dev/null
+++ b/po/fetchmail.pot
@@ -0,0 +1,2744 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the PACKAGE package.
+# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=CHARSET\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr ""
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr ""
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr ""
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr ""
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr ""
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr ""
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr ""
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr ""
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr ""
+
+#: driver.c:497
+#, c-format
+msgid "skipping message %s@%s:%d"
+msgstr ""
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr ""
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr ""
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr ""
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr ""
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr ""
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr ""
+
+#: driver.c:606
+msgid "header "
+msgstr ""
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr ""
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+
+#: driver.c:767
+msgid " retained\n"
+msgstr ""
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr ""
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr ""
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr ""
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr ""
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr ""
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr ""
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr ""
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr ""
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr ""
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr ""
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr ""
+
+#: driver.c:1016
+#, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr ""
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr ""
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr ""
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr ""
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr ""
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr ""
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr ""
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr ""
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr ""
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr ""
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr ""
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr ""
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr ""
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr ""
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr ""
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr ""
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr ""
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr ""
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr ""
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr ""
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr ""
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr ""
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr ""
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr ""
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr ""
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr ""
+
+#: driver.c:1362
+#, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr ""
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr ""
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr ""
+
+#: driver.c:1366
+msgid "seen"
+msgstr ""
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr ""
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr ""
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr ""
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr ""
+
+#: driver.c:1515
+msgid "socket"
+msgstr ""
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr ""
+
+#: driver.c:1521
+msgid "MDA"
+msgstr ""
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr ""
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr ""
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr ""
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr ""
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr ""
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr ""
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr ""
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr ""
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr ""
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr ""
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr ""
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr ""
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr ""
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr ""
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr ""
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr ""
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr ""
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr ""
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr ""
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr ""
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr ""
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr ""
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr ""
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr ""
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr ""
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr ""
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr ""
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr ""
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr ""
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr ""
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr ""
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr ""
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr ""
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr ""
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr ""
+
+#: fetchmail.c:332
+msgid " and "
+msgstr ""
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr ""
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr ""
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr ""
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr ""
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr ""
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr ""
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr ""
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr ""
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr ""
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr ""
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr ""
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr ""
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr ""
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr ""
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr ""
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr ""
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr ""
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr ""
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr ""
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr ""
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr ""
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr ""
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr ""
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr ""
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr ""
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr ""
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr ""
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr ""
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr ""
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr ""
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr ""
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr ""
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr ""
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr ""
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr ""
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr ""
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr ""
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr ""
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr ""
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr ""
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr ""
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr ""
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr ""
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr ""
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr ""
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr ""
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr ""
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr ""
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr ""
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr ""
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr ""
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr ""
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr ""
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr ""
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr ""
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr ""
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr ""
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr ""
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr ""
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr ""
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr ""
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr ""
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr ""
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr ""
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr ""
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr ""
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr ""
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr ""
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr ""
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr ""
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr ""
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr ""
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr ""
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr ""
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr ""
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr ""
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr ""
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr ""
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr ""
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr ""
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr ""
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr ""
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr ""
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr ""
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr ""
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr ""
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr ""
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr ""
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr ""
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr ""
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr ""
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr ""
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr ""
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr ""
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr ""
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr ""
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr ""
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr ""
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr ""
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr ""
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr ""
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr ""
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr ""
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr ""
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr ""
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr ""
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr ""
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr ""
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr ""
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr ""
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr ""
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr ""
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr ""
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr ""
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr ""
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr ""
+
+#: fetchmail.c:1647
+#, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr ""
+
+#: fetchmail.c:1650
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr ""
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr ""
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr ""
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr ""
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr ""
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr ""
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr ""
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr ""
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr ""
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr ""
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr ""
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr ""
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr ""
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr ""
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr ""
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr ""
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr ""
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr ""
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr ""
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr ""
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr ""
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr ""
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr ""
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr ""
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr ""
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr ""
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr ""
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr ""
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr ""
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr ""
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr ""
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr ""
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr ""
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr ""
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr ""
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr ""
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr ""
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr ""
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr ""
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr ""
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr ""
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr ""
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr ""
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr ""
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr ""
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr ""
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr ""
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr ""
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr ""
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr ""
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr ""
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr ""
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr ""
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr ""
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr ""
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr ""
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr ""
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr ""
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr ""
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr ""
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr ""
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr ""
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr ""
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr ""
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr ""
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr ""
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr ""
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr ""
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr ""
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr ""
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr ""
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr ""
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr ""
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr ""
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr ""
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr ""
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr ""
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr ""
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr ""
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr ""
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr ""
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr ""
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr ""
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr ""
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr ""
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr ""
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr ""
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr ""
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr ""
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr ""
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr ""
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr ""
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr ""
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr ""
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr ""
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr ""
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr ""
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr ""
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr ""
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr ""
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr ""
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr ""
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr ""
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr ""
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr ""
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr ""
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr ""
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr ""
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr ""
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr ""
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr ""
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr ""
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr ""
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr ""
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr ""
+
+#: options.c:211
+msgid "smaller"
+msgstr ""
+
+#: options.c:211
+msgid "larger"
+msgstr ""
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr ""
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr ""
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr ""
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr ""
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr ""
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr ""
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr ""
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr ""
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr ""
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr ""
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr ""
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr ""
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr ""
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr ""
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr ""
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr ""
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr ""
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr ""
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr ""
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr ""
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr ""
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr ""
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr ""
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr ""
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr ""
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr ""
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr ""
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr ""
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr ""
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr ""
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr ""
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr ""
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr ""
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr ""
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr ""
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr ""
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr ""
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr ""
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr ""
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr ""
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr ""
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr ""
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr ""
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr ""
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+
+#: options.c:720
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr ""
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr ""
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr ""
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr ""
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr ""
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr ""
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr ""
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr ""
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr ""
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr ""
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr ""
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr ""
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr ""
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr ""
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr ""
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr ""
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr ""
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr ""
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr ""
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr ""
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr ""
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr ""
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr ""
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr ""
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr ""
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr ""
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr ""
+
+#: rpa.c:116
+msgid "Success"
+msgstr ""
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr ""
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr ""
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr ""
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr ""
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr ""
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr ""
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr ""
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr ""
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr ""
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr ""
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr ""
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr ""
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr ""
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr ""
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr ""
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr ""
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr ""
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr ""
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr ""
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr ""
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr ""
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr ""
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr ""
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr ""
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr ""
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr ""
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr ""
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr ""
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr ""
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr ""
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr ""
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr ""
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr ""
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr ""
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr ""
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr ""
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr ""
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr ""
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr ""
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr ""
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr ""
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr ""
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr ""
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr ""
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr ""
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr ""
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr ""
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr ""
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr ""
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr ""
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr ""
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr ""
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr ""
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr ""
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr ""
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr ""
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr ""
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr ""
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr ""
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr ""
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr ""
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr ""
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr ""
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr ""
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr ""
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr ""
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr ""
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr ""
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr ""
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr ""
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr ""
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr ""
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr ""
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr ""
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr ""
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr ""
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr ""
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr ""
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr ""
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr ""
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr ""
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr ""
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr ""
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr ""
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr ""
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr ""
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr ""
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr ""
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr ""
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr ""
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr ""
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr ""
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr ""
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr ""
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr ""
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr ""
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr ""
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr ""
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr ""
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr ""
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr ""
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr ""
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr ""
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr ""
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr ""
+
+#: transact.c:554
+#, c-format
+msgid "line: %s"
+msgstr ""
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr ""
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr ""
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr ""
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr ""
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr ""
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr ""
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr ""
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr ""
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr ""
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr ""
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr ""
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr ""
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, c-format
+msgid "Merged UID list from %s:"
+msgstr ""
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr ""
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr ""
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr ""
+
+#: uid.c:575
+msgid "discarding new UID list\n"
+msgstr ""
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr ""
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr ""
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr ""
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr ""
diff --git a/po/fr.gmo b/po/fr.gmo
new file mode 100644
index 00000000..b5203524
--- /dev/null
+++ b/po/fr.gmo
diff --git a/po/fr.po b/po/fr.po
new file mode 100644
index 00000000..f05735fc
--- /dev/null
+++ b/po/fr.po
@@ -0,0 +1,2915 @@
+# Message translation file for fetchmail
+# Copyright (C) 1999 Free Software Foundation, Inc.
+# Guy Brand <guybrand@chimie.u-strasbg.fr>, 1999-2000.
+#
+# fr translation for fetchmail
+# Copyright (C) 1999 Free Software Foundation, Inc.
+# Guy Brand <guybrand@chimie.u-strasbg.fr>, Avril 2000
+# mise à jour par Sébastien KALT <ustilago@bigfoot.com>
+# mise à jour par Thierry Vignaud <tvignaud@mandrakesoft.com>
+# Commentaires bienvenus
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 6.2.2\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2003-05-15 22:58+0200\n"
+"Last-Translator: Thierry Vignaud <tvignaud@mandrakesoft.com>\n"
+"Language-Team: fr <fr@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=ISO-8859-1\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: Emacs-21.3\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Vérification si %s est réellement le même noeud que %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Oui, leurs adresses IP coïncident\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Non, leurs adresses IP ne coïncident pas\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr "échec de la résolution de noms pour «%s» durant réception depuis %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "impossible de décoder le challenge BASE64 \n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "décodé comme %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "erreur kerberos %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s  [le serveur indique «%*s»] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Subject: Alerte de Fetchmail: messages trop grands.\n"
+"\n"
+"Les messages suivants, qui sont trop grands, restent sur le serveur\n"
+"de mail %s :"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\tmessage %d de %d octets ignoré par fetchmail.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "message %s@%s:%d ignoré (%d octets)"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "message %s@%s:%d ignoré (%d octets)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr " (longueur -1)"
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr " (trop volumineux)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr "impossible de récupérer l'en-tete du message %s@%s:%d (%d octets)\n"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "lecture du message %s@%s:%d parmi %d"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d %soctets)"
+
+#: driver.c:606
+msgid "header "
+msgstr "en-tête "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d octets dans le corps) "
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"le message %s@%s:%d n'est pas de la longueur attendue (%d actuelle != %d "
+"attendue)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " conservé\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " éliminé\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " non éliminé\n"
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+"fetchlimit %d atteinte; %d messages demeurent sur le serveur %s (compte %s)\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "«SIGPIPE» envoyé par un MDA ou une erreur de «stream socket»\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+"délai dépassé après %d secondes d'attente d'une connexion avec le serveur %"
+"s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "délai dépassé après %d secondes d'attente du serveur %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "délai dépassé après %d secondes d'attente de %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr "délai dépassé après %d secondes d'attente de la réponse du client.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "délai d'attente dépassé après %d secondes.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr ""
+"Subject: fetchmail a rencontré des dépassements de délais à plusieurs "
+"reprises\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail a rencontré plus de %d dépassements de délais en récupérant du "
+"courrier depuis %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Ceci pourrait vouloir dire que votre serveur de courrier est bloqué,\n"
+"ou que votre serveur SMTP est coincé, ou que le fichier contenant\n"
+"votre boîte aux lettres sur le serveur a été corrompu par une erreur\n"
+"du serveur.  Vous pouvez exécuter «fetchmail -v -v» pour \n"
+"diagnostiquer le problème\n"
+"\n"
+"Fetchmail n'interrogera pas de nouveau cette boîte aux lettres\n"
+"tant que vous ne l'aurez pas redémarré.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "la commande de pré-connexion a échoué avec l'état %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "impossible de trouver la boîte HESIOD pour %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Le serveur principal n'a pas de nom\n"
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "impossible de trouver le nom canonique DNS de %s\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "inconsistance interne\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "Échec de connexion %s avec %s"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "hôte inconnu."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "le nom est valide mais ne correspond à aucune adresse IP."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "erreur irrécupérable avec le serveur de noms."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "erreur temporaire avec le serveur de noms."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "erreur DNS inconnue %d."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Subject: avertissement de serveur non accessible par Fetchmail.\n"
+"\n"
+"Fetchmail ne peut pas accéder au serveur de mail %s :"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "Échec de la connexion SSL\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Erreur «lock-busy» sur %s@%s\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Erreur «busy» sur %s@%s\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Échec de l'autorisation sur %s@%s%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr " (précédemment autorisée)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: l'authentification de fetchmail a échoué sur %s@%s\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail n'a pas pu recevoir le courrier de %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Votre demande d'autorisation a échoué.\n"
+"Votre mot de passe est probablement erroné, mais certains serveurs\n"
+"ont d'autres types d'erreurs que fetchmail ne peut pas distinguer\n"
+"de celle-ci car ils n'envoient pas de messages d'erreur utiles\n"
+"en cas d'échec du login.\n"
+"\n"
+"Le démon fetchmail va continuer à s'exécuter et à tenter de se connecter\n"
+"a chaque réveil. Il n'y aura plus d'autre notifications jusqu'à ce que\n"
+"le service soit réactivé."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Votre demande d'autorisation a échoué.\n"
+"Votre mot de passe est probablement erroné, mais certains serveurs\n"
+"ont d'autres types d'erreurs que fetchmail ne peut pas distinguer\n"
+"de celle-ci car ils n'envoient pas de messages d'erreur utiles\n"
+"en cas d'échec du login.\n"
+"\n"
+"Le démon fetchmail va continuer à s'exécuter et à tenter de se connecter\n"
+"a chaque réveil. Il n'y aura plus d'autre notifications jusqu'à ce que\n"
+"le service soit réactivé."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr "Re-récupération immédiate sur %s@%s\n"
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Erreur de login ou d'identification inconnue pour %s@%s\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Autorisation OK sur %s@%s\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: l'authentification de fetchmail a réussie sur %s@%s\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail n'a pu enregistrer dans le journal (%s@%s).\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "Le service a été réactivé\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "sélection ou re-réception du dossier %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "sélection ou re-réception du dossier par défaut\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s dans %s (dossier %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s dans %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Réception de %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d vu) pour %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "messages"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "message"
+
+#: driver.c:1366
+msgid "seen"
+msgstr "déjà vu"
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s pour %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d octets).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "Aucun message pour %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "nombre de messages erroné !"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "l'en-tête RFC822 est manquant ou endommagé"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "synchronisation client/serveur"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "protocole client/serveur"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "verrou occupé sur le serveur"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "Transaction SMTP"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "requête au DNS"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "erreur non définie\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "erreur %s durant l'envoi vers le serveur SMTP %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "erreur %s durant la réception de %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "la commande de post-connexion a échoué avec l'état %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Support de Kerberos V4 non inclus.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Support de Kerberos V5 non inclus.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Option --flush non supportée avec %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Option --all non supportée avec %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Option --limit non supportée avec %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s : la variable d'environnement QMAILINJECT est renseignée.\n"
+"C'est dangereux car cela permet à qmail-inject ou à l'enveloppeur\n"
+"sendmail de qmail d'altérer vos entêtes `From:' ou `Message-ID:'.\n"
+"Essayez avec \"env QMAILINJECT= %s VOS ARGUMENTS ICI\"\n"
+"%s : Abandon.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s : la variable d'environnement NULLMAILER_FLAGS est renseignée.\n"
+"C'est dangereux car cela permet à qmail-inject ou à l'enveloppeur\n"
+"sendmail de qmail d'altérer vos entêtes `From:', `Message-ID:',\n"
+"ou `Return-Path:'.\\n\"\n"
+"Essayez avec \"env QMAILINJECT= %s VOS ARGUMENTS ICI\"\n"
+"%s : Abandon.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s : Vous n'existez pas.  Allez vous en.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s : impossible de déterminer le nom de votre hôte !"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "«gethostbyname» a échoué pour %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "Le serveur SMTP de %s ne supporte pas ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "Le serveur SMTP de %s ne supporte pas ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Queue pour %s initiée\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Aucun message en attente pour %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Messages en attente pour %s initiés\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Impossible de placer les messages pour le noeud %s en queue\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Noeud %s non permis : %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "Erreur de syntaxe ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "Erreur de syntaxe ETRN dans les paramètres\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Erreur ETRN inconnue %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "L'option --keep n'est pas supportée avec ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "L'option --keep n'est pas supportée avec ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "L'option --remote n'est pas supportée avec ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "L'option --check n'est pas supportée avec ETRN\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail appellé avec"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "impossible de trouver le répertoire de travail courrant\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Ceci est fetchmail, version %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Lecture des options sur la ligne de commande %s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " et "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "Pas de serveur de courrier paramétré -- %s est peut-être manquant ?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: aucun serveur de courrier n'a été spécifié.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: aucun autre fetchmail n'est en cours d'exécution\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: erreur en terminant %s fetchmail (%d); abandon.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "tâche de fond"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "premier plan"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %s fetchmail (%d) terminé.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: impossible de vérifier le courrier lorsqu'un autre fetchmail est "
+"exécuté sur le même hôte\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: impossible de récupérer le courrier si un autre fetchmail est "
+"exécuté sur %d.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr ""
+"fetchmail: un autre fetchmail, au premier plan, est en exécution sur %d.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: les options ne sont pas disponibles lorsque fetchmail fonctionne "
+"en tâche de fond.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: fetchmail en tâche de fond (%d) a été réactivé.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: processus fils plus ancien (%d) terminé mystérieusement.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: ne trouve pas de mot de passe pour %s@%s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Entrez le mot de passe pour %s@%s : "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "démarrage de fetchmail %s en tâche de fond \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "impossible d'ouvrir %s pour y ajouter les messages\n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "«time-check» %s impossible (erreur %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "redémarrage de fetchmail (%s  a changé)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+"la tentative de réexécution peut échouer car le répertoire n'a pas été "
+"recréé\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "la tentative d'exécuter à nouveau fetchmail a échoué\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"réception de %s ignorée (authentification échouée ou dépassements de "
+"délais)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "intervalle non atteint, pas de requête vers %s\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "État de la requête=0 (SUCCES)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "État de la requête=1 (PAS DE MAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "État de la requête=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "État de la requête=3 (ECHEC DE L'AUTHENTIFICATION)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "État de la requête=4 (PROTOCOLE)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "État de la requête=5 (SYNTAXE)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "État de la requête=6 (ERREUR E/S)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "État de la requête=7 (ERREUR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "État de la requête=8 (EXCLU)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "État de la requête=9 (verrou déjà pris)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "État de la requête=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "État de la requête=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "État de la requête=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "État de la requête=13 (NOMBRE MAXIMUM DE MESSAGES ATTEINT)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "État de la requête=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Toutes les connexions sont établies. Terminé.\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "mise en sommeil à %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "réveillé par %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "réveillé par un signal %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "réveillé à %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "terminaison normale, état %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "impossible de «time-check» le fichier run-control\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr ""
+"Attention : plusieurs mentions de l'hôte %s dans le fichier de "
+"configuration\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "Le support de SSL n'est pas été activé à la compilation.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: attention: aucun DNS disponible pour vérifier les réceptions "
+"«multidrop» depuis %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "configuration de %s invalide, le numéro de port ne peut être négatif\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "configuration de %s invalide, RPOP requiert un port privilégié\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"configuration de %s invalide, LMTP ne peut utiliser le port SMTP par défaut\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "Utiliser «fetchall» et «keep» ensemble en mode démon est une erreur!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "terminé par un signal %d\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s interroge %s (protocole %s) à %s : récupération en cours\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "Le support de POP2 n'est pas configuré.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "Le support de POP3 n'est pas configuré.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "Le support d'IMAP n'est pas configuré.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "Le support d'ETRN n'est pas configuré.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "Impossible de supporter ETRN sans gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "Le support de ODMR n'est pas configuré.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "Impossible de supporter ODMR sans gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "protocole sélectionné non supporté.\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s interroge %s (protocole %s) à %s : interrogation finie\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "L'intervalle entre les réceptions est de %d secondes\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Le fichier de traces est %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Le fichier des identificateurs est %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Les messages de progression sont enregistrés via syslog\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail va se masquer et ne générer aucun «Received»\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr "Fetchmail affichera des points de progression, même dans le journal\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr ""
+"Fetchmail réexpédiera les messages «multidrop» mal aiguillés vers %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr ""
+"Fetchmail expédiera les erreurs de messagerie\n"
+"au maître de poste.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail expédiera les erreur de messagerie à l'envoyeur\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Options pour la réception depuis %s@%s :\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Le courrier sera reçu via %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  La réception depuis ce serveur s'opérera tous les %d intervalles.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Le vrai nom du serveur est %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr "  Cet hôte %s interrogé lorsqu'aucun hôte n'est spécifié.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr "ne sera pas"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr "sera"
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Le mot de passe sera requis.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  Secret APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  Identification RPOP = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Mot de passe = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  Le protocole est KPOP avec authentification Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  Le protocole est %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (utilisant le service %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (utilisant les options réseaux de sécurité %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (utilisant le port %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (utilisant le port par défaut)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (forçant l'usage des UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  Toutes les méthodes d'authentification vont être essayées.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "Authentification par mot de passe forcé.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "L'authentification NTLM forcée.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  Authentification OTP forcée.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  Authentification CRAM-Md5 forcée.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  Authentification GSSAPI forcée.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Authentification de Kerberos V4 forcée.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr " Authentification de Kerberos V5 forcée.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  cryptage «End-to-end» assumé.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  Le principal service de mail est: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  Les sessions encryptée SSL sont supportées.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  Protocole SSL: %s\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  Activation de la vérification des certificats du serveur SSL.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  Répertoire des certificats SSL surs: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr "  Signature de la clé SSL (vérifié via le serveur de clés): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  Le délai d'attente d'une réponse du serveur est de %d secondes"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (par défaut).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  La boîte aux lettres par défaut est sélectionnée.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Les boîtes aux lettres sélectionnées sont :"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s messages seront reçus (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "Tous les"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "Uniquement les nouveaux"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Tout message récupéré %s conservé sur le serveur (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+"  Tout ancien message %s éliminé avant relève du courrier (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  La ré-écriture des adresses locales est %se (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "activé"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "inactivé"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  La suppression des retour-chariots est %se (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Le forçage des retour-chariots est %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+"  L'interprétation des «Content-Transfer-Encoding» est %se (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  Le décodage MIME est %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  L'inoccupation après la réception est %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Les lignes «Status» non vides seront %ses (dropstatus %s).\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "ignoré"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "conservé"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr ""
+"  Les lignes «Delivered-To» non vides seront %ses (dropdelivered %s).\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  La taille des messages est limitée à %d octets (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  La taille des messages n'est pas limitée (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  Alertes sur la taille des messages toutes les %d secondes (--warnings %"
+"d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+"  Alertes sur la taille des messages à chaque réception (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  Le nombre de messages reçu est limité à %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  Le nombre de messages reçu n'est pas limité (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  La limite de taille de récupération de messages est %d (--fetchsizelimit %d)\n"
+
+#: fetchmail.c:1650
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Aucune limite de taille de récupération de messages (--fetchsizelimit 0)\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr "  Effectue la recherche binaire des UIDs à chaque sondage (--fastuidl 1).\n"
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr "  Effectue la recherche binaire des UIDs durant %d sondages sur %d (--fastuidl %d).\n"
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr "  Effectue la recherche linéaire des UIDs à chaque sondage (--fastuidl 0).\n"
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  Le nombre de messages expédiés est limité à %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  Le nombre de messages expédiés n'est pas limité (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+"  Purge à chaque fois que %d messages ont été éliminés (--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Aucune purge forcée n'aura lieu (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Domaines pour lesquels le mail est récupéré :"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (par défaut)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Les messages seront ajoutés après %s en tant que BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Les messages seront acheminés avec \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Les messages seront réexpédiés via %cMTP vers :"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  Le nom de la machine sur la ligne «MAIL FROM» sera %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr "  L'adresse placée après la commande SMTP 'RCPT TO' sera %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Les réponses du serveur reconnaissant des blocs de «spam» sont :"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Le blocage du «spam» est inactivé\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  La connexion au serveur sera initiée avec \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Aucune commande de pré-connexion définie.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  La connexion au serveur sera terminée avec \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Aucune commande de post-connexion définie.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Aucun nom local déclaré pour cet hôte.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Mode «multi-drop»: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Mode «single-drop»: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d nom(s) local(aux) reconnu(s).\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  La requête DNS des adresses «multidrop» est %se.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr ""
+"  Les alias du serveur seront comparés avec les adresses «multidrop» par "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "adresse IP.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "nom.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  Le routage vers l'adresse d'enveloppe est inactivé\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  L'en-tête d'enveloppe est pris comme étant : %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Received"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Numéro de l'en-tête d'enveloppe devant être traité : %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Le préfixe %s sera soustrait des id d'utilisateur\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  Aucun préfixe ne sera soustrait\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Alias pré-déclarés du serveur de courrier :"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Domaines locaux :"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  La connexion se fera via l'interface %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Aucun choix d'interface n'a été spécifié.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  La boucle de réception observera %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Aucune interface à observer n'a été spécifiée.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr "  Connexions au serveur à travers le «plugin» %s (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Aucune commande de «plugin» n'a été spécifiée.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr "  Connexions au client à travers le «plugout» %s (--plugout %s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Aucune commande de «plugout» n'a été spécifiée.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Aucun UID n'a été enregistré sur cet hôte.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d UIDs enregistrés.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+"  Information de traçage de la réception ajoutée aux en-tetes Received.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  Aucune ajout d'information de traçage de la réception aux en-tetes "
+"Received.\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Propriétés du passage \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "échec d'alloca"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "ERREUR: pas de support de la routine getpassword()\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"Détection d'un signal SIGINT... abandon.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Impossible d'obtenir le nom du service pour [%s]\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "Utilisant le nom de service [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Envoi des credentials\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Erreur durant l'échange des credentials\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Impossible d'extraire les données du niveau de sécurité\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Echange des credentials terminé\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Le serveur requiert des échanges intègres et/ou privés\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Options du niveau de sécurité extraites : %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "La taille du composant GSS maximal est %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Erreur à la création de la requête de niveau de sécurité\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Lâchage des credentials GSS\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Erreur de relarguage des credentials\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: mise en sommeil du thread pour %d secondes.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protocole identifié comme étant IMAP4 rev \n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protocole identifié comme étant IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protocole identifié comme étant IMAP2 ou IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "attendra après la réception\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "La fonctionnalité OTP requise n'est pas supportée par fetchmail\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "La fonctionnalité NTLM requise n'est pas supportée par fetchmail.\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "La fonction LOGIN requise n'est pas supportée par le serveur\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "échec de la purge\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "échec durant la re-réception\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "%d messages en attente après le nouveau poll\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "échec de la sélection de boîte aux lettres\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "%d messages en attente après le premier poll\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "%d messages en attente après la purge\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "échec de la recherche des messages non-vus\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u n'est pas vu\n"
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr "%u est le premier a n'avoir pas été vu\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"Impossible d'ouvrir l'interface kvm.\n"
+"Assurez-vous que fetchmail est SGID kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "Impossible d'interpréter le nom de l'interface depuis %s"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: échec du sysctl (iflist estimate)"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: échec malloc"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: échec du sysctl (iflist)"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "La version %d du message de routage n'est pas compréhensible"
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "Aucune interface n'a été trouvée avec le nom %s"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "Aucune adresse IP trouvée pour %s"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "l'adresse IP de l'interface est manquante\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "l'adresse IP de l'interface est invalide\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "le masque de l'interface est invalide\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "activité sur %s -notée- comme étant %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "la réception depuis %s est ignorée, %s arrêtée\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "la réception depuis %s est ignorée, l'adresse IP de %s est exclue\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "activité sur %s vérifiée comme étant %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "la réception depuis %s est ignorée, %s inactivée\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "l'activité sur %s était %d, est %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "impossible de décoder le challenge BASE64 initial\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "%s principal dans le «ticket» ne coïncide pas avec -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "instance non nulle (%s) peut causer un comportement étrange\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "impossible de décoder la réponse BASE64 «ready»\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "non coïncidence du challenge\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: suppression de l'ancien fichier verrou\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: impossible de créer le verrou.\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "attention: \"%s\" rencontré avant tout nom d'hôte"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: attention: \"%s\" rencontré avant tout nom d'hôte\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: attention: le composant \"%s\" est inconnu\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "Le serveur SMTP %s ne supporte pas ATRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "Inversion des rôles émetteur/récepteur maintenant...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "requête ATRN refusée.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "Impossible de traiter la requete ATRN maintenant\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "Vous n'avez pas de mail\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Commande non implémentée\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Authentification nécessaire.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Erreur ODMR inconnue %d\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "L'option --keep n'est pas supportée avec ODMR\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "L'option --keep n'est pas supportée avec ODMR\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "L'option --remote n'est pas supportée avec ODMR\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "L'option --check n'est pas supportée avec ODMR\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "erreur fatale de recv serveur\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Impossible de décoder le challenge OTP\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Phrase de passe secrète : "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "La chaîne de caractères «%s» n'est pas un nombre valide.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "La valeur de la chaîne de caractères «%s» est %s que %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "moins"
+
+#: options.c:211
+msgid "larger"
+msgstr "plus"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Le protocole «%s» spécifié est invalide.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "La authentification «%s» spécifiée est invalide.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: le support de la sécurité réseau est inactif\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "usage:  fetchmail [options] [serveur ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Les options sont les suivantes :\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        afficher la présente aide\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     informations sur la version courante\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       vérifier les messages sans les récupérer\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      travailler silencieusement\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     travail verbeux (information de diagnostic)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      démarrer en démon toutes les n secondes\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    ne pas lancer de processus démon\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        terminer le processus démon\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     spécifier le nom du fichier de traces\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      utiliser syslog(3) pour les messages, en mode démon\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   ne pas écrire de `Received' y activer le spoofing\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc spécifier un autre fichier de contrôle\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      spécifier un autre fichier contenant les UIDs\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  spécifier le destinataire en dernier ressort\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr "      --nobounce    redirige les rebonds vers le maître de poste.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   spécifier l'interface requise\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     surveiller l'activité d'une interface\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         permettre les sessions cryptées SSL\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey       fichier de clé SSL privée\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     certificat de session SSL\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      --sslproto    force le protocole ssl (ssl2/ssl3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+"      --plugin      spécifier la commande externe pour ouvrir la connexion\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     spécifier la commande externe pour ouvrir la connexion "
+"smtp\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    spécifier le protocole de récupération (voir la page "
+"man)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        forcer l'utilisation des UIDLs (uniquement pop3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        port TCP/IP auquel se connecter\n"
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr ""
+"      --auth        type d'authentification (mot de passe/kerberos/ssh/otp)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     temps d'attente d'une réponse du serveur\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    en-tête de l'adresse d'enveloppe\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr "  -Q, --qvirtual    préfixer à soustraire à l'id local d'utilisateur\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   principal service mail\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+"      --tracepolls  ajoute des informations de tracage de la réception\n"
+"                    aux en-testes Received\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr ""
+"  -u, --username    spécifier le `login' de l'utilisateur sur le serveur\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         récupérer anciens et nouveaux messages\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr ""
+"  -K, --nokeep      supprimer les nouveaux messages après récupération\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr ""
+"  -k, --keep        conserver les nouveaux messages après récupération\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       supprimer les anciens messages du serveur\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   ne pas récrire les adresses d'en-tête\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr ""
+"  -l, --limit       limite maximale de la taille des messages à récupérer\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    intervalle entre les notifications de courrier\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      configurer la requête de sécurité IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    spécifier l'hôte SMTP pour la réexpédition\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr "      --fetchdomains récupère le mail pour les domaines indiqués\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr ""
+"  -D, --smtpaddress spécifier le domaine de délivrance SMTP à utiliser\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr "      --smtpname    force le nom complet SMTP nom@domaine\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    configurer les valeurs de réponse anti`spam'\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+"  -b, --batchlimit  limite du nombre de messages pour chaque connexion SMTP\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  limite des récupérations pour les connexions au serveur\n"
+
+#: options.c:720
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr "      --fetchsizelimit indique la tialle limite des messages récupérés\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr "      --fastuidl    effectue une recherche binaire des UIDLs\n"
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+"  -e, --expunge     limite du nombre des suppressions entre deux purges\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         spécifier le MDA à utiliser pour la réexpédition\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       spécifier le fichier de sortie BSMTP\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        utiliser LMTP (RFC2033) pour la délivrance\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      spécifier le nom du dossier distant\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+"      --showdots    affiche des points de progression, même dans le journal\n"
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "L'horodatage APOP requis est absent du message d'invitation\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Erreur de syntaxe dans l'horodatage du message d'invitation\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Requête de protocole indéfinie dans POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "Fichier verrou en service. Y'a-t-il une autre session active ?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr "id=%s (num=%d) a été effacé, mais est toujours présent !\n"
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr "Messages insérés dans une liste du serveur. Impossible de gérer ça.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "erreur de protocole\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "erreur de protocole durant la réception des UIDLs\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "L'option --remote n'est pas supportée avec POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "une option serveur est placée après les options utilisateur"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "le support de SDPS est désactivé"
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "requête de niveau de sécurité invalide"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "le support de la sécurité réseau est inactif"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: l'option interface n'est supportée que sous Linux (sans IPv6) "
+"et \n"
+"FreeBSD\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: l'option monitor n'est supportée que sous Linux (sans IPv6) et \n"
+"FreeBSD\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "le support de SSL n'est pas activé"
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "fin de l'entrée"
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "Le fichier %s doit etre un fichier normal.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "Le fichier %s doit avoir au moins les permissions -rwx--x--- (0710)\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "Le fichier %s doit vous appartenir.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Erreur système inconnue"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (message de trace incomplet)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "erreur partielle de surcharge du tampon de message"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "Sur le point de réécrire %s"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "La version réécrite est %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Succès"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Utilisation restreinte (quelque chose d'anormal avec le compte)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "ID Utilisateur ou phrase de passe invalide"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "Erreur fatale"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "Composant RPA 2: erreur de décodage Base64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Service retenu RPA version %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Challenge du service (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Horodatage du service %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "Erreur sur la longueur du composant RPA 2\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Liste des domaines : %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "Erreur RPA dans la chaîne service@domaine\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "Composant RPA 4 : erreur de décodage\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Authentification de l'utilisateur (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "Etat RPA : %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "Erreur dans la longueur du composant RPA 4\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA vous a rejeté : %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA vous a rejeté pour une raison inconnue\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr ""
+"Erreur dans la longueur de l'authentification RPA de l'utilisateur : %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "Erreur de longueur de clé de session RPA : %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "Échec d'authentification du _service_ RPA. Serveur falsifié ?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Clé de session établie :\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "Autorisation RPA complète\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Obtention de la réponse\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Obtention d'un retour de réponse %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "L'en-tête n'est pas 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "Erreur de longueur de composant\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "La longueur %d du composant n'est pas conforme à rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Champ du mécanisme incorrect\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "Erreur dec64 sur le caractère %d : %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Données binaires entrantes :\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Données sortantes:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "Chaîne de caractères RPA trop longue\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "Échec RPA à l'ouverture de /dev/urandom. Ceci ne devrait pas\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    empêcher votre login, mais signifie que\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    rien ne garantit que vous discutez avec\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    le service que vous pensez utiliser (des attaques\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    par imitation par un service louche sont possibles).\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Challenge d'utilisateur :\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "Application de MD5 au bloc de données :\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "Le résultat de MD5 est : \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "réexpédition vers %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (corps du message ayant rebondi)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "message depuis %s ayant rebondi sur %s\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "L'erreur mémorisée est toujours %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "Erreur %cMTP: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "Échec d'ouverture du fichier BSMTP ou à l'écriture du préambule\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "Le serveur %cMTP n'apprécie pas l'adresse de destinataire `%s'\n"
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "Le serveur %cMTP n'apprécie pas l'adresse du destinataire `%s'\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "les adresses ne correspondent pas ; pas de postmaster\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "il n'est même pas possible d'expédier vers %s\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "aucune correspondance dans les adresses ; réexpédition vers %s.\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "sur le point de délivrer le courrier à : %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "Échec d'ouverture MDA\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "Échec de connexion %cMTP avec %s\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "ne peut relever l'agent ; se replie sur %s"
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr "le programme de livraison du courrier a été tué par un signal %d\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "MDA a retourné un état non nul (%d)\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr "Etrange : le MDA a retourné %d lors du pclose; cas impossible à gérer %s:%d\n"
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Échec à la terminaison du message ou à la fermeture de BSMTP\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "Le serveur SMTP a refusé de délivrer le courrier\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "Erreur de délivrance LMTP en EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Réponse non-503 inattendue à un ordre LMTP EOM: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tLe Démon Fetchmail\n"
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "Authentification ESMTP CRAM-Md5...\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "Le serveur a refusé la commande AUTH.\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "Mauvaise réponse en base 64 du serveur.\n"
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "Challenge décodé: %s\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "Autentification ESMTP PLAIN ...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "Autentification ESMTP LOGIN ...\n"
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr "erreur de protocole avec le serveur smtp\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: échec de malloc\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: échec socketpair\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: échec fork\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "échec dup2\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "exécution de %s (machine %s, service %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "échec de execvp(%s)\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: longueur d'adresse illégale reçue de l'hôte %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Organisation de l'expéditeur: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+"Avertissement: le nom de l'organisation de l'expéditeur est tros long (et "
+"peut etre tronqué).\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "Organisation inconnue\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "Nom commun de l'émetteur : %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+"Avertissement: le nom de l'expéditeur est tros long (et peut etre tronqué).\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "Nom commun de l'expéditeur inconnu\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Nom commun du serveur: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "Certificat erroni: Sujet nom commun trop long!\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "Pas de concordance du nom commun du serveur: %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+"Le nom du serveur n'est pas spécifié, impossible de vérifier le certificat!\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "Nom commun du serveur inconnu\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "Le nom du serveur n'est pas présent dans le certificat!\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "échec de EVP_md5()\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "Plus de mémoire!\n"
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "Le tampon résumé est trop court!\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "signature de la clé %s : %s\n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "La signature %s correspond.\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "La signature %s ne correspond pas!\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "Avertissement: vérification du certificat du serveur: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "expéditeur inconnu (%d premiers caractères) : %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Descripteur de fichier inaccessible pour SSL"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr ""
+"Le protocole SSL «%s» spécifié est invalide, le protocole par défaut "
+"(SSLv23) est utilisé.\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr "La vérification du certificat ou de la signature n'a pas été faite!\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr "Nouvel essai de lecture sur la socket Cygwin\n"
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr "Le nouvel essai de lecture sur la socket Cygwin a échoué!\n"
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "correspondance de %s en local %s\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "passage au travers de %s et coïncidence avec %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analyse de la ligne «Received»:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "ligne acceptée, %s est un alias du serveur de courrier\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "ligne rejetée, %s n'est pas un alias du serveur de courrier\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "aucune adresse trouvée dans «Received»\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "adresse `%s' trouvée dans «Received»\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "délimiteur de message trouvé durant l'analyse des en-têtes\n"
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "ligne d'en-tête incorrecte trouvée lors du scan des en-têtes\n"
+
+#: transact.c:554
+#, c-format
+msgid "line: %s"
+msgstr "ligne: %s"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "aucune correspondance locale, réexpédition vers %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "réexpédition et effacement supprimés suite à des erreurs de DNS\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "écriture d'en-têtes RFC822\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "aucune adresse de destination ne correspond aux noms locaux déclarés"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "l'adresse de destination %s ne correspond à aucun nom local"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "le message contient des caractères NULs"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "Le serveur SMTP rejette les adresses locales de destination : "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "écriture du texte du message\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s : %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "Ancienne liste d'UID depuis %s :"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <vide>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Liste brute des UIDs:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, c-format
+msgid "Merged UID list from %s:"
+msgstr "Fusion de la Liste d'UIDs depuis %s :"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "Nouvelle liste d'UID à partir de %s :"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "inversion des listes d'UIDs\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr "ne permute pas les listes d'UIDs, aucun UID vu dans cette requête\n"
+
+#: uid.c:575
+msgid "discarding new UID list\n"
+msgstr "élimination la nouvelle liste d'UIDs\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "Effacement du fichier fetchids.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "Ecriture du fichier fetchids.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "échec malloc\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "échec realloc\n"
+
+#~ msgid "all mailserver name lookups failed, exiting\n"
+#~ msgstr ""
+#~ " toutes les tentatives pour résoudre le nom du serveur de mail ont "
+#~ "échouées. Fin du processus.\n"
+
+#~ msgid "Could not decode initial BASE64 challenge\n"
+#~ msgstr "Impossible de décoder le challenge BASE64 initial\n"
+
+#~ msgid "fetchmail: %s connection to %s failed"
+#~ msgstr "fetchmail: échec de la connexion %s à %s"
+
+#~ msgid "Skipping message %d, length -1\n"
+#~ msgstr "Message %d ignoré, longueur -1\n"
+
+#~ msgid "authorization"
+#~ msgstr "autorisation"
+
+#~ msgid "%s: can't find your name and home directory!\n"
+#~ msgstr ""
+#~ "%s: Impossible de déterminer votre nom et répertoire utilisateur !\n"
+
+#~ msgid "Lockfile at %s\n"
+#~ msgstr "Fichier verrou sur %s\n"
+
+#~ msgid "fetchmail: cannot allocate memory for lock name.\n"
+#~ msgstr "fetchmail: impossible d'allouer la mémoire pour le nom du verrou.\n"
+
+#~ msgid "Requesting authorization as %s\n"
+#~ msgstr "Requête d'une autorisation en tant que %s\n"
+
+#~ msgid "Required GSS capability not supported by server\n"
+#~ msgstr "La fonction GSS requise n'est pas supportée par le serveur\n"
+
+#~ msgid "KERBEROS_V4 authentication is supported\n"
+#~ msgstr "Authentification KERBEROS_V4 supportée\n"
+
+#~ msgid "Required KERBEROS_V4 capability not supported by server\n"
+#~ msgstr ""
+#~ "La fonction KERBEROS_V4 requise n'est pas supportée par le serveur\n"
+
+#~ msgid "Required CRAM-MD5 capability not supported by server\n"
+#~ msgstr "La capacité CRAM-MD5 requise n'est pas supportée par le serveur\n"
diff --git a/po/fr.po.orig b/po/fr.po.orig
new file mode 100644
index 00000000..dddf879a
--- /dev/null
+++ b/po/fr.po.orig
@@ -0,0 +1,2915 @@
+# Message translation file for fetchmail
+# Copyright (C) 1999 Free Software Foundation, Inc.
+# Guy Brand <guybrand@chimie.u-strasbg.fr>, 1999-2000.
+#
+# fr translation for fetchmail
+# Copyright (C) 1999 Free Software Foundation, Inc.
+# Guy Brand <guybrand@chimie.u-strasbg.fr>, Avril 2000
+# mise à jour par Sébastien KALT <ustilago@bigfoot.com>
+# mise à jour par Thierry Vignaud <tvignaud@mandrakesoft.com>
+# Commentaires bienvenus
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 6.2.2\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2003-05-15 22:58+0200\n"
+"Last-Translator: Thierry Vignaud <tvignaud@mandrakesoft.com>\n"
+"Language-Team: fr <fr@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=ISO-8859-1\n"
+"Content-Transfer-Encoding: 8bit\n"
+"X-Generator: Emacs-21.3\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Vérification si %s est réellement le même noeud que %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Oui, les adresses IP coïncident\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Non, les adresses IP ne coïncident pas\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr "échec de la résolution de noms pour «%s» durant réception depuis %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "impossible de décoder le challenge BASE64 \n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "Décodé comme %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "erreur kerberos %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s  [le serveur indique «%*s»] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Subject: Alerte de Fetchmail: messages trop grands.\n"
+"\n"
+"Les messages suivants, qui sont trop grands, restent sur le serveur\n"
+"de mail %s:"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\tmessage %d de %d octets ignoré par fetchmail.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "message %s@%s:%d ignoré (%d octets)"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "message %s@%s:%d ignoré (%d octets)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr " (longueur -1)"
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr " (trop volumineux)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr "impossible de récupérer l'en-tete du message %s@%s:%d (%d octets)\n"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "lecture du message %s@%s:%d parmi %d"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d %soctets)"
+
+#: driver.c:606
+msgid "header "
+msgstr "en-tête "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d octets dans le corps) "
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"le message %s@%s:%d n'est pas de la longueur attendue (%d actuelle != %d "
+"attendue)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " conservé\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " éliminé\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " non éliminé\n"
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+"fetchlimit %d atteinte; %d messages demeurent sur le serveur %s (compte %s)\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "«SIGPIPE» envoyé par un MDA ou une erreur de «stream socket»\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+"délai dépassé après %d secondes d'attente d'une connexion avec le serveur %"
+"s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "délai dépassé après %d secondes d'attente du serveur %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "délai dépassé après %d secondes d'attente de %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr "délai dépassé après %d secondes d'attente de la réponse du client.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "délai d'attente dépassé après %d secondes.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr ""
+"Subject: fetchmail a rencontré des dépassements de délais à plusieurs "
+"reprises\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail a rencontré plus de %d dépassements de délais en récupérant du "
+"courrier depuis %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Ceci pourrait vouloir dire que votre serveur de courrier est bloqué,\n"
+"ou que votre serveur SMTP est coincé, ou que le fichier contenant\n"
+"votre boîte aux lettres sur le serveur a été corrompu par une erreur\n"
+"du serveur.  Vous pouvez exécuter «fetchmail -v -v» pour \n"
+"diagnostiquer le problème\n"
+"\n"
+"Fetchmail n'interrogera pas de nouveau cette boîte aux lettres\n"
+"tant que vous ne l'aurez pas redémarré.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "la commande de pré-connexion a échoué avec l'état %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "impossible de trouver la boîte HESIOD pour %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Le serveur principal n'a pas de nom\n"
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "impossible de trouver le nom canonique DNS de %s\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "inconsistance interne\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "Échec de connexion %s avec %s"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "hôte inconnu."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "le nom est valide mais ne correspond à aucune adresse IP."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "erreur irrécupérable avec le serveur de noms."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "erreur temporaire avec le serveur de noms."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "erreur DNS inconnue %d."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Subject: avertissement de serveur non accessible par Fetchmail.\n"
+"\n"
+"Fetchmail ne peut pas accéder au serveur de mail %s:"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "Échec de la connexion SSL\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Erreur «lock-busy» sur %s@%s\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Erreur «busy» sur %s@%s\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Échec de l'autorisation sur %s@%s%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr " (précédemment autorisée)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: l'authentification de fetchmail a échoué sur %s@%s\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail n'a pas pu recevoir le courrier de %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Votre demande d'autorisation a échoué.\n"
+"Votre mot de passe est probablement erroné, mais certains serveurs\n"
+"ont d'autres types d'erreurs que fetchmail ne peut pas distinguer\n"
+"de celle-ci car ils n'envoient pas de messages d'erreur utiles\n"
+"en cas d'échec du login.\n"
+"\n"
+"Le démon fetchmail va continuer à s'exécuter et à tenter de se connecter\n"
+"a chaque réveil. Il n'y aura plus d'autre notifications jusqu'à ce que\n"
+"le service soit réactivé."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Votre demande d'autorisation a échoué.\n"
+"Votre mot de passe est probablement erroné, mais certains serveurs\n"
+"ont d'autres types d'erreurs que fetchmail ne peut pas distinguer\n"
+"de celle-ci car ils n'envoient pas de messages d'erreur utiles\n"
+"en cas d'échec du login.\n"
+"\n"
+"Le démon fetchmail va continuer à s'exécuter et à tenter de se connecter\n"
+"a chaque réveil. Il n'y aura plus d'autre notifications jusqu'à ce que\n"
+"le service soit réactivé."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr "Re-récupération immédiate sur %s@%s\n"
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Erreur de login ou d'identification inconnue pour %s@%s\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Autorisation OK sur %s@%s\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: l'authentification de fetchmail a réussie sur %s@%s\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail n'a pu enregistrer dans le journal (%s@%s).\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "Le service a été réactivé\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "sélection ou re-réception du dossier %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "sélection ou re-réception du dossier par défaut\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s dans %s (dossier %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s dans %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Réception de %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d vu) pour %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "messages"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "message"
+
+#: driver.c:1366
+msgid "seen"
+msgstr "déja vu"
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s pour %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d octets).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "Aucun message pour %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "mauvais nombre de messages!"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "l'en-tête RFC822 est manquant ou endommagé"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "synchronisation client/serveur"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "protocole client/serveur"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "verrou actif sur le serveur"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "Transaction SMTP"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "requête au DNS"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "erreur non définie\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "erreur %s durant l'envoi vers le serveur SMTP %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "erreur %s durant la réception de %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "la commande de post-connexion a échoué avec l'état %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Support de Kerberos V4 non inclus.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Support de Kerberos V5 non inclus.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Option --flush non supportée avec %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Option --all non supportée avec %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Option --limit non supportée avec %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s : la variable d'environnement QMAILINJECT est renseignée.\n"
+"C'est dangereux car cela permet à qmail-inject ou à l'enveloppeur\n"
+"sendmail de qmail d'altérer vos entêtes `From:' ou `Message-ID:'.\n"
+"Essayez avec \"env QMAILINJECT= %s VOS ARGUMENTS ICI\"\n"
+"%s : Abandon.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s : la variable d'environnement NULLMAILER_FLAGS est renseignée.\n"
+"C'est dangereux car cela permet à qmail-inject ou à l'enveloppeur\n"
+"sendmail de qmail d'altérer vos entêtes `From:', `Message-ID:',\n"
+"ou `Return-Path:'.\\n\"\n"
+"Essayez avec \"env QMAILINJECT= %s VOS ARGUMENTS ICI\"\n"
+"%s : Abandon.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Vous n'existez pas.  Allez vous en.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: impossible de déterminer le nom de votre hôte !"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "«gethostbyname» a échoué pour %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "Le serveur SMTP de %s ne supporte pas ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "Le serveur SMTP de %s ne supporte pas ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Queue pour %s initiée\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Aucun message en attente pour %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Messages en attente pour %s initiés\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Impossible de placer les messages pour le noeud %s en queue\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Noeud %s non permis : %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "Erreur de syntaxe ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "Erreur de syntaxe ETRN dans les paramètres\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Erreur ETRN inconnue %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "Option --keep non supportée avec ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "Option --keep non supportée avec ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "Option --remote non supportée avec ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "Option --check non supportée avec ETRN\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail appellé avec"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "impossible de trouver le répertoire de travail courrant\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Ceci est fetchmail, version %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Lecture des options sur la ligne de commande %s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " et "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "Pas de serveur de courrier paramétré -- %s est peut-être manquant ?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: aucun serveur de courrier n'a été spécifié.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: aucun autre fetchmail n'est en cours d'exécution\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: erreur en terminant %s fetchmail (%d); abandon.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "tâche de fond"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "premier plan"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %s fetchmail (%d) terminé.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: impossible de vérifier le courrier lorsqu'un autre fetchmail est "
+"exécuté sur le même hôte\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: impossible de récupérer le courrier si un autre fetchmail est "
+"exécuté sur %d.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr ""
+"fetchmail: un autre fetchmail, au premier plan, est en exécution sur %d.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: les options ne sont pas disponibles lorsque fetchmail fonctionne "
+"en tâche de fond.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: fetchmail en tâche de fond (%d) a été réactivé.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: processus fils plus ancien (%d) terminé mystérieusement.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: ne trouve pas de mot de passe pour %s@%s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Entrez le mot de passe pour %s@%s : "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "démarrage de fetchmail %s en tâche de fond \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "impossible d'ouvrir %s pour y ajouter les messages\n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "«time-check» %s impossible (erreur %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "redémarrage de fetchmail (%s  a changé)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+"la tentative de réexécution peut échouer car le répertoire n'a pas été "
+"recréé\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "la tentative d'exécuter à nouveau fetchmail a échoué\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"réception de %s ignorée (authentification échouée ou dépassements de "
+"délais)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "intervalle non atteint, pas de requête vers %s\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "État de la requête=0 (SUCCES)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "État de la requête=1 (PAS DE MAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "État de la requête=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "État de la requête=3 (ECHEC DE L'AUTHENTIFICATION)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "État de la requête=4 (PROTOCOLE)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "État de la requête=5 (SYNTAXE)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "État de la requête=6 (ERREUR E/S)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "État de la requête=7 (ERREUR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "État de la requête=8 (EXCLU)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "État de la requête=9 (verrou déjà pris)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "État de la requête=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "État de la requête=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "État de la requête=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "État de la requête=13 (NOMBRE MAXIMUM DE MESSAGES ATTEINT)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "État de la requête=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Toutes les connexions sont établies. Terminé.\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "mise en sommeil à %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "réveillé par %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "réveillé par un signal %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "réveillé à %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "terminaison normale, état %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "impossible de «time-check» le fichier run-control\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr ""
+"Attention : plusieurs mentions de l'hôte %s dans le fichier de "
+"configuration\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "Le support de SSL n'est pas été activé à la compilation.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: attention: aucun DNS disponible pour vérifier les réceptions "
+"«multidrop» depuis %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "configuration de %s invalide, le numéro de port ne peut être négatif\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "configuration de %s invalide, RPOP requiert un port privilégié\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"configuration de %s invalide, LMTP ne peut utiliser le port SMTP par défaut\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "Utiliser «fetchall» et «keep» ensemble en mode démon est une erreur!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "terminé par un signal %d\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s interroge %s (protocole %s) à %s : récupération en cours\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "Le support de POP2 n'est pas configuré.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "Le support de POP3 n'est pas configuré.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "Le support d'IMAP n'est pas configuré.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "Le support d'ETRN n'est pas configuré.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "Impossible de supporter ETRN sans gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "Le support de ODMR n'est pas configuré.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "Impossible de supporter ODMR sans gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "protocole sélectionné non supporté.\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s interroge %s (protocole %s) à %s : interrogation finie\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "L'intervalle entre les réceptions est de %d secondes\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Le fichier de traces est %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Le fichier des identificateurs est %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Les messages de progression sont enregistrés via syslog\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail va se masquer et ne générer aucun «Received»\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr "Fetchmail affichera des points de progression, même dans le journal\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr ""
+"Fetchmail réexpédiera les messages «multidrop» mal aiguillés vers %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr ""
+"Fetchmail expédiera les erreurs de messagerie\n"
+"au maître de poste.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail expédiera les erreur de messagerie à l'envoyeur\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Options pour la réception depuis %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Le courrier sera reçu via %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  La réception depuis ce serveur s'opérera tous les %d intervalles.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Le vrai nom du serveur est %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr "  Cet hôte %s interrogé lorsqu'aucun hôte n'est spécifié.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr "ne sera pas"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr "sera"
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Le mot de passe sera requis.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  Secret APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  Identification RPOP = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Mot de passe = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  Le protocole est KPOP avec authentification Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  Le protocole est %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (utilisant le service %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (utilisant les options réseaux de sécurité %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (utilisant le port %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (utilisant le port par défaut)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (forçant l'usage des UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  Toutes les méthodes d'authentification vont être essayées.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "Authentification par mot de passe forcé.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "L'authentification NTLM forcée.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  Authentification OTP forcée.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  Authentification CRAM-Md5 forcée.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  Authentification GSSAPI forcée.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Authentification de Kerberos V4 forcée.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr " Authentification de Kerberos V5 forcée.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  cryptage «End-to-end» assumé.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  Le principal service de mail est: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  Les sessions encryptée SSL sont supportées.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  Protocole SSL: %s\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  Activation de la vérification des certificats du serveur SSL.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  Répertoire des certificats SSL surs: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr "  Signature de la clé SSL (vérifié via le serveur de clés): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  Le délai d'attente d'une réponse du serveur est de %d secondes"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (par défaut).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  La boîte aux lettres par défaut est sélectionnée.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Les boîtes aux lettres sélectionnées sont :"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s messages seront reçus (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "Tous les"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "Uniquement les nouveaux"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Tout message récupéré %s conservé sur le serveur (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+"  Tout ancien message %s éliminé avant relève du courrier (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  La ré-écriture des adresses locales est %se (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "activé"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "inactivé"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  La suppression des retour-chariots est %se (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Le forçage des retour-chariots est %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+"  L'interprétation des «Content-Transfer-Encoding» est %se (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  Le décodage MIME est %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  L'inoccupation après la réception est %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Les lignes «Status» non vides seront %ses (dropstatus %s).\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "ignoré"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "conservé"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr ""
+"  Les lignes «Delivered-To» non vides seront %ses (dropdelivered %s).\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  La taille des messages est limitée à %d octets (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  La taille des messages n'est pas limitée (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  Alertes sur la taille des messages toutes les %d secondes (--warnings %"
+"d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+"  Alertes sur la taille des messages à chaque réception (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  Le nombre de messages reçu est limité à %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  Le nombre de messages reçu n'est pas limité (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  La limite de taille de récupération de messages est %d (--fetchsizelimit %d)\n"
+
+#: fetchmail.c:1650
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Aucune limite de taille de récupération de messages (--fetchsizelimit 0)\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr "  Effectue la recherche binaire des UIDs à chaque sondage (--fastuidl 1).\n"
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr "  Effectue la recherche binaire des UIDs durant %d sondages sur %d (--fastuidl %d).\n"
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr "  Effectue la recherche linéaire des UIDs à chaque sondage (--fastuidl 0).\n"
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  Le nombre de messages expédiés est limité à %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  Le nombre de messages expédiés n'est pas limité (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+"  Purge à chaque fois que %d messages ont été éliminés (--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Aucune purge forcée n'aura lieu (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Domaines pour lesquels le mail est récupéré :"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (par défaut)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Les messages seront ajoutés après %s en tant que BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Les messages seront acheminés avec \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Les messages seront réexpédiés via %cMTP vers :"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  Le nom de la machine sur la ligne «MAIL FROM» sera %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr "  L'adresse placée après la commande SMTP 'RCPT TO' sera %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Les réponses du serveur reconnaissant des blocs de «spam» sont :"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Le blocage du «spam» est inactivé\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  La connexion au serveur sera initiée avec \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Aucune commande de pré-connexion définie.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  La connexion au serveur sera terminée avec \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Aucune commande de post-connexion définie.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Aucun nom local déclaré pour cet hôte.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Mode «multi-drop»: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Mode «single-drop»: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d nom(s) local(aux) reconnu(s).\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  La requête DNS des adresses «multidrop» est %se.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr ""
+"  Les alias du serveur seront comparés avec les adresses «multidrop» par "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "adresse IP.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "nom.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  Le routage vers l'adresse d'enveloppe est inactivé\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  L'en-tête d'enveloppe est pris comme étant : %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Received"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Numéro de l'en-tête d'enveloppe devant être traité : %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Le préfixe %s sera soustrait des id d'utilisateur\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  Aucun préfixe ne sera soustrait\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Alias pré-déclarés du serveur de courrier :"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Domaines locaux :"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  La connexion se fera via l'interface %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Aucun choix d'interface n'a été spécifié.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  La boucle de réception observera %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Aucune interface à observer n'a été spécifiée.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr "  Connexions au serveur à travers le «plugin» %s (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Aucune commande de «plugin» n'a été spécifiée.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr "  Connexions au client à travers le «plugout» %s (--plugout %s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Aucune commande de «plugout» n'a été spécifiée.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Aucun UID n'a été enregistré sur cet hôte.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d UIDs enregistrés.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+"  Information de traçage de la réception ajoutée aux en-tetes Received.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  Aucune ajout d'information de traçage de la réception aux en-tetes "
+"Received.\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Propriétés du passage \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "échec d'alloca"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "ERREUR: pas de support de la routine getpassword()\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"Détection d'un signal SIGINT... abandon.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Impossible d'obtenir le nom du service pour [%s]\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "Utilisant le nom de service [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Envoi des credentials\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Erreur durant l'échange des credentials\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Impossible d'extraire les données du niveau de sécurité\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Echange des credentials terminé\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Le serveur requiert des échanges intègres et/ou privés\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Options du niveau de sécurité extraites : %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "La taille du composant GSS maximal est %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Erreur à la création de la requête de niveau de sécurité\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Lâchage des credentials GSS\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Erreur de relarguage des credentials\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: mise en sommeil du thread pour %d secondes.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protocole identifié comme étant IMAP4 rev \n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protocole identifié comme étant IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protocole identifié comme étant IMAP2 ou IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "attendra après la réception\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "La fonctionnalité OTP requise n'est pas supportée par fetchmail\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "La fonctionnalité NTLM requise n'est pas supportée par fetchmail.\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "La fonction LOGIN requise n'est pas supportée par le serveur\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "échec de la purge\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "échec durant la re-réception\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "%d messages en attente après le nouveau poll\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "échec de la sélection de boîte aux lettres\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "%d messages en attente après le premier poll\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "%d messages en attente après la purge\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "échec de la recherche des messages non-vus\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u n'est pas vu\n"
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr "%u est le premier a n'avoir pas été vu\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"Impossible d'ouvrir l'interface kvm.\n"
+"Assurez-vous que fetchmail est SGID kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "Impossible d'interpréter le nom de l'interface depuis %s"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: échec du sysctl (iflist estimate)"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: échec malloc"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: échec du sysctl (iflist)"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "La version %d du message de routage n'est pas compréhensible"
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "Aucune interface n'a été trouvée avec le nom %s"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "Aucune adresse IP trouvée pour %s"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "l'adresse IP de l'interface est manquante\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "l'adresse IP de l'interface est invalide\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "le masque de l'interface est invalide\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "activité sur %s -notée- comme étant %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "la réception depuis %s est ignorée, %s arrêtée\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "la réception depuis %s est ignorée, l'adresse IP de %s est exclue\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "activité sur %s vérifiée comme étant %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "la réception depuis %s est ignorée, %s inactivée\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "l'activité sur %s était %d, est %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "impossible de décoder le challenge BASE64 initial\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "%s principal dans le «ticket» ne coïncide pas avec -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "instance non nulle (%s) peut causer un comportement étrange\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "impossible de décoder la réponse BASE64 «ready»\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "non coïncidence du challenge\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: suppression de l'ancien fichier verrou\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: impossible de créer le verrou.\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "attention: \"%s\" rencontré avant tout nom d'hôte"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: attention: \"%s\" rencontré avant tout nom d'hôte\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: attention: le composant \"%s\" est inconnu\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "Le serveur SMTP %s ne supporte pas ATRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "Inversion des rôles émetteur/récepteur maintenant...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "requête ATRN refusée.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "Impossible de traiter la requete ATRN maintenant\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "Vous n'avez pas de mail\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Commande non implémentée\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Authentification nécessaire.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Erreur ODMR inconnue %d\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "L'option --keep n'est pas supportée avec ODMR\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "L'option --keep n'est pas supportée avec ODMR\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "L'option --remote n'est pas supportée avec ODMR\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "L'option --check n'est pas supportée avec ODMR\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "erreur fatale de recv serveur\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Impossible de décoder le challenge OTP\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Phrase de passe secrète : "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "La chaîne de caractères «%s» n'est pas un nombre valide.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "La valeur de la chaîne de caractères «%s» est %s que %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "moins"
+
+#: options.c:211
+msgid "larger"
+msgstr "plus"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Le protocole «%s» spécifié est invalide.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "La authentification «%s» spécifiée est invalide.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: le support de la sécurité réseau est inactif\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "usage:  fetchmail [options] [serveur ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Les options sont les suivantes :\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        afficher la présente aide\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     informations sur la version courante\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       vérifier les messages sans les récupérer\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      travailler silencieusement\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     travail verbeux (information de diagnostic)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      démarrer en démon toutes les n secondes\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    ne pas lancer de processus démon\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        terminer le processus démon\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     spécifier le nom du fichier de traces\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      utiliser syslog(3) pour les messages, en mode démon\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   ne pas écrire de `Received' y activer le spoofing\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc spécifier un autre fichier de contrôle\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      spécifier un autre fichier contenant les UIDs\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  spécifier le destinataire en dernier ressort\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr "      --nobounce    redirige les rebonds vers le maître de poste.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   spécifier l'interface requise\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     surveiller l'activité d'une interface\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         permettre les sessions cryptées SSL\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey       fichier de clé SSL privée\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     certificat de session SSL\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      --sslproto    force le protocole ssl (ssl2/ssl3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+"      --plugin      spécifier la commande externe pour ouvrir la connexion\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     spécifier la commande externe pour ouvrir la connexion "
+"smtp\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    spécifier le protocole de récupération (voir la page "
+"man)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        forcer l'utilisation des UIDLs (uniquement pop3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        port TCP/IP auquel se connecter\n"
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr ""
+"      --auth        type d'authentification (mot de passe/kerberos/ssh/otp)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     temps d'attente d'une réponse du serveur\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    en-tête de l'adresse d'enveloppe\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr "  -Q, --qvirtual    préfixer à soustraire à l'id local d'utilisateur\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   principal service mail\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+"      --tracepolls  ajoute des informations de tracage de la réception\n"
+"                    aux en-testes Received\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr ""
+"  -u, --username    spécifier le `login' de l'utilisateur sur le serveur\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         récupérer anciens et nouveaux messages\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr ""
+"  -K, --nokeep      supprimer les nouveaux messages après récupération\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr ""
+"  -k, --keep        conserver les nouveaux messages après récupération\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       supprimer les anciens messages du serveur\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   ne pas récrire les adresses d'en-tête\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr ""
+"  -l, --limit       limite maximale de la taille des messages à récupérer\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    intervalle entre les notifications de courrier\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      configurer la requête de sécurité IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    spécifier l'hôte SMTP pour la réexpédition\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr "      --fetchdomains récupère le mail pour les domaines indiqués\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr ""
+"  -D, --smtpaddress spécifier le domaine de délivrance SMTP à utiliser\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr "      --smtpname    force le nom complet SMTP nom@domaine\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    configurer les valeurs de réponse anti`spam'\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+"  -b, --batchlimit  limite du nombre de messages pour chaque connexion SMTP\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  limite des récupérations pour les connexions au serveur\n"
+
+#: options.c:720
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr "      --fetchsizelimit indique la tialle limite des messages récupérés\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr "      --fastuidl    effectue une recherche binaire des UIDLs\n"
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+"  -e, --expunge     limite du nombre des suppressions entre deux purges\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         spécifier le MDA à utiliser pour la réexpédition\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       spécifier le fichier de sortie BSMTP\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        utiliser LMTP (RFC2033) pour la délivrance\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      spécifier le nom du dossier distant\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+"      --showdots    affiche des points de progression, même dans le journal\n"
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "L'horodatage APOP requis est absent du message d'invitation\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Erreur de syntaxe dans l'horodatage du message d'invitation\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Requête de protocole indéfinie dans POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "Fichier verrou en service. Y'a-t-il une autre session active ?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr "id=%s (num=%d) a été effacé, mais est toujours présent !\n"
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr "Messages insérés dans une liste du serveur. Impossible de gérer ça.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "erreur de protocole\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "erreur de protocole durant la réception des UIDLs\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "L'option --remote n'est pas supportée avec POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "une option serveur est placée après les options utilisateur"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "le support de SDPS est désactivé"
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "requête de niveau de sécurité invalide"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "le support de la sécurité réseau est inactif"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: l'option interface n'est supportée que sous Linux (sans IPv6) "
+"et \n"
+"FreeBSD\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: l'option monitor n'est supportée que sous Linux (sans IPv6) et \n"
+"FreeBSD\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "le support de SSL n'est pas activé"
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "fin de l'entrée"
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "Le fichier %s doit etre un fichier normal.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "Le fichier %s doit avoir au moins les permissions -rwx--x--- (0710)\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "Le fichier %s doit vous appartenir.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Erreur système inconnue"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (message de trace incomplet)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "erreur partielle de surcharge du tampon de message"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "Sur le point de réécrire %s"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "La version réécrite est %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Succès"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Utilisation restreinte (quelque chose d'anormal avec le compte)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "ID Utilisateur ou phrase de passe invalide"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "Erreur fatale"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "Composant RPA 2: erreur de décodage Base64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Service retenu RPA version %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Challenge du service (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Horodatage du service %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "Erreur sur la longueur du composant RPA 2\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Liste des domaines : %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "Erreur RPA dans la chaîne service@domaine\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "Composant RPA 4 : erreur de décodage\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Authentification de l'utilisateur (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "Etat RPA : %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "Erreur dans la longueur du composant RPA 4\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA vous a rejeté : %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA vous a rejeté pour une raison inconnue\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr ""
+"Erreur dans la longueur de l'authentification RPA de l'utilisateur : %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "Erreur de longueur de clé de session RPA : %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "Échec d'authentification du _service_ RPA. Serveur falsifié ?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Clé de session établie :\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "Autorisation RPA complète\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Obtention de la réponse\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Obtention d'un retour de réponse %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "L'en-tête n'est pas 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "Erreur de longueur de composant\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "La longueur %d du composant n'est pas conforme à rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Champ du mécanisme incorrect\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "Erreur dec64 sur le caractère %d : %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Données binaires entrantes :\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Données sortantes:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "Chaîne de caractères RPA trop longue\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "Échec RPA à l'ouverture de /dev/urandom. Ceci ne devrait pas\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    empêcher votre login, mais signifie que\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    rien ne garantit que vous discutez avec\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    le service que vous pensez utiliser (des attaques\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    par imitation par un service louche sont possibles).\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Challenge d'utilisateur :\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "Application de MD5 au bloc de données :\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "Le résultat de MD5 est : \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "réexpédition vers %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (corps du message ayant rebondi)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "message depuis %s ayant rebondi sur %s\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "L'erreur mémorisée est toujours %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "Erreur %cMTP: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "Échec d'ouverture du fichier BSMTP ou à l'écriture du préambule\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "Le serveur %cMTP n'apprécie pas l'adresse de destinataire `%s'\n"
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "Le serveur %cMTP n'apprécie pas l'adresse du destinataire `%s'\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "les adresses ne correspondent pas ; pas de postmaster\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "il n'est même pas possible d'expédier vers %s\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "aucune correspondance dans les adresses ; réexpédition vers %s.\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "sur le point de délivrer le courrier à : %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "Échec d'ouverture MDA\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "Échec de connexion %cMTP avec %s\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "ne peut relever l'agent ; se replie sur %s"
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr "le programme de livraison du courrier a été tué par un signal %d\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "MDA a retourné un état non nul (%d)\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr "Etrange : le MDA a retourné %d lors du pclose; cas impossible à gérer %s:%d\n"
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Échec à la terminaison du message ou à la fermeture de BSMTP\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "Le serveur SMTP a refusé de délivrer le courrier\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "Erreur de délivrance LMTP en EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Réponse non-503 inattendue à un ordre LMTP EOM: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tLe Démon Fetchmail\n"
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "Authentification ESMTP CRAM-Md5...\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "Le serveur a refusé la commande AUTH.\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "Mauvaise réponse en base 64 du serveur.\n"
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "Challenge décodé: %s\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "Autentification ESMTP PLAIN ...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "Autentification ESMTP LOGIN ...\n"
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr "erreur de protocole avec le serveur smtp\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: échec de malloc\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: échec socketpair\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: échec fork\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "échec dup2\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "exécution de %s (machine %s, service %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "échec de execvp(%s)\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: longueur d'adresse illégale reçue de l'hôte %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Organisation de l'expéditeur: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+"Avertissement: le nom de l'organisation de l'expéditeur est tros long (et "
+"peut etre tronqué).\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "Organisation inconnue\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "Nom commun de l'émetteur : %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+"Avertissement: le nom de l'expéditeur est tros long (et peut etre tronqué).\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "Nom commun de l'expéditeur inconnu\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Nom commun du serveur: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "Certificat erroni: Sujet nom commun trop long!\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "Pas de concordance du nom commun du serveur: %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+"Le nom du serveur n'est pas spécifié, impossible de vérifier le certificat!\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "Nom commun du serveur inconnu\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "Le nom du serveur n'est pas présent dans le certificat!\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "échec de EVP_md5()\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "Plus de mémoire!\n"
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "Le tampon résumé est trop court!\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "signature de la clé %s: %s\n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "La signature %s correspond.\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "La signature %s ne correspond pas!\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "Avertissement: vérification du certificat du serveur: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "expéditeur inconnu (%d premiers caractères) : %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Descripteur de fichier inaccessible pour SSL"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr ""
+"Le protocole SSL «%s» spécifié est invalide, le protocole par défaut "
+"(SSLv23) est utilisé.\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr "La vérification du certificat ou de la signature n'a pas été faite!\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr "Nouvel essai de lecture sur la socket Cygwin\n"
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr "Le nouvel essai de lecture sur la socket Cygwin a échoué!\n"
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "correspondance de %s en local %s\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "passage au travers de %s et coïncidence avec %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analyse de la ligne «Received»:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "ligne acceptée, %s est un alias du serveur de courrier\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "ligne rejetée, %s n'est pas un alias du serveur de courrier\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "aucune adresse trouvée dans «Received»\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "adresse `%s' trouvée dans «Received»\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "délimiteur de message trouvé durant l'analyse des en-têtes\n"
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "ligne d'en-tête incorrecte trouvée lors du scan des en-têtes\n"
+
+#: transact.c:554
+#, c-format
+msgid "line: %s"
+msgstr "ligne: %s"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "aucune correspondance locale, réexpédition vers %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "réexpédition et effacement supprimés suite à des erreurs de DNS\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "écriture d'en-têtes RFC822\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "aucune adresse de destination ne correspond aux noms locaux déclarés"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "l'adresse de destination %s ne correspond à aucun nom local"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "le message contient des caractères NULs"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "Le serveur SMTP rejette les adresses locales de destination : "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "écriture du texte du message\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "Ancienne liste d'UID depuis %s:"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <vide>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Liste brute des UIDs:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, c-format
+msgid "Merged UID list from %s:"
+msgstr "Fusion de la Liste d'UIDs depuis %s:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "Nouvelle liste d'UID à partir de %s:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "inversion des listes d'UIDs\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr "ne permute pas les listes d'UIDs, aucun UID vu dans cette requête\n"
+
+#: uid.c:575
+msgid "discarding new UID list\n"
+msgstr "élimination la nouvelle liste d'UIDs\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "Effacement du fichier fetchids.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "Ecriture du fichier fetchids.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "échec malloc\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "échec realloc\n"
+
+#~ msgid "all mailserver name lookups failed, exiting\n"
+#~ msgstr ""
+#~ " toutes les tentatives pour résoudre le nom du serveur de mail ont "
+#~ "échouées. Fin du processus.\n"
+
+#~ msgid "Could not decode initial BASE64 challenge\n"
+#~ msgstr "Impossible de décoder le challenge BASE64 initial\n"
+
+#~ msgid "fetchmail: %s connection to %s failed"
+#~ msgstr "fetchmail: échec de la connexion %s à %s"
+
+#~ msgid "Skipping message %d, length -1\n"
+#~ msgstr "Message %d ignoré, longueur -1\n"
+
+#~ msgid "authorization"
+#~ msgstr "autorisation"
+
+#~ msgid "%s: can't find your name and home directory!\n"
+#~ msgstr ""
+#~ "%s: Impossible de déterminer votre nom et répertoire utilisateur !\n"
+
+#~ msgid "Lockfile at %s\n"
+#~ msgstr "Fichier verrou sur %s\n"
+
+#~ msgid "fetchmail: cannot allocate memory for lock name.\n"
+#~ msgstr "fetchmail: impossible d'allouer la mémoire pour le nom du verrou.\n"
+
+#~ msgid "Requesting authorization as %s\n"
+#~ msgstr "Requête d'une autorisation en tant que %s\n"
+
+#~ msgid "Required GSS capability not supported by server\n"
+#~ msgstr "La fonction GSS requise n'est pas supportée par le serveur\n"
+
+#~ msgid "KERBEROS_V4 authentication is supported\n"
+#~ msgstr "Authentification KERBEROS_V4 supportée\n"
+
+#~ msgid "Required KERBEROS_V4 capability not supported by server\n"
+#~ msgstr ""
+#~ "La fonction KERBEROS_V4 requise n'est pas supportée par le serveur\n"
+
+#~ msgid "Required CRAM-MD5 capability not supported by server\n"
+#~ msgstr "La capacité CRAM-MD5 requise n'est pas supportée par le serveur\n"
diff --git a/po/fr.po.rej b/po/fr.po.rej
new file mode 100644
index 00000000..e1732175
--- /dev/null
+++ b/po/fr.po.rej
@@ -0,0 +1,116 @@
+***************
+*** 9,15 ****
+  # mise à jour par Sébastien KALT <ustilago@bigfoot.com>
+  # mise à jour par Thierry Vignaud <tvignaud@mandrakesoft.com>, 2001-2003
+  # mise à jour par Philippe Verdy <verdy_p@wanadoo.fr> 2003.
+- # Commentaires bienvenus
+  #
+  msgid ""
+  msgstr ""
+--- 9,15 ----
+  # mise à jour par Sébastien KALT <ustilago@bigfoot.com>
+  # mise à jour par Thierry Vignaud <tvignaud@mandrakesoft.com>, 2001-2003
+  # mise à jour par Philippe Verdy <verdy_p@wanadoo.fr> 2003.
++ # Commentaires bienvenus.
+  #
+  msgid ""
+  msgstr ""
+***************
+*** 255,270 ****
+  
+  #: driver.c:1072
+  msgid "unrecoverable name server error."
+- msgstr "erreur irrécupérable avec le serveur de noms."
+  
+  #: driver.c:1074
+  msgid "temporary name server error."
+- msgstr "erreur temporaire avec le serveur de noms."
+  
+  #: driver.c:1081
+  #, c-format
+  msgid "unknown DNS error %d."
+- msgstr "erreur DNS inconnue %d."
+  
+  #: driver.c:1099
+  #, c-format
+--- 255,270 ----
+  
+  #: driver.c:1072
+  msgid "unrecoverable name server error."
++ msgstr "erreur irrécupérable du serveur de noms."
+  
+  #: driver.c:1074
+  msgid "temporary name server error."
++ msgstr "erreur temporaire du serveur de noms."
+  
+  #: driver.c:1081
+  #, c-format
+  msgid "unknown DNS error %d."
++ msgstr "erreur DNS %d inconnue."
+  
+  #: driver.c:1099
+  #, c-format
+***************
+*** 286,297 ****
+  #: driver.c:1181
+  #, c-format
+  msgid "Lock-busy error on %s@%s\n"
+- msgstr "Erreur «lock-busy» sur %s@%s\n"
+  
+  #: driver.c:1185
+  #, c-format
+  msgid "Server busy error on %s@%s\n"
+- msgstr "Erreur «busy» sur %s@%s\n"
+  
+  #: driver.c:1190
+  #, c-format
+--- 286,297 ----
+  #: driver.c:1181
+  #, c-format
+  msgid "Lock-busy error on %s@%s\n"
++ msgstr "Erreur verrou-occupé sur %s@%s\n"
+  
+  #: driver.c:1185
+  #, c-format
+  msgid "Server busy error on %s@%s\n"
++ msgstr "Erreur (serveur occupé) sur %s@%s\n"
+  
+  #: driver.c:1190
+  #, c-format
+***************
+*** 509,525 ****
+  #: driver.c:1597
+  #, c-format
+  msgid "Option --flush is not supported with %s\n"
+- msgstr "Option --flush non supportée avec %s\n"
+  
+  #: driver.c:1603
+  #, c-format
+  msgid "Option --all is not supported with %s\n"
+- msgstr "Option --all non supportée avec %s\n"
+  
+  #: driver.c:1611
+  #, c-format
+  msgid "Option --limit is not supported with %s\n"
+- msgstr "Option --limit non supportée avec %s\n"
+  
+  #: env.c:60
+  #, c-format
+--- 509,525 ----
+  #: driver.c:1597
+  #, c-format
+  msgid "Option --flush is not supported with %s\n"
++ msgstr "L'option --flush n'est pas supportée avec %s\n"
+  
+  #: driver.c:1603
+  #, c-format
+  msgid "Option --all is not supported with %s\n"
++ msgstr "L'option --all n'est pas supportée avec %s\n"
+  
+  #: driver.c:1611
+  #, c-format
+  msgid "Option --limit is not supported with %s\n"
++ msgstr "L'option --limit n'est pas supportée avec %s\n"
+  
+  #: env.c:60
+  #, c-format
diff --git a/po/gl.gmo b/po/gl.gmo
new file mode 100644
index 00000000..635c79e9
--- /dev/null
+++ b/po/gl.gmo
diff --git a/po/gl.po b/po/gl.po
new file mode 100644
index 00000000..5693d62c
--- /dev/null
+++ b/po/gl.po
@@ -0,0 +1,2912 @@
+# Galician translation of fetchmail.
+# Copyright (C) 2000 Jesús Bravo Álvarez.
+# Jesús Bravo Álvarez <jba@pobox.com>, 2000.
+#
+# Se desexas colaborar connosco na traducción de programas libres ó galego,
+# vai mira-la páxina do noso grupo:  http://www.ctv.es/USERS/jtarrio/trans
+#
+# First Version: 2000-03-27 20:18+0200
+# Based on pt_BR.po by Jorge Godoy <godoy@conectiva.com.br>
+# Based on es.po by Javier Kohen <jkohen@tough.com>
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 5.3.6\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2000-04-10 01:26+0200\n"
+"Last-Translator: Jesús Bravo Álvarez <jba@pobox.com>\n"
+"Language-Team: Galician <gpul-traduccion@ceu.fi.udc.es>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=iso-8859-1\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Comprobando se %s é realmente o mesmo nodo que %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Si, os seus enderezos IP coinciden\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Non, os seus enderezos IP non coinciden\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr "fallo na resolución do nome ó buscar `%s' mentres se recibía de %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "non se puido decodificar o challenge BASE64\n"
+
+#: cram.c:103
+#, fuzzy, c-format
+msgid "decoded as %s\n"
+msgstr "espertado en %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "erro %s de kerberos\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [o servidor di '%*s'] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\tmensaxe %d de %d octetos omitido polo fetchmail.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "omitindo mensaxe %d (%d octetos)"
+
+#: driver.c:549
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "omitindo mensaxe %d (%d octetos)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr ""
+
+#: driver.c:568
+#, fuzzy
+msgid " (oversized)"
+msgstr " (exceso de tamaño, %d octetos)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr ""
+
+#: driver.c:600
+#, fuzzy, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "lendo mensaxe %d de %d"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d octetos%s)"
+
+#: driver.c:606
+msgid "header "
+msgstr " de cabeceira"
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d octetos de corpo) "
+
+#: driver.c:736
+#, fuzzy, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr "a mensaxe %d non tiña o tamaño agardado (%d real != %d agardado)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " mantida\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " eliminada\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " non eliminada\n"
+
+#: driver.c:809
+#, fuzzy, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr "atinxiuse o límite de %d mensaxes; %d deixadas no servidor\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "SIGPIPE enviado por un MDA ou erro da conexión stream\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr "tempo esgotado tras %d segundos agardando a conexión ó servidor %s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "tempo esgotado tras %d segundos agardando ó servidor %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "tempo esgotado tras %d segundos agardando a %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr ""
+"tempo esgotado tras %d segundos agardando a resposta do servidor receptor.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "tempo esgotado tras %d segundos.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Subject: fetchmail atopa repetidas expiracións do tempo de espera\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail atopou máis de %d expiracións do tempo de espera tentando colle-lo "
+"correo de %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Isto pode significar que o seu servidor de correo está trabado, ou\n"
+"que o seu servidor SMTP local está colgado, ou que a súa caixa de\n"
+"correo no servidor está corrupta por un erro do servidor.  Pode executar\n"
+"`fetchmail -v -v' para diagnostica-lo problema.\n"
+"\n"
+"Fetchmail non recibirá de novo correo desta caixa ata que o reinicie.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "o programa de pre-conexión fallou con estado %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "non se puido atopar a caixa postal HESIOD para %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "O servidor principal non ten nome.\n"
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "non se puido atopar o nome DNS canónico de %s\n"
+
+#: driver.c:1053
+#, fuzzy
+msgid "internal inconsistency\n"
+msgstr "fetchmail: inconsistencia interna\n"
+
+#: driver.c:1063
+#, fuzzy, c-format
+msgid "%s connection to %s failed"
+msgstr "fallou a conexión %cMTP a %s\n"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "a máquina é descoñecida."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "o nome é válido mais non ten enderezo IP."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "erro irrecuperable do servidor de nomes."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "erro temporal do servidor de nomes."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "erro %d de DNS descoñecido."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+#, fuzzy
+msgid "SSL connection failed.\n"
+msgstr "fallou a conexión %cMTP a %s\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Erro de bloqueo/actividade en %s@%s\n"
+
+#: driver.c:1188
+#, fuzzy, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Erro de bloqueo/actividade en %s@%s\n"
+
+#: driver.c:1193
+#, fuzzy, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Fallou a autorización en %s@%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr ""
+
+#: driver.c:1217
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: fallou a autenticación do fetchmail\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail non puido coller correo de %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+
+#: driver.c:1239
+#, fuzzy
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Fallou a tentativa de obter autorización.\n"
+"Probablemente isto quere dicir que a súa contrasinal non é válida,\n"
+"pero os servidores POP3 poden fallar por outras causas, e o fetchmail\n"
+"non pode distinguilas porque non envían mensaxes de erro útiles cando\n"
+"hai un fallo de login.\n"
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr ""
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Erro descoñecido de login ou autenticación en %s@%s\n"
+
+#: driver.c:1283
+#, fuzzy, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Fallou a autorización en %s@%s\n"
+
+#: driver.c:1289
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: fallou a autenticación do fetchmail\n"
+
+#: driver.c:1292
+#, fuzzy, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail non puido coller correo de %s@%s.\n"
+
+#: driver.c:1296
+#, fuzzy
+msgid "Service has been restored.\n"
+msgstr "O servicio escolleu a versión %d.%d do RPA\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "escollendo ou recibindo de novo mensaxes da carpeta %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "escollendo ou recibindo de novo mensaxes da carpeta por defecto\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s en %s (carpeta %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s en %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Recibindo de %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d lidas) para %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "mensaxes"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "mensaxe"
+
+#: driver.c:1366
+msgid "seen"
+msgstr ""
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s para %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d octetos).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "Non hai correo para %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr ""
+
+#: driver.c:1515
+msgid "socket"
+msgstr "socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "a cabeceira RFC822 falta ou é errónea"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "sincronización cliente/servidor"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "protocolo cliente/servidor"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "bloqueo activado no servidor"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "Transacción SMTP"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "Busca no DNS"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "erro indefinido\n"
+
+#: driver.c:1550
+#, fuzzy, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "erro %s ó baixar correo de %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "erro %s ó baixar correo de %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "o comando de pos-conexión fallou con estado %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Non está enlazado con soporte Kerberos V4.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Non está enlazado con soporte Kerberos V5.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "A opción --flush non está soportada con %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "A opción --all non está soportada con %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "A opción --limit non está soportada con %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Vostede non existe.  Marche.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: non se pode determina-la súa máquina"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "o gethostbyname fallou para %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "O servidor SMTP receptor de %s non soporta ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "O servidor SMTP receptor de %s non soporta ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Cola para %s iniciada\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Non hai mensaxes agardando para %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Mensaxes pendentes para %s iniciadas\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Imposible poñer mensaxes na cola para o nodo %s\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Nodo %s non permitido: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "Erro de sintaxe de ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "Erro de sintaxe de ETRN nos parámetros\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Erro de ETRN %d descoñecido\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "A opción --keep non está soportada con ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "A opción --flush non está soportada con ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "A opción --remote non está soportada con ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "A opción --check non está soportada con ETRN\n"
+
+#: fetchmail.c:156
+#, fuzzy
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: fallou o fork\n"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr ""
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Isto é fetchmail versión %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Collendo as opcións da liña de comandos%s%s\n"
+
+# Estas dúas cadeas quedan "... da liña de comandos e de .fetchmailrc"
+#: fetchmail.c:332
+msgid " and "
+msgstr " e de "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr ""
+"Non hai ningún servidor de correo configurado -- ¿quizais falta o %s?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: non se indicou ningún servidor de correo.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: non hai outro fetchmail a se executar\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: erro matando fetchmail en %s co pid %d; saíndo.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "segundo plano"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "primeiro plano"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: fetchmail en %s co pid %d matado.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: non se pode comproba-lo correo cando hai outro fetchmail na\n"
+"mesma máquina a se executar.\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: non se pode recibir das máquinas indicadas con outro fetchmail a "
+"se executar en %d.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr ""
+"fetchmail: outro fetchmail en primeiro plano está a se executar en %d.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: non se poden aceptar opcións cando hai un fetchmail en segundo "
+"plano a se executar.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: fetchmail en segundo plano co pid %d espertado.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: proceso máis antigo en %d morreu misteriosamente.\n"
+
+#: fetchmail.c:460
+#, fuzzy, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: non se pode atopar unha contrasinal para %s@%s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Introduza a contrasinal para %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "iniciando o demonio de fetchmail %s \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr ""
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "non se puido comproba-la data de %s (erro %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "iniciando fetchmail (%s cambiou)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "fallou a tentativa de reexecutar o fetchmail\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"recepción de %s omitida (fallo de autenticación ou demasiados excesos de "
+"espera)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "non se atinxiu o intervalo, non se interrogará %s\n"
+
+#: fetchmail.c:667
+#, fuzzy
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:669
+#, fuzzy
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:671
+#, fuzzy
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:673
+#, fuzzy
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:675
+#, fuzzy
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:677
+#, fuzzy
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:679
+#, fuzzy
+msgid "Query status=6 (IOERR)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:681
+#, fuzzy
+msgid "Query status=7 (ERROR)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:683
+#, fuzzy
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:685
+#, fuzzy
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:687
+#, fuzzy
+msgid "Query status=10 (SMTP)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:689
+#, fuzzy
+msgid "Query status=11 (DNS)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:691
+#, fuzzy
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:693
+#, fuzzy
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Estado da petición=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Tódalas las conexións están trabadas.  Saíndo.\n"
+
+#: fetchmail.c:748
+#, fuzzy, c-format
+msgid "sleeping at %s\n"
+msgstr "fetchmail: durmindo en %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "espertado por %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "espertado por sinal %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "espertado en %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "finalización normal, estado %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "non se puido comprobar a data do ficheiro de control de execución\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr "Aviso: múltiples mencións da máquina %s no ficheiro de configuración\n"
+
+#: fetchmail.c:1116
+#, fuzzy
+msgid "SSL support is not compiled in.\n"
+msgstr "non está configurado o soporte POP2.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: aviso: ningún DNS dispoñible para comprobar recepcións con "
+"múltiples entregas de %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr ""
+"configuración de %s non válida, o número de porto non pode ser negativo\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "configuración de %s non válida, RPOP require un porto privilexiado\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"configuración de %s non válida, LMTP non pode usar o porto por defecto SMTP\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "¡Baixar e manter tódalas mensaxes en modo demonio é un erro!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "terminado con sinal %d\n"
+
+#: fetchmail.c:1339
+#, fuzzy, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s interrogando %s (protocolo %s) en %s\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "non está configurado o soporte POP2.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "non está configurado o soporte POP3.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "non está configurado o soporte IMAP.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "non está configurado o soporte ETRN.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "Non se pode soportar ETRN sen gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+#, fuzzy
+msgid "ODMR support is not configured.\n"
+msgstr "non está configurado o soporte POP2.\n"
+
+#: fetchmail.c:1411
+#, fuzzy
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "Non se pode soportar ETRN sen gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "o protocolo escollido non está soportado.\n"
+
+#: fetchmail.c:1427
+#, fuzzy, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s interrogando %s (protocolo %s) en %s\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "O intervalo entre peticións é de %d segundos\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "O ficheiro de rexistro é %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "O ficheiro de identificacións é %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "As mensaxes de progreso rexistraranse polo syslog\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail enmascararase e non xerará unha liña Received\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr ""
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr "Fetchmail reenviará mensaxes multidrop con enderezo incorrecto a %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Fetchmail enviará as mensaxes de erro ó postmaster.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail enviará as mensaxes de erro ó autor.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Opcións para recibir de %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  O correo recibirase vía %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  Recibirase deste servidor cada %d intervalos.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  O nome real do servidor é %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr ""
+"  Esta máquina%sserá interrogada cando non se indique ningunha outra.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr " non "
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr " "
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Pedirase a contrasinal.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  Segredo APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  Identificación RPOP = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Contrasinal = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  O protocolo é KPOP con autenticación Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  O protocolo é %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (usando o servicio %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (usando opcións de seguridade de rede %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (usando o porto %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (usando o porto por defecto)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (forzando o uso de UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr ""
+
+#: fetchmail.c:1536
+#, fuzzy
+msgid "  Password authentication will be forced.\n"
+msgstr "Autenticación OTP soportada\n"
+
+#: fetchmail.c:1539
+#, fuzzy
+msgid "  NTLM authentication will be forced.\n"
+msgstr "Autenticación NTLM soportada\n"
+
+#: fetchmail.c:1542
+#, fuzzy
+msgid "  OTP authentication will be forced.\n"
+msgstr "Autenticación OTP soportada\n"
+
+#: fetchmail.c:1545
+#, fuzzy
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "Autenticación CRAM-MD5 soportada\n"
+
+#: fetchmail.c:1548
+#, fuzzy
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "Autenticación OTP soportada\n"
+
+#: fetchmail.c:1551
+#, fuzzy
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Activada a preautenticación Kerberos V4.\n"
+
+#: fetchmail.c:1554
+#, fuzzy
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Activada a preautenticación Kerberos V5.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  Asúmese encriptado dun punto ó outro.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr ""
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1566
+#, fuzzy, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  O protocolo é %s"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr ""
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr ""
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  O tempo de espera de resposta do servidor é %d segundos"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (por defecto).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Caixa de correo por defecto escollida.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  As caixas de correo escollidas son:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  Baixaranse %s mensaxes (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "tódalas"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "só as novas"
+
+# %s substitúese por " non " ou " "
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  As mensaxes recibidas%sserán mantidas no servidor (--keep %s).\n"
+
+# %s substitúese por " non " ou " "
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+"  As mensaxes vellas%sserán eliminadas antes da recepción de mensaxes (--"
+"flush %s).\n"
+
+# A traducción está feita cos : porque é o único xeito de que as
+# palabras "activado" e "desactivado" sirvan para as sentencias
+# masculinas e femininas, sen que quede moi mal
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  Rescritura dos enderezos locais: %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "activado"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "desactivado"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  Eliminación do retorno de carro: %s (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Retorno de carro forzado: %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr "  Interpretación de Content-Transfer-Encoding: %s (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  Decodificación MIME: %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  Inactividade despois da recepción: %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  As liñas Status non baleiras serán %s (dropstatus %s)\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "descartadas"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "mantidas"
+
+#: fetchmail.c:1625
+#, fuzzy, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  As liñas Status non baleiras serán %s (dropstatus %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  O límite de tamaño de mensaxe é %d octetos (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  Sen límite de tamaño de mensaxe (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  O intervalo de avisos do tamaño das mensaxes é %d segundos (--warnings %"
+"d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr "  Avisos de tamaño de mensaxe en cada recepción (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  O límite de mensaxes recibidas é %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  Sen límite de mensaxes recibidas (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  O límite de mensaxes recibidas é %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Sen límite de tamaño de mensaxe (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  O límite de lote de mensaxes SMTP é %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  Sen límite de lote de mensaxes SMTP (--bathlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+"  O intervalo de borrado entre eliminacións forzado a %d (--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Sen eliminacións forzadas (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr ""
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (por defecto)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  As mensaxes serán engadidas a %s como BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  As mensaxes serán entregadas con \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  As mensaxes serán redirixiadas a través de %cMTP a:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  O nome da máquina na liña MAIL FROM será %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr ""
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  As respostas de bloques spam recoñecidas polo servidor receptor son:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Bloqueo de spam desactivado\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  A conexión ó servidor será iniciada con \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Ningún comando de pre-conexión.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  A conexión ó servidor será rematada con \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Ningún comando de pos-conexión.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Non hai ningún nome local declarado para esta máquina.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Modo de entrega múltiple: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Modo de entrega simple: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d nome(s) local(is) recoñecidos.\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  Busca no DNS por enderezos de múltiple entrega: %s.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr ""
+"  Os aliases do servidor compararanse cos enderezos de múltiple entrega "
+"segundo "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "o enderezo IP.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "o nome.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  O encamiñamento dos enderezos do sobre está desactivado\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Asúmese que a cabeceira do sobre é: %s\n"
+
+# Non traducir, refírese á cabeceira Received das mensaxes
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Received"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Número da cabeceira do sobre a procesar: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Eliminarase o prefixo %s do identificador de usuario\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  Sen eliminación de prefixo\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Aliases predeclarados do servidor de correo:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Dominios locais:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  A conexión ten que ser a través da interfaz %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Non se indicou ningún requirimento de interfaz.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  O bucle de recibimento monitorizará %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Non se indicou ningunha interfaz de monitorización.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr "  As conexións ó servidor faranse polo plugin %s (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Non se indicou ningún comando de plugin.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  Ás conexións ó servidor receptor faranse polo plugout %s (--plugout %s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Non se indicou ningún comando de plugout.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Ningún UID foi grabado desta máquina.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d UIDs gravados.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Propiedades de paso \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+#, fuzzy
+msgid "alloca failed"
+msgstr "fallou o malloc\n"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "ERRO: non hai soporte para a rotina getpassword()\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"SIGINT recibido... saíndo.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Non se puido obte-lo nome do servicio para [%s]\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "Usando o nome de servicio [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Enviando credenciais\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Erro no troco de credenciais\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Non foi posible desempaquetar os datos do nivel de seguridade\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Troco de credenciais completo\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "O servidor require integridade e/ou privacidade\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Desempaquetadas as marcas do nivel de seguridade: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "O tamaño máximo do símbolo GSS é %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Erro ó crear a petición de nivel de seguridade\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Liberando as credenciais GSS\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Erro liberando as credenciais\n"
+
+#: idle.c:62
+#, fuzzy, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: durmindo en %s\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protocolo identificado como IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protocolo identificado como IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protocolo identificabo como IMAP2 ou IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr ""
+
+#: imap.c:460
+#, fuzzy
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "Capacidade LOGIN requirida non soportada polo servidor\n"
+
+#: imap.c:482
+#, fuzzy
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Capacidade LOGIN requirida non soportada polo servidor\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Capacidade LOGIN requirida non soportada polo servidor\n"
+
+#: imap.c:641 imap.c:707
+#, fuzzy
+msgid "expunge failed\n"
+msgstr "fallou o execl(%s)\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "fallou a nova tentativa de baixar mensaxes\n"
+
+#: imap.c:671
+#, fuzzy, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "Non hai mensaxes agardando para %s\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "fallou a selección de caixa de correo\n"
+
+#: imap.c:685
+#, fuzzy, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "Non hai mensaxes agardando para %s\n"
+
+#: imap.c:711
+#, fuzzy, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "Non hai mensaxes agardando para %s\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "fallou a busca de mensaxes non lidas\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "a %u aínda foi lida\n"
+
+#: imap.c:776 pop3.c:679
+#, fuzzy, c-format
+msgid "%u is first unseen\n"
+msgstr "a %u aínda foi lida\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"Non se puido abri-la interfaz kvm. Asegúrese que o fetchmail é SGID de kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr ""
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr ""
+
+#: interface.c:426
+#, fuzzy
+msgid "get_ifinfo: malloc failed"
+msgstr "fallou o malloc\n"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr ""
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr ""
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr ""
+
+#: interface.c:540
+#, fuzzy, c-format
+msgid "No IP address found for %s"
+msgstr "non se atopou ningún enderezo `Received'\n"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "falta o enderezo IP da interfaz\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "enderezo IP da interfaz non válido\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "máscara IP da interfaz non válida\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "actividade en %s -percibida- como %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "omitindo a recepción de %s, %s está desactivada\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "omitindo a recepción de %s, enderezo IP de %s excluído\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "actividade en %s comprobada como %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "omitindo a recepción de %s, %s está inactiva\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "actividade en %s era %d, é %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "non se puido decodificar o challenge BASE64 inicial\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "%s principal no ticket non coincide con -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "instancia non nula (%s) pode causar comportamento estraño\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "non se puido decodificar a resposta BASE64 de dispoñibilidade\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "o challenge non encaixa\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: borrando ficheiro de bloqueo antigo\n"
+
+#: lock.c:122
+#, fuzzy
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: fallou o socketpair\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "aviso: atopouse \"%s\" antes de calquera nome de máquina"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: aviso: atopouse \"%s\" antes de calquera nome de máquina\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: aviso: símbolo descoñecido \"%s\"\n"
+
+#: odmr.c:65
+#, fuzzy, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "O servidor SMTP receptor de %s non soporta ETRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr ""
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr ""
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr ""
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr ""
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr ""
+
+#. Authentication required
+#: odmr.c:125
+#, fuzzy
+msgid "Authentication required.\n"
+msgstr "Autenticación OTP soportada\n"
+
+#: odmr.c:129
+#, fuzzy, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Erro de ETRN %d descoñecido\n"
+
+#: odmr.c:244
+#, fuzzy
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "A opción --keep non está soportada con ETRN\n"
+
+#: odmr.c:248
+#, fuzzy
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "A opción --flush non está soportada con ETRN\n"
+
+#: odmr.c:252
+#, fuzzy
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "A opción --remote non está soportada con ETRN\n"
+
+#: odmr.c:256
+#, fuzzy
+msgid "Option --check is not supported with ODMR\n"
+msgstr "A opción --check non está soportada con ETRN\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr ""
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Non se puido decodificar o challenge OTP\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Contrasinal segreda: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "A cadea '%s' non é unha cadea numérica válida.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "O valor da cadea '%s' é %s que %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "máis pequeno"
+
+#: options.c:211
+msgid "larger"
+msgstr "maior"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Protocolo indicado `%s' non válido.\n"
+
+#: options.c:429
+#, fuzzy, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Preautenticación `%s' indicada non válida.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: o soporte de seguridade de rede está desactivado\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "uso:  fetchmail [opcións] [servidor ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  As opcións son as seguintes:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        amosar esta axuda das opcións\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     amosa-la información da versión\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       comprobar as mensaxes sen recollelas\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      traballar silenciosamente\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     traballar barullentamente (saída de diagnóstico)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr ""
+"  -d, --daemon      executarse como un demonio unha vez cada n segundos\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    non quitar do primeiro plano o proceso demonio\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        mata-lo proceso demonio\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     indica-lo nome do ficheiro de rexistro\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      usar syslog(3) para a maior parte das mensaxes ó "
+"se                     executar como demonio\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   non escribir `Received' e activar finximento de máquina\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr ""
+"  -f, --fetchmailrc indicar un ficheiro de control de execución diferente\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      indicar un ficheiro de UIDs alternativo\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  indicar o destinatario en último caso\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr ""
+"      --nobounce    redirixir as mensaxes erradas do usuario ó postmaster.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   indicación de requirimento de interfaz\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     monitorizar a actividade da interfaz\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         activar sesión encriptada con ssl\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      ficheiro coa chave privada ssl\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     certificado de cliente ssl\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr ""
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr "      --plugin      indicar comando externo para abri-la conexión\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     indicar comando externo para abri-la conexión smtp "
+"local\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    indicar o protocolo de recepción (mirar a páxina man)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        forzar o uso de UIDLs (só pop3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        porto do servicio TCP/IP ó que se conectar\n"
+
+#: options.c:694
+#, fuzzy
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr ""
+"      --preauth     tipo de preautenticación: password (contrasinal),\n"
+"                    kerberos, ou ssh\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     tempo de espera da resposta do servidor\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    cabeceira co enderezo do sobre\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+"  -Q, --qvirtual    prefixo a borrar da identificación de usuario local\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr ""
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    indicar o login do usuario no servidor\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         coller as mensaxes vellas e novas\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      borra-las novas mensaxes despois de recollelas\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        mante-las novas mensaxes despois de recollelas\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       elimina-las mensaxes vellas do servidor\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   non rescribi-los enderezos das cabeceiras\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -l, --limit       non coller mensaxes meirandes que o tamaño dado\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr ""
+"  -w, --warnings    intervalo entre notificacións de avisos de correo\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      establecer petición de seguridade IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    establece-lo servidor SMTP para redirixir\n"
+
+#: options.c:714
+#, fuzzy
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr ""
+"  -B, --fetchlimit  establece-lo límite de mensaxes para as conexións\n"
+"                    ó servidor\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr "  -D, --smtpaddress establece-lo dominio de entrega SMTP a usar\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr ""
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam,   establece-los valores de resposta antispam\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr "  -b, --batchlimit  establece-lo límite de lote para conexións SMTP\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  establece-lo límite de mensaxes para as conexións\n"
+"                    ó servidor\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr ""
+"  -B, --fetchlimit  establece-lo límite de mensaxes para as conexións\n"
+"                    ó servidor\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+"  -e, --expunge     establece-lo número máximo de borrados entre "
+"eliminacións\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         establece-lo MDA a usar para redirixir\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       establece-lo ficheiro BSMTP de saída\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        usar LMTP (RFC2033) para a entrega\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      indicar o nome da carpeta remota\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "Mostra da data de APOP requirida non atopada no saúdo\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Erro de sintaxe na mostra da data no saúdo\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Petición de protocolo indefinida en POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "¡bloqueo activado!  ¿Hai outra sesión activa?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr ""
+"Mensaxes inseridas nunha lista no servidor. Non se pode manexar isto.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "erro de protocolo\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "erro de protocolo ó obter os UIDLs\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "A opción --remote non está soportada con POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr ""
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr ""
+
+#: rcfile_y.y:218
+#, fuzzy
+msgid "invalid security request"
+msgstr "Erro ó crear a petición de nivel de seguridade\n"
+
+#: rcfile_y.y:224
+#, fuzzy
+msgid "network-security support disabled"
+msgstr "fetchmail: o soporte de seguridade de rede está desactivado\n"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr ""
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr ""
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr ""
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr ""
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr ""
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Erro de sistema descoñecido"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (mensaxe de rexistro incompleta)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "erro parcial de sobrecarga no buffer de mensaxe"
+
+#: rfc822.c:74
+#, fuzzy, c-format
+msgid "About to rewrite %s"
+msgstr "a piques de entregar con: %s\n"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr ""
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Éxito"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Usuario restrinxido (algo está mal coa conta)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "Identificador de usuario ou contrasinal non válidos"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "Erro fatal"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "RPA símbolo 2: Erro de decodificación Base64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "O servicio escolleu a versión %d.%d do RPA\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Challenge do servicio (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Mostra da data do servicio %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "Erro na lonxitude do símbolo 2 RPA\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Lista de dominios: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "Erro RPA na cadea servicio@dominio\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA símbolo 4: Erro de decodificación Base64\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Autenticación de usuario (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "Estado RPA: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "Erro na lonxitude do símbolo 4 RPA\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA rexeitoulle: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA rexeitoulle, razón descoñecida\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "Erro de lonxitude da autenticación de usuario RPA: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "Erro de lonxitude da chave da sesión RPA: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "Fallo na autorización do _servicio_ RPA. ¿Servidor falsificado?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Chave de sesión establecida:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "Autorización RPA completa\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Obtención de resposta\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "A obtención de resposta devolveu %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "A cabeceira non é 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "Erro de lonxitude do símbolo\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "A lonxitude %d do compoñente non está de acordo coa rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Campo de mecanismo incorrecto\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "erro dec64 no carácter %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Datos binarios entrantes:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Datos saíntes:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "Cadea RPA longa de máis\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA fallou na apertura de /dev/urandom. Isto non debería\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    impedilo de se conectar, pero significa que\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    non pode estar seguro de estar a falar co\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    servicio que vostede cre (son posibles\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    ataques de re-tentativa por un servicio deshonesto.)\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Challenge de usuario:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "MD5 sendo aplicado ó bloque de datos:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "O resultado MD5 é: \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "redirixindo a %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr ""
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr ""
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr ""
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "erro de %cMTP: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "Fallou a apertura do ficheiro BSMTP ou a escritura do preámbulo\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "O receptor %cMTP non acepta o enderezo de destinatario `%s'\n"
+
+#: sink.c:989
+#, fuzzy, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "O receptor %cMTP non acepta o enderezo de destinatario `%s'\n"
+
+#: sink.c:1027
+#, fuzzy
+msgid "no address matches; no postmaster set.\n"
+msgstr "ningunha coincidencia do enderezo; redirixindo a %s.\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "¡non se pode nin sequera enviar a %s!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "ningunha coincidencia do enderezo; redirixindo a %s.\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "a piques de entregar con: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "Fallou a apertura MDA\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "fallou a conexión %cMTP a %s\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr ""
+
+#: sink.c:1339
+#, fuzzy, c-format
+msgid "MDA died of signal %d\n"
+msgstr "espertado por sinal %d\n"
+
+#: sink.c:1342
+#, fuzzy, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "O MDA saiu anormalmente ou devolveu estado non cero\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr ""
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Fallou o remate da mensaxe ou o pechamento do ficheiro BSMTP\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "O receptor SMTP rexeitou a entrega\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "Erro na entrega LMTP no EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Resposta distinta de 503 non agardada ó LMTP EOM: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+
+#: smtp.c:86
+#, fuzzy
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "Autenticación CRAM-MD5 soportada\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr ""
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr ""
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr ""
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:361 smtp.c:384
+#, fuzzy
+msgid "smtp listener protocol error\n"
+msgstr "erro de protocolo\n"
+
+#: socket.c:108 socket.c:134
+#, fuzzy
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: fallou o fork\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: fallou o socketpair\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: fallou o fork\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "fallou o dup2\n"
+
+#: socket.c:186
+#, fuzzy, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "executando %s %s %s\n"
+
+#: socket.c:189
+#, fuzzy, c-format
+msgid "execvp(%s) failed\n"
+msgstr "fallou o execl(%s)\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: lonxitude de enderezo ilegal recibido para a máquina %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr ""
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr ""
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr ""
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr ""
+
+#: socket.c:792
+#, fuzzy, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Mostra da data do servicio %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr ""
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr ""
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr ""
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr ""
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr ""
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr ""
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr ""
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr ""
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr ""
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr ""
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr ""
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr ""
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr ""
+
+#: socket.c:948
+#, fuzzy, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr "Protocolo indicado `%s' non válido.\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr ""
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr ""
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr ""
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s asociado a %s local\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "pasou por %s coincidindo con %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analizando a liña Received:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "liña aceptada, %s é un alias do servidor de correo\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "liña rexeitada, %s non é un alias do servidor de correo\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "non se atopou ningún enderezo `Received'\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "atopouse o enderezo `Received' `%s'\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "delimitador de mensaxes atopado ó explora-las cabeceiras\n"
+
+#: transact.c:552
+#, fuzzy
+msgid "incorrect header line found while scanning headers\n"
+msgstr "delimitador de mensaxes atopado ó explora-las cabeceiras\n"
+
+#: transact.c:554
+#, fuzzy, c-format
+msgid "line: %s"
+msgstr "Recibindo de %s\n"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "non hai ningunha coincidencia local, reenviando a %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "reenvío e borrado omitidos por causa de erros de DNS\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "escribindo cabeceiras de mensaxe RFC822\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "ningún dos enderezos coincidiu cos nomes locais declarados"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "o enderezo de destinatario %s non coincidiu con ningún nome local"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "a mensaxe contén caracteres nulos"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr ""
+"O servidor SMTP receptor rexeitou os enderezos de destinatario locais: "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "escribindo o texto da mensaxe\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr ""
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr ""
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr ""
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr ""
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, c-format
+msgid "Merged UID list from %s:"
+msgstr ""
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr ""
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr ""
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr ""
+
+#: uid.c:575
+msgid "discarding new UID list\n"
+msgstr ""
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr ""
+
+#: uid.c:616
+#, fuzzy
+msgid "Writing fetchids file.\n"
+msgstr "iniciando o demonio de fetchmail %s \n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "fallou o malloc\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "fallou o realloc\n"
+
+#~ msgid "fetchmail: %s connection to %s failed"
+#~ msgstr "fetchmail: a conexión %s a %s fallou"
+
+#~ msgid "Skipping message %d, length -1\n"
+#~ msgstr "Omitindo mensaxe %d, lonxitude -1\n"
+
+#~ msgid "authorization"
+#~ msgstr "autorización"
+
+#~ msgid "%s: can't find your name and home directory!\n"
+#~ msgstr "%s: non se pode atopa-lo seu nome e o seu directorio home\n"
+
+#~ msgid "Lockfile at %s\n"
+#~ msgstr "Ficheiro de bloqueo en %s\n"
+
+#~ msgid "fetchmail: cannot allocate memory for lock name.\n"
+#~ msgstr ""
+#~ "fetchmail: non se pode asignar memoria para o nome do ficheiro de "
+#~ "bloqueo.\n"
+
+#~ msgid "Could not decode initial BASE64 challenge\n"
+#~ msgstr "Non se puido decodificar o challenge BASE64 inicial\n"
+
+#~ msgid "Requesting authorization as %s\n"
+#~ msgstr "Solicitando autorización como %s\n"
+
+#~ msgid "Required GSS capability not supported by server\n"
+#~ msgstr "Capacidade GSS requirida non está soporta polo servidor\n"
+
+#~ msgid "KERBEROS_V4 authentication is supported\n"
+#~ msgstr "Autenticación KERBEROS_V4 soportada\n"
+
+#~ msgid "Required KERBEROS_V4 capability not supported by server\n"
+#~ msgstr "Capacidade KERBEROS_V4 requirida non soportada polo servidor\n"
+
+#~ msgid "Required CRAM-MD5 capability not supported by server\n"
+#~ msgstr "Capacidade CRAM-MD5 requirida non soportada polo servidor\n"
diff --git a/po/ja.gmo b/po/ja.gmo
new file mode 100644
index 00000000..a31da6ba
--- /dev/null
+++ b/po/ja.gmo
diff --git a/po/ja.po b/po/ja.po
new file mode 100644
index 00000000..20dc99b2
--- /dev/null
+++ b/po/ja.po
@@ -0,0 +1,2883 @@
+# Japanese messages for fetchmail.
+# Copyright (C) 2002 Free Software Foundation, Inc.
+# Jumpei Baba <jbaba@wb3.so-net.ne.jp>, 2002 
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 5.9.11\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2002-04-07 12:00+0900\n"
+"Last-Translator: Jumpei Baba <jbaba@wb3.so-net.ne.jp>\n"
+"Language-Team: Japanese <translation-team-ja@lists.sourceforge.net>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=EUC-JP\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "%s ¤È %s ¤¬ËÜÅö¤ËƱ¤¸¥Î¡¼¥É¤Ç¤¢¤ë¤«³Îǧ¤·¤Æ²¼¤µ¤¤¡£\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "¤Ï¤¤¡¢¤³¤ì¤é¤ÎIP¥¢¥É¥ì¥¹¤¬°ìÃפ·¤Þ¤·¤¿¡£\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "¤¤¤¤¤¨¡¢¤³¤ì¤é¤ÎIP¥¢¥É¥ì¥¹¤Ï°ìÃפ·¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr "¥Í¡¼¥à¥µ¡¼¥Ð¤¬`%s'¤ò¸¡º÷½ÐÍè¤Þ¤»¤ó¤Ç¤·¤¿¡£(%s ¤ËÀܳ¤¹¤ëºÝ¤Ë)\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "BASE64 ÊÑ´¹¤µ¤ì¤¿ challenge ¤ò¥Ç¥³¡¼¥É¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "%s ¤È¥Ç¥³¡¼¥É¤µ¤ì¤Þ¤·¤¿¡£\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "kerberos ¥¨¥é¡¼ : %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [¥µ¡¼¥Ð¤Î±þÅú  '%*s']\n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Subject: ·Ù¹ð : Fetchmail ÍÆÎÌĶ²á\n"
+"\n"
+"°Ê²¼¤Ë¼¨¤¹ÍÆÎ̤òĶ²á¤·¤¿¥á¥Ã¥»¡¼¥¸¤¬¥á¡¼¥ë¥µ¡¼¥Ð %s ¤Ë»Ä¤Ã¤Æ¤¤¤Þ¤¹ :"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr ""
+"\t%d ÈÖÌܤΥá¥Ã¥»¡¼¥¸(%d bytes ¤ÎŤµ¤¬¤¢¤ê¤Þ¤¹)¤ÏÆɤßÈô¤Ð¤µ¤ì¤Þ¤·¤¿¡£\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr ""
+"%s@%s °¸¤ËÆϤ¤¤¿ %d ÈÖÌܤΥá¥Ã¥»¡¼¥¸ (%d ¥Ð¥¤¥È) ¤òÆɤßÈô¤Ð¤·¤Æ¤¤¤Þ¤¹¡£"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr ""
+"%s@%s °¸¤ËÆϤ¤¤¿ %d ÈÖÌܤΥá¥Ã¥»¡¼¥¸ (%d ¥Ð¥¤¥È) ¤òÆɤßÈô¤Ð¤·¤Æ¤¤¤Þ¤¹¡£"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr " (Ťµ -1)"
+
+#: driver.c:568
+#, fuzzy
+msgid " (oversized)"
+msgstr "  (ÍÆÎÌĶ²á, %d ¥Ð¥¤¥È)"
+
+#: driver.c:583
+#, fuzzy, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr ""
+"%s@%s °¸¤ËÆϤ¤¤¿ %d ÈÖÌܤΥá¥Ã¥»¡¼¥¸(%d ¥Ð¥¤¥È) ¤Î¥Ø¥Ã¥À¤òÆɤ߽Ф»¤Þ¤»¤ó¤Ç¤·"
+"¤¿¡£"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "%s@%s °¸¤ËÆϤ¤¤¿ %d ÈÖÌܤΥá¥Ã¥»¡¼¥¸(Á´Éô¤Ç %d ÄÌ)¤òÆɤ߹þ¤ó¤Ç¤¤¤Þ¤¹"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d ¥Ð¥¤¥È%s)"
+
+#: driver.c:606
+msgid "header "
+msgstr " (¥Ø¥Ã¥À) "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d ¥Ð¥¤¥È (ËÜÂÎ) )"
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"%s@%s °¸¤ËÆϤ¤¤¿ %d ÈÖÌܤΥá¥Ã¥»¡¼¥¸¤ÎÂ礭¤µ¤¬¹ç¤¤¤Þ¤»¤ó (%d (¼ÂºÝ) != %d (ͽ"
+"ÁÛ)) \n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " ¥á¥Ã¥»¡¼¥¸¤Ï¥µ¡¼¥Ð¤Ë¤½¤Î¤Þ¤Þ¤Ë¤·¤Æ¤¢¤ê¤Þ¤¹¡£\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " ¥µ¡¼¥Ð¤«¤é¥á¥Ã¥»¡¼¥¸¤òºï½ü¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " ¥µ¡¼¥Ð¤«¤é¥á¥Ã¥»¡¼¥¸¤òºï½ü¤·¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+"ºÇÂç¼è¤ê¹þ¤ß¿ô¤Ç¤¢¤ë %d Ä̤Ë㤷¤Þ¤·¤¿; ¥á¥Ã¥»¡¼¥¸¤¬ %d ÄÌ¡¢¥µ¡¼¥Ð %s ¤Ë¥¢¥«"
+"¥¦¥ó¥È %s °¸¤Ç»Ä¤µ¤ì¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "MDA ¤è¤ê SIGPIPE ¤¬È¯¿®¤µ¤ì¤¿¤« stream socket ¤Î¥¨¥é¡¼¤Ç¤¹¡£\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr "%d Éô֥µ¡¼¥Ð %s ¤ÎÀܳ±þÅú¤òÂÔ¤Á¤Þ¤·¤¿¤¬À©¸Â»þ´Ö¤òĶ²á¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "%d Éô֥µ¡¼¥Ð %s ¤Î±þÅú¤òÂÔ¤Á¤Þ¤·¤¿¤¬À©¸Â»þ´Ö¤òĶ²á¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "%d ÉÃ´Ö %s ¤Î±þÅú¤òÂÔ¤Á¤Þ¤·¤¿¤¬À©¸Â»þ´Ö¤òĶ²á¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr ""
+"žÁ÷Àè¤Î¥×¥í¥°¥é¥à¤Î±þÅú¤ò %d ÉôÖÂÔ¤Á¤Þ¤·¤¿¤¬À©¸Â»þ´Ö¤òĶ²á¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "%d ÉôÖÂÔµ¡¤·¤Þ¤·¤¿¤¬À©¸Â»þ´Ö¤òĶ²á¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Subject: fetchmail ¼Â¹ÔÃæ¤Ë·«¤êÊÖ¤·À©¸Â»þ´Ö¤ÎĶ²á¤¬È¯À¸¤·¤Þ¤·¤¿\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail ¼Â¹ÔÃæ¤Ë %d ²ó°Ê¾å¡¢%s@%s °¸¤ËÆϤ¤¤¿¥á¡¼¥ë¼õ¿®¤ò»î¤ß¤Þ¤·¤¿¤¬¡¢¤½¤Î"
+"ÅÙ¤ËÀ©¸Â»þ´Ö¤òĶ²á¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"¤³¤Î¤³¤È¤Ïµ®Êý¤Î¥á¡¼¥ë¥µ¡¼¥ÐËô¤Ï SMTP ¥µ¡¼¥Ð¤¬Æ°ºîÉÔÁ´¤Ë´Ù¤Ã¤Æ¤¤¤ë¤«¡¢\n"
+"¥µ¡¼¥Ð¤ÎÉÔÄ´¤Ë¤è¤Ã¤Æµ®Êý¤Î¥á¡¼¥ë¥Ü¥Ã¥¯¥¹¥Õ¥¡¥¤¥ë¤¬Ç˲õ¤µ¤ì¤Æ¤¤¤ë¤³¤È¤ò\n"
+"°ÕÌ£¤·¤Þ¤¹¡£¤³¤ÎÌäÂê¤ò¿ÇÃǤ¹¤ë¤¿¤á¤Ë `fetchmail -v -v' ¤ò¼Â¹Ô¤·¤Æ²¼¤µ¤¤¡£\n"
+"\n"
+"ºÆµ¯Æ°¤·¤Ê¤¤¸Â¤ê fetchmail ¤Ï¤³¤Î¥á¡¼¥ë¥Ü¥Ã¥¯¥¹¤è¤ê\n"
+"¥á¡¼¥ë¤ò¼è¤ê½Ð¤·¤Þ¤»¤ó¤Î¤ÇÃí°Õ¤·¤Æ²¼¤µ¤¤¡£\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr ""
+"¥µ¡¼¥Ð¤Ø¤ÎÀܳ³«»ÏÁ°¤Ë¼Â¹Ô¤·¤¿¥³¥Þ¥ó¥É¤¬¥¹¥Æ¡¼¥¿¥¹ %d ¤òÊÖ¤·¤Æ½ªÎ»¤·¤Þ¤·"
+"¤¿¡£\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "%s ¤Ë¤¢¤ë¤Ù¤­ HESIOD pobox ¤¬¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Lead server ¤Î̾Á°¤¬¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "%s ¤Î canonical DNS ̾¤ò¸¡º÷¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "ÆâÉô¤Ç¤ÎÉÔ°ìÃפ¬¤¢¤ê¤Þ¤·¤¿¡£\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "%s ¥×¥í¥È¥³¥ë¤òÍøÍѤ·¤¿ %s ¤Ø¤ÎÀܳ¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "ÉÔÌÀ¤Ê¥Û¥¹¥È¤Ç¤¹¡£"
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "̾Á°¤ÏÍ­¸ú¤Ç¤¹¤¬ IP ¥¢¥É¥ì¥¹¤¬¤¢¤ê¤Þ¤»¤ó¡£"
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "¥Í¡¼¥à¥µ¡¼¥Ð¤Î²óÉüÉÔǽ¤Ê¥¨¥é¡¼¤Ç¤¹¡£"
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "°ì»þŪ¤Ê¥Í¡¼¥à¥µ¡¼¥Ð¤Î¥¨¥é¡¼¤Ç¤¹¡£"
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "ÉÔÌÀ¤Ê DNS ¤Î¥¨¥é¡¼ %d ¤Ç¤¹¡£"
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Subject: Fetchmail ·Ù¹ð : ¥µ¡¼¥Ð¤È¸ò¿®ÉÔǽ\n"
+"\n"
+"Fetchmail ¼Â¹ÔÃæ¤Ë¥á¡¼¥ë¥µ¡¼¥Ð %s ¤È¸ò¿®½ÐÍè¤Þ¤»¤ó¤Ç¤·¤¿¡£"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "SSL ¤Ë¤è¤ëÀܳ¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "¥¢¥«¥¦¥ó¥È %s@%s ¤¬ Lock-busy ¾õÂ֤Ǥ¹¡£\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "%s@%s ¤Î¥µ¡¼¥Ð¤¬ busy ¾õÂ֤Ǥ¹¡£\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "%s@%s%s ¤Îǧ¾Ú¤Ë¼ºÇÔ¤·¤Þ¤·¤¿\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr "(°ÊÁ°¤Ïǧ¾Ú¤µ¤ì¤Þ¤·¤¿)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: Fetchmail ¼Â¹ÔÃæ %s@%s ¤Îǧ¾Ú¤Ë¼ºÇÔ\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail ¼Â¹ÔÃæ¤Ë %s@%s °¸¤ËÆϤ¤¤¿¥á¡¼¥ë¤ò¼è¤ê½Ð¤»¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: driver.c:1224
+#, fuzzy
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"ǧ¾Ú¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+"¤«¤Ä¤Æ¤³¤Î¥µ¡¼¥Ð¤è¤êÀܳǧ¾Ú¤ò¼õ¤±¤ë¤³¤È¤¬¤Ç¤­¤¿¤Î¤Ç¡¢¥µ¡¼¥Ð¤¬ busy ¤Ê¤É¡¢\n"
+"¾¤ÎÍ×°ø¤Ë¤è¤ë¤â¤Î¤Ç¤¢¤ë¤È»×¤ï¤ì¤Þ¤¹¤¬¡¢²¿¸Î login ¤Ë¼ºÇÔ¤·¤¿¤Î¤«\n"
+"¥µ¡¼¥Ð¤«¤éÍ­±×¤Ê¾ðÊó¤¬Á÷¿®¤µ¤ì¤Æ¤¤¤Ê¤¤¤¿¤á¡¢fetchmail ¤Ç¤ÏȽÃǤ·¤«¤Í¤Þ¤¹¡£\n"
+"\n"
+"¤â¤· fetchmail ¥Ç¡¼¥â¥ó¤òµ¯Æ°¸å¤Ë¥¢¥«¥¦¥ó¥È¤Î¾ðÊó¤òÊѹ¹¤·¤¿¤Î¤Ç¤·¤¿¤é¡¢\n"
+"°ìÅ٥ǡ¼¥â¥ó¤òÄä»ß¤·¤Æ¡¢fetchmail ¤ÎÀßÄê¤òÀµ¤·¤¯Êѹ¹¤·¡¢\n"
+"ºÆÅ٥ǡ¼¥â¥ó¤òΩ¤Á¾å¤²¤Æ²¼¤µ¤¤¡£\n"
+"\n"
+"fetchmail ¥Ç¡¼¥â¥ó¤Ï°ú³¤­Àܳ¤ò»î¤ß³¤±¤Þ¤¹¡£\n"
+"¥µ¡¼¥Ó¥¹¤¬Éüµì¤·¤Ê¤¤¸Â¤ê²¿¤âÄÌÃΤ¬½Ð¤µ¤ì¤Ê¤¤¤³¤È¤òλ¾µ´ê¤¤¤Þ¤¹¡£\n"
+" "
+
+#: driver.c:1239
+#, fuzzy
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"ǧ¾Ú¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+"²¿¸Î login ¤Ë¼ºÇÔ¤·¤¿¤Î¤«¥µ¡¼¥Ð¤«¤éÍ­±×¤Ê¾ðÊó¤¬Á÷¿®¤µ¤ì¤Æ¤¤¤Ê¤¤¤¿¤á¡¢\n"
+"µ®Êý¤Î¥Ñ¥¹¥ï¡¼¥É¤¬Í­¸ú¤Ç¤Ï¤Ê¤¤¤Î¤«¡¢¥µ¡¼¥Ð¤Ë²¿¤«¾ã³²¤¬È¯À¸¤·¤Æ¤¤¤ë¤Î¤«\n"
+"fetchmail ¤Ç¤ÏȽÃǤ·¤«¤Í¤Þ¤¹¡£\n"
+"\n"
+"fetchmail ¥Ç¡¼¥â¥ó¤Ï°ú³¤­Àܳ¤ò»î¤ß³¤±¤Þ¤¹¡£\n"
+"¥µ¡¼¥Ó¥¹¤¬Éüµì¤·¤Ê¤¤¸Â¤ê²¿¤âÄÌÃΤ¬½Ð¤µ¤ì¤Ê¤¤¤³¤È¤òλ¾µ´ê¤¤¤Þ¤¹¡£\n"
+"\n"
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr ""
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "%s@%s ¤ËÂФ¹¤ëÉÔÌÀ¤Ê¥í¥°¥¤¥óËô¤Ïǧ¾Ú¤Î¥¨¥é¡¼¤Ç¤¹¡£\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "%s@%s ¤ËÂФ¹¤ëǧ¾Ú¤¬¹Ô¤ï¤ì¤Þ¤·¤¿¡£\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: fetchmail %s@%s ǧ¾Ú´°Î»\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr ""
+"%s@%s ¤Î¥í¥°¥¤¥ó¤¬´°Î»¤· fetchmail ¤Ë¤è¤ë¥¢¥¯¥»¥¹¤¬²Äǽ¤È¤Ê¤ê¤Þ¤·¤¿¡£\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "¥µ¡¼¥Ó¥¹¤¬Éüµ¢¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr ""
+"ÁªÂò¤ò¤·¤Æ²¼¤µ¤¤¡£ÁªÂò¤µ¤ì¤Ê¤¤¾ì¹ç¤Ï¥Õ¥©¥ë¥À %s ¤ËºÆÅÙ¥¢¥¯¥»¥¹¤·¤Þ¤¹¡£\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr ""
+"ÁªÂò¤ò¤·¤Æ²¼¤µ¤¤¡£ÁªÂò¤µ¤ì¤Ê¤¤¾ì¹ç¤Ï¥Ç¥Õ¥©¥ë¥È¤Î¥Õ¥©¥ë¥À¤ËºÆÅÙ¥¢¥¯¥»¥¹¤·¤Þ"
+"¤¹¡£\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "¥¢¥«¥¦¥ó¥È %s , ¥µ¡¼¥Ð %s (¥Õ¥©¥ë¥À %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "¥¢¥«¥¦¥ó¥È %s , ¥µ¡¼¥Ð %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "%s ¤Ë¥¢¥¯¥»¥¹¤·¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s ( ¤½¤Î¤¦¤Á %d Ä̤ϴû¤ËÆɤ߹þ¤ó¤Ç¤¤¤Þ¤¹ ) ¤¬%s°¸¤ËÆϤ¤¤Æ¤¤¤Þ¤¹¡£"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "Ä̤Υá¥Ã¥»¡¼¥¸"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "Ä̤Υá¥Ã¥»¡¼¥¸"
+
+#: driver.c:1366
+msgid "seen"
+msgstr ""
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s¤¬%s °¸¤ËÆϤ¤¤Æ¤¤¤Þ¤¹¡£"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d ¥Ð¥¤¥È)\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "%s °¸¤Ë¥á¥Ã¥»¡¼¥¸¤ÏÆϤ¤¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "µ¶Â¤¤µ¤ì¤¿¥á¥Ã¥»¡¼¥¸¿ô!"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "RFC822 ¥Ø¥Ã¥À¤Î·çÍ¸íɵ"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "¥¯¥é¥¤¥¢¥ó¥È/¥µ¡¼¥ÐƱ´ü"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "¥¯¥é¥¤¥¢¥ó¥È/¥µ¡¼¥Ð¥×¥í¥È¥³¥ë"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "¥µ¡¼¥Ð¤Î lock busy"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "SMTP ÄÌ¿®"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "DNS »²¾È"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "ÉÔÌÀ¤Ê¥¨¥é¡¼\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "%s¥¨¥é¡¼¤¬ SMTP ¥µ¡¼¥Ð %s ¤Ø¤Î¥á¡¼¥ëÁ÷¿®Ãæ¤ËȯÀ¸¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "%s¥¨¥é¡¼¤¬ %s ¤è¤ê¥á¡¼¥ë¤ò¼õ¿®¤·¤Æ¤¤¤ëºÇÃæ¤ËȯÀ¸¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "Àܳ½ªÎ»¸å¤Ë¼Â¹Ô¤¹¤ë¥³¥Þ¥ó¥É¤¬¥¹¥Æ¡¼¥¿¥¹ %d ¤òÊÖ¤·¤Þ¤·¤¿¡£\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Kerberos V4 ¤Ë¤ÏÂбþ¤·¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Kerberos V5 ¤Ë¤ÏÂбþ¤·¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "¥ª¥×¥·¥ç¥ó --flush ¤È %s ¤ÏƱ»þ¤ËÀßÄê¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "¥ª¥×¥·¥ç¥ó --all ¤È %s ¤ÏƱ»þ¤ËÀßÄê¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "¥ª¥×¥·¥ç¥ó --limit ¤È %s ¤ÏƱ»þ¤ËÀßÄê¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: ´Ä¶­ÊÑ¿ô QMAILINJECT ¤¬ÀßÄꤵ¤ì¤Æ¤¤¤Þ¤¹¡£\n"
+"¤³¤ÎÀßÄ꤬¹Ô¤ï¤ì¤Æ¤¤¤Þ¤¹¤È¡¢qmail-inject ¤ä qmail ¤Î sendmail wrapper ¤¬\n"
+"¥Ø¥Ã¥À¤Î From: ¤ä Message-ID ¹Ô¤ò¾¡¼ê¤Ëµ¶Â¤¤¹¤ë¤¿¤áÂçÊÑ´í¸±¤Ç¤¹¡£\n"
+"\"env QMAILINJECT = %s (°ú¿ô)\" ¤ò¼Â¹Ô¤·¤Æ¤ß¤Æ²¼¤µ¤¤¡£\n"
+"%s: ½ªÎ»¤·¤Þ¤¹¡£\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: NULLMAILER_FLAGS ´Ä¶­ÊÑ¿ô¤¬ÀßÄꤵ¤ì¤Æ¤¤¤Þ¤¹¡£\n"
+"nullmailer-inject ¤ä nullmailer ¤Î senmail wrapper ¤Ë¤è¤Ã¤Æ\n"
+"¥Ø¥Ã¥À¤Î From: ¤ä Message-ID:¡¢Return-Path: ¤Î²þɵ¤¬¹Ô¤ï¤ì¤ë¶²¤ì¤¬¤¢¤ê¡¢´í¸±"
+"¤Ç¤¹¡£\n"
+"\"env NULLMAILER_FLAGS= %s (¤¢¤Ê¤¿¤ÎÍøÍѤ·¤Æ¤¤¤ë¥¨¡¼¥¸¥§¥ó¥È)\" ¤È¤·¤Æ²¼¤µ"
+"¤¤¡£\n"
+"%s: ½ªÎ»¤·¤Þ¤¹¡£\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr ""
+"%s: µ®ÍͤΥ¢¥«¥¦¥ó¥È¤Ï¸ºß¤·¤Ê¤¤¡£¤µ¤Ã¤µ¤ÈΩ¤Áµî¤êÆóÅÙ¤ÈÌá¤Ã¤Æ¤¯¤ë¤Ê¡£\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: ¥Û¥¹¥È¤¬·èÄê¤Ç¤­¤Þ¤»¤ó¡£"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "¥Û¥¹¥È %s ¤ò gethostbyname ¤Ç¸¡º÷¤»¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "¥µ¡¼¥Ð %s ¾å¤Î SMTP ¼õ¿®¥×¥í¥°¥é¥à¤Ï ESMTP ¤ËÂбþ¤·¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "¥µ¡¼¥Ð %s ¾å¤Î SMTP ¼õ¿®¥×¥í¥°¥é¥à¤Ï ETRN ¤ËÂбþ¤·¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "%s °¸¥á¥Ã¥»¡¼¥¸¤Î°ì»þÊÝ´É¡¦Å¾Á÷¤ò³«»Ï¤·¤Þ¤¹¡£\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "%s °¸¤Ë¥á¥Ã¥»¡¼¥¸¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "%s °¸¥á¥Ã¥»¡¼¥¸¤ò¸å²ó¤·¤Ë¤·¤Þ¤¹¡£\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "¥Î¡¼¥É %s °¸¤Î¥á¥Ã¥»¡¼¥¸¤Î°ì»þÊݴɤ¬½ÐÍè¤Þ¤»¤ó¡£\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "¥Î¡¼¥É %s ¤Ï %s ¤Î¤¿¤áµö²Ä¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "ETRN ¤Î¹½Ê¸¥¨¥é¡¼¤Ç¤¹¡£\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "ETRN ¤Î¥Ñ¥é¥á¡¼¥¿¤¬¸í¤Ã¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "ÉÔÌÀ¤Ê ETRN ¤Î¥¨¥é¡¼¤Ç¤¹ (%d)\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "¥ª¥×¥·¥ç¥ó --keep ¤Ï ETRN ¤È¤ÏƱ»þ¤ËÍøÍѤǤ­¤Þ¤»¤ó¡£\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "¥ª¥×¥·¥ç¥ó --flush ¤Ï ETRN ¤È¤ÏƱ»þ¤ËÍøÍѤǤ­¤Þ¤»¤ó¡£\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "¥ª¥×¥·¥ç¥ó --remote ¤Ï ETRN ¤È¤ÏƱ»þ¤ËÍøÍѤǤ­¤Þ¤»¤ó¡£\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "¥ª¥×¥·¥ç¥ó --check ¤Ï ETRN ¤È¤ÏƱ»þ¤ËÍøÍѤǤ­¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: ¼¡¤Îʪ¤ò±çÍѤ·¤Æ¤¤¤Þ¤¹¡£"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr ""
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "fetchmail ¥ê¥ê¡¼¥¹ %s "
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "¥³¥Þ¥ó¥É¥é¥¤¥ó%s%s¤è¤ê¥ª¥×¥·¥ç¥ó¤òÀßÄꤷ¤Þ¤¹¡£\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr "µÚ¤Ó"
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "¥á¡¼¥ë¥µ¡¼¥Ð¤Î½àÈ÷¤¬À°¤¤¤Þ¤»¤ó -- ¤ª¤½¤é¤¯ %s ¤¬Â¸ºß¤·¤Ê¤¤¤¿¤á¤Ç¤¹\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: ¥á¡¼¥ë¥µ¡¼¥Ð¤¬»ØÄꤵ¤ì¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: ¾¤Î fetchmail ¤¬¼Â¹ÔÃæ¤Ç¤¹¡£\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: ¥¨¥é¡¼¤ÎȯÀ¸¤Ë¤è¤ê%s fetchmail (PID=%d)¤ò½ªÎ»¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "¥Ð¥Ã¥¯¥°¥é¥¦¥ó¥É¤Î"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "¥Õ¥©¥¢¥°¥é¥¦¥ó¥É¤Î"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %s fetchmail (PID=%d) ¤¬½ªÎ»¤·¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: Ʊ¤¸¥Û¥¹¥È¤ËÂФ·¤ÆÊ̤Πfetchmail ¤¬¸ò¿®¤·¤Æ¤¤¤ë¤¿¤á¥á¡¼¥ë¤Î³Îǧ¤¬"
+"½ÐÍè¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: ¾¤Î fetchmail (PID=%d) ¤¬¼Â¹ÔÃæ¤Î¤¿¤á»ØÄꤵ¤ì¤¿¥Û¥¹¥È¤ÈÀܳ¤Ç¤­¤Þ"
+"¤»¤ó¡£\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: ¾¤Î fetchmail (PID=%d) ¤¬¥Õ¥©¥¢¥°¥é¥¦¥ó¥ÉÆ°ºîÃæ¤Ç¤¹¡£\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: ¥Ð¥Ã¥¯¥°¥é¥¦¥ó¥É¤Ç fetchmail ¤¬Æ°ºîÃæ¤Î¤¿¤á¥ª¥×¥·¥ç¥ó¤¬¼õ¤±ÉÕ¤±¤é"
+"¤ì¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr ""
+"fetchmail: ¥Ð¥Ã¥¯¥°¥é¥¦¥ó¥É¤Î fetchmail (PID=%d) ¤¬Æ°ºî¤òºÆ³«¤·¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr ""
+"fetchmail: Ʊ»þ¤ËÆ°ºî¤·¤Æ¤¤¤¿ fetchmail (PID=%d) ¤¬ÆÍÁ³¾ÃÌǤ·¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: %s@%s ¤Ë¥í¥°¥¤¥ó¤¹¤ë¤¿¤á¤Î¥Ñ¥¹¥ï¡¼¥É¤¬¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "%s@%s ¤Ë¥í¥°¥¤¥ó¤¹¤ë¤¿¤á¤Î¥Ñ¥¹¥ï¡¼¥É¤òÆþÎϤ·¤Æ²¼¤µ¤¤ : "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "fetchmail %s ¥Ç¡¼¥â¥ó¤òÆ°ºî³«»Ï¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "¥í¥°¤òÄɲ乤뤿¤á¤Ë %s ¤ò³«¤¯¤³¤È¤¬½ÐÍè¤Þ¤»¤ó¤Ç¤·¤¿\n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "%s ¤ÎÊÔ½¸¤µ¤ì¤¿»þ´Ö¤òÄ´¤Ù¤ë¤³¤È¤¬¤Ç¤­¤Þ¤»¤ó¡£(¥¨¥é¡¼ %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "%s ¤¬ÊÔ½¸¤µ¤ì¤¿¤¿¤á fetchmail ¤òºÆµ¯Æ°¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "fetchmail ¤ÎºÆµ¯Æ°¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr "ǧ¾Ú¼ºÇÔ¤«À©¸Â»þ´ÖĶ²á¤¬ÉÑȯ¤·¤¿¤¿¤á %s ¤È¤Î¸ò¿®¤òÈô¤Ð¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "»þ´Ö´Ö³Ö¤Ë㤷¤Æ¤¤¤Ê¤¤¤Î¤Ç %s ¤Î°ì»þÊݴɤò¹Ô¤¤¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Query status=0 (SUCCESS)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Query status=1 (NOMAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Query status=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Query status=3 (AUTHFAIL)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Query status=4 (PROTOCOL)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Query status=5 (SYNTAX)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "Query status=6 (IOERR)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "Query status=7 (ERROR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Query status=8 (EXCLUDE)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Query status=9 (LOCKBUSY)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "Query status=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "Query status=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Query status=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Query status=13 (MAXFETCH)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Query status=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Á´¤Æ¤ÎÀܳ¤¬Æ°ºîÉÔÁ´¤Ë´Ù¤Ã¤Æ¤·¤Þ¤¤¤Þ¤·¤¿¡£½ªÎ»¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "%s ¤ËµÙ̲¾õÂ֤Ȥʤê¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "%s ¿®¹æ¤ò¼õ¿®¤·¤¿¤¿¤áÆ°ºî¤òºÆ³«¤·¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "%d È֤ο®¹æ¤ò¼õ¿®¤·¤¿¤¿¤áÆ°ºî¤òºÆ³«¤·¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "%s ¤ËÆ°ºî¤òºÆ³«¤·¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "Ä̾ï¤Î½ªÎ»¤Ç¤¹¡£status %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "Æ°ºîÀ©¸æ¥Õ¥¡¥¤¥ë¤ÎÊÔ½¸»þ´Ö¤ò³Îǧ¤¹¤ë¤³¤È¤¬¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr "·Ù¹ð : ÀßÄê¥Õ¥¡¥¤¥ëÃæ¤Ë¥Û¥¹¥È %s ¤òÊ£¿ô²óµ­½Ò¤·¤Æ¤¤¤Þ¤¹\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "SSL Âбþ¤¬¥³¥ó¥Ñ¥¤¥ë¤Î»þÅÀ¤ÇÍ­¸ú¤Ë¤µ¤ì¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: ·Ù¹ð : %s ¤è¤ê multidrop fetch ¤ò³Îǧ¤¹¤ë¤¿¤á¤Î DNS ¤¬Í­¸ú¤Ç¤¢¤ê¤Þ"
+"¤»¤ó¡£\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "¥µ¡¼¥Ð %s ¤ÎÀßÄ̵꤬¸ú¤Ç¤¹¡£¥Ý¡¼¥ÈÈÖ¹æ¤ÏÉé¤Î¿ô¤Ç¤Ï¤¤¤±¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr ""
+"¥µ¡¼¥Ð %s ¤ÎÀßÄ̵꤬¸ú¤Ç¤¹¡£ RPOP ¤Ç¤Ï privileged port ¤òÍøÍѤ¹¤ëɬÍפ¬¤¢¤ê¤Þ"
+"¤¹¡£\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"¥µ¡¼¥Ð %s ¤ÎÀßÄ̵꤬¸ú¤Ç¤¹¡£LMTP ¤Ï¥Ç¥Õ¥©¥ë¥È¤Î SMTP ¥Ý¡¼¥È¤òÍøÍѤǤ­¤Þ¤»"
+"¤ó¡£\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "fetchall ¤È keep ¥ª¥×¥·¥ç¥ó¤Ï¥Ç¡¼¥â¥ó¥â¡¼¥É¤ÇÀßÄê¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "¥·¥°¥Ê¥ë %d ¤Ç½ªÎ»¤·¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr ""
+"%s ¤Ï %s ¤È¥×¥í¥È¥³¥ë %s ¤òÍѤ¤¤Æ %s ¤Ë¸ò¿®¤·¤Æ¤¤¤Þ¤¹¡£¸ò¿®¤¬³«»Ï¤µ¤ì¤Þ¤·"
+"¤¿¡£\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "POP2 ¤ËÂбþ¤·¤¿ÀßÄ꤬¹Ô¤ï¤ì¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "POP3 ¤ËÂбþ¤·¤¿ÀßÄ꤬¹Ô¤ï¤ì¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "IMAP ¤ËÂбþ¤·¤¿ÀßÄ꤬¹Ô¤ï¤ì¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "ETRN ¤ËÂбþ¤·¤¿ÀßÄ꤬¹Ô¤ï¤ì¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "gethostbyname(2) ̵¤·¤Ç ETRN ¤ËÂбþ¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "ODMR ¤ËÂбþ¤·¤¿ÀßÄ꤬¹Ô¤ï¤ì¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "gethostbyname(2) ̵¤·¤Ç ODMR ¤ËÂбþ¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "Âбþ¤·¤Æ¤¤¤Ê¤¤¥×¥í¥È¥³¥ë¤¬ÁªÂò¤µ¤ì¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr ""
+"%s ¤Ï %s ¤È¥×¥í¥È¥³¥ë %s ¤òÍѤ¤¤Æ %s ¤Ë¸ò¿®¤·¤Æ¤¤¤Þ¤¹¡£¸ò¿®¤¬½ªÎ»¤·¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "¸ò¿®´Ö³Ö¤Ï %d ÉäǤ¹¡£\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "¥í¥°¥Õ¥¡¥¤¥ë¤Ï %s ¤Ç¤¹¡£\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "ID ¥Õ¥¡¥¤¥ë¤Ï %s ¤Ç¤¹¡£\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "¿Ê¹Ô¾õ¶·¤Î¥á¥Ã¥»¡¼¥¸¤Ï syslog ¤òÄ̤·¤Æµ­Ï¿¤µ¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail ¤Ï¥¢¥É¥ì¥¹¤ò½ñ¤­´¹¤¨¡¢Received ¤òÀ¸À®¤·¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr "Fetchmail ¤Ï¥í¥°¥Õ¥¡¥¤¥ëÃæ¤Ë¤â¿Ê¹Ô¾õ¶·¤ò¼¨¤¹ . ¤ò½ñ¤­¹þ¤ß¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr "Fetchmail ¤Ï¸í¤Ã¤¿°¸Àè¤Î½ñ¤«¤ì¤¿¥á¥Ã¥»¡¼¥¸¤ò %s ¤ËžÁ÷¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Fetchmail ¤Ï postmaster °¸¤Ë¥¨¥é¡¼¥á¡¼¥ë¤òÁ÷¿®¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail ¤ÏÁ÷¤ê¼ç¤Ë¥¨¥é¡¼¥á¥Ã¥»¡¼¥¸¤òÁ÷¿®¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "¥¢¥«¥¦¥ó¥È %s@%s ¤Ç¤Î¥ª¥×¥·¥ç¥ó¤Ç¤¹¡£\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  ¥á¡¼¥ë¤Ï¥Û¥¹¥È %s ¤ò²ð¤·¤Æ¤ä¤ê¤È¤ê¤µ¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  ¤³¤Î¥µ¡¼¥Ð¤ËÂФ·¤Æ¤Î¥¢¥¯¥»¥¹¤Ï %d ¤Î´Ö³Ö¤Ç¹Ô¤ï¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  ¥µ¡¼¥Ð¤ÎËÜ̾¤Ï %s ¤Ç¤¹¡£\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr "  ¤³¤Î¥Û¥¹¥È¤Ï¥Û¥¹¥È¤¬»Ø¼¨¤µ¤ì¤Ê¤¤¾ì¹ç¤Ë¥¢¥¯¥»¥¹%s\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr "¤µ¤ì¤Þ¤»¤ó¡£"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr "¤µ¤ì¤Þ¤¹¡£"
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  ¥Ñ¥¹¥ï¡¼¥ÉÆþÎϤ¬É¬ÍפǤ¹¡£\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  APOP secret = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  RPOP id = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  ¥Ñ¥¹¥ï¡¼¥É = \"%s\"\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  Kerberos %s ǧ¾Ú¤Ë¤è¤ë KPOP ¥×¥í¥È¥³¥ë¤òÍøÍѤ·¤Þ¤¹¡£"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  %s ¥×¥í¥È¥³¥ë¤òÍøÍѤ·¤Þ¤¹¡£"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (%s ¥µ¡¼¥Ó¥¹¤òÍøÍѤ·¤Þ¤¹)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (%s ¥Í¥Ã¥È¥ï¡¼¥¯¥»¥­¥å¥ê¥Æ¥£¥ª¥×¥·¥ç¥ó¤òÍøÍѤ·¤Þ¤¹)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (¥Ý¡¼¥È %d ¤òÍøÍѤ·¤Þ¤¹)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (¥Ç¥Õ¥©¥ë¥È¤Î¥Ý¡¼¥È¤òÍøÍѤ·¤Þ¤¹)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (UIDL ¤ÎÍøÍѤò¶¯À©¤·¤Þ¤¹)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  ÍøÍѲÄǽ¤ÊÁ´¤Æ¤Îǧ¾ÚÊý¼°¤ò»î¤ß¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  ¥Ñ¥¹¥ï¡¼¥É¤Ë¤è¤ëǧ¾Ú¤ò¶¯À©Åª¤Ë¹Ô¤¤¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  NTLM ǧ¾Ú¤ò¶¯À©Åª¤Ë¹Ô¤¤¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  OTP ¤Ë¤è¤ëǧ¾Ú¤ò¶¯À©Åª¤Ë¹Ô¤¤¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "   CRAM-MD5 Êý¼°¤Ë¤è¤ëǧ¾Ú¤ò¶¯À©Åª¤Ë¹Ô¤¤¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  GSSAPI Êý¼°¤Ë¤è¤ëǧ¾Ú¤ò¶¯À©Åª¤Ë¹Ô¤¤¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Kerberos V4 Êý¼°¤Ë¤è¤ëǧ¾Ú¤ò¶¯À©Åª¤Ë¹Ô¤¤¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Kerberos V5 Êý¼°¤Ë¤è¤ëǧ¾Ú¤ò¶¯À©Åª¤Ë¹Ô¤¤¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  End-to-end °Å¹æ²½¤Ç¤¢¤ë¤È¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  ¥á¡¼¥ë¥µ¡¼¥Ó¥¹¤Ï %s ¤Ë¤è¤Ã¤Æ¹Ô¤ï¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  SSL ¤Ë¤è¤ë°Å¹æ²½ÄÌ¿®¤¬¹Ô¤ï¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1566
+#, fuzzy, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  %s ¥×¥í¥È¥³¥ë¤òÍøÍѤ·¤Þ¤¹¡£"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  SSL ¥µ¡¼¥Ð¾ÚÌÀ½ñ¤Î³Îǧ¤¬ÀßÄꤵ¤ì¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  SSL ¿®ÍѲÄǽ¾ÚÌÀ½ñ¤Ï %s ¤Ë³ÊǼ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr "  SSL key fingerprint (checked against the server key): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  ¥µ¡¼¥Ð¤Î±þÅúÀ©¸Â»þ´Ö¤Ï %d ÉäǤ¹¡£"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (¥Ç¥Õ¥©¥ë¥È)¡£\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  ¥Ç¥Õ¥©¥ë¥È¤Î¥á¡¼¥ë¥Ü¥Ã¥¯¥¹¤¬ÁªÂò¤µ¤ì¤Þ¤·¤¿¡£\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  ÁªÂò¤µ¤ì¤¿¥á¡¼¥ë¥Ü¥Ã¥¯¥¹:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s¼èÆÀ¤·¤Þ¤¹¡£ (--all %s)\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "Á´¤Æ¤Î¥á¥Ã¥»¡¼¥¸¤ò"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "¿·µ¬¤Î¥á¥Ã¥»¡¼¥¸¤Î¤ß"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  ¼èÆÀ¤·¤¿¥á¥Ã¥»¡¼¥¸¤Ï¥µ¡¼¥Ð¤ËÊÝ»ý%s (--keep %s)\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr "  ¸Å¤¤¥á¥Ã¥»¡¼¥¸¤Ï¼èÆÀ¤ÎÁ°¤Ë¾Ãµî%s (--flush %s)\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  server-local ¥¢¥É¥ì¥¹¤Ø¤Î½ñ¤­´¹¤¨%s (--norewrite %s)\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "¤¬¹Ô¤ï¤ì¤Þ¤¹¡£"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "¤Ï¹Ô¤ï¤ì¤Þ¤»¤ó¡£"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  ²þ¹Ôµ­¹æ¤Î½üµî%s (stripcr %s)\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  ²þ¹Ôµ­¹æ¤ÎÄɲÃ%s (forcecr %s)\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr "  Content-Transfer-Encoding ¤ÎÊÑ´¹%s (pass8bits %s)\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  MIME ¤Î¥Ç¥³¡¼¥É%s (mimedecode %s)\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  ¥µ¡¼¥Ð¥¢¥¯¥»¥¹¸å¤ÎÂÔµ¡%s (idle %s)\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  µ­½Ò¤Î¤¢¤ë Status ¹Ô¤Ï%s (dropstatus %s)\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "ºï½ü¤µ¤ì¤Þ¤¹¡£"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "ÊÝ»ý¤µ¤ì¤Þ¤¹¡£"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Delivered-To ¹Ô¤Ï%s (dropdelivered %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  ¥á¥Ã¥»¡¼¥¸¤ÎÂ礭¤µ¤ÎºÇÂç %d ¥Ð¥¤¥È¤ËÀ©¸Â¤µ¤ì¤Þ¤¹¡£ (--limit %d)\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  ¥á¥Ã¥»¡¼¥¸¤ÎÂ礭¤µ¤ËÀ©¸Â¤Ï¤¢¤ê¤Þ¤»¤ó¡£ (--limit 0)\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  ¥á¥Ã¥»¡¼¥¸¤ÎÂ礭¤µ¤ËÂФ¹¤ë·Ù¹ð¤Ï %d ÉÃËè¤Ë¹Ô¤ï¤ì¤Þ¤¹¡£ (--warnings %d)\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+"  ¥µ¡¼¥Ð¥¢¥¯¥»¥¹¤ÎÅ٤˥á¥Ã¥»¡¼¥¸¤ÎÂ礭¤µ¤Î·Ù¹ð¤ò¹Ô¤¤¤Þ¤¹¡£ (--warnings 0)\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr ""
+"  °ì²ó¤ÎÀܳ¤Ç¼èÆÀ¤Ç¤­¤ë¥á¥Ã¥»¡¼¥¸¤Ï %d Ä̤ËÀ©¸Â¤µ¤ì¤Þ¤¹¡£(--fetchlimit %d)\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr ""
+"  °ì²ó¤ÎÀܳ¤Ç¼èÆÀ¤Ç¤­¤ë¥á¥Ã¥»¡¼¥¸¤Î¿ô¤ËÀ©¸Â¤Ï¤¢¤ê¤Þ¤»¤ó¡£ (--fetchlimit 0)\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr ""
+"  °ì²ó¤ÎÀܳ¤Ç¼èÆÀ¤Ç¤­¤ë¥á¥Ã¥»¡¼¥¸¤Ï %d Ä̤ËÀ©¸Â¤µ¤ì¤Þ¤¹¡£(--fetchlimit %d)\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  ¥á¥Ã¥»¡¼¥¸¤ÎÂ礭¤µ¤ËÀ©¸Â¤Ï¤¢¤ê¤Þ¤»¤ó¡£ (--limit 0)\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  °ì²ó¤ÎÀܳ¤ÇžÁ÷¤Ç¤­¤ë¥á¥Ã¥»¡¼¥¸¤Ï %d Ä̤ËÀ©¸Â¤µ¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr ""
+"  °ì²ó¤ÎÀܳ¤ÇžÁ÷¤Ç¤­¤ë¥á¥Ã¥»¡¼¥¸¤Î¿ô¤ËÀ©¸Â¤Ï¤¢¤ê¤Þ¤»¤ó¡£ (--batchlimit 0)\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr "  ¥á¥Ã¥»¡¼¥¸¤Ï %d ÄÌËè¤Ëºï½ü¤µ¤ì¤Þ¤¹¡£ (--expunge %d)\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  ¥á¥Ã¥»¡¼¥¸¤òºï½ü¤¹¤ë´Ö³Ö¤ÏÀßÄꤵ¤ì¤Æ¤ª¤ê¤Þ¤»¤ó¡£ (--expunge 0)\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  ¥á¡¼¥ë¤ò¼èÆÀ¤¹¤ë¥É¥á¥¤¥ó¤Ï : "
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (¥Ç¥Õ¥©¥ë¥È)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  ¥Õ¥¡¥¤¥ë %s ¤Ë BSMTP ·Á¼°¤Ç¥á¥Ã¥»¡¼¥¸¤¬Äɵ­¤µ¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  ¥¢¥×¥ê¥±¡¼¥·¥ç¥ó\"%s\"¤Ë¤è¤Ã¤Æ¥á¥Ã¥»¡¼¥¸¤¬Á÷¿®¤µ¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  ¼õ¿®¤·¤¿¥á¥Ã¥»¡¼¥¸¤Ï %cMTP ¤Ë¤è¤Ã¤Æ¼¡¤Ë¼¨¤¹¥µ¡¼¥Ð¤ØžÁ÷¤µ¤ì¤Þ¤¹ :"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  ¥Û¥¹¥È¤Î MAIL FROM ¹Ô¤Î¥¢¥É¥ì¥¹¤Ï %s ¤Ç¤¹¡£\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr "  SMTP ¤Ë¤è¤Ã¤ÆÇÛ¿®¤µ¤ì¤ë RCPT TO ¹Ô¤Ëµ­¤µ¤ì¤¿¥¢¥É¥ì¥¹¤Ï %s ¤Ç¤¹¡£\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Á÷¿®Àè¤Î¥¹¥Ñ¥à¥Ö¥í¥Ã¥¯¤ËÂФ¹¤ë±þÅú¤Ï : "
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  ¥¹¥Ñ¥à¥Ö¥í¥Ã¥¯¤Ï¹Ô¤ï¤ì¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  ¥µ¡¼¥Ð¤È¤ÎÀܳ¤Ï\"%s\"¤Ë¤è¤Ã¤Æ¹Ô¤ï¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  ÀܳÁ°¤Ë¼Â¹Ô¤¹¤ëÌ¿Îá¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  ¥µ¡¼¥Ð¤È¤ÎÀܳ¤Ï\"%s\"¤Ë¤è¤Ã¤ÆÀÚÃǤµ¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Àܳ½ªÎ»»þ¤Ë¹Ô¤¦Ì¿Îá¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  ¤³¤Î¥Û¥¹¥È¤ËÂФ¹¤ë localname ¤ÏÀë¸À¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  `multi-drop' ¥â¡¼¥É: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  `single-drop' ¥â¡¼¥É: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d ¸Ä¤Î localname ¤¬Â¸ºß¤·¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  multidrop ¥¢¥É¥ì¥¹¤ò¸¡º÷¤¹¤ë DNS ¤Ï %s ¤Ç¤¹¡£\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr "  ¥µ¡¼¥Ð¤ÎÊÌ̾¤Ï multidrop ¥¢¥É¥ì¥¹¤È¼¡¤Î¤â¤Î¤ÇÈæ³Ó¤µ¤ì¤Þ¤¹ : "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "IP ¥¢¥É¥ì¥¹ \n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "̾Á° \n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  Envelope-address ¤Ë¤è¤ë¥ë¡¼¥Æ¥£¥ó¥°¤Ï¹Ô¤ï¤ì¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Envelope header ¤Ï %s ¤È¤µ¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Received"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  %d ¸Ä¤Î Envelope header ¤¬²òÀϤµ¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Prefix %s ¤Ï¥æ¡¼¥¶ ID ¤«¤é½üµî¤µ¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  Prefix ¤Ï½üµî¤µ¤ì¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  ͽ¤áÀë¸À¤µ¤ì¤¿¥á¡¼¥ë¥µ¡¼¥Ð¤ÎÊÌ̾:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  ¥í¡¼¥«¥ë¥É¥á¥¤¥ó:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  Àܳ¤Ï¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹ %s ¤òÄ̤·¤Æ¹Ô¤ï¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Àܳ¤ËÍøÍѤ¹¤Ù¤­¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹¤Î»ØÄê¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Àܳ¤Ï %s ¤Î¾õÂÖ¤ò´Æ»ë¤·¤Æ¹Ô¤ï¤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  ¾õÂÖ¤ò´Æ»ë¤·¤ÆÀܳ¤Ï¤ª¤³¤Ê¤¤¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr "  ¥µ¡¼¥Ð¤È¤ÎÀܳ¤Ë¤Ï¥×¥é¥°¥¤¥ó \"%s\" ¤òÍøÍѤ·¤Þ¤¹¡£(--plugin %s)\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  ¥µ¡¼¥Ð¤È¤ÎÀܳ¤ËÍøÍѤ¹¤ë¥×¥é¥°¥¤¥ó¤Î»ØÄê¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  ¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤È¤ÎÀܳ¤Ë¤Ï¥×¥é¥°¥¢¥¦¥È\"%s\"¤òÍøÍѤ·¤Þ¤¹¡£(--plugout %"
+"s)\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  ¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤È¤ÎÀܳ¤ËÍøÍѤ¹¤ë¥×¥é¥°¥¢¥¦¥È¤Î»ØÄê¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  ¤³¤Î¥Û¥¹¥È¤«¤é¤Î UID ¤Ïµ­Ï¿¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d ¸Ä¤Î UID ¤¬µ­Ï¿¤µ¤ì¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr "  Àܳ¾ðÊó¤Ï Received ¥Ø¥Ã¥À¤ËÄɲ䵤ì¤Þ¤¹¡£\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  Àܳ¾ðÊó¤Ï Received ¥Ø¥Ã¥À¤ËÄɲ䵤ì¤Þ¤»¤ó¡£\n"
+"\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  ¥×¥í¥Ñ¥Æ¥£ \"%s\" ¤Ï̵»ë¤µ¤ì¤Þ¤¹¡£\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "alloca ¤¬¼Â¹Ô¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "¥¨¥é¡¼ : getpassword() ¤ËÂбþ¤·¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"SIGINT ¤ò¼õ¿®¤·¤Þ¤·¤¿¡£ ½ªÎ»¤·¤Þ¤¹¡£\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr " [%s] ¤ËÂФ¹¤ë¥µ¡¼¥Ó¥¹Ì¾¤òÆÀ¤ë¤³¤È¤¬¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr " ¥µ¡¼¥Ó¥¹Ì¾ [%s] ¤òÍøÍѤ·¤Þ¤¹¡£\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "¾ÚÌÀ½ñ¤òÁ÷¿®¤·¤Þ¤¹¡£\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "¾ÚÌÀ½ñ¸ò´¹¥¨¥é¡¼¤Ç¤¹¡£\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "¥»¥­¥å¥ê¥Æ¥£¡¼¥ì¥Ù¥ë¥Ç¡¼¥¿¤òÊѹ¹¤·¤Þ¤·¤¿¡£\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "¾ÚÌÀ½ñ¤Î¸ò´¹¤¬½ªÎ»¤·¤Þ¤·¤¿¡£\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "¥µ¡¼¥Ð¤Ï integrity ¤È privacy ¤òÍ׵ᤷ¤Æ¤¤¤Þ¤¹\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Êѹ¹¤µ¤ì¤Ê¤¤¥»¥­¥å¥ê¥Æ¥£¡¼¥ì¥Ù¥ë¤Î¥Õ¥é¥°: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "ºÇÂç GSS ¥È¡¼¥¯¥óĹ¤Ï %ld ¤Ç¤¹\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "¥»¥­¥å¥ê¥Æ¥£¡¼¥ì¥Ù¥ë¤ÎÍ×µá¤ÎÀ¸À®¥¨¥é¡¼¤Ç¤¹¡£\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "GSS ¾ÚÌÀ½ñ¤òȯ¹Ô¤·¤Þ¤¹¡£\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "¾ÚÌÀ½ñ¤Îȯ¹Ô¥¨¥é¡¼¤Ç¤¹¡£\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: ¥¹¥ì¥Ã¥É¤Ï %d Éô֥¹¥ê¡¼¥×¤·¤Þ¤¹¡£\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "¥×¥í¥È¥³¥ë¤Ï IMAP4 rev 1 ¤Èǧ¼±¤µ¤ì¤Þ¤·¤¿¡£\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "¥×¥í¥È¥³¥ë¤Ï IMAP4 rev 0 ¤Èǧ¼±¤µ¤ì¤Þ¤·¤¿¡£\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "¥×¥í¥È¥³¥ë¤Ï IMAP2 Ëô¤Ï IMAP2BIS ¤Èǧ¼±¤µ¤ì¤Þ¤·¤¿¡£\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "Àܳ¤Î¸å¡¢µÙ»ß¤·¤Þ¤¹¡£\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr ""
+"OTP ¤¬Í׵ᤵ¤ì¤Þ¤·¤¿¤¬¡¢fetchmail ¤¬ OTP Âбþ¤Ç¥³¥ó¥Ñ¥¤¥ë¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Í׵ᤵ¤ì¤¿ NTLM ½èÍýǽÎÏ¤Ï fetchmail ¤ËÁȤ߹þ¤Þ¤ì¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Í׵ᤵ¤ì¤¿ LOGIN ½èÍýǽÎϤϥµ¡¼¥Ð¤Ç¥µ¥Ý¡¼¥È¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "ºï½ü¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "ºÆ¥¢¥¯¥»¥¹¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "%d Ä̤Υá¥Ã¥»¡¼¥¸¤¬ºÆ¥¢¥¯¥»¥¹¤Î¸å¤Ë¸ºß¤·¤Þ¤¹¡£\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "¥á¡¼¥ë¥Ü¥Ã¥¯¥¹¤ÎÁªÂò¤Ë¼ºÇÔ¤·¤Þ¤·¤¿\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "ºÇ½é¤Î¥¢¥¯¥»¥¹¤«¤é %d Ä̤Υá¥Ã¥»¡¼¥¸¤¬¤¢¤ê¤Þ¤¹¡£\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "ºï½ü¤Î¸å¡¢%d Ä̤Υá¥Ã¥»¡¼¥¸¤¬»Ä¤Ã¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "̤ÆÉ¥á¥Ã¥»¡¼¥¸¤Î¸¡º÷¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u ¤Ï̤ÆɤǤ¹¡£\n"
+
+#: imap.c:776 pop3.c:679
+#, fuzzy, c-format
+msgid "%u is first unseen\n"
+msgstr "%u ¤Ï̤ÆɤǤ¹¡£\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"kvm ¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹¤ò³«¤±¤Þ¤»¤ó¤Ç¤·¤¿¡£fetchmail ¤¬ SGID kmem ¤Ç¤¢¤ë¤«³Îǧ¤·"
+"¤Æ¤¯¤À¤µ¤¤¡£"
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "%s ¤«¤é¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹Ì¾¤ò²òÀϤǤ­¤Þ¤»¤ó¡£"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: sysctl (iflist estimate) ¤Ë¼ºÇÔ¤·¤Þ¤·¤¿"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: malloc ¤¬¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: sysctl (iflist) ¤Ë¼ºÇÔ¤·¤Þ¤·¤¿"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "¥ë¡¼¥Æ¥£¥ó¥°¥á¥Ã¥»¡¼¥¸ version %d ¤¬Íý²ò¤µ¤ì¤Þ¤»¤ó¤Ç¤·¤¿¡£"
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "%s ¤È¤¤¤¦Ì¾¤Î¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹¤Ï¸ºß¤·¤Þ¤»¤ó¡£"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "%s ¤Î IP ¥¢¥É¥ì¥¹¤¬¤¢¤ê¤Þ¤»¤ó¡£"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "IP ¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹¥¢¥É¥ì¥¹¤¬¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "̵¸ú¤Ê IP ¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹¥¢¥É¥ì¥¹¤Ç¤¹\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "̵¸ú¤Ê IP ¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹¥Þ¥¹¥¯¤Ç¤¹¡£\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "%s ¤ÎÆ°ºî¾õÂÖ¤Ï %d ¤È¤µ¤ì¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "¥µ¡¼¥Ð %s ¤Ø¤Î¥¢¥¯¥»¥¹¤òÈô¤Ð¤·¤Þ¤¹¡£¥µ¡¼¥Ð %s ¤Ïµ¡Ç½¤·¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "¥µ¡¼¥Ð %s ¤Ø¤Î¥¢¥¯¥»¥¹¤òÈô¤Ð¤·¤Þ¤¹¡£%s \n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "%s ¤ÎÆ°ºî¾õÂÖ¤Ï %d ¤ÈȽÄꤵ¤ì¤Þ¤·¤¿¡£\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "¥µ¡¼¥Ð %s ¤Ø¤Î¥¢¥¯¥»¥¹¤òÈô¤Ð¤·¤Þ¤¹¡£%s ¤ÏÆ°ºî²Äǽ¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "%s ¤ÎÆ°ºî¤Ï %d ¤Ç¤·¤¿¤¬¡¢º£¤Ï %d ¤Ç¤¹¡£\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "Initial BASE64 challenge ¤ò¥Ç¥³¡¼¥É¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr ""
+"Ticket Ãæ¤Ë¤¢¤ëËÜ¿Í %s ¤Ï -u ¥ª¥×¥·¥ç¥ó¤Ç»ØÄꤵ¤ì¤¿ %s ¤È°ìÃפ·¤Þ¤»¤ó¡£\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "NULL ¤Ç¤Ê¤¤ %s ¤È¤¤¤¦»ØÎá¤ÏÉԲIJò¤ÊÆ°ºî¤Î¸µ¤È¤Ê¤ë²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "BASE64 ¥ì¥Ç¥£±þÅú¤ò¥Ç¥³¡¼¥É¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "challenge ¤ÎÉÔ°ìÃפǤ¹¡£\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: ¸Å¤¤¥í¥Ã¥¯¥Õ¥¡¥¤¥ë¤òºï½ü¤·¤Þ¤¹¡£\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: ¥í¥Ã¥¯¥Õ¥¡¥¤¥ë¤ÎÀ¸À®¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "·Ù¹ð: ¥Û¥¹¥È̾¤ÎÁ°¤Ë \"%s\" ¤ò¸¡ÃΤ·¤Þ¤·¤¿"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: ·Ù¹ð: ¥Û¥¹¥È̾¤ÎÁ°¤Ë \"%s\" ¤ò¸¡ÃΤ·¤Þ¤·¤¿¡£\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: ·Ù¹ð: ÉÔÌÀ¤Ê¥È¡¼¥¯¥ó \"%s\"\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "%s ¤Î SMTP ¼õ¿®¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤¬ ATRN ¤ËÂбþ¤·¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "Turnaround now...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "ATRN Í׵᤬µñÀ䤵¤ì¤Þ¤·¤¿¡£\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "¸½ºß¡¢ATRN Í×µá¤ò¹Ô¤¦¤³¤È¤¬¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "¿·Ãå¥á¡¼¥ë¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "¥³¥Þ¥ó¥É¤¬¼ÂÁõ¤µ¤ì¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "¥æ¡¼¥¶Ç§¾Ú¤¬É¬ÍפǤ¹¡£\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "ÉÔÌÀ¤Ê ODMR ¤Î¥¨¥é¡¼ %d ¤Ç¤¹¡£\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "¥ª¥×¥·¥ç¥ó --keep ¤Ï ODMR ¤Ç¤ÏÂбþ¤·¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "¥ª¥×¥·¥ç¥ó --flush ¤Ï ODMR ¤Ç¤ÏÂбþ¤·¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "¥ª¥×¥·¥ç¥ó --remote ¤Ï ODMR ¤Ç¤ÏÂбþ¤·¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "¥ª¥×¥·¥ç¥ó --check ¤Ï ODMR ¤Ç¤ÏÂбþ¤·¤Æ¤ª¤ê¤Þ¤»¤ó¡£\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "server recv fatal\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "OTP challenge ¤Î¥Ç¥³¡¼¥É¤¬½ÐÍè¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Secret pass phrase: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "ʸ»úÎó '%s' ¤ÏÍ­¸ú¤ÊŤµ¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "'%s' ¤ÎÃͤϼ¡¤Ë¼¨¤¹¿ô»ú¤è¤ê%sɬÍפ¬¤¢¤ê¤Þ¤¹¡£: %d\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "¾®¤µ¤¤"
+
+#: options.c:211
+msgid "larger"
+msgstr "Â礭¤¤"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "̵¸ú¤Ê¥×¥í¥È¥³¥ë `%s' ¤¬»ØÄꤵ¤ì¤Þ¤·¤¿¡£\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "̵¸ú¤Êǧ¾ÚÊý¼° `%s' ¤¬»ØÄꤵ¤ì¤Þ¤·¤¿¡£\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: ¥Í¥Ã¥È¥ï¡¼¥¯¥»¥­¥å¥ê¥Æ¥£Âбþ¤¬Ìµ¸ú¤Ë¤µ¤ì¤Þ¤·¤¿\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "ÍøÍÑÊýË¡:  fetchmail [¥ª¥×¥·¥ç¥ó] [¥µ¡¼¥Ð ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  °Ê²¼¤Ë¼¨¤¹¥ª¥×¥·¥ç¥ó¤¬ÍøÍѲÄǽ¤Ç¤¹¡£\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        ¥ª¥×¥·¥ç¥ó¤ÎÀâÌÀ¤òɽ¼¨¤·¤Þ¤¹\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     ¥Ð¡¼¥¸¥ç¥ó¾ðÊó¤òɽ¼¨¤·¤Þ¤¹\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr ""
+"  -c, --check       ¥á¥Ã¥»¡¼¥¸¤Î̵ͭ¤òÄ´¤Ù¤Þ¤¹(¥Ç¡¼¥¿¤Ï¼è¤ê½Ð¤·¤Þ¤»¤ó)\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      ¾õÂÖɽ¼¨¤Ê¤É¤òÍÞÀ©¤·¤Þ¤¹\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     ºÙ¤«¤¯¾õÂÖɽ¼¨¤ò¹Ô¤¤¤Þ¤¹\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      n Éä˰ì²óÆ°ºî¤¹¤ë¥Ç¡¼¥â¥ó¤È¤·¤ÆÆ°ºî¤·¤Þ¤¹\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    ¥Ç¡¼¥â¥ó¥×¥í¥»¥¹¤ò¥Õ¥©¡¼¥¯¤·¤Þ¤»¤ó\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        ¥Ç¡¼¥â¥ó¥×¥í¥»¥¹¤ò½ªÎ»¤µ¤»¤Þ¤¹\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     ¥í¥°¤ò½ñ¤­½Ð¤¹¥Õ¥¡¥¤¥ë¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      ¥Ç¡¼¥â¥ó¤È¤·¤ÆÆ°ºî¤µ¤»¤ë¾ì¹ç¤Ë syslog(3) ¤òÄ̤·¤Æ\n"
+"                    ÂçȾ¤Î¥á¥Ã¥»¡¼¥¸¤ò½ñ¤­½Ð¤·¤Þ¤¹\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr "      --invisible   Received ¤ò½ñ¤«¤º¡¢¥Û¥¹¥È̾¤Îµ¶Â¤¤òµö²Ä¤·¤Þ¤¹\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc ÀßÄê¥Õ¥¡¥¤¥ë¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      UID ¥Õ¥¡¥¤¥ë¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  ºÇ½ªÅª¤Ê¼õ¤±¼è¤ê¼ê¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr "      --nobounce    ¥æ¡¼¥¶¤Ç¤Ï¤Ê¤¯ postmaster ¤Ø¥¨¥é¡¼ÄÌÃΤò¹Ô¤¤¤Þ¤¹\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   ¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     ¥¤¥ó¥¿¡¼¥Õ¥§¥¤¥¹¤¬Í­¸ú¤«´Æ»ë¤·¤Þ¤¹\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         SSL ¤Ë¤è¤ë°Å¹æ²½¤òÍøÍѤ·¤Þ¤¹\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      SSL ¤Î private key file ¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     SSL ¤Î client certificate ¥Õ¥¡¥¤¥ë¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr ""
+"      --sslproto    SSL ¤Î¥×¥í¥È¥³¥ë¤ò¶¯À©Åª¤Ë»ØÄꤷ¤Þ¤¹ (ssl2/ssl3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr "      --plugin      ÀܳÍѤγ°Éô¥³¥Þ¥ó¥É¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     SMTP ¤Ë¤è¤ë¸ò¿®¤ò¹Ô¤¦¤¿¤á¤Î³°Éô¥³¥Þ¥ó¥É¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:691
+#, fuzzy
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    ÍøÍѤ¹¤ë¥×¥í¥È¥³¥ë¤ò»ØÄꤷ¤Þ¤¹¡£\n"
+"                    (¾ÜºÙ¤Ï man page ¤ò»²¾È¤·¤Æ²¼¤µ¤¤)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        UIDL ¤ò¶¯À©Åª¤ËÍøÍѤ·¤Þ¤¹ (POP3 ¤Î¤ßÍ­¸ú¤Ç¤¹)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        Àܳ¤ËÍøÍѤ¹¤ë TCP/IP ¥µ¡¼¥Ó¥¹¥Ý¡¼¥È¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:694
+#, fuzzy
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr "      --auth        ǧ¾ÚÊý¼°¤ò»ØÄꤷ¤Þ¤¹ (password/kerberos/ssh)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     ¥µ¡¼¥Ð¤Î±þÅúÂÔ¤ÁÀ©¸Â»þ´Ö¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    ¥¢¥É¥ì¥¹¥Ø¥Ã¥À¤ò±£¤·¤Þ¤¹\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr "  -Q, --qvirtual    local user id ¤«¤é prefix ¤òºï½ü¤·¤Þ¤¹\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   ¥á¡¼¥ë¥µ¡¼¥Ó¥¹¤ÇÍøÍѤ¹¤ëÊý¼°¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr "      --tracepolls  Received ¥Ø¥Ã¥À¤ËÀܳ¾ðÊó¤ò½ñ¤­²Ã¤¨¤Þ¤¹\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    ¥µ¡¼¥Ð¤Ø¤Î¥í¥°¥¤¥ó̾¤ò¤·¤Æ¤¤¤·¤Þ¤¹\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         ¿·ÃåµÚ¤Ó´ûÃå¤Î¥á¡¼¥ë¤òÁ´¤Æ¼è¤ê½Ð¤·¤Þ¤¹\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      ¼è¤ê½Ð¤·¤¿¥á¥Ã¥»¡¼¥¸¤ò¥µ¡¼¥Ð¤«¤é¾Ãµî¤·¤Þ¤¹\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        ¼è¤ê½Ð¤·¤¿¥á¥Ã¥»¡¼¥¸¤ò¥µ¡¼¥Ð¤Ë»Ä¤·¤Æ¤ª¤­¤Þ¤¹\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       ´û¤Ë¼è¤ê½Ð¤·¤¿¥á¥Ã¥»¡¼¥¸¤ò¥µ¡¼¥Ð¤«¤é¾Ãµî¤·¤Þ¤¹\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   ¥Ø¥Ã¥À¤Î¥¢¥É¥ì¥¹¤ò½ñ¤­´¹¤¨¤Þ¤»¤ó\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -l, --limit       »ØÄꤵ¤ì¤¿Â礭¤µ°Ê¾å¤Î¥á¥Ã¥»¡¼¥¸¤ò¼è¤ê½Ð¤·¤Þ¤»¤ó\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr ""
+"  -w, --warnings    ÍÆÎÌĶ²á¤Î¥á¡¼¥ë¤Ë¤Ä¤¤¤Æ·Ù¹ð¤òȯ¤¹¤ë´Ö³Ö¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      IP security request ¤ò»ØÄꤷ¤Þ¤¹¡£\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    žÁ÷Àè¤Î SMTP ¥Û¥¹¥È¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr ""
+"      --fetchdomains °ì²ó¤ÎÀܳ¤Ç¥á¡¼¥ë¤ò¼èÆÀ¤¹¤Ù¤­¥É¥á¥¤¥ó̾¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr "  -D, --smtpaddress SMTP ¤Ë¤è¤ëžÁ÷¤ÇÍøÍѤ¹¤ë¥É¥á¥¤¥ó̾¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr ""
+"      --smtpname    SMTP žÁ÷¤ÇÍøÍѤ¹¤ë¥Õ¥ë¥Í¡¼¥à username@domain ¤ò»ØÄꤷ¤Þ"
+"¤¹\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    ¥¹¥Ñ¥à¥á¡¼¥ëÂкö¤Î±þÅú¤ò»ØÄꤷ¤Þ¤¹¡£\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+"  -b, --batchlimit  °ì²ó¤Î SMTP žÁ÷¤ÇÁ÷¿®¤µ¤ì¤ë¥á¡¼¥ë¤ÎºÇÂç¿ô¤òÀßÄꤷ¤Þ¤¹\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  °ì²ó¤Î¥µ¡¼¥Ð¤È¤Î¸ò¿®¤Ç¼èÆÀ¤Ç¤­¤ë¥á¡¼¥ë¤ÎºÇÂç¿ô¤òÀßÄꤷ¤Þ"
+"¤¹¡£\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr ""
+"      --fetchdomains °ì²ó¤ÎÀܳ¤Ç¥á¡¼¥ë¤ò¼èÆÀ¤¹¤Ù¤­¥É¥á¥¤¥ó̾¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr "  -e, --expunge     ¥á¥Ã¥»¡¼¥¸¤ò°ìÅ٤˾õ¤ëºÇÂç¿ô¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         ¥á¡¼¥ëÁ÷¿®¥×¥í¥°¥é¥à¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr ""
+"      --bsmtp       ¼è¤ê¹þ¤ó¤À¥á¡¼¥ë¤ò½ñ¤­½Ð¤¹ BSMTP ¥Õ¥¡¥¤¥ë¤ò»ØÄꤷ¤Þ¤¹¡£\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        LMTP (RFC2033) ¤òÇÛ¿®¤ËÍøÍѤ·¤Þ¤¹\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      ¥µ¡¼¥Ð¤Î¥á¡¼¥ë¥Õ¥©¥ë¥À¤ò»ØÄꤷ¤Þ¤¹\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr "      --showdots    ¥í¥°¥Õ¥¡¥¤¥ë¤Ë¤â¿Ê¹Ô¾õ¶·¤ò¼¨¤¹ . ¤ò½ñ¤­¹þ¤ß¤Þ¤¹\n"
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "greeting Ãæ¤Ë APOP timestamp ¤¬Â¸ºß¤·¤Þ¤»¤ó¡£\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "greeting Ãæ¤Î timestamp ¤¬ÉÔÀµ¤Ç¤¹¡£\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "POP3_auth Ãæ¤ÇÄêµÁ¤µ¤ì¤Æ¤¤¤Ê¤¤¥×¥í¥È¥³¥ë¤¬Í׵ᤵ¤ì¤Þ¤·¤¿¡£\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "lock busy ¾õÂ֤Ǥ¹¡£Ê̤θò¿®¤¬¹Ô¤ï¤ì¤Æ¤¤¤Ê¤¤¤«³Îǧ¤·¤Æ²¼¤µ¤¤¡£\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr ""
+"¥µ¡¼¥Ð¥ê¥¹¥È¤Ë¥á¥Ã¥»¡¼¥¸¤¬ÁÞÆþ¤µ¤ì¤Æ¤¤¤Þ¤¹¡£¼è¤ê°·¤¦¤³¤È¤¬¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "¥×¥í¥È¥³¥ë¥¨¥é¡¼¤Ç¤¹¡£\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "UIDL ¤ò¼è¤ê¹þ¤ßÃæ¤Ë¥×¥í¥È¥³¥ë¥¨¥é¡¼¤¬È¯À¸¤·¤Þ¤·¤¿¡£\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "POP3 ¤Ç¤Ï --remote ¥ª¥×¥·¥ç¥ó¤ÏÍøÍѤǤ­¤Þ¤»¤ó¡£\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "¥µ¡¼¥Ð¥ª¥×¥·¥ç¥ó¤Ï¥æ¡¼¥¶¥ª¥×¥·¥ç¥ó¤Î¸å¤ÇÀßÄꤷ¤Þ¤¹¡£"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "SDPS ¤ÏÍøÍѤǤ­¤Þ¤»¤ó¡£"
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "̵¸ú¤Ê¥»¥­¥å¥ê¥Æ¥£¡¼Í×µá¤Ç¤¹¡£"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "¥Í¥Ã¥È¥ï¡¼¥¯¥»¥­¥å¥ê¥Æ¥£¡¼Âбþ¤Ï¤Ç¤­¤Ê¤¤ÀßÄê¤È¤Ê¤Ã¤Æ¤¤¤Þ¤¹¡£"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: interface ¥ª¥×¥·¥ç¥ó¤Ï Linux (IPv6 ¤ÏÍøÍѤǤ­¤Þ¤»¤ó) ¤ÈFreeBSD ¤Î"
+"¤ß¤ÇÍøÍѲÄǽ¤Ç¤¹¡£\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: monitor ¥ª¥×¥·¥ç¥ó¤Ï Linux (IPv6 ¤ÏÍøÍѤǤ­¤Þ¤»¤ó) ¤ÈFreeBSD ¤Î¤ß"
+"¤ÇÍøÍѲÄǽ¤Ç¤¹¡£\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "SSL ¤¬Í­¸ú¤È¤Ê¤Ã¤Æ¤ª¤ê¤Þ¤»¤ó¡£"
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "ÆþÎϤνªÃ¼"
+
+#: rcfile_y.y:435
+#, fuzzy, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "%s ¤Ï¥·¥ó¥Ü¥ê¥Ã¥¯¥ê¥ó¥¯¤Ç¤¢¤Ã¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "%s ¤Ï -rwx--x--- (0710) °Ê³°¤Î¥Ñ¡¼¥ß¥Ã¥·¥ç¥ó¤Ç¤¢¤Ã¤Æ¤Ï¤¤¤±¤Þ¤»¤ó¡£\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "%s ¤Î½êÍ­¼Ô¤Ïµ®Êý¼«¿È¤Ç¤¢¤ëɬÍפ¬¤¢¤ê¤Þ¤¹¡£\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "ÉÔÌÀ¤Ê¥·¥¹¥Æ¥à¥¨¥é¡¼¤Ç¤¹¡£"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (¥í¥°¥á¥Ã¥»¡¼¥¸¤¬ÉÔ´°Á´¤Ç¤¹¡£)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "ÉôʬŪ¤Ê¥¨¥é¡¼¥á¥Ã¥»¡¼¥¸¤ÎÍÆÎÌĶ²á¤Ç¤¹¡£"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "%s ¤ÎºÆ½ñ¤­¹þ¤ß¤Ë¤Ä¤¤¤Æ"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "Rewritten ¥Ð¡¼¥¸¥ç¥ó¤Ï %s ¤Ç¤¹¡£\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "À®¸ù¤·¤Þ¤·¤¿¡£"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "À©Ìó¤ò¼õ¤±¤Æ¤¤¤ë¥æ¡¼¥¶¤Ç¤¹¡£(²¿¤«¤³¤Î¥¢¥«¥¦¥ó¥È¤ËÌäÂ꤬¤¢¤ê¤Þ¤¹¡£)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "ÉÔÀµ¤Ê¥æ¡¼¥¶ ID ¤«¥Ñ¥¹¥Õ¥ì¡¼¥º¤Ç¤¹¡£"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "Deity ¥¨¥é¡¼"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "RPA token 2: Base64 ¥Ç¥³¡¼¥É¥¨¥é¡¼\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "RPA ¥Ð¡¼¥¸¥ç¥ó %d.%d ¤òÁªÂò¤·¤Þ¤·¤¿¡£\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Service challenge (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Service timestamp %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "RPA token 2 Ĺ¥¨¥é¡¼\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Realm ¥ê¥¹¥È: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "service@realm ¤Ë¤ª¤±¤ë RPA ¥¨¥é¡¼¤¬È¯À¸¤·¤Þ¤·¤¿¡£\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA token 4: Base64 ¥Ç¥³¡¼¥É¥¨¥é¡¼\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "¥æ¡¼¥¶Ç§¾Ú (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "RPA status: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "RPA token 4 Ĺ¥¨¥é¡¼\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA ¤è¤êµñÀ䤵¤ì¤Þ¤·¤¿¡£:%s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "Íýͳ¤Ïʬ¤«¤ê¤Þ¤»¤ó¤¬ RPA ¤è¤êµñÀ䤵¤ì¤Þ¤·¤¿¡£\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "RPA User Anthentication Ĺ¥¨¥é¡¼: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "RPA Session key Ĺ¥¨¥é¡¼: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "RPA _service_ auth ¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£µ¶Áõ¥µ¡¼¥Ð¤Ç¤·¤ç¤¦¤«¡©\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Session key ¤¬³ÎΩ¤·¤Þ¤·¤¿:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "RPA ǧ¾Ú¤¬½ªÎ»¤·¤Þ¤·¤¿¡£\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "±þÅú¤òÆÀ¤Þ¤·¤¿¡£\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "±þÅú %d ¤òÆÀ¤Þ¤·¤¿¡£ [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "Hdr ¤¬ 60 ¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "¥È¡¼¥¯¥óĹ¥¨¥é¡¼\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "¥È¡¼¥¯¥ó¤ÎŤµ %d ¤Ï rxlen ¤ÎŤµ %d ¤È°ìÃפ·¤Þ¤»¤ó¡£\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Mechanism field ¤¬ÉÔÀµ¤Ç¤¹¡£\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "ʸ»ú %d ¤Ë¤ª¤¤¤Æ dec64 ¥¨¥é¡¼¤¬È¯À¸¤·¤Þ¤·¤¿¡£%x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "¼õ¿®¥Ç¡¼¥¿:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "žÁ÷Æü»þ:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "RPA String ¤¬Ä¹¤¹¤®¤Þ¤¹¡£\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA ¤Ï /dev/urandom ¤Î¥ª¡¼¥×¥ó¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "¤³¤Î¤³¤È¤Ë¤è¤Ã¤Æ¥í¥°¥¤¥ó¤¬µñÈݤµ¤ì¤ë¤³¤È¤Ï¤¢¤ê¤Þ¤»¤ó¤¬¡¢\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "ËÜÅö¤ËÄÌ¿®¤·¤¿¤¤¤È¹Í¤¨¤Æ¤¤¤ëÁê¼ê¤È¸ò¿®¤·¤Æ¤¤¤ë¤«\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "³Î¾Ú¤ÏÆÀ¤é¤ì¤Þ¤»¤ó¡£\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "(¥µ¡¼¥Ó¥¹¤òÙÔ¤¤·¤¿·«¤êÊÖ¤·¹¶·â¤Î²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹¡£)\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "User challenge:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "MD5 ¤ò¥Ç¡¼¥¿¥Ö¥í¥Ã¥¯¤ËŬÍѤ·¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "MD5 ¤Î·ë²Ì :\n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "%s ¤ØžÁ÷¤·¤Þ¤¹¡£\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (žÁ÷¤µ¤ì¤¿¥á¥Ã¥»¡¼¥¸¤ÎËÜÂÎ)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "%s ¤«¤é¤Î¥á¡¼¥ë¤ò %s ¤ËžÁ÷¤·¤Þ¤¹¡£\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "¥¨¥é¡¼¤Ï¤Þ¤À %d ¤Ç¤¹¡£\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "%cMTP ¥¨¥é¡¼: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr ""
+"BSMTP ¥Õ¥¡¥¤¥ë¤Î¥ª¡¼¥×¥ó¡¢¤Þ¤¿¤Ï¡¢¥×¥ê¥¢¥ó¥Ö¥ë¤Î½ñ¤­¹þ¤ß¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr ""
+"%cMTP Á÷¿®Àè¤Î¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤¬ `%s' ¤È¤¤¤¦¼õ¤±¼ê¤Î¥¢¥É¥ì¥¹¤ò¼õ¤±ÉÕ¤±¤Þ¤»"
+"¤ó¡£\n"
+
+#: sink.c:989
+#, fuzzy, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr ""
+"%cMTP Á÷¿®Àè¤Î¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤¬ `%s' ¤È¤¤¤¦¼õ¤±¼ê¤Î¥¢¥É¥ì¥¹¤ò¼õ¤±ÉÕ¤±¤Þ¤»"
+"¤ó¡£\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "¥¢¥É¥ì¥¹¤¬°ìÃפ·¤Þ¤»¤ó¡£postmaster ¤¬ÀßÄꤵ¤ì¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "%s ¤ËÂФ·¤Æ¤µ¤¨Á÷¿®¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "¥¢¥É¥ì¥¹¤¬°ìÃפ·¤Þ¤»¤ó¡£%s ¤ØžÁ÷¤·¤Þ¤¹¡£\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "%s ¤òÍøÍѤ·¤¿ÇÛ¿®¤Ë¤Ä¤¤¤Æ\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "MDA ¤Îµ¯Æ°¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "%cMTP ¤Ë¤è¤ë %s ¤Ø¤ÎÀܳ¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "ÄÌ¿®Àè¤Î¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤È¸ò¿®¤Ç¤­¤Þ¤»¤ó¡£%s ¤È¸ò¿®¤·¤Þ¤¹¡£"
+
+#: sink.c:1339
+#, fuzzy, c-format
+msgid "MDA died of signal %d\n"
+msgstr "%d È֤ο®¹æ¤ò¼õ¿®¤·¤¿¤¿¤áÆ°ºî¤òºÆ³«¤·¤Þ¤·¤¿¡£\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "MDA ¤¬ 0 °Ê³°¤Î¥¹¥Æ¡¼¥¿¥¹ %d ¤òÊÖ¤·¤Æ½ªÎ»¤·¤Þ¤·¤¿¡£\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr ""
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "¥á¥Ã¥»¡¼¥¸¤Î½ªÎ»¡¢¤Þ¤¿¤Ï¡¢BSMTP ¥Õ¥¡¥¤¥ë¤Î½ªÎ»¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "SMTP ÄÌ¿®Àè¤Î¥¢¥×¥ê¥±¡¼¥·¥ç¥ó¤¬ÇÛ¿®¤òµñ¤ß¤Þ¤·¤¿¡£\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "LMTP ¤Î EOM ¤Ë¤ª¤±¤ëÇÛ¿®¥¨¥é¡¼¤Ç¤¹¡£\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "LMTP EOM ¤ËÂФ·¤Æ 503 °Ê³°¤Îͽ´ü¤»¤Ì±þÅú %s ¤¬¤¢¤ê¤Þ¤·¤¿¡£\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\t Fetchmail ¥Ç¡¼¥â¥ó \n"
+
+#: smtp.c:86
+#, fuzzy
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "   CRAM-MD5 Êý¼°¤Ë¤è¤ëǧ¾Ú¤ò¶¯À©Åª¤Ë¹Ô¤¤¤Þ¤¹¡£\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "¥µ¡¼¥Ð¤¬ AUTH ¥³¥Þ¥ó¥É¤òµñÀ䤷¤Þ¤·¤¿¡£\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "¥µ¡¼¥Ð¤«¤é¸í¤Ã¤¿ base64 ¤ÎÊÖÅú¤òÆÀ¤Þ¤·¤¿¡£\n"
+
+#: smtp.c:105
+#, fuzzy, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "%s ¤È¥Ç¥³¡¼¥É¤µ¤ì¤Þ¤·¤¿¡£\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "ESMTP ¤Ç PLAIN ǧ¾Ú¤ò¤·¤Þ¤¹...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "ESMTP ¤Ç LOGIN ǧ¾Ú¤ò¤·¤Þ¤¹...\n"
+
+#: smtp.c:361 smtp.c:384
+#, fuzzy
+msgid "smtp listener protocol error\n"
+msgstr "¥×¥í¥È¥³¥ë¥¨¥é¡¼¤Ç¤¹¡£\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: malloc ¤¬¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: socketpair ¤Ë¼ºÇÔ¤·¤Þ¤·¤¿¡£\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: fork ¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "dup2 ¤¬¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "%s ¤ò¼Â¹ÔÃæ¤Ç¤¹¡£(¥Û¥¹¥È %s ¥µ¡¼¥Ó¥¹ %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "execvp(%s) ¤¬¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: ¥Û¥¹¥È %s ¤Î¥¢¥É¥ì¥¹¤ÎŤµ¤¬ÉÔÀµ¤Ç¤¹¡£\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "ȯ¹Ô¸µ¤ÎÁÈ¿¥: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr "·Ù¹ð : ȯ¹Ô¸µ¤ÎÁÈ¿¥Ì¾¤¬Ä¹²á¤®¤Þ¤¹¡£(ÙÔ¤¤µ¤ì¤¿²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹)\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "ÉÔÌÀ¤ÊÁÈ¿¥¤Ç¤¹¡£\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "ȯ¹Ô¸µ¤Î CommonName: %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+"·Ù¹ð : ȯ¹Ô¸µ¤Î CommonName ¤¬Ä¹²á¤®¤Þ¤¹¡£ (ÙÔ¤¤µ¤ì¤¿²ÄǽÀ­¤¬¤¢¤ê¤Þ¤¹)\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "ÉÔÌÀ¤Êȯ¹Ô¸µ¤Î CommonName ¤Ç¤¹¡£\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "¥µ¡¼¥Ð¤Î CommonName: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "ÉÔÀµ¾ÚÌÀ½ñ : Subject CommonName ¤¬Ä¹²á¤®¤Þ¤¹¡£\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "¥µ¡¼¥Ð¤Î CommonName ¤¬°ìÃפ·¤Þ¤»¤ó : %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr "¥µ¡¼¥Ð̾¤¬ÀßÄꤵ¤ì¤Æ¤ª¤é¤º¡¢¾ÚÌÀ½ñ¤ò¸¡¾Ú¤Ç¤­¤Þ¤»¤ó¡£\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "ÉÔÌÀ¤Ê¥µ¡¼¥Ð¤Î CommonName ¤Ç¤¹¡£\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "¾ÚÌÀ½ñÃæ¤Ë¥µ¡¼¥Ð̾¤¬»ØÄꤵ¤ì¤Æ¤¤¤Þ¤»¤ó¡£\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "EVP_md5() ¤¬¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "¥á¥â¥êÉÔ­¤Ç¤¹¡£\n"
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "¥À¥¤¥¸¥§¥¹¥È¥Æ¥­¥¹¥È¥Ð¥Ã¥Õ¥¡¤¬¾¯¤Ê²á¤®¤Þ¤¹¡£\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "%s ¤Î key fingerprint ¤Ï¼¡¤ÎÄ̤ê¤Ç¤¹¡£: %s \n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "%s ¤Î fingerprints ¤¬°ìÃפ·¤Þ¤·¤¿¡£\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "%s ¤Î fingerprints ¤¬°ìÃפ·¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "·Ù¹ð : ¥µ¡¼¥Ð¾ÚÌÀ½ñ¸¡¾Ú: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "ÉÔÌÀ¤Êȯ¹Ô¼Ô (¤Ï¤¸¤á¤Î %d ʸ»ú): %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "¥Õ¥¡¥¤¥ë¼±Ê̻Ҥ¬ SSL ¤È¤·¤Æ¤ÏĹ²á¤®¤Þ¤¹¡£"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr ""
+"̵¸ú¤Ê SSL ¥×¥í¥È¥³¥ë `%s' ¤¬»ØÄꤵ¤ì¤¿¤¿¤á¡¢¥Ç¥Õ¥©¥ë¥È (SSLv23)¤òÍøÍѤ·¤Þ"
+"¤¹¡£\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr "¾ÚÌÀ½ñ/fingerprint ¸¡¾Ú¤¬´ö¤Ä¤«Èô¤Ð¤µ¤ì¤Þ¤·¤¿¡£\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr ""
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr ""
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s ¤ò¥í¡¼¥«¥ë¤Î %s ¤ËÃÖ´¹¤·¤Þ¤·¤¿¡£\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "%s ¤È %s ¤¬°ìÃפ·¤Þ¤·¤¿¡£\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"Receive ¹Ô¤ò²òÀÏÃæ¤Ç¤¹:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "¹Ô¤¬¼õÎΤµ¤ì¤Þ¤·¤¿¡£%s ¤Ï¥á¡¼¥ë¥µ¡¼¥Ð¤ÎÊÌ̾¤Ç¤¹¡£\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "¹Ô¤¬µñÀ䤵¤ì¤Þ¤·¤¿¡£%s ¤Ï¥á¡¼¥ë¥µ¡¼¥Ð¤ÎÊÌ̾¤Ç¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "Received ¤Î¥¢¥É¥ì¥¹¤¬¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "Received ¤Î¥¢¥É¥ì¥¹¤Ï `%s' ¤Ç¤¹¡£\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "¥Ø¥Ã¥À¤ò²òÀÏÃæ¤Ë¥á¥Ã¥»¡¼¥¸¤¬½ªÎ»¤·¤Æ¤·¤Þ¤¤¤Þ¤·¤¿\n"
+
+#: transact.c:552
+#, fuzzy
+msgid "incorrect header line found while scanning headers\n"
+msgstr "¥Ø¥Ã¥À¤ò²òÀÏÃæ¤Ë¥á¥Ã¥»¡¼¥¸¤¬½ªÎ»¤·¤Æ¤·¤Þ¤¤¤Þ¤·¤¿\n"
+
+#: transact.c:554
+#, fuzzy, c-format
+msgid "line: %s"
+msgstr "%s ¤Ë¥¢¥¯¥»¥¹¤·¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "%s ¤È¤¤¤¦Å¾Á÷Àè¤Ë³ºÅö¤¹¤ë¤â¤Î¤¬¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "DNS ¤ÎÉÔÄ´¤ÇžÁ÷¤Èºï½ü¤¬½ÐÍè¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "RFC822 msgblk.headers ¤ò½ñ¤­¹þ¤ó¤Ç¤¤¤Þ¤¹¡£\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "¤³¤Á¤é¤ÇÀë¸À¤µ¤ì¤¿¥¢¥É¥ì¥¹¤È¼õ¼è¼ê¤Î¥¢¥É¥ì¥¹¤¬°ìÃפ·¤Þ¤»¤ó¤Ç¤·¤¿¡£"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "¼õ¼è¼ê¤Î¥¢¥É¥ì¥¹ %s ¤Ë³ºÅö¤¹¤ëʪ¤¬¤¢¤ê¤Þ¤»¤ó¡£"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "¥á¥Ã¥»¡¼¥¸¤Ë NUL ¤¬´Þ¤Þ¤ì¤Æ¤¤¤Þ¤¹"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "SMTP ¼õ¿®¥×¥í¥°¥é¥à¤¬¼¡¤Î¥¢¥É¥ì¥¹¤Î¼õ¿®¤òµñÈݤ·¤Þ¤·¤¿ : "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "¥á¥Ã¥»¡¼¥¸¤ò½ñ¤­¹þ¤ó¤Ç¤¤¤Þ¤¹\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "¥µ¡¼¥Ð %s ¤«¤é¤Î¸Å¤¤ UID ¥ê¥¹¥È :"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <¤¢¤ê¤Þ¤»¤ó>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "UID ¤Î¥¹¥¯¥é¥Ã¥Á¥ê¥¹¥È :"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, fuzzy, c-format
+msgid "Merged UID list from %s:"
+msgstr "¥µ¡¼¥Ð %s ¤«¤é¤Î¸Å¤¤ UID ¥ê¥¹¥È :"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "¥µ¡¼¥Ð %s ¤«¤é¤Î¿·¤¿¤Ê UID ¥ê¥¹¥È :"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "UID ¥ê¥¹¥È¤ò¸ò´¹¤·¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr "UID ¥ê¥¹¥È¤ò¸ò´¹¤·¤Þ¤»¤ó¡£¤³¤Î¸ò¿®¤ËÂФ¹¤ë UID ¤Ï¤¢¤ê¤Þ¤»¤ó¡£\n"
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "UID ¥ê¥¹¥È¤ò¸ò´¹¤·¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "fetchids ¥Õ¥¡¥¤¥ë¤òºï½ü¤·¤Æ¤¤¤Þ¤¹¡£\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "fetchids ¥Õ¥¡¥¤¥ë¤ò½ñ¤­¹þ¤ßÃæ¤Ç¤¹¡£\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "malloc ¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "realloc ¤Ç¤­¤Þ¤»¤ó¤Ç¤·¤¿¡£\n"
diff --git a/po/pl.gmo b/po/pl.gmo
new file mode 100644
index 00000000..8b512f1f
--- /dev/null
+++ b/po/pl.gmo
diff --git a/po/pl.po b/po/pl.po
new file mode 100644
index 00000000..9f515de0
--- /dev/null
+++ b/po/pl.po
@@ -0,0 +1,2858 @@
+# Copyright (C) 1998 Free Software Foundation, Inc.
+# Pawe³ Krawczyk <kravietz@ceti.com.pl>, 1998.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail-4.7.7\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 1999-02-09 17:46+01:00\n"
+"Last-Translator: Pawe³ Krawczyk <kravietz@ceti.com.pl>\n"
+"Language-Team: Polish <pl@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=iso-8859-2\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Sprawdzam, czy %s jest tym samym hostem co %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Tak, ich adresy IP s± takie same\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Nie, ich adresy IP ró¿ni± siê\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr "b³±d serwera nazw przy szukaniu `%s' podczas ³±czenia z %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "rozkodowanie pocz±tkuj±cego wyzwania BASE64 by³o niemo¿liwe\n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "rozkodowany jako %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "b³±d Kerberosa: %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [serwer odpowiedzia³ '%*s'] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+
+#: driver.c:354
+#, fuzzy, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\tlist %d o d³ugo¶ci %d zosta³ pominiêty.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "pomijam list %d (%d bajtów)\n"
+
+#: driver.c:549
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "pomijam list %d (%d bajtów)\n"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr ""
+
+#: driver.c:568
+#, fuzzy
+msgid " (oversized)"
+msgstr " (za du¿y, %d bajtów)\n"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr ""
+
+#: driver.c:600
+#, fuzzy, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "pobieram %d list z %d"
+
+# budowanie komunikatu z pojedynczych slow - uwaga
+# na spacje i odmiane -PK
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d bajtów %s)"
+
+#: driver.c:606
+msgid "header "
+msgstr "nag³ówka"
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d bajtów tre¶ci)"
+
+#: driver.c:736
+#, fuzzy, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"d³ugo¶æ listu %d nie odpowiada d³ugo¶ci zg³oszonej przez serwer (%d != %d)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " zachowany\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " skasowany\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " nie zosta³ skasowany\n"
+
+#: driver.c:809
+#, fuzzy, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr "limit pobranych listów zosta³ osi±gniêty: %d pozosta³o na serwerze\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr ""
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+"limit czasu %d sekund przekroczony podczas oczekiwania na po³±czenie z %s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "limit czasu %d sekund przekroczony podczas oczekiwania na serwer %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "limit czasu %d sekund przekroczony podczas oczekiwania na %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr "przekroczony czas oczekiwania na odpowied¼ po %d sekundach.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "przekroczony czas oczekiwania po %d sekundach.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr ""
+"Subject: fetchmail zg³asza wielokrotne przekroczenie czasu oczekiwania\n"
+
+#: driver.c:906
+#, fuzzy, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr "Po %d timeoutach fetchmail nie móg³ pobraæ poczty z %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"To mo¿e oznaczaæ, ¿e serwer pocztowy jest zablokowany, albo serwer\n"
+"SMTP jest zakleszczony, albo skrzynka na serwerze jest uszkodzona\n"
+"z powodu b³êdu serwera. Uruchomienie `fetchmail -v -v' pozwoli\n"
+"zdiagnozowaæ problem.\n"
+"\n"
+"Fetchmail nie bêdzie sprawdza³ tej skrzynki do czasu restartu.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "polecenie do uruchomienia przed po³±czeniem wysz³o z b³êdem %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "nie mogê znale¼æ skrzynki HESIOD dla %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr ""
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "nie mogê znale¼æ kanonicznej nazwy %s\n"
+
+#: driver.c:1053
+#, fuzzy
+msgid "internal inconsistency\n"
+msgstr "fetchmail: niezgodno¶æ danych wewnêtrznych\n"
+
+#: driver.c:1063
+#, fuzzy, c-format
+msgid "%s connection to %s failed"
+msgstr "po³±czenie %cMTP z %s nie powiod³o siê\n"
+
+#: driver.c:1069
+#, fuzzy
+msgid "host is unknown."
+msgstr ": nieznany host\n"
+
+#: driver.c:1072
+#, fuzzy
+msgid "name is valid but has no IP address."
+msgstr "nazwa istnieje, ale nie posiada adresu IP\n"
+
+#: driver.c:1075
+#, fuzzy
+msgid "unrecoverable name server error."
+msgstr ": b³±d serwera DNS uniemo¿liwiajacy dalsz± pracê\n"
+
+#: driver.c:1077
+#, fuzzy
+msgid "temporary name server error."
+msgstr "chwilowy problem z serwerem DNS\n"
+
+#: driver.c:1084
+#, fuzzy, c-format
+msgid "unknown DNS error %d."
+msgstr ": nieznany b³±d %d serwera DNS\n"
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+#, fuzzy
+msgid "SSL connection failed.\n"
+msgstr "po³±czenie SSL nie powiod³o siê."
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "B³±d blokady pliku dla %s@%s\n"
+
+#: driver.c:1188
+#, fuzzy, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "B³±d blokady pliku dla %s@%s\n"
+
+#: driver.c:1193
+#, fuzzy, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "B³±d autoryzacji dla %s@%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr ""
+
+#: driver.c:1217
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: b³±d autoryzacji fetchmaila\n"
+
+#: driver.c:1220
+#, fuzzy, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail nie móg³ pobraæ poczty z %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Próba uzyskania autoryzacji nie powiod³a siê.\n"
+"Poniewa¿ wcze¶niej autoryzacja dla tego po³±czenia nie uda³a siê,\n"
+"prawdopodobnie jest to inny rodzaj awarii (typu przeci±¿ony serwer),\n"
+"którego fetchmail nie mo¿e rozró¿niæ, poniewa¿ serwer nie wys³a³\n"
+"przydatnego komunikatu o b³êdzie.\n"
+"\n"
+"Mimo to, je¶li dane o koncie ZOSTA£Y zmienione od uruchomienia demona\n"
+"fetchmaila, trzeba zatrzymaæ demona, zmieniæ konfiguracjê fetchmaila\n"
+"i zrestartowaæ demona.\n"
+"\n"
+"Demon fetchmaila bêdzie nadal próbowa³ siê po³±czyæ w ka¿dym cyklu.\n"
+"Dalsze powiadomienia do czasu odzyskania us³ugi nie bêd± wysy³ane."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr ""
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr ""
+
+#: driver.c:1283
+#, fuzzy, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "B³±d autoryzacji dla %s@%s\n"
+
+#: driver.c:1289
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: b³±d autoryzacji fetchmaila\n"
+
+#: driver.c:1292
+#, fuzzy, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail nie móg³ pobraæ poczty z %s@%s.\n"
+
+#: driver.c:1296
+#, fuzzy
+msgid "Service has been restored.\n"
+msgstr "Wersja RPA %d.%d\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "ponowna próba po³±czenia z folderem %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "ponowna próba po³±czenia z domy¶lnym folderem\n"
+
+#: driver.c:1345
+#, fuzzy, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s na %s (folder %s)\n"
+
+#: driver.c:1353 rcfile_y.y:397
+#, fuzzy, c-format
+msgid "%s at %s"
+msgstr "%s na %s\n"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Próba po³±czenia z %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d przeczytanych) dla %s."
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "listów"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "list"
+
+#: driver.c:1366
+#, fuzzy
+msgid "seen"
+msgstr " "
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s dla %s."
+
+#: driver.c:1375
+#, fuzzy, c-format
+msgid " (%d octets).\n"
+msgstr "(%d bajtów)."
+
+#: driver.c:1381
+#, fuzzy, c-format
+msgid "No mail for %s\n"
+msgstr "Nie ma poczty dla %s"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr ""
+
+#: driver.c:1515
+msgid "socket"
+msgstr "gniazda"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "w nag³ówkach RFC822 (brak lub b³êdne)"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "synchronizacji miêdzy serwerem i klientem"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "protoko³u miêdzy serwerem i klientem"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "plik zablokowany na serwerze"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "transakcja SMTP"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "DNSu"
+
+#: driver.c:1539
+#, fuzzy
+msgid "undefined error\n"
+msgstr "niezdefiniowany\n"
+
+#: driver.c:1550
+#, fuzzy, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "b³±d %s podczas pobierania listów z %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "b³±d %s podczas pobierania listów z %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "polecenie wykonane po pobraniu poczty zwróci³o b³±d %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Obs³uga Kerberosa V4 nie zosta³a do³±czona do programu.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Obs³uga Kerberosa V5 nie zosta³a do³±czona do programu.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Opcja --flush nie dzia³a z %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Opcja --all nie dzia³a za %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Opcja --limit nie dzia³a z %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: Zmienna ¶rodowiskowa QMAILINJECT jest ustawiona.\n"
+"Jest to niebezpieczne, poniewa¿ mo¿e spowodowaæ, ¿e qmail-inject lub "
+"qmailowy\n"
+"zastêpnik sendmaila namiesza z nag³ówkami From: lub Message-ID:.\n"
+"Proszê spróbowaæ \"env QMAILINJECT= %s W£ASNE PARAMETRY\"\n"
+"%s: Przerwano.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: Zmienna ¶rodowiskowa NULLMAILER_FLAGS jest ustawiona.\n"
+"Jest to niebezpieczne, poniewa¿ mo¿e spowodowaæ, ¿e nullmailer-inject lub\n"
+"nullmailerowy zastêpnik sendmaila namiesza z nag³ówkami From:, Message-ID:\n"
+"lub Return-Path:.\n"
+"Proszê spróbowaæ \"env NULLMAILER_FLAGS= %s W£ASNE PARAMETRY\"\n"
+"%s: Przerwano.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Nie istniejesz. Odejd¼.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: nie mogê znale¼æ nazwy twojego hosta!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "gethostbyname zwróci³o b³±d dla %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "serwer SMTP na %s nie obs³uguje protoko³u ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "serwer SMTP na %s nie obs³uguje polecenia ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Kolejkowanie dla %s rozpoczête\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Brak listów dla %s oczekuj±cych w kolejce\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Wysy³anie oczekuj±cych listów dla %s rozpoczête\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Kolejkowanie listów dla %s nie jest mo¿liwe\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Brak dostêpu dla hosta %s: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "B³±d sk³adniowy ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "B³±d sk³adniowy ETRN w parametrach\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Nieznany b³±d ETRN %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "Opcja --keep nie dzia³a z ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "Opcja --flush nie dzia³a z ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "Opcja --remote nie dzia³a z ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "Opcja --check nie dzia³a z ETRN\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: uruchomiony z"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "nie mo¿na uzyskaæ bie¿±cego katalogu\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Tu fetchmail, wersja %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Pobieram opcje z linii poleceñ%s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " i "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "Brak skonfigurowany serwerów pocztowych -- mo¿e brakuje %s?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: nie podano ¿adnych serwerów pocztowych.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: nie dzia³a ¿aden inny proces fetchmaila\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: wyst±pi³ b³±d podczas próby ubicia %s fetchmaila, PID %d.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "dzia³aj±cego w tle"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "dzia³aj±cego na konsoli"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %s fetchmail o numerze procesu %d zosta³ ubity.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: nie mogê sprawdziæ poczty, bo dzia³a inny fetchmail do tego "
+"serwera\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: nie mogê po³±czyæ siê z podanym hostem, bo dzia³a inny fetchmail "
+"(proces %d).\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: dzia³a inny chodz±cy z konsoli fetchmail (proces %d).\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: nie mogê przyjmowaæ opcji, poniewa¿ inny fetchmail dzia³a ju¿ w "
+"tle.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: chodz±cy w tle fetchmail (proces %d) zosta³ uaktywniony.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr ""
+"fetchmail: starszy proces %d zgin±³ w niewyja¶nionych okoliczno¶ciach.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: nie mo¿na znale¼æ has³a dla %s@%s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Podaj has³o dla %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "startuje fetchmail %s w trybie demona\n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "nie mo¿na otworzyæ %s w celu do³±czania logów \n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "nie mo¿na sprawdziæ czasu %s (b³±d %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "restart fetchmaila (zmieniono %s)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+"próba restartu mo¿e siê nie udaæ, poniewa¿ katalog nie zosta³ odtworzony\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "próba ponownego uruchomienia fetchmaila nie powiod³a siê\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr "po³±czenie z %s pominiête (b³êdy autoryzacji lub timeouty)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "fetchmail: nie nadszed³ jeszcze czas na po³±czenie z %s\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Wynik zapytania=0 (SUKCES)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Wynik zapytania=1 (BRAK POCZTY)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Wynik zapytania=2 (GNIAZDO)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Wynik zapytania=3 (B£¡D AUTORYZACJI)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Wynik zapytania=4 (PROTOKÓ£)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Wynik zapytania=5 (SK£ADNIA)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "Wynik zapytania=6 (B£¡D IO)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "Wynik zapytania=7 (B£¡D)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Wynik zapytania=8 (WY£¡CZENIE)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Wynik zapytania=9 (BLOKADA)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "Wynik zapytania=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "Wynik zapytania=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Wynik zapytania=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Wynik zapytania=13 (MAKSIMUM POBRANO)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Wynik zapytania=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Nie mogê pobraæ poczty z ¿adnego serwera. Koñczê pracê.\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "usypiam o godzinie %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "uaktywniony przez %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "uaktywniony przez sygna³ %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "uaktywniony o %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "praca zakoñczona poprawnie, kod wyj¶cia %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "nie mo¿na sprawdziæ czasu pliku kontroli uruchomienia\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr "Uwaga: host %s wystêpuje wielokrotnie w pliku konfiguracyjnym\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "obs³uga SSL nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr "fetchmail: uwaga: brak serwera DNS potrzebnego do sprawdzenia %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "konfiguracja dla %s jest b³êdna - numer portu nie mo¿e byæ ujemny\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr ""
+"konfiguracja dla %s jest b³êdna - RPOP wymaga uprzywilejowanego portu "
+"(<1024)\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"konfiguracja dla %s jest b³êdna - LMTP nie u¿ywa domy¶lnego portu SMTP\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "Jednoczesne fetchall i keep w trybie demona to b³±d!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "przerwany sygna³em %d\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr ""
+"%s ³±czy siê z %s (protokó³ %s) o godzinie %s: odpytywanie rozpoczête\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "obs³uga protoko³u POP2 nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "obs³uga protoko³u POP3 nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "obs³uga protoko³u IMAP nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "obs³uga polecenia ETRN nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "Obs³uga polecenia ETRN bez gethostbyname(2) jest niemo¿liwa.\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "obs³uga protoko³u ODMR nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "Obs³uga polecenia ODMR bez gethostbyname(2) jest niemo¿liwa.\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "Wybrany protokó³ nie jest obs³ugiwany przez fetchmaila.\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr ""
+"%s ³±czy siê z %s (protokó³ %s) o godzinie %s: odpytywanie zakoñczone\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "Czas miêdzy sprawdzaniem skrzynek wynosi %d sekund\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Plik diagnostyczny to %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Plik identyfikacyjny to %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Komunikaty o postêpach po³±czenia bêd± zg³aszane przez sysloga\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail bêdzie siê ukrywa³ i nie wygeneruje nag³ówka Received\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr "Fetchmail bêdzie pokazywa³ znaki postêpu nawet w plikach logów.\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr "Fetchmail wy¶le ¼le zaadresowane listy do %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Fetchmail przekieruje pocztê z b³êdami do postmastera.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail przekieruje pocztê z b³êdami do nadawcy.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Parametry pobierania poczty ze skrzynki %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Poczta bêdzie pobierana przez %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "Po³±czenie z tym serwerem odbêdzie siê co %d okresów.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Prawdziwa nazwa serwera to %s.\n"
+
+# budowanie zdania ze s³ów, uwaga -PK
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr ""
+"  Z tym serwerem%sbêdê siê ³±czy³ je¶li nie zostanie podany ¿aden inny "
+"serwer.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr " nie "
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr " "
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Bêdê pyta³ o has³o.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  Has³o APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  U¿ytkownik RPOP = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Has³o = \"%s\".\n"
+
+# %s zawiera numer wersji protoko³u -PK
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  U¿ywam protoko³u KPOP z uwierzytelnieniem przez Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  U¿ywam protoko³u %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (us³uga %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (opcje bezpieczeñstwa %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (po³±czenie na port %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (po³±czenie na domy¶lny port)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (bêd± stosowane UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  Bêd± próbowane wszystkie dostêpne metody uwierzytelnienia.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  Zostanie wymuszone uwierzytelnienie przy pomocy has³a.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  Zostanie wymuszone uwierzytelnienie NTLM.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  Zostanie wymuszone uwierzytelnienie OTP.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  Zostanie wymuszone uwierzytelnienie CRAM-Md5.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  Zostanie wymuszone uwierzytelnienie GSSAPI.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Zostanie wymuszone uwierzytelnienie Kerberos V4.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Zostanie wymuszone uwierzytelnienie Kerberos V5.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  Zak³adam szyfrowanie end-to-end.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  Zarz±dc± us³ugi pocztowej jest: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  Sesje kodowane SSL w³±czone.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  Protokó³ SSL: %s.\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  Sprawdzanie certyfikatu SSL serwera w³±czone.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  Katalog zaufanego certyfikatu SSL: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr "  Odcisk klucza SSL (sprawdzony z kluczem serwera): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  Limit czasu na odpowied¼ serwera wynosi %d sekund"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (domy¶lne).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Wybrana jest domy¶lna skrzynka odbiorcza.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Wybrano nastêpuj±ce skrzynki:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  Zostan± pobrane %s listy (%s --all).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "wszystkie"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "tylko nowe"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Pobrane listy%sbêd± pozostawione na serwerze (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr "  Stare listy%sbêd± kasowane przed pobraniem poczty (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  Przepisywanie adresów na postaæ lokaln± jest %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "w³±czone"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "wy³±czone"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  Usuwanie znaków CR z koñców linii jest %s (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Dodawanie znaków CR na koñcach linii jest %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+"  Interpretowanie nag³ówka Content-Transfer-Encoding jest %s (pass8bits %"
+"s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  Dekodowanie MIME jest %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  Zw³oka po odpytaniu wynosi %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Niepuste nag³ówki Status bêd± %s (dropstatus %s).\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "kasowane"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "pozostawiane"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Linie Delivered-To bêd± %s (dropdelivered %s).\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  Limit wielko¶ci listu wynosi %d bajtów (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  Limit wielko¶ci listu nie jest ustawiony (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  Ostrze¿enia o wielko¶ci listu bêd± wy¶wietlane co %d sekund (--warnings %"
+"d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+"  Ostrze¿enia o wielko¶ci bêd± wy¶wietlane przy ka¿dym ³±czeniu (--warnings "
+"0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  Limit ilo¶ci otrzymanych listów wynosi %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr ""
+"  Limit ilo¶ci otrzymanych listów nie jest ustawiony (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  Limit wielko¶ci listu wynosi %d (--fetchsizelimit %d).\n"
+
+#: fetchmail.c:1650
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Limit wielko¶ci listu nie jest ustawiony (--fetchsizelimit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr "  Binarne przeszukiwanie UID-ów przy ka¿dym ¶ci±ganiu (--fastuidl 1).\n"
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr "  Binarne przeszukiwanie UID-ów przy %d z %d ¶ci±gañ (--fastuidl %d).\n"
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr "   Liniowe przeszukiwanie UID-ów przy ka¿dym ¶ci±ganiu (--fastuidl 0).\n"
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  Listy bêd± wysy³ane przez SMTP w grupach po %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr ""
+"  Limit ilo¶ci listów wysy³anych przez SMTP nie ustawiony (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr "  Odstêp miêdzy kasowaniem listów wymuszony na %d (--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Listy nie bêd± kasowane (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Domeny dla których poczta bêdzie ¶ci±gana to:"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (domy¶ny)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Listy bêd± dopisywane do %s jako BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Listy bêd± lokalne dorêczane przy u¿yciu \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Listy bêd± przes³ane przy pomocy %cMTP do:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  Nazwa hosta w MAIL FROM jest ustawiona na %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr ""
+"  Adresem do umieszczenia w liniach RCPT TO przekazanych SMTP bêdzie %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Rozpoznawane odpowiedzi blokad antyspamowych to:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Blokowanie spamu wy³±czone\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  Po³±czenie do serwera zostanie nawi±zane przy pomocy \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Przed po³±czeniem nie bêdzie wykonywane ¿adne dodatkowe polecenie.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  Po³±czenie z serwerem zostanie zamkniête przy pomocy \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr ""
+"  Po zamkniêciu po³±czenia nie bêdzie wykonywane ¿adne dodatkowe polecenie.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Brak nazw lokalnych ustawionych dla tego hosta.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Tryb wielu skrzynek: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Tryb jednej skrzynki: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d znanych nazw lokalnych.\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  DNS dla adresów wieloskrzynkowych to %s.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr "  Aliasy serwera bêd± porównywane z adresami skrzynek po "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "adresach IP.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "nazwie.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  Obs³uga poczty wed³ug adresów w kopercie jest wy³±czone\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Nag³ówek koperty zosta³ ustawiony na: %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Received"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Liczba nag³ówków koperty, które bêd± sprawdzane: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Przedrostek %s bêdzie usuwany z nazwy u¿ytkownika\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  ¯adne przedrostki nie bêd± usuwane\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Zadeklarowane aliasy serwera pocztowego:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Domeny lokalne:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  Po³±czenia bêd± nawi±zywane tylko przez interfejs %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Nie jest okre¶lony ¿aden obowi±zkowy interfejs.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Podczas prób po³±czenia w pêtli bêdzie monitorowany %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  ¯aden interfejs nie bêdzie monitorowany.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr ""
+"  Po³±czenia z serwerem bêd± nawi±zywane przez wtyczkê %s (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Nie jest skonfigurowane ¿adne polecenie nawi±zuj±ce po³±czenie\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  Po³±czenie z serwerem odbiorcy zostanie nawi±zane programem %s (--plugout %"
+"s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Nie jest skonfigurowane ¿adne polecenie zamykaj±ce po³±czenie.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  ¯adne UID-y nie zosta³y zachowane z sesji z tym hostem.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  Zachowano %d UID-ów.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+"  Informacje o ¶ledzeniu po³±czenia bêd± dodane do nag³ówka Received.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  Informacje o ¶ledzeniu po³±czenia nie bêd± dodane do nag³ówka Received.\n"
+".\n"
+
+# XXX -PK
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  W³asno¶ci przepuszczania \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "b³±d alloca"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "B£¡D; brak obs³ugi funkcji getpassword()\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"Dosta³em sygna³ SIGINT... koñczê pracê.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Uzyskanie nazwy us³ugi dla [%s] jest niemo¿liwe\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "U¿ywam nazwy us³ugi [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Wysy³am uwierzytelnienie\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Wyst±pi³ b³±d podczas wymiany uprawnieñ\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Nie mogê rozwin±æ danych poziomu bezpieczeñstwa\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Wymiana uprawnieñ zosta³a zakoñczona\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Serwer wymaga zapewnionej integralno¶ci i/lub prywatno¶ci\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Rozwiniête flagi poziomu bezpieczeñstwa: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "Maksymalny rozmiar symbolu GSS to %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Wyst±pi³ b³±d podczas budowania zapytania o poziom bezpieczeñstwa\n"
+
+# XXX tak samo, wierzytelnosci -PK
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Zwalniam uprawnienia GSS\n"
+
+# XXX
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Wyst±pi³ b³±d podczas zwalniania uprawnieñ\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: usypiam na %d sekund.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protokó³ rozpoznany jako IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protokó³ rozpoznany jako IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protokó³ rozpoznany jako IMAP2 lub IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "przejdzie w stan bezczynno¶ci po odpytaniu\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "Wymagana metoda uwierzytelnienia OTP nie wkompilowana w fetchmaila\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Wymagana metoda uwierzytelnienia NTLM nie wkompilowana w fetchmaila\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Serwer nie obs³uguje wymaganej metody uwierzytelnienia LOGIN\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "usuwanie nie powiod³o siê\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "ponowne po³±czenie nie powiod³o siê\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "%d listów oczekuj±cych po ponownym pobraniu\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "wybór skrzynki zakoñczy³ siê niepowodzeniem\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "%d listów oczekuj±cych po pierwszym pobraniu\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "%d listów oczekuj±cych po usuwaniu\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "poszukiwanie nie przeczytanych listów nie powiod³o siê\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u jest nie przeczytany\n"
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr "%u jest pierwszym nie przeczytanym\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"Nie mo¿na otworzyæ interfejsu kvm. Byæ mo¿e fetchmail nie jest SGID kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "Nie mo¿na odczytaæ nazwy interfejsu z %s"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: sysctl (iflist estimate) nie powiód³ siê"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: b³±d malloc"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: sysctl (iflist) nie powiód³ siê"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "Wiadomo¶æ przekierowuj±ca w wersji %d nie zrozumiana."
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "Nie znaleziono interfejsu o nazwie %s"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "Nie znaleziono adresu IP dla %s"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "interfejs nie ma ustawionego adresu IP\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "interfejs ma ustawiony b³êdny adres IP\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "interfejs ma ustawion± b³êdn± maskê sieci\n"
+
+# XXX -PK
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "ruch na %s zauwa¿ony jako %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "pomijam po³±czenie z %s, %s nie jest podniesiony\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "pomijam po³±czenie z %s, adres IP %s nie jest na li¶cie\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "ruch na %s sprawdzany jako %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "pomijam po³±czenie z %s, %s nie jest aktywny\n"
+
+# XXX -PK
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "ruch na %s by³ %d, jest %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "rozkodowanie pocz±tkuj±cego wyzwania BASE64 by³o niemo¿liwe\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "u¿ytkownik %s w bilecie nie pasuje do -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "niezerowy obiekt (%s) mo¿e mieæ nieprzewidywalne efekty\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "odkodowanie odpowiedzi BASE64 jest niemo¿liwe\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "niezgodno¶æ wyzwania\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: usuwam niewa¿ny plik blokady\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: tworzenie blokady nie powiod³o siê.\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "uwaga: przed ka¿d± nazw± hosta wystêpuje \"%s\""
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: uwaga: przed ka¿d± nazw± hosta wystêpuje \"%s\"\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: uwaga: nieznany symbol \"%s\"\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "serwer SMTP na %s nie obs³uguje polecenia ATRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "Prze³±czanie...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "¯±danie ATRN odrzucone.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "Nie mo¿na teraz obs³u¿yæ ¿±dania ATRN\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "Nie ma poczty.\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Polecenie nie zaimplementowane\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Wymagane uwierzytelnienie.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Nieznany b³±d ODMR %d\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "Opcja --keep nie dzia³a z ODMR\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "Opcja --flush nie dzia³a z ODMR\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "Opcja --remote nie dzia³a z ODMR\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "Opcja --check nie dzia³a z ODMR\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "recv z serwera nie powiod³o siê\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Rozkodowanie wyzwania OTP by³o niemo¿liwe\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Tajne has³o: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "Napis '%s' nie reprezentuje poprawnie zapisanej liczby.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "Warto¶æ napisu '%s' jest %s ni¿ %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "mniejsza"
+
+#: options.c:211
+msgid "larger"
+msgstr "wiêksza"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Podano b³êdny protokó³ `%s'.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Podano b³êdn± metodê uwierzytelnienia `%s'.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: obs³uga funkcji bezpieczeñstwa sieciowego jest wy³±czona\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "sk³adnia:  fetchmail [opcje] [serwer ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Mo¿na podaæ nastêpuj±ce opcje:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        wy¶wietla ten opis opcji\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     wy¶wietla informacje o wersji\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       sprawdza czy s± nowe listy bez ich pobierania\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      wy³±cza komunikaty\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     w³±cza wy¶wietlanie szczegó³owych komunikatów\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      w³±cza uruchamianie w trybie demona co n sekund\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    wy³±cza pracê w tle w trybie demona\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        koñczy pracê demona\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     podaje nazwê pliku kroniki\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      w³±cza wy¶wietlanie wiêkszo¶ci komunikatów przez syslog"
+"(3)\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   w³±cza udawanie hosta i nie dodaje nag³ówków Received\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc okre¶la alternatywny plik konfiguracyjny\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      okre¶la alternatywny plik z UID-ami\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  adres na który bêd± wysy³ane b³êdne listy\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr "      --nobounce    przekierowuje odbit± pocztê do postmastera.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   wymagana nazwa interfejsu\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     monitoruje dany interfejs czekaj±c na ruch\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         w³±cza sesje kodowane ssl\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      plik klucza prywatnego ssl\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     certyfikat klienta ssl\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      --sslproto    wymusza protokó³ ssl (ssl2/ssl3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+"      --plugin      ¶cie¿ka do zewnêtrznego polecenia otwieraj±cego "
+"po³±czenie\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     ¶cie¿ka do zewn. polecenia otwieraj±cego po³±czenie "
+"smtp\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    okre¶la protokó³ którym bêd± pobierane listy (patrz "
+"manual)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        wymusza u¿ywanie UIDL (tylko POP3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        okre¶la port TCP/IP na który nale¿y siê ³±czyæ\n"
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr ""
+"      --auth        okre¶la metodê uwierzytelnienia (has³o/Kerberos/ssh/"
+"otp)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     limit czasu oczekiwania na odpowied¼ serwera\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr ""
+"  -E, --envelope    okre¶la nazwê nag³ówka zawieraj±cego adres z koperty\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+"  -Q, --qvirtual    przedrostek, który bêdzie usuwany z nazwy u¿ytkownika\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   zarz±dca us³ugi pocztowej\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+"      --tracepolls  dodaje informacje o ¶ledzeniu po³±czenia do Received\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    okre¶la login u¿ytkownika na serwerze\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         pobiera wszystkie listy, stare i nowe\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      kasuje nowe listy po pobraniu\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        po pobraniu pozostawia nowe listy na serwerze\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       kasuje stare listy z serwera\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   nie przepisuje adresów w nag³ówkach\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -l, --limit       nie pobiera listów wiêkszych ni¿ podany rozmiar\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    czas miêdzy powiadomieniami o poczcie\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      okre¶la funkcjê bezpieczeñstwa IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr ""
+"  -S, --smtphost    okre¶la nazwê hosta SMTP przesy³aj±cego nasze listy\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr "      --fetchdomains pobiera pocztê dla podanych domen\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr ""
+"  -D, --smtpaddress okre¶la nazwê domeny SMTP u¿ywan± przy dorêczaniu "
+"poczty\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr "      --smtpname    ustawia pe³n± nazwê SMTP username@domain\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    okre¶la odpowiedzi blokad antyspamowych\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+"  -b, --batchlimit  okre¶la limit listów wys³anych w jednym po³±czeniu SMTP\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  okre¶la limit listów pobieranych w jednym po³±czeniu\n"
+
+#: options.c:720
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr "      --fetchsizelimit ustawia limit wielko¶ci ¶ci±ganego listu\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr "      --fastuidl    wykonuje binarne poszukiwanie UIDL-i\n"
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+"  -e, --expunge     liczba skasowanych listów miêdzy czyszczeniem skrzynki\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr ""
+"  -m, --mda         okre¶la ¶cie¿kê do MDA dorêczaj±cego pobrane listy\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       okre¶la nazwê wynikowego pliku BSMTP\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        u¿ywa LMTP (RFC2033) do dorêczania poczty\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      okre¶la nazwê skrzynki na serwerze\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+"      --showdots    pokazuje kropki oznaczaj±ce postêp tak¿e w logach\n"
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "W powitaniu serwera brakuje wymaganego znacznika czasu APOP\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "B³±d sk³adni znacznika czasu w powitaniu\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Pro¶ba o nieznany protokó³ w POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "plik zablokowany! Czy inna sesja nie jest aktywna?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr "id=%s (num=%d) zosta³ skasowany, ale nadal istnieje!\n"
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr ""
+"Przesy³ki zosta³y dodane do listy na serwerze. Nie mogê tego obs³u¿yæ.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "b³±d protoko³u\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "b³±d protoko³u podczas pobierania UIDL\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "Opcja --remote nie dzia³a z POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "opcja serwera po opcjach u¿ytkownika"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "SDPS nie w³±czone."
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "b³êdne zapytanie o poziom bezpieczeñstwa"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "obs³uga funkcji bezpieczeñstwa sieciowego jest wy³±czona"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: opcja interface jest obs³ugiwana tylko pod Linuksem (bez IPv6) i "
+"FreeBSD\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: opcja monitor jest obs³ugiwana tylko pod Linuksem (bez IPv6) i "
+"FreeBSD\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "SSL nie jest w³±czone."
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "koniec wej¶cia"
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "Plik %s musi byæ zwyk³ym plikiem.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "Plik %s nie mo¿e mieæ uprawnieñ wiêkszych ni¿ -rwx--x--- (0710).\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "Plik %s musi byæ w³asno¶ci± u¿ytkownika.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Nieznany b³±d systemu"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (tworzenie listy informacyjnego nie zosta³o zakoñczone)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "przepe³nienie bufora podczas tworzenia czê¶ci komunikatu o b³êdzie"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "Rozpoczêcie przepisywania %s"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "Przepisana wersja to %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Sukces"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Zablokowany u¿ytkownik (co¶ nie w porz±dku z kontem)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "B³êdny identyfikator u¿ytkownika lub has³o"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "B³±d bosko¶ci"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "Token 2 RPA: b³±d dekodowania Base64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Wersja RPA %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Has³o do us³ugi (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Datownik us³ugi %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "Token 2 RPA b³±d d³ugo¶ci\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Lista dziedzin: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "RPA: b³±d w napisie us³uga@dziedzina\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA symbol 4: b³±d podczas dekodowania Base64\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Uwierzytelnienie u¿ytkownika (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "Stan RPA: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "RPA: b³±d d³ugo¶ci symbolu 4\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA odrzuci³o u¿ytkownika: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA odrzuci³o u¿ytkownika bez podania przyczyny\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "RPA: b³±d d³ugo¶ci uwierzytelnienia u¿ytkownika: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "RPA: b³±d d³ugo¶ci klucza sesyjnego: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "RPA: b³±d uwierzytelnienia _us³ugi_. Kto¶ podszywa siê pod serwer?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Uzgodniony klucz sesyjny:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "Autoryzacja RPA zakoñczona\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Oczekiwanie na odpowied¼\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Oczekiwanie na odpowied¼ zakoñczone z wynikiem %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "D³ugo¶æ nag³ówka nie wynosi 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "B³±d d³ugo¶ci symbolu\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "D³ugo¶æ symbolu %d nie pasuje do rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "B³êdne pole mechanizmu\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "b³±d dec64 na znaku %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Przychodz±ce dane binarne:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Wychodz±ce dane binarne:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "RPA: za d³ugi napis\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA: otwarcie /dev/urandom jest niemo¿liwe. Nie uniemo¿liwia\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    to zalogowania siê, ale oznacza ¿e nie mo¿esz\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    byæ pewien, ¿e po³±czy³e¶ siê z w³a¶ciw± us³ug±\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    (mo¿liwy jest atak przez odtwarzanie\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "     nieuczciwej us³ugi.)\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Wyzwanie u¿ytkownika:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "MD5 zastosowany do bloku danych:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "Wynik MD5: \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "przesy³anie do %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: (cia³o odbitego listu)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "poczta od %s odbita do %s\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "Zachowany b³±d to nadal %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "b³±d %cMTP: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "BSMTP: otwarcie pliku lub zapis nag³ówka nie powiód³ siê\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "demon %cMTP nie lubi adresu odbiorcy `%s'\n"
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "demon %cMTP naprawdê nie lubi adresu odbiorcy `%s'\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "brak pasuj±cych adresów; postmaster nie ustawiony.\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "nie mogê wys³aæ poczty nawet do %s!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "brak pasuj±cych lokalnych adresów, przesy³am do %s\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "list zostanie dorêczony przy pomocy: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "b³±d podczas uruchamiania MDA (programu dorêczaj±cego pocztê)\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "po³±czenie %cMTP z %s nie powiod³o siê\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "nie mo¿na podnie¶æ procesu s³uchaj±cego; powrót do %s"
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr "MDA zabity przez sygna³ %d\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "MDA zwróci³ niezerowy kod b³êdu %d\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr "Dziwne: MDA pclose zwróci³o %d, nie mo¿na obs³u¿yæ w %s:%d\n"
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Zakoñczenie listu lub zamkniêcie pliku BSMTP nie powiod³o siê\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "serwer SMTP odmówi³ dostarczenia listu\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "B³±d podczas dorêczania LMTP w momencie wykonywania komendy EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Niespodziewana odpowied¼ inna ni¿ 503 na LSTMP EOM: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tDemon Fetchmaila\n"
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "Uwierzytelnienie ESMTP CRAM-MD5...\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "Serwer odrzuci³ polecenie AUTH.\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "B³êdna odpowied¼ base64 z serwera.\n"
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "Wywo³anie rozkodowane: %s\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "Uwierzytelnienie ESMTP PLAIN...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "Uwierzytelnienie ESMTP LOGIN...\n"
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr "b³±d protoko³u serwera smtp\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: b³±d malloc\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: b³±d socketpair\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: b³±d fork\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "b³±d dup2\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "uruchamiam %s (host %s us³uga %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "b³±d execvp(%s)\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: otrzyma³em b³êdn± d³ugo¶æ adresu dla hosta %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Organizacja wystawcy: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr "Uwaga: nazwa Organizacji wystawcy za d³uga (prawdopodobnie uciêta).\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "Nieznana organizacja\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "CommonName wystawcy: %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr "Uwaga: CommonName wystawcy za d³ugie (prawdopodobnie uciête).\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "Nieznane CommonName wystawcy\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "CommonName serwera: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "B³êdny certyfikat: za d³ugie CommonName podmiotu!\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "Niezgodno¶æ CommonName serwera: %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr "Nazwa serwera nie ustawiona, nie mo¿na sprawdziæ certyfikatu!\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "Nieznane CommonName serwera\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "Nazwa serwera nie podana w certyfikacie!\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "b³±d EVP_md5()!\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "Brak pamiêci!\n"
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "Bufor skrótu tekstu za ma³y!\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "Odcisk klucza %s: %s\n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "%s odcisków siê zgadza.\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "%s odcisków siê nie zgadza!\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "Uwaga: weryfikacja certyfikatu serwera: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "nieznany wystawca (pierwsze %d znaków): %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Deskryptor pliku poza zakresem dla SSL"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr "Podano b³êdny protokó³ SSL `%s', u¿ywam domy¶lnego (SSLv23).\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr "Weryfikacja certyfikatu/odcisku klucza z jakiego¶ powodu pominiêta!\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr "Powtórzenie odczytu z gniazda cygwinowego\n"
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr "Powtórzenie odczytu z gniazda cygwinowego nie powiod³o siê!\n"
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s zamieniony na lokalny %s\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "przepuszczony przez %s pasuje do %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analizujê nag³ówek Received:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "nag³ówek zosta³ przyjêty, %s jest aliasem serwera pocztowego\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "nag³ówek zosta³ odrzucony, %s nie jest aliasem serwera pocztowego\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "nie znalaz³em adresu Received\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "znalaz³em adres Received `%s'\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "podczas skanowania nag³ówków znaleziono separator listów\n"
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "podczas skanowania nag³ówków znaleziono b³êdn± liniê nag³ówka\n"
+
+#: transact.c:554
+#, c-format
+msgid "line: %s"
+msgstr "linia: %s"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "brak pasuj±cych lokalnych adresów, przesy³am do %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "listy nie zostan± przes³ane i skasowane z powodu b³êdów DNS-u\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "zapisujê RFC822 msgblk.headers\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "¿aden z adresatów nie pasowa³ do nazw lokalnych u¿ytkowników"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "adresat %s nie pasowa³ do ¿adnej nazwy lokalnego u¿ytkownika"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "list zawiera³ znaki NULL"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "demon SMTP odrzuci³ adresy lokalnych odbiorców: '"
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "zapisujê tre¶æ listu\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "Stara lista UID-ów z %s:"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <pusty>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Pocz±tkowa lista UID-ów:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, c-format
+msgid "Merged UID list from %s:"
+msgstr "Po³±czona lista UID-ów z %s:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "Nowa lista UID-ów z %s:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "prze³±czanie list UID-ów\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr "brak prze³±czania list UID-ów, w zapytaniu nie wyst±pi³y UID-y\n"
+
+#: uid.c:575
+msgid "discarding new UID list\n"
+msgstr "odrzucam now± listê UID-ów\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "Kasujê plik fetchids.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "Zapisujê plik fetchids.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "b³±d malloc\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "b³±d realloc\n"
diff --git a/po/pl.po.orig b/po/pl.po.orig
new file mode 100644
index 00000000..553e4ffc
--- /dev/null
+++ b/po/pl.po.orig
@@ -0,0 +1,3005 @@
+# Copyright (C) 1998 Free Software Foundation, Inc.
+# Pawe³ Krawczyk <kravietz@ceti.com.pl>, 1998.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail-4.7.7\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 1999-02-09 17:46+01:00\n"
+"Last-Translator: Pawe³ Krawczyk <kravietz@ceti.com.pl>\n"
+"Language-Team: Polish <pl@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=iso-8859-2\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Sprawdzam, czy %s jest tym samym hostem co %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Tak, ich adresy IP s± takie same\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Nie, ich adresy IP ró¿ni± siê\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr ""
+"wyst±pi³ b³±d serwera DNS - niemo¿liwe znalezienie `%s' podczas ³±czenia z %"
+"s.\n"
+
+#: cram.c:95
+#, fuzzy
+msgid "could not decode BASE64 challenge\n"
+msgstr "rozkodowanie pocz±tkuj±cego wyzwania BASE64 by³o niemo¿liwe\n"
+
+#: cram.c:103
+#, fuzzy, c-format
+msgid "decoded as %s\n"
+msgstr "uaktywniony o %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "b³±d Kerberosa: %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [serwer odpowiedzia³ '%*s'] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+
+#: driver.c:354
+#, fuzzy, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\tlist %d o d³ugo¶ci %d zosta³ pominiêty.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "pomijam list %d (%d bajtów)\n"
+
+#: driver.c:549
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "pomijam list %d (%d bajtów)\n"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr ""
+
+#: driver.c:568
+#, fuzzy
+msgid " (oversized)"
+msgstr " (za du¿y, %d bajtów)\n"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr ""
+
+#: driver.c:600
+#, fuzzy, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "pobieram %d list z %d"
+
+# budowanie komunikatu z pojedynczych slow - uwaga
+# na spacje i odmiane -PK
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d bajtów %s)"
+
+#: driver.c:606
+msgid "header "
+msgstr "nag³ówka"
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d bajtów tre¶ci)"
+
+#: driver.c:736
+#, fuzzy, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"d³ugo¶æ listu %d nie odpowiada d³ugo¶ci zg³oszonej przez serwer (%d != %d)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " zachowany\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " skasowany\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " nie zosta³ skasowany\n"
+
+#: driver.c:809
+#, fuzzy, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr "limit pobranych listów zosta³ osi±gniêty: %d pozosta³o na serwerze\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr ""
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+"limit czasu %d sekund przekroczony podczas oczekiwania na po³±czenie z %s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "limit czasu %d sekund przekroczony podczas oczekiwania na serwer %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "limit czasu %d sekund przekroczony podczas oczekiwania na %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr "przekroczony czas oczekiwania na odpowied¼ po %d sekundach.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "przekroczony czas oczekiwania po %d sekundach.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr ""
+"Subject: fetchmail zg³asza wielokrotne przekroczenie czasu oczekiwania\n"
+
+#: driver.c:906
+#, fuzzy, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr "Po %d timeoutach fetchmail nie móg³ pobraæ poczty z %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "polecenie do uruchomienia przed po³±czeniem wysz³o z b³êdem %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "nie mogê znale¼æ skrzynki HESIOD dla %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr ""
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "nie mogê znale¼æ kanonicznej nazwy %s\n"
+
+#: driver.c:1053
+#, fuzzy
+msgid "internal inconsistency\n"
+msgstr "fetchmail: niezgodno¶æ danych wewnêtrznych\n"
+
+#: driver.c:1063
+#, fuzzy, c-format
+msgid "%s connection to %s failed"
+msgstr "po³±czenie %cMTP z %s nie powiod³o siê\n"
+
+#: driver.c:1069
+#, fuzzy
+msgid "host is unknown."
+msgstr ": nieznany host\n"
+
+#: driver.c:1072
+#, fuzzy
+msgid "name is valid but has no IP address."
+msgstr "nazwa istnieje, ale nie posiada adresu IP\n"
+
+#: driver.c:1075
+#, fuzzy
+msgid "unrecoverable name server error."
+msgstr ": b³±d serwera DNS uniemo¿liwiajacy dalsz± pracê\n"
+
+#: driver.c:1077
+#, fuzzy
+msgid "temporary name server error."
+msgstr "chwilowy problem z serwerem DNS\n"
+
+#: driver.c:1084
+#, fuzzy, c-format
+msgid "unknown DNS error %d."
+msgstr ": nieznany b³±d %d serwera DNS\n"
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+#, fuzzy
+msgid "SSL connection failed.\n"
+msgstr "po³±czenie SSL nie powiod³o siê."
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "B³±d blokady pliku dla %s@%s\n"
+
+#: driver.c:1188
+#, fuzzy, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "B³±d blokady pliku dla %s@%s\n"
+
+#: driver.c:1193
+#, fuzzy, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "B³±d autoryzacji dla %s@%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr ""
+
+#: driver.c:1217
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: b³±d autoryzacji fetchmaila\n"
+
+#: driver.c:1220
+#, fuzzy, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail nie móg³ pobraæ poczty z %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr ""
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr ""
+
+#: driver.c:1283
+#, fuzzy, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "B³±d autoryzacji dla %s@%s\n"
+
+#: driver.c:1289
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: b³±d autoryzacji fetchmaila\n"
+
+#: driver.c:1292
+#, fuzzy, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail nie móg³ pobraæ poczty z %s@%s.\n"
+
+#: driver.c:1296
+#, fuzzy
+msgid "Service has been restored.\n"
+msgstr "Wersja RPA %d.%d\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "ponowna próba po³±czenia z folderem %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "ponowna próba po³±czenia z domy¶lnym folderem\n"
+
+#: driver.c:1345
+#, fuzzy, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s na %s (folder %s)\n"
+
+#: driver.c:1353 rcfile_y.y:397
+#, fuzzy, c-format
+msgid "%s at %s"
+msgstr "%s na %s\n"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Próba po³±czenia z %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d przeczytanych) dla %s."
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "listów"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "list"
+
+#: driver.c:1366
+#, fuzzy
+msgid "seen"
+msgstr " "
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s dla %s."
+
+#: driver.c:1375
+#, fuzzy, c-format
+msgid " (%d octets).\n"
+msgstr "(%d bajtów)."
+
+#: driver.c:1381
+#, fuzzy, c-format
+msgid "No mail for %s\n"
+msgstr "Nie ma poczty dla %s"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr ""
+
+#: driver.c:1515
+msgid "socket"
+msgstr "gniazda"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "brakuj±ce lub b³êdne nag³ówki RFC822"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "synchronizacji miêdzy serwerem i klientem"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "protoko³u miêdzy serwerem i klientem"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "plik zablokowany na serwerze"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "transakcja SMTP"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "DNSu"
+
+#: driver.c:1539
+#, fuzzy
+msgid "undefined error\n"
+msgstr "niezdefiniowany\n"
+
+#: driver.c:1550
+#, fuzzy, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "b³±d %s podczas pobierania listów z %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "b³±d %s podczas pobierania listów z %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "polecenie wykonane po pobraniu poczty zwróci³o b³±d %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Obs³uga Kerberosa V4 nie zosta³a do³±czona do programu.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Obs³uga Kerberosa V5 nie zosta³a do³±czona do programu.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Opcja --flush nie dzia³a z %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Opcja --all nie dzia³a za %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Opcja --limit nie dzia³a z %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr ""
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: nie mogê znale¼æ nazwy twojego hosta!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "gethostbyname zwróci³o b³±d dla %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "serwer SMTP na %s nie obs³uguje protoko³u ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "serwer SMTP na %s nie obs³uguje polecenia ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Kolejkowanie dla %s rozpoczête\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Brak listów dla %s oczekuj±cych w kolejce\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Wysy³anie oczekuj±cych listów dla %s rozpoczête\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Kolejkowanie listów dla %s nie jest mo¿liwe\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Brak dostêpu dla hosta %s: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "B³±d sk³adniowy ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "B³±d sk³adniowy ETRN w parametrach\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Nieznany b³±d ETRN %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "Opcja --keep nie dzia³a z ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "Opcja --flush nie dzia³a z ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "Opcja --remote nie dzia³a z ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "Opcja --check nie dzia³a z ETRN\n"
+
+#: fetchmail.c:156
+#, fuzzy
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: uaktywniony o godzinie %s"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr ""
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Tu fetchmail, wersja %s"
+
+#: fetchmail.c:331
+#, fuzzy, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Pobieram opcje z linii poleceñ"
+
+#: fetchmail.c:332
+#, fuzzy
+msgid " and "
+msgstr " i %s\n"
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "Brak skonfigurowany serwerów pocztowych -- mo¿e brakuje %s?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: nie podano ¿adnych serwerów pocztowych.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: nie dzia³a ¿aden inny proces fetchmaila\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: wyst±pi³ b³±d podczas próby ubicia %s fetchmaila, PID %d.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "dzia³aj±cego w tle"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "dzia³aj±cego na konsoli"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %s fetchmail o numerze procesu %d zosta³ ubity.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: nie mogê sprawdziæ poczty, bo dzia³a inny fetchmail do tego "
+"serwera\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: nie mogê po³±czyæ siê z podanym hostem, bo dzia³a inny fetchmail "
+"(proces %d).\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: dzia³a inny chodz±cy z konsoli fetchmail (proces %d).\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: nie mogê przyjmowaæ opcji, poniewa¿ inny fetchmail dzia³a ju¿ w "
+"tle.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: chodz±cy w tle fetchmail (proces %d) zosta³ uaktywniony.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr ""
+"fetchmail: starszy proces %d zakoñczy³ pracê w niewyja¶nionych "
+"okoliczno¶ciach.\n"
+
+#: fetchmail.c:460
+#, fuzzy, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr ""
+"fetchmail: nie mogê skonfigurowaæ domy¶lnego dostarczania listów do %s\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Podaj has³o dla %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "startuje fetchmail %s w trybie demona\n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr ""
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr ""
+
+#: fetchmail.c:557
+#, fuzzy, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "startuje fetchmail %s w trybie demona\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+
+#: fetchmail.c:589
+#, fuzzy
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "Serwer odrzuci³ nasz± próbê autoryzacji."
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr "po³±czenie z %s pominiête (b³êdy autoryzacji lub timeouty)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "fetchmail: nie nadszed³ jeszcze czas na po³±czenie z %s\n"
+
+#: fetchmail.c:667
+#, fuzzy
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:669
+#, fuzzy
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:671
+#, fuzzy
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:673
+#, fuzzy
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:675
+#, fuzzy
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:677
+#, fuzzy
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:679
+#, fuzzy
+msgid "Query status=6 (IOERR)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:681
+#, fuzzy
+msgid "Query status=7 (ERROR)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:683
+#, fuzzy
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:685
+#, fuzzy
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:687
+#, fuzzy
+msgid "Query status=10 (SMTP)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:689
+#, fuzzy
+msgid "Query status=11 (DNS)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:691
+#, fuzzy
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:693
+#, fuzzy
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Wynik po³±czenia=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Nie mogê pobraæ poczty z ¿adnego serwera. Koñczê pracê.\n"
+
+#: fetchmail.c:748
+#, fuzzy, c-format
+msgid "sleeping at %s\n"
+msgstr "fetchmail: usypiam o godzinie %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "uaktywniony przez %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "uaktywniony przez sygna³ %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "uaktywniony o %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "praca zakoñczona poprawnie, kod wyj¶cia %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr ""
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr "Uwaga: host %s wystêpuje wielokrotntie w pliku konfiguracyjnym\n"
+
+#: fetchmail.c:1116
+#, fuzzy
+msgid "SSL support is not compiled in.\n"
+msgstr "obs³uga protoko³u POP2 nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr "fetchmail: uwaga: brak serwera DNS potrzebnego do sprawdzenia %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "konfiguracja dla %s jest b³êdna - numer portu nie mo¿e byæ ujemny\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr ""
+"konfiguracja dla %s jest b³êdna - RPOP wymaga uprzywilejowanego portu "
+"(<1024)\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"konfiguracja dla %s jest b³êdna - LMTP nie u¿ywa domy¶lnego portu SMTP\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr ""
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "przerwany sygna³em %d\n"
+
+#: fetchmail.c:1339
+#, fuzzy, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "fetchmail: %s ³±czy siê z %s (protokó³ %s) o godzinie %s\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "obs³uga protoko³u POP2 nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "obs³uga protoko³u POP3 nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "obs³uga protoko³u IMAP nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "obs³uga polecenia ETRN nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "Obs³uga polecenia ETRN bez gethostbyname(2) jest niemo¿liwa.\n"
+
+#: fetchmail.c:1405
+#, fuzzy
+msgid "ODMR support is not configured.\n"
+msgstr "obs³uga protoko³u POP2 nie zosta³a wkompilowana.\n"
+
+#: fetchmail.c:1411
+#, fuzzy
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "Obs³uga polecenia ETRN bez gethostbyname(2) jest niemo¿liwa.\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "Wybrany protokó³ nie jest obs³ugiwany przez fetchmaila.\n"
+
+#: fetchmail.c:1427
+#, fuzzy, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "fetchmail: %s ³±czy siê z %s (protokó³ %s) o godzinie %s\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "Czas miêdzy sprawdzaniem skrzynek wynosi %d sekund\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Plik diagnostyczny to %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Plik identyfikacyjny to %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Komunikaty o postêpach po³±czenia bêd± zg³aszane przez sysloga\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail bêdzie siê ukrywa³ i nie wygeneruje nag³ówka Received\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr ""
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr "Fetchmail wy¶le ¼le zaadresowane listy do %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr ""
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr ""
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Parametry pobierania poczty ze skrzynki %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Poczta bêdzie pobierana przez %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "Po³±czenie z tym serwerem odbêdzie siê co %d okresów.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Prawdziwa nazwa serwera to %s.\n"
+
+# budowanie zdania ze s³ów, uwaga -PK
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr ""
+"  Z tym serwerem%sbêdê siê ³±czy³ je¶li nie zostanie podany inny ¿aden "
+"serwer.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr " nie "
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr " "
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Bêdê pyta³ o has³o.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  Has³o APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  U¿ytkownik RPOP = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Has³o = \"%s\".\n"
+
+# %s zawiera numer wersji protoko³u -PK
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  U¿ywam protoko³u KPOP z uwierzytelnieniem przez Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  U¿ywam protoko³u %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (us³uga %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (opcje bezpieczeñstwa %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (po³±czenie na port %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (po³±czenie na domy¶lny port)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (bêd± stosowane UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr ""
+
+#: fetchmail.c:1536
+#, fuzzy
+msgid "  Password authentication will be forced.\n"
+msgstr "Serwer obs³uguje uwierzytelnienie OTP\n"
+
+#: fetchmail.c:1539
+#, fuzzy
+msgid "  NTLM authentication will be forced.\n"
+msgstr "Serwer obs³uguje uwierzytelnienie OTP\n"
+
+#: fetchmail.c:1542
+#, fuzzy
+msgid "  OTP authentication will be forced.\n"
+msgstr "Serwer obs³uguje uwierzytelnienie OTP\n"
+
+#: fetchmail.c:1545
+#, fuzzy
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "Serwer obs³uguje uwierzytelnienie OTP\n"
+
+#: fetchmail.c:1548
+#, fuzzy
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "Serwer obs³uguje uwierzytelnienie GSS\n"
+
+#: fetchmail.c:1551
+#, fuzzy
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  W³±czone uwierzytelnienie Kerberos V4.\n"
+
+#: fetchmail.c:1554
+#, fuzzy
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  W³±czone uwierzytelnienie Kerberos V5.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr ""
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr ""
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1566
+#, fuzzy, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  U¿ywam protoko³u %s"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr ""
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr ""
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  Limit czasu na odpowied¼ serwera wynosi %d sekund"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (domy¶lne).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Wybrana jest domy¶lna skrzynka odbiorcza.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Wybrano nastêpuj±ce skrzynki:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  Zostan± pobrane %s listy (%s --all).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "wszystkie"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "tylko nowe"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Pobrane listy%sbêd± pozostawione na serwerze (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr "  Stare listy%sbêd± kasowane przed pobraniem poczty (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  Przepisywanie adresów na postaæ lokaln± jest %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "w³±czone"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "wy³±czone"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  Usuwanie znaków CR z koñców linii jest %s (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Dodawanie znaków CR na koñcach linii jest %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+"  Interpretowanie nag³ówka Content-Transfer-Encoding jest %s (pass8bits %"
+"s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "Dekodowanie MIME jest %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, fuzzy, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "Dekodowanie MIME jest %s (mimedecode %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Niepuste nag³ówki Status bêd± %s (dropstatus %s).\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "kasowane"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "pozostawiane"
+
+#: fetchmail.c:1625
+#, fuzzy, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Niepuste nag³ówki Status bêd± %s (dropstatus %s).\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  Limit wielko¶ci listu wynosi %d bajtów (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  Limit wielko¶ci listu nie jest ustawiony (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  Ostrze¿enia o wielko¶ci listu bêd± wy¶wietlane co %d sekund (--warnings %"
+"d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr ""
+"  Ostrze¿enia o wielko¶ci pliku bêd± wy¶wietlane przy ka¿dym po³±czeniu (--"
+"warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  Limit ilo¶ci otrzymanych listów wynosi %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr ""
+"  Limit ilo¶ci otrzymanych listów nie jest ustawiony (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  Limit ilo¶ci otrzymanych listów wynosi %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Limit wielko¶ci listu nie jest ustawiony (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  Listy bêd± wysy³ane przez SMTP w grupach po %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr ""
+"  Limit ilo¶ci listów wysy³anych przez SMTP nie jest ustawiony (--batchlimit "
+"0).\n"
+
+#: fetchmail.c:1667
+#, fuzzy, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr "  Listy bêd± kasowane co %d (--expunge %d).\n"
+
+#: fetchmail.c:1669
+#, fuzzy
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Listy nie bêd± kasowane (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr ""
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (domy¶ny)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Listy bêd± dopisywane do %s jako BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Listy bêd± lokalne dorêczane przy u¿yciu \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Listy bêd± przes³ane przy pomocy %cMTP do:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  Nazwa hosta w MAIL FROM jest ustawiona na %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr ""
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Rozpoznawane odpowiedzi blokad antyspamowych to:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Blokowanie spamu wy³±czone\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  Po³±czenie do serwera zostanie nawi±zane przy pomocy \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Przed po³±czeniem nie bêdzie wykonywane ¿adne dodatkowe polecenie.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  Po³±czenie z serwerem zostanie zamkniête przy pomocy \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr ""
+"  Po zamkniêciu po³±czenia nie bêdzie wykonywane ¿adne dodatkowe polecenie.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Brak nazw lokalnych ustawionych dla tego hosta.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Tryb wielu skrzynek: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Tryb jednej skrzynki: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d znanych nazw lokalnych.\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  DNS dla adresów wieloskrzynkowych to %s.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr "  Aliasy serwera bêd± porównywane z adresami skrzynek po "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "adresach IP.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "nazwie.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  Obs³uga poczty wed³ug adresów w kopercie jest wy³±czone\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Nag³ówek koperty zosta³ ustawiony na: %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Received"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Liczba nag³ówków koperty, które bêd± sprawdzane: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Przedrostek %s bêdzie usuwany z nazwy u¿ytkownika\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  ¯adne przedrostki nie bêd± usuwane\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Zadeklarowane aliasy serwera pocztowego:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Domeny lokalne:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  Po³±czenia bêd± nawi±zywane tylko przez interfejs %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Nie jest okre¶lony ¿aden obowi±zkowy interfejs.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Podczas prób po³±czenia w pêtli bêdzie monitorowany %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  ¯aden interfejs nie bêdzie monitorowany.\n"
+
+#: fetchmail.c:1825
+#, fuzzy, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr ""
+"  Po³±czenia z serwerem bêd± nawi±zywane przez polecenie %s (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Nie jest skonfigurowane ¿adne polecenie nawi±zuj±ce po³±czenie\n"
+
+#: fetchmail.c:1829
+#, fuzzy, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  Po³±czenie z serwerem odbiorcy zostanie nawi±zane programem %s (--plugout %"
+"s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Nie jest skonfigurowane ¿adne polecenie zamykaj±ce po³±czenie.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  ¯adne UIDy nie zosta³y zachowane z sesji z tym hostem.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  Zachowano %d UIDów.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+
+# XXX -PK
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  W³asno¶ci przepuszczania \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+#, fuzzy
+msgid "alloca failed"
+msgstr "b³±d malloc\n"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "B£¡D; brak obs³ugi funkcji getpassword()\n"
+
+#: getpass.c:194
+#, fuzzy
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"Dosta³em sygna³... koñczê pracê.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Uzyskanie nazwy us³ugi dla [%s] jest niemo¿liwe\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "U¿ywam nazwy us³ugi [%s]\n"
+
+# XXX  nie jestem pewien credentials -PK
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Wysy³am wierzytelno¶ci\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Wyst±pi³ b³±d podczas wymiany uprawnieñ\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Nie mogê rozwin±æ danych poziomu bezpieczeñstwa\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Wymiana uprawnieñ zosta³a zakoñczona\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Serwer wymaga zapewnionej integralno¶ci i/lub prywatno¶ci\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Rozwiniête flagi poziomu bezpieczeñstwa: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "Maksymalny rozmiar symbolu GSS to %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Wyst±pi³ b³±d podczas budowania zapytania o poziom bezpieczeñstwa\n"
+
+# XXX tak samo, wierzytelnosci -PK
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Zwalniam uprawnienia GSS\n"
+
+# XXX
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Wyst±pi³ b³±d podczas zwalniania uprawnieñ\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: usypiam na %d sekund.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protokó³ rozpoznany jako IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protokó³ rozpoznany jako IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protokó³ rozpoznany jako IMAP2 lub IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr ""
+
+#: imap.c:460
+#, fuzzy
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "Serwer nie obs³uguje wymaganej metody uwierzytelnienia LOGIN\n"
+
+#: imap.c:482
+#, fuzzy
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Serwer nie obs³uguje wymaganej metody uwierzytelnienia LOGIN\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Serwer nie obs³uguje wymaganej metody uwierzytelnienia LOGIN\n"
+
+#: imap.c:641 imap.c:707
+#, fuzzy
+msgid "expunge failed\n"
+msgstr "b³±d execl(%s)\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "ponowne po³±czenie nie powiod³o siê\n"
+
+#: imap.c:671
+#, fuzzy, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "Brak listów dla %s oczekuj±cych w kolejce\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "wybór skrzynki zakoñczy³ siê niepowodzeniem\n"
+
+#: imap.c:685
+#, fuzzy, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "Brak listów dla %s oczekuj±cych w kolejce\n"
+
+#: imap.c:711
+#, fuzzy, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "Brak listów dla %s oczekuj±cych w kolejce\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr ""
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr ""
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr ""
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr ""
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr ""
+
+#: interface.c:426
+#, fuzzy
+msgid "get_ifinfo: malloc failed"
+msgstr "b³±d malloc\n"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr ""
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr ""
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr ""
+
+#: interface.c:540
+#, fuzzy, c-format
+msgid "No IP address found for %s"
+msgstr "nie znalaz³em adresu Received\n"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "interfejs nie ma ustawionego adresu IP\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "interfejs ma ustawiony b³êdny adres IP\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "interfejs ma ustawion± b³êdn± maskê sieci\n"
+
+# XXX -PK
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "ruch na %s zauwa¿ony jako %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "pomijam po³±czenie z %s, %s nie jest podniesiony\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "pomijam po³±czenie z %s, adres IP %s nie jest na li¶cie\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "ruch na %s sprawdzany jako %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "pomijam po³±czenie z %s, %s nie jest aktywny\n"
+
+# XXX -PK
+#: interface.c:732
+#, fuzzy, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "ruch na %s by³ %d, jest %d"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "rozkodowanie pocz±tkuj±cego wyzwania BASE64 by³o niemo¿liwe\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "u¿ytkownik %s w bilecie nie pasuje do -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "niezerowy obiekt (%s) mo¿e mieæ nieprzewidywalne efekty\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "odkodowanie odpowiedzi BASE64 jest niemo¿liwe\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "niezgodno¶æ wyzwania\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmaila: usuwam niewa¿ny plik blokady\n"
+
+#: lock.c:122
+#, fuzzy
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: b³±d socketpair\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "uwaga: przed ka¿d± nazw± hosta wystêpuje \"%s\""
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: uwaga: przed ka¿d± nazw± hosta wystêpuje \"%s\"\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: uwaga: nieznany symbol \"%s\"\n"
+
+#: odmr.c:65
+#, fuzzy, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "serwer SMTP na %s nie obs³uguje polecenia ETRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr ""
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr ""
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr ""
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr ""
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr ""
+
+#. Authentication required
+#: odmr.c:125
+#, fuzzy
+msgid "Authentication required.\n"
+msgstr "Serwer obs³uguje uwierzytelnienie OTP\n"
+
+#: odmr.c:129
+#, fuzzy, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Nieznany b³±d ETRN %d\n"
+
+#: odmr.c:244
+#, fuzzy
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "Opcja --keep nie dzia³a z ETRN\n"
+
+#: odmr.c:248
+#, fuzzy
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "Opcja --flush nie dzia³a z ETRN\n"
+
+#: odmr.c:252
+#, fuzzy
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "Opcja --remote nie dzia³a z ETRN\n"
+
+#: odmr.c:256
+#, fuzzy
+msgid "Option --check is not supported with ODMR\n"
+msgstr "Opcja --check nie dzia³a z ETRN\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr ""
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Rozkodowanie wyzwania OTP by³o niemo¿liwe\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Tajne has³o: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "Napis '%s' nie reprezentuje poprawnie zapisanej liczby.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "Warto¶æ napisu '%s' jest %s ni¿ %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "mniejsza"
+
+#: options.c:211
+msgid "larger"
+msgstr "wiêksza"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Podano b³êdny protokó³ `%s'.\n"
+
+#: options.c:429
+#, fuzzy, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Podano b³êdn± metodê uwierzytelnienia `%s'.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: obs³uga funkcji bezpieczeñstwa sieciowego jest wy³±czona\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "u¿ycie:  fetchmail [opcje] [serwer ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Mo¿na podaæ nastêpuj±ce opcje:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        wy¶wietla ten opis opcji\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     wy¶wietla informacje o wersji\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       sprawdza czy s± nowe listy bez ich pobierania\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      wy³±cza komunikaty\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     w³±cza wy¶wietlanie szczegó³owych komunikatów\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      w³±cza uruchamianie w trybie demona co n sekund\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    wy³±cza pracê w tle w trybie demona\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        koñczy pracê demona\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     podaje nazwê pliku kroniki\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog        w³±cza wy¶wietlanie wiêkszo¶ci komunikatów przez syslog"
+"(3)\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   w³±cza udawanie hosta i nie dodaje nag³ówków Received\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc okre¶la alternatywny plik konfiguracyjny\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      okre¶la alternatywny plik z UIDami\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  adres na który bêd± wysy³ane b³êdne listy\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr ""
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   wymagana nazwa interfejsu\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     monitoruje dany interfejs czekaj±c na ruch\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr ""
+
+#: options.c:684
+#, fuzzy
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --bsmtp       okre¶la nazwê wynikowego pliku BSMTP\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr ""
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr ""
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+"      --plugin      ¶cie¿ka do zewnêtrznego polecenia otwieraj±cego "
+"po³±czenie\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     ¶cie¿ka do zewnêtrznego polecenia zamykaj±cego "
+"po³±czenie\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    okre¶la protokó³ którym bêd± pobierane listy (patrz "
+"manual)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        wymusza u¿ywanie UIDL (tylko POP3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        okre¶la port TCP/IP na który nale¿y siê ³±czyæ\n"
+
+#: options.c:694
+#, fuzzy
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr ""
+"  -A, --auth        okre¶la metodê uwierzytelnienia (has³o lub Kerberos)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     limit czasu oczekiwania na odpowied¼ serwera\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr ""
+"  -E, --envelope    okre¶la nazwê nag³ówka zawieraj±cego adres z koperty\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+"  -Q, --qvirtual    przedrostek, który bêdzie usuwany z nazwy u¿ytkownika\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr ""
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    okre¶la login u¿ytkownika na serwerze\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         pobiera wszystkie listy, stare i nowe\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      kasuje nowe listy po pobraniu\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        po pobraniu pozostawia nowe listy na serwerze\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       kasuje stare listy z serwera\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   nie przepisuje adresów w nag³ówkach\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -l, --limit       nie pobiera listów wiêkszych ni¿ podany rozmiar\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    czas miêdzy powiadomieniami o poczcie\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      okre¶la funkcjê bezpieczeñstwa IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr ""
+"  -S, --smtphost    okre¶la nazwê hosta SMTP przesy³aj±cego nasze listy\n"
+
+#: options.c:714
+#, fuzzy
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr ""
+"  -B, --fetchlimit  okre¶la limit listów pobieranych w jednym po³±czaniu\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr ""
+"  -D, --smtpaddress okre¶la nazwê domeny SMTP u¿ywan± przy dorêczaniu "
+"poczty\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr ""
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    okre¶la odpowiedzi blokad antyspamowych\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+"  -b, --batchlimit  okre¶la limit listów wys³anych w jednym po³±czeniu SMTP\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  okre¶la limit listów pobieranych w jednym po³±czaniu\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr ""
+"  -B, --fetchlimit  okre¶la limit listów pobieranych w jednym po³±czaniu\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+"  -e, --expunge     liczba skasowanych listów miêdzy czyszczeniem skrzynki\n"
+
+#: options.c:723
+#, fuzzy
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr ""
+"      --mda         okre¶la ¶cie¿kê do MDA dorêczaj±cego pobrane listy\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       okre¶la nazwê wynikowego pliku BSMTP\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        u¿ywa LMTP (RFC2033) do dorêczania poczty\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      okre¶la nazwê skrzynki na serwerze\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "W powitaniu serwera brakuje wymaganego znacznika czasu APOP\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "B³±d sk³adni znacznika czasu w powitaniu\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Pro¶ba o nieznany protokó³ w POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "plik zablokowany! Czy inna sesja nie jest aktywna?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr ""
+"Przesy³ki zosta³y dodane do listy na serwerze. Nie mogê tego obs³u¿yæ.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "b³±d protoko³u\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "b³±d protoko³u podczas pobierania UIDL\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "Opcja --remote nie dzia³a z POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr ""
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr ""
+
+#: rcfile_y.y:218
+#, fuzzy
+msgid "invalid security request"
+msgstr "Wyst±pi³ b³±d podczas budowania zapytania o poziom bezpieczeñstwa\n"
+
+#: rcfile_y.y:224
+#, fuzzy
+msgid "network-security support disabled"
+msgstr "fetchmail: obs³uga funkcji bezpieczeñstwa sieciowego jest wy³±czona\n"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr ""
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr ""
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr ""
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr ""
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr ""
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Nieznany b³±d systemu"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (tworzenie listy informacyjnego nie zosta³o zakoñczone)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "przepe³nienie bufora podczas tworzenia czê¶ci komunikatu o b³êdzie"
+
+#: rfc822.c:74
+#, fuzzy, c-format
+msgid "About to rewrite %s"
+msgstr "list zostanie dorêczony przy pomocy: %s\n"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr ""
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Sukces"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Zastrze¿ony u¿ytkownik (co¶ nie w porz±dku z kontem)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "B³êdna nazwa u¿ytkownika albo has³o"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "B³±d dziedziny"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "Token 2 RPA: b³±d dekodowanie Base64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Wersja RPA %d.%d\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Has³o do us³ugi (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Datownik us³ugi %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "Token 2 RPA b³±d d³ugo¶ci\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Lista dziedzin: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "RPA b³±d w napisie us³uga@dziedzina\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA symbol 4: b³±d podczas dekodowania Base64\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Uwierzytelnienie u¿ytkownika (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "Stan RPA: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "RPA b³±d d³ugo¶ci symbolu 4\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA odrzuci³o u¿ytkownika: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA odrzuci³o u¿ytkownika bez podania przyczyny\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "RPA b³±d d³ugo¶ci uwierzytelnienia u¿ytkownika: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "RPA b³±d d³ugo¶ci klucza sesyjnego: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "RPA b³±d uwierzytelnienia _us³ugi_. Kto¶ podszywa siê pod serwer?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Uzgodniony klucz sesyjny:\n"
+
+#: rpa.c:341
+#, fuzzy
+msgid "RPA authorisation complete\n"
+msgstr "Autoryzacja RPA zakoñczona\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Oczekiwanie na odpowied¼\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Oczekiwanie na odpowied¼ zakoñczone z wynikiem %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "D³ugo¶æ nag³ówka nie wynosi 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "B³±d d³ugo¶ci symbolu\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "D³ugo¶æ symbolu %d nie pasuje do rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "B³êdne pole mechanizmu\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "b³±d dec64 na znaku %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Przychodz±ce dane binarne:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Wychodz±ce dane binarne:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "RPA za d³ugi napis\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA otwarcie /dev/urandom jest niemo¿liwe. Nie uniemo¿liwia\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    zalogowania siê, ale oznacza ¿e nie mo¿esz\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    byæ pewien ¿e po³±czy³e¶ siê z w³a¶ciw± us³ug±\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    (mo¿liwy jest atak przez odtwarzanie\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "     nieuczciwej us³ugi.)\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Wyzwanie u¿ytkownika:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "MD5 zastosowany do bloku danych:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "Wynik MD5: \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "przesy³anie do %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr ""
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr ""
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr ""
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "b³±d %cMTP: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "BSMTP otwarcie pliku lub zapis nag³ówka nie powiód³ siê\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "demon %cMTP nie przyj±³ adresu odbiorcy `%s'\n"
+
+#: sink.c:989
+#, fuzzy, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "demon %cMTP nie przyj±³ adresu odbiorcy `%s'\n"
+
+#: sink.c:1027
+#, fuzzy
+msgid "no address matches; no postmaster set.\n"
+msgstr "brak pasuj±cych lokalnych adresów, przesy³am do %s\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "nie mogê wys³aæ poczty nawet do %s!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "brak pasuj±cych lokalnych adresów, przesy³am do %s\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "list zostanie dorêczony przy pomocy: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "b³±d podczas uruchamiania MDA (programu dorêczaj±cego poczte)\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "po³±czenie %cMTP z %s nie powiod³o siê\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr ""
+
+#: sink.c:1339
+#, fuzzy, c-format
+msgid "MDA died of signal %d\n"
+msgstr "uaktywniony przez sygna³ %d\n"
+
+#: sink.c:1342
+#, fuzzy, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "MDA nie zakoñczy³ poprawnie pracy lub zwróci³ niezerowy kod b³êdu\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr ""
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Zakoñczenie listyu lub zamkniêcie pliku BSMTP nie powiod³o siê\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "serwer SMTP odmówi³ dostarczenia listu\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "B³±d podczas dorêczania LMTP w momencie wykonywania komendy EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Niespodziewana odpowied¼ inna ni¿ 503 na LSTMP EOM: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+
+#: smtp.c:86
+#, fuzzy
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "Serwer obs³uguje uwierzytelnienie OTP\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr ""
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr ""
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr ""
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:361 smtp.c:384
+#, fuzzy
+msgid "smtp listener protocol error\n"
+msgstr "b³±d protoko³u\n"
+
+#: socket.c:108 socket.c:134
+#, fuzzy
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: b³±d fork\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: b³±d socketpair\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: b³±d fork\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "b³±d dup2\n"
+
+#: socket.c:186
+#, fuzzy, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "uruchamiam %s %s %s\n"
+
+#: socket.c:189
+#, fuzzy, c-format
+msgid "execvp(%s) failed\n"
+msgstr "b³±d execl(%s)\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: otrzyma³em b³êdn± d³ugo¶æ adresu dla hosta %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr ""
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr ""
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr ""
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr ""
+
+#: socket.c:792
+#, fuzzy, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Datownik us³ugi %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr ""
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr ""
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr ""
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr ""
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr ""
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr ""
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr ""
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr ""
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr ""
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr ""
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr ""
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr ""
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr ""
+
+#: socket.c:948
+#, fuzzy, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr "Podano b³êdny protokó³ `%s'.\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr ""
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr ""
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr ""
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s zamieniony na lokalny %s\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "przepuszczony przez %s pasuje do %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analizujê nag³ówek Received:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "nag³ówek zosta³ przyjêty, %s jest aliasem serwera pocztowego\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "nag³ówek zosta³ odrzucony, %s nie jest aliasem serwera pocztowego\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "nie znalaz³em adresu Received\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "znalaz³em adres Received `%s'\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "podczas skanowania nag³ówków znaleziono separator listów\n"
+
+#: transact.c:552
+#, fuzzy
+msgid "incorrect header line found while scanning headers\n"
+msgstr "podczas skanowania nag³ówków znaleziono separator listów\n"
+
+#: transact.c:554
+#, fuzzy, c-format
+msgid "line: %s"
+msgstr "Próba po³±czenia z %s\n"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "brak pasuj±cych lokalnych adresów, przesy³am do %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "listy nie zostan± przes³ane i skasowane z powodu b³êdów DNSu\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "zapisujê RFC822 msgblk.headers\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "¿aden z adresatów nie pasowa³ do nazw lokalnych u¿ytkowników"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "adresat %s nie pasowa³ do ¿adnej nazwy lokalnego u¿ytkownika"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "list zawiera³ znaki NULL"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "demon SMTP odrzuci³ adresy lokalnych odbiorców: '"
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "zapisujê tre¶æ listu\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr ""
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr ""
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr ""
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr ""
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, c-format
+msgid "Merged UID list from %s:"
+msgstr ""
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr ""
+
+#: uid.c:542
+#, fuzzy
+msgid "swapping UID lists\n"
+msgstr "zapisa³em listê UIDów\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr ""
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "zapisa³em listê UIDów\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr ""
+
+#: uid.c:616
+#, fuzzy
+msgid "Writing fetchids file.\n"
+msgstr "startuje fetchmail %s w trybie demona\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "b³±d malloc\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "b³±d realloc\n"
+
+#, fuzzy
+#~ msgid "fetchmail: %s connection to %s failed"
+#~ msgstr "fetchmail: %s po³±czenie do %s nie powiod³o siê: \n"
+
+#~ msgid "Skipping message %d, length -1\n"
+#~ msgstr "Pomijam list %d, d³ugo¶æ -1\n"
+
+#~ msgid "authorization"
+#~ msgstr "autoryzacji"
+
+#~ msgid "%s: can't find your name and home directory!\n"
+#~ msgstr "%s: nie mogê znale¼æ twojej nazwy i katalogu domowego!\n"
+
+#~ msgid "Lockfile at %s\n"
+#~ msgstr "Plik blokady na %s\n"
+
+#~ msgid "fetchmail: cannot allocate memory for lock name.\n"
+#~ msgstr ""
+#~ "fetchmail: nie mogê zarezerwowaæ pamiêci dla nazwy blokowanego pliku.\n"
+
+#~ msgid "Could not decode initial BASE64 challenge\n"
+#~ msgstr "Rozkodowanie pocz±tkuj±cego wyzwania BASE64 by³o niemo¿liwe\n"
+
+#~ msgid "Requesting authorization as %s\n"
+#~ msgstr "¯±dam uprawnieñ jako %s\n"
+
+#~ msgid "Required GSS capability not supported by server\n"
+#~ msgstr "Serwer nie obs³uguje wymaganej metody uwierzytelnienia GSS\n"
+
+#~ msgid "KERBEROS_V4 authentication is supported\n"
+#~ msgstr "Serwer obs³uguje uwierzytelnienie KERBEROS_V4\n"
+
+#~ msgid "Required KERBEROS_V4 capability not supported by server\n"
+#~ msgstr ""
+#~ "Serwer nie obs³uguje wymaganej metody uwierzytelnienia KERBEROS_V4\n"
+
+#, fuzzy
+#~ msgid "Required CRAM-MD5 capability not supported by server\n"
+#~ msgstr "Serwer nie obs³uguje wymaganej metody uwierzytelnienia GSS\n"
+
+#~ msgid ""
+#~ "This could mean that your mailserver is stuck, or that your SMTP listener"
+#~ msgstr ""
+#~ "Mo¿e to oznaczaæ ¿e: twój serwer pocztowy pad³, serwer SMTP popsu³ siê"
+
+#~ msgid ""
+#~ "is wedged, or that your mailbox file on the server has been corrupted by"
+#~ msgstr ""
+#~ "lub twoja poczta na serwerze zosta³a uszkodzona z powodu b³êdu serwera."
+
+#~ msgid ""
+#~ "a server error.  You can run `fetchmail -v -v' to diagnose the problem."
+#~ msgstr ""
+#~ "Mo¿esz spróbowaæ uruchomiæ `fetchmaila -v -v' i znale¼æ przyczynê "
+#~ "problemu."
+
+#~ msgid "Fetchmail won't poll this mailbox again until you restart it."
+#~ msgstr ""
+#~ "Fetchmail nie bêdzie próbowa³ pobraæ poczty z tej skrzynki do czasu "
+#~ "restartu."
+
+#~ msgid "This probably means your password is invalid."
+#~ msgstr "Oznacza to prawdopodobnie, ¿e poda³e¶ z³e has³o."
+
+#~ msgid ": Error %d"
+#~ msgstr ": B³±d %d"
+
+#~ msgid "forwarding to SMTP port on %s"
+#~ msgstr "przesy³anie na port SMTP na %s"
+
+#~ msgid "local error"
+#~ msgstr "b³±d lokalny"
+
+#~ msgid "%d message%s (%d seen) at %s."
+#~ msgstr "%d list%s (%d przeczytanych) na %s."
+
+#~ msgid "s"
+#~ msgstr "ów"
+
+#~ msgid "%d message%s at %s."
+#~ msgstr "%d list%s na %s."
+
+#~ msgid "No mail at %s"
+#~ msgstr "Nie ma nowej poczty na %s"
+
+#~ msgid "gethostbyname failed for %s"
+#~ msgstr "gethostbyname zwróci³o b³±d dla %s"
+
+#~ msgid "unknown?!?"
+#~ msgstr "nieznany?!?"
+
+#~ msgid "fetchmail: error killing %s fetchmail at %d.\n"
+#~ msgstr ""
+#~ "fetchmail: wyst±pi³ b³±d podczas próby ubicia fetchmaila (%s proces numer "
+#~ "%d).\n"
+
+#~ msgid "skipping %s poll, "
+#~ msgstr "pomijam po³±czenie z %s, "
+
+#~ msgid "DNS error"
+#~ msgstr "b³±d DNSu"
+
+#~ msgid "fetchmail: you'd never see large messages!\n"
+#~ msgstr "fetchmail: nie bêdziesz móg³ ¶ci±gn±æ du¿ych listów!\n"
+
+#~ msgid "fetchmail: can't handle multidrop mailboxes without DNS\n"
+#~ msgstr "fetchmail: nie mogê dorêczaæ poczty do wielu skrzynek bez DNSu\n"
+
+#~ msgid "  Protocol is KPOP"
+#~ msgstr "  Bêdzie u¿ywany protokó³ KPOP"
+
+#~ msgid "on"
+#~ msgstr "aktywne"
+
+#~ msgid "off"
+#~ msgstr "nieaktywne"
+
+#~ msgid "dis"
+#~ msgstr " nie "
+
+#, fuzzy
+#~ msgid "fatal error - scanner input buffer overflow"
+#~ msgstr "przepe³nienie bufora podczas tworzenia czê¶ci komunikatu o b³êdzie"
+
+#, fuzzy
+#~ msgid "parse error"
+#~ msgstr "b³±d lokalny"
diff --git a/po/pl.po.rej b/po/pl.po.rej
new file mode 100644
index 00000000..6b5bee1f
--- /dev/null
+++ b/po/pl.po.rej
@@ -0,0 +1,610 @@
+***************
+*** 1,13 ****
+  # Copyright (C) 1998 Free Software Foundation, Inc.
+- # Pawe³ Krawczyk <kravietz@ceti.com.pl>, 1998.
+- #
+  msgid ""
+  msgstr ""
+- "Project-Id-Version: fetchmail-4.7.7\n"
+- "POT-Creation-Date: 2003-10-15 15:23-0400\n"
+- "PO-Revision-Date: 1999-02-09 17:46+01:00\n"
+  "Last-Translator: Pawe³ Krawczyk <kravietz@ceti.com.pl>\n"
+- "Language-Team: Polish <pl@li.org>\n"
+  "MIME-Version: 1.0\n"
+  "Content-Type: text/plain; charset=iso-8859-2\n"
+  "Content-Transfer-Encoding: 8bit\n"
+--- 1,16 ----
++ # Polish translation for fetchmail.
+  # Copyright (C) 1998 Free Software Foundation, Inc.
++ # Pawe³ Krawczyk <kravietz@ceti.com.pl>, 1998,1999.
++ # Jakub Bogusz <qboosh@pld-linux.org>, 2002-2003.
++ # Adam Go³êbiowski <adamg@pld-linux.org>, 2003.
+  msgid ""
+  msgstr ""
++ "Project-Id-Version: fetchmail-6.2.5\n"
++ "Report-Msgid-Bugs-To: \n"
++ "POT-Creation-Date: 2003-10-19 20:57+0200\n"
++ "PO-Revision-Date: 2003-09-05 22:02+0200\n"
+  "Last-Translator: Pawe³ Krawczyk <kravietz@ceti.com.pl>\n"
++ "Language-Team: Polish <translation-team-pl@lists.sourceforge.net>\n"
+  "MIME-Version: 1.0\n"
+  "Content-Type: text/plain; charset=iso-8859-2\n"
+  "Content-Transfer-Encoding: 8bit\n"
+***************
+*** 59,79 ****
+  "\n"
+  "The following oversized messages remain on the mail server %s:"
+  msgstr ""
+  
+  #: driver.c:354
+- #, fuzzy, c-format
+  msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+- msgstr "\tlist %d o d³ugo¶ci %d zosta³ pominiêty.\n"
+  
+  #: driver.c:494
+- #, fuzzy, c-format
+  msgid "skipping message %s@%s:%d"
+- msgstr "pomijam list %d (%d bajtów)\n"
+  
+  #: driver.c:546
+- #, fuzzy, c-format
+  msgid "skipping message %s@%s:%d (%d octets)"
+- msgstr "pomijam list %d (%d bajtów)\n"
+  
+  #.
+  #. * Invalid lengths are produced by Post Office/NT's
+--- 59,82 ----
+  "\n"
+  "The following oversized messages remain on the mail server %s:"
+  msgstr ""
++ "Subject: Ostrze¿enie fetchmaila o zbyt du¿ych listach.\n"
++ "\n"
++ "Nastêpuj±ce zbyt du¿e listy pozosta³y na serwerze poczty %s:"
+  
+  #: driver.c:354
++ #, c-format
+  msgid "\t%d msg %d octets long skipped by fetchmail.\n"
++ msgstr "\tlist %d o d³ugo¶ci %d zosta³ pominiêty przez fetchmaila.\n"
+  
+  #: driver.c:494
++ #, c-format
+  msgid "skipping message %s@%s:%d"
++ msgstr "pomijam list %s@%s:%d"
+  
+  #: driver.c:546
++ #, c-format
+  msgid "skipping message %s@%s:%d (%d octets)"
++ msgstr "pomijam list %s@%s:%d (%d bajtów)"
+  
+  #.
+  #. * Invalid lengths are produced by Post Office/NT's
+***************
+*** 87,108 ****
+  #.
+  #: driver.c:562
+  msgid " (length -1)"
+- msgstr ""
+  
+  #: driver.c:565
+- #, fuzzy
+  msgid " (oversized)"
+- msgstr " (za du¿y, %d bajtów)\n"
+  
+  #: driver.c:580
+  #, c-format
+  msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+- msgstr ""
+  
+  #: driver.c:597
+- #, fuzzy, c-format
+  msgid "reading message %s@%s:%d of %d"
+- msgstr "pobieram %d list z %d"
+  
+  # budowanie komunikatu z pojedynczych slow - uwaga
+  # na spacje i odmiane -PK
+--- 90,110 ----
+  #.
+  #: driver.c:562
+  msgid " (length -1)"
++ msgstr " (d³ugo¶æ -1)"
+  
+  #: driver.c:565
+  msgid " (oversized)"
++ msgstr " (za du¿y)"
+  
+  #: driver.c:580
+  #, c-format
+  msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
++ msgstr "nie mo¿na ¶ci±gn±æ nag³ówków, list %s@%s:%d (%d bajtów)\n"
+  
+  #: driver.c:597
++ #, c-format
+  msgid "reading message %s@%s:%d of %d"
++ msgstr "pobieram list %s@%s:%d z %d"
+  
+  # budowanie komunikatu z pojedynczych slow - uwaga
+  # na spacje i odmiane -PK
+***************
+*** 121,131 ****
+  msgstr " (%d bajtów tre¶ci)"
+  
+  #: driver.c:733
+- #, fuzzy, c-format
+  msgid ""
+  "message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+  msgstr ""
+- "d³ugo¶æ listu %d nie odpowiada d³ugo¶ci zg³oszonej przez serwer (%d != %d)\n"
+  
+  #: driver.c:764
+  msgid " retained\n"
+--- 123,134 ----
+  msgstr " (%d bajtów tre¶ci)"
+  
+  #: driver.c:733
++ #, c-format
+  msgid ""
+  "message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+  msgstr ""
++ "d³ugo¶æ listu %s@%s:%d nie odpowiada d³ugo¶ci zg³oszonej przez serwer (%d != "
++ "%d)\n"
+  
+  #: driver.c:764
+  msgid " retained\n"
+***************
+*** 140,152 ****
+  msgstr " nie zosta³ skasowany\n"
+  
+  #: driver.c:806
+- #, fuzzy, c-format
+  msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+- msgstr "limit pobranych listów zosta³ osi±gniêty: %d pozosta³o na serwerze\n"
+  
+  #: driver.c:866
+  msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+- msgstr ""
+  
+  #: driver.c:873
+  #, c-format
+--- 143,157 ----
+  msgstr " nie zosta³ skasowany\n"
+  
+  #: driver.c:806
++ #, c-format
+  msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
++ msgstr ""
++ "limit pobranych listów %d osi±gniêty: %d pozosta³o na serwerze %s na koncie %"
++ "s\n"
+  
+  #: driver.c:866
+  msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
++ msgstr "SIGPIPE otrzymany od MDA lub b³±d gniazda strumienia\n"
+  
+  #: driver.c:873
+  #, c-format
+***************
+*** 180,186 ****
+  "Subject: fetchmail zg³asza wielokrotne przekroczenie czasu oczekiwania\n"
+  
+  #: driver.c:903
+- #, fuzzy, c-format
+  msgid ""
+  "Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+  "s.\n"
+--- 185,191 ----
+  "Subject: fetchmail zg³asza wielokrotne przekroczenie czasu oczekiwania\n"
+  
+  #: driver.c:903
++ #, c-format
+  msgid ""
+  "Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+  "s.\n"
+***************
+*** 208,254 ****
+  
+  #: driver.c:990
+  msgid "Lead server has no name.\n"
+- msgstr ""
+  
+  #: driver.c:1013
+- #, fuzzy, c-format
+  msgid "couldn't find canonical DNS name of %s (%s)\n"
+- msgstr "nie mogê znale¼æ kanonicznej nazwy %s\n"
+  
+  #: driver.c:1050
+- #, fuzzy
+  msgid "internal inconsistency\n"
+- msgstr "fetchmail: niezgodno¶æ danych wewnêtrznych\n"
+  
+  #: driver.c:1060
+- #, fuzzy, c-format
+  msgid "%s connection to %s failed"
+- msgstr "po³±czenie %cMTP z %s nie powiod³o siê\n"
+  
+  #: driver.c:1066
+- #, fuzzy
+  msgid "host is unknown."
+- msgstr ": nieznany host\n"
+  
+  #: driver.c:1069
+- #, fuzzy
+  msgid "name is valid but has no IP address."
+- msgstr "nazwa istnieje, ale nie posiada adresu IP\n"
+  
+  #: driver.c:1072
+- #, fuzzy
+  msgid "unrecoverable name server error."
+- msgstr ": b³±d serwera DNS uniemo¿liwiajacy dalsz± pracê\n"
+  
+  #: driver.c:1074
+- #, fuzzy
+  msgid "temporary name server error."
+- msgstr "chwilowy problem z serwerem DNS\n"
+  
+  #: driver.c:1081
+- #, fuzzy, c-format
+  msgid "unknown DNS error %d."
+- msgstr ": nieznany b³±d %d serwera DNS\n"
+  
+  #: driver.c:1099
+  #, c-format
+--- 219,260 ----
+  
+  #: driver.c:990
+  msgid "Lead server has no name.\n"
++ msgstr "Serwer prowadz±cy nie ma nazwy.\n"
+  
+  #: driver.c:1013
++ #, c-format
+  msgid "couldn't find canonical DNS name of %s (%s)\n"
++ msgstr "nie mogê znale¼æ kanonicznej nazwy %s (%s)\n"
+  
+  #: driver.c:1050
+  msgid "internal inconsistency\n"
++ msgstr "niezgodno¶æ danych wewnêtrznych\n"
+  
+  #: driver.c:1060
++ #, c-format
+  msgid "%s connection to %s failed"
++ msgstr "po³±czenie %s z %s nie powiod³o siê"
+  
+  #: driver.c:1066
+  msgid "host is unknown."
++ msgstr "nieznany host."
+  
+  #: driver.c:1069
+  msgid "name is valid but has no IP address."
++ msgstr "nazwa istnieje, ale nie posiada adresu IP."
+  
+  #: driver.c:1072
+  msgid "unrecoverable name server error."
++ msgstr "b³±d serwera nazw uniemo¿liwiaj±cy dalsz± pracê."
+  
+  #: driver.c:1074
+  msgid "temporary name server error."
++ msgstr "chwilowy problem z serwerem nazw."
+  
+  #: driver.c:1081
++ #, c-format
+  msgid "unknown DNS error %d."
++ msgstr "nieznany b³±d %d serwera nazw."
+  
+  #: driver.c:1099
+  #, c-format
+***************
+*** 257,267 ****
+  "\n"
+  "Fetchmail could not reach the mail server %s:"
+  msgstr ""
+  
+  #: driver.c:1128 imap.c:366 pop3.c:410
+- #, fuzzy
+  msgid "SSL connection failed.\n"
+- msgstr "po³±czenie SSL nie powiod³o siê."
+  
+  #: driver.c:1181
+  #, c-format
+--- 263,275 ----
+  "\n"
+  "Fetchmail could not reach the mail server %s:"
+  msgstr ""
++ "Subject: Ostrze¿enie fetchmaila o nieosi±galnym serwerze.\n"
++ "\n"
++ "Fetchmail nie móg³ po³±czyæ siê z serwerem poczty %s:"
+  
+  #: driver.c:1128 imap.c:366 pop3.c:410
+  msgid "SSL connection failed.\n"
++ msgstr "po³±czenie SSL nie powiod³o siê.\n"
+  
+  #: driver.c:1181
+  #, c-format
+***************
+*** 269,294 ****
+  msgstr "B³±d blokady pliku dla %s@%s\n"
+  
+  #: driver.c:1185
+- #, fuzzy, c-format
+  msgid "Server busy error on %s@%s\n"
+- msgstr "B³±d blokady pliku dla %s@%s\n"
+  
+  #: driver.c:1190
+- #, fuzzy, c-format
+  msgid "Authorization failure on %s@%s%s\n"
+- msgstr "B³±d autoryzacji dla %s@%s\n"
+  
+  #: driver.c:1193
+  msgid " (previously authorized)"
+- msgstr ""
+  
+  #: driver.c:1214
+- #, fuzzy, c-format
+  msgid "Subject: fetchmail authentication failed on %s@%s\n"
+- msgstr "Subject: b³±d autoryzacji fetchmaila\n"
+  
+  #: driver.c:1217
+- #, fuzzy, c-format
+  msgid "Fetchmail could not get mail from %s@%s.\n"
+  msgstr "Fetchmail nie móg³ pobraæ poczty z %s@%s.\n"
+  
+--- 277,302 ----
+  msgstr "B³±d blokady pliku dla %s@%s\n"
+  
+  #: driver.c:1185
++ #, c-format
+  msgid "Server busy error on %s@%s\n"
++ msgstr "Serwer zajêty dla %s@%s\n"
+  
+  #: driver.c:1190
++ #, c-format
+  msgid "Authorization failure on %s@%s%s\n"
++ msgstr "B³±d autoryzacji dla %s@%s%s\n"
+  
+  #: driver.c:1193
+  msgid " (previously authorized)"
++ msgstr " (poprzednio zautoryzowano)"
+  
+  #: driver.c:1214
++ #, c-format
+  msgid "Subject: fetchmail authentication failed on %s@%s\n"
++ msgstr "Subject: b³±d autoryzacji fetchmaila dla %s@%s\n"
+  
+  #: driver.c:1217
++ #, c-format
+  msgid "Fetchmail could not get mail from %s@%s.\n"
+  msgstr "Fetchmail nie móg³ pobraæ poczty z %s@%s.\n"
+  
+***************
+*** 320,355 ****
+  "at each cycle.  No future notifications will be sent until service\n"
+  "is restored."
+  msgstr ""
+  
+  #: driver.c:1251
+  #, c-format
+  msgid "Repoll immediately on %s@%s\n"
+- msgstr ""
+  
+  #: driver.c:1256
+  #, c-format
+  msgid "Unknown login or authentication error on %s@%s\n"
+- msgstr ""
+  
+  #: driver.c:1280
+- #, fuzzy, c-format
+  msgid "Authorization OK on %s@%s\n"
+- msgstr "B³±d autoryzacji dla %s@%s\n"
+  
+  #: driver.c:1286
+- #, fuzzy, c-format
+  msgid "Subject: fetchmail authentication OK on %s@%s\n"
+- msgstr "Subject: b³±d autoryzacji fetchmaila\n"
+  
+  #: driver.c:1289
+- #, fuzzy, c-format
+  msgid "Fetchmail was able to log into %s@%s.\n"
+- msgstr "Fetchmail nie móg³ pobraæ poczty z %s@%s.\n"
+  
+  #: driver.c:1293
+- #, fuzzy
+  msgid "Service has been restored.\n"
+- msgstr "Wersja RPA %d.%d\n"
+  
+  #: driver.c:1324
+  #, c-format
+--- 340,381 ----
+  "at each cycle.  No future notifications will be sent until service\n"
+  "is restored."
+  msgstr ""
++ "Próba uzyskania autoryzacji nie powiod³a siê.\n"
++ "Oznacza to prawdopodobnie, ¿e has³o jest niew³a¶ciwe, ale niektóre\n"
++ "serwery maj± inne rodzaje b³êdów, których fetchmail nie mo¿e odró¿niæ\n"
++ "od tego, poniewa¿ nie zwracaj± u¿ytecznych komunikatów o b³êdzie.\n"
++ "\n"
++ "Demon fetchmaila bêdzie nadal próbowa³ siê po³±czyæ w ka¿dym cyklu.\n"
++ "Dalsze powiadomienia do czasu wznowienia us³ugi nie bêd± wysy³ane."
+  
+  #: driver.c:1251
+  #, c-format
+  msgid "Repoll immediately on %s@%s\n"
++ msgstr "Natychmiastowe ponowne ¶ci±ganie z %s@%s\n"
+  
+  #: driver.c:1256
+  #, c-format
+  msgid "Unknown login or authentication error on %s@%s\n"
++ msgstr "Nieznany login lub b³±d uwierzytelniania dla %s@%s\n"
+  
+  #: driver.c:1280
++ #, c-format
+  msgid "Authorization OK on %s@%s\n"
++ msgstr "Autoryzacja powiod³a siê dla %s@%s\n"
+  
+  #: driver.c:1286
++ #, c-format
+  msgid "Subject: fetchmail authentication OK on %s@%s\n"
++ msgstr "Subject: autoryzacja fetchmaila powiod³a siê dla %s@%s\n"
+  
+  #: driver.c:1289
++ #, c-format
+  msgid "Fetchmail was able to log into %s@%s.\n"
++ msgstr "Fetchmail móg³ zalogowaæ siê na %s@%s.\n"
+  
+  #: driver.c:1293
+  msgid "Service has been restored.\n"
++ msgstr "Us³uga zosta³a wznowiona.\n"
+  
+  #: driver.c:1324
+  #, c-format
+***************
+*** 361,374 ****
+  msgstr "ponowna próba po³±czenia z domy¶lnym folderem\n"
+  
+  #: driver.c:1342
+- #, fuzzy, c-format
+  msgid "%s at %s (folder %s)"
+- msgstr "%s na %s (folder %s)\n"
+  
+  #: driver.c:1350 rcfile_y.y:397
+- #, fuzzy, c-format
+  msgid "%s at %s"
+- msgstr "%s na %s\n"
+  
+  #. only used for ETRN
+  #: driver.c:1355
+--- 387,400 ----
+  msgstr "ponowna próba po³±czenia z domy¶lnym folderem\n"
+  
+  #: driver.c:1342
++ #, c-format
+  msgid "%s at %s (folder %s)"
++ msgstr "%s na %s (folder %s)"
+  
+  #: driver.c:1350 rcfile_y.y:397
++ #, c-format
+  msgid "%s at %s"
++ msgstr "%s na %s"
+  
+  #. only used for ETRN
+  #: driver.c:1355
+***************
+*** 377,385 ****
+  msgstr "Próba po³±czenia z %s\n"
+  
+  #: driver.c:1359
+- #, fuzzy, c-format
+  msgid "%d %s (%d %s) for %s"
+- msgstr "%d %s (%d przeczytanych) dla %s."
+  
+  #: driver.c:1360 driver.c:1367
+  msgid "messages"
+--- 403,411 ----
+  msgstr "Próba po³±czenia z %s\n"
+  
+  #: driver.c:1359
++ #, c-format
+  msgid "%d %s (%d %s) for %s"
++ msgstr "%d %s (%d %s) dla %s."
+  
+  #: driver.c:1360 driver.c:1367
+  msgid "messages"
+***************
+*** 390,398 ****
+  msgstr "list"
+  
+  #: driver.c:1363
+- #, fuzzy
+  msgid "seen"
+- msgstr " "
+  
+  #: driver.c:1366
+  #, c-format
+--- 416,423 ----
+  msgstr "list"
+  
+  #: driver.c:1363
+  msgid "seen"
++ msgstr "widzianych"
+  
+  #: driver.c:1366
+  #, c-format
+***************
+*** 400,417 ****
+  msgstr "%d %s dla %s."
+  
+  #: driver.c:1372
+- #, fuzzy, c-format
+  msgid " (%d octets).\n"
+- msgstr "(%d bajtów)."
+  
+  #: driver.c:1378
+- #, fuzzy, c-format
+  msgid "No mail for %s\n"
+- msgstr "Nie ma poczty dla %s"
+  
+  #: driver.c:1411
+  msgid "bogus message count!"
+- msgstr ""
+  
+  #: driver.c:1512
+  msgid "socket"
+--- 425,442 ----
+  msgstr "%d %s dla %s."
+  
+  #: driver.c:1372
++ #, c-format
+  msgid " (%d octets).\n"
++ msgstr "(%d bajtów).\n"
+  
+  #: driver.c:1378
++ #, c-format
+  msgid "No mail for %s\n"
++ msgstr "Nie ma poczty dla %s\n"
+  
+  #: driver.c:1411
+  msgid "bogus message count!"
++ msgstr "b³êdna liczba listów!"
+  
+  #: driver.c:1512
+  msgid "socket"
+***************
+*** 439,459 ****
+  
+  #: driver.c:1530
+  msgid "SMTP transaction"
+- msgstr "transakcja SMTP"
+  
+  #: driver.c:1533
+  msgid "DNS lookup"
+- msgstr "DNSu"
+  
+  #: driver.c:1536
+- #, fuzzy
+  msgid "undefined error\n"
+- msgstr "niezdefiniowany\n"
+  
+  #: driver.c:1547
+- #, fuzzy, c-format
+  msgid "%s error while delivering to SMTP host %s\n"
+- msgstr "b³±d %s podczas pobierania listów z %s\n"
+  
+  #: driver.c:1549
+  #, c-format
+--- 464,483 ----
+  
+  #: driver.c:1530
+  msgid "SMTP transaction"
++ msgstr "transakcji SMTP"
+  
+  #: driver.c:1533
+  msgid "DNS lookup"
++ msgstr "DNS-u"
+  
+  #: driver.c:1536
+  msgid "undefined error\n"
++ msgstr "niezdefiniowany b³±d\n"
+  
+  #: driver.c:1547
++ #, c-format
+  msgid "%s error while delivering to SMTP host %s\n"
++ msgstr "b³±d %s podczas dostarczania listów po SMTP do %s\n"
+  
+  #: driver.c:1549
+  #, c-format
diff --git a/po/pt_BR.gmo b/po/pt_BR.gmo
new file mode 100644
index 00000000..1145ad2b
--- /dev/null
+++ b/po/pt_BR.gmo
diff --git a/po/pt_BR.po b/po/pt_BR.po
new file mode 100644
index 00000000..f6e8ab8c
--- /dev/null
+++ b/po/pt_BR.po
@@ -0,0 +1,2951 @@
+# pt_BR translation for fetchmail 5.4.4
+# Copyright (C) 1999 Free Software Foundation, Inc.
+# Tradução e revisão
+# Jorge Godoy <godoy@conectiva.com.br>, 1998
+# Marcia Norie Nakaza <norie@conectiva.com.br>, 2000 
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail-5.4.4\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2000-07-28 09:40-03:00\n"
+"Last-Translator: Marcia Norie Nakaza <norie@conectiva.com.br>\n"
+"Language-Team: pt_BR <ldp-br@bazar.conectiva.com.br>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=ISO-8859-1\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Checando se %s é realmente o mesmo nó que %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Sim, o endereço IP deles bate\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Não, o endereço IP deles não bate\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr ""
+"falha na resolução de nomes ao procurar por `%s' durante a consulta de %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "não foi possível decodificar o desafio BASE64\n"
+
+#: cram.c:103
+#, fuzzy, c-format
+msgid "decoded as %s\n"
+msgstr "acordado em %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "erro kerberos %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [servidor informa '%*s'] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\t%d mensagem %d octetos de tamanho pulada pelo fetchmail.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "pulando a mensagem %d (%d octetos)"
+
+#: driver.c:549
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "pulando a mensagem %d (%d octetos)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr ""
+
+#: driver.c:568
+#, fuzzy
+msgid " (oversized)"
+msgstr " (muito grande, %d octetos)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr ""
+
+#: driver.c:600
+#, fuzzy, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "lendo mensagem %d de %d"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d %soctetos)"
+
+#: driver.c:606
+msgid "header "
+msgstr "cabeçalho "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d octetos no corpo da mensagem) "
+
+#: driver.c:736
+#, fuzzy, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr "mensagem %d não possui o tamanho esperado (%d atual != %d esperado)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " retida\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " eliminada\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " não eliminada\n"
+
+#: driver.c:809
+#, fuzzy, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+"limite de %d mensagens a recuperar atingido; %d mensagens mantidas no "
+"servidor\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "Um MDA enviou um SIGPIPE ou houve um erro de socket\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+"tempo esgotado após %d segundos esperando para conectar ao servidor %s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "tempo esgotado após %d segundos esperando pelo servidor %s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "tempo esgotado após %d segundos esperando por %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr "tempo esgotado após %d segundos esperando pelo receptor responder.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "tempo esgotado após %d segundos.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr ""
+"Assunto: o fetchmail tem notado repetidos vencimentos de temporização\n"
+"\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail notou mais que %d vencimentos de temporização enquanto tentava "
+"baixar mensagens de %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Isto pode significar que seu servidor de email está travado, ou\n"
+"que seu servidor SMTP está emperrado, ou que seu arquivo de caixa postal\n"
+"no servidor foi corrompido por um erro do servidor. Você pode rodar\n"
+"`fetchmail -v -v' para diagnosticar o problema.\n"
+"\n"
+"Fetchmail não vai consultar mais esta caixa postal até que seja reiniciado.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "comando de pré-conexão falhou com status %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "não foi possível encontrar caixa postal HESIOD para %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Servidor líder não possui nome.\n"
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "não foi possível encontrar o nome de DNS canônico para %s\n"
+
+#: driver.c:1053
+#, fuzzy
+msgid "internal inconsistency\n"
+msgstr "fetchmail: inconsistência interna\n"
+
+#: driver.c:1063
+#, fuzzy, c-format
+msgid "%s connection to %s failed"
+msgstr "Conexão %cMTP com %s falhou\n"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "a máquina é desconhecida."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "o nome válido mas sem endereço IP."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "erro irrecuperável no servidor de nomes."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "erro temporário no servidor de nomes."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "erro desconhecido de DNS %d."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+#, fuzzy
+msgid "SSL connection failed.\n"
+msgstr "Conexão %cMTP com %s falhou\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Erro de travamento (lock-busy) para %s@%s\n"
+
+#: driver.c:1188
+#, fuzzy, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Erro de travamento (lock-busy) para %s@%s\n"
+
+#: driver.c:1193
+#, fuzzy, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Falha de autorização para %s@%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr ""
+
+#: driver.c:1217
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr ""
+"Assunto: falha de autenticação do fetchmail\n"
+"\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "O fetchmail não pôde receber o correio eletrônico de %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+
+#: driver.c:1239
+#, fuzzy
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"A tentativa de obter autorização falhou.\n"
+"Isto provavelmente indica que sua senha é inválida, mas servidores POP3\n"
+"possuem outros tipos de falhas que fetchmail não consegue distinguir desta\n"
+"pois eles não enviam mensagens de erro úteis durante a falha no login.\n"
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr ""
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Erro desconhecido de login ou autenticação em %s@%s\n"
+
+#: driver.c:1283
+#, fuzzy, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Falha de autorização para %s@%s\n"
+
+#: driver.c:1289
+#, fuzzy, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr ""
+"Assunto: falha de autenticação do fetchmail\n"
+"\n"
+
+#: driver.c:1292
+#, fuzzy, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "O fetchmail não pôde receber o correio eletrônico de %s@%s.\n"
+
+#: driver.c:1296
+#, fuzzy
+msgid "Service has been restored.\n"
+msgstr "Serviço escolheu a versão %d.%d do RPA\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "selecionando ou tentando novamente baixar mensagens da pasta %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "selecionando ou tentando novamente baixar mensagens da pasta padrão\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s em %s (pasta %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s em %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Baixando %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d visualizadas) para %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "mensagens"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "mensagem"
+
+#: driver.c:1366
+msgid "seen"
+msgstr ""
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s para %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d octetos).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "Nenhuma mensagem para %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr ""
+
+#: driver.c:1515
+msgid "socket"
+msgstr "socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "cabeçalho RFC822 ruim ou faltando"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "sincronização cliente/servidor"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "protocolo cliente/servidor"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "arquivo de lock existente no servidor"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "Transação SMTP"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "Busca no DNS"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "erro não definido\n"
+
+#: driver.c:1550
+#, fuzzy, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "erro %s enquanto baixando mensagens de %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "erro %s enquanto baixando mensagens de %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "comando de pós-conexão falhou com status %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Suporte a Kerberos V4 não incluído (linkado).\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Suporte a Kerberos V5 não incluído (linkado).\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Opção --flush não é suportada com %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Opção --all não é suportada com %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Opção --limit não é suportada com %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Você não existe. Vá embora.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: não foi possível determinar sua máquina!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "gethostbyname falhou para %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "Servidor SMTP de %s não suporta ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "Servidor SMTP de %s não suporta ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Armazenamento para %s iniciado\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "Nenhuma mensagem esperando para %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Mensagens pendentes para %s iniciadas\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Incapaz de armazenar mensagens para o nó %s\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Nó %s não permitido: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "Erro de sintaxe ETRN\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "Erro de sintaxe nos parâmetros ETRN\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Erro ETRN desconhecido %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "Opção --keep não é compatível com ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "Opção --flush não é compatível com ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "Opção --remote não é compatível com ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "Opção --check não é compatível com ETRN\n"
+
+#: fetchmail.c:156
+#, fuzzy
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: fork falhou\n"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr ""
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Este é o fetchmail versão %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Utilizando opções da linha de comando%s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " e "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr ""
+"Nenhum servidor de correio eletrônico configurado -- talvez %s esteja "
+"faltando?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: nenhum servidor de correio eletrônico foi especificado.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: nenhum outro fetchmail está rodando\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: erro eliminando %s fetchmail em %d; desistindo.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "segundo plano"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "primeiro plano"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %s fetchmail em %d terminado.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: não é possível checar por mensagens enquanto outro fetchmail está "
+"rodando para a mesma máquina.\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: não é possível receber mensagens das máquinas especificadas\n"
+"enquanto houver outro fetchmail rodando em %d.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: outro fetchmail está rodando em primeiro plano em %d.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: não é possível aceitar opções com outro fetchmail rodando em \n"
+"segundo plano.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: fetchmail rodando em segundo plano em %d despertado.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr ""
+"fetchmail: processo mais antigo rodando em %d morreu misteriosamente.\n"
+
+#: fetchmail.c:460
+#, fuzzy, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: não é possível encontrar uma senha para %s@s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Digite a senha para %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "iniciando fetchmail %s como daemon \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr ""
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "não foi possível fazer checagem de horário de %s (erro %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "reiniciando fetchmail (%s mudou) \n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "tentativa de re-executar fetchmail falhou.\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"consulta de %s pulada (falha de autenticação ou muitos vencimentos de "
+"temporização)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "intervalo não atingido, não consultando %s\n"
+
+#: fetchmail.c:667
+#, fuzzy
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:669
+#, fuzzy
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:671
+#, fuzzy
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:673
+#, fuzzy
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:675
+#, fuzzy
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:677
+#, fuzzy
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:679
+#, fuzzy
+msgid "Query status=6 (IOERR)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:681
+#, fuzzy
+msgid "Query status=7 (ERROR)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:683
+#, fuzzy
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:685
+#, fuzzy
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:687
+#, fuzzy
+msgid "Query status=10 (SMTP)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:689
+#, fuzzy
+msgid "Query status=11 (DNS)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:691
+#, fuzzy
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:693
+#, fuzzy
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Situação da consulta=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Todas as conexões estão travadas. Encerrando.\n"
+
+#: fetchmail.c:748
+#, fuzzy, c-format
+msgid "sleeping at %s\n"
+msgstr "fetchmail: `dormindo' em %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "acordado por %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "acordado pelo sinal %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "acordado em %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "encerramento normal, status %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "não foi possível checar o horário do arquivo de controle de execução\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr ""
+"Atenção: múltiplas entradas para a máquina %s no arquivo de configuração\n"
+
+#: fetchmail.c:1116
+#, fuzzy
+msgid "SSL support is not compiled in.\n"
+msgstr "O suporte a POP2 não está configurado.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: warning: nenhum DNS disponível para checar buscas com múltiplas\n"
+"entregas de %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "configuração de %s inválida, número da porta não pode ser negativo\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "configuração de %s inválida, o RPOP exige uma porta privilegiada\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr "configuração de %s inválida, LMTP não pode usar a porta SMTP padrão\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "fetchall e modo daemon juntos está errado!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "encerrado com o sinal %d\n"
+
+#: fetchmail.c:1339
+#, fuzzy, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s consultando %s (protocolo %s) em %s\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "O suporte a POP2 não está configurado.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "O suporte a POP3 não está configurado.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "O suporte a IMAP não está configurado.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "O suporte a ETRN não está configurado.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "Não é possível usar ETRN sem a função gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+#, fuzzy
+msgid "ODMR support is not configured.\n"
+msgstr "O suporte a POP2 não está configurado.\n"
+
+#: fetchmail.c:1411
+#, fuzzy
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "Não é possível usar ETRN sem a função gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "protocolo não suportado escolhido.\n"
+
+#: fetchmail.c:1427
+#, fuzzy, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s consultando %s (protocolo %s) em %s\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "Intervalo de consulta é %d segundos\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Arquivo de registro é %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Arquivo de identificação é %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Mensagens de progresso serão gravadas pelo syslog\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail fará mascaramento e não gerará `Received'\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr ""
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr "Fetchmail reenviará mensagens multidrop mal endereçadas para %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Fetchmail irá enviar mensagens de correio de erro para o postmaster.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail irá enviar mensagens de correio de erro para o remetente.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Opções para consulta de %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Mensagens serão recuperadas via %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  Consulta deste servidor irá ocorrer a cada %d intervalos.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  O verdadeiro nome do servidor é %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr ""
+"  Esta máquina %s será consultada quando nenhuma máquina for\n"
+"especificada.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr "não"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr " "
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  A senha será solicitada.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  Segredo APOP = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  Identificação RPOP = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "   Senha = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  Protocolo é KPOP com autenticação Kerberos %s"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  Protocolo é %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (usando serviço %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (usando opções de segurança de rede %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (usando porta %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (usando porta padrão)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (forçando o uso de UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr ""
+
+#: fetchmail.c:1536
+#, fuzzy
+msgid "  Password authentication will be forced.\n"
+msgstr "Autenticação OTP é suportada\n"
+
+#: fetchmail.c:1539
+#, fuzzy
+msgid "  NTLM authentication will be forced.\n"
+msgstr "Autenticação NTLM é suportada\n"
+
+#: fetchmail.c:1542
+#, fuzzy
+msgid "  OTP authentication will be forced.\n"
+msgstr "Autenticação OTP é suportada\n"
+
+#: fetchmail.c:1545
+#, fuzzy
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "Autenticação CRAM-MD5 é suportada\n"
+
+#: fetchmail.c:1548
+#, fuzzy
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "Autenticação GSS é suportada\n"
+
+#: fetchmail.c:1551
+#, fuzzy
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Pré-autenticação Kerberos V4 ativada.\n"
+
+#: fetchmail.c:1554
+#, fuzzy
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Pré-autenticação Kerberos V5 ativada.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  Criptografia end-to-end assumida.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr ""
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1566
+#, fuzzy, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  Protocolo é %s"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr ""
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr ""
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr ""
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr ""
+"  O tempo máximo para não obtenção de resposta do servidor é %d segundos"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (padrão).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Caixa de correio padrão selecionada.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  As caixas de correio selecionadas são:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s mensagens serão recuperadas (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "Todas as"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "Apenas as novas"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  As Mensagens baixadas %s serão mantidas no servidor (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+"  Mensagens antigas %s serão eliminadas antes da recuperação de mensagens \n"
+"(--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr ""
+"  A reescrita de endereços no servidor local está %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "ativada"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "desativada"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  A eliminação do retorno de carro (CR) está %s (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Forçar retorno de carro (CR) está %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr ""
+"  A interpretação de Content-Transfer-Encoding está %s (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  A decodificação MIME está %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  Inatividade após consulta é %s (inatividade %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  As linhas de status não vazias serão %s (dropstatus %s)\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "descartadas"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "mantidas"
+
+#: fetchmail.c:1625
+#, fuzzy, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  As linhas de status não vazias serão %s (dropstatus %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  O tamanho limite por mensagem é %d octetos (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  Nenhum limite para tamanho de mensagens (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  O intervalo de aviso de tamanho de mensagem é de %d segundos (--warnings \n"
+"%d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr "  Avisos de tamanho a cada recebimento (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  O limite de mensagem recebida é %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  Nenhum limite para mensagem recebida (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  O limite de mensagem recebida é %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Nenhum limite para tamanho de mensagens (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  O limite de lote de mensagens SMTP é %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  Nenhum limite de lote de mensagens SMTP (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr "  O intervalo de deleção entre eliminações é %d (--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Nenhuma eliminação (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr ""
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (padrão)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  As mensagens serão anexadas a %s como BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  As mensagens serão entregues com \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  As mensagens serão re-enviadas via %cMTP para:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  O nome da máquina na linha MAIL FROM será %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr ""
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  As respostas reconhecidas de blocos spam são:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Bloqueio de spam desabilitado\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  A conexão do servidor será efetuada com \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Nenhum comando de pré-conexão.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  A conexão com o servidor será derrubada com \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Nenhum comando de pós-conexão.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Nenhum nome local declarado para esta máquina.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Modo de múltipla entrega (multi-drop): "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Modo de entrega simples (single-drop): "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d nome(s) local(is) reconhecido(s).\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  A busca no DNS por endereços de múltipla entrega está %s.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr ""
+"  Os apelidos de servidores serão comparados com endereços de múltipla\n"
+"entrega por "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "endereço IP.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "nome.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  O roteamento de endereços de envelope está desabilitado\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Assume-se que o cabeçalho do envelope esteja: %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Recebido"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Número de cabeçalhos de envelope  a serem processados: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  O prefixo %s será removido da identificação do usuário\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  Nenhuma remoção de prefixo\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Apelidos pré-declarados do servidor de correio eletrônico:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Domínios locais:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  A conexão precisa se dar pela interface %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Não foi especificada nenhuma exigência de interface.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Ciclo de consultas monitorará %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Nenhuma interface de monitoramento foi especificada.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr "  As conexões com o servidor se darão via plugin %s (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Nenhum comando \"plugin\" especificado.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  As conexões com o cliente se darão via \"plugout\" %s (--plugout %s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Nenhum comando \"plugout\" especificado.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Nenhuma identificação de usuário gravada a partir desta máquina.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d identificações de usuários gravadas.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr ""
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Propriedades de passagem \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+#, fuzzy
+msgid "alloca failed"
+msgstr "malloc falhou\n"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "ERRO: não há suporte à rotina getpassword()\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"Sinal SIGINT recebido... saindo.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Não foi possível obter nome do serviço para [%s]\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "Usando nome do serviço [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Enviando credenciais\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Erro na troca de credenciais\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Não foi possível desempacotar dados do nível de segurança\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Troca de credenciais completa\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Servidor requer integridade e/ou privacidade\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Desempacotadas marcas de nível de segurança: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "Tamanho máximo do símbolo GSS é %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Erro criando solicitação de nível de segurança\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Liberando credenciais GSS\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Erro na liberação de credenciais\n"
+
+#: idle.c:62
+#, fuzzy, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr ""
+"fetchmail: tarefa aguardando por %d segundos.\n"
+"\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protocolo identificado como IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protocolo identificado como IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protocolo identificado como IMAP2 ou IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr ""
+
+#: imap.c:460
+#, fuzzy
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "Capacidade de LOGIN exigida não é suportada pelo servidor\n"
+
+#: imap.c:482
+#, fuzzy
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Capacidade de LOGIN exigida não é suportada pelo servidor\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Capacidade de LOGIN exigida não é suportada pelo servidor\n"
+
+#: imap.c:641 imap.c:707
+#, fuzzy
+msgid "expunge failed\n"
+msgstr "execl(%s) falhou\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "nova tentativa de baixar mensagens falhou\n"
+
+#: imap.c:671
+#, fuzzy, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "Nenhuma mensagem esperando para %s\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "seleção de caixa postal falhou\n"
+
+#: imap.c:685
+#, fuzzy, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "Nenhuma mensagem esperando para %s\n"
+
+#: imap.c:711
+#, fuzzy, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "Nenhuma mensagem esperando para %s\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "falha na busca por mensagens não vistas\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u é não vista\n"
+
+#: imap.c:776 pop3.c:679
+#, fuzzy, c-format
+msgid "%u is first unseen\n"
+msgstr "%u é não vista\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"Não foi possível abrir a interface kvm. Certifique-se que fetchmail está "
+"SGID kmem."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr ""
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr ""
+
+#: interface.c:426
+#, fuzzy
+msgid "get_ifinfo: malloc failed"
+msgstr "malloc falhou\n"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr ""
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr ""
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr ""
+
+#: interface.c:540
+#, fuzzy, c-format
+msgid "No IP address found for %s"
+msgstr "nenhum endereço Received encontrado\n"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "faltando endereço IP da interface\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "endereço IP da interface inválido\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "máscara IP da interface inválida\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "atividade em %s -percebida- como %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "pulando mensagens de %s, %s está parado\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "pulando mensagens de %s, endereço IP de %s excluído\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "atividade em %s checada como %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "pulando mensagens de %s, %s inativo\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "atividade em %s foi %d, é %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "não foi possível decodificar o desafio BASE64 inicial\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "%s no bilhete não combina com -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "instância não nula (%s) pode causar comportamento estranho\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "não foi possível decodificar resposta \"pronto\" de BASE64\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "erro no desafio\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: removendo arquivos de trava antigos\n"
+
+#: lock.c:122
+#, fuzzy
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: socketpair falhou\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "atenção: encontrado \"%s\" antes de qualquer nome de máquina"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: atenção: encontrado \"%s\" antes de qualquer nome de máquina\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: warning: símbolo desconhecido \"%s\"\n"
+
+#: odmr.c:65
+#, fuzzy, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "Servidor SMTP de %s não suporta ETRN\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr ""
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr ""
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr ""
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr ""
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr ""
+
+#. Authentication required
+#: odmr.c:125
+#, fuzzy
+msgid "Authentication required.\n"
+msgstr "Autenticação OTP é suportada\n"
+
+#: odmr.c:129
+#, fuzzy, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Erro ETRN desconhecido %d\n"
+
+#: odmr.c:244
+#, fuzzy
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "Opção --keep não é compatível com ETRN\n"
+
+#: odmr.c:248
+#, fuzzy
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "Opção --flush não é compatível com ETRN\n"
+
+#: odmr.c:252
+#, fuzzy
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "Opção --remote não é compatível com ETRN\n"
+
+#: odmr.c:256
+#, fuzzy
+msgid "Option --check is not supported with ODMR\n"
+msgstr "Opção --check não é compatível com ETRN\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr ""
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Não foi possível decodificar o desafio OTP\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Frase-senha secreta: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "Cadeia '%s' não é uma cadeia de números válidos.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "Valor da cadeia '%s' é %s que %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "menor"
+
+#: options.c:211
+msgid "larger"
+msgstr "maior"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Protocolo `%s' inválido foi especificado.\n"
+
+#: options.c:429
+#, fuzzy, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Pré-autenticação `%s' inválida foi especificada.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: suporte a segurança na rede está desativado\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "uso: fetchmail [opções] [servidor ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  As opções são:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        mostra esta tela de ajuda\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     mostra informações sobre a versão\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       checa por mensagens sem baixá-las\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      trabalha silenciosamente\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr ""
+"  -v, --verbose     trabalha barulhentamente (saídas para diagnóstico)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      roda como um servidor uma vez a cada n segundos\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr ""
+"  -N, --nodetach    não desconecta o processo servidor do seu terminal\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        elimina processo servidor\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     especifica o nome do arquivo de log\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      usa o syslog(3) para a maioria das mensagens quando\n"
+"                    estiver rodando como servidor\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   não escreve `Received' & ativa mascaramento da máquina\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr ""
+"  -f, --fetchmailrc especifica arquivo de controle de execução alternativo\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr ""
+"  -i, --idfile      especifica arquivo de identidades de usuários \n"
+"                    alternativo\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  especifica o destinatário usado em último caso\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr "      --nobounce    redireciona mensagens erradas para o postmaster.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   especificação de interface exigida\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     monitora a atividade na interface\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         habilita sessão ssl criptografada\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      arquivo contendo a chave ssl privada\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     certificado ssl do cliente\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr ""
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+"      --plugin      especifica um comando externo para abrir uma conexão\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     especifica um comando externo para abrir uma conexão "
+"smtp\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    especifica o protocolo de retirada (ver página de \n"
+"                    manual)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr "  -U, --uidl        força o uso de UIDLs (somente para pop3)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        Porta TCP para conexão\n"
+
+#: options.c:694
+#, fuzzy
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr "      --preauth     tipo de pré-autenticação (senha/kerberos/ssh)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr ""
+"  -t, --timeout     tempo limite para não obtenção de resposta do servidor\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope    cabeçalho do endereço de envelope\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+"  -Q, --qvirtual    prefixo para remover da identificação de um usuário "
+"local\n"
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr ""
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr ""
+"  -u, --username    especifica a identificação do usuário no servidor\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         recupera mensagens antigas e novas\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      apaga novas mensagens após a recuperação\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep        não apaga novas mensagens após recuperação\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       apaga mensagens antigas do servidor\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   não reescreve os cabeçalhos das mensagens\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -l, --limit       não recupera mensagens acima de um dado tamanho\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    intervalo entre avisos de notificação de e-mail\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      ativa solicitação de segurança IP\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    configura a máquina SMTP para reenvio\n"
+
+#: options.c:714
+#, fuzzy
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr ""
+"  -B, --fetchlimit  configura o limite de recepção para conexões com o\n"
+"                    servidor\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr ""
+"  -D, --smtpaddress configura o domínio de entrega do SMTP a ser usado\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr ""
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    configura o valor das respostas anti-spam\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr "  -b, --batchlimit  configura o limite de lote para conexões SMTP\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+"  -B, --fetchlimit  configura o limite de recepção para conexões com o\n"
+"                    servidor\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr ""
+"  -B, --fetchlimit  configura o limite de recepção para conexões com o\n"
+"                    servidor\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr "  -e, --expunge     configura o máximo de deleções entre eliminações\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "      --mda         configura o MDA a ser usado para reenvio\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       configura o arquivo de saída BSMTP\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        usa LMTP (RFC2033) para entrega\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder      especifica o nome da pasta remota\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "Data/horário APOP exigidos não encontrados na saudação\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Erro de sintaxe na data/horário da saudação\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "Solicitação de protocolo não definida em POP3_auth\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "arquivo de travamento presente! Há outra sessão ativa?\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr "Mensagens inseridas numa lista no servidor. Não posso tratar isso.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "erro de protocolo\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "erro de protocolo durante a obtenção de UIDLs\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "Opção --remote não é compatível com POP3\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr ""
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr ""
+
+#: rcfile_y.y:218
+#, fuzzy
+msgid "invalid security request"
+msgstr "Erro criando solicitação de nível de segurança\n"
+
+#: rcfile_y.y:224
+#, fuzzy
+msgid "network-security support disabled"
+msgstr "fetchmail: suporte a segurança na rede está desativado\n"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr ""
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr ""
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr ""
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr ""
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr ""
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Erro desconhecido do sistema"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (mensagem de registro incompleta)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "erro parcial sobrecarga no buffer de mensagem"
+
+#: rfc822.c:74
+#, fuzzy, c-format
+msgid "About to rewrite %s"
+msgstr "prestes a entregar para: %s\n"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr ""
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Sucesso"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr "Usuário restrito (algo errado com a conta)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "Identificação de usuário ou frase-senha inválidos"
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr "Erro fatal"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "RPA token 2: Erro de decodificação Base64\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Serviço escolheu a versão %d.%d do RPA\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Desafio de serviço (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Data/horário do serviço %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "Erro no comprimento do token 2 RPA\n"
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Lista de domínios: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "Erro RPA na cadeia serviço@domínio\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA token 4: Erro de decodificação Base64\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Autenticação de usuário (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "status RPA: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "Erro no comprimento do símbolo 4 RPA\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "Você foi rejeitado pelo RPA: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "Você foi rejeitado pelo RPA por motivos desconhecidos\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "Erro no comprimento da autenticação de usuário RPA: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "Erro no comprimento da chave da sessão RPA: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "Autenticação de _serviço_ RPA falhou. Enganar o servidor?\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Chave de sessão estabelecida:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "Autorização RPA completa\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Resposta recebida\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Recebido retorno de resposta %d [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "Hdr não é 60\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "Erro no comprimento do Token\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "Comprimento do símbolo %d não combina com rxlen %d\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Campo mecanismo incorreto\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "erro dec64 no caractere %d: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Entrada de dados binários:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Saída de dados:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "Cadeia RPA muito longa\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA falhou na abertura de /dev/urandom. Isto não deveria\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    impedi-lo de se conectar, mas significa que\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    você não pode ter certeza de estar falando com\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    o serviço que você pensa estar (ataques\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr ""
+"    de re-tentativa por parte de um serviço desonesto são possíveis.)\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Desafio de usuário:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "MD5 está sendo aplicado ao bloco de dados:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "O resultado MD5 é: \n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "repassando para %s\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr ""
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr ""
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr ""
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "Erro %cMTP: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "Abertura de arquivo BSMTP ou escrita de preâmbulo falhou\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "Cliente %cMTP não gosta do endereço do destinatário `%s'\n"
+
+#: sink.c:989
+#, fuzzy, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "Cliente %cMTP não gosta do endereço do destinatário `%s'\n"
+
+#: sink.c:1027
+#, fuzzy
+msgid "no address matches; no postmaster set.\n"
+msgstr "não combina com nada localmente, repassando para %s\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr "não é possível nem mandar para %s!\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "não combina com nada localmente, repassando para %s\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "prestes a entregar para: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "Abertura MDA falhou\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "Conexão %cMTP com %s falhou\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr ""
+
+#: sink.c:1339
+#, fuzzy, c-format
+msgid "MDA died of signal %d\n"
+msgstr "acordado pelo sinal %d\n"
+
+#: sink.c:1342
+#, fuzzy, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr ""
+"O MDA foi encerrado anormalmente ou retornou status diferente de zero\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr ""
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr "Encerramento de mensagem ou fechamento de arquivo BSMTP falhou\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "Cliente SMTP recusou a entrega\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "Erro na entrega LMTP no EOM\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "Resposta não-503 para o EOM LMTP: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+
+#: smtp.c:86
+#, fuzzy
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "Autenticação CRAM-MD5 é suportada\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr ""
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr ""
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr ""
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:361 smtp.c:384
+#, fuzzy
+msgid "smtp listener protocol error\n"
+msgstr "erro de protocolo\n"
+
+#: socket.c:108 socket.c:134
+#, fuzzy
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: fork falhou\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: socketpair falhou\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: fork falhou\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "dup2 falhou\n"
+
+#: socket.c:186
+#, fuzzy, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "rodando %s %s %s\n"
+
+#: socket.c:189
+#, fuzzy, c-format
+msgid "execvp(%s) failed\n"
+msgstr "execl(%s) falhou\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: comprimento de endereço ilegal recebido para máquina %s\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr ""
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr ""
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr ""
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr ""
+
+#: socket.c:792
+#, fuzzy, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Data/horário do serviço %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr ""
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr ""
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr ""
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr ""
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr ""
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr ""
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr ""
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr ""
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr ""
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr ""
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr ""
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr ""
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr ""
+
+#: socket.c:948
+#, fuzzy, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr "Protocolo `%s' inválido foi especificado.\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr ""
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr ""
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr ""
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s mapeado localmente para %s\n"
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "passou por %s combinando com %s\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analisando linha Received:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "linha aceita, %s é um apelido do servidor de email\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "linha rejeitada, %s não é um apelido do servidor de email\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "nenhum endereço Received encontrado\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "encontrado endereço Received `%s'\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr ""
+"encontrado o delimitador de mensagens durante varredura de cabeçalhos\n"
+
+#: transact.c:552
+#, fuzzy
+msgid "incorrect header line found while scanning headers\n"
+msgstr ""
+"encontrado o delimitador de mensagens durante varredura de cabeçalhos\n"
+
+#: transact.c:554
+#, fuzzy, c-format
+msgid "line: %s"
+msgstr "Baixando %s\n"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "não combina com nada localmente, repassando para %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "reenvio e remoção suprimidos devido a erro de DNS\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "escrevendo cabeçalhos RFC822\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "nenhum endereço de destino combina com o valor local declarado"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "endereço do destinatário %s não combina com nenhum nome local"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "a mensagem possui NULs inseridos"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "Cliente SMTP rejeitou o endereço do destinatário: "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "escrevendo o texto da mensagem\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr ""
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr ""
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr ""
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr ""
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, c-format
+msgid "Merged UID list from %s:"
+msgstr ""
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr ""
+
+#: uid.c:542
+#, fuzzy
+msgid "swapping UID lists\n"
+msgstr "lista de UID gravada\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr ""
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "lista de UID gravada\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr ""
+
+#: uid.c:616
+#, fuzzy
+msgid "Writing fetchids file.\n"
+msgstr "iniciando fetchmail %s como daemon \n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "malloc falhou\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "realloc falhou\n"
+
+#~ msgid "fetchmail: %s connection to %s failed"
+#~ msgstr "fetchmail: conexão de %s com %s falhou"
+
+#~ msgid "Skipping message %d, length -1\n"
+#~ msgstr "Pulando a mensagem %d, tamanho -1\n"
+
+#~ msgid "authorization"
+#~ msgstr "autorização"
+
+#~ msgid "%s: can't find your name and home directory!\n"
+#~ msgstr "%s: não foi possível encontrar seu nome e diretório pessoal!\n"
+
+#~ msgid "Lockfile at %s\n"
+#~ msgstr "Arquivo de trava em %s\n"
+
+#~ msgid "fetchmail: cannot allocate memory for lock name.\n"
+#~ msgstr ""
+#~ "fetchmail: não foi possível alocar memória para o nome do arquivo de "
+#~ "trava.\n"
+
+#~ msgid "Could not decode initial BASE64 challenge\n"
+#~ msgstr "Não foi possível decodificar o desafio BASE64 inicial\n"
+
+#~ msgid "Requesting authorization as %s\n"
+#~ msgstr "Solicitando autorização como %s\n"
+
+#~ msgid "Required GSS capability not supported by server\n"
+#~ msgstr "Capacidades GSS exigidas não é suportada pelo servidor\n"
+
+#~ msgid "KERBEROS_V4 authentication is supported\n"
+#~ msgstr "Autenticação KERBEROS_V4 é suportada\n"
+
+#~ msgid "Required KERBEROS_V4 capability not supported by server\n"
+#~ msgstr "Capacidade KERBEROS_V4 exigida não é suportada pelo servidor\n"
+
+#~ msgid "Required CRAM-MD5 capability not supported by server\n"
+#~ msgstr "Capacidade CRAM-MD5 exigida não é suportada pelo servidor\n"
+
+#~ msgid ""
+#~ "This could mean that your mailserver is stuck, or that your SMTP "
+#~ "listener\n"
+#~ msgstr ""
+#~ "Isso pode significar que seu servidor de correio eletrônico está "
+#~ "travado \n"
+#~ "ou que o cliente SMTP\n"
+
+#~ msgid ""
+#~ "is wedged, or that your mailbox file on the server has been corrupted by\n"
+#~ msgstr ""
+#~ "está travado, ou que seu arquivo de caixa de correio foi corrompido por\n"
+
+#~ msgid ""
+#~ "a server error.  You can run `fetchmail -v -v' to diagnose the problem.\n"
+#~ msgstr ""
+#~ "um erro no servidor. Você pode executar `fetchmail -v -v' para \n"
+#~ "diagnosticar o problema.\n"
+
+#~ msgid "Fetchmail won't poll this mailbox again until you restart it.\n"
+#~ msgstr ""
+#~ "O fetchmail não vai receber dessa caixa postal novamente até que \n"
+#~ "você o reinicie.\n"
+
+#~ msgid "This probably means your password is invalid.\n"
+#~ msgstr "Isso significa, provavelmente, que sua senha está incorreta.\n"
+
+#~ msgid ": Error %d\n"
+#~ msgstr ": Erro %d\n"
diff --git a/po/sk.gmo b/po/sk.gmo
new file mode 100644
index 00000000..1e1f8c3e
--- /dev/null
+++ b/po/sk.gmo
diff --git a/po/sk.po b/po/sk.po
new file mode 100644
index 00000000..a39fed6e
--- /dev/null
+++ b/po/sk.po
@@ -0,0 +1,2825 @@
+# Slovak Messages for fetchmail.
+# Copyright (C) 2002 Free Software Foundation, Inc.
+# This file is distributed under the same license as the fetchmail package.
+# Lubos Vitek <lubos_vitek@yahoo.com>, 2002, 2003.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 6.2.2\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2003-06-12 15:02+00\n"
+"Last-Translator: Lubos Vitek <lubos_vitek@yahoo.com>\n"
+"Language-Team: Slovak <sk-i18n@lists.linux.sk>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=ISO-8859-2\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "Kontrolujem, èi %s je naozaj ten istý uzol ako %s\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Áno, ich IP adresy súhlasia\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Nie, ich IP adresy nesúhlasia\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, fuzzy, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr "Nameserver-zlyhanie pri hµadaní `%s' poèas komunikácie s %s.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "nemô¾em dekódova» BASE64 výzvu\n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "dekódované ako %s\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "Kerberos-chyba %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [server odpovedal '%*s'] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Predmet: Fetchmail-varovanie: nadrozmerná správa.\n"
+"\n"
+"Nasledujúca nadrozmerná správa zostáva na po¹tovom serveri %s:"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\t%d msg %d oktetov dlhé vynechané fetchmailom.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "vynechávam správu %s@%s:%d (%d oktetov)"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "vynechávam správu %s@%s:%d (%d oktetov)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr "(då¾ka -1)"
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr "(nadrozmerné)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr "nemô¾em získa» záhlavie, správa %s@%s:%d (%d oktetov)\n"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "èítam správu %s@%s:%d z %d"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d %s oktetov)"
+
+#: driver.c:606
+msgid "header "
+msgstr "záhlavie "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (%d oktetov v tele správy)"
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr "správa %s@%s:%d nemala oèakávanú då¾ku (%d aktuálne != %d oèakávané)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " ponechané\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " vyprázdnené\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " nevyprázdnené\n"
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr "fetchlimit %d dosiahnutý; %d správ ponecháných na serveri %s úèet %s\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "SIGPIPE obdr¾ané z MDA alebo chyba v prúde dát zo socketu\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+"vypr¹anie èasového limitu po %d sekundách pri èakaní na pripojenie na server "
+"%s.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr ""
+"vypr¹anie èasového limitu po %d sekundách pri èakaní na odpoveï zo servera %"
+"s.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "vypr¹anie èasového limitu po %d sekundách pri èakaní na %s.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr ""
+"vypr¹anie èasového limitu po %d sekundách pri èakaní na odpoveï z "
+"prijímaèa.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "vypr¹anie èasového limitu po %d sekundách.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Predmet: fetchmail spozoroval opakované vypr¹anie èasových limitov\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail zistil viac ako %d vypr¹aní èasových limitov pri pokusoch\n"
+"získa» po¹tu z %s@%s.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"To mô¾e znamena», ¾e vá¹ po¹tový server zlyhal, alebo vá¹ SMTP\n"
+"server nefunguje správne, alebo vá¹ po¹tový prieèinok na serveri bol\n"
+"po¹kodený chybou servera. Mô¾ete spusti» `fetchmail -v -v'\n"
+"pre diagnostiku problému.\n"
+"\n"
+"Fetchmail nebude pracova» s týmto prieèinkom, pokiaµ ho nespustíte znova.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "príkaz spú¹»aný pred spojením nebol úspe¹ný, návratový stav: %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "nemô¾em nájs» HESIOD po¹tovú schránku pre %s\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Vedúci server nemá meno.\n"
+
+#: driver.c:1016
+#, fuzzy, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "nemô¾em nájs» kanonické DNS meno pre %s\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "vnútorná nezrovnalos»\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "%s spojení s %s bolo neúspe¹ných"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "hostiteµ je neznámy."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "meno je platné ale nemá IP adresu."
+
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "neodstrániteµná chyba servera mien."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "doèasná chyba servera mien."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "neznáma DNS chyba %d."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Predmet: Fetchmail varovanie - nedosiahnuteµný server.\n"
+"\n"
+"Fetchmail sa nemohol spoji» s po¹tovým serverom %s:"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "SSL spojenie neúspe¹né.\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Zámka-chyba zaneprázdnenia pri %s@%s\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Chyba zaneprázdnenia servra pri %s@%s\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "Chyba autorizácie pri %s@%s%s\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr " (predtým autorizovaný)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Predmet: autentifikácia fetchmailu neúspe¹ná pri %s@%s\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail nemohol získa» po¹tu z %s@%s.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Pokus o autorizáciu bol neúspe¹ný.\n"
+"Preto¾e predchádzajúce pokusy o autorizáciu tohoto  spojenia boli úspe¹né,\n"
+"asi existuje iná príèina chyby spojenia (zaneprázdnený server a pod.)\n"
+"ktorú fetchmail nevie rozpozna», preto¾e server neposlal potrebné\n"
+"chybové hlásenie.\n"
+"\n"
+"Napriek tomu ak ste skutoène zmenili údaje o va¹om konte po ¹tarte\n"
+"fetchmail démona, potrebujete tento démon zastavi», zmeni» konfiguráciu\n"
+"fetchmail-u a potom démon znovu spusti».\n"
+"\n"
+"Fetchmail démon bude naïalej pokraèova» v práci a bude sa pokú¹a»\n"
+"o spojenie. Ïal¹ie upozornenia nebudú zasielané, pokiaµ slu¾ba\n"
+"nebude obnovená."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Pokus o autorizáciu bol neúspe¹ný.\n"
+"Znamená to pravdepodobne, ¾e va¹e heslo je neplatné, av¹ak niektoré\n"
+"servre majú iné chybové módy, ktoré fetchmail nevie rozpozna»,\n"
+"preto¾e servre neposlali potrebné chybové hlásenia ohµadom prihlásenia.\n"
+"\n"
+"Fetchmail démon bude naïalej pokraèova» v práci a bude sa pokú¹a»\n"
+"o spojenie. Ïal¹ie upozornenia nebudú zasielané, pokiaµ slu¾ba\n"
+"nebude obnovená."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr "Okam¾ité stiahnutie z %s@%s\n"
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "Neznáma chyba pri prihlásení alebo autentifikácii na %s@%s\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "Autentifikácia OK na %s@%s\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Predmet: fetchmail autentifikácia OK na %s@%s\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail bol úspe¹ný pri prihlásení na %s@%s.\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "Slu¾ba bola obnovená.\n"
+
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "výber alebo stiahnutie prieèinka %s\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "výber alebo stiahnutie ¹tandardného prieèinka\n"
+
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%s pri %s (prieèinok %s)"
+
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%s pri %s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "Obnovujem %s\n"
+
+#: driver.c:1362
+#, fuzzy, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%d %s (%d videné) pre %s"
+
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "správ"
+
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "správa"
+
+#: driver.c:1366
+msgid "seen"
+msgstr ""
+
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%d %s pre %s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d oktetov).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "®iadna po¹ta pre %s\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "neplatný poèet správ!"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "Socket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "chýbajúce alebo neplatné záhlavie RFC822"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "klient/server synchronizácia"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "klient/server protokol"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "zámka na servri zaneprázdnená"
+
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "SMTP transakcia"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "DNS vyhµadávanie"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "neznáma chyba\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "%s-chyba pri doruèovaní na SMTP server %s\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "%s-chyba pri s»ahovaní po¹ty z %s\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "príkaz spú¹»aný po spojení nebol úspe¹ný, návratový stav: %d\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Podpora Kerberos V4 nebola pripojená.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Podpora Kerberos V5 nebola pripojená.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "Voµba --flush nie je podporovaná s %s\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "Voµba --all nie je podporovaná s %s\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "Voµba --limit nie je podporovaná s %s\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: QMAILINJECT-premenná prostredia je nastavená.\n"
+"To je nebezpeèné, preto¾e to umo¾òuje pomocou qmail-inject alebo pomocou\n"
+"qmail-sendmail wrappera sfal¹ovanie va¹ich Od: alebo Správa-ID: záhlaví.\n"
+"Skúste \"env QMAILINJECT= %s PARAMETRE\"\n"
+"%s: Ukonèené.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: NULLMAILER_FLAGS-premenná prostredia je nastavená.\n"
+"To je nebezpeèné, preto¾e to umo¾òuje pomocou nullmailer-inject a pomocou\n"
+"nullmailer-sendmail wrappera sfal¹ovanie va¹ich Od:, Správa-ID: alebo "
+"Návratová-cesta: záhlaví. Skúste \"env NULLMAILER_FLAGS= %s PARAMETRE\"\n"
+"%s: Ukonèené.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Neexistujete. Choïte preè.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: nemô¾em rozozna» vá¹ho hostiteµa!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "gethostbyname zlyhalo pre %s\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "SMTP prijímaè %s nepodporuje ESMTP\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "SMTP prijímaè %s nepodporuje ETRN\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "Spracovanie fronty pre %s bolo spustené\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "®iadna správa pre %s\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "Spracovanie nedoruèených správ pre %s bolo spustené\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "Nemô¾em spracova» frontu správ pre uzol %s\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Uzol %s nie je prípustný: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "ETRN-syntaktická chyba\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "ETRN-syntaktická chyba v parametroch\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "ETRN-neznáma syntaktická chyba %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "Voµba --keep nie je podporovaná s ETRN\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "Voµba --flush nie je podporovaná s ETRN\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "Voµba --remote nie je podporovaná s ETRN\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "Voµba --check nie je podporovaná s ETRN\n"
+
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: vyvolaný s"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "nemô¾em nájs» aktuálny pracovný adresár\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "Toto je fetchmail verzia %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Preberám voµby z príkazového riadku%s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " a "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "Nie sú nakongifurované po¹tové sevre -- mo¾no chýba %s?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: neboli ¹pecifikované po¹tové servre.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: nie je spustený ¾iadny ïal¹í fetchmail\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr "fetchmail: chyba pri stopovaní %s-fetchmailu pri %d; zastavené.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "pozadie"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "popredie"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %s-fetchmail pri %d ukonèený.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"nemô¾em skontrolova» po¹tu pokiaµ je spustený iný fetchmail pre rovnakého "
+"hostiteµa.\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: nemô¾em »aha» z uvedených hostiteµov pokiaµ be¾í iný fetchmail na "
+"%d.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: je spustený iný fetchmail v popredí na %d.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: nemô¾em akceptova» voµby pokiaµ be¾í iný fetchmail v pozadí.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: fetchmail be¾iaci v pozadí na %d bol prebudený.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: star¹í súrodenec na %d záhadne zomrel.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: nemô¾em nájs» heslo pre %s@%s.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "Zadaj heslo pre %s@%s: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "¹tartujem fetchmail %s démona \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "nemô¾em otvori» %s pre pripojenie logov k \n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "nemô¾em vykona» èasovú kontrolu %s (chyba %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "fetchmail re¹tartovaný (%s zmenených)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr "pokus o nové spustenie mô¾e zlyha», preto¾e prieèinok nebol obnovený\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "pokus o nové spustenie fetchmail zlyhal\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"obnovenie %s vynechané (zlyhala autentifikácia alebo vypr¹al èas spojenia)\n"
+
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "interval nebol dosiahnutý, nebudem posiela» dotaz na %s\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Stav dotazu=0 (SUCCESS)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Stav dotazu=1 (NOMAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Stav dotazu=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Stav dotazu=3 (AUTHFAIL)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Stav dotazu=4 (PROTOCOL)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Stav dotazu=5 (SYNTAX)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "Stav dotazu=6 (IOERR)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "Stav dotazu=7 (ERROR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Stav dotazu=8 (EXCLUDE)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Stav dotazu=9 (LOCKBUSY)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "Stav dotazu=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "Stav dotazu=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Stav dotazu=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Stav dotazu=13 (MAXFETCH)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Stav dotazu=%d\n"
+
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "®iadne spojenie nefunguje. Konèím.\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "spím o %s\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "zobudený od %s\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "zobudený signálom %d\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "zobudený o %s\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "normálne ukonèenie, stav %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "nemô¾em vykona» èasovú kontrolu run-control súboru\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr "Upozornenie: viaceré zmienky o hostiteli %s v konfiguraènom súbore\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "SSL podpora nebola prelo¾ená.\n"
+
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: varovanie: nie je dostupný DNS pre kontrolu Multidrop-spracovaní "
+"z %s\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "nesprávna konfigurácia %s, èíslo portu nemô¾e by» záporné\n"
+
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "nesprávna konfigurácia %s, RPOP vy¾aduje privilegovaný port\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr "nesprávna konfigurácia %s, LMTP nemô¾e pou¾i» ¹tandardný SMTP port\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "Pou¾itie fetchall ako aj keep on v re¾ime démona je chybné!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "ukonèené signálom %d\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%s dotazuje %s (protokol %s) na %s: »ahanie spustené\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "POP2 podpora nebola nakonfigurovaná.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "POP3 podpora nebola nakonfigurovaná.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "IMAP podpora nebola nakonfigurovaná.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "ETRN podpora nebola nakonfigurovaná.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "ETRN nie je podporované bez gethostbyname(2).\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "ODMR podpora nebola nakonfigurovaná.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "ODMR nie je podporované bez gethostbyname(2).\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "vybraný nepodporovaný protokol.\n"
+
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr "%s dotazuje %s (protokol %s) na %s: »ahanie dokonèené\n"
+
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "Dotazovací interval je %d sekúnd\n"
+
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Log-súbor je %s\n"
+
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Idfile je %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Protokol o správach bude zaznamenaný syslog-om\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail sa bude maskova» a nebude generova» Received\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr "Fetchmail bude zobrazova» priebeh pomocou bodiek aj v log-súbore.\n"
+
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr "Fetchmail bude nesprávne adresované správy posiela» ïalej na %s.\n"
+
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Fetchmail bude smerova» chybové správy správcovi po¹ty.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail bude smerova» chybové správy odosielateµovi.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "Voµby pre príjem z %s@%s:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Po¹ta bude prijatá cez %s\n"
+
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  Dotazovanie tohoto servra bude vykonané ka¾dé %d intervaly.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Skutoèný názov servera je %s.\n"
+
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr "  Tento hostiteµ %s dotazovaný, keï nebude ¹pecifikovaný ¾iadny iný.\n"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr "nebude"
+
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr "bude"
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Heslo bude po¾adované.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  APOP tajomstvo = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  RPOP id = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Heslo = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "  Protokol je KPOP s Kerberos %s autentifikáciou"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  Protokol je %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (pou¾ívam slu¾bu %s)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (pou¾ívam bezpeènostné nastavenia siete %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (pou¾ívam port %d)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (pou¾ívam ¹tandardný port)"
+
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (povinné pou¾itie UIDL)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr " V¹etky dostupné metódy autentifikácie budú vyskú¹ané.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  Autentifikácia heslom bude povinná.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  NTLM autentifikácia bude povinná.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  OTP autentifikácia bude povinná.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  CRAM-Md5 autentifikácia bude povinná.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  GSSAPI autentifikácia bude povinná.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Kerberos V4 autentifikácia bude povinná.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Kerberos V5 autentifikácia bude povinná.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  Predpokladané ¹ifrovanie na úrovni koncového zariadenia.\n"
+
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  Vedúci po¹tovej slu¾by je: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  SSL ¹ifrované spojenia povolené.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  SSL Protokol je %s.\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  Kontrola certifikátu SSL servra povolená.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  SSL prieèinok pre dôverné certifikáty: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr "  Odtlaèok SSL kµúèa (kontrolovaný proti kµúèu servra): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  Èasový limit pre ne-odpovedanie servra je %d sekúnd"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (implicitná hodnota).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Vybraný ¹tandardný po¹tový prieèinok.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Vybrané po¹tové prieèinky sú:"
+
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s správy budu prijaté (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "V¹etky"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "Len nové"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Stiahnuté správy %s ponechané na servri (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr ""
+"  Staré správy %s budú zmazané pred príjmom nových správ (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  Prepis lokálnej adresy servra je %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "povolené"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "zakázané"
+
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  Vynechanie znaku \"návrat vozíka\"-CR je %s (stripcr %s).\n"
+
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Vynútenie znaku \"návrat vozíka\"-CR je %s (forcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr "  Interpretácia ¹ifrovania obsahu pri prenose je %s (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  Dekódovanie MIME je %s (mimedecode %s).\n"
+
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  Neèinnos» po stiahnutí je %s (idle %s).\n"
+
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Neprázdne stavové riadky budú %s (dropstatus %s)\n"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "zahodené"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "ponechané"
+
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Delivered-To riadky budú %s (dropdelivered %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  Limit pre veµkos» správy je %d oktetov (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  Správy nemajú limitovanú veµkos» (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr ""
+"  Interval pre varovanie ohµadom veµkosti správy je %d sekúnd (--warnings %"
+"d).\n"
+
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr "  Varovanie o veµkosti správ pri ka¾dom s»ahovaní (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  Limit pre prijaté správy je %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  Príjem správ nie je limitovaný (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  Limit pre prijaté správy je %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Správy nemajú limitovanú veµkos» (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  Limit dávky SMTP správ je %d.\n"
+
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  Dávka SMTP správ nie je limitovaná (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+"  Interval medzi skutoènými vymazaniami nastavený na %d (--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Nevynútené vymazania (--expunge 0).\n"
+
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Domény pre ktoré bude doruèená po¹ta sú:"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr "(implicitná hodnota)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Správy budú pripojené k %s ako BSMTP\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Správy budú doruèené s \"%s\".\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Správy budú %cMTP-dopravené na:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  Hos»ová èas» z MAIL FROM riadku bude %s\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr "  Adresa, ktorá sa pou¾ije v RCPT TO a bude doruèená v SMTP bude %s\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Rozpoznané SPAM-blokované odpovede prijímaèa sú:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  SPAM-blokovanie vypnuté\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  Spojenie so servrom bude aktivované s \"%s\".\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Príkaz spú¹»aný pred spojením neexistuje.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  Spojenie so servrom bude ukonèené s \"%s\".\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Príkaz spú¹»aný po spojení neexistuje.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Nie sú definované ¾iadne lokálne názvy pre tohto hostiteµa.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Multi-drop mód: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Single-drop mód: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d rozpoznaných lokálnych názvov.\n"
+
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  DNS vyhµadávanie pre multi-drop adresy je %s.\n"
+
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr "  Prezývky servra budú porovnávané s multi-drop adresami pomocou "
+
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "IP adries.\n"
+
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "mien.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  Smerovanie adries obálok nie je aktivované\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Predpokladá sa záhlavie obálky: %s\n"
+
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Prijaté"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Poèet záhlaví obálok na analýzu: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  Prefix %s bude odstránený z pou¾ívateµovho id\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  ®iadne odstránenie prefixu\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Preddeklarované prezývky po¹tového servra:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Lokálne domény:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  Spojenie musí by» realizované pomocou rozhrania %s.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Neboli ¹pecifikované ¾iadne po¾iadavky na rozhranie.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Dotazovací cyklus s monitorom %s.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Nebolo ¹pecifikované ¾iadne monitorovacie rozhranie.\n"
+
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr ""
+"  Spojenie so servrom bude realizované pomocou plugin-u %s (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Nebol ¹pecifikovaný ¾iadny príkaz pre plugin.\n"
+
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr ""
+"  Spojenia s prijímaèom budú realizované pomocou plugout-u %s (--plugout %"
+"s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Nebol ¹pecifikovaný ¾iadny príkaz pre plugout.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Neboli ulo¾ené ¾iadne UID-y z tohoto hostiteµa.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d UID-ov ulo¾ených.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr "  Informácia o trase dotazu bude pridaná do záhlavia Received.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  Do záhlavia Received nebude pridaná ¾iadna informácia o trase s»ahovania.\n"
+".\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Vlastnosti prechodu \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "alloca neúspe¹né"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "CHYBA: ¾iadna podpora pre rutinu getpassword()\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"SIGINT obdr¾ané... konèím.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "Nemô¾em získa» názov slu¾by pre [%s]\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "Pou¾ívam názov slu¾by [%s]\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Posielam osobné údaje\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Chyba pri výmene osobných údajov\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Nemô¾em rozbali» dáta bezpeènostnej úrovne\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Výmena osobných údajov kompletná\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Server po¾aduje integritu a/alebo súkromie\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Rozbalené príznaky bezpeènostnej úrovne: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "Maximálna veµkos» GSS symbolu je %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Chyba pri vytváraní ¾iadosti bezpeènostnej úrovne\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "Uvoµòujem osobné údaje GSS\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Chyba pri uvoµòovaní osobných údajov\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: vlákno uspaté na %d sekúnd.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protokol identifikovaný ako IMAP4 rev 1\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protokol identifikovaný ako IMAP4 rev 0\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protokol identifikovaný ako IMAP2 alebo IMAP2BIS\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "bude neèinný po stiahnutí\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "Po¾adovaná funkcia OTP nebola prelo¾ená do fetchmail-u\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "Po¾adovaná funkcia NTLM nebola prelo¾ená do fetchmail-u\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Po¾adovaná funkcia LOGIN nie je podporovaná servrom\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "vymazanie zlyhalo\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "stiahnutie zlyhalo\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "%d správ èaká po stiahnutí\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "výber po¹tového prieèinka zlyhal\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "%d správ èaká po prvom stiahnutí\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "%d správ èaká po prvom vymazaní\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "vyhµadávanie nepreèítaných správ zlyhalo\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u je nepreèítaných\n"
+
+#: imap.c:776 pop3.c:679
+#, fuzzy, c-format
+msgid "%u is first unseen\n"
+msgstr "%u je prvá nepreèítaná\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr ""
+"Nemô¾em otvori» rozhranie kvm, uistite sa ¾e fetchmail má nastavené SGID kmem"
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "Nemô¾em analyzova» názov rozhrania z %s"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: sysctl (iflist odhad) zlyhal"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: malloc zlyhal"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: sysctl (iflist) zlyhal"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "Verzia smerovania správy %d nerozpoznaná."
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "Nebolo nájdené ¾iadne rozhranie s názvom %s"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "Nebola nájdená ¾iadna IP adresa pre %s"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "chýbajúca IP adresa rozhrania\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "neplatná IP adresa rozhrania\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "neplatná IP maska rozhrania\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "aktivita na %s -zaznamenaná- ako %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "s»ahovanie z %s vynechané, %s je nedostupný\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "s»ahovanie z %s vynechané, IP adresa %s je vylúèená\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "aktivita na %s skontrolovaná ako %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "s»ahovanie z %s vynechané, %s neaktívny\n"
+
+#: interface.c:732
+#, fuzzy, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "aktivita na %s bola %d, je %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "nemô¾em dekódova» poèiatoènú BASE64 výzvu\n"
+
+#: kerberos.c:139
+#, fuzzy, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "principál %s v tikete sa nezhoduje s -u %s\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "nenulová in¹tancia (%s) mô¾e spôsobi» zvlá¹tne správanie\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "nemô¾em dekódova» BASE64 odpoveï o pripravenosti\n"
+
+#: kerberos.c:220
+#, fuzzy
+msgid "challenge mismatch\n"
+msgstr "nezhoda výzvy\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: odstraòujem starý zamykací súbor\n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: vytvorenie zámky zlyhalo.\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "varovanie: nájdené \"%s\" pred niektorými názvami hostiteµa"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: varovanie: nájdené \"%s\" pred niektorými názvami hostiteµa\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: varovanie: neznámy symbol \"%s\"\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "SMTP prijímaè %s nepodporuje ATRN\n"
+
+#: odmr.c:103
+#, fuzzy
+msgid "Turnaround now...\n"
+msgstr "Otoèené teraz...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "ATRN ¾iados» zamietnutá.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "Nie je mo¾né teraz spracova» ATRN ¾iados»\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "Nemáte po¹tu.\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Príkaz nie je implementovaný\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Autentifikácia po¾adovaná.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Neznáma ODMR chyba %d\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "Voµba --keep nie je podporovaná s ODMR\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "Voµba --flush nie je podporovaná s ODMR\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "Voµba --remote nie je podporovaná s ODMR\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "Voµba --check nie je podporovaná s ODMR\n"
+
+#: opie.c:37
+#, fuzzy
+msgid "server recv fatal\n"
+msgstr "server recv fatal\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "Nie je mo¾né dekódova» OTP výzvu\n"
+
+#: opie.c:59 pop3.c:495
+#, fuzzy
+msgid "Secret pass phrase: "
+msgstr "Heslo: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "Re»azec '%s' nie je platný èíselny re»azec.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "Hodnota re»azca '%s' je %s ako %d.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "men¹ia"
+
+#: options.c:211
+msgid "larger"
+msgstr "väè¹ia"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "©pecifikovaný neplatný protokol `%s'.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "©pecifikovaná neplatná autentifikácia `%s'.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: podpora sie»ovej bezpeènosti je zakázaná\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "pou¾itie:  fetchmail [prepínaèe] [server ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Prepínaèe sú nasledovné:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        zobraz tohto pomocníka\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     zobraz informáciu o verzii\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       skontroluj správy bez stiahnutia\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      pracuj potichu\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     pracuj hluène (diagnostický výstup)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      spusti ako démon raz za n sekúnd\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    neodpájaj proces démona\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        zabi proces démona\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     ¹pecifikuj názov log-súboru\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      pou¾i syslog(3) pre väè¹inu správ keï be¾í ako démon\n"
+
+#: options.c:673
+#, fuzzy
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr "      --invisible   nezapisuj Received & povoµ podvrhnutie hostiteµa\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc ¹pecifikuj náhradný spú¹»ací riadiaci súbor\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      ¹pecifikuj náhradný súbor UID-ov\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr ""
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr ""
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr ""
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr ""
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr ""
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr ""
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr ""
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr ""
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr ""
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr ""
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr ""
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr ""
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr ""
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr ""
+
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr ""
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr ""
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr ""
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr ""
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr ""
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr ""
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr ""
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr ""
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr ""
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr ""
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr ""
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr ""
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr ""
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr ""
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr ""
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr ""
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr ""
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr ""
+
+#: options.c:720
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr ""
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr ""
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr ""
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr ""
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr ""
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr ""
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr ""
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr ""
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr ""
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr ""
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr ""
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr ""
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr ""
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr ""
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr ""
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr ""
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr ""
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr ""
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr ""
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr ""
+
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr ""
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr ""
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr ""
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr ""
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr ""
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr ""
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr ""
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr ""
+
+#: rpa.c:116
+msgid "Success"
+msgstr ""
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr ""
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr ""
+
+#: rpa.c:119
+msgid "Deity error"
+msgstr ""
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr ""
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr ""
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr ""
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr ""
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr ""
+
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr ""
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr ""
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr ""
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr ""
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr ""
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr ""
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr ""
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr ""
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr ""
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr ""
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr ""
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr ""
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr ""
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr ""
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr ""
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr ""
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr ""
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr ""
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr ""
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr ""
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr ""
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr ""
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr ""
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr ""
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr ""
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr ""
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr ""
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr ""
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr ""
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr ""
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr ""
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr ""
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr ""
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr ""
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr ""
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr ""
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr ""
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr ""
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr ""
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr ""
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr ""
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr ""
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr ""
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr ""
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr ""
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr ""
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr ""
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr ""
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr ""
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr ""
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr ""
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr ""
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr ""
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr ""
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr ""
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr ""
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr ""
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr ""
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr ""
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr ""
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr ""
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr ""
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr ""
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr ""
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr ""
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr ""
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr ""
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr ""
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr ""
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr ""
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr ""
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr ""
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr ""
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr ""
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr ""
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr ""
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr ""
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr ""
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr ""
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr ""
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr ""
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr ""
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr ""
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr ""
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr ""
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr ""
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr ""
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr ""
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr ""
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr ""
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr ""
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr ""
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr ""
+
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr ""
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"analýza riadku Received:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "riadok akceptovaný, %s je alias po¹tového servra\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "riadok zamietnutý, %s nie je alias po¹tového servra\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "nenájdená adresa Received\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "nájdená adresa Received `%s'\n"
+
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "oddeµovaè správy nájdený pri prezeraní záhlaví\n"
+
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "nesprávny riadok záhlavia nájdený pri prezeraní záhlaví\n"
+
+#: transact.c:554
+#, fuzzy, c-format
+msgid "line: %s"
+msgstr "Obnovujem %s\n"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "¾iadne lokálne zhody, posielam na %s\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "odoslanie a zmazanie odlo¾ené kvôli DNS chybám\n"
+
+#: transact.c:1225
+#, fuzzy
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "zápis msgblk.hlavièiek RFC822\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr "¾iadna adresa príjemcu nezodpovedá zadaným lokálnym menám"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "adresa príjemcu %s nezodpovedá ¾iadnemu lokálnemu menu"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "správa obsahuje NUL-y"
+
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "SMTP prijímaè zamietol lokálne adresy príjemcu: "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "zápis textu správy\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "Starý zoznam UID z %s:"
+
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <prázdny>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Doèasný zoznam UID-ov:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, fuzzy, c-format
+msgid "Merged UID list from %s:"
+msgstr "Starý zoznam UID z %s:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "Nový zoznam UID z %s:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "vymieòam zoznamy UID\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr "nevymieòam zoznamy UID, ¾iadne UID-y nevideli túto po¾iadavku\n"
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "vymieòam zoznamy UID\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "Ma¾em súbor fetchids.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "Zapisujem súbor fetchids.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "malloc zlyhal\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "realloc zlyhal\n"
diff --git a/po/stamp-cat-id b/po/stamp-cat-id
new file mode 100644
index 00000000..9788f702
--- /dev/null
+++ b/po/stamp-cat-id
@@ -0,0 +1 @@
+timestamp
diff --git a/po/tr.gmo b/po/tr.gmo
new file mode 100644
index 00000000..3f4eb1ad
--- /dev/null
+++ b/po/tr.gmo
diff --git a/po/tr.po b/po/tr.po
new file mode 100644
index 00000000..f988c2b8
--- /dev/null
+++ b/po/tr.po
@@ -0,0 +1,2932 @@
+# Turkish translation for fetchmail messages
+# Copyright (C) 2002 Free Software Foundation, Inc.
+# Engin Gündüz <engin@ripe.net>, 2002.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: fetchmail 6.2.4\n"
+"POT-Creation-Date: 2004-01-12 15:50-0500\n"
+"PO-Revision-Date: 2003-08-18 23:00+0100\n"
+"Last-Translator: Engin Gündüz <engin@ripe.net>\n"
+"Language-Team: Turkish <gnu-tr-u12a@lists.sourceforge.net>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=ISO-8859-9\n"
+"Content-Transfer-Encoding: 8bit\n"
+
+#: checkalias.c:171
+#, c-format
+msgid "Checking if %s is really the same node as %s\n"
+msgstr "`%s' düðümünün gerçekten `%s' ile ayný olup olmadýðýna bakýlýyor\n"
+
+#: checkalias.c:175
+msgid "Yes, their IP addresses match\n"
+msgstr "Evet, IP adresleri birbirine uyuyor\n"
+
+#: checkalias.c:179
+msgid "No, their IP addresses don't match\n"
+msgstr "Hayýr, IP adresleri birbirine uymuyor\n"
+
+#: checkalias.c:199 checkalias.c:225
+#, c-format
+msgid "nameserver failure while looking for `%s' during poll of %s.\n"
+msgstr ""
+"%2$s yoklanýrken `%1$s'in aranmasý sýrasýnda DNS sorgusu baþarýsýz oldu.\n"
+
+#: cram.c:95
+msgid "could not decode BASE64 challenge\n"
+msgstr "BASE64 challenge'ýnýn kodunu çözemedim\n"
+
+#: cram.c:103
+#, c-format
+msgid "decoded as %s\n"
+msgstr "%s olarak kodu çözüldü\n"
+
+#: driver.c:191
+#, c-format
+msgid "kerberos error %s\n"
+msgstr "kerberos hatasý %s\n"
+
+#: driver.c:250 driver.c:255
+#, c-format
+msgid "krb5_sendauth: %s [server says '%*s'] \n"
+msgstr "krb5_sendauth: %s [sunucu '%*s' diyor] \n"
+
+#: driver.c:336
+#, c-format
+msgid ""
+"Subject: Fetchmail oversized-messages warning.\n"
+"\n"
+"The following oversized messages remain on the mail server %s:"
+msgstr ""
+"Subject: Fetchmail çok büyük ileti uyarýsý.\n"
+"\n"
+"Aþaðýda yazýlý çok büyük iletiler sunucu %s üzerinde býrakýldý:"
+
+#: driver.c:354
+#, c-format
+msgid "\t%d msg %d octets long skipped by fetchmail.\n"
+msgstr "\tfetchmail %2$d sekizlik büyüklüðündeki %1$d. iletiyi atlýyor.\n"
+
+#: driver.c:497
+#, fuzzy, c-format
+msgid "skipping message %s@%s:%d"
+msgstr "ileti %s@%s:%d atlanýyor (%d sekizlik)"
+
+#: driver.c:549
+#, c-format
+msgid "skipping message %s@%s:%d (%d octets)"
+msgstr "ileti %s@%s:%d atlanýyor (%d sekizlik)"
+
+#.
+#. * Invalid lengths are produced by Post Office/NT's
+#. * annoying habit of randomly prepending bogus
+#. * LIST items of length -1.  Patrick Audley
+#. * <paudley@pobox.com> tells us: LIST shows a
+#. * size of -1, RETR and TOP return "-ERR
+#. * System error - couldn't open message", and
+#. * DELE succeeds but doesn't actually delete
+#. * the message.
+#.
+#: driver.c:565
+msgid " (length -1)"
+msgstr " (büyüklük -1)"
+
+#: driver.c:568
+msgid " (oversized)"
+msgstr " (çok büyük)"
+
+#: driver.c:583
+#, c-format
+msgid "couldn't fetch headers, message %s@%s:%d (%d octets)\n"
+msgstr "baþlýklar getirilemedi, ileti %s@%s:%d (%d sekizlik)\n"
+
+#: driver.c:600
+#, c-format
+msgid "reading message %s@%s:%d of %d"
+msgstr "ileti %s@%s:%d okunuyor (%d taneden)"
+
+#: driver.c:605
+#, c-format
+msgid " (%d %soctets)"
+msgstr " (%d %ssekizlik)"
+
+#: driver.c:606
+msgid "header "
+msgstr "baþlýk "
+
+#: driver.c:678
+#, c-format
+msgid " (%d body octets) "
+msgstr " (ileti gövdesi %d sekizlik) "
+
+#: driver.c:736
+#, c-format
+msgid ""
+"message %s@%s:%d was not the expected length (%d actual != %d expected)\n"
+msgstr ""
+"%s@%s:%d iletisinin uzunluðu beklendiði kadar deðil (gerçekte %d != beklenen "
+"%d)\n"
+
+#: driver.c:767
+msgid " retained\n"
+msgstr " býrakýldý\n"
+
+#: driver.c:776
+msgid " flushed\n"
+msgstr " boþaltýldý\n"
+
+#: driver.c:793
+msgid " not flushed\n"
+msgstr " boþaltýlmadý\n"
+
+#: driver.c:809
+#, c-format
+msgid "fetchlimit %d reached; %d messages left on server %s account %s\n"
+msgstr ""
+"`fetchlimit' %d ulaþýldý; %d ileti %s sunucusunda %s hesabýnda býrakýldý\n"
+
+#: driver.c:869
+msgid "SIGPIPE thrown from an MDA or a stream socket error\n"
+msgstr "bir MDA'dan SIGPIPE fýrlatýldý ya da stream soket hatasý\n"
+
+#: driver.c:876
+#, c-format
+msgid "timeout after %d seconds waiting to connect to server %s.\n"
+msgstr ""
+"%d saniye %s sunucusuna baðlanmak beklendi ve zamanaþýmý süresi doldu.\n"
+
+#: driver.c:880
+#, c-format
+msgid "timeout after %d seconds waiting for server %s.\n"
+msgstr "sunucu %2$s %1$d saniye beklendi ve zamanaþýmý süresi doldu.\n"
+
+#: driver.c:884
+#, c-format
+msgid "timeout after %d seconds waiting for %s.\n"
+msgstr "%2$s %1$d saniye beklendi ve zamanaþýmý süresi doldu.\n"
+
+#: driver.c:889
+#, c-format
+msgid "timeout after %d seconds waiting for listener to respond.\n"
+msgstr "dinleyici %d saniye beklendikten sonra zamanaþýmýna uðrandý.\n"
+
+#: driver.c:892
+#, c-format
+msgid "timeout after %d seconds.\n"
+msgstr "%d saniye beklendi ve zamanaþýmý süresi doldu.\n"
+
+#: driver.c:904
+msgid "Subject: fetchmail sees repeated timeouts\n"
+msgstr "Subject: fetchmail çok sayýda zamanaþýmý ile karþýlaþýyor\n"
+
+#: driver.c:906
+#, c-format
+msgid ""
+"Fetchmail saw more than %d timeouts while attempting to get mail from %s@%"
+"s.\n"
+msgstr ""
+"Fetchmail %2$s@%3$s'den posta almaya çalýþýrken %1$d'den çok zamanaþýmý ile "
+"karþýlaþtý.\n"
+
+#: driver.c:911
+msgid ""
+"This could mean that your mailserver is stuck, or that your SMTP\n"
+"server is wedged, or that your mailbox file on the server has been\n"
+"corrupted by a server error.  You can run `fetchmail -v -v' to\n"
+"diagnose the problem.\n"
+"\n"
+"Fetchmail won't poll this mailbox again until you restart it.\n"
+msgstr ""
+"Bunun nedeni posta sunucunuzun takýlmýþ olmasý, SMTP sunucunuzun\n"
+"sýkýþmýþ olmasý ya da sunucu üzerindeki mektup kutusu dosyanýzýn\n"
+"bir sunucu hatasýyla bozulmuþ olmasý olabilir. Sorunu tanýlamak için\n"
+"`fetchmail -v -v' çalýþtýrabilirsiniz.\n"
+"\n"
+"Fetchmail yeniden çalýþtýrýlana dek bir daha bu posta kutusuna\n"
+"bakmayacak.\n"
+
+#: driver.c:940
+#, c-format
+msgid "pre-connection command failed with status %d\n"
+msgstr "baðlantý sonrasý komut baþarýsýz oldu, durum kodu %d\n"
+
+#: driver.c:971
+#, c-format
+msgid "couldn't find HESIOD pobox for %s\n"
+msgstr "%s için HESIOD pobox bulunamadý\n"
+
+#: driver.c:993
+msgid "Lead server has no name.\n"
+msgstr "Lead sunucunun adý yok.\n"
+
+# canonical'in Türkçesi ne ola? kanonik hiç hoþ deðil.
+#: driver.c:1016
+#, c-format
+msgid "couldn't find canonical DNS name of %s (%s)\n"
+msgstr "%s (%s)'in kanonik DNS adýný bulamadým\n"
+
+#: driver.c:1053
+msgid "internal inconsistency\n"
+msgstr "iç tutarsýzlýk\n"
+
+#: driver.c:1063
+#, c-format
+msgid "%s connection to %s failed"
+msgstr "%2$s'ye %1$s baðlantýsý baþarýsýz oldu"
+
+#: driver.c:1069
+msgid "host is unknown."
+msgstr "makina bilinmiyor."
+
+#: driver.c:1072
+msgid "name is valid but has no IP address."
+msgstr "ad geçerli ama IP adresi yok."
+
+# unrecoverable = düzeltilemez (Sankur'un sözlüðü 'kurtarýlamaz' diyor ama buraya pek
+# uymuyor bence...
+#: driver.c:1075
+msgid "unrecoverable name server error."
+msgstr "düzeltilemeyen ad sunucusu hatasý."
+
+#: driver.c:1077
+msgid "temporary name server error."
+msgstr "geçici ad sunucusu hatasý."
+
+#: driver.c:1084
+#, c-format
+msgid "unknown DNS error %d."
+msgstr "bilinmeyen DNS hatasý %d."
+
+#: driver.c:1102
+#, c-format
+msgid ""
+"Subject: Fetchmail unreachable-server warning.\n"
+"\n"
+"Fetchmail could not reach the mail server %s:"
+msgstr ""
+"Subject: Fetcmail ulaþýlamayan sunucu uyarýsý.\n"
+"\n"
+"Fetchmail posta sunucusuna (%s) ulaþamadý:"
+
+#: driver.c:1131 imap.c:366 pop3.c:410
+msgid "SSL connection failed.\n"
+msgstr "SSL baðlantýsý baþarýsýz oldu.\n"
+
+#: driver.c:1184
+#, c-format
+msgid "Lock-busy error on %s@%s\n"
+msgstr "Meþgul kilit hatasý (%s@%s)\n"
+
+#: driver.c:1188
+#, c-format
+msgid "Server busy error on %s@%s\n"
+msgstr "Sunucu meþgul hatasý (%s@%s)\n"
+
+#: driver.c:1193
+#, c-format
+msgid "Authorization failure on %s@%s%s\n"
+msgstr "%s@%s%s'te yetkilendirme hatasý\n"
+
+#: driver.c:1196
+msgid " (previously authorized)"
+msgstr " (önceden yetkilendirilmiþ)"
+
+#: driver.c:1217
+#, c-format
+msgid "Subject: fetchmail authentication failed on %s@%s\n"
+msgstr "Subject: %s@%s'te fetchmail kimlik denetlemesi baþarýsýz oldu\n"
+
+#: driver.c:1220
+#, c-format
+msgid "Fetchmail could not get mail from %s@%s.\n"
+msgstr "Fetchmail %s@%s'den posta alamadý.\n"
+
+#: driver.c:1224
+msgid ""
+"The attempt to get authorization failed.\n"
+"Since we have already succeeded in getting authorization for this\n"
+"connection, this is probably another failure mode (such as busy server)\n"
+"that fetchmail cannot distinguish because the server didn't send a useful\n"
+"error message.\n"
+"\n"
+"However, if you HAVE changed your account details since starting the\n"
+"fetchmail daemon, you need to stop the daemon, change your configuration\n"
+"of fetchmail, and then restart the daemon.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Yetki alma denemesi baþarýsýz oldu.\n"
+"Bu baðlantý için daha önce yetki almýþ olduðumuza göre, bu bir olasýlýkla\n"
+"baþka bir hata (örneðin sunucunun meþgul olmasý) nedeniyle olabilir, fakat\n"
+"fetchmail sunucudan iþe yarar bir hata iletisi almadýðýndan bunu "
+"anlayamamýþ\n"
+"olabilir.\n"
+"\n"
+"Fakat eðer hesabýnýzýn bilgilerini fetchmail daemon'ý baþlatýldýðýndan\n"
+"beri deðiþtirilmiþse, þimdi daemon'ý durdurup, fetchmail yapýlandýrmasýný\n"
+"deðiþtirip, daemon'ý yeniden baþlatmanýz gerekiyor.\n"
+"\n"
+"Fetchmail daemon'ý çalýþmaya devam edecek ve sýrasý geldikçe baðlanmaya\n"
+"çalýþacak. Hizmet yeniden saðlanana dek baþka bir bildirim gönderilmeyecek."
+
+#: driver.c:1239
+msgid ""
+"The attempt to get authorization failed.\n"
+"This probably means your password is invalid, but some servers have\n"
+"other failure modes that fetchmail cannot distinguish from this\n"
+"because they don't send useful error messages on login failure.\n"
+"\n"
+"The fetchmail daemon will continue running and attempt to connect\n"
+"at each cycle.  No future notifications will be sent until service\n"
+"is restored."
+msgstr ""
+"Yetki alma denemesi baþarýsýz oldu.\n"
+"Bu, parolanýzýn geçersiz olmasýndan kaynaklanýyor olabilir, ancak\n"
+"bazý sunucularýn giriþ sýrasýnda iþe yarar hata iletisi göndermemelerinden\n"
+"dolayý fetchmail'in anlayamadýðý baþka hata modlarý da vardýr.\n"
+"\n"
+"Fetchmail daemon'ý çalýþmaya devam edecek ve sýrasý geldikçe baðlanmaya\n"
+"çalýþacak. Hizmet yeniden saðlanana dek baþka bir bildirim gönderilmeyecek."
+
+#: driver.c:1254
+#, c-format
+msgid "Repoll immediately on %s@%s\n"
+msgstr "%s@%s'de hemen yeniden kontrol\n"
+
+#: driver.c:1259
+#, c-format
+msgid "Unknown login or authentication error on %s@%s\n"
+msgstr "%s@%s'te bilinmeyen giriþ ya da kimlik denetleme hatasý\n"
+
+#: driver.c:1283
+#, c-format
+msgid "Authorization OK on %s@%s\n"
+msgstr "%s@%s'te yetki denetleme tamam\n"
+
+#: driver.c:1289
+#, c-format
+msgid "Subject: fetchmail authentication OK on %s@%s\n"
+msgstr "Subject: %s@%s'te fetchmail kimlik denetleme tamam\n"
+
+#: driver.c:1292
+#, c-format
+msgid "Fetchmail was able to log into %s@%s.\n"
+msgstr "Fetchmail %s@%s'e girmeyi baþardý.\n"
+
+#: driver.c:1296
+msgid "Service has been restored.\n"
+msgstr "Hizmet yeniden saðlanýyor.\n"
+
+# Bunu kaynak kodunda kontrol et.
+#: driver.c:1327
+#, c-format
+msgid "selecting or re-polling folder %s\n"
+msgstr "%s klasörünü seçiyor ya da yeniden kontrol ediyorum\n"
+
+#: driver.c:1329
+msgid "selecting or re-polling default folder\n"
+msgstr "öntanýmlý klasörü seçiyor ya da yeniden kotrol ediyorum\n"
+
+# kaynak koduna bakýlacak
+#: driver.c:1345
+#, c-format
+msgid "%s at %s (folder %s)"
+msgstr "%2$s'de %1$s (klasör %3$s)"
+
+# kaynak koduna bakýlacak
+#: driver.c:1353 rcfile_y.y:397
+#, c-format
+msgid "%s at %s"
+msgstr "%2$s'de %1$s"
+
+#. only used for ETRN
+#: driver.c:1358
+#, c-format
+msgid "Polling %s\n"
+msgstr "%s yoklanýyor\n"
+
+# sonraki iki ileti ile ilgili
+#: driver.c:1362
+#, c-format
+msgid "%d %s (%d %s) for %s"
+msgstr "%5$s için (%3$d adedi %4$s) %1$d %2$s"
+
+# bir önceki ve bir sonraki iletilerle ilgili.
+# Bunun Türkçede tekil çerilmesi gerek, çünkü hemen önünde bir sayý olacak.
+#: driver.c:1363 driver.c:1370
+msgid "messages"
+msgstr "ileti"
+
+# önceki iki ileti ile ilgili.
+#: driver.c:1364 driver.c:1371
+msgid "message"
+msgstr "ileti"
+
+#: driver.c:1366
+msgid "seen"
+msgstr "görülmüþ"
+
+# önceki iki ileti ile ilgili.
+#: driver.c:1369
+#, c-format
+msgid "%d %s for %s"
+msgstr "%3$s için %1$d %2$s"
+
+#: driver.c:1375
+#, c-format
+msgid " (%d octets).\n"
+msgstr " (%d sekizli).\n"
+
+#: driver.c:1381
+#, c-format
+msgid "No mail for %s\n"
+msgstr "%s için mektup yok\n"
+
+#: driver.c:1414
+msgid "bogus message count!"
+msgstr "sahte ileti sayýsý!"
+
+#: driver.c:1515
+msgid "socket"
+msgstr "soket"
+
+#: driver.c:1518
+msgid "missing or bad RFC822 header"
+msgstr "RFC822 baþlýðý ya hiç yok ya da formatý kötü"
+
+#: driver.c:1521
+msgid "MDA"
+msgstr "MDA"
+
+#: driver.c:1524
+msgid "client/server synchronization"
+msgstr "istemci/sunucu senkronizasyonu"
+
+#: driver.c:1527
+msgid "client/server protocol"
+msgstr "istemci/sunucu protokolü"
+
+#: driver.c:1530
+msgid "lock busy on server"
+msgstr "sunucuda kilit meþgul"
+
+# transaction'ý iþlem diye çevirdim. Doðru mu?
+#: driver.c:1533
+msgid "SMTP transaction"
+msgstr "SMTP iþlemi"
+
+#: driver.c:1536
+msgid "DNS lookup"
+msgstr "DNS sorgusu"
+
+#: driver.c:1539
+msgid "undefined error\n"
+msgstr "tanýmlanmamýþ hata\n"
+
+#: driver.c:1550
+#, c-format
+msgid "%s error while delivering to SMTP host %s\n"
+msgstr "SMTP makinasý %2$s'e daðýtýlýrken %1$s hatasý\n"
+
+#: driver.c:1552
+#, c-format
+msgid "%s error while fetching from %s\n"
+msgstr "%2$s'den getirilirken %1$s hatasý\n"
+
+#: driver.c:1560
+#, c-format
+msgid "post-connection command failed with status %d\n"
+msgstr "baðlantý sonrasý komut %d durum kodu ile baþarýsýz oldu\n"
+
+#: driver.c:1581
+msgid "Kerberos V4 support not linked.\n"
+msgstr "Kerberos V4 desteði yok.\n"
+
+#: driver.c:1589
+msgid "Kerberos V5 support not linked.\n"
+msgstr "Kerberos V5 desteði yok.\n"
+
+#: driver.c:1600
+#, c-format
+msgid "Option --flush is not supported with %s\n"
+msgstr "--flush seçeneði %s ile desteklenmiyor\n"
+
+#: driver.c:1606
+#, c-format
+msgid "Option --all is not supported with %s\n"
+msgstr "--all seçeneði %s ile desteklenmiyor\n"
+
+#: driver.c:1614
+#, c-format
+msgid "Option --limit is not supported with %s\n"
+msgstr "--limit seçeneði %s ile desteklenmiyor\n"
+
+#: env.c:60
+#, c-format
+msgid ""
+"%s: The QMAILINJECT environment variable is set.\n"
+"This is dangerous as it can make qmail-inject or qmail's sendmail wrapper\n"
+"tamper with your From: or Message-ID: headers.\n"
+"Try \"env QMAILINJECT= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: QMAILINJECT çevre deðiþkeni var.\n"
+"Bu tehlikelidir çünkü qmail-inject ya da qmail'in sendmail\n"
+"wrapper'ýnýn From: ve Message-ID: baþlýklarýný deðiþtirmesine\n"
+"neden olabilir.\n"
+"Þunu deneyin: \"env QMAILINJECT= %s KULLANDIÐINIZ DÝÐER ARGÜMANLAR\"\n"
+"%s: Çýkýyorum.\n"
+
+#: env.c:72
+#, c-format
+msgid ""
+"%s: The NULLMAILER_FLAGS environment variable is set.\n"
+"This is dangerous as it can make nullmailer-inject or nullmailer's\n"
+"sendmail wrapper tamper with your From:, Message-ID: or Return-Path: "
+"headers.\n"
+"Try \"env NULLMAILER_FLAGS= %s YOUR ARGUMENTS HERE\"\n"
+"%s: Abort.\n"
+msgstr ""
+"%s: QMAILINJECT çevre deðiþkeni var.\n"
+"Bu tehlikelidir çünkü qmail-inject ya da qmail'in sendmail\n"
+"wrapper'ýnýn From: ve Message-ID: baþlýklarýný deðiþtirmesine\n"
+"neden olabilir.\n"
+"Þunu deneyin: \"env QMAILINJECT= %s KULLANDIÐINIZ DÝÐER ARGÜMANLAR\"\n"
+"%s: Çýkýyorum.\n"
+
+#: env.c:84
+#, c-format
+msgid "%s: You don't exist.  Go away.\n"
+msgstr "%s: Burada yoksunuz. Uzak durun.\n"
+
+#: env.c:145
+#, c-format
+msgid "%s: can't determine your host!"
+msgstr "%s: makinanýzý belirleyemiyorum!"
+
+#: env.c:161
+#, c-format
+msgid "gethostbyname failed for %s\n"
+msgstr "`gethostbyname' %s için baþarýsýz oldu\n"
+
+#: etrn.c:47 odmr.c:59
+#, c-format
+msgid "%s's SMTP listener does not support ESMTP\n"
+msgstr "%s'nin SMTP dinleyicisi ESMTP'yi desteklemiyor\n"
+
+#: etrn.c:53
+#, c-format
+msgid "%s's SMTP listener does not support ETRN\n"
+msgstr "%s'nin SMTP dinleyicisi ETRN'yi desteklemiyor\n"
+
+#: etrn.c:77
+#, c-format
+msgid "Queuing for %s started\n"
+msgstr "%s için kuyruða koyma baþladý\n"
+
+#: etrn.c:82
+#, c-format
+msgid "No messages waiting for %s\n"
+msgstr "%s için bekleyen ileti yok\n"
+
+#: etrn.c:88
+#, c-format
+msgid "Pending messages for %s started\n"
+msgstr "%s için bekleyen iletiler baþladý\n"
+
+#. Unable to queue messages for node <x>
+#: etrn.c:92
+#, c-format
+msgid "Unable to queue messages for node %s\n"
+msgstr "%s düðümü için iletiler kuyruða konamýyor\n"
+
+#. Node <x> not allowed: <reason>
+#: etrn.c:96
+#, c-format
+msgid "Node %s not allowed: %s\n"
+msgstr "Düðüm %s'in izni yok: %s\n"
+
+#. Syntax Error
+#: etrn.c:100
+msgid "ETRN syntax error\n"
+msgstr "ETRN sözdizim hatasý\n"
+
+#. Syntax Error in Parameters
+#: etrn.c:104
+msgid "ETRN syntax error in parameters\n"
+msgstr "Parametrelerde ETRN sözdizim hatasý\n"
+
+#: etrn.c:108
+#, c-format
+msgid "Unknown ETRN error %d\n"
+msgstr "Bilinmeyen ETRN hatasý %d\n"
+
+#: etrn.c:155
+msgid "Option --keep is not supported with ETRN\n"
+msgstr "--keep seçeneði ETRN ile desteklenmiyor\n"
+
+#: etrn.c:159
+msgid "Option --flush is not supported with ETRN\n"
+msgstr "--flush seçeneði ETRN ile desteklenmiyor\n"
+
+#: etrn.c:163
+msgid "Option --remote is not supported with ETRN\n"
+msgstr "--remote seçeneði ETRN ile desteklenmiyor\n"
+
+#: etrn.c:167
+msgid "Option --check is not supported with ETRN\n"
+msgstr "--check seçeneði ETRN ile desteklenmiyor\n"
+
+# bu Türkçe'nin sözdizimine uymuyor??? Ne biçim 'i18n'!! :((
+#: fetchmail.c:156
+msgid "fetchmail: invoked with"
+msgstr "fetchmail: bunlarla baþlatýldý"
+
+#: fetchmail.c:180
+msgid "could not get current working directory\n"
+msgstr "çalýþma dizini bulunamadý\n"
+
+#: fetchmail.c:190
+#, c-format
+msgid "This is fetchmail release %s"
+msgstr "fetchmail sürüm %s"
+
+#: fetchmail.c:331
+#, c-format
+msgid "Taking options from command line%s%s\n"
+msgstr "Seçenekler komut satýrýndan alýnýyor%s%s\n"
+
+#: fetchmail.c:332
+msgid " and "
+msgstr " ve "
+
+#: fetchmail.c:337
+#, c-format
+msgid "No mailservers set up -- perhaps %s is missing?\n"
+msgstr "Hiçbir posta sunucusu yok; belki %s eksik?\n"
+
+#: fetchmail.c:358
+msgid "fetchmail: no mailservers have been specified.\n"
+msgstr "fetchmail: hiçbir posta sunucusu belirtilmedi.\n"
+
+#: fetchmail.c:367 fetchmail.c:376
+msgid "fetchmail: no other fetchmail is running\n"
+msgstr "fetchmail: baþka bir fetchmail çalýþmýyor\n"
+
+#: fetchmail.c:382
+#, c-format
+msgid "fetchmail: error killing %s fetchmail at %d; bailing out.\n"
+msgstr ""
+"fetchmail: %2$d'de %1$sda çalýþan fetchmail'i öldürürken hata; çýkýyorum.\n"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "background"
+msgstr "arkaplan"
+
+#: fetchmail.c:383 fetchmail.c:389
+msgid "foreground"
+msgstr "önplan"
+
+#: fetchmail.c:388
+#, c-format
+msgid "fetchmail: %s fetchmail at %d killed.\n"
+msgstr "fetchmail: %2$d'de %1$sde çalýþan fetchmail öldürüldü.\n"
+
+#: fetchmail.c:404
+msgid ""
+"fetchmail: can't check mail while another fetchmail to same host is "
+"running.\n"
+msgstr ""
+"fetchmail: ayný makinaya baþka bir fetchmail çalýþýrken iletilere bakamam.\n"
+
+#: fetchmail.c:410
+#, c-format
+msgid ""
+"fetchmail: can't poll specified hosts with another fetchmail running at %d.\n"
+msgstr ""
+"fetchmail: %d'de çalýþan baþka bir fetchmail ile belirtilen makinalarý "
+"yoklayamam.\n"
+
+#: fetchmail.c:417
+#, c-format
+msgid "fetchmail: another foreground fetchmail is running at %d.\n"
+msgstr "fetchmail: %d'de baþka bir fetchmail önplanda çalýþýyor.\n"
+
+#: fetchmail.c:427
+msgid ""
+"fetchmail: can't accept options while a background fetchmail is running.\n"
+msgstr ""
+"fetchmail: arkaplanda bir fetchmail çalýþýrken seçenekleri kabul edemem.\n"
+
+#: fetchmail.c:433
+#, c-format
+msgid "fetchmail: background fetchmail at %d awakened.\n"
+msgstr "fetchmail: %d'de arkaplanda çalýþan fetchmail uyandýrýldý.\n"
+
+#: fetchmail.c:445
+#, c-format
+msgid "fetchmail: elder sibling at %d died mysteriously.\n"
+msgstr "fetchmail: %d büyük kardeþ süreç gizemli bir biçimde öldü.\n"
+
+#: fetchmail.c:460
+#, c-format
+msgid "fetchmail: can't find a password for %s@%s.\n"
+msgstr "fetchmail: %s@%s'in parolasýný bulamýyorum.\n"
+
+#: fetchmail.c:466
+#, c-format
+msgid "Enter password for %s@%s: "
+msgstr "%s@%s'in parolasýný yazýnýz: "
+
+#: fetchmail.c:497
+#, c-format
+msgid "starting fetchmail %s daemon \n"
+msgstr "fetchmail %s daemon baþlatýlýyor \n"
+
+#: fetchmail.c:512 fetchmail.c:514
+#, c-format
+msgid "could not open %s to append logs to \n"
+msgstr "kayýt eklemek için %s açýlamadý \n"
+
+#: fetchmail.c:552
+#, c-format
+msgid "couldn't time-check %s (error %d)\n"
+msgstr "dosya zamaný kontrol edilemedi %s (hata kodu %d)\n"
+
+#: fetchmail.c:557
+#, c-format
+msgid "restarting fetchmail (%s changed)\n"
+msgstr "fetchmail yeniden baþlatýlýyor (%s deðiþti)\n"
+
+#: fetchmail.c:562
+msgid "attempt to re-exec may fail as directory has not been restored\n"
+msgstr ""
+"yeniden baþlatma denemesi, dizin eski haline döndürülmediðinden baþarýsýz "
+"olabilir\n"
+
+#: fetchmail.c:589
+msgid "attempt to re-exec fetchmail failed\n"
+msgstr "fetchmail'i yeniden baþlatma denemesi baþarýsýz oldu\n"
+
+#: fetchmail.c:617
+#, c-format
+msgid "poll of %s skipped (failed authentication or too many timeouts)\n"
+msgstr ""
+"%s'e bakmadan atlýyorum (ya kimlik denetlemesi baþarýsýz ya da çok fazla "
+"zamamaþýmý)\n"
+
+# interval ne? time interval mi?? kaynak koduna bak
+#: fetchmail.c:629
+#, c-format
+msgid "interval not reached, not querying %s\n"
+msgstr "aralýk ulaþýlmadý, %s'i sorgulamýyorum\n"
+
+#: fetchmail.c:667
+msgid "Query status=0 (SUCCESS)\n"
+msgstr "Sorgulama durumu=0 (SUCCESS)\n"
+
+#: fetchmail.c:669
+msgid "Query status=1 (NOMAIL)\n"
+msgstr "Sorgulama durumu=1 (NOMAIL)\n"
+
+#: fetchmail.c:671
+msgid "Query status=2 (SOCKET)\n"
+msgstr "Sorgulama durumu=2 (SOCKET)\n"
+
+#: fetchmail.c:673
+msgid "Query status=3 (AUTHFAIL)\n"
+msgstr "Sorgulama durumu=3 (AUTHFAIL)\n"
+
+#: fetchmail.c:675
+msgid "Query status=4 (PROTOCOL)\n"
+msgstr "Sorgulama durumu=4 (PROTOCOL)\n"
+
+#: fetchmail.c:677
+msgid "Query status=5 (SYNTAX)\n"
+msgstr "Sorgulama durumu=5 (SYNTAX)\n"
+
+#: fetchmail.c:679
+msgid "Query status=6 (IOERR)\n"
+msgstr "Sorgulama durumu=6 (IOERR)\n"
+
+#: fetchmail.c:681
+msgid "Query status=7 (ERROR)\n"
+msgstr "Sorgulama durumu=7 (ERROR)\n"
+
+#: fetchmail.c:683
+msgid "Query status=8 (EXCLUDE)\n"
+msgstr "Sorgulama durumu=8 (EXCLUDE)\n"
+
+#: fetchmail.c:685
+msgid "Query status=9 (LOCKBUSY)\n"
+msgstr "Sorgulama durumu=9 (LOCKBUSY)\n"
+
+#: fetchmail.c:687
+msgid "Query status=10 (SMTP)\n"
+msgstr "Sorgulama durumu=10 (SMTP)\n"
+
+#: fetchmail.c:689
+msgid "Query status=11 (DNS)\n"
+msgstr "Sorgulama durumu=11 (DNS)\n"
+
+#: fetchmail.c:691
+msgid "Query status=12 (BSMTP)\n"
+msgstr "Sorgulama durumu=12 (BSMTP)\n"
+
+#: fetchmail.c:693
+msgid "Query status=13 (MAXFETCH)\n"
+msgstr "Sorgulama durumu=13 (MAXFETCH)\n"
+
+#: fetchmail.c:695
+#, c-format
+msgid "Query status=%d\n"
+msgstr "Sorgulama durumu=%d\n"
+
+# wedge'yi sýkýþmak diye çevirdim. Uygun mu?
+#: fetchmail.c:741
+msgid "All connections are wedged.  Exiting.\n"
+msgstr "Tüm baðlantýlar sýkýþtý. Çýkýyorum.\n"
+
+#: fetchmail.c:748
+#, c-format
+msgid "sleeping at %s\n"
+msgstr "fetchmail: %s'de uyuyorum\n"
+
+#: fetchmail.c:772
+#, c-format
+msgid "awakened by %s\n"
+msgstr "%s tarafýndan uyandýrýldým\n"
+
+#: fetchmail.c:775
+#, c-format
+msgid "awakened by signal %d\n"
+msgstr "%d sinyali ile tarafýndan uyandýrýldým\n"
+
+#: fetchmail.c:782
+#, c-format
+msgid "awakened at %s\n"
+msgstr "%s'de uyandýrýldým\n"
+
+#: fetchmail.c:788
+#, c-format
+msgid "normal termination, status %d\n"
+msgstr "normal bitiþ, durum kodu %d\n"
+
+#: fetchmail.c:941
+msgid "couldn't time-check the run-control file\n"
+msgstr "çalýþma denetimi (run-control) dosyasýnýn zamaný kontrol edilemedi\n"
+
+#: fetchmail.c:974
+#, c-format
+msgid "Warning: multiple mentions of host %s in config file\n"
+msgstr ""
+"Uyarý: yapýlandýrma dosyasýnda %s makinasýnýn adý birden çok kez geçiyor\n"
+
+#: fetchmail.c:1116
+msgid "SSL support is not compiled in.\n"
+msgstr "SSL desteði derlenirken eklenmemiþ.\n"
+
+# multidrop'u çeviremedim.
+#: fetchmail.c:1149
+#, c-format
+msgid ""
+"fetchmail: warning: no DNS available to check multidrop fetches from %s\n"
+msgstr ""
+"fetchmail: uyarý: %s'den multidrop iletileri kontrol etmek için DNS yok\n"
+
+#: fetchmail.c:1166
+#, c-format
+msgid "%s configuration invalid, port number cannot be negative\n"
+msgstr "%s yapýlandýrma geçersiz, port sýfýrdan küçük bir sayý olamaz\n"
+
+# priviledged port = ayrýcalýklý port???
+#: fetchmail.c:1173
+#, c-format
+msgid "%s configuration invalid, RPOP requires a privileged port\n"
+msgstr "%s yapýlandýrma geçersiz, RPOP ayrýcalýklý bir port gerektirir\n"
+
+#: fetchmail.c:1189
+#, c-format
+msgid "%s configuration invalid, LMTP can't use default SMTP port\n"
+msgstr ""
+"%s yapýlandýrma geçersiz, LMTP, SMTP'nin öntanýmlý portunu kullanamaz\n"
+
+#: fetchmail.c:1204
+msgid "Both fetchall and keep on in daemon mode is a mistake!\n"
+msgstr "`fetchall' ve daemon kipinde çalýþma birlikte olmaz!\n"
+
+#: fetchmail.c:1254
+#, c-format
+msgid "terminated with signal %d\n"
+msgstr "%d sinyali ile sona erdirildi\n"
+
+#: fetchmail.c:1339
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll started\n"
+msgstr "%4$s'de %1$s %2$s'i sorguluyor (protokol %3$s): yoklama baþlatýldý\n"
+
+#: fetchmail.c:1364
+msgid "POP2 support is not configured.\n"
+msgstr "POP2 desteði yapýlandýrýlmamýþ.\n"
+
+#: fetchmail.c:1376
+msgid "POP3 support is not configured.\n"
+msgstr "POP3 desteði yapýlandýrýlmamýþ.\n"
+
+#: fetchmail.c:1386
+msgid "IMAP support is not configured.\n"
+msgstr "IMAP desteði yapýlandýrýlmamýþ.\n"
+
+#: fetchmail.c:1392
+msgid "ETRN support is not configured.\n"
+msgstr "ETRN desteði yapýlandýrýlmamýþ.\n"
+
+#: fetchmail.c:1398
+msgid "Cannot support ETRN without gethostbyname(2).\n"
+msgstr "`gethostbyname(2)' olmadan ETRN'yi destekleyemem.\n"
+
+#: fetchmail.c:1405
+msgid "ODMR support is not configured.\n"
+msgstr "ODMR desteði yapýlandýrýlmamýþ.\n"
+
+#: fetchmail.c:1411
+msgid "Cannot support ODMR without gethostbyname(2).\n"
+msgstr "`gethostbyname(2)' olmadan ODMR'yi destekleyemem.\n"
+
+#: fetchmail.c:1417
+msgid "unsupported protocol selected.\n"
+msgstr "desteklenmeyen protokol seçilmiþ.\n"
+
+# bunu kontrol et kaynak kodunda.
+#: fetchmail.c:1427
+#, c-format
+msgid "%s querying %s (protocol %s) at %s: poll completed\n"
+msgstr ""
+"%4$s'de %1$s %2$s'i sorguluyor (protokol %3$s): yoklama tamamlandý\n"
+"\n"
+
+# poll = yoklama
+#: fetchmail.c:1444
+#, c-format
+msgid "Poll interval is %d seconds\n"
+msgstr "Nabýz yoklama aralýðý %d saniye\n"
+
+# logfile = kayýt dosyasý ?
+#: fetchmail.c:1446
+#, c-format
+msgid "Logfile is %s\n"
+msgstr "Kayýt  dosyasý = %s\n"
+
+# Idfile'i Türkçe'ye çevirebilir miyim burada (kimlik dosyasý?) Kaynak koduna bak
+#: fetchmail.c:1448
+#, c-format
+msgid "Idfile is %s\n"
+msgstr "Kimlik dosyasý %s\n"
+
+#: fetchmail.c:1451
+msgid "Progress messages will be logged via syslog\n"
+msgstr "Ýlerleme durumu iletileri syslog ile kaydedilecek.\n"
+
+#: fetchmail.c:1454
+msgid "Fetchmail will masquerade and will not generate Received\n"
+msgstr "Fetchmail kýlýk deðiþtirecek ve Received satýrý oluþturmayacak\n"
+
+#: fetchmail.c:1456
+msgid "Fetchmail will show progress dots even in logfiles.\n"
+msgstr ""
+"Fetchmail ilerleme durumunu gösteren noktalarý kayýt dosyalarýnda bile "
+"gösterecek.\n"
+
+# multidrop message ne demek?
+#: fetchmail.c:1458
+#, c-format
+msgid "Fetchmail will forward misaddressed multidrop messages to %s.\n"
+msgstr ""
+"Fetchmail yanlýþ adrese gönderilmiþ multidrop iletileri %s'e iletecek.\n"
+
+# postmaster = postmaster ??
+#: fetchmail.c:1462
+msgid "Fetchmail will direct error mail to the postmaster.\n"
+msgstr "Fetchmail hata iletisini postmaster'a iletecek.\n"
+
+#: fetchmail.c:1464
+msgid "Fetchmail will direct error mail to the sender.\n"
+msgstr "Fetchmail hata iletisini göndericiye iletecek.\n"
+
+#: fetchmail.c:1471
+#, c-format
+msgid "Options for retrieving from %s@%s:\n"
+msgstr "%s@%s'den getirmek için seçenekler:\n"
+
+#: fetchmail.c:1475
+#, c-format
+msgid "  Mail will be retrieved via %s\n"
+msgstr "  Mektuplar %s yoluyla getirilecek\n"
+
+# poll = yoklama
+#: fetchmail.c:1478
+#, c-format
+msgid "  Poll of this server will occur every %d intervals.\n"
+msgstr "  Bu sunucunun yoklamasý her %d zaman aralýðýnda yapýlacak.\n"
+
+#: fetchmail.c:1481
+#, c-format
+msgid "  True name of server is %s.\n"
+msgstr "  Sunucunun gerçek adý %s.\n"
+
+# Bu çeviriyi kontrol et.
+#: fetchmail.c:1483
+#, c-format
+msgid "  This host %s be queried when no host is specified.\n"
+msgstr "  Hiçbir makina belirtilmediðinde %s sorgulanacak.\n"
+
+# Harika. Nasýl çevrilecek bu?
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will not"
+msgstr ""
+
+# Harika! Nasýl çevrilecek þimdi bu?? :(
+#: fetchmail.c:1484 fetchmail.c:1599 fetchmail.c:1602
+msgid "will"
+msgstr ""
+
+#: fetchmail.c:1488
+msgid "  Password will be prompted for.\n"
+msgstr "  Parola sorulacak.\n"
+
+#: fetchmail.c:1492
+#, c-format
+msgid "  APOP secret = \"%s\".\n"
+msgstr "  APOP secret'i = \"%s\".\n"
+
+#: fetchmail.c:1495
+#, c-format
+msgid "  RPOP id = \"%s\".\n"
+msgstr "  RPOP kullanýcý adý = \"%s\".\n"
+
+#: fetchmail.c:1498
+#, c-format
+msgid "  Password = \"%s\".\n"
+msgstr "  Parola = \"%s\".\n"
+
+#: fetchmail.c:1511
+#, c-format
+msgid "  Protocol is KPOP with Kerberos %s authentication"
+msgstr "Protokol olarak Kerberos %s kimlik denetlemesi ile KPOP kullanýlýyor"
+
+#: fetchmail.c:1514
+#, c-format
+msgid "  Protocol is %s"
+msgstr "  Protokol %s"
+
+#: fetchmail.c:1517
+#, c-format
+msgid " (using service %s)"
+msgstr " (%s hizmetini kullanýyorum)"
+
+#: fetchmail.c:1519
+#, c-format
+msgid " (using network security options %s)"
+msgstr " (þu að güvenliði seçeneklerini kullanýyorum: %s)"
+
+#: fetchmail.c:1522
+#, c-format
+msgid " (using port %d)"
+msgstr " (port %d kullanýlýyor)"
+
+#: fetchmail.c:1525
+msgid " (using default port)"
+msgstr " (öntanýmlý port kullanýlýyor)"
+
+# 'to force' nasýl çevrilebilir?
+#: fetchmail.c:1527
+msgid " (forcing UIDL use)"
+msgstr " (UIDL kullanýmý istenecek)"
+
+#: fetchmail.c:1533
+msgid "  All available authentication methods will be tried.\n"
+msgstr "  Tüm kimlik denetleme yöntemleri denenecek.\n"
+
+#: fetchmail.c:1536
+msgid "  Password authentication will be forced.\n"
+msgstr "  Parola ile kimlik kanýtlamasý istenecek.\n"
+
+#: fetchmail.c:1539
+msgid "  NTLM authentication will be forced.\n"
+msgstr "  NTLM kimlik kanýtlamasý istenecek.\n"
+
+#: fetchmail.c:1542
+msgid "  OTP authentication will be forced.\n"
+msgstr "  OTP kimlik kanýtlamasý istenecek.\n"
+
+#: fetchmail.c:1545
+msgid "  CRAM-Md5 authentication will be forced.\n"
+msgstr "  CRAM-Md5 kimlik kanýtlamasý istenecek.\n"
+
+#: fetchmail.c:1548
+msgid "  GSSAPI authentication will be forced.\n"
+msgstr "  GSSAPI kimlik kanýtlamasý istenecek.\n"
+
+#: fetchmail.c:1551
+msgid "  Kerberos V4 authentication will be forced.\n"
+msgstr "  Kerberos V4 kimlik kanýtlamasý istenecek.\n"
+
+#: fetchmail.c:1554
+msgid "  Kerberos V5 authentication will be forced.\n"
+msgstr "  Kerberos V5 kimlik kanýtlamasý istenecek.\n"
+
+#: fetchmail.c:1557
+msgid "  End-to-end encryption assumed.\n"
+msgstr "  Uçtan uca þifreleme varsayýlýyor.\n"
+
+# mail service principal ne demek?
+#: fetchmail.c:1561
+#, c-format
+msgid "  Mail service principal is: %s\n"
+msgstr "  Posta hizmeti 'pricipal'i: %s\n"
+
+#: fetchmail.c:1564
+msgid "  SSL encrypted sessions enabled.\n"
+msgstr "  SSL ile þifrelenmiþ oturumlar etkinleþtirildi.\n"
+
+#: fetchmail.c:1566
+#, c-format
+msgid "  SSL protocol: %s.\n"
+msgstr "  SSL protokolü: %s.\n"
+
+#: fetchmail.c:1568
+msgid "  SSL server certificate checking enabled.\n"
+msgstr "  SSL sunucu sertifikasý kontrolü etkinleþtirildi.\n"
+
+#: fetchmail.c:1570
+#, c-format
+msgid "  SSL trusted certificate directory: %s\n"
+msgstr "  SSL güvenilir sertifika dizini: %s\n"
+
+#: fetchmail.c:1573
+#, c-format
+msgid "  SSL key fingerprint (checked against the server key): %s\n"
+msgstr "  SSL anahtar parmakizi (sunucu anahtarý ile denetlendi): %s\n"
+
+#: fetchmail.c:1576
+#, c-format
+msgid "  Server nonresponse timeout is %d seconds"
+msgstr "  Sunucu zamanaþýmý %d saniye"
+
+#: fetchmail.c:1578
+msgid " (default).\n"
+msgstr " (öntanýmlý).\n"
+
+#: fetchmail.c:1585
+msgid "  Default mailbox selected.\n"
+msgstr "  Öntanýmlý posta kutusu seçildi.\n"
+
+#: fetchmail.c:1590
+msgid "  Selected mailboxes are:"
+msgstr "  Seçilen posta kutularý:"
+
+#  bu çeviriyi kontrol et
+#: fetchmail.c:1595
+#, c-format
+msgid "  %s messages will be retrieved (--all %s).\n"
+msgstr "  %s ileti getirilecek (--all %s).\n"
+
+#: fetchmail.c:1596
+msgid "All"
+msgstr "Hepsi"
+
+#: fetchmail.c:1596
+msgid "Only new"
+msgstr "Yalnýzca yeniler"
+
+#: fetchmail.c:1598
+#, c-format
+msgid "  Fetched messages %s be kept on the server (--keep %s).\n"
+msgstr "  Getirilen iletiler %s sunucuda tutulacak (--keep %s).\n"
+
+#: fetchmail.c:1601
+#, c-format
+msgid "  Old messages %s be flushed before message retrieval (--flush %s).\n"
+msgstr "  Eski iletiler %s ileti alýmýndan önce boþaltýlacak (--flush %s).\n"
+
+#: fetchmail.c:1604
+#, c-format
+msgid "  Rewrite of server-local addresses is %s (--norewrite %s).\n"
+msgstr "  server-local adreslerin yeniden yazýlmasý %s (--norewrite %s).\n"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "enabled"
+msgstr "etkin"
+
+#: fetchmail.c:1605 fetchmail.c:1608 fetchmail.c:1611 fetchmail.c:1614
+#: fetchmail.c:1617 fetchmail.c:1620 fetchmail.c:1767
+msgid "disabled"
+msgstr "etkin deðil"
+
+# carriage-return?? Baþkalarýna sor
+#: fetchmail.c:1607
+#, c-format
+msgid "  Carriage-return stripping is %s (stripcr %s).\n"
+msgstr "  Carriage-return'lerin silinmesi %s (stripcr %s).\n"
+
+# carriage-return?? Baþkalarýna sor
+#: fetchmail.c:1610
+#, c-format
+msgid "  Carriage-return forcing is %s (forcecr %s).\n"
+msgstr "  Carriage-return'lerin zorunlu kullanýmý %s (orcecr %s).\n"
+
+#: fetchmail.c:1613
+#, c-format
+msgid "  Interpretation of Content-Transfer-Encoding is %s (pass8bits %s).\n"
+msgstr "  Content-Transfer-Encoding'in yorumu %s (pass8bits %s).\n"
+
+#: fetchmail.c:1616
+#, c-format
+msgid "  MIME decoding is %s (mimedecode %s).\n"
+msgstr "  MIME kod çözümü %s (mimedecode %s).\n"
+
+# idle = ?? Baþkalarýna sor
+#: fetchmail.c:1619
+#, c-format
+msgid "  Idle after poll is %s (idle %s).\n"
+msgstr "  Yoklamadan sonra 'idle' kalma %s (idle %s).\n"
+
+# Bunun aþaðýdaki 'discarded' ve 'kept' ile iliþkisi var, birlikte
+# düþünülmeliler.
+#: fetchmail.c:1622
+#, c-format
+msgid "  Nonempty Status lines will be %s (dropstatus %s)\n"
+msgstr "  Boþ olmayan Status satýrlarý %s (dropstatus %s)\n"
+
+# 	    printf(GT_("  Nonempty Status lines will be %s (dropstatus %s)\n"),
+# 		   ctl->dropstatus ? GT_("discarded") : GT_("kept"),
+# 		   ctl->dropstatus ? "on" : "off");
+# 	    printf(GT_("  Delivered-To lines will be %s (dropdelivered %s)\n"),
+# 		   ctl->dropdelivered ? GT_("discarded") : GT_("kept"),
+# 		   ctl->dropdelivered ? "on" : "off");
+#
+# DIKKAT: 'discarded' ve 'kept'in durumlari özel; atýlacak ve tutulacak
+# olarak çevrilmeleri gerekiyor.
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "discarded"
+msgstr "atýlacak"
+
+#: fetchmail.c:1623 fetchmail.c:1626
+msgid "kept"
+msgstr "tutulacak"
+
+# Bunun yukarýdaki 'discarded' ve 'kept' ile iliþkisi var, birlikte
+# düþünülmeliler.
+#: fetchmail.c:1625
+#, c-format
+msgid "  Delivered-To lines will be %s (dropdelivered %s)\n"
+msgstr "  Delivered-To satýrlarý %s (dropdelivered %s)\n"
+
+#: fetchmail.c:1631
+#, c-format
+msgid "  Message size limit is %d octets (--limit %d).\n"
+msgstr "  Ýleti boyut sýnýrý %d sekizlik (--limit %d).\n"
+
+#: fetchmail.c:1634
+msgid "  No message size limit (--limit 0).\n"
+msgstr "  Ýleti boyut sýnýrý yok (--limit 0).\n"
+
+#: fetchmail.c:1636
+#, c-format
+msgid "  Message size warning interval is %d seconds (--warnings %d).\n"
+msgstr "  Ýleti boyut uyarýsý aralýðý %d saniye (--warnings %d).\n"
+
+# poll = yoklama
+#: fetchmail.c:1639
+msgid "  Size warnings on every poll (--warnings 0).\n"
+msgstr "  Her yoklamada büyüklük uyarýsý (--warnings 0).\n"
+
+#: fetchmail.c:1642
+#, c-format
+msgid "  Received-message limit is %d (--fetchlimit %d).\n"
+msgstr "  Alýnan ileti sýnýrý %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1645
+msgid "  No received-message limit (--fetchlimit 0).\n"
+msgstr "  Alýnan ileti sýnýrý yok (--fetchlimit 0).\n"
+
+#: fetchmail.c:1647
+#, fuzzy, c-format
+msgid "  Fetch message size limit is %d (--fetchsizelimit %d).\n"
+msgstr "  Alýnan ileti sýnýrý %d (--fetchlimit %d).\n"
+
+#: fetchmail.c:1650
+#, fuzzy
+msgid "  No fetch message size limit (--fetchsizelimit 0).\n"
+msgstr "  Ýleti boyut sýnýrý yok (--limit 0).\n"
+
+#: fetchmail.c:1654
+msgid "  Do binary search of UIDs during each poll (--fastuidl 1).\n"
+msgstr ""
+
+#: fetchmail.c:1656
+#, c-format
+msgid "  Do binary search of UIDs during %d out of %d polls (--fastuidl %d).\n"
+msgstr ""
+
+#: fetchmail.c:1659
+msgid "   Do linear search of UIDs during each poll (--fastuidl 0).\n"
+msgstr ""
+
+# batch = ?
+#: fetchmail.c:1661
+#, c-format
+msgid "  SMTP message batch limit is %d.\n"
+msgstr "  SMTP ileti 'batch' limiti %d.\n"
+
+# batch = ??
+#: fetchmail.c:1663
+msgid "  No SMTP message batch limit (--batchlimit 0).\n"
+msgstr "  SMTP iletisi 'batch' limiti yok (--batchlimit 0).\n"
+
+#: fetchmail.c:1667
+#, c-format
+msgid "  Deletion interval between expunges forced to %d (--expunge %d).\n"
+msgstr ""
+"  Silmeler arasýndaki zaman aralýðý olarak %d kullanýlacak (--expunge %d).\n"
+
+#: fetchmail.c:1669
+msgid "  No forced expunges (--expunge 0).\n"
+msgstr "  Silmeler zorlanmayacak (--expunge 0).\n"
+
+# bu çeviriye bir bak. domain=alan deyince 'alanlar' sanki 'recipients' gibi anlaþýlabilir??
+#: fetchmail.c:1676
+msgid "  Domains for which mail will be fetched are:"
+msgstr "  Þu alanlar (domains) için posta getirilecek:"
+
+#: fetchmail.c:1681 fetchmail.c:1701
+msgid " (default)"
+msgstr " (öntanýmlý)"
+
+#: fetchmail.c:1686
+#, c-format
+msgid "  Messages will be appended to %s as BSMTP\n"
+msgstr "  Ýletiler %s'e BSMTP olarak eklenecek\n"
+
+#: fetchmail.c:1688
+#, c-format
+msgid "  Messages will be delivered with \"%s\".\n"
+msgstr "  Ýletiler \"%s\" ile ulaþtýrýlacak.\n"
+
+#: fetchmail.c:1695
+#, c-format
+msgid "  Messages will be %cMTP-forwarded to:"
+msgstr "  Ýletiler %cMTP ile aþaðýdakilere iletilecek:"
+
+#: fetchmail.c:1706
+#, c-format
+msgid "  Host part of MAIL FROM line will be %s\n"
+msgstr "  MAIL FROM satýrýnýn bilgisayar bölümü %s olacak\n"
+
+#: fetchmail.c:1709
+#, c-format
+msgid "  Address to be put in RCPT TO lines shipped to SMTP will be %s\n"
+msgstr "  SMTP'ye gönderilecek RCPT TO satýrlarýna konacak adres %s olacak\n"
+
+#: fetchmail.c:1718
+msgid "  Recognized listener spam block responses are:"
+msgstr "  Bilinen dinleyici spam engelleme yanýtlarý þöyle:"
+
+#: fetchmail.c:1724
+msgid "  Spam-blocking disabled\n"
+msgstr "  Spam engelleme etkin deðil\n"
+
+#: fetchmail.c:1727
+#, c-format
+msgid "  Server connection will be brought up with \"%s\".\n"
+msgstr "  Sunucu baðlantýsý \"%s\" ile açýlacak.\n"
+
+#: fetchmail.c:1730
+msgid "  No pre-connection command.\n"
+msgstr "  Hiçbir baðlantý öncesi komutu yok.\n"
+
+#: fetchmail.c:1732
+#, c-format
+msgid "  Server connection will be taken down with \"%s\".\n"
+msgstr "  Sunucu baðlantýsý \"%s\" ile kopatýlacak.\n"
+
+#: fetchmail.c:1735
+msgid "  No post-connection command.\n"
+msgstr "  Hiçbir baðlantý öncesi komutu yok.\n"
+
+#: fetchmail.c:1738
+msgid "  No localnames declared for this host.\n"
+msgstr "  Bu makina için hiçbir yerel ad tanýmlanmamýþ.\n"
+
+#: fetchmail.c:1748
+msgid "  Multi-drop mode: "
+msgstr "  Multi-drop kipi: "
+
+#: fetchmail.c:1750
+msgid "  Single-drop mode: "
+msgstr "  Single-drop kipi: "
+
+#: fetchmail.c:1752
+#, c-format
+msgid "%d local name(s) recognized.\n"
+msgstr "%d yerel ad tanýndý.\n"
+
+# buradaki %s 'enabled' ve 'disabled' oluyor :(
+#: fetchmail.c:1766
+#, c-format
+msgid "  DNS lookup for multidrop addresses is %s.\n"
+msgstr "  Multidrop adresler için DNS sorgulamasý %s.\n"
+
+# Bu string'den hemen sonra aþaðýdaki iki string geliyor ("IP address."
+# ve "name.". Dilbilgisi yapýsý Türkçeye tümüyle ters olduðundan
+# bunlarý aþaðýdaki iki iletide çevirmeyi uygun buldum. Kaynak koduna
+# bakmak gerek niye böyle olduðunu anlamak için.
+#: fetchmail.c:1770
+msgid "  Server aliases will be compared with multidrop addresses by "
+msgstr "  "
+
+# Niçin böyle çevrildiðini anlamak için yukarýdaki iletiye
+# bakýnýz.
+#: fetchmail.c:1772
+msgid "IP address.\n"
+msgstr "Sunucu takma adlarý IP adresleri kullanýlarak karþýlaþtýrýlacak.\n"
+
+# Niçin böyle çevrildiðini anlamak için yukarýdaki iletiye
+# bakýnýz.
+#: fetchmail.c:1774
+msgid "name.\n"
+msgstr "Sunucu takma adlarý, adlarý kullanýlarak karþýlaþtýrýlacak.\n"
+
+#: fetchmail.c:1777
+msgid "  Envelope-address routing is disabled\n"
+msgstr "  Envelope-address routing etkin deðil\n"
+
+#: fetchmail.c:1780
+#, c-format
+msgid "  Envelope header is assumed to be: %s\n"
+msgstr "  Envelope baþlýðý þöyle varsayýlýyor: %s\n"
+
+# Bu ileti yukarýdaki "Envelope header is assumed to be: %" iletisine
+# baðlý.
+#: fetchmail.c:1781
+msgid "Received"
+msgstr "Received"
+
+#: fetchmail.c:1783
+#, c-format
+msgid "  Number of envelope header to be parsed: %d\n"
+msgstr "  Parse edilecek envelope baþlýðý sayýsý: %d\n"
+
+#: fetchmail.c:1786
+#, c-format
+msgid "  Prefix %s will be removed from user id\n"
+msgstr "  %s öneki kullanýcý kimliðinden silinecek\n"
+
+#: fetchmail.c:1789
+msgid "  No prefix stripping\n"
+msgstr "  Sonekler silinmeyecek\n"
+
+#: fetchmail.c:1796
+msgid "  Predeclared mailserver aliases:"
+msgstr "  Önceden tanýmlanmýþ posta sunucusu takma adlarý:"
+
+#: fetchmail.c:1805
+msgid "  Local domains:"
+msgstr "  Yerel alanlar:"
+
+#: fetchmail.c:1815
+#, c-format
+msgid "  Connection must be through interface %s.\n"
+msgstr "  Baðlatý %s arayüzünden olmalý.\n"
+
+#: fetchmail.c:1817
+msgid "  No interface requirement specified.\n"
+msgstr "  Belirli bir arayüzün kullanýlmasý zorunlu koþulmamýþ.\n"
+
+#: fetchmail.c:1819
+#, c-format
+msgid "  Polling loop will monitor %s.\n"
+msgstr "  Yoklama döngüsü %s'i gözleyecek.\n"
+
+#: fetchmail.c:1821
+msgid "  No monitor interface specified.\n"
+msgstr "  Gözleme arayüzü belirtilmemiþ.\n"
+
+# plugin == ?
+#: fetchmail.c:1825
+#, c-format
+msgid "  Server connections will be made via plugin %s (--plugin %s).\n"
+msgstr "  Sunucu baðlantýlarý %s plugin'i ile yapýlacak (--plugin %s).\n"
+
+#: fetchmail.c:1827
+msgid "  No plugin command specified.\n"
+msgstr "  Plugin komutu belirtilmemiþ.\n"
+
+# plugout da ne demek?
+#: fetchmail.c:1829
+#, c-format
+msgid "  Listener connections will be made via plugout %s (--plugout %s).\n"
+msgstr "  Dinleyici baðlantýlarý %s plugout'u ile yapýlacak (--plugput %s).\n"
+
+#: fetchmail.c:1831
+msgid "  No plugout command specified.\n"
+msgstr "  Plugout komutu belirtilmemiþ.\n"
+
+#: fetchmail.c:1836
+msgid "  No UIDs saved from this host.\n"
+msgstr "  Bu makineden hiçbir UID saklanmadý.\n"
+
+#: fetchmail.c:1845
+#, c-format
+msgid "  %d UIDs saved.\n"
+msgstr "  %d UID saklandý.\n"
+
+#: fetchmail.c:1853
+msgid "  Poll trace information will be added to the Received header.\n"
+msgstr "  Received baþlýðýna yoklama izleme bilgisi eklenecek.\n"
+
+#: fetchmail.c:1855
+msgid ""
+"  No poll trace information will be added to the Received header.\n"
+".\n"
+msgstr ""
+"  Received baþlýðýna yoklama izleme bilgisi eklenmeyecek.\n"
+".\n"
+
+#: fetchmail.c:1858
+#, c-format
+msgid "  Pass-through properties \"%s\".\n"
+msgstr "  Özellikler geçiriliyor \"%s\".\n"
+
+#.
+#. * This is a hack to help xgettext which cannot find strings in
+#. * macro definitions like the one for xalloca above.
+#.
+#: fetchmail.h:584 fetchmail.h:590
+msgid "alloca failed"
+msgstr "alloca baþarýsýz oldu"
+
+#: getpass.c:72
+msgid "ERROR: no support for getpassword() routine\n"
+msgstr "HATA: getpassword() desteklenmiyor\n"
+
+#: getpass.c:194
+msgid ""
+"\n"
+"Caught SIGINT... bailing out.\n"
+msgstr ""
+"\n"
+"SIGINT yakalandý... çýkýyorum.\n"
+
+#: gssapi.c:62
+#, c-format
+msgid "Couldn't get service name for [%s]\n"
+msgstr "[%s] için hizmet adý alýnamadý\n"
+
+#: gssapi.c:68
+#, c-format
+msgid "Using service name [%s]\n"
+msgstr "Hizmet adý olarak [%s] kullanýlýyor\n"
+
+#: gssapi.c:84
+msgid "Sending credentials\n"
+msgstr "Credential'lar gönderiliyor\n"
+
+#: gssapi.c:102
+msgid "Error exchanging credentials\n"
+msgstr "Credential takasýnda hata\n"
+
+#: gssapi.c:144
+msgid "Couldn't unwrap security level data\n"
+msgstr "Güvenlik düzeyi verisi elde edilemedi\n"
+
+#: gssapi.c:149
+msgid "Credential exchange complete\n"
+msgstr "Crendential takasý tamamlandý\n"
+
+#: gssapi.c:153
+msgid "Server requires integrity and/or privacy\n"
+msgstr "Sunucu iç tutarlýlýk ve/ya da mahremiyet gerektiriyor\n"
+
+#: gssapi.c:162
+#, c-format
+msgid "Unwrapped security level flags: %s%s%s\n"
+msgstr "Güvenlik düzeyi bayraklarý: %s%s%s\n"
+
+#: gssapi.c:166
+#, c-format
+msgid "Maximum GSS token size is %ld\n"
+msgstr "En büyük GSS token boyutu %ld\n"
+
+#: gssapi.c:179
+msgid "Error creating security level request\n"
+msgstr "Güvenlik düzeyi isteðini oluþtururken hata\n"
+
+#: gssapi.c:190
+msgid "Releasing GSS credentials\n"
+msgstr "GSS credential'larý býrakýlýyor\n"
+
+#: gssapi.c:193
+msgid "Error releasing credentials\n"
+msgstr "Credential'lar býrakýlýrken hata\n"
+
+#: idle.c:62
+#, c-format
+msgid "fetchmail: thread sleeping for %d sec.\n"
+msgstr "fetchmail: thread %d saniye uyuyor.\n"
+
+#: imap.c:280
+msgid "Protocol identified as IMAP4 rev 1\n"
+msgstr "Protokol IMAP4 rev 1 olarak belirlendi\n"
+
+#: imap.c:286
+msgid "Protocol identified as IMAP4 rev 0\n"
+msgstr "Protokol IMAP rev 0 olarak belirlendi.\n"
+
+#: imap.c:293
+msgid "Protocol identified as IMAP2 or IMAP2BIS\n"
+msgstr "Protokol IMAP2 ya da IMAP2BIS olarak belirlendi\n"
+
+#: imap.c:308
+msgid "will idle after poll\n"
+msgstr "yoklamadan sonra idle kalýnacak\n"
+
+#: imap.c:460
+msgid "Required OTP capability not compiled into fetchmail\n"
+msgstr "fetchmail gerekli OTP desteði ile derlenmemiþ\n"
+
+#: imap.c:482
+msgid "Required NTLM capability not compiled into fetchmail\n"
+msgstr "fetchmail gerekli NTLM desteði ile derlenmemiþ\n"
+
+#: imap.c:491
+msgid "Required LOGIN capability not supported by server\n"
+msgstr "Sunucu gerekli LOGIN yeteneðini desteklemiyor\n"
+
+#: imap.c:641 imap.c:707
+msgid "expunge failed\n"
+msgstr "silme baþarýsýz oldu\n"
+
+#: imap.c:663 imap.c:692
+msgid "re-poll failed\n"
+msgstr "yeniden yoklama baþarýsýz oldu\n"
+
+#: imap.c:671
+#, c-format
+msgid "%d messages waiting after re-poll\n"
+msgstr "yeniden yokladýktan sonra %d ileti bekliyor\n"
+
+#: imap.c:681
+msgid "mailbox selection failed\n"
+msgstr "posta kutusu seçimi baþarýsýz oldu\n"
+
+#: imap.c:685
+#, c-format
+msgid "%d messages waiting after first poll\n"
+msgstr "ilk yoklamadan sonra %d ileti bekliyor\n"
+
+#: imap.c:711
+#, c-format
+msgid "%d messages waiting after expunge\n"
+msgstr "silinmeden sonra %d ileti bekliyor\n"
+
+#: imap.c:734
+msgid "search for unseen messages failed\n"
+msgstr "görülmemiþ iletileri arama iþlemi baþarýsýz oldu\n"
+
+#: imap.c:764 pop3.c:658 pop3.c:670 pop3.c:887 pop3.c:894
+#, c-format
+msgid "%u is unseen\n"
+msgstr "%u görülmemiþ\n"
+
+#: imap.c:776 pop3.c:679
+#, c-format
+msgid "%u is first unseen\n"
+msgstr "%u ilk görülmemiþ\n"
+
+#: interface.c:253
+msgid "Unable to open kvm interface. Make sure fetchmail is SGID kmem."
+msgstr "kvm arayüzü açýlamadý. fetchmail'in SGID kmem olduðundan emin olunuz."
+
+#: interface.c:398
+#, c-format
+msgid "Unable to parse interface name from %s"
+msgstr "%s'den arayüz adýný çýkaramadým"
+
+#: interface.c:420
+msgid "get_ifinfo: sysctl (iflist estimate) failed"
+msgstr "get_ifinfo: sysctl (iflist kestirme) baþarýsýz oldu"
+
+#: interface.c:426
+msgid "get_ifinfo: malloc failed"
+msgstr "get_ifinfo: malloc baþarýsýz oldu"
+
+#: interface.c:432
+msgid "get_ifinfo: sysctl (iflist) failed"
+msgstr "get_ifinfo: sysctl (iflist) baþarýsýz oldu"
+
+#: interface.c:450
+#, c-format
+msgid "Routing message version %d not understood."
+msgstr "Routing iletisi sürüm %d anlaþýlamadý."
+
+#. we did not find an interface with a matching name
+#: interface.c:482
+#, c-format
+msgid "No interface found with name %s"
+msgstr "Adý %s olan bir arayüz bulunamadý"
+
+#: interface.c:540
+#, c-format
+msgid "No IP address found for %s"
+msgstr "%s için bir IP adresi bulunamadý"
+
+#: interface.c:592
+msgid "missing IP interface address\n"
+msgstr "IP arayüzü adresi yok\n"
+
+#: interface.c:608
+msgid "invalid IP interface address\n"
+msgstr "geçersiz IP arayüzü adresi\n"
+
+#: interface.c:614
+msgid "invalid IP interface mask\n"
+msgstr "geçersiz IP arayüzü maskesi\n"
+
+#: interface.c:653
+#, c-format
+msgid "activity on %s -noted- as %d\n"
+msgstr "activity on %s -noted- as %d\n"
+
+#: interface.c:668
+#, c-format
+msgid "skipping poll of %s, %s down\n"
+msgstr "%s'in yoklanmasýný atlýyorum, %s çalýþmýyor\n"
+
+#: interface.c:687
+#, c-format
+msgid "skipping poll of %s, %s IP address excluded\n"
+msgstr "%s'in yoklamasý atlanýyor, %s IP adresi dýþarýda tutuluyor\n"
+
+#: interface.c:699
+#, c-format
+msgid "activity on %s checked as %d\n"
+msgstr "activity on %s checked as %d\n"
+
+#: interface.c:725
+#, c-format
+msgid "skipping poll of %s, %s inactive\n"
+msgstr "%s'in yoklamasý atlanýyor, %s etkin deðil\n"
+
+#: interface.c:732
+#, c-format
+msgid "activity on %s was %d, is %d\n"
+msgstr "%s'de etkinlik %d idi, þimdi %d\n"
+
+#: kerberos.c:74
+msgid "could not decode initial BASE64 challenge\n"
+msgstr "Ýlk BASE64 challenge'ýnýn kodu çözülemedi\n"
+
+#: kerberos.c:139
+#, c-format
+msgid "principal %s in ticket does not match -u %s\n"
+msgstr "Ticket'teki %s principal'ý -u %s'e uymuyor\n"
+
+#: kerberos.c:147
+#, c-format
+msgid "non-null instance (%s) might cause strange behavior\n"
+msgstr "null olmayan (%s) garip davranýþa neden olabilir\n"
+
+#: kerberos.c:213
+msgid "could not decode BASE64 ready response\n"
+msgstr "BASE64 hazýr yanýtýnýn kodu çözülemedi\n"
+
+#: kerberos.c:220
+msgid "challenge mismatch\n"
+msgstr "challenge'lar uymuyor\n"
+
+#: lock.c:81
+msgid "fetchmail: removing stale lockfile\n"
+msgstr "fetchmail: eski kilit dosyasýný siliyorum \n"
+
+#: lock.c:122
+msgid "fetchmail: lock creation failed.\n"
+msgstr "fetchmail: kilit oluþturulamadý.\n"
+
+#: netrc.c:218
+#, c-format
+msgid "warning: found \"%s\" before any host names"
+msgstr "uyarý: herhangi bir makina adýndan önce \"%s\" bulundu"
+
+#: netrc.c:222
+#, c-format
+msgid "%s:%d: warning: found \"%s\" before any host names\n"
+msgstr "%s:%d: uyarý: herhangi bir makina adýndan önce \"%s\" bulundu\n"
+
+#: netrc.c:261
+#, c-format
+msgid "%s:%d: warning: unknown token \"%s\"\n"
+msgstr "%s:%d: uyarý: bilinmeyen token \"%s\"\n"
+
+#: odmr.c:65
+#, c-format
+msgid "%s's SMTP listener does not support ATRN\n"
+msgstr "%s'in SMTP dinleyicisi ATRN'yi desteklemiyor\n"
+
+#: odmr.c:103
+msgid "Turnaround now...\n"
+msgstr "Roller deðiþiliyor...\n"
+
+#: odmr.c:108
+msgid "ATRN request refused.\n"
+msgstr "ATRN isteði reddedildi.\n"
+
+#. Unable to process ATRN request now
+#: odmr.c:112
+msgid "Unable to process ATRN request now\n"
+msgstr "ATRN isteðini þimdi iþleyemiyorum\n"
+
+#: odmr.c:117
+msgid "You have no mail.\n"
+msgstr "Mektubunuz yok.\n"
+
+#. Command not implemented
+#: odmr.c:121
+msgid "Command not implemented\n"
+msgstr "Bu komut gerçeklenmemiþ\n"
+
+#. Authentication required
+#: odmr.c:125
+msgid "Authentication required.\n"
+msgstr "Kimlik kanýtlamasý gerekiyor.\n"
+
+#: odmr.c:129
+#, c-format
+msgid "Unknown ODMR error %d\n"
+msgstr "Bilinmeyen ODMR hatasý %d\n"
+
+#: odmr.c:244
+msgid "Option --keep is not supported with ODMR\n"
+msgstr "--keep seçeneði ODMR ile desteklenmiyor\n"
+
+#: odmr.c:248
+msgid "Option --flush is not supported with ODMR\n"
+msgstr "--flush seçeneði ODMR ile desteklenmiyor\n"
+
+#: odmr.c:252
+msgid "Option --remote is not supported with ODMR\n"
+msgstr "--remote seçeneði ODMR ile desteklenmiyor\n"
+
+#: odmr.c:256
+msgid "Option --check is not supported with ODMR\n"
+msgstr "--check seçeneði ODMR ile desteklenmiyor\n"
+
+#: opie.c:37
+msgid "server recv fatal\n"
+msgstr "sunucu recv ölümcül\n"
+
+#: opie.c:51
+msgid "Could not decode OTP challenge\n"
+msgstr "OPT challenge'ýnýn kodu çözülemedi\n"
+
+#: opie.c:59 pop3.c:495
+msgid "Secret pass phrase: "
+msgstr "Parola: "
+
+#: options.c:201 options.c:245
+#, c-format
+msgid "String '%s' is not a valid number string.\n"
+msgstr "'%s' katarý geçerli bir sayý katarý deðil.\n"
+
+#: options.c:210
+#, c-format
+msgid "Value of string '%s' is %s than %d.\n"
+msgstr "'%1$s'in deðeri %3$d'den %2$s.\n"
+
+#: options.c:211
+msgid "smaller"
+msgstr "küçük"
+
+#: options.c:211
+msgid "larger"
+msgstr "büyük"
+
+#: options.c:383
+#, c-format
+msgid "Invalid protocol `%s' specified.\n"
+msgstr "Geçersiz protokol `%s' belirtilmiþ.\n"
+
+#: options.c:429
+#, c-format
+msgid "Invalid authentication `%s' specified.\n"
+msgstr "Geçersiz kimlik denetlemesi yöntemi `%s' belirtilmiþ.\n"
+
+#: options.c:567
+msgid "fetchmail: network security support is disabled\n"
+msgstr "fetchmail: að güvenliði desteði etkin deðil\n"
+
+#: options.c:660
+msgid "usage:  fetchmail [options] [server ...]\n"
+msgstr "kullaným: fetchmail [seçenekler] [sunucu ...]\n"
+
+#: options.c:661
+msgid "  Options are as follows:\n"
+msgstr "  Aþaðýdaki seçenekler kullanýlabilir:\n"
+
+#: options.c:662
+msgid "  -?, --help        display this option help\n"
+msgstr "  -?, --help        bu yardým iletisini göster\n"
+
+#: options.c:663
+msgid "  -V, --version     display version info\n"
+msgstr "  -V, --version     sürüm bilgisini göster\n"
+
+#: options.c:665
+msgid "  -c, --check       check for messages without fetching\n"
+msgstr "  -c, --check       iletileri kontrol et ama getirme\n"
+
+#: options.c:666
+msgid "  -s, --silent      work silently\n"
+msgstr "  -s, --silent      sessizce çalýþ\n"
+
+#: options.c:667
+msgid "  -v, --verbose     work noisily (diagnostic output)\n"
+msgstr "  -v, --verbose     çok ayrýntýlý bilgi ver (tanýlama çýktýsý)\n"
+
+#: options.c:668
+msgid "  -d, --daemon      run as a daemon once per n seconds\n"
+msgstr "  -d, --daemon      n saniye için bir kez daemon olarak  çalýþ\n"
+
+#: options.c:669
+msgid "  -N, --nodetach    don't detach daemon process\n"
+msgstr "  -N, --nodetach    deamon sürecini 'detach' etme\n"
+
+#: options.c:670
+msgid "  -q, --quit        kill daemon process\n"
+msgstr "  -q, --quit        daemon sürecini öldür\n"
+
+#: options.c:671
+msgid "  -L, --logfile     specify logfile name\n"
+msgstr "  -L, --logfile     kayýt dosyasý adýný belirle\n"
+
+#: options.c:672
+msgid ""
+"      --syslog      use syslog(3) for most messages when running as a "
+"daemon\n"
+msgstr ""
+"      --syslog      daemon olarak çalýþýrken çoðu ileti için syslog(3) "
+"kullan\n"
+
+#: options.c:673
+msgid "      --invisible   don't write Received & enable host spoofing\n"
+msgstr ""
+"      --invisible   'Received' satýrlarýný yazma ve 'spoof' etmeye izin ver\n"
+
+#: options.c:674
+msgid "  -f, --fetchmailrc specify alternate run control file\n"
+msgstr "  -f, --fetchmailrc baþka bir yapýlandýrma dosyasý kullan\n"
+
+#: options.c:675
+msgid "  -i, --idfile      specify alternate UIDs file\n"
+msgstr "  -i, --idfile      baþka bir UID dosyasý kullan\n"
+
+#: options.c:676
+msgid "      --postmaster  specify recipient of last resort\n"
+msgstr "      --postmaster  baþka bir \"son çare\" alýcýsý belirle\n"
+
+#: options.c:677
+msgid "      --nobounce    redirect bounces from user to postmaster.\n"
+msgstr ""
+"      --nobounce    bounce eden iletileri kullanýcýdan postmaster'a gönder.\n"
+
+#: options.c:679
+msgid "  -I, --interface   interface required specification\n"
+msgstr "  -I, --interface   interface required specification\n"
+
+#: options.c:680
+msgid "  -M, --monitor     monitor interface for activity\n"
+msgstr "  -M, --monitor     arayüzün etkinliðini gözle\n"
+
+#: options.c:683
+msgid "      --ssl         enable ssl encrypted session\n"
+msgstr "      --ssl         ssl ile þifrelenmiþ oturumu etkinleþtir\n"
+
+#: options.c:684
+msgid "      --sslkey      ssl private key file\n"
+msgstr "      --sslkey      ssl özel anahtar dosyasý\n"
+
+#: options.c:685
+msgid "      --sslcert     ssl client certificate\n"
+msgstr "      --sslcert     ssl istemci sertifikasý\n"
+
+#: options.c:686
+msgid "      --sslproto    force ssl protocol (ssl2/ssl3/tls1)\n"
+msgstr "      --sslproto    ssl protokolünü seç (ssl2/ssl3/tls1)\n"
+
+#: options.c:688
+msgid "      --plugin      specify external command to open connection\n"
+msgstr ""
+"      --plugin      baðlatýlarý açmak için dýþarýdan bir program belirle\n"
+
+#: options.c:689
+msgid "      --plugout     specify external command to open smtp connection\n"
+msgstr ""
+"      --plugout     SMTP baðlantýlarýný yapmak için dýþarýdan bir program "
+"belirle\n"
+
+#: options.c:691
+msgid "  -p, --protocol    specify retrieval protocol (see man page)\n"
+msgstr ""
+"  -p, --protocol    belirtilen protokolü kullan (man sayfasýna bakýnýz)\n"
+
+#: options.c:692
+msgid "  -U, --uidl        force the use of UIDLs (pop3 only)\n"
+msgstr ""
+"  -U, --uidl        UIDL kullanýmýný zorunlu kýl (yalnýzca pop3 için)\n"
+
+#: options.c:693
+msgid "  -P, --port        TCP/IP service port to connect to\n"
+msgstr "  -P, --port        baðlanýlacak TCP/IP portu\n"
+
+#: options.c:694
+msgid "      --auth        authentication type (password/kerberos/ssh/otp)\n"
+msgstr "      --auth        kimlik kanýtama türü (parola/kerberos/ssh/otp)\n"
+
+#: options.c:695
+msgid "  -t, --timeout     server nonresponse timeout\n"
+msgstr "  -t, --timeout     sunucu zamanaþýmý süresi\n"
+
+#: options.c:696
+msgid "  -E, --envelope    envelope address header\n"
+msgstr "  -E, --envelope   envelope adresi baþlýðý\n"
+
+#: options.c:697
+msgid "  -Q, --qvirtual    prefix to remove from local user id\n"
+msgstr "  -Q, --qvirtual    yerel kullanýcý kimliðinden silinecek önek\n"
+
+# 'principal' ne demek?
+#: options.c:698
+msgid "      --principal   mail service principal\n"
+msgstr "      --principal   posta hizmeti pricipal'ý\n"
+
+#: options.c:699
+msgid "      --tracepolls  add poll-tracing information to Received header\n"
+msgstr "      --tracepolls  Received baþlýklarýna yoklama bilgisi ekle\n"
+
+#: options.c:701
+msgid "  -u, --username    specify users's login on server\n"
+msgstr "  -u, --username    kullanýcýnýn sunucudaký kullanýcý adý\n"
+
+#: options.c:702
+msgid "  -a, --all         retrieve old and new messages\n"
+msgstr "  -a, --all         eski ve yeni iletileri getir\n"
+
+#: options.c:703
+msgid "  -K, --nokeep      delete new messages after retrieval\n"
+msgstr "  -K, --nokeep      getirdikten sonra yeni iletileri sil\n"
+
+#: options.c:704
+msgid "  -k, --keep        save new messages after retrieval\n"
+msgstr "  -k, --keep       getirdikten sonra yeni iletileri sakla\n"
+
+#: options.c:705
+msgid "  -F, --flush       delete old messages from server\n"
+msgstr "  -F, --flush       eski iletileri sunucudan sil\n"
+
+#: options.c:706
+msgid "  -n, --norewrite   don't rewrite header addresses\n"
+msgstr "  -n, --norewrite   baþlýk adreslerini yeniden yazma\n"
+
+#: options.c:707
+msgid "  -l, --limit       don't fetch messages over given size\n"
+msgstr "  -w, --limit       belirtilenden daha büyük iletileri getirme\n"
+
+#: options.c:708
+msgid "  -w, --warnings    interval between warning mail notification\n"
+msgstr "  -w, --warnings    posta bildirimleri arasýndaki zaman aralýðý\n"
+
+#: options.c:711
+msgid "  -T, --netsec      set IP security request\n"
+msgstr "  -T, --netsec      IP güvenliði iste\n"
+
+#: options.c:713
+msgid "  -S, --smtphost    set SMTP forwarding host\n"
+msgstr "  -S, --smtphost    bu SMTP sunucusunu kullan\n"
+
+#: options.c:714
+msgid "      --fetchdomains fetch mail for specified domains\n"
+msgstr ""
+"      --fetchdomains belirtilen alan adlarý için gelen postalarý getir\n"
+
+#: options.c:715
+msgid "  -D, --smtpaddress set SMTP delivery domain to use\n"
+msgstr "  -D, --smtpaddress kullanýlacak SMTP daðýtým alaný (domain) belirle\n"
+
+#: options.c:716
+msgid "      --smtpname    set SMTP full name username@domain\n"
+msgstr "      --smtpname    bu SMTP kullanýcý@alanadý adresini kullan\n"
+
+#: options.c:717
+msgid "  -Z, --antispam,   set antispam response values\n"
+msgstr "  -Z, --antispam    antispam yanýt deðerlerini kullan\n"
+
+#: options.c:718
+msgid "  -b, --batchlimit  set batch limit for SMTP connections\n"
+msgstr "  -b, --batchlimit  SMTP baðlantýlarý için batch limiti belirle\n"
+
+#: options.c:719
+msgid "  -B, --fetchlimit  set fetch limit for server connections\n"
+msgstr "  -B, --fetchlimit  sunucu baðlantýlarý için getirme sýnýrý\n"
+
+#: options.c:720
+#, fuzzy
+msgid "      --fetchsizelimit set fetch message size limit\n"
+msgstr ""
+"      --fetchdomains belirtilen alan adlarý için gelen postalarý getir\n"
+
+#: options.c:721
+msgid "      --fastuidl    do a binary search for UIDLs\n"
+msgstr ""
+
+#: options.c:722
+msgid "  -e, --expunge     set max deletions between expunges\n"
+msgstr "  -e, --expunge     set max deletions between expunges\n"
+
+#: options.c:723
+msgid "  -m, --mda         set MDA to use for forwarding\n"
+msgstr "  -m, --mda         iletim için kullanýlacak MDA'yý belirle\n"
+
+#: options.c:724
+msgid "      --bsmtp       set output BSMTP file\n"
+msgstr "      --bsmtp       BSMTP çýktýsýný bu dosyaya al\n"
+
+#: options.c:725
+msgid "      --lmtp        use LMTP (RFC2033) for delivery\n"
+msgstr "      --lmtp        daðýtým için LMTP (RFC2033) kullan\n"
+
+#: options.c:726
+msgid "  -r, --folder      specify remote folder name\n"
+msgstr "  -r, --folder    uzaktaki klasör adý olarak bunu kullan\n"
+
+#: options.c:727
+msgid "      --showdots    show progress dots even in logfiles\n"
+msgstr ""
+"      --showdots    ilerlemeyi gösteren noktalarý kayýt dosyalarýnda bile "
+"göster\n"
+
+# timestamp = zaman damgasý (zaman belirteci daha doðal olurdu bence ama böyle kullanýlmýþ
+# baþka yerlerde)
+#: pop3.c:533
+msgid "Required APOP timestamp not found in greeting\n"
+msgstr "Gerekli olan APOP zaman damgasý selamlama içerisinde bulunamadý\n"
+
+#: pop3.c:542
+msgid "Timestamp syntax error in greeting\n"
+msgstr "Selamlama içindeki zaman damgasýnda sözdizim yanlýþý var\n"
+
+#: pop3.c:564
+msgid "Undefined protocol request in POP3_auth\n"
+msgstr "POP3_auth'ta tanýmlanmamýþ protokol isteði\n"
+
+#: pop3.c:572
+msgid "lock busy!  Is another session active?\n"
+msgstr "kilit meþgul!  Baþka bir oturum açýk olabilir\n"
+
+#: pop3.c:649 pop3.c:878
+#, c-format
+msgid "id=%s (num=%d) was deleted, but is still present!\n"
+msgstr ""
+
+#: pop3.c:751
+msgid "Messages inserted into list on server. Cannot handle this.\n"
+msgstr "Sunucuda listeye iletiler araya sokulmuþ. Bu durumu idare edemem.\n"
+
+#: pop3.c:837
+msgid "protocol error\n"
+msgstr "protokol hatasý\n"
+
+#: pop3.c:852
+msgid "protocol error while fetching UIDLs\n"
+msgstr "UIDL'leri getirirken protokol hatasý\n"
+
+#: pop3.c:1210
+msgid "Option --remote is not supported with POP3\n"
+msgstr "--remote seçeneði POP3 ile desteklenmiyor\n"
+
+#: rcfile_y.y:123
+msgid "server option after user options"
+msgstr "kullanýcý seçeneklerinden sonra sunucu seçeneði verilmiþ"
+
+#: rcfile_y.y:170
+msgid "SDPS not enabled."
+msgstr "SDPS etkin deðil."
+
+#: rcfile_y.y:218
+msgid "invalid security request"
+msgstr "geçersiz güvenlik isteði"
+
+#: rcfile_y.y:224
+msgid "network-security support disabled"
+msgstr "að güvenliði desteðini etkisizleþtirildi"
+
+#: rcfile_y.y:231
+msgid ""
+"fetchmail: interface option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: 'interface' seçeneði yalnýzca Linux'ta (IPv6'sýz) ve FreeBSD'de "
+"destekleniyor\n"
+
+#: rcfile_y.y:238
+msgid ""
+"fetchmail: monitor option is only supported under Linux (without IPv6) and "
+"FreeBSD\n"
+msgstr ""
+"fetchmail: 'monitor' seçeneði yalnýzca Linux'ta (IPv6'sýz) ve FreeBSD'de "
+"destekleniyor\n"
+
+#: rcfile_y.y:350
+msgid "SSL is not enabled"
+msgstr "SSL etkin deðil."
+
+#: rcfile_y.y:398
+msgid "end of input"
+msgstr "girdi sonu"
+
+# symbolic link?
+#: rcfile_y.y:435
+#, c-format
+msgid "File %s must be a regular file.\n"
+msgstr "%s dosyasý normal bir dosya olmalý.\n"
+
+#: rcfile_y.y:442
+#, c-format
+msgid "File %s must have no more than -rwx--x--- (0710) permissions.\n"
+msgstr "Dosyanýn (%s) izinleri -rwx--x--- (0710)'den çok olmamalý.\n"
+
+#: rcfile_y.y:454
+#, c-format
+msgid "File %s must be owned by you.\n"
+msgstr "Dosyanin (%s) sahibi siz olmalýsýnýz.\n"
+
+#: report.c:81
+msgid "Unknown system error"
+msgstr "Bilinmeyen sistem hatasý"
+
+#: report.c:108
+#, c-format
+msgid "%s (log message incomplete)"
+msgstr "%s (kayýt iletisi tam deðil)"
+
+#: report.c:266 report.c:294 report.c:366 report.c:394
+msgid "partial error message buffer overflow"
+msgstr "hata ileti tamponu taþmasý"
+
+#: rfc822.c:74
+#, c-format
+msgid "About to rewrite %s"
+msgstr "%s'i yeniden yazmak üzereyim"
+
+#: rfc822.c:210
+#, c-format
+msgid "Rewritten version is %s\n"
+msgstr "Yeniden yazýlan %s\n"
+
+#: rpa.c:116
+msgid "Success"
+msgstr "Baþarýlý"
+
+#: rpa.c:117
+msgid "Restricted user (something wrong with account)"
+msgstr ""
+"Sýnýrlý kullanýcý (kullanýcý hesabý ile ilgili yanlýþ birþeyler olabilir)"
+
+#: rpa.c:118
+msgid "Invalid userid or passphrase"
+msgstr "Kullanýcý adý ya da parolasý geçersiz"
+
+# deity error???
+#: rpa.c:119
+msgid "Deity error"
+msgstr "`Deity' hatasý"
+
+#: rpa.c:172
+msgid "RPA token 2: Base64 decode error\n"
+msgstr "RPA token 2: Base64 kod çözme hatasý\n"
+
+#: rpa.c:183
+#, c-format
+msgid "Service chose RPA version %d.%d\n"
+msgstr "Hizmet RPA sürüm %d.%d'i seçti\n"
+
+#: rpa.c:189
+#, c-format
+msgid "Service challenge (l=%d):\n"
+msgstr "Hizmet challenge'i (l=%d):\n"
+
+#: rpa.c:198
+#, c-format
+msgid "Service timestamp %s\n"
+msgstr "Hizmet zaman damgasý %s\n"
+
+#: rpa.c:203
+msgid "RPA token 2 length error\n"
+msgstr "RPA token 2'de uzunluk hatasý var\n"
+
+# realm = alem
+#: rpa.c:207
+#, c-format
+msgid "Realm list: %s\n"
+msgstr "Alem listesi: %s\n"
+
+#: rpa.c:211
+msgid "RPA error in service@realm string\n"
+msgstr "hizmet@alem katarýnda RPA hatasý\n"
+
+#: rpa.c:248
+msgid "RPA token 4: Base64 decode error\n"
+msgstr "RPA token 4: Base64 kod çözme hatasý\n"
+
+#: rpa.c:259
+#, c-format
+msgid "User authentication (l=%d):\n"
+msgstr "Kullanýcý kimlik kanýtlama (l=%d):\n"
+
+#: rpa.c:273
+#, c-format
+msgid "RPA status: %02X\n"
+msgstr "RPA durumu: %02X\n"
+
+#: rpa.c:279
+msgid "RPA token 4 length error\n"
+msgstr "RPA token 4: uzunluk hatasý\n"
+
+#: rpa.c:286
+#, c-format
+msgid "RPA rejects you: %s\n"
+msgstr "RPA sizi reddediyor: %s\n"
+
+#: rpa.c:288
+msgid "RPA rejects you, reason unknown\n"
+msgstr "RPA sizi reddediyor, nedeni bilinmiyor\n"
+
+#: rpa.c:294
+#, c-format
+msgid "RPA User Authentication length error: %d\n"
+msgstr "RPA Kullanýcý Kimlik Kanýtlama uzunluk hatasý: %d\n"
+
+#: rpa.c:299
+#, c-format
+msgid "RPA Session key length error: %d\n"
+msgstr "RPA Oturumu anahtar uzunluðu hatasý: %d\n"
+
+#: rpa.c:305
+msgid "RPA _service_ auth fail. Spoof server?\n"
+msgstr "RPA _hizmet_ kimlik kanýtlamasý baþarýsýz oldu.\n"
+
+#: rpa.c:310
+msgid "Session key established:\n"
+msgstr "Oturum anahtarý kuruldu:\n"
+
+#: rpa.c:341
+msgid "RPA authorisation complete\n"
+msgstr "RPA yetkilendirme tamamlandý\n"
+
+#: rpa.c:370
+msgid "Get response\n"
+msgstr "Yanýt al\n"
+
+#: rpa.c:400
+#, c-format
+msgid "Get response return %d [%s]\n"
+msgstr "Yanýt alma %d döndü [%s]\n"
+
+#: rpa.c:463
+msgid "Hdr not 60\n"
+msgstr "Baþlýk 60 deðil\n"
+
+#: rpa.c:484
+msgid "Token length error\n"
+msgstr "Token uzunluk hatasý\n"
+
+#: rpa.c:489
+#, c-format
+msgid "Token Length %d disagrees with rxlen %d\n"
+msgstr "Token uzunluðu %d rxlen (%d) ile uyuþmuyor\n"
+
+#: rpa.c:495
+msgid "Mechanism field incorrect\n"
+msgstr "Mekanizma alaný doðru deðil\n"
+
+#: rpa.c:532
+#, c-format
+msgid "dec64 error at char %d: %x\n"
+msgstr "karakter %d'de dec64 hatasý: %x\n"
+
+#: rpa.c:547
+msgid "Inbound binary data:\n"
+msgstr "Gelen ikilik veri:\n"
+
+#: rpa.c:585
+msgid "Outbound data:\n"
+msgstr "Giden veri:\n"
+
+#: rpa.c:651
+msgid "RPA String too long\n"
+msgstr "RPA katarý çok uzun\n"
+
+#: rpa.c:656
+msgid "Unicode:\n"
+msgstr "Unicode:\n"
+
+#: rpa.c:718
+msgid "RPA Failed open of /dev/urandom. This shouldn't\n"
+msgstr "RPA /dev/urandom açýlamadý. Bu durum sisteme\n"
+
+#: rpa.c:719
+msgid "    prevent you logging in, but means you\n"
+msgstr "    girmenize engel deðildir, ancak konuþtuðunuzu\n"
+
+#: rpa.c:720
+msgid "    cannot be sure you are talking to the\n"
+msgstr "    düþündüðünüz sistem ile konuþmuyor\n"
+
+#: rpa.c:721
+msgid "    service that you think you are (replay\n"
+msgstr "    olabilirsiniz (kötü niyetli sistemler\n"
+
+#: rpa.c:722
+msgid "    attacks by a dishonest service are possible.)\n"
+msgstr "    `replay' saldýrýsý yapabilir).\n"
+
+#: rpa.c:733
+msgid "User challenge:\n"
+msgstr "Kullanýcý challenge'ý:\n"
+
+#: rpa.c:891
+msgid "MD5 being applied to data block:\n"
+msgstr "Veri bloðuna MD5 uygulanýyor:\n"
+
+#: rpa.c:904
+msgid "MD5 result is: \n"
+msgstr "MD5 sonucu:\n"
+
+#: sink.c:249
+#, c-format
+msgid "forwarding to %s\n"
+msgstr "%s'e iletiliyor\n"
+
+#: sink.c:351
+msgid "SMTP: (bounce-message body)\n"
+msgstr "SMTP: ('bounce' iletisi gövdesi)\n"
+
+#. this will usually go to sylog...
+#: sink.c:354
+#, c-format
+msgid "mail from %s bounced to %s\n"
+msgstr "%s'den gelen ileti %s'e `bounce' edildi\n"
+
+#: sink.c:464
+#, c-format
+msgid "Saved error is still %d\n"
+msgstr "Kaydedilen hata hala %d\n"
+
+#: sink.c:527 sink.c:607
+#, c-format
+msgid "%cMTP error: %s\n"
+msgstr "%cMTP hatasý: %s\n"
+
+#: sink.c:761
+msgid "BSMTP file open or preamble write failed\n"
+msgstr "BSMTP dosya açýlamadý ya da önsöz yazýlamadý\n"
+
+#: sink.c:982
+#, c-format
+msgid "%cMTP listener doesn't like recipient address `%s'\n"
+msgstr "%cMTP dinleyicisi alýcý adresi olarak `%s'i sevmedi\n"
+
+#: sink.c:989
+#, c-format
+msgid "%cMTP listener doesn't really like recipient address `%s'\n"
+msgstr "%cMTP dinleyicisi alýcý adresi olarak `%s'i sevmedi\n"
+
+#: sink.c:1027
+msgid "no address matches; no postmaster set.\n"
+msgstr "hiçbir adres uyuþmadý; postmaster yok.\n"
+
+#: sink.c:1039
+#, c-format
+msgid "can't even send to %s!\n"
+msgstr ""
+"%s'e bile gönderilemedi!\n"
+"\n"
+
+#: sink.c:1045
+#, c-format
+msgid "no address matches; forwarding to %s.\n"
+msgstr "hiçbir adres uymuyor; %s'e iletiyorum.\n"
+
+#: sink.c:1198
+#, c-format
+msgid "about to deliver with: %s\n"
+msgstr "iletmek üzereyim: %s\n"
+
+#: sink.c:1222
+msgid "MDA open failed\n"
+msgstr "MDA açma baþarýsýz oldu\n"
+
+#: sink.c:1259
+#, c-format
+msgid "%cMTP connect to %s failed\n"
+msgstr "%2$s'e %1$cMTP baðlantýsý baþarýsýz oldu\n"
+
+#: sink.c:1283
+#, c-format
+msgid "can't raise the listener; falling back to %s"
+msgstr "dinleyici çalýþtýrýlamadý; %s denenecek"
+
+#: sink.c:1339
+#, c-format
+msgid "MDA died of signal %d\n"
+msgstr "MDA %d sinyali ile öldürüldü\n"
+
+#: sink.c:1342
+#, c-format
+msgid "MDA returned nonzero status %d\n"
+msgstr "MDA sýfýrdan baþka bir durum kodu döndürdü (%d)\n"
+
+#: sink.c:1345
+#, c-format
+msgid "Strange: MDA pclose returned %d, cannot handle at %s:%d\n"
+msgstr "Garip: MDA pclose durum kodu olarak %d döndürdü, %s:%d'de sorun\n"
+
+#: sink.c:1366
+msgid "Message termination or close of BSMTP file failed\n"
+msgstr ""
+"Ýletiyi bitirme ya da BSMTP dosyasýný kapatma iþlemi baþarýsýzlýkla "
+"sonuçlandý\n"
+
+#: sink.c:1387
+msgid "SMTP listener refused delivery\n"
+msgstr "SMTP dinleyicisi daðýtýmý reddetti\n"
+
+#: sink.c:1417
+msgid "LMTP delivery error on EOM\n"
+msgstr "Ýleti sonunda LMTP daðýtým hatasý\n"
+
+#: sink.c:1420
+#, c-format
+msgid "Unexpected non-503 response to LMTP EOM: %s\n"
+msgstr "LMTP EOM'a beklenmeyen, 503 olmayan yanýt: %s\n"
+
+#: sink.c:1570
+msgid ""
+"--\n"
+"\t\t\t\tThe Fetchmail Daemon\n"
+msgstr ""
+"--\n"
+"\t\t\t\tFetchmail Daemon'u\n"
+
+#: smtp.c:86
+msgid "ESMTP CRAM-MD5 Authentication...\n"
+msgstr "ESMTP CRAM-Md5 Kimlik kanýtlamasý...\n"
+
+#. Server rejects AUTH
+#: smtp.c:93 smtp.c:153
+msgid "Server rejected the AUTH command.\n"
+msgstr "Sunucu AUTH komutunu reddetti.\n"
+
+#: smtp.c:101 smtp.c:160 smtp.c:170 smtp.c:176
+msgid "Bad base64 reply from server.\n"
+msgstr "Sunucudan geçersiz base64 yanýtý.\n"
+
+#: smtp.c:105
+#, c-format
+msgid "Challenge decoded: %s\n"
+msgstr "'Challenge'ýn kodu çözüldü: %s\n"
+
+#: smtp.c:126
+msgid "ESMTP PLAIN Authentication...\n"
+msgstr "ESMTP PLAIN Kimlik kanýtlamasý...\n"
+
+#: smtp.c:146
+msgid "ESMTP LOGIN Authentication...\n"
+msgstr "ESMTP LOGIN Kimlik kanýtlamasý...\n"
+
+#: smtp.c:361 smtp.c:384
+msgid "smtp listener protocol error\n"
+msgstr "smtp dinleyicisi protokol hatasý\n"
+
+#: socket.c:108 socket.c:134
+msgid "fetchmail: malloc failed\n"
+msgstr "fetchmail: malloc baþarýsýz oldu\n"
+
+#: socket.c:166
+msgid "fetchmail: socketpair failed\n"
+msgstr "fetchmail: socketpair baþarýsýz oldu\n"
+
+#. error
+#: socket.c:172
+msgid "fetchmail: fork failed\n"
+msgstr "fetchmail: fork baþarýsýz oldu\n"
+
+#: socket.c:180
+msgid "dup2 failed\n"
+msgstr "dup2 baþarýsýz oldu\n"
+
+#: socket.c:186
+#, c-format
+msgid "running %s (host %s service %s)\n"
+msgstr "%s çalýþtýrýlýyor (makina %s hizmet %s)\n"
+
+#: socket.c:189
+#, c-format
+msgid "execvp(%s) failed\n"
+msgstr "execvp(%s) baþarýsýz oldu\n"
+
+#: socket.c:281
+#, c-format
+msgid "fetchmail: getaddrinfo(%s.%s)\n"
+msgstr "fetchmail: getaddrinfo(%s.%s)\n"
+
+#: socket.c:428
+#, c-format
+msgid "fetchmail: illegal address length received for host %s\n"
+msgstr "fetchmail: %s makinesi için geçersiz adres uzunluðu alýndý\n"
+
+#: socket.c:778
+#, c-format
+msgid "Issuer Organization: %s\n"
+msgstr "Çýkaran Kurum: %s\n"
+
+#: socket.c:780
+msgid "Warning: Issuer Organization Name too long (possibly truncated).\n"
+msgstr "Uyarý: Çýkaran Kurum Adý çok uzun (sonundan kesilmiþ olabilir).\n"
+
+#: socket.c:782
+msgid "Unknown Organization\n"
+msgstr "Bilinmeyen Kurum\n"
+
+#: socket.c:784
+#, c-format
+msgid "Issuer CommonName: %s\n"
+msgstr "Çýkaran `CommonName'i: %s\n"
+
+#: socket.c:786
+msgid "Warning: Issuer CommonName too long (possibly truncated).\n"
+msgstr "Uyarý: Çýkaran `CommonName'i çok uzun (sonundan kesilmiþ olabilir).\n"
+
+#: socket.c:788
+msgid "Unknown Issuer CommonName\n"
+msgstr "Bilinmeyen Çýkaran `CommonName'i\n"
+
+#: socket.c:792
+#, c-format
+msgid "Server CommonName: %s\n"
+msgstr "Sunucu `CommonName'i: %s\n"
+
+#. Possible truncation. In this case, this is a DNS name, so this
+#. * is really bad. We do not tolerate this even in the non-strict case.
+#: socket.c:796
+msgid "Bad certificate: Subject CommonName too long!\n"
+msgstr "Kötü sertifika: `Subject CommonName' çok uzun!\n"
+
+#: socket.c:812
+#, c-format
+msgid "Server CommonName mismatch: %s != %s\n"
+msgstr "Sunucu CommonName'i uyuþmazlýðý: %s != %s\n"
+
+#: socket.c:818
+msgid "Server name not set, could not verify certificate!\n"
+msgstr "Sunucu adý ayarlanmamýþ, sertifikayý doðrulayamýyorum!\n"
+
+#: socket.c:823
+msgid "Unknown Server CommonName\n"
+msgstr "Bilinmeyen Sunucu `CommonName'i\n"
+
+#: socket.c:825
+msgid "Server name not specified in certificate!\n"
+msgstr "Sunucu adý sertifikada belirtilmemiþ!\n"
+
+#: socket.c:835
+msgid "EVP_md5() failed!\n"
+msgstr "EVP_md5() baþarýsýz oldu!\n"
+
+#: socket.c:839
+msgid "Out of memory!\n"
+msgstr "Bellek yetmedi!\n"
+
+#: socket.c:851
+msgid "Digest text buffer too small!\n"
+msgstr "`Digest' metni tamponu çok küçük!\n"
+
+#: socket.c:857
+#, c-format
+msgid "%s key fingerprint: %s\n"
+msgstr "%s anahtarý parmak izi: %s\n"
+
+#: socket.c:861
+#, c-format
+msgid "%s fingerprints match.\n"
+msgstr "%s parmak izleri uyuþuyor.\n"
+
+#: socket.c:864
+#, c-format
+msgid "%s fingerprints do not match!\n"
+msgstr "%s parmak izleri uyuþmuyor!\n"
+
+#: socket.c:872
+#, c-format
+msgid "Warning: server certificate verification: %s\n"
+msgstr "Uyarý: sunucu sertifikasý doðrulamasý: %s\n"
+
+#: socket.c:878
+#, c-format
+msgid "unknown issuer (first %d characters): %s\n"
+msgstr "bilinmeyen çýkaran firma adý (ilk %d karakter): %s\n"
+
+#: socket.c:931
+msgid "File descriptor out of range for SSL"
+msgstr "Dosya belirteci SSL için sýnýrlar dýþýnda"
+
+#: socket.c:948
+#, c-format
+msgid "Invalid SSL protocol '%s' specified, using default (SSLv23).\n"
+msgstr ""
+"Geçersiz SSL protokolü '%s' belirtildi, öntanýmlý olan kullanýlýyor "
+"(SSLv23).\n"
+
+#: socket.c:1008
+msgid "Certificate/fingerprint verification was somehow skipped!\n"
+msgstr "Sertifika/parmak izi doðrulamasý bir biçimde atlandý!\n"
+
+#: socket.c:1080
+msgid "Cygwin socket read retry\n"
+msgstr "Cygwin soketinden okuma yeniden deneniyor\n"
+
+#: socket.c:1083
+msgid "Cygwin socket read retry failed!\n"
+msgstr "Cygwin soketinden okuma baþarýsýz oldu!\n"
+
+#: transact.c:70
+#, c-format
+msgid "mapped %s to local %s\n"
+msgstr "%s yerel %s'e eþlendi\n"
+
+# kaynak koduna bakýlacak
+#: transact.c:134
+#, c-format
+msgid "passed through %s matching %s\n"
+msgstr "%2$s ile uyuþan %1$s geçirildi\n"
+
+#: transact.c:203
+#, c-format
+msgid ""
+"analyzing Received line:\n"
+"%s"
+msgstr ""
+"'Received' satýrý çözümleniyor:\n"
+"%s"
+
+#: transact.c:242
+#, c-format
+msgid "line accepted, %s is an alias of the mailserver\n"
+msgstr "satýr kabul edildi, %s posta sunucusu için bir takma ad\n"
+
+#: transact.c:248
+#, c-format
+msgid "line rejected, %s is not an alias of the mailserver\n"
+msgstr "satýr kabul edilmedi, %s posta sunucusu için bir takma ad deðil\n"
+
+#: transact.c:322
+msgid "no Received address found\n"
+msgstr "hiçbir Received adresi bulunamadý\n"
+
+#: transact.c:331
+#, c-format
+msgid "found Received address `%s'\n"
+msgstr "`%s' Received adresi bulundu\n"
+
+# delimiter = sýnýr belirteci  (Sankur'un sözlüðünden)
+#: transact.c:531
+msgid "message delimiter found while scanning headers\n"
+msgstr "baþlýklar taranýrken ileti sýnýr belirteci bulundu\n"
+
+# delimiter = sýnýr belirteci  (Sankur'un sözlüðünden)
+#: transact.c:552
+msgid "incorrect header line found while scanning headers\n"
+msgstr "baþlýklar taranýrken geçersiz baþlýk satýrý bulundu\n"
+
+#: transact.c:554
+#, c-format
+msgid "line: %s"
+msgstr "satýr: %s"
+
+#: transact.c:1074
+#, c-format
+msgid "no local matches, forwarding to %s\n"
+msgstr "yerelde uyan bulunamadý, %s'e iletiliyor\n"
+
+#: transact.c:1089
+msgid "forwarding and deletion suppressed due to DNS errors\n"
+msgstr "iletme ve silme DNS hatalarý nedeniyle yapýlmýyor\n"
+
+#: transact.c:1225
+msgid "writing RFC822 msgblk.headers\n"
+msgstr "RFC822 msgblk.headers yazýlýyor\n"
+
+#: transact.c:1246
+msgid "no recipient addresses matched declared local names"
+msgstr ""
+"alýcý adreslerinden hiçbiri bildirilen yerel adlardan hiçbirine uymuyor"
+
+#: transact.c:1257
+#, c-format
+msgid "recipient address %s didn't match any local name"
+msgstr "alýcý adresi %s yerel adlardan hiçbirine uymuyor"
+
+#: transact.c:1271
+msgid "message has embedded NULs"
+msgstr "iletinin içinde NUL karakterleri var"
+
+# listener = dinleyici
+#: transact.c:1284
+msgid "SMTP listener rejected local recipient addresses: "
+msgstr "SMTP dinleyicisi yerel alýcý adreslerini reddetti: "
+
+#: transact.c:1409
+msgid "writing message text\n"
+msgstr "ileti metni yazýlýyor\n"
+
+#: uid.c:137
+#, c-format
+msgid "lstat: %s: %s\n"
+msgstr "lstat: %s: %s\n"
+
+#: uid.c:248
+#, c-format
+msgid "Old UID list from %s:"
+msgstr "%s'den eski UID listesi:"
+
+# kaynak koduna bakýlacak
+#: uid.c:253 uid.c:264 uid.c:518 uid.c:567
+msgid " <empty>"
+msgstr " <boþ>"
+
+#: uid.c:260
+msgid "Scratch list of UIDs:"
+msgstr "Müsvedde UID listesi:"
+
+#. this is now a merged list! the mails which were seen in this
+#. * poll are marked here.
+#: uid.c:512 uid.c:563
+#, fuzzy, c-format
+msgid "Merged UID list from %s:"
+msgstr "%s'den eski UID listesi:"
+
+#: uid.c:514
+#, c-format
+msgid "New UID list from %s:"
+msgstr "%s'den yeni UID listesi:"
+
+#: uid.c:542
+msgid "swapping UID lists\n"
+msgstr "UID listeleri takas ediliyor\n"
+
+#: uid.c:550
+msgid "not swapping UID lists, no UIDs seen this query\n"
+msgstr "UID listeleri takas edilmiyor, hiçbir UID bu sorguyu görmedi\n"
+
+#: uid.c:575
+#, fuzzy
+msgid "discarding new UID list\n"
+msgstr "UID listeleri takas ediliyor\n"
+
+#: uid.c:610
+msgid "Deleting fetchids file.\n"
+msgstr "fetchids dosyasý siliniyor.\n"
+
+#: uid.c:616
+msgid "Writing fetchids file.\n"
+msgstr "fetchids dosyasý yazýlýyor.\n"
+
+#: xmalloc.c:33
+msgid "malloc failed\n"
+msgstr "malloc baþarýsýz oldu\n"
+
+#: xmalloc.c:47
+msgid "realloc failed\n"
+msgstr "realloc baþarýsýz oldu\n"
+
+#~ msgid "Skipping message %d, length -1\n"
+#~ msgstr "Ýleti %d atlanýyor, uzunluk -1\n"
+
+#, fuzzy
+#~ msgid "unknown issuer= %s"
+#~ msgstr "bilinmeyen"
+
+#~ msgid "Server Certificate expired"
+#~ msgstr "Sunucu Seritifikasý'nýn kullaným süresi doldu"
diff --git a/progtest.m4 b/progtest.m4
new file mode 100644
index 00000000..2482d4a9
--- /dev/null
+++ b/progtest.m4
@@ -0,0 +1,47 @@
+# Search path for a program which passes the given test.
+# Ulrich Drepper <drepper@cygnus.com>, 1996.
+#
+# This file can be copied and used freely without restrictions.  It can
+# be used in projects which are not available under the GNU Public License
+# but which still want to provide support for the GNU gettext functionality.
+# Please note that the actual code is *not* freely available.
+
+# serial 1
+
+dnl AM_PATH_PROG_WITH_TEST(VARIABLE, PROG-TO-CHECK-FOR,
+dnl   TEST-PERFORMED-ON-FOUND_PROGRAM [, VALUE-IF-NOT-FOUND [, PATH]])
+AC_DEFUN(AM_PATH_PROG_WITH_TEST,
+[# Extract the first word of "$2", so it can be a program name with args.
+set dummy $2; ac_word=[$]2
+AC_MSG_CHECKING([for $ac_word])
+AC_CACHE_VAL(ac_cv_path_$1,
+[case "[$]$1" in
+  /*)
+  ac_cv_path_$1="[$]$1" # Let the user override the test with a path.
+  ;;
+  *)
+  IFS="${IFS= 	}"; ac_save_ifs="$IFS"; IFS="${IFS}:"
+  for ac_dir in ifelse([$5], , $PATH, [$5]); do
+    test -z "$ac_dir" && ac_dir=.
+    if test -f $ac_dir/$ac_word; then
+      if [$3]; then
+	ac_cv_path_$1="$ac_dir/$ac_word"
+	break
+      fi
+    fi
+  done
+  IFS="$ac_save_ifs"
+dnl If no 4th arg is given, leave the cache variable unset,
+dnl so AC_PATH_PROGS will keep looking.
+ifelse([$4], , , [  test -z "[$]ac_cv_path_$1" && ac_cv_path_$1="$4"
+])dnl
+  ;;
+esac])dnl
+$1="$ac_cv_path_$1"
+if test -n "[$]$1"; then
+  AC_MSG_RESULT([$]$1)
+else
+  AC_MSG_RESULT(no)
+fi
+AC_SUBST($1)dnl
+])
diff --git a/rh-config/fetchmailconf.init b/rh-config/fetchmailconf.init
new file mode 100644
index 00000000..42d9aa6e
--- /dev/null
+++ b/rh-config/fetchmailconf.init
@@ -0,0 +1,5 @@
+fetchmailconf
+fetchmailconf.xpm
+Fetchmail configuration
+This is a program that allows
+you to configure fetchmail easily.
\ No newline at end of file
diff --git a/rh-config/fetchmailconf.wmconfig b/rh-config/fetchmailconf.wmconfig
new file mode 100644
index 00000000..c69061d9
--- /dev/null
+++ b/rh-config/fetchmailconf.wmconfig
@@ -0,0 +1,4 @@
+fetchmailconf name "Fetchmail Configuration"
+fetchmailconf description "A graphical configuration tool for Fetchmail"
+fetchmailconf exec "fetchmailconf &"
+fetchmailconf group Administration
diff --git a/rh-config/fetchmailconf.xpm b/rh-config/fetchmailconf.xpm
new file mode 100644
index 00000000..0f6c2ce5
--- /dev/null
+++ b/rh-config/fetchmailconf.xpm
@@ -0,0 +1,163 @@
+/* XPM */
+static char *magick[] = {
+/* columns rows colors chars-per-pixel */
+"64 64 93 2",
+"   c Gray0",
+".  c #020202",
+"X  c Gray2",
+"o  c Gray4",
+"O  c Gray9",
+"+  c #272727",
+"@  c Gray22",
+"#  c #393939",
+"$  c Gray23",
+"%  c #414141",
+"&  c Gray26",
+"*  c #444444",
+"=  c Gray28",
+"-  c #4c4c4c",
+";  c Gray30",
+":  c #4e4e4e",
+">  c Gray32",
+",  c #565656",
+"<  c #5a5a5a",
+"1  c Gray37",
+"2  c #5f5f5f",
+"3  c Gray38",
+"4  c #626262",
+"5  c #676767",
+"6  c #686868",
+"7  c #6a6a6a",
+"8  c Gray42",
+"9  c #6c6c6c",
+"0  c Gray43",
+"q  c #767676",
+"w  c #777777",
+"e  c Gray47",
+"r  c #7b7b7b",
+"t  c Gray50",
+"y  c #808080",
+"u  c #818181",
+"i  c #838383",
+"p  c #848484",
+"a  c Gray52",
+"s  c Gray53",
+"d  c Gray54",
+"f  c #8b8b8b",
+"g  c Gray55",
+"h  c #8e8e8e",
+"j  c Gray57",
+"k  c #929292",
+"l  c #959595",
+"z  c Gray59",
+"x  c #979797",
+"c  c #989898",
+"v  c Gray60",
+"b  c #9b9b9b",
+"n  c Gray61",
+"m  c #9f9f9f",
+"M  c Gray64",
+"N  c #a5a5a5",
+"B  c #a7a7a7",
+"V  c Gray66",
+"C  c #a9a9a9",
+"Z  c #acacac",
+"A  c #aeaeae",
+"S  c #afafaf",
+"D  c Gray69",
+"F  c #b1b1b1",
+"G  c #b2b2b2",
+"H  c Gray70",
+"J  c #b4b4b4",
+"K  c #b7b7b7",
+"L  c Gray72",
+"P  c #bbbbbb",
+"I  c #c0c0c0",
+"U  c #c1c1c1",
+"Y  c #c3c3c3",
+"T  c Gray77",
+"R  c #c8c8c8",
+"E  c Gray80",
+"W  c Gray82",
+"Q  c #d3d3d3",
+"!  c Gray83",
+"~  c #d8d8d8",
+"^  c #dadada",
+"/  c Gray86",
+"(  c #dddddd",
+")  c Gray88",
+"_  c #e4e4e4",
+"`  c Gray90",
+"'  c Gray91",
+"]  c Gray93",
+"[  c #f1f1f1",
+"{  c Gray97",
+"}  c Gray98",
+"|  c #fdfdfd",
+" . c Gray100",
+/* pixels */
+"} } } } } } } } } } } } } } } } } } } } } } } } } } ' } ' ' ' ' ' ' ' ' ~ ~ ~ ~ ~ ~ ~ R ~ R R R R R L R L L L L L V L V V V V c ",
+"} } } } } } } } } } } } } } } } } } } } } } } ' } ' } ' } ' ' ' ' ' ~ ' ' ~ ~ ~ ~ R ~ R R R R R R L R L L L L V L V V V V V c c ",
+"} } } } } } } } } } } } } } } } } } } } } } } } } ' } ' ' ' ' ' ' ' ~ ~ ~ ~ ~ ~ ~ R ~ R ~ R R R L R L L L L L L V L V V c c V c ",
+"} } } } } } } } } } } } } } } } } } } } } } ' ' } ' ' } ' ' ' ' ~ ~ ' ~ ~ ~ ~ ~ R ~ R R R R R L R L L L L L L V V V V c V c c c ",
+"} } } } } } } } } } } } } } } } } } } } ' } } ' } ' ' ' ' ' ' ' ' ~ ~ ~ ~ ~ R ~ R R R R R L R L L L L L L V V L V V V c c c c s ",
+"} } } } } } } } } } } } } } } } } } } } } ' } ' } ' ' ' ' ' ~ ~ ~ ~ ~ ~ ~ ~ ~ R ~ R R R R R L R L L L L V L V V c V c c c c s c ",
+"} } } } } }  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .b c c c c s s ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   c c c s s s ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   c s s c s s ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   s c s s s w ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   c s s s s w ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   s s s w w w ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   s s w s w w ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   w s w w w w ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   s w w w w 5 ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   w w w w w 5 ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   s w w 5 5 5 ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   w 5 w 5 5 5 ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   w 5 5 5 5 5 ",
+"} } } } } }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   5 w 5 5 5 , ",
+"} } } } ' }  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   5 5 5 , 5 , ",
+"} } } } } '  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   5 5 5 5 , , ",
+"} } ' } } '  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   5 , , , , , ",
+"} } } ' } '  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   5 5 5 , , , ",
+"} ' } ' } '  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   , , , , = , ",
+"' } } ' ' }  .b b b b b b b b b b b b b b b b b b b b b b b b b p y p p r p p y p p r p p y p p r p p b b b b b b   , , , , = = ",
+"} ' ' } ' '  .b b b b b b b b b b b b b b b b b b b b b b b i t 3 { [ } { } { } { [ { } { [ } { [ { y b b b b b b   , , = , = = ",
+"' } ' ' ' '  .b b b b b b b b b b b b b b b b b b b b b i * 2 0 8 J | { } { } { } | | [ | | { | | { r b b b b b b   , , = = = = ",
+"' } ' ' ' '  .b b b b b b b b . . . . . p r b b b b 1 % 4 A A 7 & G ( } } } | } { } | | { } | } ! M p b b b b b b   = , = = = @ ",
+"' ' ' ' ' '  .b b b b b b b b . . . . . } [ 6 d : 2 e m A K F Q m # l J ^ } { } } } { } | } ` k N } r b b b b b b   = = = = = @ ",
+"' ' ' ' ' '  .b b b b b b b b . . . . . { } , 4 b m f F K S F F / Q s : < I U | } { } | ' n n } } { p b b b b b b   = = = @ @ @ ",
+"' ' ' ~ ' ~  .b b b b b b b b . . . . . } { q C v l k f F K K B 9 u / H z D W g U | _ n g } } { | } y b b b b b b   = = @ = @ @ ",
+"' ' ' ' ~ '  .b b b b b b b b . . . . . } } q z x x k v d e 1 2 $ , - - > i ) } ! p Z { } Z | } | [ p b b b b b b   = = @ @ @ @ ",
+"' ' ' ~ ~ ~  .b b b b b b b b . . . . . } { 8 m h j z x m h p s y } E ) G T } { } } } } { _ v [ | | p b b b b b b   @ @ @ @ @ + ",
+"' ~ ~ ' ~ ~  .b b b b b b b b . . . . . [ } 8 m m b h n k j x C r | | } P | [ | } } { | } | ] M | [ p b b b b b b   @ = @ + @ + ",
+"~ ' ~ ~ ~ ~  .b b b b b b b b . . . . . { | q s 2 2 a z z z e 2 i } _ n } { | | } { } } { } { _ M } i b b b b b b   @ @ @ @ + + ",
+"~ ' ~ ~ ~ ~  .b b b b b b b b . . . . . | } & 1 s s , , , ; 8 s r } Y } | } } { } | } } } | } } } ! y b b b b b b   @ @ + + @ + ",
+"~ ~ ~ ~ ~ ~  .b b b b b b b b . . . . . } { 0 b b b b b b b b b i y r i y p y p y p r p p y i r p p r b b b b b b   + @ + + + + ",
+"~ ~ ~ R ~ R  .b b b b b b b b . . . . . i r b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   + @ + + + O ",
+"~ ~ ~ ~ R R  .b b b b b b b b . . o . . b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   + + + + O + ",
+"~ R R ~ R ~  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   + + + + O O ",
+"~ ~ R R R R  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   + + O O O O ",
+"R ~ R R R R  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   + + O + O O ",
+"~ R R R R R  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   + O O O O O ",
+"R R R R L R  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   O O O O X O ",
+"R R R R R L  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   O O O O X X ",
+"R R R L L R  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   O O X O X X ",
+"R R L R L L  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   O O X O X X ",
+"R L L L L L  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   X O X X X X ",
+"R L R L L L  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   O X X X X X ",
+"L L L L L V  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   O X X X X X ",
+"R L L L L L  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   X X X X X X ",
+"L L L V V V  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   X X X X X X ",
+"L L L L L V  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   X X X X X X ",
+"L V V V V V  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   X X X X X X ",
+"L L V L V V  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   X X X X X X ",
+"V L V V V V  .b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b b   X X X X X X ",
+"V V V V c V b                                                                                                       X X X X X X ",
+"V V V V c c c c c s s s s w s w w 5 w 5 5 5 5 5 , , , , = , = = @ = @ @ @ @ + + + + + + O O O O X X X X X X X X X X X X X X X X ",
+"V V c V c c c s c s s s s w w w w w 5 5 5 5 5 , , , , , = = = = = @ @ @ @ + @ + + + O + O O O O O X O X X X X X X X X X X X X X ",
+"V V c c c c c s s s s w s w w w 5 5 5 5 5 , , , , , = , = = = @ @ @ @ @ + + + + + + O O O O X X O X X X X X X X X X X X X X X X ",
+"c V c c c s c s s s s w w w w 5 w 5 5 5 5 , 5 , , , = = = = @ = @ @ @ + @ + + + + O O O O O O X X X X X X X X X X X X X X X X X ",
+"c c c c c s s s s w s w w 5 w 5 5 5 5 , , , , , = , = = = @ @ @ @ + @ + + + + O O O O O X X O X X X X X X X X X X X X X X X X X ",
+"c c c s c s s s s w w w w w 5 5 5 , 5 5 , , , , = = = = @ = @ @ @ @ + + + O + + O O O O O X X X X X X X X X X X X X X X X X X X "
+};
diff --git a/smb.h b/smb.h
new file mode 100644
index 00000000..eb5e382e
--- /dev/null
+++ b/smb.h
@@ -0,0 +1,52 @@
+typedef unsigned short uint16;
+typedef unsigned       uint32;
+typedef unsigned char  uint8;
+
+typedef struct
+{
+uint16  len;
+uint16  maxlen;
+uint32  offset;
+}tSmbStrHeader;
+
+typedef struct
+{
+char          ident[8];
+uint32        msgType;
+uint32        flags;
+tSmbStrHeader    user;
+tSmbStrHeader    domain;
+uint8         buffer[1024];
+uint32        bufIndex;
+}tSmbNtlmAuthRequest;
+
+typedef struct
+{
+char          ident[8];
+uint32        msgType;
+tSmbStrHeader    uDomain;
+uint32        flags;
+uint8         challengeData[8];
+uint8         reserved[8];
+tSmbStrHeader    emptyString;
+uint8         buffer[1024];
+uint32        bufIndex;
+}tSmbNtlmAuthChallenge;
+
+
+typedef struct
+{
+char          ident[8];
+uint32        msgType;
+tSmbStrHeader    lmResponse;
+tSmbStrHeader    ntResponse;
+tSmbStrHeader    uDomain;
+tSmbStrHeader    uUser;
+tSmbStrHeader    uWks;
+tSmbStrHeader    sessionKey;
+uint32        flags;
+uint8         buffer[1024];
+uint32        bufIndex;
+}tSmbNtlmAuthResponse;
+
+#define SmbLength(ptr) (((ptr)->buffer - (uint8*)(ptr)) + (ptr)->bufIndex)
diff --git a/smbbyteorder.h b/smbbyteorder.h
new file mode 100644
index 00000000..59ae4979
--- /dev/null
+++ b/smbbyteorder.h
@@ -0,0 +1,265 @@
+/* 
+   Unix SMB/Netbios implementation.
+   Version 1.9.
+   SMB Byte handling
+   Copyright (C) Andrew Tridgell 1992-1998
+   
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+   
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#ifndef _BYTEORDER_H
+#define _BYTEORDER_H
+
+/*
+   This file implements macros for machine independent short and 
+   int manipulation
+
+Here is a description of this file that I emailed to the samba list once:
+
+> I am confused about the way that byteorder.h works in Samba. I have
+> looked at it, and I would have thought that you might make a distinction
+> between LE and BE machines, but you only seem to distinguish between 386
+> and all other architectures.
+> 
+> Can you give me a clue?
+
+sure.
+
+The distinction between 386 and other architectures is only there as
+an optimisation. You can take it out completely and it will make no
+difference. The routines (macros) in byteorder.h are totally byteorder
+independent. The 386 optimsation just takes advantage of the fact that
+the x86 processors don't care about alignment, so we don't have to
+align ints on int boundaries etc. If there are other processors out
+there that aren't alignment sensitive then you could also define
+CAREFUL_ALIGNMENT=0 on those processors as well.
+
+Ok, now to the macros themselves. I'll take a simple example, say we
+want to extract a 2 byte integer from a SMB packet and put it into a
+type called uint16 that is in the local machines byte order, and you
+want to do it with only the assumption that uint16 is _at_least_ 16
+bits long (this last condition is very important for architectures
+that don't have any int types that are 2 bytes long)
+
+You do this:
+
+#define CVAL(buf,pos) (((unsigned char *)(buf))[pos])
+#define PVAL(buf,pos) ((unsigned)CVAL(buf,pos))
+#define SVAL(buf,pos) (PVAL(buf,pos)|PVAL(buf,(pos)+1)<<8)
+
+then to extract a uint16 value at offset 25 in a buffer you do this:
+
+char *buffer = foo_bar();
+uint16 xx = SVAL(buffer,25);
+
+We are using the byteoder independence of the ANSI C bitshifts to do
+the work. A good optimising compiler should turn this into efficient
+code, especially if it happens to have the right byteorder :-)
+
+I know these macros can be made a bit tidier by removing some of the
+casts, but you need to look at byteorder.h as a whole to see the
+reasoning behind them. byteorder.h defines the following macros:
+
+SVAL(buf,pos) - extract a 2 byte SMB value
+IVAL(buf,pos) - extract a 4 byte SMB value
+SVALS(buf,pos) signed version of SVAL()
+IVALS(buf,pos) signed version of IVAL()
+
+SSVAL(buf,pos,val) - put a 2 byte SMB value into a buffer
+SIVAL(buf,pos,val) - put a 4 byte SMB value into a buffer
+SSVALS(buf,pos,val) - signed version of SSVAL()
+SIVALS(buf,pos,val) - signed version of SIVAL()
+
+RSVAL(buf,pos) - like SVAL() but for NMB byte ordering
+RSVALS(buf,pos) - like SVALS() but for NMB byte ordering
+RIVAL(buf,pos) - like IVAL() but for NMB byte ordering
+RIVALS(buf,pos) - like IVALS() but for NMB byte ordering
+RSSVAL(buf,pos,val) - like SSVAL() but for NMB ordering
+RSIVAL(buf,pos,val) - like SIVAL() but for NMB ordering
+RSIVALS(buf,pos,val) - like SIVALS() but for NMB ordering
+
+it also defines lots of intermediate macros, just ignore those :-)
+
+*/
+
+/* some switch macros that do both store and read to and from SMB buffers */
+
+#define RW_PCVAL(read,inbuf,outbuf,len) \
+	{ if (read) { PCVAL (inbuf,0,outbuf,len); } \
+	else      { PSCVAL(inbuf,0,outbuf,len); } }
+
+#define RW_PIVAL(read,big_endian,inbuf,outbuf,len) \
+	{ if (read) { if (big_endian) { RPIVAL(inbuf,0,outbuf,len); } else { PIVAL(inbuf,0,outbuf,len); } } \
+	else      { if (big_endian) { RPSIVAL(inbuf,0,outbuf,len); } else { PSIVAL(inbuf,0,outbuf,len); } } }
+
+#define RW_PSVAL(read,big_endian,inbuf,outbuf,len) \
+	{ if (read) { if (big_endian) { RPSVAL(inbuf,0,outbuf,len); } else { PSVAL(inbuf,0,outbuf,len); } } \
+	else      { if (big_endian) { RPSSVAL(inbuf,0,outbuf,len); } else { PSSVAL(inbuf,0,outbuf,len); } } }
+
+#define RW_CVAL(read, inbuf, outbuf, offset) \
+	{ if (read) { (outbuf) = CVAL (inbuf,offset); } \
+	else      { SCVAL(inbuf,offset,outbuf); } }
+
+#define RW_IVAL(read, big_endian, inbuf, outbuf, offset) \
+	{ if (read) { (outbuf) = ((big_endian) ? RIVAL(inbuf,offset) : IVAL (inbuf,offset)); } \
+	else      { if (big_endian) { RSIVAL(inbuf,offset,outbuf); } else { SIVAL(inbuf,offset,outbuf); } } }
+
+#define RW_SVAL(read, big_endian, inbuf, outbuf, offset) \
+	{ if (read) { (outbuf) = ((big_endian) ? RSVAL(inbuf,offset) : SVAL (inbuf,offset)); } \
+	else      { if (big_endian) { RSSVAL(inbuf,offset,outbuf); } else { SSVAL(inbuf,offset,outbuf); } } }
+
+#undef CAREFUL_ALIGNMENT
+
+/* we know that the 386 can handle misalignment and has the "right" 
+   byteorder */
+#ifdef __i386__
+#define CAREFUL_ALIGNMENT 0
+#endif
+
+#ifndef CAREFUL_ALIGNMENT
+#define CAREFUL_ALIGNMENT 1
+#endif
+
+#define CVAL(buf,pos) (((unsigned char *)(buf))[pos])
+#define PVAL(buf,pos) ((unsigned)CVAL(buf,pos))
+#define SCVAL(buf,pos,val) (CVAL(buf,pos) = (val))
+
+
+#if CAREFUL_ALIGNMENT
+
+#define SVAL(buf,pos) (PVAL(buf,pos)|PVAL(buf,(pos)+1)<<8)
+#define IVAL(buf,pos) (SVAL(buf,pos)|SVAL(buf,(pos)+2)<<16)
+#define SSVALX(buf,pos,val) (CVAL(buf,pos)=(val)&0xFF,CVAL(buf,pos+1)=(val)>>8)
+#define SIVALX(buf,pos,val) (SSVALX(buf,pos,val&0xFFFF),SSVALX(buf,pos+2,val>>16))
+#define SVALS(buf,pos) ((int16)SVAL(buf,pos))
+#define IVALS(buf,pos) ((int32)IVAL(buf,pos))
+#define SSVAL(buf,pos,val) SSVALX((buf),(pos),((uint16)(val)))
+#define SIVAL(buf,pos,val) SIVALX((buf),(pos),((uint32)(val)))
+#define SSVALS(buf,pos,val) SSVALX((buf),(pos),((int16)(val)))
+#define SIVALS(buf,pos,val) SIVALX((buf),(pos),((int32)(val)))
+
+#else /* CAREFUL_ALIGNMENT */
+
+/* this handles things for architectures like the 386 that can handle
+   alignment errors */
+/*
+   WARNING: This section is dependent on the length of int16 and int32
+   being correct 
+*/
+
+/* get single value from an SMB buffer */
+#define SVAL(buf,pos) (*(uint16 *)((char *)(buf) + (pos)))
+#define IVAL(buf,pos) (*(uint32 *)((char *)(buf) + (pos)))
+#define SVALS(buf,pos) (*(int16 *)((char *)(buf) + (pos)))
+#define IVALS(buf,pos) (*(int32 *)((char *)(buf) + (pos)))
+
+/* store single value in an SMB buffer */
+#define SSVAL(buf,pos,val) SVAL(buf,pos)=((uint16)(val))
+#define SIVAL(buf,pos,val) IVAL(buf,pos)=((uint32)(val))
+#define SSVALS(buf,pos,val) SVALS(buf,pos)=((int16)(val))
+#define SIVALS(buf,pos,val) IVALS(buf,pos)=((int32)(val))
+
+#endif /* CAREFUL_ALIGNMENT */
+
+/* macros for reading / writing arrays */
+
+#define SMBMACRO(macro,buf,pos,val,len,size) \
+{ int l; for (l = 0; l < (len); l++) (val)[l] = macro((buf), (pos) + (size)*l); }
+
+#define SSMBMACRO(macro,buf,pos,val,len,size) \
+{ int l; for (l = 0; l < (len); l++) macro((buf), (pos) + (size)*l, (val)[l]); }
+
+/* reads multiple data from an SMB buffer */
+#define PCVAL(buf,pos,val,len) SMBMACRO(CVAL,buf,pos,val,len,1)
+#define PSVAL(buf,pos,val,len) SMBMACRO(SVAL,buf,pos,val,len,2)
+#define PIVAL(buf,pos,val,len) SMBMACRO(IVAL,buf,pos,val,len,4)
+#define PCVALS(buf,pos,val,len) SMBMACRO(CVALS,buf,pos,val,len,1)
+#define PSVALS(buf,pos,val,len) SMBMACRO(SVALS,buf,pos,val,len,2)
+#define PIVALS(buf,pos,val,len) SMBMACRO(IVALS,buf,pos,val,len,4)
+
+/* stores multiple data in an SMB buffer */
+#define PSCVAL(buf,pos,val,len) SSMBMACRO(SCVAL,buf,pos,val,len,1)
+#define PSSVAL(buf,pos,val,len) SSMBMACRO(SSVAL,buf,pos,val,len,2)
+#define PSIVAL(buf,pos,val,len) SSMBMACRO(SIVAL,buf,pos,val,len,4)
+#define PSCVALS(buf,pos,val,len) SSMBMACRO(SCVALS,buf,pos,val,len,1)
+#define PSSVALS(buf,pos,val,len) SSMBMACRO(SSVALS,buf,pos,val,len,2)
+#define PSIVALS(buf,pos,val,len) SSMBMACRO(SIVALS,buf,pos,val,len,4)
+
+
+/* now the reverse routines - these are used in nmb packets (mostly) */
+#define SREV(x) ((((x)&0xFF)<<8) | (((x)>>8)&0xFF))
+#define IREV(x) ((SREV(x)<<16) | (SREV((x)>>16)))
+
+#define RSVAL(buf,pos) SREV(SVAL(buf,pos))
+#define RSVALS(buf,pos) SREV(SVALS(buf,pos))
+#define RIVAL(buf,pos) IREV(IVAL(buf,pos))
+#define RIVALS(buf,pos) IREV(IVALS(buf,pos))
+#define RSSVAL(buf,pos,val) SSVAL(buf,pos,SREV(val))
+#define RSSVALS(buf,pos,val) SSVALS(buf,pos,SREV(val))
+#define RSIVAL(buf,pos,val) SIVAL(buf,pos,IREV(val))
+#define RSIVALS(buf,pos,val) SIVALS(buf,pos,IREV(val))
+
+/* reads multiple data from an SMB buffer (big-endian) */
+#define RPSVAL(buf,pos,val,len) SMBMACRO(RSVAL,buf,pos,val,len,2)
+#define RPIVAL(buf,pos,val,len) SMBMACRO(RIVAL,buf,pos,val,len,4)
+#define RPSVALS(buf,pos,val,len) SMBMACRO(RSVALS,buf,pos,val,len,2)
+#define RPIVALS(buf,pos,val,len) SMBMACRO(RIVALS,buf,pos,val,len,4)
+
+/* stores multiple data in an SMB buffer (big-endian) */
+#define RPSSVAL(buf,pos,val,len) SSMBMACRO(RSSVAL,buf,pos,val,len,2)
+#define RPSIVAL(buf,pos,val,len) SSMBMACRO(RSIVAL,buf,pos,val,len,4)
+#define RPSSVALS(buf,pos,val,len) SSMBMACRO(RSSVALS,buf,pos,val,len,2)
+#define RPSIVALS(buf,pos,val,len) SSMBMACRO(RSIVALS,buf,pos,val,len,4)
+
+#define DBG_RW_PCVAL(charmode,string,depth,base,read,inbuf,outbuf,len) \
+	{ RW_PCVAL(read,inbuf,outbuf,len) \
+	DEBUG(5,("%s%04x %s: ", \
+             tab_depth(depth), base,string)); \
+    if (charmode) print_asc(5, (unsigned char*)(outbuf), (len)); else \
+	{ int idx; for (idx = 0; idx < len; idx++) { DEBUG(5,("%02x ", (outbuf)[idx])); } } \
+	DEBUG(5,("\n")); } 
+
+#define DBG_RW_PSVAL(charmode,string,depth,base,read,big_endian,inbuf,outbuf,len) \
+	{ RW_PSVAL(read,big_endian,inbuf,outbuf,len) \
+	DEBUG(5,("%s%04x %s: ", \
+             tab_depth(depth), base,string)); \
+    if (charmode) print_asc(5, (unsigned char*)(outbuf), 2*(len)); else \
+	{ int idx; for (idx = 0; idx < len; idx++) { DEBUG(5,("%04x ", (outbuf)[idx])); } } \
+	DEBUG(5,("\n")); }
+
+#define DBG_RW_PIVAL(charmode,string,depth,base,read,big_endian,inbuf,outbuf,len) \
+	{ RW_PIVAL(read,big_endian,inbuf,outbuf,len) \
+	DEBUG(5,("%s%04x %s: ", \
+             tab_depth(depth), base,string)); \
+    if (charmode) print_asc(5, (unsigned char*)(outbuf), 4*(len)); else \
+	{ int idx; for (idx = 0; idx < len; idx++) { DEBUG(5,("%08x ", (outbuf)[idx])); } } \
+	DEBUG(5,("\n")); }
+
+#define DBG_RW_CVAL(string,depth,base,read,inbuf,outbuf) \
+	{ RW_CVAL(read,inbuf,outbuf,0) \
+	DEBUG(5,("%s%04x %s: %02x\n", \
+             tab_depth(depth), base, string, outbuf)); }
+
+#define DBG_RW_SVAL(string,depth,base,read,big_endian,inbuf,outbuf) \
+	{ RW_SVAL(read,big_endian,inbuf,outbuf,0) \
+	DEBUG(5,("%s%04x %s: %04x\n", \
+             tab_depth(depth), base, string, outbuf)); }
+
+#define DBG_RW_IVAL(string,depth,base,read,big_endian,inbuf,outbuf) \
+	{ RW_IVAL(read,big_endian,inbuf,outbuf,0) \
+	DEBUG(5,("%s%04x %s: %08x\n", \
+             tab_depth(depth), base, string, outbuf)); }
+
+#endif /* _BYTEORDER_H */
diff --git a/smbdes.c b/smbdes.c
new file mode 100644
index 00000000..e3ab78af
--- /dev/null
+++ b/smbdes.c
@@ -0,0 +1,399 @@
+/* 
+   Unix SMB/Netbios implementation.
+   Version 1.9.
+
+   a partial implementation of DES designed for use in the 
+   SMB authentication protocol
+
+   Copyright (C) Andrew Tridgell 1998
+   
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+   
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#include "smbdes.h"
+
+/* NOTES: 
+
+   This code makes no attempt to be fast! In fact, it is a very
+   slow implementation 
+
+   This code is NOT a complete DES implementation. It implements only
+   the minimum necessary for SMB authentication, as used by all SMB
+   products (including every copy of Microsoft Windows95 ever sold)
+
+   In particular, it can only do a unchained forward DES pass. This
+   means it is not possible to use this code for encryption/decryption
+   of data, instead it is only useful as a "hash" algorithm.
+
+   There is no entry point into this code that allows normal DES operation.
+
+   I believe this means that this code does not come under ITAR
+   regulations but this is NOT a legal opinion. If you are concerned
+   about the applicability of ITAR regulations to this code then you
+   should confirm it for yourself (and maybe let me know if you come
+   up with a different answer to the one above)
+*/
+
+
+#define uchar unsigned char
+
+static uchar perm1[56] = {57, 49, 41, 33, 25, 17,  9,
+			 1, 58, 50, 42, 34, 26, 18,
+			10,  2, 59, 51, 43, 35, 27,
+			19, 11,  3, 60, 52, 44, 36,
+			63, 55, 47, 39, 31, 23, 15,
+			 7, 62, 54, 46, 38, 30, 22,
+			14,  6, 61, 53, 45, 37, 29,
+			21, 13,  5, 28, 20, 12,  4};
+
+static uchar perm2[48] = {14, 17, 11, 24,  1,  5,
+                         3, 28, 15,  6, 21, 10,
+                        23, 19, 12,  4, 26,  8,
+                        16,  7, 27, 20, 13,  2,
+                        41, 52, 31, 37, 47, 55,
+                        30, 40, 51, 45, 33, 48,
+                        44, 49, 39, 56, 34, 53,
+                        46, 42, 50, 36, 29, 32};
+
+static uchar perm3[64] = {58, 50, 42, 34, 26, 18, 10,  2,
+			60, 52, 44, 36, 28, 20, 12,  4,
+			62, 54, 46, 38, 30, 22, 14,  6,
+			64, 56, 48, 40, 32, 24, 16,  8,
+			57, 49, 41, 33, 25, 17,  9,  1,
+			59, 51, 43, 35, 27, 19, 11,  3,
+			61, 53, 45, 37, 29, 21, 13,  5,
+			63, 55, 47, 39, 31, 23, 15,  7};
+
+static uchar perm4[48] = {   32,  1,  2,  3,  4,  5,
+                            4,  5,  6,  7,  8,  9,
+                            8,  9, 10, 11, 12, 13,
+                           12, 13, 14, 15, 16, 17,
+                           16, 17, 18, 19, 20, 21,
+                           20, 21, 22, 23, 24, 25,
+                           24, 25, 26, 27, 28, 29,
+                           28, 29, 30, 31, 32,  1};
+
+static uchar perm5[32] = {      16,  7, 20, 21,
+                              29, 12, 28, 17,
+                               1, 15, 23, 26,
+                               5, 18, 31, 10,
+                               2,  8, 24, 14,
+                              32, 27,  3,  9,
+                              19, 13, 30,  6,
+                              22, 11,  4, 25};
+
+
+static uchar perm6[64] ={ 40,  8, 48, 16, 56, 24, 64, 32,
+                        39,  7, 47, 15, 55, 23, 63, 31,
+                        38,  6, 46, 14, 54, 22, 62, 30,
+                        37,  5, 45, 13, 53, 21, 61, 29,
+                        36,  4, 44, 12, 52, 20, 60, 28,
+                        35,  3, 43, 11, 51, 19, 59, 27,
+                        34,  2, 42, 10, 50, 18, 58, 26,
+                        33,  1, 41,  9, 49, 17, 57, 25};
+
+
+static uchar sc[16] = {1, 1, 2, 2, 2, 2, 2, 2, 1, 2, 2, 2, 2, 2, 2, 1};
+
+static uchar sbox[8][4][16] = {
+	{{14,  4, 13,  1,  2, 15, 11,  8,  3, 10,  6, 12,  5,  9,  0,  7},
+	 {0, 15,  7,  4, 14,  2, 13,  1, 10,  6, 12, 11,  9,  5,  3,  8},
+	 {4,  1, 14,  8, 13,  6,  2, 11, 15, 12,  9,  7,  3, 10,  5,  0},
+	 {15, 12,  8,  2,  4,  9,  1,  7,  5, 11,  3, 14, 10,  0,  6, 13}},
+
+	{{15,  1,  8, 14,  6, 11,  3,  4,  9,  7,  2, 13, 12,  0,  5, 10},
+	 {3, 13,  4,  7, 15,  2,  8, 14, 12,  0,  1, 10,  6,  9, 11,  5},
+	 {0, 14,  7, 11, 10,  4, 13,  1,  5,  8, 12,  6,  9,  3,  2, 15},
+	 {13,  8, 10,  1,  3, 15,  4,  2, 11,  6,  7, 12,  0,  5, 14,  9}},
+
+	{{10,  0,  9, 14,  6,  3, 15,  5,  1, 13, 12,  7, 11,  4,  2,  8},
+	 {13,  7,  0,  9,  3,  4,  6, 10,  2,  8,  5, 14, 12, 11, 15,  1},
+	 {13,  6,  4,  9,  8, 15,  3,  0, 11,  1,  2, 12,  5, 10, 14,  7},
+	 {1, 10, 13,  0,  6,  9,  8,  7,  4, 15, 14,  3, 11,  5,  2, 12}},
+
+	{{7, 13, 14,  3,  0,  6,  9, 10,  1,  2,  8,  5, 11, 12,  4, 15},
+	 {13,  8, 11,  5,  6, 15,  0,  3,  4,  7,  2, 12,  1, 10, 14,  9},
+	 {10,  6,  9,  0, 12, 11,  7, 13, 15,  1,  3, 14,  5,  2,  8,  4},
+	 {3, 15,  0,  6, 10,  1, 13,  8,  9,  4,  5, 11, 12,  7,  2, 14}},
+
+	{{2, 12,  4,  1,  7, 10, 11,  6,  8,  5,  3, 15, 13,  0, 14,  9},
+	 {14, 11,  2, 12,  4,  7, 13,  1,  5,  0, 15, 10,  3,  9,  8,  6},
+	 {4,  2,  1, 11, 10, 13,  7,  8, 15,  9, 12,  5,  6,  3,  0, 14},
+	 {11,  8, 12,  7,  1, 14,  2, 13,  6, 15,  0,  9, 10,  4,  5,  3}},
+
+	{{12,  1, 10, 15,  9,  2,  6,  8,  0, 13,  3,  4, 14,  7,  5, 11},
+	 {10, 15,  4,  2,  7, 12,  9,  5,  6,  1, 13, 14,  0, 11,  3,  8},
+	 {9, 14, 15,  5,  2,  8, 12,  3,  7,  0,  4, 10,  1, 13, 11,  6},
+	 {4,  3,  2, 12,  9,  5, 15, 10, 11, 14,  1,  7,  6,  0,  8, 13}},
+
+	{{4, 11,  2, 14, 15,  0,  8, 13,  3, 12,  9,  7,  5, 10,  6,  1},
+	 {13,  0, 11,  7,  4,  9,  1, 10, 14,  3,  5, 12,  2, 15,  8,  6},
+	 {1,  4, 11, 13, 12,  3,  7, 14, 10, 15,  6,  8,  0,  5,  9,  2},
+	 {6, 11, 13,  8,  1,  4, 10,  7,  9,  5,  0, 15, 14,  2,  3, 12}},
+
+	{{13,  2,  8,  4,  6, 15, 11,  1, 10,  9,  3, 14,  5,  0, 12,  7},
+	 {1, 15, 13,  8, 10,  3,  7,  4, 12,  5,  6, 11,  0, 14,  9,  2},
+	 {7, 11,  4,  1,  9, 12, 14,  2,  0,  6, 10, 13, 15,  3,  5,  8},
+	 {2,  1, 14,  7,  4, 10,  8, 13, 15, 12,  9,  0,  3,  5,  6, 11}}};
+
+static void permute(char *out, char *in, uchar *p, int n)
+{
+	int i;
+	for (i=0;i<n;i++)
+		out[i] = in[p[i]-1];
+}
+
+static void lshift(char *d, int count, int n)
+{
+	char out[64];
+	int i;
+	for (i=0;i<n;i++)
+		out[i] = d[(i+count)%n];
+	for (i=0;i<n;i++)
+		d[i] = out[i];
+}
+
+static void concat(char *out, char *in1, char *in2, int l1, int l2)
+{
+	while (l1--)
+		*out++ = *in1++;
+	while (l2--)
+		*out++ = *in2++;
+}
+
+static void xor(char *out, char *in1, char *in2, int n)
+{
+	int i;
+	for (i=0;i<n;i++)
+		out[i] = in1[i] ^ in2[i];
+}
+
+static void dohash(char *out, char *in, char *key, int forw)
+{
+	int i, j, k;
+	char pk1[56];
+	char c[28];
+	char d[28];
+	char cd[56];
+	char ki[16][48];
+	char pd1[64];
+	char l[32], r[32];
+	char rl[64];
+
+	permute(pk1, key, perm1, 56);
+
+	for (i=0;i<28;i++)
+		c[i] = pk1[i];
+	for (i=0;i<28;i++)
+		d[i] = pk1[i+28];
+
+	for (i=0;i<16;i++) {
+		lshift(c, sc[i], 28);
+		lshift(d, sc[i], 28);
+
+		concat(cd, c, d, 28, 28); 
+		permute(ki[i], cd, perm2, 48); 
+	}
+
+	permute(pd1, in, perm3, 64);
+
+	for (j=0;j<32;j++) {
+		l[j] = pd1[j];
+		r[j] = pd1[j+32];
+	}
+
+	for (i=0;i<16;i++) {
+		char er[48];
+		char erk[48];
+		char b[8][6];
+		char cb[32];
+		char pcb[32];
+		char r2[32];
+
+		permute(er, r, perm4, 48);
+
+		xor(erk, er, ki[forw ? i : 15 - i], 48);
+
+		for (j=0;j<8;j++)
+			for (k=0;k<6;k++)
+				b[j][k] = erk[j*6 + k];
+
+		for (j=0;j<8;j++) {
+			int m, n;
+			m = (b[j][0]<<1) | b[j][5];
+
+			n = (b[j][1]<<3) | (b[j][2]<<2) | (b[j][3]<<1) | b[j][4]; 
+
+			for (k=0;k<4;k++) 
+				b[j][k] = (sbox[j][m][n] & (1<<(3-k)))?1:0; 
+		}
+
+		for (j=0;j<8;j++)
+			for (k=0;k<4;k++)
+				cb[j*4+k] = b[j][k];
+		permute(pcb, cb, perm5, 32);
+
+		xor(r2, l, pcb, 32);
+
+		for (j=0;j<32;j++)
+			l[j] = r[j];
+
+		for (j=0;j<32;j++)
+			r[j] = r2[j];
+	}
+
+	concat(rl, r, l, 32, 32);
+
+	permute(out, rl, perm6, 64);
+}
+
+static void str_to_key(unsigned char *str,unsigned char *key)
+{
+	int i;
+
+	key[0] = str[0]>>1;
+	key[1] = ((str[0]&0x01)<<6) | (str[1]>>2);
+	key[2] = ((str[1]&0x03)<<5) | (str[2]>>3);
+	key[3] = ((str[2]&0x07)<<4) | (str[3]>>4);
+	key[4] = ((str[3]&0x0F)<<3) | (str[4]>>5);
+	key[5] = ((str[4]&0x1F)<<2) | (str[5]>>6);
+	key[6] = ((str[5]&0x3F)<<1) | (str[6]>>7);
+	key[7] = str[6]&0x7F;
+	for (i=0;i<8;i++) {
+		key[i] = (key[i]<<1);
+	}
+}
+
+
+static void smbhash(unsigned char *out, unsigned char *in, unsigned char *key, int forw)
+{
+	int i;
+	char outb[64];
+	char inb[64];
+	char keyb[64];
+	unsigned char key2[8];
+
+	str_to_key(key, key2);
+
+	for (i=0;i<64;i++) {
+		inb[i] = (in[i/8] & (1<<(7-(i%8)))) ? 1 : 0;
+		keyb[i] = (key2[i/8] & (1<<(7-(i%8)))) ? 1 : 0;
+		outb[i] = 0;
+	}
+
+	dohash(outb, inb, keyb, forw);
+
+	for (i=0;i<8;i++) {
+		out[i] = 0;
+	}
+
+	for (i=0;i<64;i++) {
+		if (outb[i])
+			out[i/8] |= (1<<(7-(i%8)));
+	}
+}
+
+void E_P16(unsigned char *p14,unsigned char *p16)
+{
+	unsigned char sp8[8] = {0x4b, 0x47, 0x53, 0x21, 0x40, 0x23, 0x24, 0x25};
+	smbhash(p16, sp8, p14, 1);
+	smbhash(p16+8, sp8, p14+7, 1);
+}
+
+void E_P24(unsigned char *p21, unsigned char *c8, unsigned char *p24)
+{
+	smbhash(p24, c8, p21, 1);
+	smbhash(p24+8, c8, p21+7, 1);
+	smbhash(p24+16, c8, p21+14, 1);
+}
+
+void D_P16(unsigned char *p14, unsigned char *in, unsigned char *out)
+{
+	smbhash(out, in, p14, 0);
+        smbhash(out+8, in+8, p14+7, 0);
+}
+
+void E_old_pw_hash( unsigned char *p14, unsigned char *in, unsigned char *out)
+{
+        smbhash(out, in, p14, 1);
+        smbhash(out+8, in+8, p14+7, 1);
+}
+
+void cred_hash1(unsigned char *out,unsigned char *in,unsigned char *key)
+{
+	unsigned char buf[8];
+
+	smbhash(buf, in, key, 1);
+	smbhash(out, buf, key+9, 1);
+}
+
+void cred_hash2(unsigned char *out,unsigned char *in,unsigned char *key)
+{
+	unsigned char buf[8];
+	static unsigned char key2[8];
+
+	smbhash(buf, in, key, 1);
+	key2[0] = key[7];
+	smbhash(out, buf, key2, 1);
+}
+
+void cred_hash3(unsigned char *out,unsigned char *in,unsigned char *key, int forw)
+{
+        static unsigned char key2[8];
+
+        smbhash(out, in, key, forw);
+        key2[0] = key[7];
+        smbhash(out + 8, in + 8, key2, forw);
+}
+
+void SamOEMhash( unsigned char *data, unsigned char *key, int val)
+{
+  unsigned char s_box[256];
+  unsigned char index_i = 0;
+  unsigned char index_j = 0;
+  unsigned char j = 0;
+  int ind;
+
+  for (ind = 0; ind < 256; ind++)
+  {
+    s_box[ind] = (unsigned char)ind;
+  }
+
+  for( ind = 0; ind < 256; ind++)
+  {
+     unsigned char tc;
+
+     j += (s_box[ind] + key[ind%16]);
+
+     tc = s_box[ind];
+     s_box[ind] = s_box[j];
+     s_box[j] = tc;
+  }
+  for( ind = 0; ind < (val ? 516 : 16); ind++)
+  {
+    unsigned char tc;
+    unsigned char t;
+
+    index_i++;
+    index_j += s_box[index_i];
+
+    tc = s_box[index_i];
+    s_box[index_i] = s_box[index_j];
+    s_box[index_j] = tc;
+
+    t = s_box[index_i] + s_box[index_j];
+    data[ind] = data[ind] ^ s_box[t];
+  }
+}
diff --git a/smbdes.h b/smbdes.h
new file mode 100644
index 00000000..f890fcd5
--- /dev/null
+++ b/smbdes.h
@@ -0,0 +1,9 @@
+
+extern void E_P16(unsigned char *p14,unsigned char *p16);
+extern void E_P24(unsigned char *p21, unsigned char *c8, unsigned char *p24);
+extern void D_P16(unsigned char *p14, unsigned char *in, unsigned char *out);
+extern void E_old_pw_hash( unsigned char *p14, unsigned char *in, unsigned char *out);
+extern void cred_hash1(unsigned char *out,unsigned char *in,unsigned char *key);
+extern void cred_hash2(unsigned char *out,unsigned char *in,unsigned char *key);
+extern void cred_hash3(unsigned char *out,unsigned char *in,unsigned char *key, int forw);
+extern void SamOEMhash( unsigned char *data, unsigned char *key, int val);
diff --git a/smbencrypt.c b/smbencrypt.c
new file mode 100644
index 00000000..8740481d
--- /dev/null
+++ b/smbencrypt.c
@@ -0,0 +1,325 @@
+/* 
+   Unix SMB/Netbios implementation.
+   Version 1.9.
+   SMB parameters and setup
+   Copyright (C) Andrew Tridgell 1992-1998
+   Modified by Jeremy Allison 1995.
+   
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+   
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#define DEBUG(a,b) ;
+
+extern int DEBUGLEVEL;
+
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <ctype.h>
+#include "smbbyteorder.h"
+#include "smbdes.h"
+#include "smbmd4.h"
+
+#ifndef _AIX
+typedef unsigned char uchar;
+#endif
+typedef signed short int16;
+typedef unsigned short uint16;
+typedef int BOOL;
+#define False 0
+#define True  1
+
+/****************************************************************************
+ Like strncpy but always null terminates. Make sure there is room!
+ The variable n should always be one less than the available size.
+****************************************************************************/
+
+char *StrnCpy(char *dest,const char *src, size_t n)
+{
+  char *d = dest;
+  if (!dest) return(NULL);
+  if (!src) {
+    *dest = 0;
+    return(dest);
+  }
+  while (n-- && (*d++ = *src++)) ;
+  *d = 0;
+  return(dest);
+}
+
+size_t skip_multibyte_char(char c)
+{
+return 0;
+}
+
+
+/*******************************************************************
+safe string copy into a known length string. maxlength does not
+include the terminating zero.
+********************************************************************/
+
+char *safe_strcpy(char *dest,const char *src, size_t maxlength)
+{
+    size_t len;
+
+    if (!dest) {
+        DEBUG(0,("ERROR: NULL dest in safe_strcpy\n"));
+        return NULL;
+    }
+
+    if (!src) {
+        *dest = 0;
+        return dest;
+    }  
+
+    len = strlen(src);
+
+    if (len > maxlength) {
+            DEBUG(0,("ERROR: string overflow by %d in safe_strcpy [%.50s]\n",
+                     (int)(len-maxlength), src));
+            len = maxlength;
+    }
+      
+    memcpy(dest, src, len);
+    dest[len] = 0;
+    return dest;
+}  
+
+
+void strupper(char *s)
+{
+while (*s)
+  {
+    {
+    size_t skip = skip_multibyte_char( *s );
+    if( skip != 0 )
+      s += skip;
+    else
+      {
+      if (islower(*s))
+	*s = toupper(*s);
+      s++;
+      }
+    }
+  }
+}
+
+extern void SMBOWFencrypt(uchar passwd[16], uchar *c8, uchar p24[24]);
+
+/*
+ This implements the X/Open SMB password encryption
+ It takes a password, a 8 byte "crypt key" and puts 24 bytes of 
+ encrypted password into p24 
+ */
+
+void SMBencrypt(uchar *passwd, uchar *c8, uchar *p24)
+  {
+  uchar p14[15], p21[21];
+  
+  memset(p21,'\0',21);
+  memset(p14,'\0',14);
+  StrnCpy((char *)p14,(char *)passwd,14);
+  
+  strupper((char *)p14);
+  E_P16(p14, p21); 
+  
+  SMBOWFencrypt(p21, c8, p24);
+  
+#ifdef DEBUG_PASSWORD
+  DEBUG(100,("SMBencrypt: lm#, challenge, response\n"));
+  dump_data(100, (char *)p21, 16);
+  dump_data(100, (char *)c8, 8);
+  dump_data(100, (char *)p24, 24);
+#endif
+  }
+
+/* Routines for Windows NT MD4 Hash functions. */
+static int _my_wcslen(int16 *str)
+{
+	int len = 0;
+	while(*str++ != 0)
+		len++;
+	return len;
+}
+
+/*
+ * Convert a string into an NT UNICODE string.
+ * Note that regardless of processor type 
+ * this must be in intel (little-endian)
+ * format.
+ */
+ 
+static int _my_mbstowcs(int16 *dst, uchar *src, int len)
+{
+	int i;
+	int16 val;
+ 
+	for(i = 0; i < len; i++) {
+		val = *src;
+		SSVAL(dst,0,val);
+		dst++;
+		src++;
+		if(val == 0)
+			break;
+	}
+	return i;
+}
+
+/* 
+ * Creates the MD4 Hash of the users password in NT UNICODE.
+ */
+ 
+void E_md4hash(uchar *passwd, uchar *p16)
+{
+	int len;
+	int16 wpwd[129];
+	
+	/* Password cannot be longer than 128 characters */
+	len = strlen((char *)passwd);
+	if(len > 128)
+		len = 128;
+	/* Password must be converted to NT unicode */
+	_my_mbstowcs(wpwd, passwd, len);
+	wpwd[len] = 0; /* Ensure string is null terminated */
+	/* Calculate length in bytes */
+	len = _my_wcslen(wpwd) * sizeof(int16);
+
+	mdfour(p16, (unsigned char *)wpwd, len);
+}
+
+/* Does both the NT and LM owfs of a user's password */
+void nt_lm_owf_gen(char *pwd, uchar nt_p16[16], uchar p16[16])
+{
+	char passwd[130];
+
+	memset(passwd,'\0',130);
+	safe_strcpy( passwd, pwd, sizeof(passwd)-1);
+
+	/* Calculate the MD4 hash (NT compatible) of the password */
+	memset(nt_p16, '\0', 16);
+	E_md4hash((uchar *)passwd, nt_p16);
+
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("nt_lm_owf_gen: pwd, nt#\n"));
+	dump_data(120, passwd, strlen(passwd));
+	dump_data(100, (char *)nt_p16, 16);
+#endif
+
+	/* Mangle the passwords into Lanman format */
+	passwd[14] = '\0';
+	strupper(passwd);
+
+	/* Calculate the SMB (lanman) hash functions of the password */
+
+	memset(p16, '\0', 16);
+	E_P16((uchar *) passwd, (uchar *)p16);
+
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("nt_lm_owf_gen: pwd, lm#\n"));
+	dump_data(120, passwd, strlen(passwd));
+	dump_data(100, (char *)p16, 16);
+#endif
+	/* clear out local copy of user's password (just being paranoid). */
+	memset(passwd, '\0', sizeof(passwd));
+}
+
+/* Does the des encryption from the NT or LM MD4 hash. */
+void SMBOWFencrypt(uchar passwd[16], uchar *c8, uchar p24[24])
+{
+	uchar p21[21];
+ 
+	memset(p21,'\0',21);
+ 
+	memcpy(p21, passwd, 16);    
+	E_P24(p21, c8, p24);
+}
+
+/* Does the des encryption from the FIRST 8 BYTES of the NT or LM MD4 hash. */
+void NTLMSSPOWFencrypt(uchar passwd[8], uchar *ntlmchalresp, uchar p24[24])
+{
+	uchar p21[21];
+ 
+	memset(p21,'\0',21);
+	memcpy(p21, passwd, 8);    
+	memset(p21 + 8, 0xbd, 8);    
+
+	E_P24(p21, ntlmchalresp, p24);
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("NTLMSSPOWFencrypt: p21, c8, p24\n"));
+	dump_data(100, (char *)p21, 21);
+	dump_data(100, (char *)ntlmchalresp, 8);
+	dump_data(100, (char *)p24, 24);
+#endif
+}
+
+
+/* Does the NT MD4 hash then des encryption. */
+ 
+void SMBNTencrypt(uchar *passwd, uchar *c8, uchar *p24)
+{
+	uchar p21[21];
+ 
+	memset(p21,'\0',21);
+ 
+	E_md4hash(passwd, p21);    
+	SMBOWFencrypt(p21, c8, p24);
+
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("SMBNTencrypt: nt#, challenge, response\n"));
+	dump_data(100, (char *)p21, 16);
+	dump_data(100, (char *)c8, 8);
+	dump_data(100, (char *)p24, 24);
+#endif
+}
+
+#if 0
+
+BOOL make_oem_passwd_hash(char data[516], const char *passwd, uchar old_pw_hash[16], BOOL unicode)
+{
+	int new_pw_len = strlen(passwd) * (unicode ? 2 : 1);
+
+	if (new_pw_len > 512)
+	{
+		DEBUG(0,("make_oem_passwd_hash: new password is too long.\n"));
+		return False;
+	}
+
+	/*
+	 * Now setup the data area.
+	 * We need to generate a random fill
+	 * for this area to make it harder to
+	 * decrypt. JRA.
+	 */
+	generate_random_buffer((unsigned char *)data, 516, False);
+	if (unicode)
+	{
+		struni2( &data[512 - new_pw_len], passwd);
+	}
+	else
+	{
+		fstrcpy( &data[512 - new_pw_len], passwd);
+	}
+	SIVAL(data, 512, new_pw_len);
+
+#ifdef DEBUG_PASSWORD
+	DEBUG(100,("make_oem_passwd_hash\n"));
+	dump_data(100, data, 516);
+#endif
+	SamOEMhash( (unsigned char *)data, (unsigned char *)old_pw_hash, True);
+
+	return True;
+}
+
+#endif
diff --git a/smbencrypt.h b/smbencrypt.h
new file mode 100644
index 00000000..0f33b062
--- /dev/null
+++ b/smbencrypt.h
@@ -0,0 +1,2 @@
+void SMBencrypt(char *passwd, uint8 *c8, uint8 *p24);
+void SMBNTencrypt(char *passwd, uint8 *c8, uint8 *p24);
diff --git a/smbmd4.c b/smbmd4.c
new file mode 100644
index 00000000..4b47e621
--- /dev/null
+++ b/smbmd4.c
@@ -0,0 +1,173 @@
+/* 
+   Unix SMB/Netbios implementation.
+   Version 1.9.
+   a implementation of MD4 designed for use in the SMB authentication protocol
+   Copyright (C) Andrew Tridgell 1997-1998.
+   
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+   
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+   
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#include <string.h>
+#include "smbmd4.h"
+
+typedef unsigned uint32;
+
+/* NOTE: This code makes no attempt to be fast! 
+
+   It assumes that a int is at least 32 bits long
+*/
+
+static uint32 A, B, C, D;
+
+static uint32 F(uint32 X, uint32 Y, uint32 Z)
+{
+	return (X&Y) | ((~X)&Z);
+}
+
+static uint32 G(uint32 X, uint32 Y, uint32 Z)
+{
+	return (X&Y) | (X&Z) | (Y&Z); 
+}
+
+static uint32 H(uint32 X, uint32 Y, uint32 Z)
+{
+	return X^Y^Z;
+}
+
+static uint32 lshift(uint32 x, int s)
+{
+	x &= 0xFFFFFFFF;
+	return ((x<<s)&0xFFFFFFFF) | (x>>(32-s));
+}
+
+#define ROUND1(a,b,c,d,k,s) a = lshift(a + F(b,c,d) + X[k], s)
+#define ROUND2(a,b,c,d,k,s) a = lshift(a + G(b,c,d) + X[k] + (uint32)0x5A827999,s)
+#define ROUND3(a,b,c,d,k,s) a = lshift(a + H(b,c,d) + X[k] + (uint32)0x6ED9EBA1,s)
+
+/* this applies md4 to 64 byte chunks */
+static void mdfour64(uint32 *M)
+{
+	int j;
+	uint32 AA, BB, CC, DD;
+	uint32 X[16];
+
+	for (j=0;j<16;j++)
+		X[j] = M[j];
+
+	AA = A; BB = B; CC = C; DD = D;
+
+        ROUND1(A,B,C,D,  0,  3);  ROUND1(D,A,B,C,  1,  7);  
+	ROUND1(C,D,A,B,  2, 11);  ROUND1(B,C,D,A,  3, 19);
+        ROUND1(A,B,C,D,  4,  3);  ROUND1(D,A,B,C,  5,  7);  
+	ROUND1(C,D,A,B,  6, 11);  ROUND1(B,C,D,A,  7, 19);
+        ROUND1(A,B,C,D,  8,  3);  ROUND1(D,A,B,C,  9,  7);  
+	ROUND1(C,D,A,B, 10, 11);  ROUND1(B,C,D,A, 11, 19);
+        ROUND1(A,B,C,D, 12,  3);  ROUND1(D,A,B,C, 13,  7);  
+	ROUND1(C,D,A,B, 14, 11);  ROUND1(B,C,D,A, 15, 19);	
+
+        ROUND2(A,B,C,D,  0,  3);  ROUND2(D,A,B,C,  4,  5);  
+	ROUND2(C,D,A,B,  8,  9);  ROUND2(B,C,D,A, 12, 13);
+        ROUND2(A,B,C,D,  1,  3);  ROUND2(D,A,B,C,  5,  5);  
+	ROUND2(C,D,A,B,  9,  9);  ROUND2(B,C,D,A, 13, 13);
+        ROUND2(A,B,C,D,  2,  3);  ROUND2(D,A,B,C,  6,  5);  
+	ROUND2(C,D,A,B, 10,  9);  ROUND2(B,C,D,A, 14, 13);
+        ROUND2(A,B,C,D,  3,  3);  ROUND2(D,A,B,C,  7,  5);  
+	ROUND2(C,D,A,B, 11,  9);  ROUND2(B,C,D,A, 15, 13);
+
+	ROUND3(A,B,C,D,  0,  3);  ROUND3(D,A,B,C,  8,  9);  
+	ROUND3(C,D,A,B,  4, 11);  ROUND3(B,C,D,A, 12, 15);
+        ROUND3(A,B,C,D,  2,  3);  ROUND3(D,A,B,C, 10,  9);  
+	ROUND3(C,D,A,B,  6, 11);  ROUND3(B,C,D,A, 14, 15);
+        ROUND3(A,B,C,D,  1,  3);  ROUND3(D,A,B,C,  9,  9);  
+	ROUND3(C,D,A,B,  5, 11);  ROUND3(B,C,D,A, 13, 15);
+        ROUND3(A,B,C,D,  3,  3);  ROUND3(D,A,B,C, 11,  9);  
+	ROUND3(C,D,A,B,  7, 11);  ROUND3(B,C,D,A, 15, 15);
+
+	A += AA; B += BB; C += CC; D += DD;
+	
+	A &= 0xFFFFFFFF; B &= 0xFFFFFFFF;
+	C &= 0xFFFFFFFF; D &= 0xFFFFFFFF;
+
+	for (j=0;j<16;j++)
+		X[j] = 0;
+}
+
+static void copy64(uint32 *M, unsigned char *in)
+{
+	int i;
+
+	for (i=0;i<16;i++)
+		M[i] = (in[i*4+3]<<24) | (in[i*4+2]<<16) |
+			(in[i*4+1]<<8) | (in[i*4+0]<<0);
+}
+
+static void copy4(unsigned char *out,uint32 x)
+{
+	out[0] = x&0xFF;
+	out[1] = (x>>8)&0xFF;
+	out[2] = (x>>16)&0xFF;
+	out[3] = (x>>24)&0xFF;
+}
+
+/* produce a md4 message digest from data of length n bytes */
+void mdfour(unsigned char *out, unsigned char *in, int n)
+{
+	unsigned char buf[128];
+	uint32 M[16];
+	uint32 b = n * 8;
+	int i;
+
+	A = 0x67452301;
+	B = 0xefcdab89;
+	C = 0x98badcfe;
+	D = 0x10325476;
+
+	while (n > 64) {
+		copy64(M, in);
+		mdfour64(M);
+		in += 64;
+		n -= 64;
+	}
+
+	for (i=0;i<128;i++)
+		buf[i] = 0;
+	memcpy(buf, in, n);
+	buf[n] = 0x80;
+	
+	if (n <= 55) {
+		copy4(buf+56, b);
+		copy64(M, buf);
+		mdfour64(M);
+	} else {
+		copy4(buf+120, b); 
+		copy64(M, buf);
+		mdfour64(M);
+		copy64(M, buf+64);
+		mdfour64(M);
+	}
+
+	for (i=0;i<128;i++)
+		buf[i] = 0;
+	copy64(M, buf);
+
+	copy4(out, A);
+	copy4(out+4, B);
+	copy4(out+8, C);
+	copy4(out+12, D);
+
+	A = B = C = D = 0;
+}
+
+
diff --git a/smbmd4.h b/smbmd4.h
new file mode 100644
index 00000000..af739949
--- /dev/null
+++ b/smbmd4.h
@@ -0,0 +1 @@
+extern void mdfour(unsigned char *out, unsigned char *in, int n);
diff --git a/smbutil.c b/smbutil.c
new file mode 100644
index 00000000..cbe18b99
--- /dev/null
+++ b/smbutil.c
@@ -0,0 +1,219 @@
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <ctype.h>
+#include <assert.h>
+#include <string.h>
+#include "ntlm.h"
+#include "smbencrypt.h"
+#include "smbbyteorder.h"
+#include "fetchmail.h"
+
+char versionString[] ="libntlm version 0.21";
+
+/* Utility routines that handle NTLM auth structures. */
+
+/* The [IS]VAL macros are to take care of byte order for non-Intel
+ * Machines -- I think this file is OK, but it hasn't been tested.
+ * The other files (the ones stolen from Samba) should be OK.
+ */
+
+
+/* I am not crazy about these macros -- they seem to have gotten
+ * a bit complex.  A new scheme for handling string/buffer fields
+ * in the structures probably needs to be designed
+ */
+
+#define AddBytes(ptr, header, buf, count) \
+{ \
+if (buf && count) \
+  { \
+  SSVAL(&ptr->header.len,0,count); \
+  SSVAL(&ptr->header.maxlen,0,count); \
+  SIVAL(&ptr->header.offset,0,((ptr->buffer - ((uint8*)ptr)) + ptr->bufIndex)); \
+  memcpy(ptr->buffer+ptr->bufIndex, buf, count); \
+  ptr->bufIndex += count; \
+  } \
+else \
+  { \
+  ptr->header.len = \
+  ptr->header.maxlen = 0; \
+  SIVAL(&ptr->header.offset,0,ptr->bufIndex); \
+  } \
+}
+
+#define AddString(ptr, header, string) \
+{ \
+char *p = string; \
+int len = 0; \
+if (p) len = strlen(p); \
+AddBytes(ptr, header, ((unsigned char*)p), len); \
+}
+
+#define AddUnicodeString(ptr, header, string) \
+{ \
+char *p = string; \
+unsigned char *b = NULL; \
+int len = 0; \
+if (p) \
+  { \
+  len = strlen(p); \
+  b = strToUnicode(p); \
+  } \
+AddBytes(ptr, header, b, len*2); \
+}
+
+
+#define GetUnicodeString(structPtr, header) \
+unicodeToString(((char*)structPtr) + IVAL(&structPtr->header.offset,0) , SVAL(&structPtr->header.len,0)/2)
+#define GetString(structPtr, header) \
+toString((((char *)structPtr) + IVAL(&structPtr->header.offset,0)), SVAL(&structPtr->header.len,0))
+#define DumpBuffer(fp, structPtr, header) \
+dumpRaw(fp,((unsigned char*)structPtr)+IVAL(&structPtr->header.offset,0),SVAL(&structPtr->header.len,0))
+
+
+static void dumpRaw(FILE *fp, unsigned char *buf, size_t len)
+  {
+  int i;
+  
+  for (i=0; i<len; ++i)
+    fprintf(fp,"%02x ",buf[i]);
+    
+    fprintf(fp,"\n");
+  }
+
+static char *unicodeToString(char *p, size_t len)
+  {
+  int i;
+  static char buf[1024];
+
+  assert(len+1 < sizeof buf);
+  
+  for (i=0; i<len; ++i)
+    {  
+    buf[i] = *p & 0x7f;
+    p += 2;
+    }
+
+  buf[i] = '\0';
+  return buf;
+  }
+
+static unsigned char *strToUnicode(char *p)
+  {
+  static unsigned char buf[1024];
+  size_t l = strlen(p);
+  int i = 0;
+  
+  assert(l*2 < sizeof buf);
+  
+  while (l--)
+    {
+    buf[i++] = *p++;
+    buf[i++] = 0;
+    }
+  
+  return buf;
+  }
+
+static unsigned char *toString(char *p, size_t len)
+  {
+  static unsigned char buf[1024];
+  
+  assert(len+1 < sizeof buf);
+  
+  memcpy(buf,p,len);
+  buf[len] = 0;
+  return buf;
+  }
+
+void dumpSmbNtlmAuthRequest(FILE *fp, tSmbNtlmAuthRequest *request)
+  {
+  fprintf(fp,"NTLM Request:\n");
+  fprintf(fp,"      Ident = %s\n",request->ident);
+  fprintf(fp,"      mType = %d\n",IVAL(&request->msgType,0));
+  fprintf(fp,"      Flags = %08x\n",IVAL(&request->flags,0));
+  fprintf(fp,"       User = %s\n",GetString(request,user));
+  fprintf(fp,"     Domain = %s\n",GetString(request,domain));
+  }
+
+void dumpSmbNtlmAuthChallenge(FILE *fp, tSmbNtlmAuthChallenge *challenge)
+  {
+  fprintf(fp,"NTLM Challenge:\n");
+  fprintf(fp,"      Ident = %s\n",challenge->ident);
+  fprintf(fp,"      mType = %d\n",IVAL(&challenge->msgType,0));
+  fprintf(fp,"     Domain = %s\n",GetUnicodeString(challenge,uDomain));
+  fprintf(fp,"      Flags = %08x\n",IVAL(&challenge->flags,0));
+  fprintf(fp,"  Challenge = "); dumpRaw(fp, challenge->challengeData,8);
+  }
+
+void dumpSmbNtlmAuthResponse(FILE *fp, tSmbNtlmAuthResponse *response)
+  {
+  fprintf(fp,"NTLM Response:\n");
+  fprintf(fp,"      Ident = %s\n",response->ident);
+  fprintf(fp,"      mType = %d\n",IVAL(&response->msgType,0));
+  fprintf(fp,"     LmResp = "); DumpBuffer(fp,response,lmResponse);
+  fprintf(fp,"     NTResp = "); DumpBuffer(fp,response,ntResponse);
+  fprintf(fp,"     Domain = %s\n",GetUnicodeString(response,uDomain));
+  fprintf(fp,"       User = %s\n",GetUnicodeString(response,uUser));
+  fprintf(fp,"        Wks = %s\n",GetUnicodeString(response,uWks));
+  fprintf(fp,"       sKey = "); DumpBuffer(fp, response,sessionKey);
+  fprintf(fp,"      Flags = %08x\n",IVAL(&response->flags,0));
+  }
+
+void buildSmbNtlmAuthRequest(tSmbNtlmAuthRequest *request, char *user, char *domain)
+  {
+    char *u = xstrdup(user);
+    char *p = strchr(u,'@');
+    
+    if (p)
+      {
+        if (!domain) 
+          domain = p+1;
+        *p = '\0';
+      }
+    
+    request->bufIndex = 0;
+    memcpy(request->ident,"NTLMSSP\0\0\0",8);
+    SIVAL(&request->msgType,0,1);
+    SIVAL(&request->flags,0,0x0000b207);  /* have to figure out what these mean */
+    AddString(request,user,u);
+    AddString(request,domain,domain);
+    free(u);
+  }
+
+void buildSmbNtlmAuthResponse(tSmbNtlmAuthChallenge *challenge, tSmbNtlmAuthResponse *response, char *user, char *password)
+  {
+    uint8 lmRespData[24];
+    uint8 ntRespData[24];
+    char *d = xstrdup(GetUnicodeString(challenge,uDomain));
+    char *domain = d;
+    char *u = xstrdup(user);
+    char *p = strchr(u,'@');
+    
+    if (p)
+      {
+        domain = p+1;
+        *p = '\0';
+      }
+    
+    SMBencrypt(password,   challenge->challengeData, lmRespData);
+    SMBNTencrypt(password, challenge->challengeData, ntRespData);
+    
+    response->bufIndex = 0;
+    memcpy(response->ident,"NTLMSSP\0\0\0",8);
+    SIVAL(&response->msgType,0,3);
+    
+    AddBytes(response,lmResponse,lmRespData,24);
+    AddBytes(response,ntResponse,ntRespData,24);
+    AddUnicodeString(response,uDomain,domain);
+    AddUnicodeString(response,uUser,u);
+    AddUnicodeString(response,uWks,u);
+    AddString(response,sessionKey,NULL);
+  
+    response->flags = challenge->flags;
+    
+    free(d);
+    free(u);
+  }
+    
diff --git a/test-request b/test-request
new file mode 100644
index 00000000..160c1885
--- /dev/null
+++ b/test-request
@@ -0,0 +1,20 @@
+I maintain an open-source POP and IMAP client called fetchmail.  It is
+widely used in the Linux and open-source community, and is probably
+the single most popular remote-mail client in that world.  You can
+find out more about this project at
+<http://www.catb.org/~esr/fetchmail>.
+
+In order to be able to do thorough regression testing before each release,
+I collect test accounts on as many different kinds of POP3, IMAP, and
+ODMR servers as possible.  Because fetchmail is strictly conformant to the 
+remote-mail RFCs, many server developers have found fetchmail a useful
+standards-conformance test.
+
+I'm writing to request test accounts on your server.  I support all flavors 
+of POP2, POP3, IMAP and ODMR with either plain-password, CRAM-MD5, NTLM, 
+GSSAPI, or Kerberos authentication.  I also support SSL/TLS.
+
+It would be very helpful if I could have a separate test account for
+each protocol you support (that is, separate POP3, IMAP, and ODMR
+accounts) so I can do automated regression testing without worrying
+about mailbox race conditions.
diff --git a/testmail b/testmail
new file mode 100755
index 00000000..7941892e
--- /dev/null
+++ b/testmail
@@ -0,0 +1,10 @@
+#!/bin/sh
+size=${1:-0}
+
+(
+echo "This mail was generated on "`date`"."
+
+) | mail -s "${size}k test mail from process $$" esr@ccil.org
+
+ <<EOF
+EOF
diff --git a/testmda b/testmda
new file mode 100755
index 00000000..98a7c760
--- /dev/null
+++ b/testmda
@@ -0,0 +1,10 @@
+#!/bin/sh
+# Test MDA for debugging fetchmail configurations.
+echo "[testmda called with the following arguments: $*]"
+
+# Display the input
+cat >/tmp/testmda$$
+echo "[text is "`wc -c </tmp/testmda$$`" bytes long]"
+cat /tmp/testmda$$
+rm /tmp/testmda$$
+
diff --git a/testrc b/testrc
new file mode 100644
index 00000000..7520f8d4
--- /dev/null
+++ b/testrc
@@ -0,0 +1,14 @@
+# Configuration created Thu Oct 23 20:13:55 2003 by fetchmailconf
+set syslog
+set postmaster "postmaster"
+set bouncemail
+set no spambounce
+set properties ""
+poll pop.whosey.net with proto POP3
+       user 'foo' there with password '*' is 'me' here
+       user 'bar' there with password '*' is 'her' here
+       user 'baz' there with password '*' is 'that' here
+
+poll mail.whatsey.ca with proto POP3 interval 60
+       user 'nimble' there with password '*' is 'her' here
+
diff --git a/testservers.html b/testservers.html
new file mode 100644
index 00000000..62dc9e7b
--- /dev/null
+++ b/testservers.html
@@ -0,0 +1,64 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<link rev=made href="mailto:esr@snark.thyrsus.com"/>
+<meta name="description" content=""/>
+<meta name="keywords" content=""/> 
+<title>Fetchmail's Test List</title>
+</head>
+<body>
+<table width="100%" cellpadding=0 summary="Canned page header"><tr>
+<td width="30%">Back to <a href="/~esr">Eric's Home Page</a>
+<td width="30%" align=center>Up to <a href="/~esr/sitemap.html">Site Map</a>
+<td width="30%" align=right>Mon Jan 12 15:52:14 EST 2004
+</tr></table>
+<hr />
+<h1>Fetchmail's Test List</h1>
+
+<p>Here are the server types on my regression-test list:</p>
+
+<table border=1 width=80% align=center summary="Server list">
+<tr>
+<td><strong>Protocol &amp; Version:</strong></td>
+<td><strong>Special Options:</strong></td>
+</tr>
+<tr><td>IMAP: CommuniGate IMAP server</td><td>IMAPrev1 STARTTLS AUTH=CRAM-MD5 AUTH=DIGEST-MD5</td>
+<tr><td>POP3: CommuniGate POP3 server</td><td>CAPA LAST APOP CRAM-MD5</td>
+<tr><td>POP3: IntraStore POP3 mail server</td><td>!CAPA LAST</td>
+<tr><td>APOP: IntraStore POP3 mail server</td><td>!CAPA LAST APOP</td>
+<tr><td>IMAP: IntraStore IMAP mail server</td><td>IMAPrev1 IDLE AUTH=CRAM-MD5 AUTH=SKEY AUTH=ANONYMOUS</td>
+<tr><td>POP3: Eudora EIMS</td><td>CAPA LAST APOP SASL CRAM-MD5 NTLM</td>
+<tr><td>POP3: gmx.de pop server</td><td>!CAPA UIDL</td>
+<tr><td>IMAP: IMail IMAP server</td><td>IMAP4rev1 AUTH=CRAM-MD5</td>
+<tr><td>IMAP: Microsoft Exchange</td><td>IDLE AUTH=NTLM</td>
+<tr><td>POP3: qpopper 3.1.2 (Eudora) patched with mysql</td><td>CAPA UIDL</td>
+<tr><td>IMAP: Courier IMAP</td><td>IMAP4rev1</td>
+<tr><td>POP3: Courier POP3</td><td>CAPA UIDL</td>
+<tr><td>APOP: Qpopper using APOP</td><td>!CAPA</td>
+<tr><td>IMAP: UW IMAP</td><td>IMAPrev1</td>
+<tr><td>IMAP: Courier IMAP</td><td>IMAP4rev1</td>
+<tr><td>POP3: Qpopper 4.0.5</td><td>CAPA UIDL</td>
+</tr></table>
+
+<p>If you control a post-office server that is not one of the types listed
+here, please consider lending me a test account.  Note that I do <em>not</em>
+need shell access, just the permissions to send mail to a mailbox the server
+looks at and to fetch mail off of it.</p>
+
+<p>I'd like to have weird things like a POP2 server on here.  Also more
+closed-source servers because they tend to be broken in odd
+ways. These are the real robustness tests.</p>
+
+<hr />
+<table width="100%" cellpadding=0 summary="Canned page header"><tr>
+<td width="30%">Back to <a href="/~esr">Eric's Home Page</a>
+<td width="30%" align=center>Up to <a href="/~esr/sitemap.html">Site Map</a>
+<td width="30%" align=right>Mon Jan 12 15:52:14 EST 2004
+</tr></table>
+
+<br clear="left" />
+<ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com">&lt;esr@thyrsus.com&gt;</A></ADDRESS>
+</BODY>
+</HTML>
diff --git a/timeplot b/timeplot
new file mode 100755
index 00000000..c8240d05
--- /dev/null
+++ b/timeplot
@@ -0,0 +1,40 @@
+#!/bin/sh
+#
+# timeplot -- plot data on fetchmail release intervals
+#
+# 
+
+# Get data from the NEWS file
+timeseries | awk >/tmp/timeplot$$ '
+START	{maxdiff = 0;}
+/^[#%]/	{next;}
+	{days[count++] = $6;}
+END	{
+		for (i = 0; i < count-1; i++)
+		{
+			diffs[i] = days[i] - days[i + 1];
+			if (maxdiff < diffs[i])
+				maxdiff = diffs[i];
+		}
+		for (i = 0; i <= maxdiff; i++)
+			freq[i] = 0;
+		for (i = 0; i < count - 1; i++)
+		{
+			freq[diffs[i]]++;
+		}
+		for (i = 0; i <= maxdiff; i++)
+			printf("%d	%d\n", i, freq[i]);
+	}
+'
+
+gnuplot >time.png - <<EOF
+set xlabel "Release interval (days)"
+set ylabel "Interval frequency"
+plot '/tmp/timeplot$$' using 1:2 \
+	title "Release interval frequency"
+pause 9999
+EOF
+
+rm -f /tmp/time*
+
+# timeplot ends here
diff --git a/torturetest.gladep b/torturetest.gladep
new file mode 100644
index 00000000..d44797c3
--- /dev/null
+++ b/torturetest.gladep
@@ -0,0 +1,7 @@
+<?xml version="1.0" standalone="no"?> <!--*- mode: xml -*-->
+<!DOCTYPE glade-project SYSTEM "http://glade.gnome.org/glade-project-2.0.dtd">
+
+<glade-project>
+  <name>torturetest</name>
+  <program_name>torturetest</program_name>
+</glade-project>
diff --git a/uploadfaq b/uploadfaq
new file mode 100755
index 00000000..73d29468
--- /dev/null
+++ b/uploadfaq
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+version=`sed -n '/VERSION *= *\(.*\)/s//\1/p' <Makefile`
+echo "Uploading fetchmail version ${version} FAQ"
+
+if [ $* ]
+then
+    ../upload $*
+else
+    lftp <<EOF
+# First, copy to primary website
+open ${WWWHOST}
+cd ${WWWDIR}/fetchmail
+put fetchmail-FAQ.html
+close
+
+# Next, upload to the ftp site
+open locke.ccil.org
+cd ~ftp/pub/esr/fetchmail
+put FAQ
+close
+EOF
+    echo "fetchmail FAQ uploaded"
+fi
\ No newline at end of file