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

Brandon Long <blong@google.com> Tue, 15 May 2018 22:15 UTC

Return-Path: <blong@google.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 61C7B126E01 for <ietf@ietfa.amsl.com>; Tue, 15 May 2018 15:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -18.209
X-Spam-Level:
X-Spam-Status: No, score=-18.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 amURH83f7W81 for <ietf@ietfa.amsl.com>; Tue, 15 May 2018 15:15:19 -0700 (PDT)
Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 B51DF126D73 for <ietf@ietf.org>; Tue, 15 May 2018 15:15:19 -0700 (PDT)
Received: by mail-it0-x236.google.com with SMTP id q4-v6so5926379ite.3 for <ietf@ietf.org>; Tue, 15 May 2018 15:15:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3lRPY1cv1DPCxBtKZREYNc7DoA2dgR4f794s7hqfqUk=; b=n6d8ouJq9cQN/wi80/TzdE7NBt2tZlYjAVJxdFZAUUgI4d4/OIiuCyWFEUL1kdhWfF UOHXRJrTdTQEX0KlUZqfde7dlCzznvhBVAzUziSI0UTTV3R/f9jerPg1vmLDZsLIdX/u e69fHzJbcX7igvJgFCbqlsCUxeO4kwHWnOdfXyx8/qwDdA+INwSVJy4KyR4YG8OVLLXu 765QBT8NzoZx9JEdE1iEaI4o5D6Re0NV+iJ80TENv2CGQTkUOn+9A6GXzvkzyBYmA+Av 2fYzwMwoRVTDusyFZ7CoyeCN0kARrsynO7+5Pek7IVaHaDdoosMdeBP9C8B5Jy0615HA J/AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3lRPY1cv1DPCxBtKZREYNc7DoA2dgR4f794s7hqfqUk=; b=HAY/5xpLuDjWjNzReiqj7yLw9e2KOb+xK51ZWQEf/lQye5l4G7wcuQBlqA6duD2PX1 CICTcDJmsORaUGA/U9nAk5GT/Mvw1oFdROTTvvExt53oGnABr4OS8QCR5MVxv0Ufut/d 6tubf6wNTZH11jXPGTlr4xHGVtssqCSd+Fpq1pIOXUgH4wmeUwsxqvxI93YLRqlysSxC JrdycluvlZ1LvQHmbWFaN8RHEgake8EN+jVSjZ4YfMpvYch0LLcnF3FjfV2nFLBDCvjm gagERJGykWoY2xHhDnhSbTp62s2V3FeA+Ae+ydV1TB1VnplCT/O/YuyvlTA4K3XbKkED uUHA==
X-Gm-Message-State: ALKqPwfU17NzcKwmp3gNYnT3Pk4x3/Vn0113ezEryBMBihwzDdZX5c7P Bi5NWNS+VAvFUbYSee7qA1WB00jhD501CcN2AQpe
X-Google-Smtp-Source: AB8JxZpzuroxDEk0SSUNGNsKpSfi1rfo4rB8ZEBcop8Z/YHrcb3agM9wB1I+IFeCWA/Ff2Nrv5dwm260VyNyihwxAzM=
X-Received: by 2002:a6b:33c5:: with SMTP id z188-v6mr19409179ioz.112.1526422518292; Tue, 15 May 2018 15:15:18 -0700 (PDT)
MIME-Version: 1.0
References: <919855CA-9F77-420A-8B8F-79174CD2FC19@fastmail.fm> <5849b364-ee61-6c0c-4905-b7bca88d2fd3@tana.it>
In-Reply-To: <5849b364-ee61-6c0c-4905-b7bca88d2fd3@tana.it>
From: Brandon Long <blong@google.com>
Date: Tue, 15 May 2018 15:15:03 -0700
Message-ID: <CABa8R6szrVEeW9BC+1Mv1mMGq1a=HLPrFDZai1=+uojULXQ=yA@mail.gmail.com>
Subject: Re: Enabling DMARC workaround code for all IETF/IRTF mailing lists
To: Alessandro Vesely <vesely@tana.it>
Cc: aamelnikov@fastmail.fm, IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fc0a6d056c45ef55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ha2hG8z9lfsc86ZffgQe8-A_0r4>
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: Tue, 15 May 2018 22:15:25 -0000

On Sun, May 13, 2018 at 4:50 AM Alessandro Vesely <vesely@tana.it> wrote:

> Just a couple of notes:
>
> On Fri 11/May/2018 14:00:15 +0200 Alexey Melnikov wrote:
> >
> > Below are some technical details on how the email address rewriting
> workaround is going to work:
> >
> > Emails from domains that don't have a p=reject DMARC setting are not
> going to be affected in any way.
> >
> > For emails from p=reject domains:
>
> Some put p=reject; pct=0; for the sole purpose of having From: rewritten.
> The
> principle of least surprise would suggest to apply rewriting uniformly.
>
> > - The From header field of such emails will be rewritten to be under
> > @dmarc.ietf.org domain (which will have a p=none policy). For example,
> > "alexey@example.com" email address would become
> > "alexey=40example.com@dmarc.ietf.org". The original From header field
> will
> > be preserved in the X-Original-From header field, which can be used for
> > automatic message processing by Sieve and Mail User Agents.
> Besides encoding, the semantic of alexey=40example.com@dmarc.ietf.org will
> never be clear, even to those familiar with DMARC.  My experience after
> replying "all" on one of those messages was not what I expected, and I
> couldn't
> tell if that was a bug[*].  How about just appending the original address
> to
> Reply-To[**]: and keep the From: address as simple as dmarc@ietf.org?
>

One of the benefits for having a per-sender unique from address to rewrite
to, is that it plays better with email clients who might otherwise get
confused that all of the messages are from the same person.  For example,
Gmail doesn't display quite right the "authors" of a thread if they're all
from the mailing list.  Other address book software might "learn" the name
of a list, or add the list address to the name or other confusion.

That said, using unique rewrites does open up a different can of worms in
terms of spam forwarding and different types of address book issues.

A client could use the List-ID header matching the From header to be
smarter, it's a bit harder if every mailing list provider used a different
rewriting scheme
to be smarter.

Which works better in practice, I don't know.  Adding Reply-To, even if the
from keeps the per-user rewriting, is probably a good idea.

Brandon