Mailing List Archive

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: someuser@vianet.ca
Return-Path: <NoReply.ODD@dhl.com>
Received: from gateway2h.dhl.com (gateway2h.dhl.com [199.40.206.31]) by
mx2.vianet.ca (Postfix) with ESMTPS id 69E9C100C9E for
<someuser@vianet.ca>;
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 mykullspc000017.apis.dhl.com ([199.40.12.27]) by
gateway2h.dhl.com with ESMTP; 23 Feb 2021 12:39:36 +0000
Date: Tue, 23 Feb 2021 12:39:36 +0000 (UTC)
From: DHL EXPRESS <NoReply.ODD@dhl.com>
To: someuser@vianet.ca
Message-ID: <168986178.834667.1614083976700@mykullspc000017.apis.dhl.com>
Subject: DHL On Demand Delivery
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_834663_677665159.1614083976694"


-kgd

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

On 2022-08-03 at 18:24:31 UTC-0400 (Wed, 3 Aug 2022 18:24:31 -0400)
Rob McEwen <rob@invaluement.com>
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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

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 +0000
Date: Wed, 15 Jun 2022 12:11:19 +0200 (CEST)
From: noreply@dhl.com
To: hamann.w@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"