Thanks again for your helpful comments. We seem to be thinking along
pretty much the same lines.
I'll have a look at that. What I had in mind was a Transmitted: trace
header that parallels the Received: header, and some new "with protocol"
types (e.g. esmtpt) to assert that the client had done some extra
checking. But this would add a lot of bloat for one bit of information so
perhaps it should just be left in the logs. Dunno.
Well, that really depends on what you mean by "parallel". A field a client can
insert saying what server it was talking to, what protocol choices were made,
and so on and so forth, is fine.
Right, that's what I've tried to describe in the -01 version.
But the minute you try and link the Transmitted: field to the
corresponding Received: field the client hasn't even seen yet, that's
not a good idea. There's too much piddling around with headers in
practice to use such linkages.
Reusing basic Received: field syntax is also fine, and probably the right
approach if we are to define such a thing. But I again wonder if this belongs
in this proposal or would be better off in a separate document.
Yes. I'm still half inclined to rip out the Transmitted: stuff. I mainly
wrote it up as a straw man to see what others think of the idea.
Hmm, yes, I should add something about DSNs. Thanks. I think it might be
sufficient to register a new MTA-name-type, perhaps "dane".
Ah, that's clever. Avoids the need for a new field. I like it.
... though I wonder if it has interop implications. As far as I know the
only MTA-name-type that has been used is "dns".
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
Rockall, Malin, Hebrides, Bailey: Easterly or northeasterly 4 or 5, increasing
6 at times in Rockall. Moderate, occasionally rough in Rockall. Rain at times
in Rockall and Malin, otherwise fair. Moderate or good, occasionally poor in
Rockall and Malin.