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.
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.
The main point is they found an implementation reason to add an
verification option to relax the RFC 4871 MUST hash 5322.From requirement.
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.
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.
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.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html