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 >
- [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Lookup Li… Simon Gnieslaw
- Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Looku… John Levine
- Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Looku… John R Levine
- Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Looku… Scott Kitterman
- Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Looku… Simon Gnieslaw
- Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Looku… Simon Gnieslaw
- Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Looku… John R Levine
- Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Looku… Måns Nilsson
- Re: [spfbis] Fwd: RFC 7208 SPF - 4.6.4. DNS Looku… John Levine