>
> From the discussion on this mailing list from January 2019, I could not
> understand:
> - Does OpenDKIM sign in a way, that other software does not validate, or
> - does OpenDKIM not validate, emailis signed by Microsoft?
> - does the TXT record to be queried for validating DKIM-Signature exists
> in reality and OpenDKIM does not obtailn it for
> the purposes of validation?
> - Who creates that Authentication-Results (AR):, that cannot be parsed by
> OpenDKIM? If other sites creates them, then
> the local system shall add its own AR header and ignore what the other
> site inserted.
> - Does the validation work, if the same email is sent to hotmail, google
> and yahoo?
The only issue I'm seeing is with messages signed by Microsoft do not
validate.
OpenDKIM is unable to parse the authentication-results: header field
resulting in OpenDMARC failing to verify the messages signature
In the posted example, DNS TXT selector1-Q2e-onmicrosoft-com._
> domainkey.Q2e.onmicrosoft.com exists now, perhaps the local DNS server
> cannot fetch it.
>
No, that was the first thing I thought of. DNS resolves them with no
problem.
> but opendkim 2.10.3 normalizes it to "Header:<new line>text".
>
> This is fixed on the develop branch, with opendkim 2.10.3 validation will
> fail, cf.
> https://sourceforge.net/p/opendkim/bugs/226/ .
This may very well be the cause of the problem. Is the patch usable? Or is
it better to just wait for an official release at this point?
The persons in TDP are currently overloaded.
> TDP is non-for profilt orginizations.
That explains a lot. The efforts of everyone involved at TDP is greatly
appreciated
On Thu, Jan 31, 2019 at 3:32 PM Дилян Палаузов <dilyan.palauzov_at_aegee.org>
wrote:
> Hello,
>
> Microsoft tends sometimes to send emails like:
>
> Header:<new line>
> <spaces/tabs>text
>
> which under relaxed canonization is converted to
>
> Header:text
>
> but opendkim 2.10.3 normalizes it to "Header:<new line>text".
>
> This is fixed on the develop branch, with opendkim 2.10.3 validation will
> fail, cf.
> https://sourceforge.net/p/opendkim/bugs/226/ .
>
> The README was recently updated to describe cases, where sendmail can
> break the signatures.
>
> My reading of RFC 6376, section 3.2:
>
> tag-list = tag-spec *( ";" tag-spec ) [ ";" ]
> tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
>
> is that whitespaces can be left out. So v=;a=;c=; without spaces and
> with content after the equal sign is
> syntactically valid.
>
> From the discussion on this mailing list from January 2019, I could not
> understand:
> - Does OpenDKIM sign in a way, that other software does not validate, or
> - does OpenDKIM not validate, emailis signed by Microsoft?
> - does the TXT record to be queried for validating DKIM-Signature exists
> in reality and OpenDKIM does not obtailn it for
> the purposes of validation?
> - Who creates that Authentication-Results (AR):, that cannot be parsed by
> OpenDKIM? If other sites creates them, then
> the local system shall add its own AR header and ignore what the other
> site inserted.
> - Does the validation work, if the same email is sent to hotmail, google
> and yahoo?
>
> In the posted example, DNS TXT selector1-Q2e-onmicrosoft-com._
> domainkey.Q2e.onmicrosoft.com exists now, perhaps the
> local DNS server cannot fetch it.
>
> To the curios of you, asking why there is no OpenDKIM release made, that
> includes the fix for the for-3years-known-
> immediate-newline-after-the-colon and other errors, my information is:
>
> - OpenDKIM is managed by the Trusted Domain Project (TDP) and any change
> on the code means legal obligations for the TDP
> in terms of IP, bylaws, and some requirements towards the code quality.
> The persons in TDP are currently overloaded.
> TDP is non-for profilt orginizations. For half a year or so TDP is
> looking for additional persons to work on TDP. This
> persons have to be local, meaning more or less that only if one lives in
> San Francisco, has preferably also written some
> RFCs, and is not overloadad, will s/he be entitled to release a new
> version OpenDKIM, that is to the current knowledge
> error-free.
>
> For the record, linking with libunbound for doing DNSSEC fetches within
> opendkim, neither the code on master nor on the
> develop branches works, cf.
> https://github.com/trusteddomainproject/OpenDKIM/issues/14.
>
> Regards
> Дилян
>
>
>
Received on Thu Jan 31 2019 - 22:13:48 PST