rfc2919.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   help to reduce internal conflicts between the administrators of the
   subdomains of large organizations.  For example, list identifiers at
   "within.com" are generated in the subdomain of "list-id.within.com".

   List-IDs not ending with ".localhost" MUST be globally unique in
   reference to all other mailing lists.

   List owners wishing to use the special "localhost" namespace for
   their list identifier SHOULD use the month and year (in the form
   MMYYYY) that they create the list identifier as a "subdomain" of the
   "localhost" namespace.  In addition, some portion of the list
   identifier MUST be a randomly generated string.  List owners
   generating such identifiers should refer to [MSGID] for further
   suggestions on generating a unique identifier, and [RFC1750] for
   suggestions on generating random numbers.  In particular, list
   identifiers that have a random component SHOULD contain a hex
   encoding of 128 bits of randomness (resulting in 32 hex characters)
   as part of the list identifier

   Thus, list identifiers such as
   <lenas-jokes.da39efc25c530ad145d41b86f7420c3b.021999.localhost> and
   <da39efc25c530ad145d41b86f7420c3b.051998.localhost> conform to these
   guidelines, while <lenas-jokes.021999.localhost> and




Chandhok & Wenger           Standards Track                     [Page 5]

RFC 2919                        List-Id                       March 2001


   <mylist.localhost> do not.  A particular list owner with several
   lists MAY choose to use the same random number subdomain when
   generating list identifiers for each of the lists.

   List-IDs ending with ".localhost" are not guaranteed to be globally
   unique.

6. Operations on List Identifiers

   There is only one operation defined for list identifiers, that of
   case insensitive equality (See Section 3.4.7., CASE INDEPENDENCE
   [RFC822]).  The sole use of a list identifier is to identify a
   mailing list, and the sole use of the List-Id header is to mark a
   particular message as belonging to that list.  The comparison
   operation MUST ignore any part of the List-Id header outside of the
   angle brackets, the MUA MAY choose to inform the user if the
   descriptive name of a mailing list changes.

7. Supporting Nested Lists

   A list that is a sublist for another list in a nested mailing list
   hierarchy MUST NOT modify the List-Id header field; however, this
   will only be possible when the nested mailing list is aware of the
   relationship between it and its "parent" mailing lists.  If a mailing
   list processor encounters a List-Id header field from any unexpected
   source it SHOULD NOT pass it through to the list.  This implies that
   mailing list processors may have to be updated to properly support
   List-Ids for nested lists.

8. Security Considerations

   There are very few new security concerns generated with this
   proposal.  Message headers are an existing standard, designed to
   easily accommodate new types.  There may be concern with headers
   being forged, but this problem is inherent in Internet e-mail, not
   specific to the header described in this document.  Further, the
   implications are relatively harmless.

   As mentioned above, mail list processors SHOULD NOT allow any user-
   originated List-Id fields to pass through to their lists, lest they
   confuse the user and have the potential to create security problems.

   On the client side, a forged list identifier may break automated
   processing.  The list identifier (in its current form) SHOULD NOT be
   used as an indication of the authenticity of the message.






Chandhok & Wenger           Standards Track                     [Page 6]

RFC 2919                        List-Id                       March 2001


9. Acknowledgements

   The numerous participants of the List-Header [LISTHEADER] and
   ListMom-Talk [LISTMOM] mailing lists contributed much to the
   formation and structure of this document.

   Grant Neufeld <[e-mail]> focused much of the early discussion,
   and thus was essential in the creation of this document.

References

   [LISTHEADER] "List-Header" Mail list. [e-mail]
                <http://www.nisto.com/listspec/mail/>
                <http://www.nisto.com/listspec/>

   [LISTMOM]    "ListMom-Talk" Mail list. [e-mail]
                <http://cgi.skyweyr.com/ListMom.Home>

   [MSGID]      J. Zawinski, M. Curtin, "Recommendations for generating
                Message IDs", Work in Progress.

   [RFC822]     Crocker, D., "Standard for the Format of ARPA Internet
                Text Messages", RFC 822, August 1982.

   [RFC1750]    Eastlake, D., Crocker S. and J. Schiller, "Randomness
                Recommendations for Security", RFC 1750, December 1994.

   [RFC2234]    Crocker, D. and P. Overell. "Augmented BNF for Syntax
                Specifications: ABNF", RFC 2234, November 1997.

   [RFC2369]    Neufeld G. and J. Baer, "The Use of URLs as Meta-Syntax
                for Core Mail List Commands and their Transport through
                Message Header Fields", RFC 2369, July 1998.

   [RFC2606]    Eastlake, 3rd, D., and S. Panitz. "Reserved Top Level
                DNS Names", BCP 32, RFC 2606, June 1999.

   [RFC2822]    Resnick, P., Editor, "Internet Message Format Standard",
                STD 11, RFC 2822, March 2001.












Chandhok & Wenger           Standards Track                     [Page 7]

RFC 2919                        List-Id                       March 2001


Authors' Addresses

   Ravinder Chandhok
   QUALCOMM, Inc.
   5775 Morehouse Drive
   San Diego, CA 92121 USA

   EMail: [e-mail]


   Geoffrey Wenger
   QUALCOMM, Inc.
   5775 Morehouse Drive
   San Diego, CA 92121 USA

   EMail: [e-mail]



































Chandhok & Wenger           Standards Track                     [Page 8]

RFC 2919                        List-Id                       March 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

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



















Chandhok & Wenger           Standards Track                     [Page 9]