Re: Enabling DMARC workaround code for all IETF/IRTF mailing lists

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 11 May 2018 20:31 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F5D12D879 for <ietf@ietfa.amsl.com>; Fri, 11 May 2018 13:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 kIzVZvIcvI6n for <ietf@ietfa.amsl.com>; Fri, 11 May 2018 13:31:17 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 ED29112D87C for <ietf@ietf.org>; Fri, 11 May 2018 13:31:16 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id l142-v6so1948834ywc.11 for <ietf@ietf.org>; Fri, 11 May 2018 13:31:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8+8H7rcoBpfAI2yrMdzwkxuSGmLnnHt37mSPm9mJoIY=; b=U3z7aH09auPSMb6qLSDE37gssa4JYRalKxCrY0wAzqpvefnanQWe74pdn1bBPizKH+ jjolpV/RbtpheSoX9p02/LHeCa20WLGslM6Rc/XRykWxZhprOexQSQvhcRnQgQxUwllP TyWFpsX3j6W3+pgj8hw8GryzH29K4smfhVHQhgxhOFQYHEZfPufWkKYjE5TY0LEkWiWL US8ndQgm9W9OPhys+oZ1NuhVqj0sTcGyfs93YvPKHbHzKV3OoOTEp/kDhcWNSoaCFbBR 7p4+COjUy7YTq/Kb+TFaFnc/HfhiO2j7w+gxDmi7e6869RDFHUM/g9INCOn9180I+bRK 93Qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8+8H7rcoBpfAI2yrMdzwkxuSGmLnnHt37mSPm9mJoIY=; b=KiKjy/FQM1GH/tZmH4EsAHJFpANlnMiijeDbFZHxxqnpRNEVPwPqhpYIPRYRtmY+P0 YKgoxaOBe+CvXe/iuzesSCfLvbIe5s2yKEKSLq5c3WTP8iQVvGAdcj3pm7m6dFKMBbVd 1CWLG4uucpHpuW00FxyyQBQwjPDOA/ybDDpLKFxtyPpN1kUGNhT5wJkuFzuNt37+j+O+ gNPbmfpeWALRa9WkrsezXO+MV3Z1TGdmnJpx3gt6zl4VxXi9vGPKqGcE8yl569PEH6aA qVvh2B1ilm42vmWywmjp+qS21HrOfplT/Y15vVbVmaIrE/EjjJe7bA5I+LB6sMh1RYaP 9qLQ==
X-Gm-Message-State: ALKqPwdclJc1mi1jwzkguBWXQafY/+bBW3A0Mrelprkf2AU4uuwUDfQ4 JuSfMvZwssz5TPZ2HkN5KOh6NaHqP2CynSHb58U=
X-Google-Smtp-Source: AB8JxZpPIXV9T1ja6aHbfk5BvzQ79KFSbIl55xIloTCkHFVg5itEgxz8mp9zSLePm38lZUSuUT5wdSHc2DaTa7Avdfw=
X-Received: by 2002:a0d:ca96:: with SMTP id m144-v6mr258032ywd.279.1526070676057; Fri, 11 May 2018 13:31:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Fri, 11 May 2018 13:31:15 -0700 (PDT)
In-Reply-To: <911C82676980A52DB95C7DEF@PSB>
References: <919855CA-9F77-420A-8B8F-79174CD2FC19@fastmail.fm> <61B1EDB45FC4FF33154B13B0@PSB> <739143A6-90EB-4F26-8F54-B281DA2FB0E4@fastmail.fm> <CAKKJt-cvxgW2=Od_hkF8+keDHfT_1RJtSLwXSiiR7_dhmqPJYQ@mail.gmail.com> <911C82676980A52DB95C7DEF@PSB>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 11 May 2018 15:31:15 -0500
Message-ID: <CAKKJt-cH8ZhkdspxG9kW=QwGZN-e3ek=+hx5uPXBZtSOsjm2-A@mail.gmail.com>
Subject: Re: Enabling DMARC workaround code for all IETF/IRTF mailing lists
To: John C Klensin <john-ietf@jck.com>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, IETF list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008c7232056bf40459"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Tc-HhDX_BxbzTDArd7Ceac2VSs0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2018 20:31:20 -0000

Hi, John,

On Fri, May 11, 2018 at 2:05 PM, John C Klensin <john-ietf@jck.com> wrote:

>
>
> --On Friday, May 11, 2018 13:13 -0500 Spencer Dawkins at IETF
> <spencerdawkins.ietf@gmail.com> wrote:
>
> > Perhaps I've spent too much time talking to  QUIC WG
> > participants about header invariants, but can you actually
> > change the encoding, or did you mean just adding a new
> > encoding, so that if someone tries to respond to an earlier
> > e-mail from someone with a re-written =40 address, that would
> > still work?
>

Thanks for the clues!


> Spencer,  because I started the subthread, let me give you a
> partial answer.  I think you know this already, but probably
> have other things on your mind.   There is basically a firm rule
> in SMTP (5321, but going back to 821 and maybe earlier) that
> nothing in the mail path between what we now call the submission
> server and the final delivery server gets to interpret, much
> less tamper with, the internals of the local part of an address.
> While we have many examples of systems breaking that rule, the
> integrity of the mail systems depends on it in important ways.
>

When I'm not thinking about QUIC invariants, or QUIC spin bits, that sounds
familiar, but it wasn't the first thing I thought about.

>
> Having a mailing list management system transform an address
> between receipt and [re]distribution does not violate that rule
> because we treat the message as having been delivered to that
> system and then rewritten and hence not altered in that path.
> However, had Alexey been writing very precisely, I don't think
> he would have used "encoding" but instead talked about this as a
> convention or something similar.   Then the question becomes
> whether, if the mailing list system changes an address using
> that convention, whether the user, MUA, or delivery MTA at the
> receiving end recognizes the convention.
>
> Speaking as a user who sees that convention, it took me around
> five seconds to figure out what =40 referred to (and it should
> not have taken me that long).  I don't know whether that would
> be true of the typical IETF participant; it certainly is not
> true of my delivery MTA or my now-ancient MUA.
>
> So, there are really several possible questions:
>
> (1) If your question is whether a recipient of the mailing list
> distribution of the address would recognize the convention and
> be able to infer the original address, the answer is "anyone's
> guess", but most users tend to pay more attention to the
> personal name phrase than to the address anyway, so maybe it
> isn't important.
>
> (2) If someone receives a message whose envelope MAIL FROM and
> header "From:" fields show
>   "alexey=40example.com@dmarc.ietf.org"
> and replies to it offlist without recognizing the convention or
> de-converting the address, I assume that dmarc.ietf.org will
> recognize its own convention, rewrite the message headers, and
> send it off to alexey@example.com.  If it does not do that
> rewrite, then the message (or the copy addressed to him) bounces
> or gets lost, which is not necessarily a bad thing.  If it does
> do the rewrite, it works even if the convention is changed to
>    "alexey☺example.com@dmarc.ietf.org"
> as long as dmarc.ietf.org keeps track of all of the conventions
> it has used.  It does raise a privacy concern that might or
> might not be important -- if I pick up Alexey's address (that
> one) for use in a private reply, having the message pass through
> IETF mail servers leaves traces (and possibly the message in
> clear-text form and that might not be desirable.
>

(2) is closest to what I was curious about - whether if we are running =40
as the convention, and decide that =80 would be twice as good (just
kidding, I mean "any other value besides =40"), and implement the new
convention, if something good would happen someone who replies to an e-mail
that was processed using the original convention.

So I was stumbling toward asking if we planned to remember old conventions
if we adopted a new one, and it sounds like if we did remember old
conventions, most of the reply-to-old-convention e-mail would end up in the
right place, most of the time.

Your explanation was helpful. And thanks for clues, as always.

Spencer


> (3) If the expectation is that a delivery server or receiving
> MUA, upon receiving a message from, e.g.,
>      "alexey=40example.com@dmarc.ietf.org"
> will recognize the convention, decode it and present
> "alexey@example.com" to the user, well, don't hold your breath
> waiting for it to happen with this convention so worrying about
> how disruptive a change in convention might be is hardly worth
> the effort.  In addition, if we wanted / expected that
> recognition to occur, I'd expect to see an Internet-Draft
> proposing some sort of standards action to establish the
> convention and encourage all mail systems to recognize it.
> Alexey quite noticeably did not propose that.
>
> best,
>     john
>
>