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

[Ned Freed <[e-mail]>]

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

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.

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

And once again I'm failing to see any relevance. Yes, parsing Recieved: 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.

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

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

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.

Sieve is actually an example of this. Sieve can perform tests on all occurances
of a given field or it can be restricted to look at the first, second, Nth,
N-1th, etc. occurance. So as long as you have some idea of how many Received:
fields are added prior to delivery in a given environment (and you usually do),
you can write tests that check the correct field or fields and don't get
confused by stuff provided by stuff outside the administrative domain (which is
inherently unreliable).

But there's no way to test something like "the Foo: field that appears after
the Nth Bar: field". And an extension that does that is going to be very, very
ugly, no matter how you slice it. And that ugliness is going to make using such
an extension quite problematic, even for fairly experienced script
constructors.

Again, we went through all of this stuff in tedious detail back when MIME
header internationalization was being standardized. The encoded-word propsoal
certainly has had issues (mostly poor quality implementation - for some reason
people just don't seem to get that certain activities have to be performed in a
specific order), but it was small beer compared to the problems we would have
had with multiple interconnected fields.

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

And my answer, I'm afraid, is still a very emphatic NO.

				Ned