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

John C Klensin <john-ietf@jck.com> Fri, 11 May 2018 21:36 UTC

Return-Path: <john-ietf@jck.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 7478212D88D for <ietf@ietfa.amsl.com>; Fri, 11 May 2018 14:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 ZSe4aAYGhv97 for <ietf@ietfa.amsl.com>; Fri, 11 May 2018 14:36:31 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC48126DD9 for <ietf@ietf.org>; Fri, 11 May 2018 14:36:31 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1fHFiH-000CjF-Ss; Fri, 11 May 2018 17:36:29 -0400
Date: Fri, 11 May 2018 17:36:22 -0400
From: John C Klensin <john-ietf@jck.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
cc: Alexey Melnikov <aamelnikov@fastmail.fm>, IETF list <ietf@ietf.org>
Subject: Re: Enabling DMARC workaround code for all IETF/IRTF mailing lists
Message-ID: <B47EF05A530D8024BE6B3B78@PSB>
In-Reply-To: <CAKKJt-cH8ZhkdspxG9kW=QwGZN-e3ek=+hx5uPXBZtSOsjm2-A@mail.gmail.com>
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> <CAKKJt-cH8ZhkdspxG9kW=QwGZN-e3ek=+hx5uPXBZtSOsjm2-A@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/fA4Lan-DGq98fCbW-HMcS62q56o>
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 21:36:33 -0000


--On Friday, May 11, 2018 15:31 -0500 Spencer Dawkins at IETF
<spencerdawkins.ietf@gmail.com> wrote:

>...
>> (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.

Glad to help.  Incidentally, while my mini-analysis had not
gotten that far, Victor is probably correct.  If mail can
actually be sent to
   "alexey=40example.com@dmarc.ietf.org"
with the expectation of delivery to 
   "alexey@example.com"

we would need to either have a very complex filtering or
validation system or we would basically have created an open
relay (btw, another issue with the use of "%").  For that
reason, it might actually be better to either refuse to accept
incoming mail with dmarc.ietf.org as a nominal destination or to
bounce all such mail with a message similar to 

   550 No such mailbox; this was a cheap hack to prevent DMARC
problems with mailing list postings

And just move on.  I'm confident that those who worry about
blowback and similar bad behavior would prefer the former.   If
that were the approach, it really wouldn't make any difference
what conventions were used or how often they were changed as
long as a competent human could manually decode them.

best,
   john