"Hector Santos" <hsantos(_at_)isdg(_dot_)net> wrote:
Based on existing open source DKIM API code from a large MTA, they
must of come across signatures that did not include the 5322.From
signature binding requirement of RFC 4871 because it contains an
option to not enforce 5322.From hash binding in the DKIM.H header.
I don't think that's a reasonable conclusion do draw from this data point.
In other words, if the DKIM-Signature h= header does not have the
"from" value, then this code has an option to ignore this RFC 4871
requirement and allow this type of DKIM-Signature.
Although the API is technically violating RFC 4871, they must of did
this for a reason but I am not totally clear what all scenarios this
will cover with Author Domains who sign without the 5322.From bind.
Protecting messages from in transit modification was one of the DKIM design
goals. Excluding this user visible header from such protections is not a good
idea. This is an even worse idea than "l=".
The main point is they found an implementation reason to add an
verification option to relax the RFC 4871 MUST hash 5322.From requirement.
People implement all kinds of thing for all kinds of reasons. Don't depend very
much on the mere fact of an implementation tidbit.
My Technical recommendation.
1) For 4871bis, we should consider relaxing the 5322.From
binding requirement from a MUST to a SHOULD. This will help
justify its new words of "separating the signer domain from
the author domain." There is no separation until the 5322.From
binding requirement is relaxed.
As discussed during the original DKIM development effort, this is about
protecting content from modification. The base DKIM spec already doesn't treat
5322.from specially, so such a change in not needed to meet your specified goal.
2) We should consider a 5617bis (ADSPbis) to codify its semantics
regarding Author Domain only signature policies to include a:
Always sign by *anyone* Policy.
Currently 5617 (ADSP) defines the two policies:
all All mail from the domain is signed with an Author
Domain Signature.
discardable All mail from the domain is signed with an Author
Domain Signature........
Many people felt we were missing the "Signed by Anyone" concept which
did not help "authorized" 3rd party signers or the list servers who
are going to be resigning. To compensate, many viewed ADSP=ALL to
mean it allowed any signer, not just the Author Domain as defined by
the spec.
In fact, this same DKIM API includes ADSP support and it also
interprets ADSP=ALL as an anyone can sign concept as long as there is
a valid signature. There is no option in the software to follow
ADSP=ALL exactly how it it defined in 5871.
It sounds to me like a bug.
Since this is an API from a large MTA vendor, I would not ignore this
implementation "data point." If the suggestion is made the software is
"buggy" then we are back to a status quo of non-resolution of
conflicting issues regarding the author domain, 3rd party signers
and/or list servers.
Since anyone can generate a DKIM signature with a signing domain they control,
an unconstrained 3rd party signing policy means precisely nothing. Without some
kind of constraint (1st party only or a defined set of third party signers)
arbitrary senders could meet the policy requirements.
- 1.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html