Re: Options for temporary operational solution to DMARC problem
Toerless Eckert <tte@cs.fau.de> Fri, 04 November 2016 20:53 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 94FC51279EB; Fri, 4 Nov 2016 13:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.696
X-Spam-Level:
X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 rGvlSI4UIgTA; Fri, 4 Nov 2016 13:53:26 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7071200DF; Fri, 4 Nov 2016 13:53:25 -0700 (PDT)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4FDE558C4AF; Fri, 4 Nov 2016 21:53:24 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3AB1BB0AD31; Fri, 4 Nov 2016 21:53:24 +0100 (CET)
Date: Fri, 04 Nov 2016 21:53:24 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Ted Lemon <mellon@fugue.com>
Subject: Re: Options for temporary operational solution to DMARC problem
Message-ID: <20161104205324.GA11905@faui40p.informatik.uni-erlangen.de>
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> <1F305C1D-7228-4084-9F33-8834AAAC82CB@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1F305C1D-7228-4084-9F33-8834AAAC82CB@fugue.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/s12fB0mL-uZyNFiqtRCUi2Febc0>
Cc: IETF <ietf@ietf.org>, 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: Fri, 04 Nov 2016 20:53:28 -0000
Ted, *: a) Fluffy's original mail also described illigitimate senders DOS attacks to auto-unsubscribe IETF mailing list participants. I only remember two answers in this long thread to that question: RTFML from JohnL and "have mailman do DMARC rejections itself" from mcr. Has this problem been observed (auto-unsubscribe because of explicit attacks ?) How would it change under your proposed options (you seem to only focus on the impact of legitimiate p=reject senders). To me, mcr's recommendation sounds good, and i don't believe ARC adoption would ever be fast/complete enough to to not do it but "just wait for ARC". b) Given how your proposed solutions have all pro/cons, i would strongly suggest to also consider first options to raise awareness to the problem via mailman: Eg: Does IETF mailman send any mails to senders or receivers to inform them if/when they are DMARC victims ? And warn of potentially impending auto-unsubscribe to receivers ... ? Or give suggestions/hints to senders/receiver including eg: - use a DMARC-free email account for sending - Check email archives or add another receiver account with digest if you fear you're loosing emails due to DMARC issues - subscribe to dmarc@ietf.org if you're technically versed and want to contribute Typically all mailman error messages are totally cryptic and non-decipherable for non-mail-gurus. c) Wrt to your options: - do DMARC check in mailman, reject p-reject failures (mcr) - provide good visibility on rejection - rewrite accepted DMARC p=reject sender address stateless, eg: orig-sender%orig-domain@dmarc-reply.ietf.org Ideally, do this only if the sender has opted in, eg: via a subscription option. Of course the reply alias should only work for mailing list participants so it ha the same DOS protection as other mailman forwarders. Kinda a mix of your 2+4 Cheers Toerless On Thu, Nov 03, 2016 at 06:21:45PM -0400, Ted Lemon wrote: > 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. > -- --- tte@cs.fau.de
- 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