Hello Ken,
the message contains a new line before Thread-Topic. So the following, unparsable “authentication-results; spf=none
(sender IP is )smtp.mailfrom=xxxxxx_at_doccs.ny.gov; ” is not part of the email. It is unparsable, because there is a
semi-colon instead of a colon after the header-field.
If it were part of the message headers, I would classify the mail as spam (quarantine) anyway, as putting semi-colon
after authentication-results or any other header field is an indication for spam.
The email does not include Authentication-Results header, inserted by your site, containing the DKIM-Signature
evaluation, that is why OpenDMARC ignores DKIM-Signature and, redirecting such a message means also SPF and therefore
DMARC will fail.
The DKIM-Signature suggests obtaining the DNS TXT record selector1._domainkey.doccs.ny.gov , but this record does not
exist, so OpenDKIM cannot validate DKIM-Signature.
Looking at the code generating “Jan 10 15:36:42 weaver opendkim[4235]: x0AKafla028855: failed to parse authentication-
results: header field”, OpenDKIM just tries to parse each header and unparsable headers are ignored. The purpose of
parsing all the headers, is to let OpenDKIM remove all other AR-headers, that were inserted before the email arrived in
the system, in order to prevent OpenDMARC evaluate headers confirming the DKIM validation, when those headers were
inserted before the email arrived at your site.
Now, OpenDKIM emits for “authentication-results; spf=none (sender IP is )smtp.mailfrom=xxxxxx_at_doccs.ny.gov;” a warning
and ignores it. I think this is valid behaviour.
Summa summarum, the problem is not with OpenDKIM in this case, but with the lack of understanding of DKIM and DMARC.
Regards
Дилян
On Fri, 2019-02-01 at 07:58 -0500, Ken wrote:
> > despite being asked, you do not share the exact header, that cannot be parsed.
>
> There you go
>
> Return-Path: <?g>
> Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840077.outbound.protection.outlook.com [40.107.84.77])by weaver.campbus.com (8.14.9/8.14.9) with ESMTP id x0AD7Bws013004(version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=FAIL)for <local_user_at_campbus.com>; Thu, 10 Jan 2019 08:07:12 -0500
> Authentication-Results: weaver.campbus.com; dmarc=fail (p=quarantine dis=quarantine) header.from=doccs.ny.gov
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=doccs.ny.gov;s=selector1;h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=nle3m1ypJwIQJcEYxNcs+Ir/fcHuMGnDz4yqI+qTars=;b=0M3G0N6YRSxSUP9QdLY5O9boBg+AxQf48/z10u8TgBHEYO4GJfEUoedSH4qteMfrHDw+IQhpV+dRkv+pk0ggaxMkaWVgzGutk+NiZoRzpYoRCjcJwuCs2pRcqNpScxd/LseV2AnrAfBRi3W7Xs8ExaYN6H0Dcbm2zHqmU6oDf/k=
> Received: from BN6PR09MB1203.namprd09.prod.outlook.com (10.172.17.149) byBN6PR09MB1202.namprd09.prod.outlook.com (10.172.17.148) with Microsoft SMTPServer (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id15.20.1516.14; Thu, 10 Jan 2019 13:07:10 +0000
> Received: from BN6PR09MB1203.namprd09.prod.outlook.com([fe80::1854:9727:aad7:f8ac]) by BN6PR09MB1203.namprd09.prod.outlook.com([fe80::1854:9727:aad7:f8ac%8]) with mapi id 15.20.1516.016; Thu, 10 Jan 201913:07:10 +0000
>
> Thread-Topic: Quote
> Thread-Index: AdSoJ+0X16qh1PIvSx+JI5nsInSggwAu0HkAAACE3rA=
> Date: Thu, 10 Jan 2019 13:07:10 +0000<BN6PR09MB12035CECDBD9887F8B20678BA4840_at_BN6PR09MB1203.namprd09.prod.outlook.com><MWHPR09MB12149BD5AA8ED63B6F76E79CA48B0_at_MWHPR09MB1214.namprd09.prod.outlook.com><0533931a-48f6-b74b-ca8f-c45adbd4540e_at_campbus.com>
> In-Reply-To: <0533931a-48f6-b74b-ca8f-c45adbd4540e_at_campbus.com>
> Accept-Language: en-US
> Content-Language: en-US
> authentication-results; spf=none (sender IP is )smtp.mailfrom=xxxxxx_at_doccs.ny.gov;
> x-originating-ip: [161.11.121.220]
> x-ms-publictraffictype: Email1;BN6PR09MB1202;6:Br+3ZjjSYR6GFOoOs/95+tb+pn+Tb7xYcOzNtisc5LyI3XpDKgsf27L4uRELHU5jjNtjM/uqe0P/OTgJaQ/3KaG41FaIYV4D/d8uhKMxu2Kzhe+tEfiX7SMSKM+SMIh+kaX9ranK60sQosjcb1UnQVT5ljk2GqrVP5vQFAAhuacsInz5HRaRTatcqbNT0yIu8NVV+31huRBj2CzGp/Tl/YbLzk5cyk2lJDVjByav1GakJtae8ow59PVCdAYvbxE3ca4A3CyriiHjreIhwKwZumzJ7GbP3dCS4h1+9bNxZsI6vN/bNx9m/bhef5sMK2UiveqAmK/3Rt3jReU0S0WdZe2QY8p/1fVwVhOy2IYrbq3+9DTy3Hc0QRvmr+3jGSr+E70YVqYicHiihxTqeSCfO2YTEPtSSxncImPuO4d4Du2bQSdThqM89s2uxtqbq/Q7DsQWKsTktTNhwaGz46gIzA==;5:JsBKFw2bWc4sBKQWwzj0N5qFpMWQpktj5edhbD74zrcZayIaZUq6iQRzQMTa1ysY2UD2aGZJv6yrNUP3Isj236YqGABUc8UH9sxFvZWWMc3YeyB9WI8YyTM1MUHhhYAuYRO0vFluM7OTDg2SAVNBrCMECLoh2j4P6Q7VZmn1gyjicfP1Z8iVt6ebulMhAq02fLHRo3XvHSLfjf61OHriIQ==;7:ymhwgOTL87vWV/YChB0vk5CB09S1JobjU4s3KYTpSyB30eRX3kpD1YFXtHviPZfJC4db6QHAg4jX/KT8kxhVpzIp8Qc8D321j1YiSmCh9NR+s+ggitY4ToxZOR5si+z8ZPu1FlfORQ4O8Ed3Wmb2tA==
> X-ms-exchange-antispam-srfa-diagnostics: SOS;
> x-ms-office365-filtering-correlation-id: d7791c0a-e60c-4f00-66bd-08d676fc880c
> x-ms-office365-filtering-ht: TenantBCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020);SRVR:BN6PR09MB1202;
> x-ms-traffictypediagnostic: BN6PR09MB1202:<BN6PR09MB120283FC5D80069A559BC65BA4840_at_BN6PR09MB1202.namprd09.prod.outlook.com>
> x-forefront-prvs: 0913EA1D60SFV:NSPM;SFS:(10009020)(39860400002)(376002)(396003)(136003)(346002)(366004)(199004)(189003)(221733001)(66066001)(5660300001)(6436002)(7116003)(229853002)(71190400001)(74316002)(71200400001)(256004)(68736007)(5024004)(14444005)(733005)(86362001)(53936002)(476003)(3480700005)(6916009)(606006)(14454004)(236005)(54896002)(6306002)(446003)(9686003)(97736004)(486006)(72206003)(55016002)(11346002)(99286004)(25786009)(316002)(2906002)(76176011)(8676002)(81166006)(81156014)(186003)(6116002)(6246003)(33656002)(6506007)(3846002)(53546011)(105586002)(7736002)(102836004)(26005)(7696005)(106356001)(790700001)(478600001)(8936002);DIR:OUT;SFP:1101;SCL:1;SRVR:BN6PR09MB1202;H:BN6PR09MB1203.namprd09.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:0;MX:1;
> received-spf: None (protection.outlook.com: doccs.ny.gov does not designatepermitted sender hosts)
> x-ms-exchange-senderadcheck: 1zRbjbDBbanxwjSRVF5qKGxF54I7Bu7ZQ3vIRcOUI9L7vRomLC/cG8IOeZFp0esKWHzFGde4ogl9tG/41W1d1iiXb7cei5S0Lv+Y4oTlamb5wxvOmqIX+CddW0GeLIcNPDQuI1CQmGTuJ3JoIhKWIewFV0svGsD5fJTeTwAYn0xEN6A47M4lQ0mYE4t4n4amiyhNI6FQa8qHU28pg56Hu9qxmeVUQCAv6LoqqS9eLCtEHSZlD+Y0c7cjSWUoRDqbmDrn+iVUevh9dPOdS8ahmtIXlOKE/t+wrPCyOt/0cHoyiOGC0F9b5IzE3yz66XsFP
> spamdiagnosticoutput: 1:99
> spamdiagnosticmetadata: NSPM
> Content-Type: multipart/alternative;boundary="_000_BN6PR09MB12035CECDBD9887F8B20678BA4840BN6PR09MB1203namp_"
> MIME-Version: 1
> X-OriginatorOrg: doccs.ny.gov
> X-MS-Exchange-CrossTenant-Network-Message-Id: d7791c0a-e60c-4f00-66bd-08d676fc880c
> X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2019 13:07:10.5423(UTC)
> X-MS-Exchange-CrossTenant-fromentityheader: Hosted
> X-MS-Exchange-CrossTenant-id: f46cb8ea-7900-4d10-8ceb-80e8c1c81ee7
> X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR09MB1202
>
>
> On Fri, Feb 1, 2019 at 3:19 AM Дилян Палаузов <dilyan.palauzov_at_aegee.org> wrote:
> > 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 - 14:52:36 PST