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

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

--On Thursday, January 19, 2012 03:44 -0800 Ned Freed
<[e-mail]> wrote:

>> 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.
> 
> John, while I agree that adding post-delivery information to
> Received: fields would be bad, I'm completely failing to see
> how the current proposal does anything of the sort. It's
> entirely about what sort of queue the  message ends up in and
> all of the cases clearly correspond to states prior to final
> delivery.

I thought I was clear in my initial note.  If I wasn't, I
apologize.  Let me try to say it differently:

It is reasonable to hypothesize that there is some information
that people might want to capture between when the message
leaves the Submission server and when it arrives on the user's
screen-equivalent that should not be loaded onto Received
fields.  One can make the argument that some things should be in
different header fields from "Received:" on the basis of parsing
idiosyncrasies associated with the changing definition of
"Received:" over the years (which I overstressed), concerns
about arbitrarily-long header fields (as with parsing, more a
concern for lower-quality implementations than high-quality
ones), precedent, or aesthetics, but the hypothesis remains.
My guess is that at least part of the dividing line will work
out to be associated with states before or after final delivery,
but that was an example, not a position.  Perhaps, for example,
some authentication information should be separated out as well.
Perhaps not.

I believe that we should take that issue up and start developing
a theory and guidelines before adding more stuff to "Received:".
I believe that any WG that is going to take up specifications
that propose adding "Received:" clauses should be obligated to
address this more philosophical boundary question about what
belongs there and, as has been pointed out, the issue of an
appropriate registry for such clauses.

I've expressed absolutely no opinion about whether the data
elements proposed in this particular specification belong in
"Received:" or not.  My guess is that they probably do.   If
that opinion is generally shared, I don't see any problem moving
ahead with this specification _as long as a serious effort is
underway in parallel to address the broader issue.

> If you think a rule about not adding MUA stuff to Received:
> fields needs to be stated explicity, the place for that is
> either in RFC 5321bis or in some sort of clarifying document.
> It makes no sense for it to be part of the present proposal.

Never suggested it should be.  All I've suggested is that, if
AppsAWG is going to take up this sort of proposal, it should be
prepared  to take on that classification question --more broadly
stated than "MUA stuff in 'Received:'" as well.   I haven't even
said "solve the general problem before addressing the specific
proposal".

>...
> And once again I'm failing to see any relevance. Yes, parsing
> Received: fields in the wild has some complications - in fact
> one of the complictions is the use of nonstandard clauses,
> which like it or not are present in the wild.  There's nothing
> we can do at this point to change any of this. But the present
> proposal is to add a clause with a single keyword arugment. I
> fail to see a parsing problem in that.

See above.

>> 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.
> 
> And those implementations are already failing on real world
> messages. I'm not seeing how this is going to have significant
> added impact.

Again, with the understanding that what I'm saying is "please
can we examine the tradeoffs" and not "don't do this", let me
suggest where significant added impact might occur.  Suppose I
have a moderately fragile real world implementation that is not
now failing because it was written on the assumption that
"Received:" fields are used for debugging information and it
doesn't actually have to parse them at all.  If it does
minimally parse them -- e.g., for loop detection purposes (which
mostly requires only that it recognize "Received:" header fields
that it might have added -- its belief in the "debugging" model
is such that it can and does simply ignore any "Received:"
header field that confuses it.   Now we come along and put
information in the "Received:" field to which it actually needs
to pay attention.   Its sloppy parsing and willingness to
discard confusing ones keeps it from getting to that information.

That actually does have significant added impact relative to
having the information in a separate header field that can be
analyzed without having to first parse "Received:" into its
components.  Of course, whether that "significant added impact"
is worse (because the weak implementation can't find the
information) or actually an improvement (because that
implementation might be encouraged to clean up its act) is one
of those tradeoffs I've been talking about.  As you know from
experience, I'm inclined to favor the "get them to clean up
their act" plan for such situations.  But I also recognize that
it sometimes works poorly enough to believe there is a tradeoff
that ought to be considered.

But, again, "considered" and "tradeoffs" arsn't "I think there
is anything wrong with this proposal".  I just want to see us
ask the question in a serious way.

> Again, the problems with Received: field parsing pale in
> comparison with the problems associated with having multiple
> order-dependent interrelated trace fields. Agents that reorder
> multiple occurances of the same field are rare, agents that
> lose or are incapable of "seeing" the relative order of
> multiple fields, not so much.
>...

Again, this (including the Sieve issue) is exactly the
discussion of tradeoffs I was hoping to encourage.  I'm not as
convinced as you are that the issues were settled with MIME i18n
and encoded words, but that is another matter.  And it seems to
me that the Sieve example argues against even using different
header fields/names for post-final-delivery information, at
least without a degree of hair-splitting about the definition of
final delivery  that we have so far managed to avoid.  If the
answer turns out to be "No, let's keep putting everything into
'Received:'", I have no problem with that.

    john