Re: [apps-discuss] Adoption of draft-kucherawy-received-state?

[John C Klensin <[e-mail]>]

Hi.

I had a major system failure on Sunday, may have lost some hours
of email, and, while I got an alternate server up early Monday,
I have been only only slowly digging out.  The discussion seems
to have progressed significantly after I dropped out, including
a couple of new I-Ds.  While I hope those could be consolidated
to the degree possible, I think the idea of getting these things
registered is just great.

It may still be worth clarifying the point/suggestion I was
trying to make.

First, my concern was that loading too much disparate
information into "Received:", and especially intermixing
post-delivery MUA information with in transit MTA information
might not be a sufficiently good idea that we should do it
automatically and without thinking.   I didn't say "don't do
it", especially wrt this specific proposal.  I did suggest that
it was worth examining the question.

Second, please remember that, while RFC 5321 requires RFC
5322-conforming date-time fields, the <daytime> production of
RFC 821 is a little different.   The 821 syntax is not quite a
proper subset of the 5321/5322 syntax (e.g., seconds are
required in 821 and not in 5321/5322, 821 permitted two-digit
years, etc.).  Both 821 and 5321 require that both FROM and BY
appear, but I've seen that rule broken innumerable times.  5321
permits "TCP-info" to be supplied as a comment to BY (in
<Extended-domain>); 821 does not.  I've also seen liberties
taken with the specific format of the <date-time> (or
<datetime>) fields, especially by systems on the other side of
gateways that, e.g., use ISO dates (both 821 and 5321 warn
against (5321 says "MUST NOT") later systems messing with those
fields to try to "correct" them).  The multiple-path FOR form is
still seen in the wild, despite the security issues and language
in 5321 deprecating it. If multiple paths or mailboxes are used
with FOR, the beginning of the [Additional-Registered-Clauses]
becomes ambiguous, at least in theory.

I have no doubt that Ned, or anyone else even half as competent,
can sort this out and has implementations that do so.  I believe
that any MUA that is really as robust as 5322 MUAs are supposed
to be (indeed required to be to deal with other common erroneous
practices) can get it right.  But we see intermediate MTAs and
post-delivery filters trying to check these fields for bogus
information as part of spam assessments, and some of those are
not too bright.  

So what I was suggesting, and continue to suggest, is that it
may be time to think about whether it is better to keep adding
fields to "Received:" or whether one or more additional header
fields are in order.  Clearly the disadvantage of additional
ones is that something that treats anything appearing between
the first and last "Received:" header fields other than more of
them as bogus would get into trouble.  The advantage is that
something that wants to find one of these things for processing
purposes would know exactly where to look, rather than having to
parse "Received:" fields, looking for the relevant information,
and trusting that someone hasn't used the same
<Additional-Registered-Clauses> for something else (despite the
SHOULD NOT) in 5321 Section 4.4).

If we concluded that additional header fields, with different
names, were appropriate, it might still be the case that the
current "received-state" proposal would belong within
"Received:".  I'm just suggesting that we ask the question.

     john