I think I can see a pattern developing in several of the technical threads.
I appears that Sender-ID's (Microsoft's) primary, urgent concern is with
Phishing.
I would imagine that major banks etc. are, quite properly, 'encouraging'
Microsoft to find a reliable way to show users that messages really are from the
purportedly-responsible organization.
Microsoft has, it appears, chosen to do this by testing the PRA for proof of
authenticity (Sender-ID) and will then later find some way to display on the MTA
some symbol of authenticity alongside the PRA (e.g. the HTTPS-like closed
padlock which Margaret Olsen suggested).
If I am right, then Microsoft is only interested in absolute proof of
authenticity.
It does not really need to distinguish the range of other test values, such as
'probably authentic', 'probably forged', 'proven to be forged', and it thinks it
does not need to consider message entities other than the PRA (except in special
cases).
Now others, entering this WG with some knowledge of SPF, are perhaps approaching
this differently.
As the 'last call' process requires, we are looking only at the Sender-ID drafts
on the table - we have no visibility of any 'greater plan'.
Now when these people analyse the functionality provided by Sender-ID _in
isolation_, they deduce that, like SPF, Sender-ID is intended to be a forgery
detection system, i.e. that it is supposed to be able to say categorically 'this
message is forged'.
This functionality is urgently required by MTA operators for the management of
threats other than Phishing.
What I think I observe is several people, myself included, making constructive
suggestions to improve the ability of Sender-ID to detect and handle forgeries,
and to do so in an SMTP-friendly way. We then get frustrated when Sender-ID's
supporters don't seem to be interested, or actively oppose what are believed to
be viable, constructive suggestions made in good faith.
Suppose my deduction is right - suppose the central objective of Sender-ID is
only to recognise authentic messages.
Suppose the greater scheme of which Sender-ID is a part has no need to
distinguish the different degrees of 'not proven to be authentic'.
Suppose, therefore, that the ability to _prove_ that a message was forged is not
a core requirement of Sender-ID.
If I am right, would it help to make harmonious technical progress in this WG if
the -core draft were amended to reflect this significantly-different emphasis in
the objectives of Sender-ID?
If so, it's probably more appropriate for Microsoft to propose the change, but I
will (as the process requires) if necessary.
If I am wrong in my deduction, then we should be able to close this thread quite
quickly; I'm not about to argue with Microsoft about what their objectives
actually are or should be.
----------------
I have classed this as a TECH-OMISSION because its a case of inserting/
modifying a requirement so that it matches the actual functionality being
specified; it closes a requirement-functionality gap which is what I interpret
the spirit of TECH-OMISSION to be.
Chris Haynes