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

Douglas Foster <dougfoster.emailstandards@gmail.com> Mon, 01 February 2021 14:26 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 817CC3A11C4 for <dmarc@ietfa.amsl.com>; Mon, 1 Feb 2021 06:26:51 -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=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 tzHZg0hekxc5 for <dmarc@ietfa.amsl.com>; Mon, 1 Feb 2021 06:26:49 -0800 (PST)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 652003A11C3 for <dmarc@ietf.org>; Mon, 1 Feb 2021 06:26:49 -0800 (PST)
Received: by mail-vs1-xe34.google.com with SMTP id 186so9146128vsz.13 for <dmarc@ietf.org>; Mon, 01 Feb 2021 06:26: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; bh=gnU3ObnLvQoWRRKc2Xo+9KWU8Q3X+eH15csawGYoWiU=; b=d1UthBtf5pLui0YwXzH+Gj44L9t8C3TL3PObYaQkU1F+ZYgTkkyyi6zmsxCK+yvU8t hu/JmCLbxR9CLDDuZMSALeylLyB/IV9LWA/+8Y1DZHObOr889ppz2lfwk8WteF1tkpT8 IlLCsJN6+ul4WU+HCZPwcwxAridjnm157F/Ni28c46CzXjZ+dDtCHBdOaRt5Yd9OdpwP HWV4FOyC9QlctH2rqdsku7aL4zd3ZDDG32JUAfbEAgA95JfTXAIBJRvYSj3R3kU4XB93 fPcsyd20ZmpEobt43I+cG9LROCdsEmLFzJGJIRnEED/0nUVbI7Pb6EyW6lagDK62XsIo aXcA==
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; bh=gnU3ObnLvQoWRRKc2Xo+9KWU8Q3X+eH15csawGYoWiU=; b=EWdDYnyahmwQCRB+GJ9nGoAbmQqf8J9sdkIWVdOUDylaT4PmuHcaaTjLI1imLLqrlu +wXjvkVRGLecf+tn/xfwZghGkpRIFaFx0WCT01hHgJsMRT6KXhR5Ya5e4h23ow/PLsmE yzWcHWdKyfJFQfiaCPBjdaLVJEQ2vfiev/FAQdP9Xl+6udohiiHXKBKCNmNZDDZv81K2 CxKdMG0VV5CJsbYp6egUo+oyxSqW591UxdDk5CliowMYi9FttWuoYb7ZQ8EEj47yLKED pIj5n4HYz7IvoczDKi9lPSAuAl9U5zZkhWkd9isWq0LVDJ1gOg4C0MpQIL2/1XlzpFL9 9cLw==
X-Gm-Message-State: AOAM533jE+d52RBJKGw/VCyQTwXPCUW9xm+Pz/SArSm1NpSt1NSsB/qt lXHiO9BvgZqH/3ZBY8e6WJU174ktFW2kh+UmYWDVwjlqBgg=
X-Google-Smtp-Source: ABdhPJyEWB9oHUh2eDqvvTxsgYUkr7RBDt8Y85J7CKkNoR0W2vtCDseZBtniFxnhIyVfo/5cG3qNBK7srhojOmL3eqg=
X-Received: by 2002:a67:24c5:: with SMTP id k188mr9207102vsk.16.1612189608161; Mon, 01 Feb 2021 06:26:48 -0800 (PST)
MIME-Version: 1.0
References: <20210130212339.447316D04763@ary.qy> <36a1c70-875d-89c8-7e95-a32324654275@taugh.com> <CAH48ZfwBKyA-TwSrr2422zmMO8wr1CKf2MiQZ3KvQu2hOH=_CA@mail.gmail.com> <1654196.ygyh55z74P@zini-1880> <babf1538-5172-f101-d5e4-c4fa33dea495@tana.it>
In-Reply-To: <babf1538-5172-f101-d5e4-c4fa33dea495@tana.it>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Mon, 1 Feb 2021 09:26:37 -0500
Message-ID: <CAH48ZfzAEhxSgS=VZtsp-xdWMzKq0Zow7DyCALq=qvMAv8_mEQ@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e7b5b505ba4724c0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/eE2uTHmP-BIZ2zAmDOVDMZOf5S8>
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: Mon, 01 Feb 2021 14:26:52 -0000

An SPF check on MailFrom says that this host has permission to send on this
particular SMTP mail domain, and From alignment with that this SMTP mail
domain has permission to send on behalf of that same domain.

If Helo aligns with From, it says that the mail server has permission to
send on behalf of the From domain, but it does not justify using a
different domain in the SMTP address.   If the SMTP address is null, this
is not a problem.   If it is not null and is different from the HELO
domain, we have permitted domain abuse.



On Mon, Feb 1, 2021 at 7:17 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Mon 01/Feb/2021 01:10:01 +0100 Scott Kitterman wrote:
> > I think that we're well past learning anything new in this thread.
> >
> > SPF is what it is (RFC 7208).  DMARC doesn't need to re-invent the
> protocol
> > (and shouldn't).  For any properly implemented SPF verifier, DMARC
> should be
> > able to consume the Mail From result.
>
>
> Perhaps Courier-MTA is not so properly implemented, but when mail from is
> empty
> it just omits the corresponding Received-SPF: header field.
>
> OTOH, properly implemented SPF verifiers could skip producing a Mail From
> result if the helo identity was verified successfully.
>
> In conclusion, the idiosyncratic requirement can hardly be implemented.
>
>
> > On Sunday, January 31, 2021 2:03:45 PM EST Douglas Foster wrote:
> >> I don't see any justification for using HELO unless the SMTP address is
> >> null.  If the SPF RFC says otherwise, this should be corrected.
>
>
> It makes sense to add a section that modifies RFC 7208.  See below.
>
> On Sun 31/Jan/2021 03:27:41 +0100 Douglas Foster wrote:
> > My data, cited previously, indicates that HELO can be useful for both
> > blacklisting and whitelisting.   It should not be ignored.
>
>
> >> On Sun, Jan 31, 2021 at 11:52 AM John R Levine <johnl@taugh.com> wrote:
> >>> On Sun, 31 Jan 2021, Alessandro Vesely wrote:
> >>>> One way to interpret RFC 7489 is that you can put dmarc=pass based on
> >>>> the helo identity *only if* MAIL FROM is null. >>>
> >>> That would be consistent with 7489.
> >>>
> >>> Sec 3.1.2 says
> >>>
> >>>     Note that the RFC5321.HELO identity is not typically used in the
> >>>     context of DMARC (except when required to "fake" an otherwise null
> >>>     reverse-path), even though a "pure SPF" implementation according to
> >>>     [SPF] would check that identifier.
>
>
> Does that mean that an implementation that uses the RFC5321.HELO identity
> without taking care of whether RFC5321.MailFrom is empty is *atypical*?
>
> Please note that all the text occurring before that paragraph would
> suggest
> that any authenticated domain, if aligned, would do.  The quoted paragraph
> comes as a note, by surprise, without bringing any rationale.  That text
> needs
> to be revised whether or not we remove the idiosyncrasy.
>
> And the only rationale learnt in this thread is that one could type
> whatever it
> wants in the helo/ehlo command, as if that weren't true for the whole SMTP
> session.
>
>
> >>> But then 4.1 says
> >>>
> >>>     o  [SPF], which can authenticate both the domain found in an [SMTP]
> >>>        HELO/EHLO command (the HELO identity) and the domain found in an
> >>>        SMTP MAIL command (the MAIL FROM identity).  DMARC uses the
> result
> >>>        of SPF authentication of the MAIL FROM identity.  Section 2.4 of
> >>>        [SPF] describes MAIL FROM processing for cases in which the MAIL
> >>>        command has a null path.
> >>>
> >>> That section of 7208 says that if there's a null bounce address, SPF
> >>> pretends that the MAIL FROM was postmaster@HELO.
>
>
> "Postmaster" is necessary, because SPF mechanisms can refer to the local
> part.
>
> The SPF part I'd modify, however, is Section 2.3, where it says:
>
>                                 If a conclusive determination about the
>     message can be made based on a check of "HELO", then the use of DNS
>     resources to process the typically more complex "MAIL FROM" can be
>     avoided.
>
> I'd append to that sentence:
>
>            , unless downstream filters need it anyway.
>
> Since we're at it, that paragraph continues with the following sentence:
>
>              Additionally, since SPF records published for "HELO"
>     identities refer to a single host, when available, they are a very
>     reliable source of host authorization status.
>
> Isn't that the exact opposite of what many of us are claiming?  And is it
> legit
> for a proposed standard to quietly counter an existing proposed standard
> without some kind of rationale?
>
>
> >>> If we want, we can say not to use the SPF HELO identity, but that
> would be
> >>> an incompatible change to 7489 and I suspect would not match what most
> >>> DMARC checking code does.
>
>
> OTOH, relaxing the requirement that the SPF HELO identity be used only
> when
> MAIL FROM is empty brings no incompatibility.  It's just a cleanup.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>