idnits 2.17.1 draft-rare-msg-a-bombs-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-04-25) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** 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 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.) == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 1994) is 10968 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 section? '13' on line 820 looks like a reference -- Missing reference section? '7' on line 791 looks like a reference -- Missing reference section? '8' on line 796 looks like a reference -- Missing reference section? '12' on line 817 looks like a reference -- Missing reference section? '1' on line 771 looks like a reference -- Missing reference section? '2' on line 775 looks like a reference -- Missing reference section? '3' on line 778 looks like a reference -- Missing reference section? '4' on line 782 looks like a reference -- Missing reference section? '5' on line 785 looks like a reference -- Missing reference section? '6' on line 788 looks like a reference -- Missing reference section? '9' on line 802 looks like a reference -- Missing reference section? '10' on line 807 looks like a reference -- Missing reference section? '11' on line 812 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RARE-DRAFT Jeroen Houttuin 2 IESG Mail Applicability Design Team RARE Secretariat 3 April 1994 5 Bombs series: Behaviour of Mail Based Servers 6 Part 2: A-bombs 7 Answering servers 9 Abstract 11 This document defines rules for the behaviour of Mail Based Echo 12 Servers and Vacation Servers in the Internet. It is highly desirable 13 that other e-mail networks connected to the Internet also implement 14 these rules. 16 Status of this Memo 18 This document is a RARE Draft. RARE Drafts form a subseries of the 19 Internet Drafts, which are working documents of the Internet 20 Engineering Task Force (IETF), its Areas, and its Working Groups. 21 Note that other groups may also distribute working documents as 22 Internet Drafts. For example, RARE Drafts are produced by the RARE 23 Working Groups. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet 28 Drafts as reference material or to cite them other than as a "working 29 draft" or "work in progress." 31 Please check the I-D abstract listing contained in each Internet 32 Draft directory to learn the current status of this or any other 33 Internet Draft. 35 Distribution of this memo is unlimited. 37 This document builds upon the classification of MBS types, which can 38 be found in the Bombs series, part1: C-bombs [13]. 40 Within the context of the connectivity testing tool 'concord', 41 initial work on the requirements for echo servers was done within 42 SWITCH and XNREN ([7], [8]). 44 The document was then integrated in the work of the IESG solicited 45 Mail Applicability Design Team, consisting of: Ned Freed (INNOsoft), 46 Jeroen Houttuin (RARE), John Klensin (INfoods, UN), Keith Moore 47 (University of Tennessee). 49 Depending on the nature of your comments, please respond to one of 50 the following addresses: 52 The main discussion group: wg-msg@rare.nl 53 The design team: mail-as@infoods.unu.edu 54 The author: houttuin@rare.nl 56 Contents 58 1. Introduction 2 59 2. General approach 2 60 3. Implementation levels and protocols 4 61 4. Rules 4 62 4.1. Input message restrictions 5 63 4.2. Output messages 6 64 4.2.1. Relation to the input message 6 65 4.2.2. Restrictions 10 66 4.3. Logging 14 67 4.4. Access permissions 16 68 5. Reference implementations 17 69 6. Acknowledgements 17 70 7. Security considerations 17 71 8. Bibliography 17 72 9. Abbreviations 19 73 10. Author's Address 19 75 1. Introduction 77 Mail Based Servers (MBSs) are defined in C-bombs [13] as follows: 79 An MBS is a process that automatically generates one or more messages 80 (the output messages) as a result of receiving a message (the input 81 message). 83 Two main types are identified: repliers and forwarders. This 84 documents deals only with the basic behaviour of a subclass of 85 repliers: echo servers and vacation servers (jointly referred to as 86 'answering servers'). 88 2. General approach 90 The overall approach for all MBS header requirements based upon C- 91 bombs [13] is as follows. 93 If all MBSs would agree to implement a common set of behaviour rules, 94 this set could be fairly small. In practice however, there are some 95 reasons why such a 'minimum approach' will not work: 97 - The most obvious reason is that one cannot realistically expect 98 all networks and software developers to implement one common 99 strict set of rules. In different mail communities, different 100 MBS conventions have already been used for a long time. Some of 101 these conventions can be unacceptable for other communities to 102 implement. 104 - MBSs can be built upon different underlying protocols. For 105 instance, it is almost impossible to have a small set of rules 106 that will prevent problems between any combination of MBSs, e.g. 107 between an RFC 822-like MBS running over NJE and a P1 based MBS. 108 More problems can be expected because header fields are crucial 109 for the properly functioning of MBSs, and protocol gateways will 110 not always map header fields bijectively. 112 - Not all MBSs are controlled by software developers or network 113 operators. Any user can write a simple program that will have 114 the functionality of an MBS. 116 Because the 'minimum approach' is not feasible, the bombs series 117 follows the 'unilateral safety approach'. This means that any MBS 118 that implements the complete set of rules should be safe from harm, 119 regardless of what other 'dumb' MBSs it is interacting with. 121 This approach results in quite a large number of recommendations, of 122 which not every single one is strictly necessary to prevent problems, 123 but none of them will 'hurt' the functioning of an MBS. 125 From the previous paragraphs it follows that MBSs do not operate in a 126 vacuum; they interact with other types of MBSs. As a result, the 127 requirements in this document may sometimes look like an overkill 128 when not seen in the light of the behaviour of other types of MBSs. 129 To get an idea of the requirements for other MBSs, please refer to 130 the H-bombs document [12] (which is the predecessor of the bombs 131 series). 133 As for the programming overhead caused by the recommendations, there 134 is at least one example of an echo server (Echoput) that implements 135 all a-bombs rules in two pages of (perl) code. 137 In addition to the rules that protect against loops and explosions, 138 there are also some rules reflecting common sense. For instance, if a 139 user sends a message flagged 'urgent' to an echo server, he would 140 expect not only his request message, but also the reply message to be 141 handled with extra priority. 143 The rules for vacation servers are the same as for echo servers, but 144 due to the lifetime attribute and a vacation server not normally 145 having a separate administrator, these servers have some 146 additional/exceptional rules. 148 3. Implementation levels and protocols 150 Answering servers are normally implemented at UA level. If one wants 151 to test connectivity at a lower level, a message can be sent to a 152 'nosuchuser' address, which will result in an MTA-generated non- 153 delivery message or report. 155 To a user, it is often not known beforehand in which protocol world 156 (RFC 822, X.400, others) an MBS is located. Also an MBS doesn't 157 normally 'know' in which world a user lives. In order to come to a 158 consistent echo server behaviour regardless of used protocols, this 159 document describes recommendations for both RFC mail and X.400 echo 160 servers. Note that a one hundred percent transparency cannot be 161 reached (yet), because there exists no one-to-one mapping between all 162 RFC mail and X.400 service elements. 164 For the reader's convenience, the rules for MBSs in different 165 implementation levels and protocols are explicitly stated in the 166 appropriate terminologies. The rules are labelled as follows: 168 For Internet mail: 170 #RFC# Applies to RFC 822 on top of RFC 821 (SMTP) based MBSs 171 #1327# Some the RFC 822 rules deal with non-standard headers as 172 described in RFC 1327 174 For X.400: 176 #400# Applies to X.400 (both 84 and 88) based MBSs 177 #84# Applies to X.400(84) based MBSs 178 #88# Applies to X.400(88) based MBSs 179 #P1# Applies to P1 (MTS) based MBSs 180 #P2# Applies to P2 (UA) based MBSs 181 #P3# Applies to P3 (MTA) based MBSs 183 4. Rules 185 Depending on implementation level and protocol, answering servers 186 follow, as a minimum, the requirements defined in RFC 822, RFC 821, 187 RFC 1123, X.411, X.420, X.435 etc. For those requirements, the MBS 188 must behave as an automated user or UA, depending on whether it is 189 implemented at UA- or MTS-level, respectively. This chapter describes 190 additional rules for answering servers in terms of RFC 821, RFC 822, 191 P1, P3, and P2. 193 4.1. Input message restrictions 195 4.1.1. Don't reply to automatically forwarded messages 197 DISCUSSION: There is no need for a user to automatically forward his 198 incoming messages to an echo server or a vacation server. Note that 199 non-auto-forwarded messages can only be unambiguously identified in 200 P2, Internet mail has no standard headers for this purpose. RFC 1327 201 gateways map this attribute to a new RFC 822 header "Auto- 202 Forwarded:". In the presence of this header, RFC based MBSs can 203 safely assume that the message was indeed auto-forwarded. 205 RULE: An auto-forwarded message is not valid as an input message. The 206 result is the generation of an exception output message. 208 ORIGIN OF RULE: This document. 210 4.1.2. Don't reply to threads 212 DISCUSSION: It is very unlikely that a user will send a reply to 213 another message as an input message to an answering server. Such a 214 reply or follow-up should either have gone to the MBS administrator 215 (due to the rules in this document) or to any other address that is 216 not an answering server. 218 RULE: An exception output message is generated if the input message 219 contains either of the following headers or attributes: 221 #RFC# In-Reply-To: 222 References: 224 #P2# In-Reply-To 225 crossReferences 227 ORIGIN OF RULE: This document. 229 APPLICABILITY: should. 231 4.1.3. Valid input message types 233 DISCUSSION #RFC#: An answering server is not to send automatic 234 replies to (automatically generated) non-delivery messages, to avoid 235 loops. In RFC mail, non-delivery messages can be recognised by the 236 empty MAIL FROM: line. 238 RULE: Only the following types of input messages are valid as input 239 messages. Any other type of input message (report, receipt 240 notification) leads to the generation of an exception message. 242 #RFC# Any message that does not have an empty MAIL FROM: line. 244 #84#P1# UserMPDU 245 #84#P2# IM-UAPDU 247 #88#P1# Message 248 #88#P2# IPM 250 #400# P1.Probes are expected to be handled by the MTS and are thus 251 not interpreted by the MBS. 253 4.2. Output messages 255 4.2.1. Relation to the input message 257 4.2.1.1. User can specify alternate output message recipient 259 DISCUSSION: The user may decide that the output message should be 260 sent to another address than his own. This is especially useful when 261 the user is an automated process, e.g. a connectivity checker, with a 262 complex distributed configuration. 264 RULE: If the input message contains the following header or 265 attribute, the output message is sent to that address. If this field 266 contains more than one address, an output message is sent to at least 267 the first address of this field. (Sending to the others is not 268 recommended.) 270 #RFC# Reply-To: 272 #84#P2# replyToUsers 274 #88#P2# reply-recipients 276 ORIGIN OF RULE: Common practice, RFC 821, RFC 822, RFC 1123, X.400. 278 APPLICABILITY: must. 280 4.2.1.2. Make output messages traceable 282 DISCUSSION: This rule allows the user to find know exactly to which 283 message this output message belongs. 285 ORIGIN OF RULE: RFC 822, X.400, common practice, this document. 287 4.2.1.2.1. In reply to 289 RULE: The following header or attribute of the output message has the 290 value: 292 #RFC# In-Reply-To: : Message-ID of input message 294 #84#P2# inReplyTo : IPMessageID of input message 296 #88#P2# replied-to-IPM : this-IPM of input message 298 APPLICABILITY: must. 300 4.2.1.2.2. Subject 302 The following header or attribute of the output message has as value 303 the string 'Re: ', concatenated with the subject of the input 304 message. 306 #RFC# Subject: 308 #P2# subject 310 APPLICABILITY: should. 312 4.2.1.2.3. References 314 RULE: If the following header or attribute is used in the output 315 message, it has the value: 317 #RFC# References: : Message-ID of input message 319 #84#P2# crossReferences : IPMessageID of input message 321 #88#P2# related-IPMs : this-IPM of input message 323 APPLICABILITY: may. 325 4.2.1.2.4. Alternate recipient can trace originator of the input message 327 DISCUSSION: A user who receives mail from an MBS, without having 328 ordered this information himself, has the right to know who was 329 responsible for having messages sent to his mailbox. The semantics of 330 both RFC 822 and X.400 header fields allow to specify that a message 331 was sent from a certain address, but was authorised by someone else. 332 This matches the semantics needed here. Another reason for using 333 header fields for carrying this information is that the addresses 334 will still be readable for the end-user after the message has crossed 335 a protocol gateway. 337 RULE: 339 #RFC# If the output message is not sent to the originator of the 340 input message, its From: field contains the addresses of the From: 341 and the Sender: fields of the input message. In this case the Sender: 342 field of the output message contains the address of the MBS 343 administrator. 345 #P2# If the output message is not sent to the P2.originator of the 346 input message, its P2.authorizingUsers field contains the addresses 347 of the P2.originator and the P2.authorizingUsers of the input 348 message. 350 ORIGIN OF RULE: This document, RFC 822, RFC 1327, X.400. 352 APPLICABILITY: shall. 354 4.2.1.4. Body contents 356 DISCUSSION: In order for the user to see what happened to his 357 original input message on its way to the answering server (format, 358 timing etc), the input message is reflected back to the user. Further 359 info- and advertainment about the server can be included as well. See 360 also 4.2.2. 362 ORIGIN OF RULE: Common practice, this document. 364 RULE: The input message (all headers and an optionally truncated part 365 of the body) is included in the output message in an end user 366 readable format, preferably as a MIME message body-part, an 367 IPMS.ForwardedIPMessage bodypart, or in plain ASCII text. 369 APPLICABILITY: must. 371 4.2.1.5. Conservation 373 DISCUSSION: There are a number of headers or attributes, set by the 374 originator of the input message, that are to be set to the same value 375 in the output message. For instance, a user will expect a high 376 priority request to be handled with high priority. The output message 377 will in this case have the same priority. Note that an MBS can, as a 378 local decision, choose to spool all requests in order to spread the 379 MBS load. As long as the local processing of high priority request 380 can be guaranteed to be no slower than that of normal requests, and 381 the following rules for the output messages are followed, these local 382 processing delays will be transparent for the MBS users. 384 4.2.1.5.1. Retain privacy requests 386 DISCUSSION: The server is to respect the originator's request for 387 privacy. 389 RULE: The following headers or attributes have the same value in the 390 output message as in the input message: 392 #1327# Sensitivity: 393 #1327# Importance: 394 #1327# Priority: 396 #P2# P2.sensitivity 397 #P2# Importance 399 #P1#P3# Priority 401 ORIGIN OF RULE: this document. 403 APPLICABILITY: must. 405 4.2.1.5.2. Answer in same type of content 407 DISCUSSION: To minimise the chance of UAs not being able to handle a 408 certain message content type, the content type of the output message 409 is the same as that of the input message. 411 RULE: The following headers or attributes have the same value in the 412 output message as in the input message 414 #RFC# MIME-Version: 415 #RFC# Content-Transfer-Encoding: 417 #84#P1#P3# ContentType 419 ORIGIN OF RULE: this document. 421 APPLICABILITY: should. 423 4.2.2. Restrictions 425 4.2.2.1. Don't ask for replies 427 DISCUSSION: If an MBS would request some form of reply or report for 428 an output message, other MBSs might as a result automatically send a 429 message, report or (non)delivery message back to the MBS, which is to 430 be avoided at all cost, or to the MBS administrator, which is highly 431 undesirable. 433 ORIGIN OF RULE: This document. 435 4.2.2.1.1. Don't give incentive to reply to output message 437 DISCUSSION: Replies to the output message should be avoided, 438 especially because they might be generated automatically. 440 RULE: The following headers or attributes are not used in the output 441 message: 443 #RFC#1327# Reply-By: 444 #RFC#1327# Expiry-Date: 446 #P2# Recipient.replyRequest 447 (defaults to FALSE) 449 #84#P2# replyBy 450 #84#P2# expiryDate 452 #88#P2# reply-time 453 #88#P2# Expiry Time 454 #88#P1#P3# Proof-of-delivery-request 455 (defaults to proof-of-delivery-not- 456 requested) 458 APPLICABILITY: shall 460 4.2.2.1.2. Use of Reply-To functionality 462 DISCUSSION: It is redundant to explicitly attract replies to the 463 output message to the MBS administrator, as the other rules in this 464 document will ensure such behaviour. If an MBS decides to explicitly 465 attract replies to the output message to a certain address, that 466 address is not to be the server's address, but preferably the 467 administrators. Since this rule contains three different 468 applicability levels, it is subdivided into 3 rules. 470 A. Don't use Reply-To functionality 472 DISCUSSION: Other rules in this document will ensure that replies to 473 the output message will automatically be sent to the right address 474 (the administrator's). 476 RULE: The following headers or attributes are not used in the output 477 message: 479 #RFC# Reply-To: 481 #84#P2# replyToUsers 483 #88#P2# reply-recipients 485 ORIGIN OF RULE: This document. 487 APPLICABILITY: shall 489 B. Don't attract replies towards the server itself 491 DISCUSSION: If the MBS decides, despite rule A, to attract replies to 492 a certain address, that address is not this (or any other) answering 493 server's. 495 RULE: If the following field is used in the output message, it does 496 not contain the address of the answering server. 498 #RFC# Reply-To: 500 #84#P2# replyToUsers 502 #88#P2# reply-recipients 504 ORIGIN OF RULE: This document. 506 APPLICABILITY: must. 508 C. Attract replies towards the administrator 510 DISCUSSION: If the MBS decides, despite rule A, to attract replies to 511 a certain address, that address is the MBS administrator's. 513 RULE: If the following field is used in the output message, it 514 contains the address of the answering server's administrator. 516 #RFC# Reply-To: 518 #84#P2# replyToUsers 520 #88#P2# reply-recipients 522 ORIGIN OF RULE: This document. 524 APPLICABILITY: should. 526 4.2.2.2. Avoid non deliverable output messages to cause loops 528 DISCUSSION: If the output message has an MTS-level originator with 529 the address of the answering server itself, a loop can occur if the 530 output message is undeliverable. Note that for X.400 answering 531 servers, this rule affects a P1 attribute, but only when the output 532 message is P2. For instance, consider a P1 distribution list that 533 distributes another content type than P2, say Pc. Since Pc can be 534 completely unstructured, changing the P1.originator would make it 535 impossible to reply to the originator of the input message. Changing 536 the P1.originator will also make sense for content types that have P2 537 like header fields, e.g. for P35 messages. 539 RULE: The following line or attribute of the output message has the 540 value: 542 #RFC# MAIL FROM: : address of the MBS administrator 544 #P2# P1.originator : address of the MBS administrator 546 ORIGIN OF RULE: Common practice, this document. 548 APPLICABILITY: must. 550 4.2.2.3. Avoid replies to the output message to go back to the server 552 RULE: The following line or attribute of the output message has the 553 value: 555 #RFC# From: : address of the MBS administrator 557 #P2# P2.originator : address of the MBS administrator 559 ORIGIN OF RULE: This document. 561 APPLICABILITY: must. 563 4.2.2.4. Avoid reports about the output message 565 DISCUSSION: We don't want anything automatically generated in reply 566 to the output message, to avoid loops. 568 A. PerRececipientFlags 570 RULE: #84#P1#P3# Every PerRececipientFlag in the output message has 571 the following bits set: 573 Report Request: 01 574 User Report Request: 00 576 (I.e. the Non-delivery Notification service will be prevented) 578 ORIGIN OF RULE: this document. 580 APPLICABILITY: must. 582 B. Don't request Reports or Notifications to the output message 584 RULE: The following attribute is empty in the output message: 586 #84#P2# Recipient.reportRequest 588 #88#P2# NotificationRequests 590 ORIGIN OF RULE: this document. 592 APPLICABILITY: must. 594 4.2.2.5. Extension Identifiers 596 DISCUSSION: There is at least one case where not all 597 P1.ExtensionIdentifiers being different has caused a mailing loop. 598 Although this was due to a software bug, there is no good reason for 599 not using different P1.ExtensionIdentifiers. 601 RULE #P1#: All P1.ExtensionIdentifiers in the output message are 602 distinct. 604 ORIGIN OF RULE: Common practice, common sense, this document. 606 APPLICABILITY: shall. 608 4.2.2.6. Body contents 610 DISCUSSION: In order for the user to see what happened to his 611 original input message on its way to the answering server (format, 612 timing etc), the input message is reflected back to the user. Further 613 info- and advertainment about the server can be included as well. See 614 also under 4.2.1. 616 ORIGIN OF RULE: Common practice, this document. 618 RULE: Additional information is included in separate bodyparts of the 619 output message. 621 APPLICABILITY: may. 623 4.3. Logging 625 4.3.1. Logging for the administrator 627 DISCUSSION: This rule allows the MBS administrator to track down 628 malicious behaviour. 630 RULE: The MBS logs the originator of the input message and all 631 recipient(s) of the output/exception message(s). 633 ORIGIN OF RULE: this document. 635 APPLICABILITY: shall. 637 4.3.2. Log output message IDs 639 DISCUSSION: This will prevent all routing and MTS-redirection loops 640 amongst MBSs. UA level MBSs, which create a new output message for 641 each input message, will at least be safeguarded against mail storms 642 from other MTS based MBSs. 644 RULE: The MBS logs the message ID of every input message and every 645 output message. It generates an exception message if the same message 646 ID is encountered in the input message more than once. 648 ORIGIN OF RULE: This document. Similar techniques are already being 649 used in Netnews. 651 APPLICABILITY: should. 653 4.3.3. Vacation logging 655 DISCUSSION: Users of vacation servers don't normally want to use a 656 server, but to reach another person. One output message stating that 657 this person is on vacation will be enough. 659 RULE: Vacation servers at least log the originator of the input 660 message. During the lifetime of an vacation server, only one output 661 message per input message originator is generated. 663 ORIGIN OF RULE: This document. Similar techniques are already being 664 used in Netnews. 666 APPLICABILITY: must. 668 4.3.4. Black list 670 DISCUSSION: Repliers are not to send output messages to addresses 671 which are likely to be repliers themselves, to avoid loops. 673 RULE: Repliers keep a list of loop-suspicious addresses, containing 674 at least the following values for the local address designator 675 (localpart, Surname, CommonName): 677 autoanswer 678 echo 679 listserv 680 mailerdaemon 681 mirror 682 netserv 683 server 685 In this respect, also echo servers can be thought to have a limited 686 lifetime, during which a normal output message (with an extra 687 bodypart containing a warning) will be sent to loop-suspicious 688 addresses only once. This can be implemented by automatically adding 689 the exact suspicious address to a negative access control list. 690 Whenever this list is cleared, the replier can be thought to start a 691 new lifetime. 693 The loop suspicious addresses are matched in any combination of upper 694 and lower case. 696 ORIGIN OF RULE: Tradition, this document. 698 APPLICABILITY: shall. 700 4.4. Access permissions 702 DISCUSSION: The user is is to be informed whether and why he has not 703 been granted access to the server. 705 ORIGIN OF RULE: Tradition, this document. 707 DISCUSSION #RFC#: Note that in this case the not granted access is to 708 be reported from MTS level, i.e. by the MBS administrator, owner or 709 operator - and not by the MBS itself. 711 RULE: #RFC# In case of an Access Permission violation an exception 712 message is generated with the following text in the message body: 714 "Originator not allowed to send to this address" 716 APPLICABILITY: shall. 718 DISCUSSION #84#: Note that also here the not granted access is to be 719 reported from MTS level, i.e. by the MBS administrator, owner or 720 operator - and not by the MBS itself. This holds for both options: 722 RULE option 1: #84#: In case of an Access Permission violation a 723 P1.DeliveryReportMPDU is generated with the following values: 725 ReasonCode: unableToTransfer(1) 726 DiagnosticCode:uaUnavailable(4) 727 SupplementaryInformation: 728 "Originator not allowed to send to this 729 address" 731 APPLICABILITY: shall. 733 DISCUSSION: This option is preferred, but a P2 server may choose to 734 respond more in line with RFC servers as follows: 736 RULE option 2: #84#P2# In case of an Access Permission violation an 737 exception message is generated with the following text in the message 738 body: 740 "Originator not allowed to send to this address" 742 APPLICABILITY: may. 744 5. Reference implementations 746 There are a number of MBS implementations that follow most of the 747 recommendations listed in this document. They include the following, 748 all operating at UA level: 750 Name Protocols Contact 751 ---------------------------------------------------------------- 752 Concord RFC, X.400(84) klarenberg@netconsult.ch 753 EAN echo serverX.400 martinez@fundesco.es 754 Echoput RFC, MIME klarenberg@netconsult.ch 755 PP echo server X.400(84 and 88) onions@xtel.co.uk 757 6. Acknowledgements 759 Thanks for ideas, comments, flames and corrections: Harald Alvestrand 760 (SINTEF), Allan Cargille (XNREN), Urs Eppenberger (SWITCH), Paul 761 Klarenberg (NetConsult AG), Ignacio Martinez (Fundesco), Juan 762 Pizzorno (DFN), Eric Thomas (SUNET), Johan Vromans (Multihouse), Jan 763 van der Weele (Du Pont). 765 7. Security considerations 767 Security issues are not discussed in this memo. 769 8. Bibliography 771 [1] Jonathan B. Postel, "Simple Mail Transfer Protocol", 772 RFC 821, University of Southern California, August 773 1982 775 [2] Crocker, D., "Standard of the Format of ARPA Internet 776 Text Messages", RFC 822, UDEL, August 1982. 778 [3] R. Braden, Editor, "Requirements for Internet Hosts - 779 - Application and Support", RFC 1123, USC/Information 780 Sciences Institute, October 1989. 782 [4] Kille, S., "Mapping between X.400(1988) / ISO 10021 783 and RFC 822", RFC 1327, UCL, May 1992. 785 [5] Kille, S., "X.400 1988 to 1984 downgrading", RFC 786 1328, UCL, May 1992 788 [6] N. Borenstein, N. Freed, MIME (Multipurpose Internet 789 Mail Extensions), RFC 1341, June 1992 791 [7] J. Houttuin, "Concord functional specification", 792 COSINE MHS server, Mail: cosine-mhs- 793 server@nic.switch.ch, FTP: nic.switch.ch, Username: 794 cosine , File: tools/operational/concord/xxxxxxxx 796 [8] J. Houttuin, Allan Cargille, "Requirements for 797 concord echo servers and distribution lists", COSINE 798 MHS server, Mail: cosine-mhs-server@nic.switch.ch, 799 FTP: nic.switch.ch, Username: cosine, File: 800 procedures/echo-server-reqs 802 [9] "list of surnames/usernames not to automatically 803 reply to", RARE server, Mail: server@rare.nl, FTP: 804 ftp.rare.nl, File: 805 working-groups/wg-msg/div/dontreply 807 [10] CCITT Recommendations X.400 - X.430. Data 808 Communication Networks: Message Handling Systems. 809 CCITT Red Book, Vol. VIII - Fasc. VIII.7, Malaga- 810 Torremolinos 1984 812 [11] CCITT Recommendations X.400 - X.420. Data 813 Communication Networks: Message Handling Systems. 814 CCITT Blue Book, Vol. VIII - Fasc. VIII.7, Melbourne 815 1988 817 [12] Houttuin, J., "H-bombs: Header Behaviour of MBSs", 818 work in progress, November 1993. 820 [13] Houttuin, J., "C-bombs: Classification of Breeds of 821 MBSs", work in progress, April 1994. 823 9. Abbreviations 825 ASCII American Standard Code for Information Exchange 826 CCITT Comite Consultatif International de Telegraphique et 827 Telephonique 828 COSINE Co-operation for OSI networking in Europe 829 EAN MHS software (not an abbreviation) 830 IESG Internet Engineering Steering Group 831 IETF Internet Engineering Task Force 832 IPM Inter-Personal Message 833 IPN Inter-Personal Notification 834 MHS Message Handling System 835 MBS Mail based server 836 MTA Message Transfer Agent 837 MTL Message Transfer Layer 838 MTS Message Transfer System 839 NJE Network Job Entry 840 PP MHS software (not an abbreviation) 841 RARE Reseaux Associes pour la Recherche Europeenne 842 SMTP simple mail transfer protocol 843 UA User Agent 845 10. Author's Address 847 Jeroen Houttuin 849 RARE Secretariat 850 Singel 466-468 851 NL-1017 AW Amsterdam 852 Europe 854 Tel +31 20 6391131 855 Fax +31 20 6393289 857 RFC 822 houttuin@rare.nl 858 X.400 /S=houttuin/O=rare/PRMD=surf/ADMD=400net/C=nl/