Re: [ietf-smtp] Email explained from first principles

Dave Crocker <dhc@dcrocker.net> Tue, 25 May 2021 01:36 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022D43A0883 for <ietf-smtp@ietfa.amsl.com>; Mon, 24 May 2021 18:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_BLOCKED=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=dcrocker.net
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 JTWHKz-bt6wg for <ietf-smtp@ietfa.amsl.com>; Mon, 24 May 2021 18:35:57 -0700 (PDT)
Received: from fossa.ash.relay.mailchannels.net (fossa.ash.relay.mailchannels.net [23.83.222.62]) (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 5EC503A087D for <ietf-smtp@ietf.org>; Mon, 24 May 2021 18:35:55 -0700 (PDT)
X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 890C678111C; Tue, 25 May 2021 01:35:51 +0000 (UTC)
Received: from nl-srv-smtpout3.hostinger.io (100-98-55-237.trex.outbound.svc.cluster.local [100.98.55.237]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 2B6C478185B; Tue, 25 May 2021 01:35:50 +0000 (UTC)
X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net
Received: from nl-srv-smtpout3.hostinger.io ([UNAVAILABLE]. [145.14.159.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.98.55.237 (trex/6.2.1); Tue, 25 May 2021 01:35:51 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net
X-MailChannels-Auth-Id: hostingeremail
X-Spicy-Abortive: 39590da8367df71c_1621906551207_160530376
X-MC-Loop-Signature: 1621906551207:1765386441
X-MC-Ingress-Time: 1621906551206
Received: from [192.168.0.111] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout3.hostinger.io (smtp.hostinger.com) with ESMTPSA id 162DE31E1374; Tue, 25 May 2021 01:35:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1621906548; bh=jRQeWMjkC8oFnDFiTTwL3vGk02goK1r7Kl0rKe/meIQ=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To; b=HpzXiXjWqNDCBd+/gswqoUBLgsLRhdKCVMOgMOmphiV2pm47sUJO2uKYGUYuKMgeG 8RdwvzcEvjP4YQHLgV4akunYiq1lYlLHYD5uQFRSYWoycp1wRH7M8h2iBLn2AbZAll LjFBD3rUA09oI1gtlsoKGmW0x1f2/w3vCY1HRy5o7yh4zgg06ICDtcZcjdA9TwyjIQ kZBrJyG7WPchy78y+AJWjEY1o5KtpHD5B9KMkzx7iYfgEjEHmW5DhUzS4B+qOntG+a ncGarKpsiBMj9Qva0uwg7vY7gzenOZqVRYUYJW1FDhPP61OlUwWgqOcIJFX3PxFlwN B/zt4eaCFuNzw==
Reply-To: dcrocker@bbiw.net
To: John Levine <johnl@taugh.com>, ietf-smtp@ietf.org
References: <20210524140315.991E3890E35@ary.qy>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <7d7f2e66-a9da-4d34-b109-79a1b2996780@dcrocker.net>
Date: Mon, 24 May 2021 18:35:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <20210524140315.991E3890E35@ary.qy>
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/ietf-smtp/st64xqpGDaMZ723VCzgnXJgeGdQ>
Subject: Re: [ietf-smtp] Email explained from first principles
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2021 01:36:03 -0000

On 5/24/2021 7:03 AM, John Levine wrote:
> It appears that Kaspar Etter  <kaspar@ef1p.com> said:
>> 2. List-Name header field: Mailing lists shouldn’t rewrite the messages of others and break DKIM signatures in the process.
> 
> Sorry, but this shows some serious misunderstandings about both DKIM and mailing lists.
> 
> DKIM is a transport signature, which in this case shows that the message was sent from the author
> to the mailing list system.  

Since DKIM is often misunderstood -- and especially with beliefs that go 
far beyond what it actually does -- it is important that we be very 
careful in its description.

Although DKIM is, indeed, applied and interpreted by operators rather 
than users, it is /not/ a transport mechanism.

DKIM does not know or care about sessions or transport (for any 
definition of transport.)  DKIM is an object-level mechanism. At an 
architectural level, it is comparable to OpenPGP and S/MIME, though of 
course its semantics and algorthms are wholly different.

In technical terms, DKIM actually /can/ be created and processed by 
end-user software.  That it isn't is a matter of operational 
preferences, rather than technical design.

Further, DKIM does not say anything at all about the author.  Nothing. 
Nada.  Some signers have stringent policies that well might permit 
making assessments relative to the author, but that is fully and 
completely outside the DKIM specification.


> List apply their own DKIM signature on the mail they send.
> Mailing lists have been editing messages for 40 years, long before anyone
> ever thought of DKIM or DMARC. 

Yup.

Any attempt to pretend that 'we' can dictate much to the list 'them' has 
proven to be a non-starter.  For ever.


> The whole point of ARC is to provide recipient systems with info to help recognize when they should
> ignore DMARC and deliver mail from lists and other legitimate senders that don't happen to match the
> assumptions that DMARC makes.

Yeah.  No.  It does not say you can ignore DMARC.

Rather it says that the list that broke DMARC is reporting what their 
DMARC evaluation was.  If you trust that list's reporting, then indeed 
you can very much pay attention to DMARC.

That is, the main motivation for ARC is to provide a plausible basis for 
paying attention to DMARC, even when its underlying authentication 
mechanism are broken by the time they show up at the receiver.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net