Subject: [spfbis] (no subject)

From: Arthur Thisell <[email-masked]>
Date: Fri, 31 Aug 2012 07:39:41 -0700 (PDT)

> And then the citation I provided from RFC5322 warns that despite this
> normative requirement, there exist programs that do such reordering,
> and one must not rely on order. 

Even the text you quoted from RFC 5322 said that:

   More importantly, the trace header fields and resent
   header fields MUST NOT be reordered, and SHOULD be kept in blocks
   prepended to the message.

You are taking warnings about non-trace fields and applying it to trace fields.

Lots of stuff breaks when programs violate MUSTs left and right.  Yes, programs like PROFS would re-order other header fields, but PROFS was old and almost (does?) predates SMTP.

A much more serious problem raised during MARID is that defining a new trace field, we may have to mark RFC 5321/22 as being updated.   This was clearly out of bounds for the MARID WG.  It is probably out of bounds here.

Maybe we should try to get IANA to create a registry for trace fields?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 09:53:17 -0700

> You are taking warnings about non-trace fields and applying it to trace fields.

The citation included this:

   It is important to note that the header fields are not guaranteed to
   be in a particular order.  They may appear in any order, and they
   have been known to be reordered occasionally when transported over
   the Internet.

That admonition is not specific to trace fields or to non-trace
fields, but to all fields.  Yes, of course, an agent that does
reordering contrary to the normative assertions violates the
specification, but that doesn't mean it doesn't happen.  So do we
presume compliance, or do we defend against extant non-compliance that
can confound end user agents or internal filters?  I seem to recall
from the DKIM work that there's far more recent MTA software (compared
to PROFS) that does undesirable reordering or reformatting of header
fields, including trace data.

> Maybe we should try to get IANA to create a registry for trace fields?

That was proposed either on ietf-smtp or apps-discuss during the
discussion of the received-state draft recently, but it didn't go
anywhere.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 10:18:55 -0700

At 07:39 31-08-2012, Arthur Thisell wrote:
>Lots of stuff breaks when programs violate MUSTs left and 
>right.  Yes, programs like PROFS would re-order other header fields, 
>but PROFS was old and almost (does?) predates SMTP.
>
>A much more serious problem raised during MARID is that defining a 
>new trace field, we may have to mark RFC 5321/22 as being 
>updated.   This was clearly out of bounds for the MARID WG.  It is 
>probably out of bounds here.
>

There is an expired draft about such a registry.  That's out of scope 
for this working group.

As mentioned above an update RFC 5321 or RFC 5322 is out of 
bounds.  I suggest that WG participants step back a little and look 
at the security angle instead of RFC 5321 or RFC 5322.  I posted the 
following some time back:

    - which attacks are out of scope (and why!)
    - which attacks are in-scope
      *  and the protocol is susceptible to
      *  and the protocol protects against

I would ask the above for the Received-SPF: header field.

Here's an excerpt of a message about an unrelated draft (the quote 
level is unrelated to SPFBIS messages):

>>The alternatives, as I see it, for the first sentence are:
>>
>>(a) Do you want people to go and write code so that the site administrator
>>      can enforce such a policy?
>
>I want server developers to take this into consideration and expose 
>any possible management knobs to administrators.
>
>>(b) Do you want people to "think" about this as a security consideration?
>
>Yes.
>
>>  (c) Do you want to enjoy the summer weather instead of generating more
>>      mail traffic?
>
>Most certainly, yes :-).

For context, the discussion was about finding an acceptable 
alternative without too much stress.  The author explained clearly 
what he wanted.  That made it easy to come up with a solution.  I 
don't know how to explain this.  I'll rely on the indulgence of WG 
participants.  The WG is exploring tangents when there is already 
prior work discussing about such a problem.

Regards,
S. Moonesamy