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
- Re: Enabling DMARC workaround code for all IETF/I… Andrew G. Malis
- Re: Enabling DMARC workaround code for all IETF/I… Russ Housley
- Re: Enabling DMARC workaround code for all IETF/I… Andrew G. Malis
- Enabling DMARC workaround code for all IETF/IRTF … Alexey Melnikov
- Re: Enabling DMARC workaround code for all IETF/I… Andrew G. Malis
- Re: Enabling DMARC workaround code for all IETF/I… John C Klensin
- RE: Enabling DMARC workaround code for all IETF/I… MH Michael Hammer (5304)
- RE: Enabling DMARC workaround code for all IETF/I… John C Klensin
- Re: Enabling DMARC workaround code for all IETF/I… Alexey Melnikov
- Re: Enabling DMARC workaround code for all IETF/I… Ted Lemon
- Re: Enabling DMARC workaround code for all IETF/I… Andrew G. Malis
- Re: Enabling DMARC workaround code for all IETF/I… John C Klensin
- Re: Enabling DMARC workaround code for all IETF/I… Spencer Dawkins at IETF
- Re: Enabling DMARC workaround code for all IETF/I… John C Klensin
- Re: Enabling DMARC workaround code for all IETF/I… Viktor Dukhovni
- Re: Enabling DMARC workaround code for all IETF/I… Spencer Dawkins at IETF
- Re: Enabling DMARC workaround code for all IETF/I… John Levine
- Re: Enabling DMARC workaround code for all IETF/I… John C Klensin
- Re: Enabling DMARC workaround code for all IETF/I… Viktor Dukhovni
- Re: Enabling DMARC workaround code for all IETF/I… John Levine
- Re: Enabling DMARC workaround code for all IETF/I… Viktor Dukhovni
- Re: Enabling DMARC workaround code for all IETF/I… Hector Santos
- Integrity of mail systems (was Re: Enabling DMARC… Andrew Sullivan
- Re: Enabling DMARC workaround code for all IETF/I… Alessandro Vesely
- Re: Integrity of mail systems (was Re: Enabling D… John C Klensin
- Re: Integrity of mail systems (was Re: Enabling D… Michael Richardson
- Re: Integrity of mail systems (was Re: Enabling D… Phillip Hallam-Baker
- Re: Enabling DMARC workaround code for all IETF/I… Hector Santos
- Re: Enabling DMARC workaround code for all IETF/I… Brandon Long
- Re: Enabling DMARC workaround code for all IETF/I… Brian E Carpenter
- Re: Enabling DMARC workaround code for all IETF/I… Glen