The only thing self-asserting POLICY can do with some benefit it to
help prove the negative assertion - failure detection.
Positive assertions prove nothing and more information is required.
Currently, although it is out of scope, the WG consensus and
specifications has leaned towards Reputation and Domain certifications.
POLICY is about what is expected by the domain and anything short of
that expectation is evidence that there is some form of failure.
This is a solid engineering concept, Failure Detection, used
throughout the society inventions and processes of the world, e.g, a
nuclear power plant operations conditions - deviations from normal
expectations signals events.
For the non-nuclear simple email concept, the closest analogy is a SSL
certificate. When there is a detection of current SSL certificate
expectations, the BROWSER will inform the user:
- Expiration
- Common Domain mismatch A.K.A 3rd PARTY SIGNATURE!!
So there is really odd about using Self-Asserting DKIM POLICY methods
to emulate the receiver detection for policy failure.
Now, here is something that might be attractable to the CA market -
the OCSP "Online Certificate Status Protocol".
This use to be optional for the browsers. Today, browsers like FF
enabled it by default. OCSP is a 3rd party PING to the CA OCSP
servers to validate the certificate.
That is what the Reputation and Domain Certificate would desire and if
it can be pulled off, it might work.
But that is the "Batteries Required" problem for DKIM adoption.
For wide adoption, it would be useful for original domains to have a
self-assertion policy that allows receivers to easily detect failure.
--
Michael Deutschmann wrote:
On Mon, 12 Oct 2009, Ian Eiloart wrote:
It also seems to me that there must be a difference between "dkim=all" and
"dkim=discard". Publishing "discard" should mean that there's no
My understanding is that the all/discard distinction is orthogonal to
the mailing list issue.
I think the motivation for discard is to give guidance when someone
realizes a message seems to be forged after it has already been accepted
by their MX. This could happen, say, if a user at a DKIM-unaware ISP
installed a DKIM-analysing plugin into their MUA.
In this situation, there are only three choices:
1. Send a bounce message
2. Drop it silently
3. Ignore the validation failure and show it to the user anyway.
#1 is clearly unacceptable in this day and age, since in the frequent
case that the message was indeed forged, the bounce would be backscatter.
(Unless perhaps SPF asserted the provenance of the bounce address.)
dkim=discard hints that people in this situation should take option #2.
It would be appropriate for sites that really, really, don't want their
users to ever see a phish.
dkim=all hints that people in this situation should take option #3. It
makes mail less likely to be mysteriously lost if there is a screwup in
the signing of the legitimate mailstream.
Ideally, of course, all improperly signed mail would be rejected at CR LF
'.' CR LF, and this distinction would be irrelevant.
discard, all, and except_mlist thus cover three corners of a
square.
In theory we could have a fourth option, that provides for silent discard
of mail that fails DKIM and is clearly not legitimate mailing list
traffic. But I don't think anyone would ever use it.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html