Responding to this late, but I think there are some important points not
previously covered.
> On 10/3/2015 10:08 AM, John R Levine wrote:
> > I suppose the version bump to v=2 is an open issue, but I don't really
> > see what the problem is. Since the current spec says that unknown tags
> > are ignored, there's no way to add mandatory tags without a version
> > bump. I believe when this came up before, people looked at common DKIM
> > libraries including yours, the perl and python ones, and found that the
> > current code would all fail a v=2 signature, so the version bump should
> > do what we want it to.
> Claiming that something is mandatory, as part of a version bump, is
> meaningless, when the installed base will be using the older version and
> ignoring the supposedly-mandatory new feature.
There's always a context to terms like "mandatory". In this case the context
is that of v2 signatures. The term is hardly meaningless in that context.
> If the installed base can legally ignore a new feature, then it is not
> mandatory.
The nature of DKIM is such that many signatures end up getting ignored as
part of normal operation. That doesn't make any aspect of the various
mandatory aspects of processing those signatures any less mandatory.
> The only way to make a feature mandatory in a new version is to provide
> it in a fashion that makes it only available to folks adhering to the
> new set of mandatory features.[*]
> FWIW, this is equivalent to saying that adding new
> mandatory features is equivalent to creating a new
> protocol.
I suppose you can define it that way if you like, but doing so ignores
the substantive overlap both in terms of syntax, processing semantics, and
most important of call, usage.
> So if you want to modify DKIM to change the set of mandatory features,
> then specify that the signature use a /different header field name/,
> such as DKIM-Signature2. Only adherents to the new scheme will see this.
This approach has the significant downside that it's more costly in terms
of code. Not a lot more costly, and if John's proposal had significant
associated cost I'd say it's a wash.
But John's proposal isn't costly at all. As a result I'd say that of using a
different header versus building off existing version suport just about doubles
the complexity.
Given this, I need significant to see significant justification - such as
reports that existing implementations don't properly handle DKIM versions -
before I will support a proposal to use a different field.
Such reports have not appeared AFAIK.
> If the signer wants legacy folk who only understand older DKIM to also
> be able to evaluate a signature, then the signer needs to create two
> signatures.
That's not an argument for using a different field.
Ned
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
