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

["Murray S. Kucherawy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of John C Klensin
> Sent: Wednesday, January 18, 2012 2:35 PM
> To: [e-mail]
> Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state?
> 
> 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.

I had thought there was objection to doing the received-state work by using Additional-Registered-Clauses, when my own MTA implementation experience suggests to me that it's actually ideal and that a new header field wouldn't be right for this.  Rather, what I'm seeing now is just an observation that the whole "trace field" thing is a little under-defined and we need to fix that.  I can buy that if we agree the two topics are in fact separate.

And an interesting observation: When I wrote RFC5451, my goal was to call Authentication-Results a trace field specifically because preserving the order of addition of Received fields with this mixed in is an important hint to figuring out where, and perhaps why, message authentication work ran into problems.  So I only wanted to piggyback on the "don't reorder or change this" rule that had already been laid out rather than re-stating it.  However, it also has an end-user purpose, which you correctly called post-delivery MUA information.  That part isn't exactly trace information per se, or maybe it is but it's actually MUA-actionable.  So that header field is actually a mix of both types of header field, I suppose: Agents should all follow trace header field handling rules, but it actually contains actionable stuff.  I'm hoping it doesn't thus deserve its own hybrid category...

One reason I prefer a Received extension for the received state work is because moving it into its own header field requires repetition of a bunch of information (hostname and date, for starters) that's already present in a corresponding Received field.  Thus, it seems it would add more clutter than it's worth to go that route.

> 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.

I think perhaps the amalgamated draft we seem to see forming between John's and SM's proposals might do well to talk about situations where each approach (Additional-Registered-Clause vs. new header field) is more appropriate.

> 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).

So far since the parsing of Received is mostly 1*(key value) up until the date part, parsing hasn't been a problem for systems I've worked on.  Most systems appropriately ignore things they don't understand.  However, naturally, I don't claim to speak for anything more than a fraction of the Received parsers out there.

-MSK