IETF Logo Mail Archive

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Alessandro Vesely <vesely@tana.it> Mon, 19 June 2023 15: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 8CFDAC151531 for <dmarc@ietfa.amsl.com>; Mon, 19 Jun 2023 08:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b="4OaHO71V"; dkim=pass (1152-bit key) header.d=tana.it header.b="BVv3XtoC"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkdu_KaLU2eo for <dmarc@ietfa.amsl.com>; Mon, 19 Jun 2023 08:57:29 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [94.198.96.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9EFC15106A for <dmarc@ietf.org>; Mon, 19 Jun 2023 08:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1687190245; bh=YPoH+OPaHM7inFvP0Fqg+BKutMXXF9/P2DyxJ1ojiN8=; h=Author:Date:Subject:To:References:From:In-Reply-To; b=4OaHO71Vaz/Hcr6ELyJLb2L7WTvhCSO09SvqBN2gVA4eAntJmZqZwwqdkf6N5oH6Q 9Sk7xBmS/BcfWyxS3XPBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1687190245; bh=YPoH+OPaHM7inFvP0Fqg+BKutMXXF9/P2DyxJ1ojiN8=; h=Date:Subject:To:References:From:In-Reply-To; b=BVv3XtoCBDCGD/fweLYNPE09YHHJ4LRwo/Ty77r0YyZJVcwee9zFql+4ce42kaqD4 vI2JL9cGxiIvgjRG2e/KwstUB04hEOb77yaQ8qMlVQw3bU8PRCZlvZZkb0kLFJLPtn jyVOFy4qgFxGrrpatNSLSapOKLnaM4geOFpNwezZ7DRlsORvOZWgpkU7Zdf6I
Original-Subject: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
Author: 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 00000000005DC0F0.0000000064907AE4.00005E7D; Mon, 19 Jun 2023 17:57:24 +0200
Message-ID: <074b4181-f9a4-078f-533a-196eb5e308b1@tana.it>
Date: Mon, 19 Jun 2023 17:57:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US, it-IT
To: dmarc@ietf.org
References: <30BB83B2-B454-41B8-992B-8E2569802D9C@1und1.de> <CALaySJKwuOK-81dW2H9dtURxa5mLQDUNo+MWcs+Hho8N+yP9qg@mail.gmail.com> <2817813.dRqVH37e0G@localhost> <CALaySJJbPFBAV_7mZaARYWuMzuX+74r2Cm0jD+z92_iuFRn_MQ@mail.gmail.com> <25736.57534.195344.782189@fireball.acr.fi> <1ec42959-977a-9ce0-907a-83a5eb2b6ef2@tana.it> <25739.5435.550786.601699@fireball.acr.fi> <25739.33240.127804.524371@fireball.acr.fi> <5d9a0b0f-8777-2494-d779-376c6ab8b37d@tana.it> <7d39aa8e-dacc-05fa-eff1-2cc350d521db@inboxsys.com> <CAH48ZfwyBwfKzG_3R5uyV6tmY0yUtWy=5yAoAOEhUGn_Rz6HNw@mail.gmail.com> <47b8a0c7-6a52-a4ad-e98e-8cb2f881713e@inboxsys.com> <285f2d2e-13fd-7cdc-c816-fba759f0745b@dusatko.org> <CAH48ZfzhyZK3RQHXH-PPk=sqY9gOtpA85vV-Myyo_RrEvOGu-Q@mail.gmail.com> <CAEYhs4F9=GDsCuQ9pAi8z-MBNHUJ9jZCwipT3Qe_YjaD65s9mA@mail.gmail.com> <CAH48Zfz-GRvXhOAWYn_mAypyoWm4L3=BKBxJad6X5NSFDD83yQ@mail.gmail.com> <CAEYhs4E=nrXsnTRNjCmC1yD-8HrKi0GLCdri5WjDHBvFubKHjw@mail.gmail.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <CAEYhs4E=nrXsnTRNjCmC1yD-8HrKi0GLCdri5WjDHBvFubKHjw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/zUHBHX035Pwy-f1vSwd9FgMVl08>
Subject: Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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, 19 Jun 2023 15:57:35 -0000

On Sun 18/Jun/2023 23:06:59 +0200 Ken Simpson wrote:
> The hosting provider has to hook up everything for them and presumably, with 
> enough encouragement, we could eventually get hosting companies to implement 
> DKIM signing for their customers. That is not the case today.


Domain-based authentication was conceived exactly because end users have a hard 
time trying to understand authentication mechanisms.  Hosting providers who 
cannot do DKIM, on the other hand, are certainly not professional.


> Some transactional email providers provide a DKIM signing service with CNAME-based DKIM key hosting.


This trick is used when the signing server is detached from DNS.  They create a 
public key and publish it under their own domain, then ask the user to publish 
a CNAME pointing to it.  The user could have published the public key directly. 
  The need to resort to pointers stems from difficulties in publishing long RSA 
keys, which required to increase the maximum length of TXT data in some DNS web 
forms.


Best
Ale
--

v2.23.0 | Report a Bug | By Email