This idea is repeating the same thing again.
What would "DKIM-Delegate compliant" systems do when the "new
information" is missing? What do you do when there are protocol
faults? What are the protocol faults?
Mr Crocker, you have been leading the DKIM project since day one. You
have always been opposed to policy mail handling concepts that
includes rejection. Either you keep missing these essential finer
protocol faults points or just don't believe they are important and
nothing gets resolved for the resigner market. Your perspective for
the DKIM model has only been on the GOOD side of things. The honor
system when things are run perfect.
But the market has long been telling us there were other
functionalities to this. DKIM has also been about eliminating the bad
using a verifiable mechanism and thus allows us to stream the
potential good where you can do a "TRUST" assessment with the signer
domain. But there wasn't an IETF endorsed answer in how to filter the
bad. I really wish you would finally get that "Ah Ha" so that the
entire DKIM project can finally get completed. We can't keep doing
this half way wasting so much time.
The DKIM-delegate idea is asking for "change" again, yet the change is
unwilling to except the simplest change which is to simply lookup the
originating site policy.
So what is the problem? The idea of a lookup? A scalability issue?
A management issue?
The DKIM-delegate idea appears only to try to avoid doing a lookup,
but conceptually it the same idea of authorizing 3rd party resigners.
At best, it can serve as an optimizer, but only if the originator is
aware of the potential resigner which the receiver will need to do
more additional overhead to verify anyway. You are now asking for
additional receiver complex overhead when the simplest one has already
been available; a straight forward query based on the Author Domain
Identity (ADID) and Signer Domain Identity (SDID):
YesNo = IsSignerAllowed(ADID, SDID)
If you are finally telling us to begin thinking this way, well good. I
support it, but I don't see how DKIM-Delegate is going to address all
the key protocol faults that has always plagued the DKIM project.
--
HLS
On 6/7/2014 6:43 AM, Dave Crocker wrote:
Folks,
I've been stewing on this idea for awhile and Murray pressed to get it
into writing, adding his usual, significant enhancements to the original
concept. We've gone a couple of rounds before releasing it, but it's
still nascent enough to warrant gentle-but-firm handling. In other
words, comments eagerly solicited.
d/
-------- Original Message --------
Name: draft-kucherawy-dkim-delegate
Revision: 00
Title: Delegating DKIM Signing Authority
Document date: 2014-06-07
Group: Individual Submission
Pages: 10
URL:
http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-00.txt
Status:
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-delegate/
Htmlized: http://tools.ietf.org/html/draft-kucherawy-dkim-delegate-00
Abstract:
DomainKeys Identified Mail (DKIM) permits a handling agent to affix a
digital signature to an email message, associating a domain name with
that message using cryptographic signing techniques. The digital
signature typically covers most of a message's original portions,
although the specific choices for content hashing are at the
discretion of the signer. DKIM signatures survive simply email
relaying but typically are invalidated by processing through
Mediators, such as mailing lists. For such cases, the signer needs a
way to indicate that a valid signature from some third party was
anticipated, and constitutes an acceptable handling of the message.
This enables a receiver to conclude that the content is legitimately
from that original signer, even though its original signature no
longer validates.
This document defines a mechanism for improving the ability to assess
DKIM validity for such messages.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
