pEp.foundation
/
Pantomime
6
1
Fork 1
Code Issues 1 Pull Requests 1 Releases Wiki Activity

Basic xcode project with Pantomime

Browse Source
tagCommandMap
Dirk Zimmermann 7 years ago
commit a8fd57a6b5
206 changed files with 65143 additions and 0 deletions
Show Stats Download Patch File Download Diff File

4
.hgignore
Unescape Escape View File

@ -0,0 +1,4 @@
\.DS_Store
.*project.xcworkspace/.*
.*xcuserdata/.*
.*Pods/.*

229
Pantomime-1.2.2/ChangeLog
Unescape Escape View File

@ -0,0 +1,229 @@
2014-07-25 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/NSString+Extensions.m
Fix warning on FreeBSD too
2014-06-15 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/io.c
Fix cast to signed ssize_t or error cannot be checked.
* Framework/Pantomime/CWIMAPStore.m
* Framework/Pantomime/CWLocalFolder+mbox.m
* Framework/Pantomime/CWMIMEUtility.m
Cast safely and properly chars to int.
2014-06-12 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/CWPOP3Folder.m
Rewrite not to misues NSDate as NSCalendarDate, but to use only NSDate only.
2014-06-12 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/io.c
Better check for fread() results and print some info.
* Framework/Pantomime/CWIMAPCacheManager.m
Fix recently introduced stuid bug of double ftruncate()
* Framework/Pantomime/CWLocalFolder+mbox.m
Add minor debug logs.
2014-06-12 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/NSString+Extensions.m
Fix iconv cast.
* Framework/Pantomime/CWLocalFolder+mbox.m
Check for file function return values.
2014-06-11 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/NSString+Extensions.m
in case of realloc() failure, return
2014-06-09 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/GNUmakefile
Use LIBRARIES_DEPEND_UPON instead of ADDITIONAL_LDFLAGS. Extended version of Yavor Doganov's patch.
2014-06-09 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/CWIMAPCacheManager.m
* Framework/Pantomime/CWLocalCacheManager.m
Check for write() writing the requested number of bytes.
2014-06-09 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/CWIMAPCacheManager.m
* Framework/Pantomime/CWLocalCacheManager.m
* Framework/Pantomime/CWPOP3CacheManager.m
check for ftruncate() return values. Extended rewrite of Yavor Doganov's patch.
2014-01-12: Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/io.c
* remove a commented out line and comment out printf debug string
2014-01-10 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/NSData+Extensions.m
Inizialize char and throw an Exception if non-hex data is supplied.
2014-01-05 German Arias <germanandre@gmx.es>
* Framework/Pantomime/NSData+Extensions.m (-unwrapWithLimit:): Revert
last change.
2014-01-04 German Arias <germanandre@gmx.es>
* Framework/Pantomime/CWParser.m (+_parameterValueUsingLine:range:
decode:charset:): Ensure the length isn't a negative value.
2014-01-02 German Arias <germanandre@gmx.es>
* Framework/Pantomime/NSData+Extensions.m (-unwrapWithLimit:): Use
-setLength:, not -replaceBytesInRange:withBytes:length: which don't
allows read the message.
2013-12-30 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/NSData+Extensions.m
Revert patch that broke extended char decoding.
2013-11-01 Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/NSData+Extensions.m
* fix memory leak
2013-11-01 Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/CWIMAPCacheManager.m
* fix mem leak introduced with one of the last commits
* Framework/Pantomime/CWSendmail.m
* Framework/Pantomime/CWSMTP.m
* introduce a _fail method to CWSMTP private category, and
make the code similar to CWSendmail for better comparison, and
fix potential initialization of dictionary with nil object
* fix mem leak introduced in last commit to both files
* Framework/Pantomime/CWIMAPStore.m
* prevent initializing dictionary with nil object
2013-10-31 Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/CWIMAPCacheManager.m
* do not malloc( 0 or negative amount of memory)
* do not memcpy( 0 or negative amount of bytes)
* do not read( 0 or negative amount of bytes)
* little reformatting
* fixes a lot of crashers in GNUMail for me
* Framework/Pantomime/CWIMAPFolder.m
* initialize super correctly in init methods
* Framework/Pantomime/CWLocalStore.m
* remove unnecessary assignment
* Framework/Pantomime/CWPOP3CacheManager.m
* initialize super correctly in init methods
* Framework/Pantomime/CWSendmail.m
* do not autorelease too often, and line break fixes
* Framework/Pantomime/CWPart.m
* restructure init method a bit
* Framework/Pantomime/CWIMAPStore.m
* fix a couple of memory leaks
* do not try to access uninitialized pointers
* some line breaks
2013-10-24 German Arias <germanandre@gmx.es>
* Framework/Pantomime/CWParser.m (_parameterValueUsingLine:...):
Fix error when parse RFC2231 and don't assume that always are a
language specified.
2013-10-21: Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/CWDNSManager.m
* Framework/Pantomime/CWIMAPStore.m
* Framework/Pantomime/CWLocalFolder+mbox.m
* Framework/Pantomime/CWLocalStore.m
* Framework/Pantomime/CWMIMEUtility.m
* Framework/Pantomime/CWMessage.m
* Framework/Pantomime/CWParser.m
* Framework/Pantomime/CWPart.m
* Framework/Pantomime/NSData+Extensions.m
* Framework/Pantomime/NSString+Extensions.m
fix some problems reported by clang static analyzer
2013-10-20: Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/CWIMAPFolder.m
* Framework/Pantomime/CWLocalFolder.m
* Framework/Pantomime/CWLocalStore.m
* Framework/Pantomime/NSString+Extensions.m
fix format strings and other few warnings emitted by clang
* GNUmakefile
add version variables to allow make dist to create a
sane tarball
* Framework/Pantomime/CWIMAPCacheManager.h
* Framework/Pantomime/CWLocalCacheManager.h
add - (void) initInRange: (NSRange) theRange; to the header,
GNUMail is using it and otherwise whining about it
* Framework/Pantomime/CWLocalCacheManager.m
* Framework/Pantomime/CWIMAPCacheManager.m
* Framework/Pantomime/CWLocalFolder.m
get rid of some useless assignments spotty by clang static
analyzer
2013-05-26: Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/CWService.m
fix tautological compare, and fix comment
* Framework/Pantomime/CWMD5.m
use memset correctly
2013-04-27 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/CWDNSManager.h
Fix count to NSUInteger.
* Framework/Pantomime/CWFolder.[h,m]
Fix count to NSUInteger.
2013-03-04: Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/NSString+Extensions.m
make comparison work on 64 bit
* Framework/Pantomime/CWCacheManager.h
* Framework/Pantomime/CWDNSManager.h
* Framework/Pantomime/CWFolder.h
* Framework/Pantomime/CWIMAPCacheManager.[h|m]
* Framework/Pantomime/CWIMAPMessage.h
* Framework/Pantomime/CWMIMEMultipart.[h|m]
some int -> NS(U)Integer transitions
* Framework/Pantomime/CWIMAPMessage.h
* Framework/Pantomime/CWIMAPMessage.m
* Framework/Pantomime/CWLocalCacheManager.m
some transitions missed
2013-02-24: Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/CWIMAPCacheManager.m
* Framework/Pantomime/CWLocalCacheManager.m
* Framework/Pantomime/CWMessage.m
* Framework/Pantomime/CWPOP3Folder.m
* Framework/Pantomime/CWPart.m
* Framework/Pantomime/CWService.m
* Fix warnings found with clang
2012-08-15: Sebastian Reitenbach <sebastia@l00-bugdead-prods.de>
* Framework/Pantomime/io.c
include missing header
2012-05-21 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/CWDNSManager.m
Fix warning.
2012-04-13 Riccardo Mottola <rm@gnu.org>
* Framework/Pantomime/CWDNSManager.m
Use res_ninit() on NetBSD to fix long-standing incompatibility
2011-06-04 German Arias <german@xelalug.org>
* Framework/Pantomime/NSString+Extensions.m: Removed GNUstepBase/
GSCategories.h and added GNUstepBase/Additions.h.
2011-06-01 German Arias <german@xelalug.org>
* GNA: Initial repository at gna.org.

5072
Pantomime-1.2.2/ChangeLog.1
View File

File diff suppressed because it is too large Load Diff

24
Pantomime-1.2.2/Documentation/AUTHORS
Unescape Escape View File

@ -0,0 +1,24 @@
Ludovic Marcotte <ludovic@Sophos.ca>
====================================
- main developer
Jonathan B. Leffert <jonathan@leffert.net>
==========================================
- some methods in the NSString category
Alexander Malmberg <alexander@malmberg.org>
============================================
- some bug fixes and enhanced support of qp and base64
Ujwal S. Sathyam <ujwal@setlurgroup.com>
========================================
- frequent contributor
- contributor on the maildir code
Riccardo Mottola <rm@gnu.org>
=============================
- portability and bug fixing

504
Pantomime-1.2.2/Documentation/LICENSE
Unescape Escape View File

@ -0,0 +1,504 @@
GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
[This is the first released version of the Lesser GPL. It also counts
as the successor of the GNU Library Public License, version 2, hence
the version number 2.1.]
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
This license, the Lesser General Public License, applies to some
specially designated software packages--typically libraries--of the
Free Software Foundation and other authors who decide to use it. You
can use it too, but we suggest you first think carefully about whether
this license or the ordinary General Public License is the better
strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use,
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 and use pieces of
it in new free programs; and that you are informed that you can do
these things.
To protect your rights, we need to make restrictions that forbid
distributors to deny you these rights or to ask you to surrender these
rights. These restrictions translate to certain responsibilities for
you if you distribute copies of the library or if you modify it.
For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you. You must make sure that they, too, receive or can get the source
code. If you link other code with the library, you must provide
complete object files to the recipients, so that they can relink them
with the library after making changes to the library and recompiling
it. And you must show them these terms so they know their rights.
We protect your rights with a two-step method: (1) we copyright the
library, and (2) we offer you this license, which gives you legal
permission to copy, distribute and/or modify the library.
To protect each distributor, we want to make it very clear that
there is no warranty for the free library. Also, if the library is
modified by someone else and passed on, the recipients should know
that what they have is not the original version, so that the original
author's reputation will not be affected by problems that might be
introduced by others.
Finally, software patents pose a constant threat to the existence of
any free program. We wish to make sure that a company cannot
effectively restrict the users of a free program by obtaining a
restrictive license from a patent holder. Therefore, we insist that
any patent license obtained for a version of the library must be
consistent with the full freedom of use specified in this license.
Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License. This license, the GNU Lesser
General Public License, applies to certain designated libraries, and
is quite different from the ordinary General Public License. We use
this license for certain libraries in order to permit linking those
libraries into non-free programs.
When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library. The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom. The Lesser General
Public License permits more lax criteria for linking other code with
the library.
We call this license the "Lesser" General Public License because it
does Less to protect the user's freedom than the ordinary General
Public License. It also provides other free software developers Less
of an advantage over competing non-free programs. These disadvantages
are the reason we use the ordinary General Public License for many
libraries. However, the Lesser license provides advantages in certain
special circumstances.
For example, on rare occasions, there may be a special need to
encourage the widest possible use of a certain library, so that it becomes
a de-facto standard. To achieve this, non-free programs must be
allowed to use the library. A more frequent case is that a free
library does the same job as widely used non-free libraries. In this
case, there is little to gain by limiting the free library to free
software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free
programs enables a greater number of people to use a large body of
free software. For example, permission to use the GNU C Library in
non-free programs enables many more people to use the whole GNU
operating system, as well as its variant, the GNU/Linux operating
system.
Although the Lesser General Public License is Less protective of the
users' freedom, it does ensure that the user of a program that is
linked with the Library has the freedom and the wherewithal to run
that program using a modified version of the Library.
The precise terms and conditions for copying, distribution and
modification follow. Pay close attention to the difference between a
"work based on the library" and a "work that uses the library". The
former contains code derived from the library, whereas the latter must
be combined with the library in order to run.
GNU LESSER GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library or other
program which contains a notice placed by the copyright holder or
other authorized party saying it may be distributed under the terms of
this Lesser General Public License (also called "this License").
Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language. (Hereinafter, translation is
included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, 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 library.
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running a program using the Library is not restricted, and output from
such a program is covered only if its contents constitute a work based
on the Library (independent of the use of the Library in a tool for
writing it). Whether that is true depends on what the Library does
and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's
complete 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 distribute a copy of this License along with the
Library.
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 Library or any portion
of it, thus forming a work based on the Library, 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) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices
stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no
charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a
table of data to be supplied by an application program that uses
the facility, other than as an argument passed when the facility
is invoked, then you must make a good faith effort to ensure that,
in the event an application does not supply such function or
table, the facility still operates, and performs whatever part of
its purpose remains meaningful.
(For example, a function in a library to compute square roots has
a purpose that is entirely well-defined independent of the
application. Therefore, Subsection 2d requires that any
application-supplied function or table used by this function must
be optional: if the application does not supply it, the square
root function must still compute square roots.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Library,
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 Library, 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 Library.
In addition, mere aggregation of another work not based on the Library
with the Library (or with a work based on the Library) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library. To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or
derivative of it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you 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.
If distribution of 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 satisfies the requirement to
distribute the source code, even though third parties are not
compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at
least three years, to give the same user the materials
specified in Subsection 6a, above, for a charge no more
than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be 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.
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
library, provided that the separate distribution of the work based on
the Library and of the other library facilities is otherwise
permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work
based on the Library, uncombined with any other library
facilities. This must be distributed under the terms of the
Sections above.
b) Give prominent notice with the combined library of the fact
that part of it is a work based on the Library, and explaining
where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or distribute
the Library except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense, link with, or
distribute the Library 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.
9. 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 Library or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Library (or any work based on the
Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
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 with
this License.
11. 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 Library at all. For example, if a patent
license would not permit royalty-free redistribution of the Library 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 Library.
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.
12. If the distribution and/or use of the Library is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Library 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.
13. The Free Software Foundation may publish revised and/or new
versions of the Lesser 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 Library
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 Library does not specify a
license version number, you may choose any version ever published by
the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
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
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE LIBRARY "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
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. 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 LIBRARY 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
LIBRARY (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 LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest
possible use to the public, we recommend making it free software that
everyone can redistribute and change. You can do so by permitting
redistribution under these terms (or, alternatively, under the terms of the
ordinary General Public License).
To apply these terms, attach the following notices to the library. 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 library's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library 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
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the library, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the
library `Frob' (a library for tweaking knobs) written by James Random Hacker.
<signature of Ty Coon>, 1 April 1990
Ty Coon, President of Vice
That's all there is to it!

69
Pantomime-1.2.2/Documentation/README
Unescape Escape View File

@ -0,0 +1,69 @@
Pantomime v1.2.0
===============================================================================
Compiling Pantomime for GNUstep
===============================================================================
To try Pantomime, your first need to install GNUstep. You can get GNUstep at:
http://www.gnustep.org
Be sure to fully read and understand the GNUstep installation procedure. You
can read a comprehensive guide on how to install GNUstep on Unix systems here:
http://documents.made-it.com/GNUstep/Build/
Once you have installed GNUstep, you can compile Pantomime.
To compile and install it:
cd Pantomime
make
make install
If you are using RedHat 9 or Fedora, you might have to define the
ADDITIONAL_OBJCFLAGS environment variable, like this:
export ADDITIONAL_OBJCFLAGS="-I/usr/kerberos/include"
in order to include the Kerberos headers during compilation (since
your OpenSSL installation requires them).
Compiling Pantomime for Apple Mac OS X
===============================================================================
In order to compile Pantomime under OS X, you first need to install Apple's
developer tools. You can get them at:
http://developer.apple.com/tools/
Once you've downloaded and installed the developer tools, open Xcode.
Once Xcode is started, open the Pantomime's project file (Pantomime.xcode).
To compile it, choose the "Build" menu item from the "Build" menu. This will create
a "Pantomime.framework" directory inside the Pantomime's build directory. You can
safely move this framework where you want, or simply add it to your application
from Xcode (Project->Add Frameworks...).
Using Pantomime in your application
===============================================================================
Under GNUstep, you must add the following line to your GNUmakefile:
ADDITIONAL_LDFLAGS = -lPantomime
Under Apple Mac OS X, you must add the following compiler flag:
-DMACOSX
Otherwise, you'll get errors when compiling your application.
===============================================================================
Author: Ludovic Marcotte (ludovic@Sophos.ca)
The name "Pantomime" was proposed by Jay Kominek.

507
Pantomime-1.2.2/Documentation/RFC/rfc1870.txt
Unescape Escape View File

@ -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]

1291
Pantomime-1.2.2/Documentation/RFC/rfc1939.txt
View File

File diff suppressed because it is too large Load Diff

1739
Pantomime-1.2.2/Documentation/RFC/rfc2045.txt
View File

File diff suppressed because it is too large Load Diff

2467
Pantomime-1.2.2/Documentation/RFC/rfc2046.txt
View File

File diff suppressed because it is too large Load Diff

843
Pantomime-1.2.2/Documentation/RFC/rfc2047.txt
Unescape Escape View File

@ -0,0 +1,843 @@
Network Working Group K. Moore
Request for Comments: 2047 University of Tennessee
Obsoletes: 1521, 1522, 1590 November 1996
Category: Standards Track
MIME (Multipurpose Internet Mail Extensions) Part Three:
Message Header Extensions for Non-ASCII Text
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
STD 11, RFC 822, defines a message representation protocol specifying
considerable detail about US-ASCII message headers, and leaves the
message content, or message body, as flat US-ASCII text. This set of
documents, collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other than US-ASCII,
(2) an extensible set of different formats for non-textual message
bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than US-ASCII.
These documents are based on earlier work documented in RFC 934, STD
11, and RFC 1049, but extends and revises them. Because RFC 822 said
so little about message bodies, these documents are largely
orthogonal to (rather than a revision of) RFC 822.
This particular document is the third document in the series. It
describes extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields.
Moore Standards Track [Page 1]
RFC 2047 Message Header Extensions November 1996
Other documents in this series include:
+ RFC 2045, which specifies the various headers used to describe
the structure of MIME messages.
+ RFC 2046, which defines the general structure of the MIME media
typing system and defines an initial set of media types,
+ RFC 2048, which specifies various IANA registration procedures
for MIME-related facilities, and
+ RFC 2049, which describes MIME conformance criteria and
provides some illustrative examples of MIME message formats,
acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which
themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
2049 describes differences and changes from previous versions.
1. Introduction
RFC 2045 describes a mechanism for denoting textual body parts which
are coded in various character sets, as well as methods for encoding
such body parts as sequences of printable US-ASCII characters. This
memo describes similar techniques to allow the encoding of non-ASCII
text in various portions of a RFC 822 [2] message header, in a manner
which is unlikely to confuse existing message handling software.
Like the encoding techniques described in RFC 2045, the techniques
outlined here were designed to allow the use of non-ASCII characters
in message headers in a way which is unlikely to be disturbed by the
quirks of existing Internet mail handling programs. In particular,
some mail relaying programs are known to (a) delete some message
header fields while retaining others, (b) rearrange the order of
addresses in To or Cc fields, (c) rearrange the (vertical) order of
header fields, and/or (d) "wrap" message headers at different places
than those in the original message. In addition, some mail reading
programs are known to have difficulty correctly parsing message
headers which, while legal according to RFC 822, make use of
backslash-quoting to "hide" special characters such as "<", ",", or
":", or which exploit other infrequently-used features of that
specification.
While it is unfortunate that these programs do not correctly
interpret RFC 822 headers, to "break" these programs would cause
severe operational problems for the Internet mail system. The
extensions described in this memo therefore do not rely on little-
used features of RFC 822.
Moore Standards Track [Page 2]
RFC 2047 Message Header Extensions November 1996
Instead, certain sequences of "ordinary" printable ASCII characters
(known as "encoded-words") are reserved for use as encoded data. The
syntax of encoded-words is such that they are unlikely to
"accidentally" appear as normal text in message headers.
Furthermore, the characters used in encoded-words are restricted to
those which do not have special meanings in the context in which the
encoded-word appears.
Generally, an "encoded-word" is a sequence of printable ASCII
characters that begins with "=?", ends with "?=", and has two "?"s in
between. It specifies a character set and an encoding method, and
also includes the original text encoded as graphic ASCII characters,
according to the rules for that encoding method.
A mail composer that implements this specification will provide a
means of inputting non-ASCII text in header fields, but will
translate these fields (or appropriate portions of these fields) into
encoded-words before inserting them into the message header.
A mail reader that implements this specification will recognize
encoded-words when they appear in certain portions of the message
header. Instead of displaying the encoded-word "as is", it will
reverse the encoding and display the original text in the designated
character set.
NOTES
This memo relies heavily on notation and terms defined RFC 822 and
RFC 2045. In particular, the syntax for the ABNF used in this memo
is defined in RFC 822, as well as many of the terminal or nonterminal
symbols from RFC 822 are used in the grammar for the header
extensions defined here. Among the symbols defined in RFC 822 and
referenced in this memo are: 'addr-spec', 'atom', 'CHAR', 'comment',
'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair'.
'quoted-string', 'SPACE', and 'word'. Successful implementation of
this protocol extension requires careful attention to the RFC 822
definitions of these terms.
When the term "ASCII" appears in this memo, it refers to the "7-Bit
American Standard Code for Information Interchange", ANSI X3.4-1986.
The MIME charset name for this character set is "US-ASCII". When not
specifically referring to the MIME charset name, this document uses
the term "ASCII", both for brevity and for consistency with RFC 822.
However, implementors are warned that the character set name must be
spelled "US-ASCII" in MIME message and body part headers.
Moore Standards Track [Page 3]
RFC 2047 Message Header Extensions November 1996
This memo specifies a protocol for the representation of non-ASCII
text in message headers. It specifically DOES NOT define any
translation between "8-bit headers" and pure ASCII headers, nor is
any such translation assumed to be possible.
2. Syntax of encoded-words
An 'encoded-word' is defined by the following ABNF grammar. The
notation of RFC 822 is used, with the exception that white space
characters MUST NOT appear between components of an 'encoded-word'.
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
charset = token ; see section 3
encoding = token ; see section 4
token = 1*<Any CHAR except SPACE, CTLs, and especials>
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
encoded-text = 1*<Any printable ASCII character other than "?"
or SPACE>
; (but see "Use of encoded-words in message
; headers", section 5)
Both 'encoding' and 'charset' names are case-independent. Thus the
charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
encoding named "Q" may be spelled either "Q" or "q".
An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.
While there is no limit to the length of a multiple-line header
field, each line of a header field that contains one or more
'encoded-word's is limited to 76 characters.
The length restrictions are included both to ease interoperability
through internetwork mail gateways, and to impose a limit on the
amount of lookahead a header parser must employ (while looking for a
final ?= delimiter) before it can decide whether a token is an
"encoded-word" or something else.
Moore Standards Track [Page 4]
RFC 2047 Message Header Extensions November 1996
IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's
by an RFC 822 parser. As a consequence, unencoded white space
characters (such as SPACE and HTAB) are FORBIDDEN within an
'encoded-word'. For example, the character sequence
=?iso-8859-1?q?this is some text?=
would be parsed as four 'atom's, rather than as a single 'atom' (by
an RFC 822 parser) or 'encoded-word' (by a parser which understands
'encoded-words'). The correct way to encode the string "this is some
text" is to encode the SPACE characters as well, e.g.
=?iso-8859-1?q?this=20is=20some=20text?=
The characters which may appear in 'encoded-text' are further
restricted by the rules in section 5.
3. Character sets
The 'charset' portion of an 'encoded-word' specifies the character
set associated with the unencoded text. A 'charset' can be any of
the character set names allowed in an MIME "charset" parameter of a
"text/plain" body part, or any character set name registered with
IANA for use with the MIME text/plain content-type.
Some character sets use code-switching techniques to switch between
"ASCII mode" and other modes. If unencoded text in an 'encoded-word'
contains a sequence which causes the charset interpreter to switch
out of ASCII mode, it MUST contain additional control codes such that
ASCII mode is again selected at the end of the 'encoded-word'. (This
rule applies separately to each 'encoded-word', including adjacent
'encoded-word's within a single header field.)
When there is a possibility of using more than one character set to
represent the text in an 'encoded-word', and in the absence of
private agreements between sender and recipients of a message, it is
recommended that members of the ISO-8859-* series be used in
preference to other character sets.
4. Encodings
Initially, the legal values for "encoding" are "Q" and "B". These
encodings are described below. The "Q" encoding is recommended for
use when most of the characters to be encoded are in the ASCII
character set; otherwise, the "B" encoding should be used.
Nevertheless, a mail reader which claims to recognize 'encoded-word's
MUST be able to accept either encoding for any character set which it
supports.
Moore Standards Track [Page 5]
RFC 2047 Message Header Extensions November 1996
Only a subset of the printable ASCII characters may be used in
'encoded-text'. Space and tab characters are not allowed, so that
the beginning and end of an 'encoded-word' are obvious. The "?"
character is used within an 'encoded-word' to separate the various
portions of the 'encoded-word' from one another, and thus cannot
appear in the 'encoded-text' portion. Other characters are also
illegal in certain contexts. For example, an 'encoded-word' in a
'phrase' preceding an address in a From header field may not contain
any of the "specials" defined in RFC 822. Finally, certain other
characters are disallowed in some contexts, to ensure reliability for
messages that pass through internetwork mail gateways.
The "B" encoding automatically meets these requirements. The "Q"
encoding allows a wide range of printable characters to be used in
non-critical locations in the message header (e.g., Subject), with
fewer characters available for use in other locations.
4.1. The "B" encoding
The "B" encoding is identical to the "BASE64" encoding defined by RFC
2045.
4.2. The "Q" encoding
The "Q" encoding is similar to the "Quoted-Printable" content-
transfer-encoding defined in RFC 2045. It is designed to allow text
containing mostly ASCII characters to be decipherable on an ASCII
terminal without decoding.
(1) Any 8-bit value may be represented by a "=" followed by two
hexadecimal digits. For example, if the character set in use
were ISO-8859-1, the "=" character would thus be encoded as
"=3D", and a SPACE by "=20". (Upper case should be used for
hexadecimal digits "A" through "F".)
(2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
represented as "_" (underscore, ASCII 95.). (This character may
not pass through some internetwork mail gateways, but its use
will greatly enhance readability of "Q" encoded data with mail
readers that do not support this encoding.) Note that the "_"
always represents hexadecimal 20, even if the SPACE character
occupies a different code position in the character set in use.
(3) 8-bit values which correspond to printable ASCII characters other
than "=", "?", and "_" (underscore), MAY be represented as those
characters. (But see section 5 for restrictions.) In
particular, SPACE and TAB MUST NOT be represented as themselves
within encoded words.
Moore Standards Track [Page 6]
RFC 2047 Message Header Extensions November 1996
5. Use of encoded-words in message headers
An 'encoded-word' may appear in a message header or body part header
according to the following rules:
(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822)
in any Subject or Comments header field, any extension message
header field, or any MIME body part field for which the field body
is defined as '*text'. An 'encoded-word' may also appear in any
user-defined ("X-") message or body part header field.
Ordinary ASCII text and 'encoded-word's may appear together in the
same header field. However, an 'encoded-word' that appears in a
header field defined as '*text' MUST be separated from any adjacent
'encoded-word' or 'text' by 'linear-white-space'.
(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and
")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC
822 ABNF definition for 'comment' is amended as follows:
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT
contain the characters "(", ")" or "
'encoded-word' that appears in a 'comment' MUST be separated from
any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.
It is important to note that 'comment's are only recognized inside
"structured" field bodies. In fields whose bodies are defined as
'*text', "(" and ")" are treated as ordinary characters rather than
comment delimiters, and rule (1) of this section applies. (See RFC
822, sections 3.1.2 and 3.1.3)
(3) As a replacement for a 'word' entity within a 'phrase', for example,
one that precedes an address in a From, To, or Cc header. The ABNF
definition for 'phrase' from RFC 822 thus becomes:
phrase = 1*( encoded-word / word )
In this case the set of characters that may be used in a "Q"-encoded
'encoded-word' is restricted to: <upper and lower case ASCII
letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_"
(underscore, ASCII 95.)>. An 'encoded-word' that appears within a
'phrase' MUST be separated from any adjacent 'word', 'text' or
'special' by 'linear-white-space'.
Moore Standards Track [Page 7]
RFC 2047 Message Header Extensions November 1996
These are the ONLY locations where an 'encoded-word' may appear. In
particular:
+ An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.
+ An 'encoded-word' MUST NOT appear within a 'quoted-string'.
+ An 'encoded-word' MUST NOT be used in a Received header field.
+ An 'encoded-word' MUST NOT be used in parameter of a MIME
Content-Type or Content-Disposition field, or in any structured
field body except within a 'comment' or 'phrase'.
The 'encoded-text' in an 'encoded-word' must be self-contained;
'encoded-text' MUST NOT be continued from one 'encoded-word' to
another. This implies that the 'encoded-text' portion of a "B"
'encoded-word' will be a multiple of 4 characters long; for a "Q"
'encoded-word', any "=" character that appears in the 'encoded-text'
portion will be followed by two hexadecimal characters.
Each 'encoded-word' MUST encode an integral number of octets. The
'encoded-text' in each 'encoded-word' must be well-formed according
to the encoding specified; the 'encoded-text' may not be continued in
the next 'encoded-word'. (For example, "=?charset?Q?=?=
=?charset?Q?AB?=" would be illegal, because the two hex digits "AB"
must follow the "=" in the same 'encoded-word'.)
Each 'encoded-word' MUST represent an integral number of characters.
A multi-octet character may not be split across adjacent 'encoded-
word's.
Only printable and white space character data should be encoded using
this scheme. However, since these encoding schemes allow the
encoding of arbitrary octet values, mail readers that implement this
decoding should also ensure that display of the decoded data on the
recipient's terminal will not cause unwanted side-effects.
Use of these methods to encode non-textual data (e.g., pictures or
sounds) is not defined by this memo. Use of 'encoded-word's to
represent strings of purely ASCII characters is allowed, but
discouraged. In rare cases it may be necessary to encode ordinary
text that looks like an 'encoded-word'.