Re: Seeking dhl.com ham samples
Hi Bill,hope that helps headers from order confirmation mail Wolfgang Received: from gateway1h.dhl.com ([165.72.200.98]) by mailin73.mgt.mul.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1o1Q0k-4aA7Un0; Wed, 15 Jun 2022 12:12:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhl.com; l=218621; s=20140901; t=1655287950; h=date:from:to:message-id:subject:mime-version; bh=jZNqE0ZOuw8c2LVfWfKHCJbxZsAgmCJOps1P6mXg1lQ=; b=QIbSZ++xkMebzAPEUgod0NxEtYiEzD1Nvr2cCrlzQvMVqxOthVXoKT32 gV7mBgAKg+4Zkm6wFVhvKcku4rq2aert43sEXtBTeeVhyMRuwzgqKsFUR aMIkXe9pJTtCVgxHZFHxiwiJazLS9xFFqD3qqZlLnY8F9KiPd0E7QmC1u pZcRgolJ0Qf4gSi0uwLcMn3dE481GG43mgjaCQjPa+f6aHbHiQSYmtZLD NpUhZrPyIoIYqWbn5Fr/D6IKtkh4xlC3jPeijlMhQl0SDqVPFGSLVxz2F ehTTo4udfo+BM4KabIzMtenXY9din56hGqSK9PYW6MX5unfYEpxWq/DM5 A==; IronPort-SDR: PvqRLak59WYBNulkTwZ84TR32Y1juowA4XjPF/40ODGAao93vP49VcSc2YunYP0iyUYqIFFAkd Xb1Qr65aSE05lAnDe3DHwazg8DuD3dick= X-ExtLoop1: 1 Received: from unknown (HELO of-backoffice-blue-prd-67486746d8-xnnsh) ([10.187.32.92]) by gateway1h.dhl.com with ESMTP; 15 Jun 2022 10:11:19 + Date: Wed, 15 Jun 2022 12:11:19 +0200 (CEST) From: nore...@dhl.com To: haman...@t-online.de Message-ID: <89105898.386694.1655287879182@of-backoffice-blue-prd-67486746d8-xnnsh> Subject: =?UTF-8?Q?Auftragsbest=C3=A4tigung_Ihrer_Online_Frankierung_4Y778E3KKACZ?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_Part_386691_426113042.1655287879178"
Re: Seeking dhl.com ham samples
On 2022-08-03 at 18:24:31 UTC-0400 (Wed, 3 Aug 2022 18:24:31 -0400) Rob McEwen is rumored to have said: I provided a ham sample off-list. Indeed; thank you. We determined that this was an interaction between local resolver config and (probably) Net::DNS or a sub-module. Setting BIND EDNS options fixed it. Also, I've recently encountered a similar issues with DHL - for example - them, several weeks ago, using an alterate domain in the mail header FROM-address - that didn't actually have ANY DNS records - crazy stuff like that - although I think that they've since stopped using that particular domain name? --Rob McEwen On 8/2/2022 10:50 AM, Bill Cole wrote: Bug 8021 reports breakage in SPF checking for dhl.com mail, due to an inability to resolve the SPF TXT record for dhl.com. That breakage is essentially due to DHL having far too many TXT records (some are clearly stale) and having a SPF record which is right at the limit of complexity, having 10 'include' directives at the top level. If anyone has samples of real legitimate mail from a dhl.com address, please share. I'm seeking a way to reproduce the reported bug, which strikes me as too stupid to be real; we SHOULD have noticed long before now if SPF lookups were not handling UDP truncation of replies. -- Rob McEwen, invaluement -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Seeking dhl.com ham samples
I provided a ham sample off-list. Also, I've recently encountered a similar issues with DHL - for example - them, several weeks ago, using an alterate domain in the mail header FROM-address - that didn't actually have ANY DNS records - crazy stuff like that - although I think that they've since stopped using that particular domain name? --Rob McEwen On 8/2/2022 10:50 AM, Bill Cole wrote: Bug 8021 reports breakage in SPF checking for dhl.com mail, due to an inability to resolve the SPF TXT record for dhl.com. That breakage is essentially due to DHL having far too many TXT records (some are clearly stale) and having a SPF record which is right at the limit of complexity, having 10 'include' directives at the top level. If anyone has samples of real legitimate mail from a dhl.com address, please share. I'm seeking a way to reproduce the reported bug, which strikes me as too stupid to be real; we SHOULD have noticed long before now if SPF lookups were not handling UDP truncation of replies. -- Rob McEwen, invaluement
Re: Seeking dhl.com ham samples
Bill Cole wrote: Bug 8021 reports breakage in SPF checking for dhl.com mail, due to an inability to resolve the SPF TXT record for dhl.com. That breakage is essentially due to DHL having far too many TXT records (some are clearly stale) and having a SPF record which is right at the limit of complexity, having 10 'include' directives at the top level. If anyone has samples of real legitimate mail from a dhl.com address, please share. I'm seeking a way to reproduce the reported bug, which strikes me as too stupid to be real; we SHOULD have noticed long before now if SPF lookups were not handling UDP truncation of replies. The newest one I have on file (headers below, should be enough to test SPF) is a bit old; Feb 2021. I just rechecked and the complete original passed both SPF and DKIM without complaint on SA 3.4.6 on Debian 10. Delivered-To: someu...@vianet.ca Return-Path: Received: from gateway2h.dhl.com (gateway2h.dhl.com [199.40.206.31]) by mx2.vianet.ca (Postfix) with ESMTPS id 69E9C100C9E for ; Tue, 23 Feb 2021 07:39:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhl.com; l=35875; s=20140901; t=1614083981; h=date:from:to:message-id:subject:mime-version; bh=DIpnjzWIqceTkeAfTQXi/K36OKJqsxnmJxUdU+eemXU=; b=exBQWWKggKa2c/ZuOeuwZBUx80u4IzrsKwSToUeyFR5wE9sb1oTbpnAp 3DJ4iSPWdwc8JJTAlwNXmQZXYSMwCy1WBHOh3ISkTrGKf8mqQ4AQSfGmz QOLWJtFD1oCx0Bdxk6fiAimrLLv7bcYWJfch9Y2Jg5FYfsZYmxFhfzQHi 4UL8dPVFmhnUa/6GbzrWAGZ/fIY62vFcgAVRoFJrFoUg+rJpWUuBO5FdL Ap0vK0NYSR6NvZPBJjOfcADJVzgucYOoiTk5luWUx7BoyZzx+RrYR3hvu 6fl1x9+EBQt5+4Rd2HTON/gvSmnmc2x6zsxWXmTllAxBAOsuh8nC9nwad g==; Received: from mykullspc17.apis.dhl.com ([199.40.12.27]) by gateway2h.dhl.com with ESMTP; 23 Feb 2021 12:39:36 + Date: Tue, 23 Feb 2021 12:39:36 + (UTC) From: DHL EXPRESS To: someu...@vianet.ca Message-ID: <168986178.834667.1614083976...@mykullspc17.apis.dhl.com> Subject: DHL On Demand Delivery MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_Part_834663_677665159.1614083976694" -kgd
Seeking dhl.com ham samples
Bug 8021 reports breakage in SPF checking for dhl.com mail, due to an inability to resolve the SPF TXT record for dhl.com. That breakage is essentially due to DHL having far too many TXT records (some are clearly stale) and having a SPF record which is right at the limit of complexity, having 10 'include' directives at the top level. If anyone has samples of real legitimate mail from a dhl.com address, please share. I'm seeking a way to reproduce the reported bug, which strikes me as too stupid to be real; we SHOULD have noticed long before now if SPF lookups were not handling UDP truncation of replies. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
