Hello Ken,
despite being asked, you do not share the exact header, that cannot be parsed.
In order to do anything further, I repeat this for third and last time, you need to be in a possession of a message that
fails validation with OpenDKIM. Send this message to ymail/gmail/hotmail and see if they validate it.
If you are not in a possession of such a message, and you cannot obtain it, if you don’t share the failed AR-headers,
then nobody can help you further.
Regards
Дилян
On Thu, 2019-01-31 at 21:40 -0500, Ken wrote:
> > To my knowledge, OpenDKIM does not parse AR-headers, it inserts AR-header, which OpenDMARC parses.
>
> Jan 10 15:36:42 weaver sm-mta[28855]: x0AKafla028855: from=<angelo.fazzina_at_uconn.edu>, size=13144, class=0, nrcpts=1, msgid=<BN7PR05MB5859DDA9E65680D1B18A8C4A98840_at_BN7PR05MB5859.namprd05.prod.outlook.com>, bodytype=7BIT, proto=ESMTP, daemon=MTA, relay=mail-eopbgr750108.outbound.protection.outlook.com [40.107.75.108]
> Jan 10 15:36:42 weaver opendkim[4235]: x0AKafla028855: mail-eopbgr750108.outbound.protection.outlook.com [40.107.75.108] not internal
> Jan 10 15:36:42 weaver opendkim[4235]: x0AKafla028855: not authenticated
> Jan 10 15:36:42 weaver opendkim[4235]: x0AKafla028855: failed to parse authentication-results: header field
> Jan 10 15:36:42 weaver opendkim[4235]: x0AKafla028855: bad signature data
> Jan 10 15:36:42 weaver sm-mta[28855]: x0AKafla028855: Milter insert (1): header: Authentication-Results: weaver.campbus.com;\n\tdkim=fail reason="signature verification failed" (1024-bit key) header.d=uconn.onmicrosoft.com header.i=_at_uconn.onmicrosoft.com header.b=IbXOR6Eh
> Jan 10 15:36:42 weaver opendmarc[19796]: x0AKafla028855: uconn.edu none
> Jan 10 15:36:42 weaver sm-mta[28855]: x0AKafla028855: Milter insert (1): header: Authentication-Results: weaver.campbus.com; dmarc=none (p=none dis=none) header.from=uconn.edu
>
> > Please clarify
> > * where does that unparsable Authentication-Results header originate from
>
> Microsoft presumably
>
> > how the header looks exactly
> > If yahoo/gmail/hotmail validate the unchanged email, then the problem is probably with opendkim/your site.
>
> It's not my end. Microsoft emails are the only messages the server receives where there's consistent issues.
> I'm also not the only one seeing this issue.
>
> http://lists.opendkim.org/archive/opendkim/users/2018/12/3776.html
>
>
>
>
>
>
> On Thu, Jan 31, 2019 at 7:01 PM Дилян Палаузов <dilyan.palauzov_at_aegee.org> wrote:
> > Hello,
> >
> > you write, that
> > 1. OpenDKIM is unable to parse AR-header,…
> > 2. resulting OpenDMARC to fail
> >
> > To my knowledge, OpenDKIM does not parse AR-headers, it inserts AR-header, which OpenDMARC parses.
> >
> > Please clarify
> > * where does that unparsable Authentication-Results header originate from,
> > * what is OpenDKIM supposed to do with it,
> > * how the header looks exactly,
> > * how does the header inserted by OpenDKIM look exactly, and
> > * whether forwarding unchanged/redirecting/sending the problematic mail to yahoo/gmail/hotmail does validate DKIM-
> > Signature?
> >
> > If yahoo/gmail/hotmail validate the unchanged email, then the problem is probably with opendkim/your site.
> >
> > OpenDKIM is offered in source code. You can ask your distribution to include that patch. The patch was usable at the
> > time and is integrated in the develop branch (https://github.com/trusteddomainproject/OpenDKIM/commits/develop).
> >
> > I am not an oracle to tell you, whether it is better to integrate the three-years-old patch yourself, wait for a new
> > stable OpenDKIM version to be released and offered by your distribution, or to contact your distribution to integrate
> > just the significant patches.
> >
> > Regards
> > Дилян
> >
> > On Thu, 2019-01-31 at 17:13 -0500, Ken wrote:
> > > > 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 Fri Feb 01 2019 - 08:19:35 PST