>
> 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 - 02:41:02 PST