Ned Freed writes:
> The obvious issue is that it makes it possible to create myriad
> incompatible but nevertheless legitimate variants of DKIM. Since an
> important aspect of DKIM is use by bilateral agreement, and since
> nothing prevents you from attaching multiple DKIM-Signature header
> fields, even if this happens I don't see it as a problem.
Multiple signatures with the same basic semantics ("the domain in 'd='
vouches for the mailbox in From:", to paraphrase Dave Crocker) from
the same signatory clearly increases complexity, of handling for third
parties as well as of interpretation by recipients.
The scenario that worries me is not that Yahoo! will choose to apply
GMail-style conditions in a separate DKIM-Signature field from their
"native" DKIM-Signature field. It's the scenario where they *don't*,
and Mediators (and Recipients) have to adjust to new "critical" tags
every time a large mailbox provider has a protocol brainstorm or
suffers a security breach.
> I don't see [ignoring criticality] as likely to happen with DKIM
> for several reasons. For one thing, the failure to interpret a
> paritcular DKIM-Signature field isn't supposed to render the
> message unprocessable - in fact it's required that it not have that
> effect.
By design, DMARC renders that requirement inoperative, and a
"p=reject" policy is intended to render messages unprocessable exactly
when a particular DKIM-signature is invalid. DKIM may not need to
worry about it, but we do.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
