Re: [dmarc-ietf] Ticket #1 - SPF alignment

Douglas Foster <dougfoster.emailstandards@gmail.com> Wed, 10 February 2021 03:13 UTC

Return-Path: <dougfoster.emailstandards@gmail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815CD3A1289 for <dmarc@ietfa.amsl.com>; Tue, 9 Feb 2021 19:13:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 7NZIUFb9auds for <dmarc@ietfa.amsl.com>; Tue, 9 Feb 2021 19:13:50 -0800 (PST)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 EB5943A1285 for <dmarc@ietf.org>; Tue, 9 Feb 2021 19:13:49 -0800 (PST)
Received: by mail-vs1-xe2f.google.com with SMTP id y123so373545vsy.13 for <dmarc@ietf.org>; Tue, 09 Feb 2021 19:13:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NMnbhwmhOYiIaMZjsnA1CKSZ8sqy3009faqahV3KDk0=; b=m66idfgCN+k1tVWj4MLcoVdunyB3IEjWE10d/5Qi6lylUaWelPrIAA5q0tnIOsE+Bo d9JMUyJgGunozxfrpHeRNDG4MG5vJuaTzbcg/0TDFYOHEHVc/oClmHveMB3VKw+ev/k7 sv1Qd6igbewWAcA8FtXM/P0+Lh+uT4AdsNP4D0BcYkDhNJY6E9uz5TIecoR5v8wJfijb 5CGhkD1o+J2/BruETKh455iRffNqx48TY10AkSidceBqkRg3lVkP1G0v2lUyPkCpk8hT AR5hHgDOrdGXocMJ/U1VUYpGF5fGpfL/BI3rROZcTaVKdHxxZ7uYySW31ZH6w4dgmo86 4MNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NMnbhwmhOYiIaMZjsnA1CKSZ8sqy3009faqahV3KDk0=; b=KNjQMaWLsvq9m0wJg/RjCPLdtf6Pu2ZEaZFOzZ6ZhkzOTttkT3IKgVG+mciHZ8T4kq H55ixRCiOs/ZbSaXiPiBYJSc00yZq5WYMthhkCZiQ/bb9O1dXPEM8cbkoGvI2/GIt2w1 VM9i+YUXvx5V727H6KPfAi4bPNLoZCxaBIul/pkwyZsnw75lO5YMg378lMmqFe+4B7Gi CwvQpm83G9PjRvqCYJxYUOvUPT9opEP0AXlDt40XEkvXUQHPJSKY4UJhQZtBQ/kGTWW1 U5B64YqYzolsx0xc7kA1D4KBsSrfXtbflbX0K7QDuNoiw1GDfsA6VLh7n9ELMZrDsyse HKZA==
X-Gm-Message-State: AOAM531Skn/l38v/SXooOn9HPHA2Ll9Psq8NojZ4KeO0cnJfZ3TdTVhu gD2+sJ28U6ocWaO9TrJOA4e8iqXltucEcsaVbQ50BW/IArlVTA==
X-Google-Smtp-Source: ABdhPJwZC4wpETP3f633AdCfyrlcqwzXLFSHEBplQ8n/fYgv3+RGzcX9PbXjILEsTsTDLXpaMzdX7lcmLE3Rngvq3wA=
X-Received: by 2002:a67:87c2:: with SMTP id j185mr734912vsd.25.1612926828807; Tue, 09 Feb 2021 19:13:48 -0800 (PST)
MIME-Version: 1.0
References: <20210203181226.9AB746D51182@ary.qy> <e169f069-376d-7072-2538-c77bbe7b7540@tana.it> <b9c3487-44ed-a132-d42-47364fd819b4@taugh.com> <CAJ4XoYfUZXuPy6a+U=GnZ43um0Ruv5FMBQYHZqoK4tmmH+zUhw@mail.gmail.com> <CABuGu1pkSqJtf+rz-pzRSEJ=C4C77c+qyLjgobMqR_Z2fmYRqw@mail.gmail.com> <b730ab9c-aa5e-e80d-5cee-69cd6aee3a7b@gmail.com> <CAH48ZfxPG29hdqj4CN-HHdEk6uzOv_fG3nSB1KdmXWLSP7bHRA@mail.gmail.com> <CAHej_8k6DA8140QB2buaRCaJfc0U9fVSC=nSAu-dWsZshCRX_Q@mail.gmail.com>
In-Reply-To: <CAHej_8k6DA8140QB2buaRCaJfc0U9fVSC=nSAu-dWsZshCRX_Q@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Tue, 9 Feb 2021 22:13:37 -0500
Message-ID: <CAH48ZfxFsQ5ntE05QYRqP5P3Na6vuDjNAQKAdjZe7Kvt7evKuw@mail.gmail.com>
To: Todd Herr <todd.herr=40valimail.com@dmarc.ietf.org>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ae09a105baf2ca95"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/4CBYFUiphPPTqc0MR5NeNbdFI4E>
Subject: Re: [dmarc-ietf] Ticket #1 - SPF alignment
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2021 03:13:53 -0000

The chairs can introduce another topic whenever they want.   This does not
seem like a pre-requisite to any of the other pending topics.

My interest is interoperability:    We want recipient requirements and
sender compliance measures to align.

RFC 7208 says that recipients MAY want to use SPF HELO and SPF MAILFROM
together.  An argument can be made that this is not necessary:   SPF
MAILFROM shows that the server is authorized to send messages for the
specific domain in the MAILFROM, while SPF HELO says only that the server
is authorized to send message for the server domain and an unknowable set
of other domains.  Therefore a PASS from SPF MAILFROM should make SPF HELO
unnecessary and redundant.    Does either the DMARC document or the SPF
document say this anywhere?

RFC 7208 can be misunderstood to suggest that SPF MAILFROM and SPF HELO are
equivalent and interchangeable, which they are not, for the reason just
mentioned.   Shouldn't we also make this clear?

Senders are motivated to ensure that their mail is delivered, which makes
them interested in all of the factors which can maximize delivery and
minimize rejection.    SPF HELO might be one of those reasons.   Do we
mention this as an additional measure that senders might want to consider,
or do we keep silent?

Todd's assertion is that SPF HELO will cause an excessive number of false
positives.   I share Todd's expectation that this will be true, but I have
no data on that point yet.  I am just beginning to collect that data,
because it seems like an interesting question.

A second assumption is that no significant recipients are evaluating SPF
MAILFROM and SPF HELO together in a way that would be of interest to
senders. This may also be true, but I don't think this is something that
can be tested.

A third assumption is that the current behavior related to SPF HELO will
continue indefinitely.

To maximize interoperability:
- Recipients can be encouraged to ignore SPF HELO as unnecessary and the
likely source of false positives.
- Senders can be encouraged to ensure SPF HELO compliance to prevent false
positives.

That interoperability outcome seems worth some comment in our final
document, since it created the confusion that led to ticket #1.

The original question and these comments are exclusively about the SPF side
of the DMARC evaluation, which presumes that the DKIM signature is missing
or invalid.   I was neither proposing a new block algorithm nor proposing a
new allow algorithm.  But I do think that we need to anticipate how people
are likely to use our documents, with the goal of minimizing incompatible
interpretations.   Ale's question demonstrates that such interpretation
problems are possible, even on a small and well-informed sample set.

DF

DF

On Mon, Feb 8, 2021 at 9:50 AM Todd Herr <todd.herr=
40valimail.com@dmarc.ietf.org> wrote:

> On Sun, Feb 7, 2021 at 7:35 AM Douglas Foster <
> dougfoster.emailstandards@gmail.com> wrote:
>
>> "We have a lot of other topics" is the wrong reason to call for
>> consensus.   The important question is "Ale, have we addressed your
>> concerns?"
>>
>> I agree with many that for DMARC, our primary interest is whether SPF
>> validation of MAILFROM produces a PASS.
>>
>
> That's only partially correct. For DMARC, the SPF validation of MAILFROM
> must produce a PASS and the identifier must align with the RFC5322.From
> header domain. Absent both the PASS verdict and the alignment, the
> <policy_evaluated> section of the aggregate report will show "fail" for
> SPF, even if the <results> bit of the <auth_results> section shows "pass"
> in the <spf> sub-section.
>
>
>> However, I also see that a cautious recipient may choose to also require
>> SPF HELO = PASS and / or fcDNS HELO = PASS ( VERIFIED ).   Getting a PASS
>> on these multiple criteria increases the confidence in the PASS result, but
>> also increases the likelihood of ambiguous results and false rejects.
>> Therefore:
>>  - Recipients need to be cautious about enforcing rules so strictly that
>> sender configuration errors produce unwanted disposition decisions.
>>  - Senders need to be careful to ensure that they configure their policy
>> to produce both SPF MAILFROM = PASS and SPF HELO=PASS.
>>
>
> The likelihood of a HELO identifier both passing an SPF check and aligning
> with the RFC5322.From identifier is, I would venture, so small as to be
> immeasurable for shared services such as ESPs, mailing list servers, and
> the like. Perhaps they could eventually be convinced of a need to publish
> SPF records, but that wouldn't do much of anything to change the
> <policy_evaluated> results for DMARC. Getting an SPF pass verdict alone for
> these identifiers isn't enough to alter the DMARC validation results; the
> identifiers must align, too. From a practical standpoint, I don't believe
> SPF MAILFROM=pass/SPF EHLO=fail would be useful information to mailbox
> providers for the significant volume of mail routing to their customers
> from shared services; I get quite a lot of such mail to my Gmail mailbox
> each day, wanted mail that is correctly routed to my Inbox.
>
> Beyond all that, though, SPF can fail for both the MAILFROM and the EHLO
> identifier on any given message, but if the message is DKIM signed in a way
> that aligns with the RFC5322.From domain and the DKIM validation check
> passes, then the message will correctly be described as having gotten a
> DMARC pass verdict. We've spent quite a lot of time on this list discussing
> authentication checks that can, by themselves, result in a DMARC pass
> verdict, but that cannot, by themselves, result in a DMARC fail verdict. A
> message has to fail SPF validation/alignment checks and DKIM
> validation/alignment checks in order to fail DMARC. I am not suggesting
> that the DMARC spec be updated to require that both SPF and DKIM both pass
> and align in order for DMARC to pass, because while I believe it to be best
> practice for senders to align both SPF and DKIM identifiers, I believe it
> would cause too much breakage in existing running code and sender
> configurations to be worth it to mandate such things.
>
>
>> Altogether, I think some wordsmithing is needed to communicate those
>> points.   I do not have such wording at this moment, but will begin
>> thinking about what I would propose.   Perhaps those who are anxious to
>> move on will be able to produce text sooner.
>>
>> I have also raised a concern about the inadequacy of reporting these
>> results, since "Recevied-SPF: pass" is currently a compliant header.   We
>> can defer this issue to a later ticket, but we need to be thinking about
>> the problem.   If this requires no change, I would like some discussion of
>> why that might be the case.
>>
>>
>>
> What the message recipient does with all this authentication information
> is left as a local policy decision, a decision that is likely to be made
> using more data points than just the SPF, DKIM, and DMARC validation
> verdicts. The DMARC spec does not mandate that a message passing DMARC
> checks be accepted, nor does it mandate that a message failing DMARC checks
> be rejected, even in the relevant policy published by the domain owner is
> "p=reject", and I am absolutely not suggesting that the DMARC spec be
> written in such a way as to mandate such behaviors. In my opinion, the text
> that should appear in the DMARC spec to sum up these points is "A DMARC
> pass verdict means only that the message can be reliably associated by the
> recipient with the identity on which the DMARC validation check was
> performed, and a DMARC fail verdict means that it cannot be so associated."
>
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *e:* todd.herr@valimail.com
> *p:* 703.220.4153
>
> `
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>