CURRENT MEETING REPORT Minutes of Detailed Revision/Update of Message Standards Working Group (DRUMS) Reported by Jim Conklin, CREN Session 1 Meta--issues Keith Moore chaired the Working Group meeting and began it with a brief review of the Working Group activities and mission. He noted that the mission of the Working Group is to: o clarify ambiguities o fix broken things o unify documents o not add new functionality Discussion highlighted the cost of breaking the installed base. Keith presented the scope of the Working Group as: o native Internet mail o don't relax standards for gateways (clearly specify conformance requirements) o doesn't include gateways, news, or MIME o does include header/envelope of mailing lists o specify 821 language (not UA functionality) o recommend UA behavior (but UA's have a lot of latitude) He raised several meta-Ñissues he wanted the Working Group to address, including: o What does it mean to be broken (Criteria for brokenness) o How do we deal with intractable issues (on which Working Group consensus appears impossible) o Criteria for making decisions (cost vs. benefit) o Possible choices, from recommending no change to deprecating an old feature and replacing it with a new one Discussion included what to do about references to RFC 821, and the extent to which the new document is to be all--inclusive. There was a rough consensus that a guiding philosophy should be to create a document that is sufficient to guide implementation of a modern SMTP agent. This allows reference to 821 for non--deprecated features which are not recommended or required to be supported by a current SMTP agent. Discussion on deprecation suggested that it would be useful to distinguish clearly between what is forbidden, undesirable but not forbidden, and unused and probably not harmful, but not generally useful either. Discussion suggested that brokenness includes situations in which: o mail is lost or misdirected, with no error message returned to document the unsuccessful delivery o situations occur in which compliant behavior causes unnecessary "user astonishment" The new document should update and clarify 821 in areas which have developed since it was written. In addition, it should clarify any other ambiguities, and it should document the oral traditions that clarify 821 and its successor RFCs. An example of a development subsequent to 821, for which clarification is desirable, is the domain name system. The document should address protocol errors, configuration requirements, and operational requirements. Where ambiguities exist in 821, they should be explicitly called out and either resolved, or, if the Working Group can't agree on a resolution, described with the effects of the various interpretations and the tradeÑoffs they involve. When the Working Group cannot reach consensus, it should, as indicated above, document the problem. The Working Group could punt to the current practice as a way of solving the problem, and it could spin off a separate group to pursue the issue and perhaps draft a new RFC proposing a solution. Criteria for decisions involving changes from previous practice should include the anticipated benefit versus the cost (disruption) to existing systems and the cost of implementation. It must take into account the long transition from an old behavior to the new behavior, with coexistence of both during the transition from one to the other. The Nature of the Document(s) Discussion moved on to the nature of the document(s) that the Working Group will produce. It was agreed that an introductory overview was not desirable because, based on previous experience, it tends to be read, without subsequent details, as the specification. However, a separate informational RFC providing such an overview was considered to be a good idea. There was consensus that multiple documents would be better than a single, all--inclusive document. (This is already the case, since mail depends on the underlying transport protocols described in separate documents.) One document should describe the underlying model for Internet mail (as a detailed specification, separate from the aforementioned overview). This should be referenced by the "821--bis" document currently being drafted, and also by the anticipated "822-- bis" document. This document should provide references to all the associated RFCs (probably including those that describe the underlying transport protocols). Keith noted that additional editors, with close collaboration among them, will be needed for this approach to be effective. The desirability of a separate document defining the ABNF was raised later in the discussion, with general agreement that such a document would be desirable and should also provide the ABNF definition of a common set of the "terminals" used by other RFCs (such as Òcharacter,Ó Òdigit,Ó etc., but not including, for example Òdomain.Ó). Addressing and Routing Issues In light of 1123's efforts to encourage the use of MX records to replace source routing (which the draft did not seem to reflect), concern was expressed about the handling of the forward path in the draft. There was general agreement that the document should be revised to encourage use of MX rather than of source routing, but should also describe the proper behavior of the SMTP agent when presented with a source route. There was no consensus as to precisely how this should be done, or whether it should be moved into a separate document (1123 suggests three alternative possibilities, each of which is acceptable.). As I recall, they are: use the source routing; ignore the source routing while using MX to resolve the mailbox address; and, refuse to send the sourceÑrouted message. Klensin noted that the draft already incorporates material from RFC 974 on MX records, which should help encourage compliance with 974's requirements for MX. No objection was raised. Klensin also noted that the final documents would resolve the differences between RFC 821 and 822 regarding mail routing and addressing. Keith promised to work with the individual authors and editors to resolve the issue of whether mail addressing and routing should be handled in a separate document or left in the present draft. Other Commands There was an extended discussion about EXPN and VRFY. Concerns were raised about the close linkage between the two in the present draft, and about whether each should be required and whether the draft noted this issue. Discussion indicated that VRFY was felt to be more important than EXPN, and that a stronger verification than presently required and/or provided would be useful. There seemed to be a consensus that both are useful for debugging purposes and should be required for debugging use only. Participants were encouraged to send their suggestions to the list. It was noted that there was no mention of the 521 reply code. The explanation was that it is only an experimental protocol at present and that there are evidently problems with part of it. TURN also evoked considerable discussion, with the consensus being that it should be deprecated in favor of other mechanisms now being discussed to solve the same problem. (Despite the fact that there are also proposals in progress to provide adequate security, no one spoke in favor of retaining TURN.) There was consensus to explicitly deprecate SAML, SOML, and SEND, while retaining them as commands that could be used by older systems without violating the new standard. (The alternative of remaining silent about these three was discussed and rejected.) As mentioned earlier, it was agreed that a separate document should define the ABNF notation and a limited set of basic ABNF definitions of broad relevance for reference by the other documents. A concern was raised about how to handle time--outs, but the meeting timed out without resolution of this issue. SESSION TWO Reported by Keith Moore, University of Tennessee The group considered several issues under a limited discussion rule, with time for discussion being limited to 20 minutes per issue. 1. Addressing issues: o Remove several characters (including "[", "]", and ".") from the list of RFC 822 "specials," and thus make addresses of the form The majority of the group preferred to keep the current list of special characters, but to explicitly advise implementors about commonly occurring (but syntactically illegal) forms. There were, however, a few objections to this proposal. o On a proposal to remove certain legal but never--used constructs from the grammar for addresses, such as "#" domain literals (from RFC 821), and "[\]]" as a domainÑliteral (from RFC 822) There were no objections to this proposal. o On IPv6 domain literals The consensus of the group was that an IPv6 domain literal is necessary for rare situations, but that the syntax proposed for IPv6 addresses will cause many existing applications to "break" (mail user agents and web browsers were mentioned specifically). The consensus was that the DRUMS WG should formally notify the Applications area directors and the IESG of this problem. Some alternatives were suggested but no agreement was reached on which alternative was most desirable. o On use of 822 as a message submission protocol (e.g. "sendmail t") Discussion was deferred to the mailing list. o On Use of SMTP as a message submission protocol Discussion was deferred to the mailing list. o Discussion on Resent--headers The chair summarized the issues with Resent-- as follows: Resent-- headers are currently interpreted differently by different UA's, and used to indicate both automatic and manual mail forwarding as well as by some mailing lists. The text in RFC 822 regarding the purpose of Resent-- is ambiguous. For user agents, the real issues are the interpretation of Resent-- From and Resent--Reply--To. Some MTAs put special requirements on handling mail with Resent-- headers, such as insisting that Resent-- headers appear in matched sets (e.g. Resent--From and Resent--To) The ensuing discussion resulted in the following suggestions: a. Resent-- headers to be retained, but only to supply information to human readers; interpretation by user agents to be discouraged. b. Clarify that Resent--headers are intended to be added for "manual" resends only, not for autoÑforwarding or by mailing lists. c. Advise as how to generate Resent-- headers when "resending": in what order, and at the top or bottom of the header. d. Advise as how to resend resent messages. o On the use of Usenet headers in eÑmail: There was consensus that: a. when Usenet header names are newly adopted for use in email, they should have the same meaning as in Usenet. b. existing and unique Usenet header names should be reserved c. IANA should maintain a registry of header names. o Received header issues Various chances to Received headers were proposed, including: o changing the format to improve ability of MTAs to detect loops o an extension mechanism for new sub--fields o a requirement for MTAs to include the source network address (to deter SPAM) o clarification of the meaning of the date subfield of a received header o a list of conditions when received headers should be generated Specific proposal(s) are needed; discussion is referred to the mailing list. o On bounced mail The group agreed to: o include advice on how to constrict a non--delivery report in the revised SMUT specification (e.g. it should contain the failed address and some indication of the cause of delivery failure) o suggest (not require) NOTARY format The group decided that issues relating to how to gateway mail into weird environments (e.g. that don't have separate header/envelope return addresses or that cannot produce reasonable nonÑdelivery reports) were out--of--scope for this group. o URLs pointing to iana.org The consensus of the attendees was to include URL references to the IANA header registry (and perhaps other IANA registries), and to ask IANA to maintain registry documents at URLs under the iana.org domain. o On the subject of character sets: The suggestion was made to incorporate the text from the MIME specifications regarding which characters are likely to survive mailing. This should appear in the revised 822 specification, with a reference to that text in the revised SMTP specification. o Issues with Sender field The Sender field cannot be relied on because MTAs, UAs, and list expanders vary considerably in when they generate such a field and what address is placed in that field. There was near--unanimous opposition to the Chair's suggestion that field like Sender (which, according to RFC 822, should never be used in automatic replies) could be deprecated and replaced with one or more new and better--defined fields. There was general agreement that the use of the word "authentic" with respect to Sender addresses was misleading in that Sender provides no guarantee of authenticity, but that it was still useful to identify the actual sender of a message even if authenticity could not be assured by such a mechanism. o Requirement for at least one of To/CC/Bcc RFC 822 requires at least one of these fields; a proposal had been made to eliminate this requirement. The group agreed that at least one of these headers should be included in each message for the benefit of human recipients who want to know why they received the message; the revised 822 spec should explain this. On the other hand, the presence of at least one of these headers should not be a requirement for processing (e.g. relaying) of the message, and there is thus no need to require one of these fields in the grammar. o In--reply--to header The consensus of the group was to recommend using the message-- id of the replied--to message in the in--reply--to field of the reply (presumably while retaining the other (no message--id) option for backward--compatibility or for when replying to messages with no message--id) The suggestion was made to use the behavior specified in RFC 1036. o On requirement for MTA support for Postmaster address The consensus was that an SMTP server should verify that its Postmaster address is valid (to ensure compliance with the requirement that it accept mail to Postmaster). The rules for this are somewhat difficult to define (what does "valid" mean, and what action should be taken if this fails?). It was suggested that this is similar to the requirement for implementation of the SMTP VRFY command, in other words, the SMTP server should internally attempt to verify the Postmaster address as if it were doing a VRFY on the Postmaster address.