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

Douglas Foster <dougfoster.emailstandards@gmail.com> Sun, 31 January 2021 02:27 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 220F13A1399 for <dmarc@ietfa.amsl.com>; Sat, 30 Jan 2021 18:27:54 -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 yMRze3MHeJOD for <dmarc@ietfa.amsl.com>; Sat, 30 Jan 2021 18:27:52 -0800 (PST)
Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 369E73A1398 for <dmarc@ietf.org>; Sat, 30 Jan 2021 18:27:52 -0800 (PST)
Received: by mail-vk1-xa2a.google.com with SMTP id d6so3112492vkb.13 for <dmarc@ietf.org>; Sat, 30 Jan 2021 18:27:52 -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=7SgMAVYXC1tF/9tE0YlbVLdVz6b0tiyRoKBMhb9QOo0=; b=VnEUfe7jy/eSz1y66Z13GgCIgp15q5DHF1QO20hOFxnwOskDIC+Mzdfr5P+akbW6H+ POqs3DAI1DwQQyTY3HeVSLegpUPPGariPPMKCMvtWqV6xaYNE35mZD7epnfWDqS0zDUZ 4MxcrIjs6cSQlXkEm2XUTKXxdc5CO+/Bospi/rTEW39MwQ1Mb9rtMYARWvhlfwstoQ4n Wd9CivCjI7gF0737OiLp+jrpnIw6UY2VBkE6AZ22ZaImuXxVzbdDg/1fankLD+1ON80g ObZiLV7xS7QnzmWxV/Mk3uuNeNs0uO5K3QVuLQq/+jlEZQ58QI26uPMeZ/MJhl2bQHW3 hSjw==
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=7SgMAVYXC1tF/9tE0YlbVLdVz6b0tiyRoKBMhb9QOo0=; b=Riw1LysfC9X3TZ/kGbDV705nOaOdJVpoVxy72ZDBvgi0K3OBcodwzJD/Qx3DUn4aya 2h9WGBiTpjrwJmMTCeUsRaY4JPKMeYWEDYZ7l2m28VIB3co/iBJBfUoJvR4ZiESuF6PS ASSQDCK+rq4LhDQvNTJeF6+UWm7oXCFzvFWPhUrS+89u9GhQAIvZRPFE9rV9GjpT1mgN T3qEbv0C83rsTQbMrQBzEQ55DV8Ex4DD5+mSq3hVed42nG0Xz55BfF5ng5UKVzYz7fEE Z+p1pOX+jydD+G4nIypuNsMjFgBAAImo2p0bKplCES7Yzq5mio3z+i9PE4XmztnTilbV HYGA==
X-Gm-Message-State: AOAM530oWAbh0F4evq6DLf+61V6llu5FRfg8COHddBv4E9gTsUSLT/tK falc5LFkswG23BkieiDebDHjgH/CIedxX0MZqXpWEp3iayo=
X-Google-Smtp-Source: ABdhPJw1eT20f2bPzo8tO1u3da/v1r4ZIeNtQVkfoCDIojLF1dj6VCQXItjK9vWf25/N5bjA+Hu+6+csmguqV3i6GKc=
X-Received: by 2002:a1f:3112:: with SMTP id x18mr6495035vkx.4.1612060070808; Sat, 30 Jan 2021 18:27:50 -0800 (PST)
MIME-Version: 1.0
References: <20210130212339.447316D04763@ary.qy> <66EB1EFC-753D-49FA-8652-BABB10397990@bluepopcorn.net> <1edea785-2420-9812-643-c38bc4bf9577@taugh.com> <892F89B5-F86C-4BAD-A88F-C7A48B930D04@bluepopcorn.net> <ae9761b9-1560-da7e-89e5-34f570d24fc5@taugh.com> <9190a914-f037-8f44-d3a0-a454deab6371@mtcc.com> <CAH48ZfxUG2QL=GO3Rnya2uXTROYy=qWuoaN41Lk-ujPGZH8Exg@mail.gmail.com>
In-Reply-To: <CAH48ZfxUG2QL=GO3Rnya2uXTROYy=qWuoaN41Lk-ujPGZH8Exg@mail.gmail.com>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sat, 30 Jan 2021 21:27:41 -0500
Message-ID: <CAH48Zfxdv+9nPYu9xdhJ9nYakicVUdT9hKQ766b11st7YtEgTw@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e08f2105ba28fbb8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/q8qIsUu5ri06KBF6fzCjUdRxGBQ>
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: Sun, 31 Jan 2021 02:27:54 -0000

The SMTP address and the HELO name are very similar in their trust
characteristics.
Both of them can be manipulated maliciously, but both can be verified with
similar techniques:   Using a DNS lookup to associate the name
assertion with the Source IP.
(We all know that the Source IP can be manipulated with a NAT device
sitting outside a network perimeter, but we ignore that possibility.   If
it is happening, there are worse things than email verification occurring.)

We do know that Reverse DNS is often outside the control of the mail
domain, so it is actually a less reliable indicator of domain ownership
than Helo.

Overall, the SPF design seems very intuitive and defensible.
I think it is unrealistic to expect rapid implementation of DKIM signatures
on null-address messages, and HELO is a good substitute.  Nor does it seem
necessary.  I see no problem using HELO in my DMARC evaluations when the
SMTP address is null.

My data, cited previously, indicates that HELO can be useful for both
blacklisting and whitelisting.   It should not be ignored.

Doug Foster
.

On Sat, Jan 30, 2021 at 7:44 PM Douglas Foster <
dougfoster.emailstandards@gmail.com> wrote:

> Anything can be gamed if it is trusted without verification. But
> verifiable data is hard to game.   If you ensure that Helo can be forward
> confirmed before considering it trusted, how is it risky?
>
>
> On Sat, Jan 30, 2021, 5:45 PM Michael Thomas <mike@mtcc.com> wrote:
>
>>
>> On 1/30/21 2:09 PM, John R Levine wrote:
>> > On Sat, 30 Jan 2021, Jim Fenton wrote:
>> >>> Part of the problem here is that DMARC generally sits on top of an
>> >>> SPF library which doesn't tell you how it got its result.  My DMARC
>> >>> code just calls the SPF library and uses the result.  I suppose I
>> >>> could put in a hack to say don't use the SPF result if the MAIL FROM
>> >>> is null, but I don't think that's what 7489 says.
>> >>
>> >> Are changes to 7489 off the table here? I didn’t know.
>> >
>> > They are certainly possible, but I would want a good reason.  At this
>> > point, SPF using HELO seems harmless so I don't see a reason to
>> > disallow it.
>> >
>> >
>>  From a security standpoint, I wonder why you would want to allow
>> something you know can be gamed. But that is probably more a question
>> for SPF itself.
>>
>> Mike
>>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>