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

Alessandro Vesely <vesely@tana.it> Tue, 02 February 2021 12:57 UTC

Return-Path: <vesely@tana.it>
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 77B983A1A89 for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 04:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 TL8wVKBSOsh3 for <dmarc@ietfa.amsl.com>; Tue, 2 Feb 2021 04:57:58 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7A63A1A88 for <dmarc@ietf.org>; Tue, 2 Feb 2021 04:57:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1612270674; bh=hGdAZwqQ2kEHV6Ep+OxJaf5YRv0X3Y6XoDKsIwEP83k=; l=3573; h=To:References:From:Date:In-Reply-To; b=C0NYzB4nelMb0PndjVVofioGFGO6GU+/fh6cCE66mae+9Hz/d9KPITkbeowhWnT9I OoLbF+4Saq9fVkfxpV4ETWLP/xeEr0tk0lZZw3KsjTUtBzGwkO7W5+T8OU5k6VAueo 0wWIelmzUh5PyOA6aiv74DHFfWYt7deUXQnTKCIwESWR0iPBaw4i6b4EbJDlD
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC083.0000000060194C52.00002554; Tue, 02 Feb 2021 13:57:54 +0100
To: dmarc@ietf.org
References: <20210130212339.447316D04763@ary.qy> <1654196.ygyh55z74P@zini-1880> <babf1538-5172-f101-d5e4-c4fa33dea495@tana.it> <4489192.U1a6Vm75Xl@zini-1880> <CAH48ZfxB8OoA=3YCdj9mCf3sBzRo8Cu0Tg0z70_tCqQ6QmsCTg@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <1ac5cc72-66c7-eb6c-e034-6cb8e49b576e@tana.it>
Date: Tue, 2 Feb 2021 13:57:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <CAH48ZfxB8OoA=3YCdj9mCf3sBzRo8Cu0Tg0z70_tCqQ6QmsCTg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/3qRYdUUscsNS1_EEZ5oP05tuwA0>
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: Tue, 02 Feb 2021 12:58:00 -0000

On Tue 02/Feb/2021 01:11:22 +0100 Douglas Foster wrote:
> I think I finally understand the complexities of this issue.   SPF is two 
> different validations, largely unrelated.
> 
> Test One:
> A connection comes in and a server asserts a HELO name.   Before proceeding, 
> the recipient was to check if the HELO name is plausible or fraudulent.    One 
> way to do this would be to forward-confirm the HELO DNS name to the source IP.


That is the method described as iprev in Section 2.7.3 of RFC 8601, a.k.a. 
Forward-confirmed reverse DNS (FCrDNS).  Like many other authentication 
methods, it is not considered by DMARC.


> An alternate method is to use SPF to see if the SPF policy says that the HELO 
> domain can send from the Source IP.   I do not understand why the domain 
> owner would be able to configure the SPF policy but not the host name in DNS.


To configure reverse DNS one needs a delegation of the relevant arpa subdomain, 
which ISPs don't routinely provide.  By contrast, A, AAA, MX, and TXT records 
can be defined by every domain owner.  In theory, each label having any of A, 
AAA, or MX resource records, deserves an SPF record as well.


> Perhaps for organizations with 1000s of servers, creating a DNS entry for 
> each machine seemed onerous.   In practice, the large organizations do have DNS 
> entries for each server, and they encourage others to do the same.


Google, for one, don't care to define an SPF record for every server.  DMARC's 
discarding the result of helo verification is certainly not an incentive.


> A recipient who gets a FAIL result from this HELO test could decide to 
> reject the connection without ever proceeding to MAILFROM.


Rejecting EHLO can be problematic, since the command does not start a mail 
transaction.  Implementations may delay 5xx replies until MAIL or RCPT commands.


> [...]
> I expect that any attempt to require a PASS from this test will encounter an
> unacceptable number of false positives, so I do not see it as particularly
> useful.

To /require/ a pass on helo is very different from /discarding/ a pass on helo.


> Test Two:
> If the conversation proceeds past HELO to MAILFROM, then the second validation 
> is performed:   Is the Source IP is authorized to send on behalf of the SMTP 
> domain?   When the SMTP address is null, then postmaster@HeloDomain serves as a 
> proxy for performing this test.


Testing postmaster@HeloDomain is exactly the same test done for helo.  When the 
SMTP address is null, then the test is not performed.


> HELO test violations will have nothing to do with message flow path, since the 
> test only examines whether the adjacent server name can be plausibly linked to 
> the adjacent IP address.  A DKIM signature is not a third way of answering this 
> question, because a DKIM signature cannot be reliably associated with the 
> server that applied the signature.   Nor do I think we want a third solution to 
> this question.  Consequently, the HELO test is unrelated to DMARC.  The SMTP 
> Address test is appropriate to DMARC, whether it is evaluated using a supplied 
> name or a derived name based on postmaster@helodomain.


That makes no sense.  There is no difference between evaluating HELO and 
evaluating "a derived name based on postmaster@helodomain".  It is an HELO test 
in both cases.  Either it is reliable or it is not.  Asserting that a test is 
reliable only when there are no other means to authenticate a message is an 
idiosyncrasy.



Best
Ale
--