> 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.
The scenario you propose makes no sense: If Yahoo! or whoever does what
you describe, their messages would in effect have no attached signatures
until the receiving systems out there upgrade their software to handle
the new critical tags.
You can't count on much from large players, but I think you can count on them
not intentionally screwing themselves over.
> > 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.
You're missing the point. We're *changing* the design here so things no
longer work this way by associating this with a version bump. And we've
already confirmed that a significant number of implementations ignore
v=2 signatures.
Ned
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
