Subject: Re: [Emailcore] Ticket #7: Better definition for trace header fields

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 08 Mar 2021 16:31:33 +0000

On Sat, Feb 27, 2021, at 4:48 PM, Ned Freed wrote:
> > On 23 Feb 2021, at 12:58, Alessandro Vesely wrote:
> 
> > > On Tue 23/Feb/2021 18:34:39 +0100 Pete Resnick wrote:
> > >
> > >> On 23 Feb 2021, at 5:39, Alessandro Vesely wrote:
> > >>
> > >>> That ABNF seems to imply there must be at least one Received:.  Why
> > >>> then does the table in Section 3.6 show a Min number of 0 trace?
> > >>
> > >> Because the entire trace block is optional according to the ABNF
> > >> right above that table in 3.6.
> > >
> > > Ugh, that way you cannot have a lone Return-Path:?
> 
> > No. Is there a reason to ever have one?
> 
> I can think of at least two:
> 
> (1) IMAP APPEND of a (possibly draft) message (thus no Received: fields) where
>     you want to say what the MAIL FROM was/is/should be.
> 
> (2) Message has had all Received: fields removed for security reasons. (And
>     please don't bother telling me this is a bad idea, because you'd be
>     barking up the wrong tree. A large number of security reviewers say
>     otherwise, and when the choice is between no Received: fields and
>     no deployment, guess what wins.)

Right, this needs fixing in the ABNF. Does this affect proposed ABNF in 3.6.7 or ABNF in 3.5?
 
> > >> But optional-field is permitted at the bottom of the ABNF of fields
> > >> in 3.6, which would allow it to be used for something that is not a
> > >> trace field. (That is, optional-field appears twice in the 3.6
> > >> syntax.)
> > >
> > > optional-field is a poor choice, as it is restricted to header fields
> > > not specified in the I-D.  That includes fields specified in other
> > > RFCs as well as unspecified fields.
> > >
> > > Consider RFC 5293, where the *addheader* Sieve action is described
> > > like so:
> > >
> > >    By default, the header field is inserted at the beginning of the
> > >    existing message header.  If the optional flag ":last" is
> > > specified,
> > >    it is appended at the end.
> 
> > So you're saying that you want it to be syntactically OK (that is, in
> > the ABNF) to add one of the non-trace fields at the top of the message?
> > There's already a discussion of this at the beginning of 3.6 saying, "It
> > is important to note that the header fields are not guaranteed to be in
> > a particular order." I'd really rather not change the syntax any more
> > that strictly necessary.
> 
> > >>> The practice to collect trace fields at the top comes from the fact
> > >>> that it is convenient to write down one's 2 cents and then copy the
> > >>> rest without even parsing it.
> 
> > Indeed, not just convenient, but that it's often been damaging to go
> > mucking around in the contents of the message. 5321 talks about this.
> 
> True, but let's keep in mind that RFC 5321 is about message transport, and
> RFC 5322 applies more broadly. User agents muck around with the content
> of messages all the time. It's kind of what they are for...

Agreed.

Best Regards,
Alexey

---

From: Pete Resnick <[email-masked]>
Date: Mon, 08 Mar 2021 10:36:46 -0600

> Right, this needs fixing in the ABNF. Does this affect proposed ABNF 

It affects both, but it's changing the ABNF in 3.5 that is making me a 
bit nervous.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 08 Mar 2021 16:39:01 +0000

> It affects both, but it's changing the ABNF in 3.5 that is making me a 

Ok, thanks. (Should have been 3.6 above).