idnits 2.17.1 draft-palme-newsmail-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 720 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 22 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 193: '...me time to both mail and news MUST use...' RFC 2119 keyword, line 198: '...rom news to mail SHOULD not modify the...' RFC 2119 keyword, line 200: '...rom mail to news MUST, if needed, modi...' RFC 2119 keyword, line 204: '...rom mail to news MAY transport the "Re...' RFC 2119 keyword, line 207: '...correctly, they MAY convert the "Refer...' (23 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Gateways from news to mail SHOULD not modify the "References" field. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The "Newsgroups" header SHOULD not be used in email messages, even if these messages are also sent to newsgroups or are replies to news messages. If a message arriving via email has a "Newsgroups" header, the value of this header should be ignored. The value of this header shall in particular not be interpreted either to indicate the newsgroup to which this message is also posted (use Posted-To see 5.4), or to indicate the newsgroup of the original message (use a comment in the "In-Reply-To" field instead, see 5.1). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an email client is designed to cooperate with a certain gateway from email to netnews, then messages sent only between clients of this type and gateways of this type may employ additional information, not standardized here, to improve the cooperation between them. Such additional information MUST not be specified in ways which can cause misunderstandings if the message gets to other than the specified cooperating recipients. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1997) is 9722 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 1036' is mentioned on line 215, but not defined ** Obsolete undefined reference: RFC 1036 (Obsoleted by RFC 5536, RFC 5537) -- Looks like a reference, but probably isn't: '1' on line 654 -- Looks like a reference, but probably isn't: '2' on line 656 == Unused Reference: 'MD5' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'CMD5' is defined on line 528, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1036 (Obsoleted by RFC 5536, RFC 5537) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jacob Palme 2 Internet Draft Stockholm University and KTH 3 draft-palme-newsmail-00.txt August 1997 4 Category-to-be: Proposed standard Expires: February 1998 6 Messages between Email and Netnews 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference material 18 or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 This memo provides information for the Internet community. This' memo 27 does not specify an Internet standard of any kind, since this document 28 is mainly a compilation of information taken from other RFC-s.. 29 Distribution of this memo is unlimited. 31 Abstract 33 Messages can be transported through gateways between email and netnews. 34 Combined clients for mail and netnews can submit the same message at the 35 same time to email and netnews. Many netnews clients can produce email 36 replies to the author of netnews articles. This standard specifies how 37 to handle these kinds of messages. This standard specifies three new 38 email headers: 'Posted-To', 'Group-Reply-To' and 'Personal-Reply-To'. 39 Further discussions on this memo should take place in the mailing-list 40 MAILNEWS-L@SEGATE.SUNET.SE. More info in the full text of this memo or 41 at URL http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#newsharmony. 43 Table of contents 45 1. Mailing List 46 2. Status 47 3. Introduction 48 4. Definitions 49 5. Headers in Combined and Converted Messages 50 5.1 References and In-Reply-To 51 5.2 Message-ID Header 52 5.3 "Followup-To" and "Group-Reply-To" Headers 53 5.4 "Posted-To" header 54 5.5 "Newsgroups" Header 55 5.6 "Approved" Header 56 5.7 "Subject" Header 57 5.8 "Received" and "Path" headers 58 5.9 "Control" messages 59 5.10 Other Headers 60 5.11 Headers Mandatory in Netnews but not in Email 61 5.12 Headers Optional in Netnews and not Defined in Email 62 6. Preparation of Replies to Combined Messages 63 7. Cooperating Clients and Gateways 64 8. Security considerations 65 9. Acknowledgments 66 10. References 67 11. Author's Addresses 68 Appendix A: Examples 69 Appendix B: Algorithm for Assigning Message-IDs to Messages in Gateways 70 from Email to Netnews 71 Appendix C: Example of two partially overlapping threads 73 1. Mailing List 75 Further discussion on this memo should be done through the mailing list 76 MAILNEWS-L@SEGATE.SUNET.SE. To subscribe to this list, send a message to 77 LISTSERV@SEGATE.SUNET.SE which contains the text 78 SUB MHTML 80 Archives of this list are available by anonymous ftp from 81 FTP://SEGATE.SUNET.SE in the 82 directory /lists/mailnews-l. The archives are also available by email. 83 Send a message to 84 LISTSERV@SEGATE.SUNET.SE with the text INDEX MAILNEWS-L to get a list of 85 the archive files, 86 and then a new message GET to retrieve the archive files. 88 You can also browse the archives by http from 89 HTTP://segate.sunet.se/archives/mailnews-l.html. The FTP archives are 90 better if you want to 91 download all messages, the HTTP archives are better if you want to 92 browse and find a 93 particular message only. 95 Finally, the archives from December 3, 1996 are also available in 96 searchable format from URL 97 http://www.reference.com/cgi-bin/pn/listarch?list=MAILNEWS-L@segate.sune 98 t.se 100 2. Status 102 This standard updates current email and netnews standards [RFC822], 103 [RFC1036], [RFC1123] and [MIME]. 105 3. Introduction 107 Clients which can handle both email and netnews are becoming more 108 common. Also those clients which are mainly intended for netnews often 109 provide facilities for replying by email to the author of netnews 110 articles. Messages are often gatewayed between netnews and email, for 111 example by having a mailing list paralleling a newsgroup. Thus the same 112 message is often sent to both email and netnews, or an email message is 113 a reply to a netnews article. This standard specifies the use and 114 interpretation of certain header information in such messages. This 115 standard specifies three not-previously standardized email headers: 116 "Posted-To", "Group-Reply-To" and "Personal-Reply-To" and gives 117 additional advice on the use of other email and netnews headers. This 118 standard also registers a global domain name, "md5.net" which should not 119 be used except as specified in this standard. 121 One goal of this standard is that the recipient should be able to 122 unambiguously identify the recipients (newsgroups and/or email) of a 123 message and get information as a basis for decisions on where to send 124 replies and followups to such messages. 126 In particular, some existing practice can cause the undesired public 127 posting of private email messages to news. It is for this reason that a 128 solution is necessary. Because of the installed base of software which 129 is based on two irreconcilable meanings of the "Newsgroups" header, when 130 it occurs in email, it is not feasible to simply change the definition 131 of these headers. New agents which use one of the two uses of this 132 header might increase the likelihood of very undesirable results, in 133 particular the undesired and unintended automatic conversion of private 134 messages to public newsgroup postings. 136 This standard does not repeat information which is in the email and 137 netnews standards [SMTP], [RFC822], [RFC1036], [RFC1123] and [MIME], 138 except where this is needed for clarity. 140 4. Definitions 142 The following terms are used in this standard. These terms may have a 143 broader meaning in other standards, but are limited to the specific 144 definitions within this document. 146 News Client A program used by a user to read and post news. 148 Mail Client A program used by a user to read and send mail. 150 Combined Client A program which combines the some or all of the functions 151 of a mail client and a news client. 153 Message A message sent to either netnews, email or both. 155 Mail Message Any message prepared by a client for transmission by mail 156 only. 158 News Message Any message prepared by a client for transmission by news 159 only. 161 Combined Message Any message which a combined agent distributes via both 162 news and mail. 164 Group A group of people receiving a message. A group can be a 165 newsgroup (representing its subscribers), a mailing list 166 (representing its subscribers), a set of nested mailing 167 lists, or a number of recipient names in To, Cc or Bcc 168 headers, or any combinations of these kinds of groups. 170 Original Message The message to which the current message is a reply. 172 Root Message A message which does not have any References, In-Reply-To 173 or Supersedes headers. 175 Thread The set of messages which can be found by finding all 176 messages which have "References", "In-Reply-To" or 177 "Supersedes" references to a certain root message, and 178 continuing this operation recursively. Note that a message 179 which has "In-Reply-To", "References" or "Supersedes" 180 headers referring to messages in more than one thread, will 181 not cause these two threads to merge into one thread. 182 Successive messages, however, will in this case belong to 183 more than one thread. See appendix C for an example. 185 Netnews Standards See [RFC 1036] 187 Email Standards See [RFC822], [RFC1123], [SMTP], [MIME] 189 5. Headers in Combined and Converted Messages 191 5.1 References and In-Reply-To 193 Messages which are sent at the same time to both mail and news MUST use 194 the References field according to the definitions in netnews standards 195 [RFC 1036], both for the copy of the message sent via email and the copy 196 sent via netnews. 198 Gateways from news to mail SHOULD not modify the "References" field. 200 Gateways from mail to news MUST, if needed, modify the syntax of 201 References and In-Reply-To to agree with netnews standards (where the 202 "phrase" variant is not allowed). 204 Gateways from mail to news MAY transport the "References" and 205 "In-Reply-To" header unchanged except for necessary syntax changes 206 ("phrase" is not allowed in netnews). If they are able to do it 207 correctly, they MAY convert the "References" and "In-Reply-To" field 208 contents from the usage specified for email to the usage specified for 209 netnews. Note that such a conversion requires a check on the messages 210 whose Message-ID are given in the "References" and "In-Reply-To" field, 211 and this check may have to be performed recursively all the way back to 212 the root message of a thread (since the netnews usage of the 213 "References" field requires the "References" field to contain the first, 214 the last and as many as possible of the intermediate earlier messages in 215 the thread, see [RFC 1036] clause 2.2.5). Thus, such a conversion is not 216 easy to perform. Conversion should not be done unless the gateway is 217 capable of doing it correctly. 219 Netnews messages can get replies, which are sent only as personal mail 220 and are not to be gatewayed to netnews. Such replies SHOULD use the 221 netnews (? or email?) conventions for "References" and "In-Reply-To". 223 Email replies to news messages MAY indicate the newsgroup of the 224 original message as a comment in the "In-Reply-To" header. Example: 226 In-Reply-To: (article in newsgroup foo.bar) 228 5.2 Message-ID Header 230 The "Message-ID" header MUST [RFC1036] be used (with its netnews syntax 231 [RFC1036]) in messages sent to netnews and in combined messages and 232 SHOULD be used with this syntax in messages sent via email to gateways 233 from mail to news. 235 A message to be gatewayed from email to netnews may lack a "Message-ID" 236 header. For creation of the Message-ID, the algorithm described in 237 appendix B is recommended. Mail and news software should however not 238 assume, without further checking, that a Message-ID which looks like it 239 had been generated according to this algorithm is the same for copies of 240 the same message which have been gatewayed at different places. 242 5.3 "Followup-To" and "Group-Reply-To" Headers 244 If the sender wishes to specify that further discussion on a message 245 sent to more than one newsgroup and/or mailing list is to be sent to 246 only one newsgroup, the "Followup-To" header MUST be used according to 247 netnews conventions in both the email and netnews version of combined 248 messages. It MUST only contain newsgroup names or the string "poster", 249 never email addresses, not even email addresses which are gatewayed to 250 newsgroups. 252 If the sender of a message wants followups, intended for the group of 253 people who saw the replied-to article, to be sent to a mailing-list, 254 this SHOULD be indicated using the "Group-Reply-To" header. The 255 "Group-Reply-To" header has the same syntax as the "Reply-To" header in 256 email standards, thus, multiple values are allowed. The "Group-Reply-To" 257 can be used to indicate a recommended reply-address for replies intended 258 for the same group of people who read the original message. Like 259 "Followup-To" in netnews, this header can suggest followups to only some 260 of the groups who got the original message. Readers of messages that 261 contain "Followup-To" or "Group-Reply-To" headers, who want to read 262 followups, should ensure that they are subscribed to one of the 263 newsgroups in "Followup-To" or one of the mailing lists in 264 "Group-Reply-To". 266 If the sender wants group followups to be sent to both a newsgroup and a 267 mailing-list, both a Followup-To and a Group-Reply-To header can be 268 used. This SHOULD however not be done if there is a gateway between the 269 mailing-list and the newsgroup. 271 A person who sends a message to a mailing list, and does not want to get 272 group replies except via this list, can include the list name in a 273 "Group-Reply-To" header. If this person wants group replies both 274 directly to his e- mail address and through the list, or if the person 275 does not subscribe to the list, s/he can put both his/her personal 276 e-mail address and the mailing list name in a "Group-Reply-To" header. 278 If "Group-Reply-To" refers to a mailing list which is run in parallel 279 with a newsgroup, gateways from mail to news may translate the 280 "Group-Reply-To" mailing list to its newsgroup equivalent in a 281 "Followup-To" clause, and gateways from news to mail may translate the 282 "Followup-To" clause to the equivalent "Group-Reply-To" header referring 283 to its parallel mailing list. 285 The "Reply-To" header in e-mail is unfortunately used in two conflicting 286 ways: (A) to indicate a replacement for the author as recipient of 287 personal replies, (B) as specified above for "Group-Reply-To". Because 288 of this, it SHOULD be phased-out, and replaced by the more explicit 289 headers "Personal-Reply-To" and "Group-Reply-To". However, because of 290 the wide usage of "Reply-To" (in both meanings) its phasing-out may take 291 some years. "Personal-Reply-To" can be used both in e-mail and netnews 292 to indicate where personal replies should be sent. 294 5.4 "Posted-To" header 296 This standard defines the new header "Posted-To". The "Posted-To" 297 header shall have the same syntax as the "Newsgroups" header defined in 298 netnews standards. 300 The email version of a combined message MUST use the "Posted-To" header 301 to indicate the newsgroups which this message is sent to. "Posted-To" 302 MUST NOT be used in the netnews version of the message (there, the 303 "Newsgroups" header is used instead). "Posted-To" must not be used for 304 any other purpose than described here. 306 Gateways between netnews and email SHOULD convert the "Newsgroups" 307 header in netnews to the "Posted-To" header in email and the reverse. 308 Gateways which do not perform this conversion MUST remove the 309 "Newsgroups" header from outgoing email messages and remove "Posted-To" 310 from outgoing news articles. 312 5.5 "Newsgroups" Header 314 The "Newsgroups" header SHOULD not be used in email messages, even if 315 these messages are also sent to newsgroups or are replies to news 316 messages. If a message arriving via email has a "Newsgroups" header, the 317 value of this header should be ignored. The value of this header shall 318 in particular not be interpreted either to indicate the newsgroup to 319 which this message is also posted (use Posted-To see 5.4), or to 320 indicate the newsgroup of the original message (use a comment in the 321 "In-Reply-To" field instead, see 5.1). 323 Note: the reason for this rule is that older software uses the 324 "Newsgroups" header in either of these two very different ways in email. 325 It is not possible to agree on a single meaning of the "Newsgroups" 326 header in email, therefore its use is deprecated and replaced by other 327 notation instead. 329 5.6 "Approved" Header 331 The "Approved" header defined in netnews standards may be used in email 332 with the same meaning: This message has been approved by the moderator 333 for distribution to members of a moderated group. 335 5.7 "Subject" Header 337 Combined messages SHOULD follow the netnews rules for the "Subject" 338 header. 340 It is the responsibility of the client to create "Subject" headers which 341 are correct. It is recommended that the netnews "Re: " convention is 342 used also in email. 344 5.8 "Received" and "Path" headers 346 Email to news gateways MUST remove "Received" headers from incoming 347 email messages while converting them to netnews. Attempts at converting 348 "Received" headers to "Path" header MUST NOT be done. It is STRONGLY 349 RECOMMENDED that the original email message be stored in the gateway 350 (including all headers) for a period following processing, to allow 351 tracing of forged or otherwise problematical articles. Netnews to email 352 gateways MAY copy the "Path" header from the news article into the 353 outgoing email. 355 Note: The "Path" header in netnews has as one of its uses to avoid 356 duplicates of the same message. Because of this, trying to convert 357 "Received" headers to "Path" headers might cause a message to be skipped 358 in netnews, and that is why such conversion MUST NOT be done. 360 5.9 "Control" messages 362 Mail to netnews gateways should provide the ability for users to cancel 363 articles they have used the gateway to post. To prevent the use of such 364 gateways for illegitimate cancels, gateways should not post cancels for 365 articles which were not posted through that gateway, and should require 366 some authentication for cancels it does post. 368 For example, the gateway may generate a key which is returned to the 369 user by email for each article posted. The user would include this key 370 in the cancel message he sends to the gateway. 372 5.10 Other Headers 374 Headers defined for netnews only can occur in email, and headers defined 375 for email can occur in netnews. An exception to this is the "Newsgroups" 376 header, which must be handled as described in clause 5.4 and 5.5 above. 377 Headers defined only for netnews should not be interpreted by email 378 clients, nor should email-only headers be interpreted by news clients. 380 Some headers have a more restricted syntax in netnews than in email, in 381 that case, the netnews syntax shall be used in combined messages. 382 Gateways must restrict the syntax of such headers if they are conveyed 383 from email to netnews. 385 5.11 Headers Mandatory in Netnews but not in Email 387 The following headers are mandatory in netnews but optional in email: 388 "Newsgroups", "Subject", "Message-ID" and "Path". Combined messages 389 SHOULD include these fields in both the mail and the netnews copy of the 390 message, except that the "Newsgroups" header in netnews is replaced by 391 the "Posted-To" header in email. 393 5.12 Headers Optional in Netnews and not Defined in Email 395 Headers optional in netnews and not defined in email may occur in email 396 messages. Combined clients MUST, and email to news gateways SHOULD, 397 include these optional headers in the netnews versions of any messages 398 they post. 400 6. Preparation of Replies to Combined Messages 402 Combined clients generating replies intended only for the author or for 403 only a few email recipients shall follow the email conventions for 404 replies and MAY indicate the newsgroup of the original message in a 405 comment in the "In-Reply-To" clause as specified in section 5.1 of this 406 standard. 408 Combined clients generating replies intended for the group who saw the 409 original message should use the information in any "Followup-To" (or 410 "Posted-To"/"Newsgroups" header, lacking a "Followup-To") to determine a 411 default list of newsgroups to which the reply may be posted, and 412 information from "Group-Reply-To" to determine a list of email 413 recipients for group replies. The client MUST allow the user to modify 414 any default list of email and newsgroup destinations. 416 "Group-Reply-To" indicates recommendations by the author of where to 417 send group replies, when these recommendations are email addresses (or 418 email addresses of mail gateways to newsgroups). "Followup-To" also 419 indicates such recommendations as specified in RFC 1036. A message may 420 include both "Followup-To" indicating a newsgroup, and "Group-Reply-To" 421 indicating a mailing list, which for example is run in parallel with the 422 same newsgroup or where the message is intended for recipients of both 423 the newsgroup and the mailing list. 425 A client which knows that a followup will reach a mailing list in a 426 "Group-Reply-To" header through a gateway from a newsgroup in a 427 "Followup-To" header may send a followup only to the newsgroup, relying 428 on the gateway to forward it to the mailing list. In this way, the risk 429 of recipients getting multiple copies of the message can be reduced. If 430 the client is not sure this will work, it should send the followup to 431 both "Followup-To" and "Group-Reply-To" recipients. 433 The choice of the appropriate recipients for a reply to the same group 434 as the original message is not always easy, and good user interfaces 435 will help users by clarifying to them what they are doing and where 436 their reply will be sent, and make the user aware if s/he is moving a 437 mail discussion to a news discussion or the reverse. 439 In particular, any "Newsgroups" header in an email message SHOULD NOT be 440 used as an indication that the original message has been sent to this 441 newsgroup. Use of the "Newsgroups" header can otherwise easily result in 442 a reply to a private message being sent to a newsgroup even though the 443 original message was not sent to this newsgroup. 445 7. Cooperating Clients and Gateways 447 If an email client is designed to cooperate with a certain gateway from 448 email to netnews, then messages sent only between clients of this type 449 and gateways of this type may employ additional information, not 450 standardized here, to improve the cooperation between them. Such 451 additional information MUST not be specified in ways which can cause 452 misunderstandings if the message gets to other than the specified 453 cooperating recipients. 455 8. Security considerations 457 This standard will reduce the risk of various unexpected results for 458 combined messages. Some existing risks in email and netnews may stay 459 even with this standard, but no new risks are expected as a result of 460 this standard. In general, increased transportation of messages between 461 news and email may mean that existing risks in news are propagated to 462 email or the reverse, but these risks would not be reduced by the lack 463 of a standard for such combined messages. 465 One security problem is that many Usenet News servers will totally 466 reject an incoming article, if the server already has an article with 467 the same Message-ID. This is of course proper if the new copy is 468 destined for the same newsgroup, but if the new copy is destined for 469 another newsgroup, the proper handling would be to distribute it to that 470 group, but not to the group where it already appears. 472 Newsgroup servers SHOULD accept articles even if the server already has 473 an article with the same Message-ID, but only if the new article has as 474 recipient some newsgroup where this message is not already stored, and 475 then only distribute the new copy to the new newsgroup. Until all Usenet 476 News servers have been modified to work this way, there is a security 477 risk with gatewaying mailing lists to news, in that a message sent to 478 more than one mailing lists, which are gatewayed to news at different 479 hosts, might not get to both newsgroups. The best way to handle this 480 problem is to change the behavious of news servers. An alternate 481 solution might be to change the Message-ID in gateways, but this 482 alternative has obvious drawbacks and is not recommended. 484 The algorithm for generating Message-IDs for messages lacking them can 485 slightly increase this security risk, but since most messages have 486 Message-IDs, the problem is there with or without this algorithm. 488 9. Acknowledgments 490 This standard is based on an earlier draft written by John Stanley. 492 10. References 494 Ref. Author, title IETF status (May 1997) 495 ---------------------- 496 --- ------------- 498 [SMTP] J. Postel: "Simple Mail Transfer Standard, Recommended. 499 Protocol", STD 10, RFC 821, August 500 1982. 502 [RFC822] D. Crocker: "Standard for the Standard, Recommended. 503 format of ARPA Internet text 504 messages." STD 11, RFC 822, August 505 1982. 507 [RFC1036] M.R. Horton, R. Adams: "Standard Non-standard (but still 508 for interchange of USENET widely used as a de-facto 509 messages", RFC 1036, December standard). 510 1987. 512 [RFC1123] R. Braden (editor): "Requirements Standard, Required. 513 for Internet Hosts -- Application 514 and Support", STD-3, RFC 1123, 515 October 1989. 517 [MIME] N. Freed, N. Borenstein and Draft Standard, elective. 518 others, "Multipurpose Internet 519 Mail Extensions (MIME) Part One to 520 Five, RFC 2045 to 2049. 522 [MD5] Rivest, R., "The MD5 Non-standard 523 Message-Digest Algorithm", RFC 524 1321, MIT Laboratory for Computer 525 Science and RSA Data Security, 526 Inc., April 1992. 528 [CMD5] J. Myers, M. Rose: The Content-MD5 Draft standard, Elective 529 Header. RFC 1864, October 1995. 531 11. Author's Addresses 533 Jacob Palme Phone: +46-8-16 16 67 534 Stockholm University/KTH Fax: +46-8-783 08 29 535 Electrum 230 Email: jpalme@dsv.su.se 536 S-164 40 Kista, Sweden 538 Appendix A: Examples 540 A.1 One Combined Message in two Instances. 542 The following is an example of a combined message, sent both to a 543 newsgroup comp.lang.c and via e-mail to a person mary@foo.bar when 544 transported via netnews: 546 Newsgroups: comp.lang.c 547 To: mary@foo.bar 548 Date: 7 Jan 1997 12:34:21 +0000 (GMT) 549 Subject: A message about inheritance 550 From: fred@somewhere.zz 551 Message-ID: <123zx@somewhere.zz> 552 Path: a.news.system!b.news.system!somewhere.zz!fred 554 What is it? 556 The same message when transported via email: 558 Posted-To: comp.lang.c 559 To: mary@foo.bar 560 Date: 7 Jan 1997 12:34:21 +0000 (GMT) 561 Subject: A message about inheritance 562 From: fred@somewhere.zz 563 Message-ID: <123zx@somewhere.zz> 564 Path: a.news.system!b.news.system!somewhere.zz!fred 566 What is it? 568 A.2 Conversion Performed by Email to News Gateway. 570 In this case, the mailing list name is not copied to a "To:" header in 571 netnews, since it gives the same information which the "Newsgroups:" 572 header gives in netnews. The email message before conversion: 574 Received: from ietf.org (ietf.org [132.151.1.19]) 575 by info.dsv.su.se (8.8.5/8.8.5) with SMTP 576 id QAA00061 for ; 577 Mon, 2 Jun 1997 16:23:10 +0200 (MET DST) 578 Received: from ietf.org by ietf.org id aa05468; 2 Jun 97 9:50 EDT 579 Received: from ietf.ietf.org by ietf.org id aa04922; 2 Jun 97 9:28 580 EDT 581 Mime-Version: 1.0 582 Content-Type: Multipart/Mixed; Boundary="NextPart" 583 To: IETF-Announce@ietf.org 584 Sender: ietf-announce-request@ietf.org 585 From: Internet-Drafts@ietf.org 586 Reply-to: Internet-Drafts@ietf.org 587 Subject: I-D ACTION:draft-leiba-imap-idle-02.txt 588 Date: Mon, 02 Jun 1997 09:28:44 -0400 589 X-Orig-Sender: cclark@ietf.org 590 Message-ID: <9706020928.aa04922@ietf.org> 592 A Revised Internet-Draft is available from the on-line Internet- 593 Drafts directories. 595 The same message after gatewaying to netnews: 597 Mime-Version: 1.0 598 Content-Type: Multipart/Mixed; Boundary="NextPart" 599 Newsgroups: comp.standards.ietf.announcements 600 Sender: ietf-announce-request@ietf.org 601 From: Internet-Drafts@ietf.org 602 Reply-to: Internet-Drafts@ietf.org 603 Subject: I-D ACTION:draft-leiba-imap-idle-02.txt 604 Date: Mon, 02 Jun 1997 09:28:44 -0400 605 X-Orig-Sender: cclark@ietf.org 606 Message-ID: <9706020928.aa04922@ietf.org> 608 A Revised Internet-Draft is available from the on-line 609 Internet-Drafts directories. 611 A.3 Conversion Performed by News to Email Gateway. 613 Original netnews article: 615 Newsgroups: comp.sys.mac 616 From: PHLLB@leeds.ac.uk (L. Burkholder) 617 Subject: cocoa (formerly kidsim) 618 Message-ID: <4p1ul5$88k_001@leeds.ac.uk> 619 NNTP-Posting-Host: woolhouse_pc37.leeds.ac.uk 620 Organization: University of Leeds 621 Date: Tue, 4 Jun 1996 19:16:24 +0100 (BST) 622 X-Newsreader: News Xpress Version 1.0 Beta #4 624 Does anyone know how to get a copy of the recently announced Apple 625 visual programming language Cocoa (formerly called Kidsim)? 627 The same message after gatewaying to email: 629 Posted-To: comp.sys.mac 630 To: info-mac@sumex-aim.stanford.edu 631 From: PHLLB@leeds.ac.uk (L. Burkholder) 632 Subject: cocoa (formerly kidsim) 633 Message-ID: <4p1ul5$88k_001@leeds.ac.uk> 634 NNTP-Posting-Host: woolhouse_pc37.leeds.ac.uk 635 Organization: University of Leeds 636 Date: Tue, 4 Jun 1996 19:16:24 +0100 (BST) 637 X-Newsreader: News Xpress Version 1.0 Beta #4 639 Does anyone know how to get a copy of the recently announced Apple 640 visual programming language Cocoa (formerly called Kidsim)? 642 Appendix B: Algorithm for Assigning Message-IDs to Messages in Gateways 643 from Email to Netnews 645 The intention of the following algorithm is to make it likely that the 646 same message will get the same Message-ID even if it is gatewayed in 647 more than one place from email to news, and to make it very unlikely 648 that two different messages get the same Message-ID. This algorithm is 649 only intended for gateways from email to netnews, and only when 650 gatewaying messages which do not have a Message-ID. 652 Step 1: Remove all headers except From, Date, Sender, Subject. 654 Step 2: Compute an MD5 checksum using the algorithm described in [1]. 656 Step 3: Encode the checksum using BASE64 encoding as specified in [2]. 658 Step 4: Concatenate the string "@MD5.net" to the encoded string. 660 Note: If the message does not have any Date header, this algorithm 661 should not be attempted, instead an algorithm giving a globally unique 662 Message-ID based on a domain controlled by the gateway should be used. 664 Appendix C: Example of two partially overlapping threads 666 THREAD A: THREAD B: 668 Subject: The beatles<-------+ Subject: Abba 669 Message-ID: a1@foo.bar \ Message-ID: b1@foo.bar 670 ^ \ ^ 671 | \ | 672 References: a1@foo.bar \ References: b1@foo.bar 673 Subject: Re: The beatles \ Subject: Re: Abba 674 Message-ID: a2@foo.bar \ Message-ID: b2@foo.bar 675 ^ \ ^ 676 | \ | THREADS A+B: 677 | \ | 678 References: a1@foo.bar, a2@foo.bar References: a1@foo.bar, b1@foo.bar, 679 Subject: Re: The beatles b2@foo.bar 680 Message-ID: a3@foo.bar Subject: Re: Abba and the beatles 681 ^ Message-ID: ab1@foo.bar 682 | ^ 683 | | 684 References: a1@foo.bar, a2@foo.bar, References: a1@foo.bar, b1@foo.bar, 685 a3@foo.bar b2@foo.bar, ab1@foo.bar 686 Subject: Re: The beatles Subject: Re: Abba and the beatles 687 Message-ID: a4@foo.bar Message-ID: ab2@foo.bar