Re: [ietf-822] Update to RFC 5322 to allow "group" syntax in the "from" header field

[Hector Santos <[e-mail]>]

Hi Barry,

Barry Leiba wrote:
> The EAI working group has a specific need to use "group" syntax to
> "downgrade" email addresses that are in UTF-8, when they are presented
> to a POP or IMAP client that does not understand such addresses.
> After a great deal of discussion of alternatives, replacing the UTF-8
> addresses with empty groups turns out to be the only reasonable
> approach.  But as it also turns out, RFC 5322 does not allow group
> syntax in the "from" header field.
> 
> I have written a draft that "updates" RFC 5322, making one change:
> allowing group syntax in "from":
>    http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/
> 
> EAI only needs to use this in presenting messages to certain POP and
> IMAP clients, and does NOT need it as messages wend their ways through
> MTAs.  That said, I think it would be better to remove the restriction
> than to document a specific-case violation.
> 
> Please review the draft and comment.  Please particularly note if you
> are aware of failures that will be caused by this change.  Please,
> *speculation* is much less useful than specifics of what you *know*
> will break.

hmmmmmm, not sure if I follow but wouldn't parser of From: field fail 
due to it not supporting group addressing and there isn't any 
expectation that it would be supported currently?

Currently, I am pretty sure our software will not break, but if a 
group address is added to From:, that will became part of the id 
(display name).  For example, using the current 5322 example but for 
From: instead of To:

   From: A Group:Ed Jones <[e-mail]>,[e-mail],John <[e-mail]>st>;

That will make the first address id

      "A Group:Ed Jones"

not

      "Ed Jones"

as part of the group "A Group"

I am pretty sure I see no harm I can see because if there is any 
database links, it would be off the email address and not the 
"passive" display name which can change at any time

I don't think its fair to preempt speculation here because you are 
asking mail people with long established code operations to review 
(Retest) quite of bit of 30+ years history of mail integration, 
including how 3rd party tools work with the mail framework. One can 
say, "oh it may not be harmful," but one may not know for sure if 
there is a mail bot, script, what have you that simply is not privy to 
how this UPDATE proposal theoretically continue with a harmless 
passive operation.  It is a change so its bound to break something, 
somehow.  Off hand, I don't see it hurting (us) because as a matter of 
logic we never did depend on the display name for any database link 
but than again, I am speculating.  I see the above issue and that 
could simply be a minor Display Rendering issue - what the user sees 
(is it really minor to him? it isn't "perfect" anymore).  That doesn't 
set the network replying though so I don't see it "breaking" at least 
the communications, just how display.

-- 
HLS