headers
Barry Leiba | 31 Jul 2012 03:19
Picon
Favicon
Gravatar

Update to RFC 5322 to allow "group" syntax in the "from" header field

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.

Barry
_______________________________________________
ietf-822 mailing list
ietf-822 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822
Permalink | Reply |
headers
Hector Santos | 31 Jul 2012 05:21
Favicon

Re: Update to RFC 5322 to allow "group" syntax in the "from" header field

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
(Continue reading)

Permalink | Reply |
headers
John R Levine | 2 Aug 2012 19:39

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

Executive summary: I sent myself some messages with an empty group in 
From: headers to see what various MUAs did with them.  Nothing broke.

* Alpine (my normal client)

Displayed OK.  Invented a matching Reply-To: line.  If I reply, the To: 
line is empty.

* Thunderbird

Displayed OK. Reply put the same empty From: group on the To: line, 
rejects attempts to send it with a message saying to fix the To: line.

* Evolution

Displayed OK. Reply has a blank To: line.

* Android mail

Displayed OK. Reply has a blank To: line.

* Squirrelmail (popular webmail IMAP client)

Displayed OK, reply put the null group on the To: line and let you try
to send mail to it.

* Yahoo Mail

Filed as spam but displayed reasonably.  Reply had an empty To: line.
(Continue reading)

Permalink | Reply |
headers
Mark Martinec | 8 Aug 2012 16:40
Picon
Picon
Favicon

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

John R Levine wrote:
> Executive summary: I sent myself some messages with an empty group in
> From: headers to see what various MUAs did with them.  Nothing broke.
> [...]
> * Thunderbird 
> Displayed OK. Reply put the same empty From: group on the To: line,
> rejects attempts to send it with a message saying to fix the To: line.

Ditto for kmail 1.13.7 (KDE 4.8.4).
  (although kmail misparses (but survives) the more complex example
  in RFC 5322 Appendix A.5 - but that is another story)

Also tested a content filter Amavis, it parses the address-list syntax
in a From header field correctly, including the RFC 5322 A.5 example.

Hector Santos wrote:
> 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). That will make the first address id "A Group:Ed Jones"

Semantically a group name behaves as a display name, so
in some generalized meaning I don't find it incorrect
to concatenate a group (display) name to every display
name in its group-list.

One comment on the change:

-   In either case, an optional reply-to field MAY also
-   be included, which contains the field name "Reply-To" and a comma-
-   separated list of one or more addresses.
(Continue reading)

Permalink | Reply |
headers
John Levine | 8 Aug 2012 23:30

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

>In other words, I think the "Sender" should be required
>when a "From" header field specifies a group with an empty
>list of mailboxes.

This is a reasonable suggestion, except that the primary motivation
for this change is EAI messages downgraded by POP or IMAP delivery
agents.  If the addresses on the From: or Reply-To: line are
non-ASCII, there is no way for an ASCII MUA to display or reply to
them, so the idea is that the header will be rewritten to something
like this:

  From: an international address :;

So either there's an existing Sender header, which might itself need
to be downgraded, or there isn't, but either way there's no promise
that there is a non-ASCII address that could be put in the Sender.
So it's not gonna happen.

R's,
John

PS: EAI went around for years trying to come up with a general way to
allow non-ASCII mail software to read and reply to EAI messages, and
finally gave up.  See the experimental RFCs and the mailing list for
details.

--

-- 
Regards,
John Levine, johnl <at> iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
(Continue reading)

Permalink | Reply |
headers
Keith Moore | 8 Aug 2012 23:42

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

I intensely dislike what EAI has done to email interoperability, and I 
don't think that IETF should have ever standardized email addresses that 
wouldn't work with legacy mail processing software.

Having said that, there's been a longstanding need for a non-replyable 
originator address in a wide variety of situations.   I'm not 
particularly enamored with the idea of using group syntax to represent 
such an address, but it might be better than some of the alternatives.

Keith

On 08/08/2012 05:30 PM, John Levine wrote:
>> In other words, I think the "Sender" should be required
>> when a "From" header field specifies a group with an empty
>> list of mailboxes.
> This is a reasonable suggestion, except that the primary motivation
> for this change is EAI messages downgraded by POP or IMAP delivery
> agents.  If the addresses on the From: or Reply-To: line are
> non-ASCII, there is no way for an ASCII MUA to display or reply to
> them, so the idea is that the header will be rewritten to something
> like this:
>
>    From: an international address :;
>
> So either there's an existing Sender header, which might itself need
> to be downgraded, or there isn't, but either way there's no promise
> that there is a non-ASCII address that could be put in the Sender.
> So it's not gonna happen.
>
> R's,
(Continue reading)

Permalink | Reply |
headers
Barry Leiba | 9 Aug 2012 06:10
Picon
Favicon
Gravatar

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

> One comment on the change:
>
> -   In either case, an optional reply-to field MAY also
> -   be included, which contains the field name "Reply-To" and a comma-
> -   separated list of one or more addresses.
> +   In either case, an optional reply-to field MAY also
> +   be included, which contains the field name "Reply-To" and a comma-
> +   separated list of one or more addresses (either mailbox or group
> +   syntax).
>
> I think the original statement should be left alone,
> the document shouldn't be touching a "Reply-To" semantics,
> which I already find problematic (what's the point in having
> a group with an empty list of mailboxes in a Reply-To ?)

This is actually a clarification: Reply-To already allows either
mailbox or group syntax (in the ABNF), and I just thought it a good
idea, while I was touching that text, to make it clear in the text.

Barry
_______________________________________________
ietf-822 mailing list
ietf-822 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822
Permalink | Reply |
headers
Barry Leiba | 9 Sep 2012 23:09
Picon
Favicon
Gravatar

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

I have just posted draft-leiba-5322upd-from-group-04:
   http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/

That changes the definition of Sender as well as From, and also adds a
new "Applicability Statement" section that has an edited version of
some text suggested by John Klensin (thanks, John).  I like the
result, and I hope others do as well: it makes it clearer that we're
not recommending the general use of group syntax in From and Sender,
but are enabling it for limited use in certain situations (of which
the EAI use case is so far the only one).

Further comments before I ask Pete to run a formal last call on this?

Barry
_______________________________________________
ietf-822 mailing list
ietf-822 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822
Permalink | Reply |
headers
Ned Freed | 10 Sep 2012 08:17

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

> I have just posted draft-leiba-5322upd-from-group-04:
>    http://datatracker.ietf.org/doc/draft-leiba-5322upd-from-group/

> That changes the definition of Sender as well as From, and also adds a
> new "Applicability Statement" section that has an edited version of
> some text suggested by John Klensin (thanks, John).  I like the
> result, and I hope others do as well: it makes it clearer that we're
> not recommending the general use of group syntax in From and Sender,
> but are enabling it for limited use in certain situations (of which
> the EAI use case is so far the only one).

> Further comments before I ask Pete to run a formal last call on this?

It occurs to me that now that sender has changed from

    sender = mailbox

to

    sender = address

Since address can be a group, and a group can contain multiple addresses, we've
left a crack through which the syntax allows multiple address to slip into a
sender field.

I suppose we could define sender as something like this:

    sender = mailbox / (display-name ":" (mailbox / CFWS) ";" [CFWS])

But this seems kinda ugly to me. I think a note to the effect that at most one
(Continue reading)

Permalink | Reply |
headers
Barry Leiba | 10 Sep 2012 21:26
Picon
Favicon
Gravatar

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

> It occurs to me that now that sender has changed from
>
>     sender = mailbox
> to
>     sender = address
>
> Since address can be a group, and a group can contain multiple addresses, we've
> left a crack through which the syntax allows multiple address to slip into a
> sender field.
...
> I think a note to the effect that at most one
> address can appear in a sender group construct would suffice.

I have this change queued up:

OLD
   If the from field contains more than one address (mailbox or group) in the
   address-list, then the sender field, containing the field name "Sender" and a
   single mailbox or group specification, MUST appear in the message.

NEW
   If the from field contains more than one address (mailbox or group) in the
   address-list, then the sender field, containing the field name "Sender" and a
   single mailbox or group specification that refers to no more than
one mailbox,
   MUST appear in the message.

Barry
_______________________________________________
ietf-822 mailing list
(Continue reading)

Permalink | Reply |
headers
Ned Freed | 10 Sep 2012 22:12

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

> > It occurs to me that now that sender has changed from
> >
> >     sender = mailbox
> > to
> >     sender = address
> >
> > Since address can be a group, and a group can contain multiple addresses, we've
> > left a crack through which the syntax allows multiple address to slip into a
> > sender field.
> ...
> > I think a note to the effect that at most one
> > address can appear in a sender group construct would suffice.

> I have this change queued up:

> OLD
>    If the from field contains more than one address (mailbox or group) in the
>    address-list, then the sender field, containing the field name "Sender" and a
>    single mailbox or group specification, MUST appear in the message.

> NEW
>    If the from field contains more than one address (mailbox or group) in the
>    address-list, then the sender field, containing the field name "Sender" and a
>    single mailbox or group specification that refers to no more than
> one mailbox,
>    MUST appear in the message.

<pedant>

This only covers the case where the from: contains more than one address. What
(Continue reading)

Permalink | Reply |
headers
Barry Leiba | 10 Sep 2012 22:21
Picon
Favicon
Gravatar

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

>> OLD
>>    If the from field contains more than one address (mailbox or group) in the
>>    address-list, then the sender field, containing the field name "Sender" and a
>>    single mailbox or group specification, MUST appear in the message.
>
>> NEW
>>    If the from field contains more than one address (mailbox or group) in the
>>    address-list, then the sender field, containing the field name "Sender" and a
>>    single mailbox or group specification that refers to no more than
>>    one mailbox, MUST appear in the message.
>
> <pedant>
>
> This only covers the case where the from: contains more than one address. What
> about the case where the from is a single address but different from the
> sender?
>
> </pedant>

He-he-he.

Yes, so I'll also add that to the end of the paragraph after the grammar:

OLD
   Otherwise, both fields SHOULD appear.

NEW
   Otherwise, both fields SHOULD appear.  If the "Sender:" field
   specifies a group, that group SHOULD NOT refer to more than
   one mailbox.
(Continue reading)

Permalink | Reply |
headers
Ned Freed | 10 Sep 2012 22:47

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

> >> OLD
> >>    If the from field contains more than one address (mailbox or group) in the
> >>    address-list, then the sender field, containing the field name "Sender" and a
> >>    single mailbox or group specification, MUST appear in the message.
> >
> >> NEW
> >>    If the from field contains more than one address (mailbox or group) in the
> >>    address-list, then the sender field, containing the field name "Sender" and a
> >>    single mailbox or group specification that refers to no more than
> >>    one mailbox, MUST appear in the message.
> >
> > <pedant>
> >
> > This only covers the case where the from: contains more than one address. What
> > about the case where the from is a single address but different from the
> > sender?
> >
> > </pedant>

> He-he-he.

> Yes, so I'll also add that to the end of the paragraph after the grammar:

> OLD
>    Otherwise, both fields SHOULD appear.

> NEW
>    Otherwise, both fields SHOULD appear.  If the "Sender:" field
>    specifies a group, that group SHOULD NOT refer to more than
>    one mailbox.
(Continue reading)

Permalink | Reply |
headers
Ned Freed | 10 Sep 2012 23:30

Re: Update to RFC 5322 to allow "group" syntax in the "from" header

I should also add that I believe this change addresses the remaining issue.

				Ned

> > >> OLD
> > >>    If the from field contains more than one address (mailbox or group) in the
> > >>    address-list, then the sender field, containing the field name "Sender" and a
> > >>    single mailbox or group specification, MUST appear in the message.
> > >
> > >> NEW
> > >>    If the from field contains more than one address (mailbox or group) in the
> > >>    address-list, then the sender field, containing the field name "Sender" and a
> > >>    single mailbox or group specification that refers to no more than
> > >>    one mailbox, MUST appear in the message.
> > >
> > > <pedant>
> > >
> > > This only covers the case where the from: contains more than one address. What
> > > about the case where the from is a single address but different from the
> > > sender?
> > >
> > > </pedant>

> > He-he-he.

> > Yes, so I'll also add that to the end of the paragraph after the grammar:

> > OLD
> >    Otherwise, both fields SHOULD appear.
(Continue reading)

Permalink | Reply |
headers
Bill McQuillan | 10 Sep 2012 23:34
Picon
Favicon

Re: Update to RFC 5322 to allow "group" syntax in the "from" header


On Mon, 2012-09-10, Barry Leiba wrote:

> I have this change queued up:

> OLD
>    If the from field contains more than one address (mailbox or group) in the
>    address-list, then the sender field, containing the field name "Sender" and a
>    single mailbox or group specification, MUST appear in the message.

> NEW
>    If the from field contains more than one address (mailbox or group) in the
>    address-list, then the sender field, containing the field name "Sender" and a
>    single mailbox or group specification that refers to no more than
> one mailbox,
>    MUST appear in the message.

Does this mean that an empty group counts as one "addr-spec" for 
the purposes of requiring a Sender: field?

If not, it sounds to me as if an IMAP or POP server downgrading for a 
legacy client will have to "violate" this rule since a downgraded 
From: field will normally have only an empty group with the 
UTF8 addr-spec hidden in the name of the group. If that triggers 
the requirement for the server to create a Sender: field, the only 
thing available to put into it is the same empty group in the 
From: field.

My belief is that the downgrading process in this case can just 
leave the From: field with an empty group and presume that the
(Continue reading)

Permalink | Reply |
headers
Ned Freed | 10 Sep 2012 23:50

Re: Update to RFC 5322 to allow "group" syntax in the "from" header


> On Mon, 2012-09-10, Barry Leiba wrote:

> > I have this change queued up:

> > OLD
> >    If the from field contains more than one address (mailbox or group) in the
> >    address-list, then the sender field, containing the field name "Sender" and a
> >    single mailbox or group specification, MUST appear in the message.

> > NEW
> >    If the from field contains more than one address (mailbox or group) in the
> >    address-list, then the sender field, containing the field name "Sender" and a
> >    single mailbox or group specification that refers to no more than
> > one mailbox,
> >    MUST appear in the message.

> Does this mean that an empty group counts as one "addr-spec" for
> the purposes of requiring a Sender: field?

No.

> If not, it sounds to me as if an IMAP or POP server downgrading for a
> legacy client will have to "violate" this rule since a downgraded
> From: field will normally have only an empty group with the
> UTF8 addr-spec hidden in the name of the group.

Correct.

> If that triggers
(Continue reading)

Permalink | Reply |
headers
Bill McQuillan | 11 Sep 2012 10:37
Picon
Favicon

Re: Update to RFC 5322 to allow "group" syntax in the "from" header


On Mon, 2012-09-10, Ned Freed wrote:

>> If that triggers
>> the requirement for the server to create a Sender: field,

> Unless I'm missing something, it doesn't trigger. The rule is "more than one",
> not "other than one".

Re-reading 5322, you're right. I'm not sure why I thought that it
was "other than one".

--

-- 
Bill McQuillan <McQuilWP <at> pobox.com>

_______________________________________________
ietf-822 mailing list
ietf-822 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822
Permalink | Reply |
headers
John Levine | 8 Aug 2012 23:33

Re: Update to RFC 5322 to allow "group" syntax in the "from" header - how about sender?

The sender and resent-sender headers have the same issue on downgrade.  The current syntax
says they contain a mailbox.

I suppose that since they're optional a downgrade could just delete
them, but if we're allowing null groups in From, how about null groups
in Sender and Resent-Sender, too?

R's,
John
_______________________________________________
ietf-822 mailing list
ietf-822 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822
Permalink | Reply |
headers
Ned Freed | 9 Aug 2012 03:40

Re: Update to RFC 5322 to allow "group" syntax in the "from" header - how about sender?

> The sender and resent-sender headers have the same issue on downgrade.  The current syntax
> says they contain a mailbox.

> I suppose that since they're optional a downgrade could just delete
> them, but if we're allowing null groups in From, how about null groups
> in Sender and Resent-Sender, too?

+1

				Ned
_______________________________________________
ietf-822 mailing list
ietf-822 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822
Permalink | Reply |
headers
Barry Leiba | 9 Aug 2012 06:13
Picon
Favicon
Gravatar

Re: Update to RFC 5322 to allow "group" syntax in the "from" header - how about sender?

> The sender and resent-sender headers have the same issue on
> downgrade.  The current syntax says they contain a mailbox.
>
> I suppose that since they're optional a downgrade could just delete
> them, but if we're allowing null groups in From, how about null groups
> in Sender and Resent-Sender, too?

I need to go dig back and see why the issue only came up with From,
and not with Sender.  If it's an oversight, then you're right.  In any
case, conceptually, there's no reason why the "sender" of the message
couldn't be a group.

And just to clarify, this change is not just allowing *null* groups:
it's a change to allow *any* groups at all, null or otherwise.

Barry
_______________________________________________
ietf-822 mailing list
ietf-822 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822
Permalink | Reply |
headers
John R Levine | 9 Aug 2012 06:32

Re: Update to RFC 5322 to allow "group" syntax in the "from" header - how about sender?

> I need to go dig back and see why the issue only came up with From,
> and not with Sender.  If it's an oversight, then you're right.  In any
> case, conceptually, there's no reason why the "sender" of the message
> couldn't be a group.
>
> And just to clarify, this change is not just allowing *null* groups:
> it's a change to allow *any* groups at all, null or otherwise.

In From lines that makes sense since they're allowed to have multiple 
mailboxes.  Sender lines currently can only have a single mailbox, so I'd 
think that if we allow groups, they should allow only 0 or 1 mailboxes.

Regards,
John Levine, johnl <at> taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
Attachment (smime.p7s): application/pkcs7-signature, 2058 bytes
_______________________________________________
ietf-822 mailing list
ietf-822 <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf-822
Permalink | Reply |

Gmane