Murray,
Interesting and intriguing perspective. I like it.
Perhaps I missed it, but I don't recall seeing such a coherent, focused and
pragmatic requirements statement in this discussion, so far.
But note that what you are describing has nothing specific to mail-vet.
Really.
You are describing a generic requirement for trusted information exchange
between two nodes that are possibly within a trust domain. The fact that the
information is, itself, security-related might affect some choices in the
design, but not in a way that is specific to mail-vet (or the fact that it is
security-releated...) The other that might be a bit different is to protect a
specified header field. Again, I doubt that affects design choices all that much.
So mail-vet *might* be motivating it, but it is really an independent technical
requirement. It warrants an independent technical specification.
Let me repeat this: To the extent that the current specification is for a data
format, rather than an end-to-end exchange service, then an effort to satisfy
this requirement belongs to a separate document.
And, of course, there are *lots* of ways to satisfy it. That's a further reason
to avoid burdening the current, core data spec with its details.
d/
Murray S. Kucherawy wrote:
Dave CROCKER wrote:
This begs the question: why bother to do the first validation; why
not simply wait and let whoever would have validated the first instead
validate the first?
If the only authentication method being applied at a site is DKIM or
other things that don't care about the path, that works. But that's a
big "if", and moreover means all consumers of authentication results
data must now learn all local path-agnostic methods being used to
evaluate messages.
The desire here is to secure arbitrary authentication results data
between the border MTA and the consuming MUA. DKIM is one way that
could be achieved, meaning the consumers need to learn one and only one
message authentication scheme in order to validate that one piece of
protected internal data.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
