[ietf-dkim] Re: Attempted summary
dotis at mail-abuse.org
Thu Jan 26 13:48:56 PST 2006
On Jan 26, 2006, at 12:22 PM, Mark Delany wrote:
>>>> Great. Will this also work with other (i.e. non-list) forms of
>>> I can't see why not particularly if:
>>> the mere presence of a signature does not imply anything more
>>> than taking responsibility for what emanates from that domain.
>>> If Mike is saying that explicitness is necessary, then I think
>>> that gels with Wietse.
>> I'm sorry Mark, this is a bit too terse for my semantic analyzer.
> I take that as a complement on this list ...
>> just says "this is what I claim passed through me". -ssp requires
>> a binding between the From: address (sender:? listId:?) and the i=
>> to validate the policy binding, if any.
>> Maybe it's just that I'm confused about what's being asked here.
> Right. So the question is, can a signature be constructed such that
> it doesn't interact with SSP to infer a binding above and beyond "I
> claim it passed through me"?
This idea has been explored in the dkim-options draft, although
perhaps not well explained. This draft includes a 'w' parameter
within the signature. Perhaps this could be described as the "What
role or verification semaphore."
The signature should allow expressions beyond "it passed through
me". The signature could indicate the purported role of the signer,
such as a signature on behalf of the MSA, MUA, mediator, or MDA. The
MSA/MUA could be differentiated by an indication via the key that the
signature is less trustworthy, which reduces the list to just MSA,
mediator, or MDA. Use of the MDA role for the signature would be to
ensure messages are not tampered with while en-route within the
receiving AdmD, especially with a practice that overlays the
signature with results. The overlay could be a means to prevent
anyone within the receiving domain staging abusive replay attacks
against those sending messages to the domain, or the domain itself,
as the MDA signature would never be accepted elsewhere.
The signature should also be able to indicate what had been verified
within the message. Currently, the 'i=' parameter provides a means
to express a validation of some email-addresses only within the
signing domain. If an opaque-identifier were used and verified,
there should also be a standardize way of expressing that this non-
email-address identifier has been verified, which can help resolve
email sources within a domain in a manner independent of an email-
Imagine a large provider signs any and all messages. Injecting a
Sender header alters the appearance of the email. An essential goal
of DKIM is to not alter the appearance. Sender header may also be in
conflict when this header is already included within the message
being sent. To allow the identification of unique sources with the
domain, the provider may instead include an account identifier within
the signature. The account identifier can be obtained from the
authentication at the MSA when accepting the message.
This account identifier is constructed in a manner to allow a
"redemption" table to be prefixed above the account identifier (O-
ID). This prefixed table value allows the revocation of messages
from a specific account, while allowing an easy means to re-enable
new messages from the account. This would not depend upon the use of
an email-address, which creates additional exposure to email abuse,
or a greater loss of privacy.
The same 'w' semaphore mechanism can replace the 'i=' parameter by
associating a header with a signing role. The MSA would always be
associated with the From, but never would the mediator. Perhaps the
mediator would always associate with the Resent-* header. Specific
codes could be created for specific headers. The signing semaphore
can indicate more than just roles, but also verification assurances.
These assurances may be the entire email-address is always verified
(w=d), just the domain of the email-address is always verified (w=a),
or that any email-address for this domain is always signed and
verified (w=b), or that this email-address is always signed and
If there is a policy either obtained or cached for a specific email-
address, it should differentiate between the source of the message
based upon the role of the signature. The current concept of the SSP
precludes making this differentiation, but a next generation of MUA
should have no difficulty being able to treat role identities
separately without degrading safety. Perhaps there could be
signaling semaphores that indicate a mediator is not allowed for a
scope of email addresses, as an interim solution. This was not
explored in the dkim-option draft.
More information about the ietf-dkim