Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Lookup Limits increase

Simon Gnieslaw <simon@gnieslaw.com> Sun, 24 April 2022 18:56 UTC

Return-Path: <simon@gnieslaw.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A8D3A184E for <spfbis@ietfa.amsl.com>; Sun, 24 Apr 2022 11:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gnieslaw.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 5REBjH5Oxbio for <spfbis@ietfa.amsl.com>; Sun, 24 Apr 2022 11:56:46 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 E4DBB3A184B for <spfbis@ietf.org>; Sun, 24 Apr 2022 11:56:45 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id b24so16087923edu.10 for <spfbis@ietf.org>; Sun, 24 Apr 2022 11:56:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gnieslaw.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t7/+2FehGARWGphbIgQl7jtk5xKyNgtPBRlExSxlmTY=; b=nL26F0Qvgm9gmudrAUmJJ60svaNncjzMLPhcHCua7kjI1sXTNKKAYYXWYgR2ay71FT humZaVU2V9Y0ldU9/4rabW81PHrJhvLImYvbCN9z7wI/DtOCccw/9o+sZUmL4v1hmzOV aZ5/Np9cpumu7U7qMSeS6nm2hQsdn4c6C9pjDTJf+Jd0eqtxtPDytCKaFMbD7oE2CNiE R49Ld8DlO5264rsARSfEkNth5RjMoDbAJd8v6HWpAliPaxcBYvhhuMRGlliN0V8c522+ fuWz3tnNZA1dVS9MIzq/mkQ5sQsE0DYVj1ptaPb5Ksv1laRJaDEJquE3Xqp1lrzTs+yo X4Rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t7/+2FehGARWGphbIgQl7jtk5xKyNgtPBRlExSxlmTY=; b=LNFYdAtj5ZVO808ayd0Kv2BoqfPvxA0ZWZhjycbPwZ1O7Zk40cUYmmSzhFGb4B/eDu zNMLfEJD/fMNdz24Vk2AzdRIaZfuG7O+3xuGHazeivbcuM0NUwvBEK4YEgyQdplIGH8W +MtRGlt+4U5kqrTWc+cGxXDsAHnSijh5yCtTQp4piRgJ1Ebu9L+6KBxhpFr0lPvEP3NP 766zJV73U2BYCcfEz8WK44msQF7JxaCq9B1nipqTQXffG4Q17v0sgWs8SaGa1mWXT8VM UTbVVNYIm2Tr1RQNuNxYIHgm/rsU2Iw0mSiHGCBjeGUuBs/SxNla0fx7w9SZen7Pd6qN YH2w==
X-Gm-Message-State: AOAM532Pb7QhcU2ulXsrqw3A5mvUvv6LgOYkxQJL3IEqHVQZHuufEd2v TgjSgaSZRnOYbJiJq3vpggN9rmqUCLahn4e9Fqfr9oyYXgsTJQ==
X-Google-Smtp-Source: ABdhPJz6H+ndPsQBSibsw1yAgUI6nIOQNx44laKqpRLhmDlOrJ5bzjm+ixnlVVgxh9lFp8CPQXYAGiQDyfScbRwEnGs=
X-Received: by 2002:a05:6402:34cd:b0:424:793:9f65 with SMTP id w13-20020a05640234cd00b0042407939f65mr15360320edc.88.1650826603646; Sun, 24 Apr 2022 11:56:43 -0700 (PDT)
MIME-Version: 1.0
References: <CABi22cc9kTSti_HjyKO0XtdcGSXzjwUeqWs0bu_zoT9nBDTbnQ@mail.gmail.com> <20220424173704.303293E71A33@ary.qy>
In-Reply-To: <20220424173704.303293E71A33@ary.qy>
From: Simon Gnieslaw <simon@gnieslaw.com>
Date: Mon, 25 Apr 2022 04:56:30 +1000
Message-ID: <CABi22cfx8-=zR4a3dttAcmqKz06FLNRdhay_1fUJdW4UoA4MTQ@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Cc: spfbis@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004be38005dd6b0574"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spfbis/dxTvKmsEvAK-JrKjW4wbkYASfa8>
X-Mailman-Approved-At: Mon, 25 Apr 2022 02:39:38 -0700
Subject: Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Lookup Limits increase
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spfbis/>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Apr 2022 18:56:51 -0000

Thanks for the reply John,

I am primarily a sysadmin and therefore my focus to put in a solution which
is for the most part just set and forget.

These workarounds to automate or semi-automate the spf flattening have a
lot of moving parts, take effort to understand and set up on a somewhere,
give favouritism to popular DNS providers (who have APIs), and there is a
high potential for failure if not monitored, especially as failures could
be subtle by not realising that only some email is failing SPF/going to
spam or some recipient servers are being strict about the 10 record limit.

I am not familiar with IETF prossesses, is there a pathway that these
relatively small changes can be discussed and amended?

What bought this on for me last year was an overzealous ISP popular for
their email address rejecting emails due to the 10 lookup limit and when
trying to discuss it with them got the old "We are just following the spec!
It is you who is wrong".

They are technically correct (The best kind) but that still leaves regular
folk without a good solution because at the end of the day their email is
not getting delivered to those who need it because of a technicality, and
isn't an easy fix. It annoyed me a bit that the spec was putting me into
this position.

Computational power is ever increasing and the cost of DNS queries is
cheap. Even just loading a typical webpage these days would probably result
in dozens of DNS queries, I think that a few extra from email could be
handled by just fine especially as it's already common to exceed the 10.

And besides, if we want to be efficient with queries, we should be
mandating that it's the 3rd party provider who maintains the include: to be
the ones who flatten, then we could pull in up to 10 pre-flattened records.

Simon.

On Mon, 25 Apr. 2022, 3:37 am John Levine, <johnl@taugh.com> wrote:

> It appears that Simon Gnieslaw  <simon@gnieslaw.com> said:
> >Basically I just have a small issue with "4.6.4.  DNS Lookup Limits"
> >limited to just 10 lookups.
>
> I agree that if we were designing SPF now we would probably make the
> limit larger. But there are currently no plans to update RFC 7408 so it's
> not likely to change any time soon.
>
> If you care about this, it is not hard to fix. The excess lookups are
> invariably due to nested includes, so if you flatten the records,
> you're well under the limit. There are lots of packages to do the
> flattening automatically, e.g.:
>
> https://pypi.org/project/sender-policy-flattener/
>
> https://pypi.org/project/cfspflat/
>
> https://github.com/spf-tools/spf-tools
>
> R's,
> John
>