Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

Dan Wing <danwing@gmail.com> Mon, 07 February 2022 22:49 UTC

Return-Path: <danwing@gmail.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E7B3A0E5C for <behave@ietfa.amsl.com>; Mon, 7 Feb 2022 14:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.855
X-Spam-Level:
X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugUFAlUNt9GQ for <behave@ietfa.amsl.com>; Mon, 7 Feb 2022 14:49:51 -0800 (PST)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897BB3A0E5A for <behave@ietf.org>; Mon, 7 Feb 2022 14:49:51 -0800 (PST)
Received: by mail-pj1-x102b.google.com with SMTP id h20-20020a17090adb9400b001b518bf99ffso481276pjv.1 for <behave@ietf.org>; Mon, 07 Feb 2022 14:49:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4DfMrcqymOIhzKXLQGh29ryvgJi0Ed5rP5OQh3N0Tx8=; b=OL0vfuipddpuNv1CQCrCY0yvFCCx58pXMBCHGCQmyKmUeJYb6xxl/XmMgB36WuD4lZ 8QsdFnHMpArutkZ7HynXgqrDJuCrqyMHtVjdkoqWe3jJ4BVo/iXT8f2SmCalFAcD0Dfr Duh+szilqEhQ22UkXKXI0VatArq6zudAsqFfqeu+kLEWEMWsGpYNzCI74eFxky71XNiV s65nGLJ6h3I0VwLo6kuJ2a6/WYsrcFuBqUNUu54G8qTWzNHXN4W0TbKoYsr7E3BRf3Lk rM25PCz0UxICRq031WzQxU1wNrMFsb4grGUO43GF9yb9m4smJr5L1F+k9LOXK6dGdz0o UX5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4DfMrcqymOIhzKXLQGh29ryvgJi0Ed5rP5OQh3N0Tx8=; b=HJBz8MakzOOGwLZGKsk6jruuzlUrUwpU0RzcatwoNkcn7+kftNEHizkvsNtilwVGZy KvRi2RigpF6GOh/PQKhbxSuZn7rjZL4Uw+nawkSmr/ylqGsQ5f5PVp8DerjJuZdnFeKQ pzuxszYKcMg1WPg60Fl2oNBDmrSlN20mmSS4QOzXjQk4AyBKBagJBuM2ehdjO3b6p4d+ MkDYgT4rxk1mjEBpmIOB1H3HOQ9ueUH9jl0o/8r7tgfbNksI/6sON1x4D0cTiVc1PPq9 yG6aC8LKUytOJsfleHQlHp4+p0IYk1ncr9jQ6AHSywLQL3XVKmNC92df2tYXN3vLsxoW FCdw==
X-Gm-Message-State: AOAM532mAc6TGjNDcgWybSRXhUdeOz5kiaJXYKezsNVR716JP+mMeeyr nY88fGegXBUSZ6Ewi+AeTJtIpEu3CWQ=
X-Google-Smtp-Source: ABdhPJxnM6nyZkPYJPo+rV1071r2mjzLv8Z+JreJfgN0SGEyKB3PzrG0HejcU8foU9YhlvInuJ+aNQ==
X-Received: by 2002:a17:90b:1bc9:: with SMTP id oa9mr1212077pjb.27.1644274190186; Mon, 07 Feb 2022 14:49:50 -0800 (PST)
Received: from smtpclient.apple (47-208-218-46.trckcmtc01.res.dyn.suddenlink.net. [47.208.218.46]) by smtp.gmail.com with ESMTPSA id ip5sm374420pjb.13.2022.02.07.14.49.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Feb 2022 14:49:49 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Dan Wing <danwing@gmail.com>
In-Reply-To: <05e6cff9-3d9f-fac6-82b7-492b21726a0f@posteo.de>
Date: Mon, 07 Feb 2022 14:49:47 -0800
Cc: behave@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB801DA6-FA5E-4C8A-8BB8-F7EEABF7677A@gmail.com>
References: <077D662F-5E6D-44F5-8DD3-B58D8B535C5D@network-heretics.com> <B6D6B4CC-AC1F-459C-952A-E9493E00FDB3@huitema.net> <7e53925e-46b0-29e4-6deb-47bcf389ff97@posteo.de> <DC6F8DB5-4D01-466F-A042-1769E5FBB677@gmail.com> <05e6cff9-3d9f-fac6-82b7-492b21726a0f@posteo.de>
To: Klaus Frank <klaus.frank@posteo.de>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/T3AkjJ4Q5eUff8Su8T_QSKTJcAI>
Subject: Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 22:49:56 -0000

Thanks.  Clearly I didn't dig deep enough into Google's configuration.

Has anyone swept the top-NNN mail operators to pull their SPF records.  Knowing how pervasive a problem could help charter work to build a consensus solution.

-d


> On Feb 7, 2022, at 11:47 AM, Klaus Frank <klaus.frank@posteo.de> wrote:
> 
> Google and O365 have a lot of IPs in their records. Currently the standard is to specify the subnets instead of dns names (for whatever reason). If you now further perform TXT-RR lookups of these includes you'll get new SPF records that contain lists of subnets e.g.:
> 
> google.com ("v=spf1 include:_spf.google.com ~all") => _spf.google.com ("v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all") => _netblocks.google.com ("v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"), _netblocks2.google.com ("v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all") and _netblocks3.google.com ("v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all")
> 
> 
> On 2022-02-07 20:37, Dan Wing wrote:
>> Klaus, David,
>> 
>> I just grabbed an email in this thread to propose a different idea:
>> 
>> Could the SPF problem dissipate if SPF records only contained DNS names and deprecate IP addresses?  Consider we had (and still have) the same issue with IPv4 addresses in URLs (https://datatracker.ietf.org/doc/html/rfc6586#section-6.1, e.g., http://1.2.3.4) which break with DNS64/NAT64 because 1.2.3.4 is not a valid IPv6 address.  The solution there was (and still is) push those deployments to use DNS names rather than IP addresses.  Of course nobody wants to spend their career chasing down websites using IPv4 address literals, which is what begat 464XLAT.
>> 
>> I don't have a list of top NNN mail servers, but I see both address literals (e.g., comcast.com, microsoft.com) and domain names (e.g., gmail.com which does SPF redirect to _spf.google.com which has only domain names).
>> 
>> -d
>> 
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave