Options for temporary operational solution to DMARC problem
Ted Lemon <mellon@fugue.com> Thu, 03 November 2016 22:21 UTC
Return-Path: <mellon@fugue.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 2D5951296DB for <ietf@ietfa.amsl.com>; Thu, 3 Nov 2016 15:21:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.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 FPuVVjbakxwl for <ietf@ietfa.amsl.com>; Thu, 3 Nov 2016 15:21:49 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 4C7351296AF for <ietf@ietf.org>; Thu, 3 Nov 2016 15:21:49 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id q130so76387799qke.1 for <ietf@ietf.org>; Thu, 03 Nov 2016 15:21:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QIh+EYLwQ+TIDpjkvQoBzypLL2XMwQ1bETTE4R5IO3w=; b=kf/o4wmP8/64BGLkY/f1CU8ExI7SDQxcv/dyDBx03YeoEij3UDkT35f7lIW9Hpo8PH qBhl88UJN628tih2XRnBBSDhaupcMk77vBFPQ/T0ORuolfsRYNhK+DZUiwq0rowuIVo6 aihv+rbzJ7kD2wpn8zD1fU07ld8KPhb0iW9keTd1T5hp0hkDildirGpnMRTWrguNPZLe /7kipCQs3TQ7dHES/ZwXpCes/BM7xusdeyBxFGTyIzfSbTBLOfgJf2Im8Qmr8X6Fsgwn q1f8rnzrWJm2w3T1MHeBY+kO0KvmNF6gc66HVD7jY4BCRB9g3E3dqGG104aYmevKsrOf geBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QIh+EYLwQ+TIDpjkvQoBzypLL2XMwQ1bETTE4R5IO3w=; b=b0T15CV1RDacKd4M7re33KvFEx4jchFjr0WRrqQn2Ne3WMKzCWYFQludgnkoGL1GWi aGiPlMVWveZv97L6oKgeq/DqOrcdkxb+aVKfDRupEjHFiII+CgPCg2OSYGB6wb2kfSt3 PAEa39AZ7kN9OKp5NfTa+4kMd40KMwNh2uuk+Yo10ItoHMNf+QfxHpZ5uZO9mPdoa5FX mVqfbtlAzIlhFeVEj33ghlPUMu3yE2ZH6K3N2yBugXBrlfmTSDsFwmIniLlu5qi91uhF 4VfBGhVHlQr/ppyekWRvANNJE9fS9XB2BJxHVNQnhgl1W7ed72UzXOfQxFFl8clKQvzh pNSQ==
X-Gm-Message-State: ABUngvc28Vb/TN9UYojS+T9x5Harh1DlBVdhS7RDupMKv4LT8TgnIbH2I0TvtgRUrAfogw==
X-Received: by 10.55.6.14 with SMTP id 14mr10306267qkg.167.1478211708309; Thu, 03 Nov 2016 15:21:48 -0700 (PDT)
Received: from [10.0.20.146] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i19sm5765344qte.8.2016.11.03.15.21.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 15:21:47 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <1F305C1D-7228-4084-9F33-8834AAAC82CB@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_86898AF1-772A-4D56-ACAA-A4B431C140C9"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Options for temporary operational solution to DMARC problem
Date: Thu, 03 Nov 2016 18:21:45 -0400
In-Reply-To: <20161103220326.jz2mtk6s7tvdg55v@thunk.org>
To: IETF <ietf@ietf.org>
References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <CABa8R6vHdt75NFKW3s6xOzLcq=jmVAHDPX0tjLRdGpYSTP2cYA@mail.gmail.com> <20161102232357.b55vx7est7vjrdfo@thunk.org> <CO2PR00MB01018CDB45F0CE17671AD67596A30@CO2PR00MB0101.namprd00.prod.outlook.com> <20161103134909.lnndzi6feaqfskyj@thunk.org> <CO2PR00MB0101960D3E311D2E1D4E1C4296A30@CO2PR00MB0101.namprd00.prod.outlook.com> <20161103220326.jz2mtk6s7tvdg55v@thunk.org>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pNXnFcAo__60Ob9osiviMw9PO2w>
Cc: The IESG <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 03 Nov 2016 22:21:52 -0000
My understanding is that there are really four possible approaches: Bounce messages from sites that have p=REJECT; users at those sites have to use some other email address for IETF business. Rewrite From: header on messages from sites that have p=REJECT to point at discard address Rewrite all From: headers to point at discard address Rewrite all From: headers to reply to addresses that forward to senders for senders with p=REJECT What it means to rewrite a From: header to point at a discard address is probably that the mailbox name will be changed to some admin address that is silently discarded, and the display name will be changed to add "via mailing-list". So e.g., Ted Lemon <mellon@fugue.com <mailto:mellon@fugue.com>> would be changed to Ted Lemon via ietf <drop-silently@ietf.org <mailto:drop-silently@ietf.org>>. For extra credit, drop-silently@ietf.org <mailto:drop-silently@ietf.org> could drop silently if the To: and Cc: headers contain multiple addresses, but generate a bounce if the _only_ address is drop-silently@ietf.org <mailto:drop-silently@ietf.org>. There would probably need to be a list ID so that the bounce message could make sense—it would probably say something like "you tried to reply to sender, but it didn’t work, here’s why, here’s what to do." Advantages of 1: Relatively easy Does not alter sender information, so no unexpected behavior in MUAs Supported by mailman. Disadvantages of 1: Substantial inconvenience for people who are unfortunate enough to work for orgs that use p=REJECT Possible snowball effect if more sites adopt p=REJECT (e.g., gmail.com <http://gmail.com/>). Requires checking p=REJECT when processing mail Advantages of 2: Does not inconvenience senders from sites with p=REJECT Minimizes whose headers are rewritten Supported by mailman Disadvantages of 2: Lots of moving parts (e.g., have to check p=REJECT when processing mail) Email from senders at sites with p=REJECT can’t be sorted the same way mail from other senders can be; inconvenient for users who use rule-based sorting on IETF lists Harder to send off-list replies if sender is from site with p=REJECT; reply-to-sender in MUA will be handled as described above. Advantages of 3: Does not inconvenience senders from sites with p=REJECT Does not require checking to see whether p=REJECT is in effect for a particular user Disadvantages of 3: Email from all senders can no longer be sorted as before, so everybody’s procmail filters, etc, break maximally Harder to send off-list replies, reply-to-sender in MUA will be handled as described above. Advantages of 4: Doesn’t inconvenience any mailing list user Behavior is as it always was Disadvantages of 4: Requires state for each sender from a site with p=REJECT Possible resource exhaustion attack Probably requires substantial programming and testing work; risk of data loss Would take a long time to deploy; might not be quicker than waiting for ARC outcome I think it is really up to the IESG to decide which of these plans to adopt. However, if people are interested in talking about what to do, I think this is a decent enumeration of the options (please correct me if I am wrong). My personal opinion is that option 2 is the least disruptive option, and I believe it is supported by mailman. Option 1 is the most technically correct option that we have right now, but I think technical correctness is not the right value to optimize for _right now_. Technical correctness can be restored once ARC completes and is deployed at the sites we are having trouble with; right now, I think the solution that removes the most pain is the best one. I mentioned options 3 and 4 for completeness, but I think 3 is unnecessarily heavy, and option 4 is too much work.
- Re: IETF Mailing Lists and DMARC Dave Crocker
- IETF Mailing Lists and DMARC Cullen Jennings
- Re: IETF Mailing Lists and DMARC John Levine
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC John Levine
- RE: IETF Mailing Lists and DMARC MH Michael Hammer (5304)
- RE: IETF Mailing Lists and DMARC John R Levine
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC John Levine
- Re: IETF Mailing Lists and DMARC Dave Crocker
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC Paul Hoffman
- Re: IETF Mailing Lists and DMARC John C Klensin
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC Michael Richardson
- Re: IETF Mailing Lists and DMARC Yoav Nir
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC Yoav Nir
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Hector Santos
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Dave Crocker
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brandon Long
- Re: IETF Mailing Lists and DMARC Cullen Jennings
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Cullen Jennings
- Re: IETF Mailing Lists and DMARC S Moonesamy
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brian E Carpenter
- Re: IETF Mailing Lists and DMARC John Levine
- Re: IETF Mailing Lists and DMARC John Levine
- Identification of an email author (was - Re: [dma… Dave Crocker
- Re: IETF Mailing Lists and DMARC Ted Lemon
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Theodore Ts'o
- RE: [dmarc-ietf] IETF Mailing Lists and DMARC Terry Zink
- Re: IETF Mailing Lists and DMARC John Levine
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Theodore Ts'o
- Next step on IETF Mailing Lists and DMARC Alexey Melnikov
- Re: IETF Mailing Lists and DMARC Bob Hinden
- RE: IETF Mailing Lists and DMARC MH Michael Hammer (5304)
- Re: IETF Mailing Lists and DMARC Ted Lemon
- RE: [dmarc-ietf] IETF Mailing Lists and DMARC Terry Zink
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Andrew G. Malis
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Steve Atkins
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Andrew G. Malis
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Theodore Ts'o
- Options for temporary operational solution to DMA… Ted Lemon
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brandon Long
- Re: [dmarc-ietf] Identification of an email autho… Brandon Long
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Franck Martin
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Hector Santos
- Re: Options for temporary operational solution to… Andrew G. Malis
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC John C Klensin
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Ted Lemon
- Re: IETF Mailing Lists and DMARC Michael Richardson
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Michael Richardson
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Michael Richardson
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC John C Klensin
- Re: Options for temporary operational solution to… John Leslie
- RE: [dmarc-ietf] Identification of an email autho… Terry Zink
- Re: Options for temporary operational solution to… Toerless Eckert
- Re: [dmarc-ietf] Identification of an email autho… Ted Lemon
- Re: Options for temporary operational solution to… John Levine
- RE: [dmarc-ietf] Identification of an email autho… Terry Zink
- Re: Options for temporary operational solution to… Ted Lemon
- RE: [dmarc-ietf] IETF Mailing Lists and DMARC Christian Huitema
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brian E Carpenter
- Re: Options for temporary operational solution to… Michael Richardson
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Michael Richardson
- Re: Options for temporary operational solution to… Dave Crocker
- Re: [dmarc-ietf] Identification of an email autho… Franck Martin
- Re: [dmarc-ietf] Identification of an email autho… Khaled Omar
- Re: [dmarc-ietf] Identification of an email autho… S Moonesamy
- Re: [dmarc-ietf] IETF Mailing Lists and DMARC Brandon Long
- Re: [dmarc-ietf] Identification of an email autho… Dave Crocker
- Re: [dmarc-ietf] Identification of an email autho… Dave Crocker
- Re: [dmarc-ietf] Identification of an email autho… ned+ietf
- Re: [dmarc-ietf] Identification of an email autho… Franck Martin
- Re: [dmarc-ietf] Identification of an email autho… Dave Crocker
- Re: [dmarc-ietf] Identification of an email autho… John C Klensin
- Re: [dmarc-ietf] Identification of an email autho… Brandon Long