Re: [ietf-dkim] Issue #1524: Signature semantics
On Dec 12, 2007, at 9:42 AM, Jim Fenton wrote:
If their web form didn't block the use of example.com as a From
address, the message would be non-Suspicious (I think that's what
you mean by "compliant" in this context), which would violate the
likely intent of the publication of SSP "all". They could deal with
this in several ways:
- Prohibit example.com from being used in the web form
- Sign using a different domain or a subdomain, e.g.,
In this case, "articles.example.com" will obscure which header the
signature had been added "on-behalf-of". If the signing domain was
also "articles.example.com", this would be a third-party signature and
might make the message somewhat questionable. Mailing-list may sign
"on-behalf-of" the List-ID header, where any email-address might be
allowed in the From header (common for many mailing lists). The
mailing-list may wish to exclude the list-id email-address from being
allowed within the From header to prevent confusion as to which header
the message was signed "on-behalf-of". The domain may not care
whether an ambiguous "on-behalf-of" causes confusion. The email-
address could be that of some innocuous role that is never used for
other messages, where the Subject line also clearly indicates that the
message is from a list.
- If comparison of the local-part of the address continues in the
draft, sign with a specific address, e.g., i=articles(_at_)example(_dot_)com,
and have the web form prohibit that specific address
A domain can be completely compliant with an "all" assertion _without_
prohibiting specific email-address from being signed! A mailing-list
is often unable to authenticate identities, even those signed by
DKIM! DKIM is _prohibited_ in the charter from asserting identities,
nor would identity authentication represent a safe assumption.
Defaults allowed for the i= parameter permits an "on-behalf-of" header
to remain ambiguous. While some domains may wish to prevent intra-
domain spoofing by employing email-address constraints, such
constraints are not typically, nor is this defined for use with DKIM.
When a message contains a header where the From contains an email-
address within the signing domain, acceptance depends upon internal
signing domain policies. The "all" assertion DOES NOT imply an
identity associated with an email-addresses has been authenticated!
Such an assertion violates DKIM's charter, where DKIM is not
sufficiently suited for such use. DKIM lacks a means to distribute
per-user keys, lacks any mandate regarding identity authentication,
mechanisms to restrict email-address use, etc. Procedures and
policies to restrict the use of email-addresses, and whether messages
are permitted to include From headers containing other email-addresses
within the domain is completely a matter of internal policy. This
internal policy has nothing to do with an "all" assertion. The "all"
assertion only indicates to receivers, they can expect all messages
originating from this domain to have been signed.
Ensuring who can use an email-address is an entirely different problem
unrelated to "all" or "strict" policy assertions. Attempting to
extend DKIM in this manner appears to violate the charter as well.
NOTE WELL: This list operates according to