FYI -- this is a bit of a change to the data model of E-Mail messages, and - if deployed - will break existing code in mutt.
If anybody has time to look into this, that'd be great... Begin forwarded message: > From: The IESG <[email protected]> > Subject: Protocol Action: 'Update to Internet Message Format to Allow Group > Syntax in the "From:" and "Sender:" Header Fields' to Proposed Standard > (draft-leiba-5322upd-from-group-09.txt) > Date: December 5, 2012 23:12:25 +0100 > To: IETF-Announce <[email protected]> > Cc: RFC Editor <[email protected]> > > The IESG has approved the following document: > - 'Update to Internet Message Format to Allow Group Syntax in the "From:" > and "Sender:" Header Fields' > (draft-leiba-5322upd-from-group-09.txt) as Proposed Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Pete Resnick. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/ > > > > > Technical Summary > > The Internet Message Format (RFC 5322) allows "group" syntax in some > email header fields, such as "To:" and "CC:", but not in "From:" nor > "Sender:". This document updates RFC 5322 to relax that restriction, > allowing group syntax in those latter fields, as well as in "Resent- > From:" and "Resent-Sender:", in certain situations. > > This change is required to make the relationship between an > internationalized POP or IMAP server handing messages with non-ASCII > material in message headers and legacy POP or IMAP clients work in > some of the ways approved by the EAI WG. Without this change, such > messages effectively become completely undeliverable and may be lost. > > Working Group Summary > > The specification has been reviewed informally on the EAI and 822 > mailing lists and extensively discussed among EAI participants as > part of that effort (see above). Other than as noted below, there > have been no significant objections; smaller issues that have been > identified have already been addressed in the document. > > One individual has expressed concerns about the change represented by > the document. The core of that concern has been addressed by adding > an Applicability Statement to the specification and adjusting some > other text. He would like us to go further, perhaps abandoning the > change entirely. There seems to be consensus on the mailing lists > that have reviewed the document that his concerns are largely > unfounded (no one else has spoken up in favor of his point of view > and several people have made that observation) as well as primarily > focused on a protocol that has not been considered in the IETF, much > less standardized. > > Given that concern, the Security Considerations provisions should be > checked during IETF Last Call, but, especially if use of the change > is confined to carefully-selected cases as the document recommends, > the document Shepherd is convinced that there are no outstanding > important issues in that or any other area. > > The small amount of ABNF in the document has been checked carefully > and adjusted for maximum clarity. > > Document Quality > > Implementation of this change is basically trivial. Parsers for > email message headers already have to contain the necessary > provisions and code to support group syntax in other contexts, so > allowing that syntax for additional backward-pointing fields should > be just a matter of changing the applicable processing from one > already-present case to another. If any additional code or > processing is needed, it will be control the specific cases in which > the construction is allowed (as advised by the Applicability > Statement). > > > Personnel > > The document shepherd is John C Klensin. The responsible Area > Director is Pete Resnick. >
