>
> 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 - 12:59:01 PST