[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 4096

Network Working Group                                         C. Malamud
Internet-Draft                                       Memory Palace Press
Expires: August 23, 2005                               February 19, 2005


        Labels in Subject Headers Considered Ineffective At Best
                     draft-malamud-subject-line-02

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 23, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This Internet-Draft discusses policies that require certain labels to
   be inserted in the "Subject:" header of a mail message.  Such
   policies are difficult to specify accurately while remaining
   compliant with key RFCs and are likely to be ineffective at best.
   This Internet-Draft discusses an alternate, standards-compliant
   approach that is significantly simpler to specify and is somewhat
   less likely to be ineffective.



Malamud                  Expires August 23, 2005                [Page 1]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119].

Table of Contents

   1.   Labeling Requirements  . . . . . . . . . . . . . . . . . . .   3
   2.   Subject Line Encoding  . . . . . . . . . . . . . . . . . . .   4
   3.   Implementing a Labeling Requirement  . . . . . . . . . . . .   6
   4.   Subjects are For Humans, Not Labels  . . . . . . . . . . . .   7
   5.   Solicitation Class Keywords  . . . . . . . . . . . . . . . .   8
   6.   Recommendations  . . . . . . . . . . . . . . . . . . . . . .   9
   7.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  10
   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  10
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  10
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1   Normative References . . . . . . . . . . . . . . . . . .  10
     10.2   Informative References . . . . . . . . . . . . . . . . .  11
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  13
   A.   Intended Status and Discussion (TO BE REMOVED UPON
        PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . .  13
   B.   Changes From Previous Versions (TO BE REMOVED UPON
        PUBLICATION) . . . . . . . . . . . . . . . . . . . . . . . .  13
        Intellectual Property and Copyright Statements . . . . . . .  14

























Malamud                  Expires August 23, 2005                [Page 2]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


1.  Labeling Requirements

   The U.S.  Congress has signed and the U.S.  President has signed the
   Controlling the Assault of Non-Solicited Pornography and Marketing
   Act of 2003 (CAN-SPAM Act of 2003) [US], which requires in Section
   11(2) that the Federal Trade Commission:

      "[transmit to the Congress] a report, within 18 months after the
      date of enactment of this Act, that sets forth a plan for
      requiring commercial electronic mail to be identifiable from its
      subject line, by means of compliance with Internet Engineering
      Task Force Standards, the use of the characters "ADV" in the
      subject line, or other comparable identifier, or an explanation of
      any concerns the Commission has that cause the Commission to
      recommend against this plan."

   The Korean Government has enacted the Act on Promotion of Information
   and Communication and Communications Network Utilization and
   Information Protection of 2001 .  As explained by the Korea
   Information Security Agency, the government body with enforcement
   authority under the act, Korean law makes it mandatory as of June,
   2003 to:

      "include the '@' (at) symbol in the title portion (right-side) of
      any commercial e-mail address, in addition to the words
      '(Advertisement)' or '(Adult Advertisement)' as applicable.  The
      inclusion of the '@' symbol, as proposed by the Korean government,
      is intended to indicate an e-mail advertisement.  Because e-mails
      easily cross international borders, the '@' symbol may be used as
      a symbol for filtering advertisement mails."[KISA]

   The State of Colorado has enacted the Colorado Junk Email Law, which
   states:

      "It shall be a violation of this article for any person that sends
      an unsolicited commercial electronic mail message to fail to use
      the exact characters "ADV:" (the capital letters "A", "D", and
      "V", in that order, followed immediately by a colon) as the first
      four characters in the subject line of an unsolicited commercial
      electronic mail message." [Colorado]

   The Rules of Professional Conduct of the Florida Bar require, in Rule
   4-7.6(c)(3) states:

      "A lawyer shall not send, or knowingly permit to be sent, on the
      lawyer's behalf or on behalf of the lawyer's firm or partner, an
      associate, or any other lawyer affiliated with the lawyer or the
      lawyer's firm, an unsolicited electronic mail communication



Malamud                  Expires August 23, 2005                [Page 3]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


      directly or indirectly to a prospective client for the purpose of
      obtaining professional employment unless ...  the subject line of
      the communication states 'legal advertisement.'" [Florida]

   A subject line that complies with the above requirements might read
   as follows:

        Subject: ADV: @ (Advertisement) legal advertisement

   A more comprehensive survey of applicable laws would no doubt
   lengthen the above example considerably.

2.  Subject Line Encoding

   The basic definition of the "Subject:" of an electronic mail message
   is contained in [RFC2822].  The the normative requirements that apply
   to all headers are:

   o  The maximum length of the header field is 998 characters.
   o  Each line must be no longer than 78 characters.

   A multi-line subject field is indicated by the presence of a carriage
   return and white space as follows:

        Subject: This
         is a test

   On the subject of the three unstructured fields ( "Subject:",
   "Comments:", and "Keywords:"), the standard indicates that these are
   "intended to have only human-readable content with information about
   the message."  In addition, on the specific subject of the "Subject:"
   field, the standard states:

      The "Subject:" field is the most common and contains a short
      string identifying the topic of the message.  When used in a
      reply, the field body MAY start with the string "Re: " (from the
      Latin "res", in the matter of) followed by the contents of the
      "Subject:" field body of the original message.  If this is done,
      only one instance of the literal string "Re: " ought to be used
      since use of other strings or more than one instance can lead to
      undesirable consequences.

   Further guidance on the structure of the "Subject:" field is
   contained in [RFC2047], which species the mechanisms for character
   set encoding in mail headers.  [RFC2978] specifies a mechanism for
   registering different character sets with the [IANA].

   In addition to choosing a character set, [RFC2047] uses two



Malamud                  Expires August 23, 2005                [Page 4]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


   algorithms, known as "Base64 Encoding" and "Quoted Printable", which
   are two different methods for encoding characters that fall outside
   of the basic 7-bit ASCII requirements that are specified in the core
   electronic mail standards.

   An encoded piece of text thus consists of the following components:

   o  The string "=?", which signifies the beginning of encoded text.
   o  A valid character set indicator.
   o  The string "?", which is a delimiter.
   o  The string "b" if "Base64 Encoding" is used or the string "q" if
      "Quoted Printable" encoding is used.
   o  The string "?", which is a delimiter.
   o  The text, which has been properly encoded.
   o  The string "?=", which signifies the ending of the encoded text.

   A simple example would be to use the popular [8859-1] character set,
   which has accents and other characters not found in the ASCII
   character set:

   o  "Subject: This is an ADV:" is an unencoded header.
   o  "Subject: =?iso-8859-1?b?VGhpcyBpcyBhbiBBRFY6?=" is encoded using
      Base64.
   o  "Subject: =?iso-8859-1?q?This=20is=20an=20ADV:?=" is encoded using
      Quoted Printable.
   o  "Subject: =?iso-8859-1?q?This=20is=20an=20=41=44=56=3A?=" is also
      encoded using Quoted Printable, but instead the last four
      characters are encoded with their hexadecimal representations.

   Note that both character set and encoding indicators are case
   insensitive.  Additional complexity can be introduced by appending a
   language specification to the character set indication, as specified
   in [RFC2231] and [RFC3066].  This language specification consists of
   the string "*" followed by a valid language indicator.  For example,
   "US-ASCII*EN" indicates the "US-ASCII" character set and the English
   language.

   When a message is read, the "Subject:" field is decoded, with
   appropriate characters from the character set displayed to the user.
   Section 7 (Conformance) of [RFC2047] specifies that a conforming mail
   reading program must:

      "The program must be able to display the unencoded text if the
      character set is "US-ASCII".  For the ISO-8859-* character sets,
      the mail reading program must at least be able to display the
      characters which are also in the ASCII set."

   However, there is no requirement for every system to have every



Malamud                  Expires August 23, 2005                [Page 5]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


   character set, and mail readers that are unable to display a
   particular set of characters resort to a variety of strategies,
   including silently ignoring the unknown text, or generating an error
   or warning message.

   Two characteristics of many common Message User Agents (MUAs) (e.g.,
   mail readers) are worth noting:

   o  Although the subject line is in theory of unlimited lengths, many
      mail readers only show the reader only the first few dozen
      characters.
   o  Electronic mail is often transmitted through gateways, reaching
      pagers or cell phones with SMS capability.  Those systems
      typically require short subject lines.

3.  Implementing a Labeling Requirement

   In this section, we posit a hypothetical situation with two key
   players:

   o  John Doe[Doe] is an attorney at the firm of Dewey, Cheatem & Howe,
      LLC.[Stooges]
   o  The Federal Trust Commission (FTC) has been entrusted with
      implementing a recent labeling requirement promulgated by the
      Sovereign Government of Freedonia.[Duck] Specifically, the
      President Firefly directed the FTC to "make sure that anybody
      spamming folks get the symbol 'SPAM:' in the subject line and or
      shoot them if you can find them."

   Based on this directive, the FTC promulgated a very simple regulation
   which read: "Please obey the law." John Doe, being a lawyer, read the
   law, and promptly proceeded to spam everybody using a fairly obvious
   loophole: he made sure his subject line was really long, and he
   shoved all the stuff like "SPAM:" and the "@" symbol and other
   verbiage near the end of the 998 allowed characters.  He was
   complying with the law, but of course, nobody saw the labels in their
   reader.

   Based on a periodic review, the FTC decided to be more specific, and
   re-promulgated their regulation as follows: "If you send SPAM, put
   'SPAM:' at the _beginning_ of the subject line."  The Freedonian FTC
   promptly received a visit from the U.S.  Ambassador to Freedonia, who
   complained that this conflicted with American requirements under the
   Marx Doctrine and was going to move the consulate to Sylvania.  The
   Ambassadeur-General du France also visited, complaining that Le
   Academie Francais now insisted on the string
   "Pate-du-Cochon-Degoutant-a-la-Facon-Hormel" on all courriel
   d'origine informatique (tr.  _e-mail_) from Freedonia.



Malamud                  Expires August 23, 2005                [Page 6]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


   The re-promulgation of the regulation was rescinded, some experts
   were called in, and a new regulation was issued: "Put it as close to
   the beginning of the subject line as you can, modulo any requirements
   by other governments."  John Doe looked at this, scratched his head,
   and applied a clever little hack, picking the ISO [8859-8] character
   set for Hebrew, and duly spelling out the letters ":" Mem Alef Pe
   Samech.

        Subject: =?iso-8859-8?q?=f1=f4=e0=ee=3a?=

   Some receivers of this message get an error message because they
   don't have Hebrew installed on their systems.  Others get some
   cryptic indicator of a missing character set, such as
   "[?iso-8859-8?]".

   The FTC called a summit of leading thinkers, and the regulation was
   amended to read "but don't use funny languages like Hebrew and
   stuff." Needless to say, the reaction from the Freedonian Jewish
   Defense League killed that proposed regulation really quickly.

   The commission continued the cycle of re-promulgation and refinement,
   but ultimately, the regulations always contained either a loophole,
   some objectionable requirements, or were simply violations of the
   relevant RFCs.

4.  Subjects are For Humans, Not Labels

   The use of an unknown character set, or of a very, very long subject
   line are just two examples of how people can try to get around
   labeling requirements.  In order to specify a regulation without
   ambiguity, it would need to be extremely complex to avoid loopholes
   such as these.

   Drafting of regulations is one issue, but there is another.  Subject
   lines are used to specify, as [RFC2822] says, a "short string
   identifying the topic of the message."

   Any regulation has to compete with the other words in the subject,
   and this mixing of purposes makes it very difficult for a machine to
   filter out messages at the direction of the user.  For example, if
   one looks for the "@" symbol, per the Korean law, checks have to be
   made that this symbol is not a legitimate part of a legitimate
   message.

   Not only do multiple labeling requirements compete with legitimate
   subject lines, there is no easy way for the sender of a legitimate
   message to effectively insert _other_ labels that indicate to the
   recipient that, although the message may have a required label, it is



Malamud                  Expires August 23, 2005                [Page 7]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


   actually a message the user might want to see based on, for example,
   a prior relationship.

   Even if one considers just the sender of the message, it is very
   difficult to specify a loophole-free way of putting a specific label
   in a specific place.  And, even if we could control what the sender
   does, it is an unfortunate fact of life that other agents may also
   alter the subject line.  For example, mailing list management
   software and even personal email filtering systems will often "munge"
   the subject line to add information such as the name of a mailing
   list, or the fact that a message comes from a certain group of
   people.  Such transformations have long been generally accepted as
   being potentially harmful,[RFC0886] and are the subject of continued
   discussion (see, e.g., [Koch]).

   The "Subject:" field is currently overloaded: it has become a handy
   place for a variety of agents to attempt to insert information.
   Because of that overloading, it is a poor location for specifying
   mandatory use of a label, since it is unlikely that label will "rise
   to the top" and become apparent to the reader of a message or even to
   the mail filtering software that examines the mail before the user.
   The difficulty of implementing subject line labeling without taking
   additional steps has been noted by several other commentators,
   including [Moore], [Lessig], and [Levine].

5.  Solicitation Class Keywords

   [RFC3865] defines the "solicitation class keyword", an arbitrary
   label which can be associated with an electronic mail message and
   transported by the ESMTP mail service as defined in [RFC2821] and
   related documents.  Solicitation class keywords are formatted like
   domain names, but reversed.  For example, the registrant of
   "example.com" might specify a particular solicitation class keyword
   such as "com.example.adv" that could be inserted in a "No-Solicit:"
   header or in a trace field.  Anybody with a domain name can specify a
   solicitation class keyword, and anybody sending a message can use any
   solicitation class keyword that has been defined by themselves or by
   others.

   This Internet-Draft argues that the "No-Solicit:" approach is either
   a superior alternative or a necessary complement to "Subject:" field
   labeling requirements because:

   o  One can specify very precisely what a label should be and where it
      should go using the "No-Solicit:" header, which is designed
      specifically for this purpose.
   o  The sender of a message can add additional solicitation class
      keywords to help distinguish the message.  For example, if the



Malamud                  Expires August 23, 2005                [Page 8]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


      "Freedonian Direct Marketing Council" wished to form a voluntary
      consortium of direct marketers who subscribe to certain practices,
      they could specify a keyword (e.g.,
      "org.example.freedonia.good..spam") and educate the public to set
      their filters to receive these types of messages.
   o  Message Transfer Agents (MTAs) may insert solicitation class
      keywords in the "received:" trace fields, thus providing
      additional tools for recipients to use for filtering messages.
   o  A recipient can also define a solicitation class keyword, a tool
      that allows them to give friends and correspondents a "pass key"
      so the recipient's mail filtering software always passes through
      messages containing that keyword.

   As can be seen, the solicitation class keyword approach is flexible
   enough to serve as a tool for government-mandated labeling and for
   other purposes as well.

   Most modern email software gives users a variety of filtering tools.
   For example, the popular Eudora program allows a user to specify the
   name of a message header, the desired match (e.g., a wild card or
   regular expression, or simply a phrase to match), and an action to
   take (e.g., moving the message to a particular folder, sounding an
   alarm, or even deleting messages with harmful content such as viruses
   automatically).  There is one popular email reader which only allows
   filtering on selected fields, such as "To:", "From:",  or "Subject:",
   but that program is the exception to the rule.

   In summary, for senders and receivers of email, use of the
   "No-Solicit:" mechanism would be simply to understand and use.  For
   policy makers, it would be extremely simply to specify the format and
   placement of the solicitation class keyword.  (Needless to say, the
   issue of how to define what classes of messages are subject to such a
   requirement and how to enforce it are beyond the scope of this
   discussion.)

6.  Recommendations

   This document makes two recommendations:

   1.  There is widespread skepticism in the technical community that
       labels of any sort will be effective and such labels should
       probably be avoided as ineffective at best.
   2.  Despite the widespread skepticism expressed in point 1, over 36
       states in the U.S.  and 27 countries have passed anti-spam
       measures, many of which require labels.[Sorkin]  If such labels
       are to be used, despite the widespread skepticism expressed in
       point 1, there is a fairly broad consensus in the technical
       community that such labels SHOULD NOT be put in the "Subject:"



Malamud                  Expires August 23, 2005                [Page 9]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


       field and should go in a designated header field.

7.  Acknowledgements

   The author would like to thank the following for their helpful
   suggestions and reviews of this draft: Harald Alvestrand, Ted Hardie,
   Scott Hollenbeck, Peter Koch, and Bruce Lilly.

8.  Security Considerations

   The use of labels in the "Subject:" field gives users and policy
   makers an unwarranted illusion that certain classes of messages will
   be "flagged" correctly by the MUA of the recipient.  The difficulty
   in specifying requirements for labels in the "Subject:" field in a
   precise, unambiguous manner makes it difficult for the MUA to
   systematically identify messages that are labeled, leading to both
   false positive and false negative indications.

   In addition, conflicting labeling requirements by policy makers, as
   well as other current practices that use the "Subject:" for a variety
   of purposes make that field "overloaded."  In order to meet these
   conflicting requirements, software designers and bulk mail senders
   resort to a variety of tactics, some of which may violate fundamental
   requirements of the mail standards, such as the practice of an
   intermediate MTA inserting various labels into the "Subject:" field.
   Such practices increase the likelihood of non-compliant mail messages
   and thus threaten interoperability between implementations.

9.  IANA Considerations

   There are no IANA Considerations in this document.

10.  References

10.1  Normative References

   [IANA]     IANA, "Registry of Official Names for Character Sets That
              May Be Used on the Internet", February 2004,
              <http://www.iana.org/assignments/character-sets>.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.




Malamud                  Expires August 23, 2005               [Page 10]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", RFC 2231, November 1997.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [RFC2978]  Freed, N. and J. Postel, "IANA Charset Registration
              Procedures", BCP 19, RFC 2978, October 2000.

   [RFC3066]  Alvestrand, H., "Tags for the Identification of
              Languages", BCP 47, RFC 3066, January 2001.

   [RFC3865]  Malamud, C., "A No Soliciting Simple Mail Transfer
              Protocol (SMTP) Service Extension", RFC 3865, September
              2004.

10.2  Informative References

   [8859-1]   International Organization for Standardization,
              "Information technology - 8-bit single byte coded graphic
              - character sets - Part 1: Latin alphabet No. 1,
              JTC1/SC2", ISO Standard 8859-1, 1987.

   [8859-8]   International Organization for Standardization,
              "Information Processing - 8-bit Single-Byte Coded Graphic
              Character Sets, Part 8: Latin/Hebrew alphabet",
              ISO Standard 8859-8, 1988.

   [Colorado]
              Sixty-Second General Assembly of the State of Colorado,
              "Colorado Junk Email Law", House Bill 1309, June 2000,
              <http://www.spamlaws.com/state/co.html>.

   [Doe]      Frank Capra (Director), "Meet John Doe", IMDB Movie
              No. 0033891, 1941, <http://us.imdb.com/title/tt0033891/>.

   [Duck]     The Mark Brothers, "Duck Soup", IMDB Movie No. 0023969,
              1933, <http://us.imdb.com/title/tt0023969/>.

   [Florida]  The Florida Bar, "Rules of Professional Conduct", 2005,
              <http://www.flabar.org/divexe/rrtfb.nsf/WContents?OpenView



Malamud                  Expires August 23, 2005               [Page 11]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


              &Start=1&Count=30&Expand=4.8#4.8>.

   [KISA]     Korea Information Security Agency, "Korea Spam Response
              Center -- Legislation for Anti-Spam Regulations: Mandatory
              Indication of Advertisement", 2003,
              <http://www.spamcop.or.kr/eng/m_2.html>.

   [Koch]     Koch, P., "Subject: [tags] Considered Harmful",
              Internet-Draft draft-koch-subject-tags-considered-00,
              November 2004.

   [Korea]    National Assembly of the Republic of Korea, "Act on
              Promotion of Information and Communication and
              Communications Network Utilization and Information
              Protection of 2001", 2001,
              <http://icic.sppo.go.kr/english_d_1.htm>.

   [Lessig]   Lessig, L., "How to unspam the Internet", The
              Philadelphia Inquirer, May 2003,
              <http://www.philly.com/mld/inquirer/news/editorial/5778539
              .htm?1c>.

   [Levine]   Levine, J., "Comments In the Matter of: REPORT TO CONGRESS
              PURSUANT TO CAN-SPAM ACT", Federal Trade Commission,
              Matter No. PO44405, February 2004,
              <http://www.ftc.gov/reports/dneregistry/xscripts/dne040226
              pm.pdf>.

   [Moore]    Moore, K., "Individual Comment of Dr. Keith Moore Re:
              Label for E-mail Messages", Federal Trade Commission of
              the U.S., NPRM Comment RIN 3084-AA96, February 2004,
              <http://www.ftc.gov/os/comments/adultemaillabeling/040216m
              oore.pdf>.

   [RFC0886]  Rose, M., "Proposed standard for message header munging",
              RFC 886, December 1983.

   [Sorkin]   Sorkin, D., "http://www.spamlaws.com/", 2005,
              <http://www.spamlaws.com/>.

   [Stooges]  The Three Stooges, "Heavenly Daze", IMDB Movie
              No. 0040429, 1948, <http://us.imdb.com/title/tt0040429/>.

   [US]       United States Congress, "The Controlling the Assault of
              Non-Solicited Pornography and Marketing Act of 2003
              (CAN-SPAM Act of 2003)", Public Law 108-187, 117
              STAT. 2699, 15 USC 7701, December 2003,
              <http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname



Malamud                  Expires August 23, 2005               [Page 12]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


              =108_cong_public_laws&docid=f:publ187.108.pdf>.


Author's Address

   Carl Malamud
   Memory Palace Press
   PO Box 300
   Sixes, OR  97476
   US

   Email: carl@media.org

Appendix A.  Intended Status and Discussion (TO BE REMOVED UPON
            PUBLICATION)

   This draft is being submitted as an individual submission with an
   intended publication as a an Informational RFC.  Discussion of this
   draft should take place on the <mailto:ietf-smtp@imc.org> mailing
   list (<mailto:ietf-smtp-request@imc.org> to subscribe).  The source
   and alternative transformations for this draft may be found at
   <http://trusted.resource.org/no-solicit/>.

Appendix B.  Changes From Previous Versions (TO BE REMOVED UPON
            PUBLICATION)

   The following changes were made from draft-malamud-subject-line-01 to
   draft-malamud-subject-line-02:

   o  Security considerations were added.
   o  Clarification of intended publication status.

   The following changes were made from draft-malamud-subject-line-00 to
   draft-malamud-subject-line-01:

   o  Added a concluding section containing 2 recommendations.
   o  Discussion of language identifiers per [RFC2231] added.
   o  Mention of limitations on conforming mail reader actions per
      [RFC2047], Section 7 added.
   o  Discussion of prior work on mailing list identifiers per [Koch]
      added.










Malamud                  Expires August 23, 2005               [Page 13]

Internet-Draft      Subject Line Labeling Ineffective      February 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Malamud                  Expires August 23, 2005               [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/